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 Zuständigkeit

Wenn die Zahlen auseinanderlaufen, untersucht jeder das Synchronisationsskript. Aber das Skript tut meist genau das, wofür es programmiert wurde; 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 abgeschlossen wird. Beide haben nach ihren eigenen Regeln recht, und der Sync-Job vermittelt zwischen beiden ohne definierte Vorrangregel.

Die Lösung ist ein Prinzip: für jede Information genau ein führendes System (System of Record). Die verbindliche Bestandszahl 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 zwischengespeicherte Kopie für die Anzeige und eine Reservierung. Sobald das festgelegt ist, hat jede Sync-Frage eine Antwort: Im Zweifel gewinnt das führende System.

Die wiederkehrenden Fehlerbilder

Ist die Zuständigkeit geklärt, sind die verbleibenden Bugs mechanisch, und sie wiederholen sich über Plattformen und ERPs hinweg:

• 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 wird zweimal ausgelöst (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 greifen auf dieselben Zeilen zu; wer zuletzt fertig wird, gewinnt, und das ist manchmal der veraltete Stand.
• Mapping-Drift. Eine im ERP umbenannte SKU wird im Shop unbemerkt 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 Tabellenkalkulation, sollten Sie davon ausgehen, dass sie veraltet ist.

Die Muster, die den Konflikt beenden

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

1. Deltas und Abgleich. Eventgetriebene Updates für die Geschwindigkeit, dazu ein periodischer Vollabgleich, der findet, was die Events verpasst haben. Erst der Abgleich macht den schnellen Pfad vertrauenswürdig.
2. Idempotente Consumer. Jedes Update trägt einen Identifier, anhand dessen 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 Schreibvorgang keinen neueren überschreiben kann.
3. Durchgängige Correlation-IDs. Wenn Bestellung 18342 nie im Lager ankam, sollten die Logs in ein, zwei Minuten zeigen, wo sie geblieben ist.
4. Alarm bei Divergenz. Ein Sync, der Erfolg meldet, während die Zahlen auseinanderdriften, ist schlimmer als einer, der offen fehlschlägt. Vergleichen Sie Aggregate nach Zeitplan und benachrichtigen 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 Legen in den Warenkorb. So oder so kehrt alles irgendwann zum führenden System zurück. Overselling während Kampagnen geht meist auf Reservierungen zurück, die nie ablaufen oder nie existiert haben.

Nichts davon hängt vom Hersteller ab. Wir haben dieselbe Architektur für NetSuite, Business Central und Odoo umgesetzt, ebenso für tschechische und slowakische Systeme wie Pohoda und Money S5, die internationale Konnektor-Anbieter gern übersehen; dieser Long Tail ist einer der Hauptgründe, warum es unsere Integrationsarbeit gibt.

Wenn Ihr Shop und Ihr ERP beim Bestand gerade auseinanderlaufen, beginnen Sie damit, klar festzulegen, welches System zuständig ist. Das zu klären ist Teil des Systemdesigns; danach ist der Aufbau der Synchronisation Routinearbeit. Wenn Sie dabei Hilfe möchten, melden Sie sich bei uns.