> Aufträge zwischen B2B-Shop und ERP synchronisieren: SAP OData, IDoc und BAPI, das Outbox-Muster, Idempotenzschlüssel und routinemäßiger Abgleich. > > Web page: https://balazscsorba.com/de/blog/b2b-order-sync-erp · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/b2b-order-sync-erp.md) · [Magyar](https://balazscsorba.com/hu/blog/b2b-order-sync-erp.md) > Author: Balázs Csorba · Published: 2026-10-08 · Keywords: order sync between shop and ERP, sap sales order api, odata sales order s/4hana, idoc orders05, transactional outbox pattern, idempotency key, erp reconciliation report, sap event mesh sales order created, bapi_salesorder_createfromdat2, shop erp order integration [Blog](https://balazscsorba.com/de/blog)/Web-Engineering # Auftragssynchronisation zwischen Shop und ERP: SAP-APIs, Idempotenz und Abgleich Aufträge zwischen B2B-Shop und ERP synchronisieren: SAP OData, IDoc und BAPI, das Outbox-Muster, Idempotenzschlüssel und routinemäßiger Abgleich. [Balázs Csorba](https://balazscsorba.com/de/about)·8\. Oktober 2026·8 Min. Lesezeit - ERP integration - SAP - Idempotency - Outbox pattern - Reconciliation ![Zwei Kästen, verbunden durch einen Pfeilkreis mit Umschlag und Beleg.](https://balazscsorba.com/images/blog/b2b-order-sync-erp/cover.webp?v=189dd9c716) ## Das Wichtigste in Kürze - Auftragssynchronisation ist ein Kreislauf von Belegen: Der Shopauftrag wird zum ERP-Kundenauftrag, Bestätigungen, Lieferungen und Rechnungen fließen zurück; Stornos und Retouren sind neue Belege, keine Löschungen. - In SAP sind die Hauptwege die OData-API für Kundenaufträge, IDocs mit Nachrichtentyp ORDERS und Basistyp ORDERS05 sowie BAPI\_SALESORDER\_CREATEFROMDAT2, der ein ausdrückliches BAPI\_TRANSACTION\_COMMIT braucht. - Schreiben Sie Auftrag und Outbox-Zeile in einer Datenbanktransaktion, akzeptieren Sie, dass das Relay doppelt veröffentlichen kann, und machen Sie den ERP-Schreiber idempotent über die Auftragsreferenz des Shops. - Genau-einmal-Zustellung überlebt die ERP-Grenze selten; Kafka arbeitet standardmäßig mit mindestens einmal, also planen Sie für Dubletten, statt auf ihre Vermeidung zu hoffen. - Abgleich ist Routinearbeit: Shop- und ERP-Zustände regelmäßig vergleichen, Abweichungen einordnen und über denselben Schreiber reparieren, der normale Aufträge verarbeitet. Auf dieser Seite 1. [Was umfasst Auftragssynchronisation?](https://balazscsorba.com/#what-order-sync-covers) 2. [Wem gehört welcher Auftragszustand?](https://balazscsorba.com/#the-order-lifecycle-between-shop-and-erp) 3. [Welche SAP-Integrationswege gibt es für Aufträge?](https://balazscsorba.com/#sap-integration-options) 4. [Was ist mit Dynamics 365, Infor und anderen ERPs?](https://balazscsorba.com/#beyond-sap) 5. [Welche Zustellgarantien bekommt man tatsächlich?](https://balazscsorba.com/#delivery-guarantees-batch-event-queue) 6. [Wie greifen Outbox und Idempotenz ineinander?](https://balazscsorba.com/#idempotency-and-the-outbox) 7. [Welche Fehler passieren, und wie fängt der Abgleich sie?](https://balazscsorba.com/#failure-modes-and-reconciliation) 8. [Tests, Beobachtbarkeit und eine Checkliste für den Livegang](https://balazscsorba.com/#testing-observability-and-checklist) 9. [Quellen](https://balazscsorba.com/#sources) Diesen Artikel anhören 0:000:00 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](https://balazscsorba.com/de/blog/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. ![Belegkreislauf zwischen Shop und ERP Fünf Belege von links nach rechts: Der Shopauftrag geht vom Shop ins ERP; der ERP-Kundenauftrag ist der maßgebliche Datensatz; Auftragsbestätigung, Lieferstatus und Rechnung fließen vom ERP zurück in den Shop. Stornos und Retouren sind neue Ausgleichsbelege im selben Kreislauf, keine Löschungen.](https://balazscsorba.com/images/blog/b2b-order-sync-erp/diagram-4.webp?v=c815b9454b) Der Auftragskreislauf: Ein Beleg geht hinaus, mehrere kommen zurück, und Korrekturen sind neue Belege statt Änderungen an alten. ## 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](https://balazscsorba.com/de/blog/ai-assistant-b2b-shop-customer-support). 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](https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/posting-sales-orders-into-s-4hana-cloud-api-part-1/ba-p/13350199)); 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](https://community.sap.com/t5/financial-management-blog-posts-by-sap/sap-s-4-hana-odata-v4-apis-available-quick-reference-and-available-in-sap/ba-p/14328827)). - **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](https://help.sap.com/doc/saphelp_nw70/7.0.12/ja-JP/dc/6b7cac43d711d1893e0000e8323c4f/content.htm)). ALE unterstützt außerdem Serialisierung, damit abhängige Nachrichten in Reihenfolge gebucht werden ([SAP Help](https://help.sap.com/doc/saphelp_nw75/7.5.5/en-US/4d/51189400071c86e10000000a42189b/content.htm)). - **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](https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/how-to-use-custom-fields-in-sales-document-bapis/ba-p/13721645)). 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. Weg Latenz Kopplung Zustellsemantik Typischer Einsatz OData-API (V2 oder V4) synchron, Sekunden direkter HTTP-Aufruf Aufrufer wiederholt; Dedupe über natürlichen Schlüssel Webshops, Cloud-ERP IDoc über ALE gepuffert, Minuten asynchron, Partnervereinbarungen Statussätze, Nachverarbeitung EDI, hohes Volumen, on-premise BAPI über RFC synchron, Sekunden eng, braucht RFC-Verbindung expliziter Commit; Aufrufer wiederholt Middleware nahe an SAP Batch-Datei geplant, Stunden lose Wiederholungsläufe, Dedupe pro Datei geringes Volumen, Altsysteme ## 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](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/api/dynamics_salesorder_create)). 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](https://developer.infor.com/business-obj-v1/sales-order/get-all-sales-orders)). 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](https://docs.confluent.io/kafka/design/delivery-semantics.html)). 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](https://microservices.io/patterns/data/transactional-outbox.html)). ![Outbox, idempotenter Schreiber und Abgleich Die Shop-Datenbank schreibt Auftrag und Outbox-Zeile in einer Transaktion. Ein Relay veröffentlicht die Nachricht und kann sie doppelt veröffentlichen. Der ERP-Schreiber legt den Kundenauftrag mit Idempotenzschlüssel an, und das ERP dedupliziert über die Auftragsreferenz des Shops. Ein Abgleich vergleicht regelmäßig Shop- und ERP-Zustände und schickt Reparaturbefehle über denselben ERP-Schreiber zurück.](https://balazscsorba.com/images/blog/b2b-order-sync-erp/diagram-23.webp?v=57e9898c6e) Outbox plus idempotenter Schreiber plus Abgleich: Dubletten werden erwartet und abgefangen, und Reparaturen nutzen denselben Schreibweg wie normale Aufträge. ``` -- 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](https://docs.stripe.com/api/idempotent_requests)). 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. **Nie zum Korrigieren löschen** Ist ein Auftrag schiefgelaufen, löschen Sie ihn in keinem System, um „neu zu synchronisieren“. Stornieren Sie ihn mit einem Ausgleichsbeleg und legen Sie über denselben Schreiber einen neuen an. Löschungen zerstören den Audit-Trail, verwirren den Abgleich und können im ERP mit Lieferungen oder Rechnungen kollidieren, die schon auf den Auftrag verweisen. ## 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](https://engineering.mercari.com/en/blog/entry/20211222-1df9e3a553/)). 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](https://balazscsorba.com/de/blog/erp-integration-error-agent) 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](https://balazscsorba.com/de/blog/b2b-email-order-entry-llm). ## 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](https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/)). 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](https://balazscsorba.com/de/expertise/b2b-ecommerce-developer) an. Konfigurierte Artikel bringen eigene Regeln für die Nutzdaten mit; siehe [Headless-Produktkonfiguratoren im B2B](https://balazscsorba.com/de/blog/headless-product-configurator-b2b). ## Quellen 1. [SAP Community: posting sales orders into S/4HANA Cloud via API (2018)](https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/posting-sales-orders-into-s-4hana-cloud-api-part-1/ba-p/13350199) 2. [SAP Community: S/4HANA OData V4 APIs quick reference (15 Feb 2026)](https://community.sap.com/t5/financial-management-blog-posts-by-sap/sap-s-4-hana-odata-v4-apis-available-quick-reference-and-available-in-sap/ba-p/14328827) 3. [SAP Help: EDI inbound processing, sales order](https://help.sap.com/doc/saphelp_nw70/7.0.12/ja-JP/dc/6b7cac43d711d1893e0000e8323c4f/content.htm) 4. [SAP Help: ALE inbound processing](https://help.sap.com/doc/saphelp_nw75/7.5.5/en-US/4d/51189400071c86e10000000a42189b/content.htm) 5. [SAP Community: custom fields in sales document BAPIs (2024)](https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/how-to-use-custom-fields-in-sales-document-bapis/ba-p/13721645) 6. [Microsoft Learn: Business Central API v2.0, create salesOrders](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/api/dynamics_salesorder_create) 7. [Infor Developer Portal: get all sales orders](https://developer.infor.com/business-obj-v1/sales-order/get-all-sales-orders) 8. [microservices.io: transactional outbox](https://microservices.io/patterns/data/transactional-outbox.html) 9. [Stripe API reference: idempotent requests](https://docs.stripe.com/api/idempotent_requests) 10. [Confluent: Kafka message delivery guarantees](https://docs.confluent.io/kafka/design/delivery-semantics.html) 11. [Mercari Engineering: payment reconciliation (2021)](https://engineering.mercari.com/en/blog/entry/20211222-1df9e3a553/) 12. [OpenTelemetry: messaging spans semantic conventions](https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/) ## Häufige Fragen Wie synchronisiert man Aufträge zwischen Webshop und SAP? Übliche Wege sind die OData-API für Kundenaufträge, eingehende IDocs mit Nachrichtentyp ORDERS und Basistyp ORDERS05 oder der BAPI BAPI\_SALESORDER\_CREATEFROMDAT2 über RFC. Wählen Sie nach Kopplung und Latenz, und ergänzen Sie eine Outbox im Shop, einen idempotenten Schreiber mit der Auftragsreferenz des Shops als Schlüssel und einen regelmäßigen Abgleich. Wie verhindert man doppelte Kundenaufträge im ERP? Tragen Sie die Auftragsreferenz des Shops in ein Feld, das das ERP prüfen kann, etwa die Bestellnummer des Kunden am SAP-Kundenauftrag oder externalDocumentNumber in Business Central, prüfen Sie es vor dem Anlegen und führen Sie im Konsumenten eine Tabelle verarbeiteter Nachrichten. Wiederholungen finden dann den bestehenden Auftrag, statt einen zweiten anzulegen. Was ist das Transactional-Outbox-Muster? Der Shop schreibt Auftrag und eine Nachrichtenzeile in derselben Transaktion in seine eigene Datenbank. Ein separates Relay veröffentlicht die Nachricht später und kann sie mehr als einmal veröffentlichen; der Konsument muss daher idempotent sein. Das Muster schließt die Lücke, in der ein Auftrag gespeichert, seine Nachricht aber verloren ist, oder umgekehrt. Ist Genau-einmal-Zustellung zwischen Shop und ERP möglich? In der Praxis nicht. Kafkas transaktionales Exactly-once gilt nur, wenn die ganze Pipeline in Kafka bleibt, und ein ERP-Aufruf liegt außerhalb. Planen Sie für mindestens einmalige Zustellung mit idempotenten Konsumenten und natürlichen Schlüsseln im ERP und gleichen Sie ab, um zu finden, was trotzdem durchrutscht. Was sollte ein Abgleichsjob für Aufträge prüfen? Aufträge, die im Shop, aber nicht im ERP existieren, Aufträge im ERP, die der Shop nicht kennt, und Aufträge in beiden Systemen mit abweichenden Details wie Mengen, Preisen oder Status. Halten Sie jeden Befund fest, reihen Sie einen Reparaturbefehl ein und führen Sie die Reparatur über denselben maßgeblichen Schreiber aus wie normale Aufträge. Geschrieben von Balázs Csorba Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten. [B2B-E-Commerce & PIM →](https://balazscsorba.com/de/expertise/b2b-ecommerce-developer)[Über mich →](https://balazscsorba.com/de/about) ## Weitere Artikel - [Schema.org-Strukturdaten für B2B-Shops: Preise hinter Logins, Einheiten und Varianten](https://balazscsorba.com/de/blog/schema-org-structured-data-b2b-shop) - [Ein KI-Assistent für den Support im B2B-Shop: Tools, Berechtigungen und die Übergabe an Menschen](https://balazscsorba.com/de/blog/ai-assistant-b2b-shop-customer-support) - [Streaming-Chat mit KI in Vue und Nuxt: von Anfang an barrierefrei](https://balazscsorba.com/de/blog/vue-ai-chat-ui-streaming-accessibility) - [Eine LLM-Übersetzungspipeline für i18n: Glossar, Platzhalter und Review](https://balazscsorba.com/de/blog/llm-translation-pipeline-i18n) ## Klingt nach dem, was du suchst? Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören. [Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)