Warum ERP und Shop beim Bestand auseinanderlaufen

Früher oder später erreicht jeden Shop mit ERP-Anbindung dasselbe Ticket: Die Storefront meldet fünf auf Lager, das Lager meldet null, und ein Kunde hat gerade einen Artikel bezahlt, der nicht verfügbar ist. Der Support wertet es als einmaligen Fehler, doch es geht auf eine Architekturentscheidung zurück, an die sich niemand mehr erinnert.

Die eigentliche Ursache: ungeklärte Ownership

Wenn die Zahlen auseinanderlaufen, debuggt jeder das Synchronisationsskript. Aber das Skript tut meist genau das, was man ihm gesagt hat; das Problem ist, dass zwei Systeme beide glauben, die Bestandszahl gehöre ihnen. Das ERP bucht ab, wenn es einen Auftrag erfasst. Der Shop bucht ab, wenn der Checkout abschließt. Beide haben nach ihren eigenen Regeln recht, und der Sync-Job vermittelt zwischen beiden ohne definierte Vorrangregel.

Der Fix ist ein Prinzip: ein System of Record pro Fakt. Die Bestandswahrheit liegt an genau einer Stelle, fast immer im ERP oder im WMS, denn dort wird der Bestand gebucht und dort bewegt sich die Ware physisch. Der Shop hält lediglich eine gecachte Kopie für die Anzeige und eine Reservierung. Ist das einmal explizit, hat jede Sync-Frage eine Antwort: Im Zweifel gewinnt das System of Record.

Die Fehlerbilder, die wir immer wieder finden

Ist die Ownership geklärt, sind die verbleibenden Bugs mechanisch, und sie wiederholen sich quer über Plattformen und ERPs:

• Verlorene Updates. Das ERP schickt eine Bestandsänderung, der Shop steckt mitten im Deployment oder drosselt den Aufruf, und niemand wiederholt ihn. Wochen später fragt jemand, warum eine SKU den ganzen Monat „ausverkauft“ war.
• Doppelte Zustellungen. Derselbe Webhook feuert zweimal (die Zustellung ist typischerweise at-least-once, dasselbe Event kann also mehrfach ankommen), und der Handler bucht den Bestand zweimal ab.
• Vollabgleiche im Wettlauf mit Deltas. Ein nächtlicher Komplettimport und eventgetriebene Updates laufen gegen dieselben Zeilen; wer zuletzt fertig wird, gewinnt, und das ist manchmal der veraltete Stand.
• Mapping-Drift. Eine im ERP umbenannte SKU wird im Shop still zu einem neuen Produkt; das alte behält seinen veralteten Bestand für immer.
• Bundles und Sets. Der Shop verkauft ein Set; das ERP zählt Komponenten. Steht die Umrechnung nur in einer Excel-Tabelle, ist sie in der Praxis nie aktuell.

Die Muster, die den Konflikt beenden

Die Integrationsschicht, die diese Tickets nicht mehr produziert, sieht unabhängig vom dahinterliegenden ERP gleich aus:

1. Deltas plus Reconciliation. Eventgetriebene Updates für die Geschwindigkeit, dazu ein periodischer Vollabgleich, der findet, was die Events verpasst haben. Die Reconciliation ist das Sicherheitsnetz, das den schnellen Pfad erst vertrauenswürdig macht.
2. Idempotente Consumer. Jedes Update trägt einen Identifier, auf dem der Consumer dedupliziert; es zweimal zu verarbeiten ändert nichts. Das fängt Retries und Replays ab. Concurrency-Konflikte sind ein eigenes Problem: Verlorene Updates und Vollabgleiche im Wettlauf mit Deltas brauchen Versionsstempel oder Sequenznummern, damit ein veralteter Write keinen neueren überschreiben kann.
3. Correlation-IDs von Ende zu Ende. Wenn Bestellung 18342 nie im Lager ankam, sollte eine einzige Log-Abfrage zeigen, wo sie hängen geblieben ist.
4. Alarm bei Divergenz, nicht nur bei Ausfall. Ein Sync, der grün läuft, während die Zahlen auseinanderdriften, ist schlimmer als einer, der abstürzt. Vergleichen Sie Aggregate nach Zeitplan und alarmieren Sie jemanden, wenn das Delta wächst.
5. Reservierungen mit Ablaufdatum. Wenn Ihr Setup Bestand früh reserviert, hält ein Warenkorb ihn für Minuten und eine unbezahlte Bestellung länger; standardmäßig entsteht die Reservierung aber erst bei der Auftragsanlage, nicht beim Add-to-Cart. So oder so fällt alles irgendwann an das System of Record zurück. Overselling während Kampagnen geht meist auf Reservierungen zurück, die nie ablaufen oder nie existiert haben.

Nichts davon hängt am Hersteller. Wir haben dieselbe Struktur gegen Business Central und SAP Business One gebaut, gegen NetSuite und Odoo, und auch gegen tschechische und slowakische Systeme wie Pohoda und Money S5, die internationale Konnektor-Anbieter gern übersehen; dieser Long Tail ist der halbe Grund, warum es unsere Integrationsarbeit gibt.

Wenn Ihr Shop und Ihr ERP diesen Streit gerade führen, beginnen Sie damit, die Ownership-Frage explizit zu machen. Wenn Sie dabei Hilfe möchten, melden Sie sich bei uns. Die Ownership-Frage zu klären ist Teil des System Designs; danach ist der Aufbau der Synchronisation Routinearbeit.