SAP liefert doch das Cloud Integration Gateway mit. Wozu brauche ich dann noch etwas?

Bei einem einzelnen S/4HANA-System mit Standard-Prozessen in Ariba Buying and Invoicing reichen das SAP Ariba Cloud Integration Gateway und der vorkonfigurierte Content der SAP Integration Suite in der Regel aus - das sagen wir Ihnen auch. Interessant wird es dort, wo der Standard-Content aufhört: mehrere ERP-Backends hinter einem Ariba-Realm, kundeneigene Z-Felder auf der Bestellung, Dienstleistungsbeschaffung mit Leistungserfassungsblättern, Drittsysteme, die dieselben Einkaufsdaten brauchen, oder Fehlerbehandlung, die im Kreditorenteam sichtbar sein muss statt in einem Monitoring-Cockpit, in das niemand schaut.

Wo entsteht die Bestellung - in Ariba oder in S/4HANA?

Beide Modelle sind verbreitet, und die Entscheidung prägt das gesamte Design. Im Ariba-geführten Modell entstehen Bedarfsanforderung und Bestellung in Ariba, die Bestellung wird nach S/4HANA repliziert und dient dort als Basis für Wareneingang und Rechnungsprüfung. Im ERP-geführten Modell wandert die Anforderung nach S/4HANA, der Einkauf legt die Bestellung in MM an, und der Beleg geht über das SAP Business Network an den Lieferanten. Diese Frage klären wir vor dem ersten Mapping, denn sie entscheidet, welches System Belegnummern und Freigaben besitzt.

Wie ordnen Sie Lieferanten im Business Network den SAP-Geschäftspartnern zu?

Ein Lieferant im SAP Business Network wird über seine ANID identifiziert, S/4HANA kennt dagegen einen Geschäftspartner in der Lieferantenrolle, eine Kreditorennummer meist mit führenden Nullen sowie getrennte Buchungskreis- und Einkaufsorganisationssichten. Eine ANID kann auf mehrere Kreditorenstammsätze in verschiedenen Buchungskreisen zeigen, abweichende Zahlungsempfänger kommen obendrauf. Wir pflegen diese Zuordnung explizit und replizieren sie aus S/4HANA, statt über Name oder USt-IdNr. zu raten.

Was passiert, wenn eine Rechnung in S/4HANA nicht gebucht werden kann?

Sie wird sichtbar gemacht, nicht stillschweigend wiederholt. Typische Ursachen sind ein unzulässiges Steuerkennzeichen, Mengen- oder Preisabweichungen außerhalb der Toleranz, ein fehlender Wareneingang oder die Dublettenprüfung. Die Pipeline nimmt die SAP-Meldung auf, hält den Beleg in einem wiederholbaren Zustand und meldet einen Rechnungsstatus an das Ariba Network zurück, damit der Lieferant eine echte Auskunft bekommt. Blind wiederholt wird nichts - eine blind wiederholte Rechnung ist eine doppelte Verbindlichkeit.

Wer betreibt die Schnittstelle nach dem Go-live?

Wir. Die Pipeline läuft auf cloud-nativer, vollständig EU-gehosteter Infrastruktur, die wir überwachen. Ändert Ariba ein cXML-Schema oder setzt SAP einen freigegebenen OData-Service ab, ist das unser Problem - keine hängende Buchung, die Ihr Einkauf zum Periodenabschluss entdeckt. Sie bekommen einen festen Ansprechpartner, Alerting, Incident Response und ein SLA statt eines Integrationsflusses, für den sich nach Projektende niemand mehr zuständig fühlt.

SAP Ariba SAP S/4HANA Schnittstelle

Was eine Anbindung von SAP Ariba an SAP S/4HANA wirklich leistet

In Ariba wird Bedarf verbindlich. Bedarfsanforderungen entstehen im Guided Buying gegen Kataloge und Verträge, durchlaufen die Freigabe und werden zu Bestellungen, die den Lieferanten über das SAP Business Network erreichen. In S/4HANA wird daraus Buchhaltung: der Einkaufsbeleg, der Wareneingang, die WE/RE-Abgrenzung, die Verbindlichkeit gegenüber dem Kreditor, der Zahllauf.

Weil beides SAP ist, wird gern unterstellt, die Systeme sprächen ohnehin miteinander. Sie tauschen Belege aus, aber sie teilen kein Datenmodell. Ariba spricht cXML über ein Lieferantennetzwerk und identifiziert Partner über Netzwerk-IDs; S/4HANA denkt in Einkaufsbelegen mit Buchungskreis, Einkaufsorganisation, Werk und Geschäftspartner. Eine Ariba-S/4HANA-Anbindung ist genau die Schicht, die beide Sichten in beide Richtungen zusammenbringt: Stammdaten hinunter in den Ariba-Realm, damit im Einkauf nur kontiert werden kann, was SAP akzeptiert - und Belege hinauf ins ERP als echte MM- und FI-Buchungen.

Welche Daten fließen

Objekt / Vorgang in SAP Ariba	Wird in SAP S/4HANA zu	Hinweis
Freigegebene Bedarfsanforderung (Guided Buying)	Bestellanforderung (EBAN) oder Bestellung	Je nachdem, ob Ariba oder das ERP bestellführend ist
Bestellung (cXML OrderRequest)	Bestellung (EKKO / EKPO)	Über API_PURCHASEORDER_PROCESS_SRV oder ORDERS-IDoc; Ariba-Belegnummer bleibt als Fremdreferenz erhalten
Änderungsbestellung / Stornierung	Neuer Belegstand bzw. Löschkennzeichen	Der Versionszähler muss den Rückweg überstehen, sonst verdoppeln sich Positionen
Auftragsbestätigung (ConfirmationRequest)	Bestätigung zur Bestellposition (EKES)	Setzt den passenden Bestätigungssteuerschlüssel voraus
Lieferavis (ShipNoticeRequest)	Anlieferung / Inbound Delivery	Optional, nur wenn der Wareneingang aus dem Netzwerk gesteuert wird
Wareneingang in S/4HANA gebucht	ReceiptRequest ans Business Network	Gegenrichtung, damit Lieferanten den Status sehen
Leistungsnachweis	Leistungserfassungsblatt (ML81N / Lean Services)	Auf Leistungsstamm und Kontierung abgebildet
Lieferantenrechnung (InvoiceDetailRequest)	Rechnung in der Logistik-Rechnungsprüfung oder FI-Beleg	Bestellbezogene Rechnungen gegen Bestellung und Wareneingang geprüft
Rechnungsstatus	StatusUpdateRequest zurück an Ariba	Angenommen, abgelehnt, bezahlt - für den Lieferanten sichtbar
Ergebnis des Zahllaufs (F110)	PaymentRemittanceRequest	Schließt den Kreis im Netzwerk
Geschäftspartner, Materialien, Werke, Kostenstellen, Sachkonten, Steuerkennzeichen, Mengeneinheiten, Kurse	Stammdaten-Replikation in den Ariba-Realm	Die Gegenrichtung, die den Hinweg überhaupt erst sauber buchen lässt

Die Details, an denen einfache Mappings scheitern

Bestellhoheit. Legt Ariba die Bestellung an und S/4HANA erzeugt aus der replizierten Anforderung noch eine zweite, stehen zwei Einkaufsbelege für eine Verpflichtung im System. Das ist kein Mapping-Fehler, den man später korrigiert, sondern eine Designentscheidung, die einmal getroffen und von der Pipeline erzwungen werden muss.
Lieferantenidentität. ANID zu Geschäftspartner ist selten eine Eins-zu-eins-Beziehung. Kreditorennummern tragen führende Nullen, ein Lieferant existiert oft in mehreren Buchungskreisen, Bestell- und Zahlungsadresse weichen ab. Unscharfes Matching über Name oder USt-IdNr. scheitert lautlos und bucht auf das falsche Konto.
Mengeneinheiten. Ariba führt UN/CEFACT-Codes, SAP interne, sprachabhängige Einheiten - EA gegen ST ist der Klassiker. Eine falsche Einheit erzeugt keinen Fehler, sie verändert die Menge, die eingeht.
Steuerkennzeichen. Ariba-Rechnungen tragen Steuerkategorien und Sätze, SAP bucht gegen ein Steuerkennzeichen. Inländische Umsatzsteuer, Reverse Charge nach § 13b UStG und steuerfreie innergemeinschaftliche Lieferung sind verschiedene Schlüssel; eine Abweichung ist ein Buchungsfehler, keine Rundungsdifferenz.
Währung und Preisgenauigkeit. Belegwährung, Buchungskreiswährung, Kurs zum Buchungsdatum und Preiseinheit der Bestellposition müssen zusammenpassen, sonst scheitert die dreiseitige Prüfung an Cent-Beträgen.
Reihenfolge der Belege. Trifft die Rechnung vor dem Wareneingang ein, bleibt sie gesperrt. Die Pipeline muss die fachliche Reihenfolge einhalten und nicht in der Sortierung buchen, in der sie die Belege abgeholt hat.
Delta statt Vollabzug. Stammdaten gehören als verlässliches Delta über SAP-Änderungszeiger übertragen. Ein nächtlicher Vollabzug von Kreditoren und Kostenstellen ist langsam, verbirgt Löschungen und ist zwischen zwei Läufen veraltet.
Wiederholungen und Dubletten. Ein cXML-Beleg, der nicht sauber quittiert wird, kommt erneut. Ohne Dublettenschutz über die Payload-ID wird aus einem erneut zugestellten InvoiceDetailRequest eine zweite Verbindlichkeit. Die Reporting-Schnittstellen von Ariba arbeiten seitenweise und mit Zeitfenstern, überlappende Abfragen sind also der Normalfall.
Teilfehler. S/4HANA weist einen kompletten Beleg zurück, wenn eine einzige Position eine unzulässige Kontierung trägt. Positionsgenaue Validierung vor der Übergabe und danach sichtbare Fehler sind der Unterschied zwischen einer Pipeline, die sich selbst fängt, und einer Warteschlange, die niemand leert.

Wie wir sie bauen und betreiben

Wir behandeln das als Pipeline, nicht als Projektlieferung, die nach dem Go-live niemandem mehr gehört. Belege werden aus Ariba und dem SAP Business Network abgeholt, gegen die aktuellen S/4HANA-Stammdaten validiert, in die abgestimmte Belegstruktur überführt und über die freigegebenen OData-Services oder die IDoc-Strecke geschrieben, die Ihr Basis-Team ohnehin betreibt. Wo das SAP Ariba Cloud Integration Gateway bereits im Einsatz ist und einen Prozess abdeckt, integrieren wir uns dort hinein, statt es zu ersetzen - Ziel ist eine funktionierende Landschaft, kein größerer Fußabdruck für uns.

Jeder Beleg trägt eine stabile Kennung, in der Regel die cXML-Payload-ID oder die Ariba-Belegnummer. Ein erneuter Lauf erzeugt damit nie eine zweite Bestellung und nie eine zweite Rechnung. Die Pipeline läuft auf cloud-nativer, vollständig EU-gehosteter AWS-Infrastruktur - Lieferanten- und Belegdaten verlassen die EU nicht, was AVV und DSGVO sauber hält.

Und dann halten wir sie am Laufen: Monitoring, Alerting, Incident Response und das Beobachten von Schema- und API-Änderungen auf beiden Seiten liegen vertraglich bei uns. Einkauf und Kreditorenbuchhaltung hören auf, fehlgeschlagenen Buchungen hinterherzulaufen, und der Periodenabschluss hängt nicht mehr daran, dass jemand an einen Blick in den Integrationsmonitor denkt.

Wann sich diese Anbindung lohnt

Wenn Sie ein S/4HANA-System, einen Buchungskreis, Standardprozesse in Ariba Buying and Invoicing und keine Eigenfelder haben, ist der SAP-Standard-Content die richtige Antwort - und das sagen wir Ihnen, statt daran vorbei zu verkaufen. Eine betreute Pipeline lohnt sich, wenn mehrere ERP-Backends hinter einem Ariba-Realm hängen, wenn Dienstleistungsbeschaffung und Rahmenbestellungen das Mapping vom Standard wegtreiben, wenn kundeneigene Felder den Rückweg überstehen müssen, wenn Rechnungsausnahmen Ihre Kreditorenbuchhaltung heute schon spürbar Zeit kosten, oder wenn Sie jemanden brauchen, der am Tag vor dem Abschluss um drei Uhr nachmittags vertraglich für die Schnittstelle zuständig ist.