Schnittstellen: Online-Vertriebssystem und Warenwirtschaft

14 Beschwerden, null Bestand

Yusuf scrollt durch das Ticketsystem. 14 Kundenbeschwerden seit heute früh, alle zum selben Bluetooth-Lautsprecher. Es ist Samstag, 10:15 Uhr. Die Warenwirtschaft zeigt Bestand null seit Montagabend. Trotzdem war der Artikel auf dem Marktplatz bis heute früh als lieferbar gelistet.

14 Stornierungen an einem Tag treiben die Stornoquote über die Marktplatz-Grenze von 2,5 Prozent. Wird die überschritten, droht eine Kontosperrung - dann gehen alle Angebote offline.

Beim Thema Auftragsdaten hast du gesehen, dass Bestellnummer, Artikel-SKU und Menge an verschiedene Empfängersysteme gehen. Aber welche Daten müssen zwischen Marktplatz und Warenwirtschaft synchronisiert werden, damit so ein Überverkauf nicht passiert?

Fünf Datenobjekte, die synchron laufen müssen

Zwischen Online-Vertriebssystem und Warenwirtschaft müssen fünf Datenobjekte synchronisiert werden:

1. Artikelstamm (Bezeichnung, Gewicht, EAN) - bidirektional, bei Änderung. Beide Systeme können Stammdaten pflegen.
2. Lagerbestände - vom WMS zum Marktplatz, idealerweise in Echtzeit oder minütlich. Genau hier lag Yusufs Problem.
3. Preise - vom ERP zum Marktplatz, bei Änderung. Falsche Preise erzeugen Verluste oder Kaufabbrüche.
4. Bestellungen - vom Marktplatz zum WMS, sofort nach Eingang. Jede Minute Verzögerung verschiebt den Versand.
5. Versandstatus (Tracking-Nummer, Zustellinfo) - vom WMS zurück zum Marktplatz, bei jedem Statuswechsel. Fehlt die Rückmeldung, öffnen Kund:innen Support-Tickets.

🎬 Vorstellung: Stell dir die fünf Datenobjekte als fünf Leitungen zwischen zwei Gebäuden vor - Marktplatz links, Warenwirtschaft rechts. Bei Yusuf war die Bestandsleitung fünf Tage lang unterbrochen. Welche der anderen vier Leitungen hätte bei einem Ausfall ähnlich gravierende Folgen?

Drei Wege, Daten zu synchronisieren

Die Ursache für Yusufs Problem liegt im Synchronisationsverfahren. Drei Ansätze stehen zur Wahl:

Echtzeit-Synchronisation: Jede Bestandsänderung wird sofort übermittelt. Der angezeigte Bestand stimmt fast immer. Nachteil: hohe Systemlast und teure Umsetzung.

Batch-Synchronisation: Daten werden gebündelt in festen Intervallen übertragen, z.B. alle 2 oder 24 Stunden. Technisch einfach, aber zwischen zwei Läufen kann sich der Bestand komplett ändern, ohne dass der Marktplatz es mitbekommt.

Ereignisgesteuerte Synchronisation: Aktualisierung nur bei bestimmten Auslösern - Wareneingang, Bestellung oder Bestand unter Schwellenwert. Gezielter als Batch, sparsamer als Echtzeit. Aber bei falsch konfiguriertem Trigger bleibt die Aktualisierung aus.

Fehlerszenarien und ihre Folgen

Jedes Verfahren hat typische Schwachstellen:

Echtzeit: (1) API-Timeout - der Marktplatz zeigt den letzten bekannten Bestand. (2) Race Condition - zwei Kund:innen bestellen gleichzeitig das letzte Stück, beide erhalten eine Bestätigung.

Batch: (1) Überverkauf wie bei Yusuf - zwischen zwei Läufen wird Ware verkauft, die nicht mehr da ist. (2) Verspätete Statusmeldung - Kund:innen sehen "in Bearbeitung", obwohl das Paket längst unterwegs ist.

Ereignisgesteuert: (1) Fehlender Trigger - ein manueller Warenausgang löst kein Event aus. (2) Doppeltes Event - die Bestandsmeldung wird zweimal gesendet, der Marktplatz zählt den Bestand doppelt.

Yusufs Fall war klassisches Batch-Versagen: Der letzte Abgleich lief Montagabend. Danach stockte der Job fünf Tage lang unbemerkt.

🔮 Bevor du weiterliest: Was wäre passiert, wenn Yusufs System statt Batch eine ereignisgesteuerte Synchronisation mit dem Trigger "Bestand unter 5 Stück" genutzt hätte?

REST-API, EDI oder CSV-Import

Von der Make-or-Buy-Entscheidung kennst du die Abwägung zwischen Kosten, Skalierbarkeit und Abhängigkeit. Dieselbe Logik greift bei der Schnittstellenwahl:

REST-API: Daten werden über standardisierte Web-Schnittstellen ausgetauscht. Echtzeitfähig, flexibel, gut dokumentiert. Braucht Entwicklungs-Know-how und laufende Pflege.

EDI (Electronic Data Interchange): Etablierter Standard im Großhandel. Verarbeitet hohe Datenvolumen zuverlässig, ist aber starr und teuer in der Ersteinrichtung.

CSV-Import: Tabellendateien werden exportiert und importiert - manuell oder zeitgesteuert. Günstig und schnell eingerichtet, aber fehleranfällig und nicht echtzeitfähig.

Vier Kriterien bestimmen die Wahl: Datenvolumen, Echtzeitbedarf, Kosten und Wartbarkeit.

Zurück zu Yusufs 14 Stornierungen

Yusufs Unternehmen nutzte einen CSV-Export, der einmal täglich per Batch an den Marktplatz ging. Als der Job am Montag stoppte, gab es kein Monitoring und keinen Fallback.

Die bessere Lösung: eine REST-API mit ereignisgesteuerter Synchronisation. Jede Bestandsänderung im WMS löst automatisch einen API-Call aus. Ein Monitoring-Tool überwacht die Verbindung und benachrichtigt das Team bei Ausfall - nicht erst nach fünf Tagen und 14 Beschwerden.

Bei 200 Bestellungen pro Tag und einer Stornoquote-Grenze von 2,5 Prozent ist eine Echtzeitanbindung kein Nice-to-have, sondern Voraussetzung für den Weiterbetrieb.

🤔 Frage dich: Dein Betrieb verkauft über drei Marktplätze gleichzeitig und hat 5.000 Artikel im Sortiment. Die IT-Abteilung besteht aus einer einzigen Person. Welche Schnittstellenlösung empfiehlst du - und welches der vier Kriterien wiegt für dich am schwersten?