Auftragssynchronisation zwischen Shop und ERP: SAP-APIs, Idempotenz und Abgleich

Die Auftragssynchronisation zwischen Shop und ERP ist der Kreislauf von Belegen, der aus einer Webshop-Bestellung einen ERP-Kundenauftrag macht und Bestätigungen, Lieferstatus und Rechnungen zurückbringt. Anders als bei der Produktdatensynchronisation ist ein Fehler hier kein falscher Preis auf einer Seite, sondern ein doppelter Kundenauftrag, ein verlorener Auftrag oder eine Rechnung, die nicht passt; damit wird er zum Finanzvorfall.

Dieser Artikel behandelt, wem welcher Zustand gehört, die Integrationswege in SAP und ihre Entsprechungen in Dynamics 365 Business Central und Infor, Zustellgarantien, das Outbox-Muster mit idempotenten Konsumenten, Fehlerbilder und Abgleich sowie Tests und Beobachtbarkeit. Die Synchronisation von Produktstammdaten ist ein eigenes Thema, beschrieben in dem Pimcore-ERP-Delta-Sync.

Was umfasst Auftragssynchronisation?

Sie umfasst jeden Beleg zwischen den beiden Systemen: den ausgehenden Auftrag und die zurückkommenden Auftragsbestätigungen, Verfügbarkeits- und Preiskorrekturen, Lieferstatus und Rechnungen. Stornos und Retouren sind keine Löschungen, sondern neue Ausgleichsbelege, die durch denselben Kreislauf laufen.

Wem gehört welcher Auftragszustand?

Der Shop besitzt den Einstieg und die Sicht des Kunden; das ERP besitzt Preise, Bestandszuteilung, Kreditprüfung, Lieferung und Fakturierung. „Synchronisiert“ bedeutet daher je Feld etwas anderes: Die Auftragsnummer des Shops gehört dem Shop und muss unverändert im ERP ankommen, der bestätigte Liefertermin gehört dem ERP, und der Shop darf ihn nur anzeigen.

Halten Sie diese Zuständigkeit pro Feld schriftlich fest, bevor Sie Code schreiben. Sie entscheidet, welche Seite bei einem Konflikt gewinnt, welche einen Wert korrigieren darf und was ein Support-Assistent ehrlich sagen kann; ein kundenseitiger Assistent kann „Wo ist meine Bestellung?“ nur beantworten, wenn dieser Kreislauf verlässlich ist, siehe KI-Support für B2B-Shops. In mehr als zehn Jahren Spryker- und Pimcore-Projekten habe ich erlebt, dass sich Probleme der Produktsynchronisation als falsche Preise auf einer Seite zeigen und Probleme der Auftragssynchronisation in der Finanzabteilung; deshalb verwendet dieser Beitrag die meiste Zeit auf Idempotenz und Abgleich.

Teilergebnisse sind im B2B der Normalfall, nicht die Ausnahme. Das ERP bestätigt vielleicht 80 von 100 Stück jetzt und den Rest nächste Woche, ersetzt einen ausgelaufenen Artikel oder passt einen Preis an, weil sich ein Vertrag geändert hat. Der Shop muss diese Änderungen so zeigen, wie sie sind; das Statusmodell braucht also Zustände auf Positionsebene, und die Bestätigungsnachricht muss Positionen aktualisieren, statt den ganzen Auftrag zu überschreiben.

Welche SAP-Integrationswege gibt es für Aufträge?

Drei Familien: die OData-API für Kundenaufträge, IDocs über ALE und BAPIs über RFC. Jede gewinnt in einem anderen Umfeld, und viele Landschaften betreiben mehr als eine.

• OData-API: Der Kundenauftragsservice API_SALES_ORDER_SRV unterstützt Anlegen, Lesen, Ändern und Löschen; ein Beitrag in der SAP Community von 2018 hält fest, dass Positionen nur per Deep Insert von Kopf und Positionen gemeinsam gebucht werden können (SAP Community); prüfen Sie das Verhalten auf Ihrem Release. Die Richtung ist OData V4: SAP listete am 15. Februar 2026 363 V4-APIs für S/4HANA on-premise (SAP Community).
• IDoc und ALE: Der klassische EDI-Weg nutzt Nachrichtentyp ORDERS, Basistyp ORDERS05, Vorgangscode ORDE und den Eingangsbaustein IDOC_INPUT_ORDERS, konfiguriert pro Partnervereinbarung des Kunden; Fehler erzeugen ein Workitem, und die Verarbeitung kann sofort oder im Hintergrund erfolgen (SAP Help). ALE unterstützt außerdem Serialisierung, damit abhängige Nachrichten in Reihenfolge gebucht werden (SAP Help).
• BAPI über RFC: BAPI_SALESORDER_CREATEFROMDAT2 legt den Auftrag aus Kopf-, Partner- und Positionstabellen an, liefert die Belegnummer in SALESDOCUMENT und Meldungen in RETURN und schreibt nicht fest; der Aufrufer muss BAPI_TRANSACTION_COMMIT ausführen (SAP Community). Ein vergessener Commit ist der klassische Vorfall „Die API sagte OK, aber nichts ist da“.

So wählt man: Läuft der Shop in der Cloud und braucht er eine Antwort im Checkout, passt die OData-API am besten. Sendet der Kunde bereits EDI-Aufträge und betreibt das SAP-Team ein IDoc-Monitoring, hält die Wiederverwendung von ORDERS05 ein einheitliches Betriebsmodell. BAPIs passen zu Middleware, die schon mit RFC-Zugang neben SAP sitzt. Was Sie auch wählen, Dedupe-Schlüssel und Abgleichsjob bleiben gleich; behandeln Sie den Transport daher als austauschbar.

Was ist mit Dynamics 365, Infor und anderen ERPs?

Die Formen sind ähnlich, und der Dedupe-Anker ist das Detail, nach dem man zuerst suchen sollte. Business Central legt Kundenaufträge mit POST /api/v2.0/companies({id})/salesOrders an und antwortet mit 201 Created; das Feld externalDocumentNumber ist der natürliche Platz für die Auftragsreferenz des Shops (Microsoft Learn). Infor stellt Kundenaufträge über das ION API Gateway mit OAuth 2.0 bereit; seine Business-Object-API blättert mit einer Standardseitengröße von 100 und maximal 20.000, und Fehlerantworten tragen ein Flag retryable (Infor).

Portabilität über ERPs hinweg wird günstiger, wenn der Shop mit einem internen Auftragsport spricht und jedes ERP einen dünnen Adapter bekommt. Der Port definiert den kanonischen Auftrag, den Dedupe-Schlüssel und das Statusvokabular; der Adapter ordnet Felder und Fehler zu. Dort kann auch ein Flag wie retryable von Infor direkt in die Retry-Regel einfließen.

Welche Zustellgarantien bekommt man tatsächlich?

Mindestens einmal, abgesichert durch Idempotenz. Kafka arbeitet standardmäßig mit mindestens einmal; seit Version 0.11.0.0 entfernt der idempotente Producer Dubletten aus seinen eigenen Wiederholungen über Producer-ID und Sequenznummern, und transaktionales Exactly-once gilt nur, wenn die ganze Pipeline in Kafka bleibt (Confluent). Ein ERP-Aufruf liegt außerhalb dieser Grenze, Exactly-once überlebt ihn also nicht.

Das prägt die Abwägung zwischen einer einfachen Retry-Schleife und einem Nachrichtenbus. Für einen Shop und ein ERP mit moderatem Volumen genügt ein synchroner API-Aufruf aus einem Worker, der eine Outbox-Tabelle liest. Ein Bus lohnt sich, wenn mehrere Konsumenten dieselben Auftragsereignisse brauchen, etwa ein Lagersystem und die Analyse, oder wenn das ERP eigene Geschäftsereignisse sendet; S/4HANA kann zum Beispiel Kundenauftragsereignisse an SAP Event Mesh veröffentlichen. In jedem Fall muss der Konsument Dubletten vertragen.

Legen Sie die Retry-Regel je Fehlerklasse fest, nicht je Aufruf. Timeouts und 5xx-Antworten bekommen eine begrenzte Zahl an Wiederholungen mit exponentiellem Backoff und Jitter; Validierungsfehler wie ein unbekannter Kunde oder ein gesperrtes Material gehen direkt an einen Menschen, denn Wiederholungen erzeugen dort nur Rauschen. Nach dem letzten Versuch geht eine Nachricht mit ihrem Fehler in einen Dead-Letter-Speicher, damit sie korrigiert und über denselben Schreiber erneut eingespielt werden kann, statt von Hand neu erfasst zu werden.

Wie greifen Outbox und Idempotenz ineinander?

Die Outbox stellt sicher, dass kein Auftrag ohne seine Nachricht gespeichert wird, und Idempotenz stellt sicher, dass eine doppelt zugestellte Nachricht keine zwei Aufträge erzeugt. Beim Transactional-Outbox-Muster werden die fachliche Änderung und die Outbox-Zeile in einer Datenbanktransaktion geschrieben, und ein Relay veröffentlicht später; das Relay kann eine Nachricht mehr als einmal veröffentlichen, also müssen Konsumenten idempotent sein, etwa indem sie verarbeitete Nachrichten-IDs festhalten (microservices.io).

-- One transaction: the order and the message that announces it
BEGIN;
INSERT INTO orders (id, customer_id, total, status)
  VALUES ('SO-2026-104233', 'C-40017', 1840.00, 'placed');
INSERT INTO outbox (id, aggregate_id, type, payload)
  VALUES (gen_random_uuid(), 'SO-2026-104233', 'OrderPlaced', '{"lines": 7}');
COMMIT;

// Idempotent consumer (sketch): the shop order id is the dedupe key all the way into the ERP
async function handleOrderPlaced(msg: OutboxMessage) {
  if (await processed.has(msg.id)) return                    // the relay may deliver twice
  await withLock(`order:${msg.aggregateId}`, async () => {    // one writer per order at a time
    const existing = await erp.findSalesOrder({ customerReference: msg.aggregateId })
    if (!existing) await erp.createSalesOrder(toErpPayload(msg)) // header and items in one call
  })
  await processed.add(msg.id)
}

Nutzen Sie die Auftrags-ID des Shops durchgehend als Schlüssel und legen Sie sie in ein Feld, das das ERP durchsuchen kann, etwa die Bestellnummer des Kunden am SAP-Kundenauftrag oder externalDocumentNumber in Business Central. Für HTTP-APIs, die Sie selbst kontrollieren, ist das Idempotenzdesign von Stripe eine gute Referenz: Der Client sendet einen Schlüssel, Wiederholungen bekommen die gespeicherte Antwort, Parameter werden mit der ursprünglichen Anfrage verglichen, und Schlüssel dürfen nach mindestens 24 Stunden gelöscht werden (Stripe). Suchen-dann-Anlegen hat eine Wettlaufsituation, deshalb hält die Skizze oben eine Sperre pro Auftrag; eine Eindeutigkeitsregel auf der Referenz im ERP, wo verfügbar, ist stärker.

Welche Fehler passieren, und wie fängt der Abgleich sie?

Doppelte Kundenaufträge, verlorene Bestätigungen, verlorene Aufträge, Teilfehler wie ein Kopf ohne Positionen, Preis- oder Einheitenabweichungen und Statusabweichungen nach einer Wiederherstellung oder einer manuellen Änderung im ERP. Der Abgleich ist die Routinearbeit, die sie findet, kein Notfallwerkzeug.

Das Engineering-Team von Mercari beschreibt drei praktische Fälle für den Zahlungsabgleich, die sich direkt auf Aufträge übertragen lassen: erfolgreich lokal, aber nicht im abhängigen System, erfolgreich im abhängigen System, aber nicht lokal, und erfolgreich in beiden mit abweichenden Details, was meist Einzelfallbearbeitung braucht (Mercari Engineering). Ich würde pro Auftrag drei Arten von Zustand halten: was der Shop will, was er als angewendet kennt, mit Zeitstempel des letzten Abgleichs, und was das ERP sagt, und den Abgleich erkennen, einordnen, festhalten und einen Reparaturbefehl einreihen lassen. Die Reparatur selbst läuft über denselben maßgeblichen Schreiber wie normale Aufträge, sodass alle Idempotenzregeln weiter gelten. Messen Sie das Alter des ältesten nicht abgeglichenen Auftrags; wächst es, ist weiter vorn etwas stehen geblieben.

Häufen sich Fehler, muss jemand IDoc-Statussätze, OData-Fehler und Dead Letter Queues lesen und entscheiden, was wiederholt wird; dabei kann ein Agent helfen, wie in einem Agenten für ERP-Integrationsfehler beschrieben. Für Aufträge, die per E-Mail statt über den Shop ankommen, gelten beim Anlageaufruf dieselben Idempotenzregeln, siehe automatisierte Auftragserfassung aus E-Mails.

Tests, Beobachtbarkeit und eine Checkliste für den Livegang

Testen Sie gegen einen ERP-Sandbox- oder QA-Mandanten mit Testbuchungskreisen und machen Sie einen hängenden Auftrag vom Commit im Shop bis zur Bestätigung im ERP nachverfolgbar. Die Messaging-Konventionen von OpenTelemetry definieren Spans für Publish, Receive, Process und Settle mit Links zwischen Producer- und Consumer-Traces, genau die Form dieses Ablaufs (OpenTelemetry).

1. Feldzuständigkeit festhalten: welches System welches Auftragsfeld und welchen Status besitzt.
2. Auftrag und Outbox-Zeile in einer Transaktion schreiben.
3. Die Auftrags-ID des Shops in ein durchsuchbares ERP-Feld tragen und darüber deduplizieren.
4. Explizit festschreiben, wo die API es verlangt, etwa mit BAPI_TRANSACTION_COMMIT.
5. Denselben Auftrag in der Sandbox zweimal senden und genau einen Kundenauftrag erwarten; ich skripte das über die echte Shop-Oberfläche mit Playwright MCP.
6. Einen geplanten Abgleich in beide Richtungen fahren und jeden Befund festhalten.
7. Jeden Auftrag über Publish, Receive und Process verfolgen und bei Queue-Alter und ältestem nicht abgeglichenem Auftrag alarmieren.
8. Mit Ausgleichsbelegen korrigieren, nie mit Löschungen.

Wenn Sie einen B2B-Shop an SAP, Business Central oder Infor anbinden und der Auftragskreislauf langweilig bleiben soll, sehen Sie sich meine B2B-E-Commerce-Arbeit an. Konfigurierte Artikel bringen eigene Regeln für die Nutzdaten mit; siehe Headless-Produktkonfiguratoren im B2B.

Quellen

1. SAP Community: posting sales orders into S/4HANA Cloud via API (2018)
2. SAP Community: S/4HANA OData V4 APIs quick reference (15 Feb 2026)
3. SAP Help: EDI inbound processing, sales order
4. SAP Help: ALE inbound processing
5. SAP Community: custom fields in sales document BAPIs (2024)
6. Microsoft Learn: Business Central API v2.0, create salesOrders
7. Infor Developer Portal: get all sales orders
8. microservices.io: transactional outbox
9. Stripe API reference: idempotent requests
10. Confluent: Kafka message delivery guarantees
11. Mercari Engineering: payment reconciliation (2021)
12. OpenTelemetry: messaging spans semantic conventions