Vom Paket in den Betrieb: S/4HANA Public Cloud und Sales Cloud V2

Um SAP S/4HANA Public Cloud und SAP Sales Cloud V2 über SAP Integration Suite zu verbinden, kopieren Sie zwei Standardpakete aus dem SAP Business Accelerator Hub in Ihren Tenant, konfigurieren und deployen sie, laden Codelisten und Stammdaten in fester Reihenfolge und schalten erst danach Angebote und Aufträge frei. Eigene Logik gehört in separate iFlows, nie in die von SAP.

TL;DR: Zwei Standardpakete decken Stammdaten (Version 1.0.48) und Vertriebsprozesse (Version 1.0.20) ab, Stand 7. Oktober 2026. Konfigurieren, nicht verändern: Ein geändertes oder umbenanntes Artefakt erhält keine SAP-Updates mehr. Zuerst Organisationsdaten und Codelisten laden, dann Produkte, dann Geschäftspartner, dann Transaktionen. Einen Datensatz und ein Angebot durchgängig testen, dazu drei Fehlerfälle. Im Betrieb braucht jede Fehlerart eine namentlich verantwortliche Person.

Sofiene Karaja hat die Integrationsarchitektur erklärt, Marek Budik das Verantwortungsmodell von Quote-to-Cash. Dieser Beitrag behandelt den Betrieb, vom Paket bis zur Produktion. Wenn SAP BAIP (ehemals BTP) für Sie neu ist, beginnen Sie mit der Einführung in SAP BAIP und den ersten Schritten mit einem Trial-Konto von Lea Marijanovic.

Zwei Betriebsarten: von SAP verwaltet oder vom Kunden verwaltet

Die Produktseite von SAP Sales Cloud V2 listet zwei Integrationsleitfäden für S/4HANA Cloud Public Edition. Der erste ist der Leitfaden «Set Up and Managed by SAP». Er gilt nur, wenn Ihr Vertrag die Integrations-Einrichtungsservices von SAP enthält.

In dieser Variante legt SAP Kommunikationsbenutzer, -systeme und -vereinbarungen an (in S/4HANA), konfiguriert die Integrationsflüsse in SAP Cloud Integration, richtet Standard-Wertemappings in Sales Cloud V2 ein und erneuert die Zertifikate. SAP ist Eigentümerin der Integrationsflüsse, überwacht und verwaltet sie.

Nach der Übergabe konfigurieren Sie Sales Cloud V2, ergänzen Wertemappings über die Standardwerte hinaus, führen den Initial Load durch, richten Single Sign-on ein und beheben fachliche Datenfehler in beiden Anwendungen. Die von SAP angelegte Kommunikationskonfiguration dürfen Sie nicht verändern.

Der zweite Leitfaden, «SAP Sales Cloud and SAP Service Cloud Version 2 Integration with SAP S/4HANA Cloud Public Edition», beschreibt den vom Kunden verwalteten Weg. Er liegt auf der SAP-Supportseite und verlangt ein SAP-Login, deshalb beschreibe ich diesen Weg unten anhand der Pakete und der Cloud-Integration-Dokumentation. Er gilt, wenn Ihr Vertrag den Einrichtungsservice von SAP nicht enthält oder wenn Sie Logik über den Standardumfang hinaus brauchen, denn Flüsse im Eigentum von SAP lassen keinen Platz für Ihre eigenen.

Was der Standardinhalt enthält

Beide Pakete liegen im SAP Business Accelerator Hub, werden von SAP gepflegt, Supportkomponente CEC-CRM-INT. Versionen mit Stand 7. Oktober 2026:

Paket	Version	Inhalt
Master Data with SAP S/4HANA Cloud Public Edition (Sales und Service Cloud V2)	1.0.48	46 iFlows, 1 Wertemapping, 1 Skriptsammlung
Sales Processes with SAP S/4HANA Cloud Public Edition (Sales Cloud V2)	1.0.20	12 iFlows, 1 Wertemapping

Gruppiert deckt das Stammdatenpaket ab:

• Geschäftspartner in beide Richtungen, dazu Geschäftspartnerbeziehungen in beide Richtungen, jeweils mit eigenem Bestätigungs-iFlow an den Absender.
• Produkte: Produkt, Produktart, Produktgruppe und eine Bestätigung für die Produktreplikation.
• Preise: Preiskonditionen, Kundenpreislistentyp, Preisspezifikation Kundengruppe, Skontobedingungen und ein Abruf der Preis-Customizing-Daten.
• Organisationsdaten: Buchungskreis, Verkaufsorganisation, Verkaufsbereich, Verkaufsbüro, Verkäufergruppe, Vertriebsweg, Sparte, Werk.
• Codelisten: Auftrags-, Liefer- und Fakturasperrgründe, Incoterms-Klassifikation, Lieferpriorität, Kundengruppe, ABC-Klassifikation, Branche, Rechtsform, Regionscodes, Mengeneinheit, VIP-Grund, Abteilung, Funktionsbezeichnung, Abrechnungszyklus.
• Serviceobjekte und Weiteres: Equipments, technische Plätze, Wechselkurse, Mitarbeitende und ein Abruf der Bestandsdaten von Produkten.

Das Paket für Vertriebsprozesse deckt ab: Folgeangebote in S/4HANA aus einer Opportunity, Simulation von Angebot und Kundenauftrag, Folgeaufträge aus einem Angebot, Replikation von Kundenaufträgen nach und aus S/4HANA, Abruf der Details von Folgeangeboten und -aufträgen sowie das Löschen von Angebots- und Auftragsreferenzen.

Drei Artefakte tragen das Präfix «Deprecated»: der alte Fluss für Regionscodes, ein älterer Fluss für Folgeaufträge und eine ältere Angebotssimulation. Deployen Sie den aktuellen Zwilling, nicht beide.

Aktivierungsreihenfolge und Konfiguration

Auf dem vom Kunden verwalteten Weg sieht die Abfolge in Ihrem Tenant so aus:

1. Beide Pakete kopieren, vom Bereich Discover in Ihren Design-Arbeitsbereich. Der technische Paketname wird dabei festgelegt und lässt sich später nicht mehr ändern.
2. Externalisierte Parameter konfigurieren für jeden iFlow (Adressen, Namen der Anmeldedaten). Nutzen Sie externalisierte Parameter, statt den Fluss selbst zu bearbeiten.
3. Security Material deployen: Anmeldedaten und Zertifikate, auf die die Parameter verweisen.
4. Wertemappings pflegen in beiden Paketen, für Ihre Codes.
5. Kommunikation auf beiden Seiten einrichten: Kommunikationsbenutzer, -system und -vereinbarungen in S/4HANA sowie Kommunikationssystem mit Inbound- und Outbound-Services in Sales Cloud V2. Die genauen Namen der Kommunikationsszenarien entnehmen Sie dem SAP-Einrichtungsleitfaden für Ihr Release.

Dann das Laden. Der SAP-Leitfaden nennt die Reihenfolge für den Initial Load: Buchungskreis, Organisationsstruktur, Produktgruppe, Produkt, Geschäftspartner und Beziehungen, Mitarbeitende. Codelisten kommen vor all dem. Angebote und Aufträge kommen zuletzt, sobald ein Testkunde und ein Testprodukt auf beiden Seiten existieren.

Zwei Voraussetzungen aus dem SAP-Leitfaden: Vor der Replikation der Codelisten braucht es eine Berechtigungsgruppe für Datenextraktions-Views (SAP Knowledge Base Article 3525713), und die Workforce-IDs unterscheiden sich zwischen beiden Systemen, sie brauchen deshalb ein Mapping über die externe ID der Arbeitszuordnung.

Standard oder eigen: wohin Ihre Logik gehört

Die SAP-Dokumentation zu Updates für SAP-Integrationspakete ist eindeutig. Ein geändertes Artefakt erhält keine Updates mehr, ein umbenanntes ebenso wenig. Konfigurierte externalisierte Parameter überstehen ein Paket-Update. SAP empfiehlt, den Standardinhalt nur zu konfigurieren.

Situation	Vorgehen	Aufwand beim nächsten Paket-Update
Andere Endpunkte, Anmeldedaten, Codewerte	Parameter und Wertemappings konfigurieren	Keiner, Einstellungen bleiben erhalten
Zusätzliches Feld oder zusätzliche Mapping-Regel	Separater eigener iFlow, aufgerufen aus dem Standardfluss, wo dieser einen Exit anbietet	Gering, der Standardfluss erhält weiter Updates
Standardfluss kann nicht, was Sie brauchen	Standard-iFlow kopieren, die Kopie ändern, die Abweichung dokumentieren	Hoch: Sie übernehmen jede SAP-Korrektur von Hand
Neues Szenario, das SAP nicht abdeckt	Separater eigener iFlow in einem eigenen Paket	Keiner für den Standardinhalt

Die SAP-Richtlinie Änderungen getrennt vom vorkonfigurierten Inhalt halten beschreibt das Muster: eigene Flüsse auf demselben Tenant, aufgerufen über Customer Exits und den ProcessDirect-Adapter. Unsere Konventionen: ein Kundenpräfix für jedes eigene Paket und jeden iFlow, eine neue Versionsnummer bei jedem Transport, eine kurze Notiz zur Abweichung in den Paketdokumenten.

Testen: ein Datensatz, ein Angebot, drei Fehlerfälle

Testen Sie auf den Test-Tenants, mit einem Datensatz, den Sie über jede Station verfolgen können.

#	Test	Erwartetes Ergebnis
1	Einen Geschäftspartner in S/4HANA ändern	Account in Sales Cloud V2 aktualisiert, Bestätigungsnachricht abgeschlossen
2	Opportunity, Angebot mit Live-Simulation, Folgeauftrag	Preis aus S/4HANA im Angebot, Auftragsnummer in Sales Cloud V2 sichtbar
3	Codewert ohne Wertemapping	Nachricht im Fehlerstatus mit lesbarem Grund, nichts halb geschrieben
4	Angebot mit einem Produkt, das S/4HANA nicht kennt	Simulation oder Folgebeleg scheitert sichtbar, der Verkauf sieht den Grund
5	Dieselbe Änderung zweimal senden	Kein doppelter Datensatz im Zielsystem; tatsächliches Verhalten dokumentieren

Notieren Sie, wer jeden Test ausgelöst hat und wo Sie das Ergebnis gesehen haben: Ihr erstes Betriebshandbuch.

Monitoring im Betrieb

Fehlerhafte Nachrichten erscheinen an drei Orten. In Cloud Integration listet Monitor Message Processing jeden Lauf mit seinem Status. In Sales Cloud V2 zeigt Settings, Integration, Message Monitoring eingehende und ausgehende Nachrichten als Successful, Error oder Pending, mit Payload und Fehlerdetails. S/4HANA hat ein eigenes Nachrichtenmonitoring.

SAP Cloud ALM Integration & Exception Monitoring bündelt das für die unterstützten Komponenten an einem Ort: Nachrichtenmonitoring, Tracking über fachliche Merkmale wie eine Auftragsnummer und Alerts zu fehlerhaften Nachrichten, die in einer Alert Inbox landen, wo Sie eine bearbeitende Person zuweisen. Die Business-Object-Seite zeigt den Status der Stammdatenreplikation.

Rhythmus	Prüfung	Verantwortlich
Täglich	Offene Alerts in Cloud ALM, Nachrichten im Status Error in Cloud Integration	Integrationsverantwortung
Täglich	Fachliche Datenfehler in Sales Cloud V2 und S/4HANA	Key User des Quellsystems
Wöchentlich	Nachrichten, die in Pending hängen, wiederkehrende Fehler je iFlow	Integrationsverantwortung
Wöchentlich	Hinweise «Update Available» im Design-Arbeitsbereich, Ablaufdaten der Zertifikate	Integrationsverantwortung
Bei jedem Paket-Update	Tests 1 bis 5 vor dem Transport in die Produktion wiederholen	Integrationsverantwortung mit Key Usern

Die Nachbearbeitung folgt der Verantwortung: Daten an der Quelle korrigieren, dann die Änderung erneut auslösen. Wer ohne Korrektur neu sendet, scheitert nur ein zweites Mal.

Mehr zu S/4HANA Public Cloud, SAP BAIP und zur Integration von Service Cloud V2. Möchten Sie Ihre eigene Landschaft durchgehen? Sprechen Sie mit uns.

Häufige Fragen

Muss ich die Integration in meinem eigenen SAP Integration Suite Tenant betreiben?

Nicht immer. Wenn Ihr Vertrag den Integrations-Einrichtungsservice von SAP enthält, konfiguriert SAP die Integrationsflüsse und ist für deren Betrieb, Überwachung und Verwaltung zuständig. Sonst kopieren Sie die Standardpakete von SAP in Ihren eigenen Integration Suite Tenant und betreiben sie selbst.

In welcher Reihenfolge lade ich die Daten?

Der SAP-Leitfaden nennt für den Initial Load diese Reihenfolge: Buchungskreis, Organisationsstruktur, Produktgruppe, Produkt, Geschäftspartner mit ihren Beziehungen, Mitarbeitende. Codelisten kommen zuerst, Transaktionsflüsse wie Angebote und Aufträge erst, wenn die Stammdaten vollständig sind.

Darf ich einen Standard-iFlow aus dem SAP-Paket ändern?

Technisch ja, beide Pakete lassen Änderungen zu. Die SAP-Dokumentation ist aber klar: Ein geändertes oder umbenanntes Artefakt erhält keine Updates mehr. Konfigurieren Sie, wo es geht, und legen Sie eigene Logik in separate iFlows neben die Standardflüsse.

Wer behebt im Betrieb eine fehlerhafte Nachricht?

Technische Fehler (Verbindung, Zertifikat, Deployment) gehören der Stelle, die für die Integration verantwortlich ist. Fachliche Datenfehler (fehlendes Mapping, gesperrter Kunde, unbekanntes Produkt) gehören dem Key User des Quellsystems. Auch in der von SAP verwalteten Variante belässt der SAP-Leitfaden fachliche Datenfehler beim Kunden.