Ein Händler schaltet nach zwei Jahren reinem Shopbetrieb Amazon dazu. Sortiment rund 9.000 Varianten, ein Lager, saubere Bestände. Nach drei Wochen kommen die ersten Stornos vor Versand: verkauft, aber nicht mehr da. Der Verdacht fällt sofort auf die Bestandsführung im Lager, weil der Bestand ja stimmt, wenn man nachschaut.
Er stimmt auch. Nur zu spät.
Der Bestand, den der Marktplatz sieht, ist immer alt
PlentyONE kennt mehrere Bestandsgrößen, und die Wahl dazwischen entscheidet, wie viel Luft im System ist. Der physische Bestand ist das, was im Regal liegt. Der reservierte Bestand ist das, was bereits in offenen Aufträgen hängt. Der Netto-Warenbestand ist die Differenz, und das ist in der Regel die Größe, die an die Kanäle geht. Daneben gibt es den bestellten Bestand, also Ware, die beim Lieferanten beauftragt, aber noch nicht eingetroffen ist. Wer den mitexportiert, verkauft Termine statt Ware. Das kann man machen, wenn Lieferzeiten und Kundenkommunikation dazu passen. Bei Amazon Seller Fulfilled mit engen Versandversprechen macht man es besser nicht.
Das eigentliche Loch sitzt woanders. Die Reservierung entsteht erst, wenn der Auftrag in PlentyONE angelegt ist. Zwischen dem Klick des Käufers auf dem Marktplatz und dem Auftragsimport vergehen je nach Kanal und Konfiguration einige Minuten. In diesen Minuten ist die Ware verkauft, aber der Netto-Warenbestand kennt sie noch nicht. Dann geht der unveränderte Bestand an alle anderen Kanäle raus, und der zweite Käufer bekommt dieselbe letzte Einheit.
Deshalb sind Überverkäufe fast immer ein Problem der letzten ein bis drei Stück, nicht der Bestandsführung. Bei einem Artikel mit 40 auf Lager interessiert die Latenz niemanden. Beim Sprung von 2 auf 0 entscheidet sie alles.
Sicherheitsbestand und Kanalpuffer sind zwei verschiedene Werkzeuge
Der Sicherheitsbestand hängt am Artikel beziehungsweise an der Lagerzuordnung. Er reduziert den verfügbaren Bestand für alle Kanäle gleichzeitig. Sinnvoll ist er für systematische Abweichungen: Artikel, bei denen die Inventur regelmäßig weniger findet als das System behauptet, Kleinteile ohne Einzelzählung, Ware mit Bruchquote.
Der Puffer je Auftragsherkunft ist etwas anderes. Er wird in den Bestandseinstellungen pro Kanal hinterlegt und zieht nur für diesen einen Kanal etwas vom exportierten Wert ab. Damit deckst du Latenz und Absatzgeschwindigkeit ab, und die sind je Kanal verschieden. Ein eBay-Angebot mit drei Verkäufen im Monat braucht keinen Puffer. Ein Amazon-Angebot, das an guten Tagen 30 Stück bewegt, braucht einen.
Die Rechnung ist unspektakulär. Nimm die Absatzspitze pro Stunde und multipliziere sie mit der Zeit, die zwischen Kauf und wirksamer Bestandsänderung auf allen Kanälen vergeht. 30 Stück am Tag verteilen sich nicht gleichmäßig; rechne mit dem Dreifachen des Stundenschnitts, also grob 4 Stück pro Stunde. Bei einer realistischen Gesamtlatenz von zehn Minuten sind das 0,7 Stück. Puffer 1 reicht. Bei einem Artikel, der während einer Kampagne 200 Stück am Tag macht, sieht die Rechnung anders aus, und zwar nur an diesen zwei Tagen.
Was wir dabei regelmäßig sehen: Puffer werden einmal gesetzt, meist pauschal auf 2 oder 3 für das ganze Sortiment, und dann nie wieder angefasst. Bei einem C-Artikel mit Bestand 4 bedeutet Puffer 3, dass ein Stück verkäuflich ist. Über ein paar tausend Varianten summiert sich das zu Ware, die im Regal liegt und in keinem Angebot auftaucht.
Wann Marktplätze eine Änderung tatsächlich übernehmen
PlentyONE schickt Bestandsänderungen ereignisgesteuert an die angebundenen Kanäle, dazu läuft ein vollständiger Abgleich in der Nacht. Der Versand aus dem System heraus ist selten das Problem. Das Warten beginnt danach.
Amazon nimmt Bestandsdaten als Feed entgegen und stellt sie in eine Warteschlange. Zu ruhigen Zeiten ist eine Mengenänderung nach wenigen Minuten im Angebot sichtbar. In den Wochen vor Weihnachten und an Aktionstagen dauert dieselbe Übertragung deutlich länger, weil die Queue voll ist, und du bekommst das nicht angezeigt. Die Feed-Verarbeitung meldet Erfolg, sobald sie verarbeitet hat, nicht wenn das Angebot aktualisiert ist. Bei eBay geht es über die Inventory-Schnittstelle in der Regel schneller, aber die Anzeige in Suchergebnissen und Cache-Seiten hinkt der API hinterher. Otto und Kaufland liegen dazwischen und verhalten sich je nach Anbindungsart unterschiedlich.
Praktische Konsequenz: Ein Kanal, der nachts um 3 Uhr im Vollabgleich korrigiert wird, ist tagsüber trotzdem auf die Einzelmeldungen angewiesen. Und wenn ein Kanal deutlich träger ist als die anderen, gehört dorthin der größere Puffer, nicht überall derselbe.
Der häufigste Auslöser ist ein stehender Auftragsimport
Wenn wir Systeme mit auffälligen Stornoquoten übernehmen, liegt die Ursache selten beim Export. Sie liegt beim Import. Ein abgelaufenes Token, ein Kanal, dessen Verbindung nach einem Passwortwechsel nicht mehr trägt, ein Prozess, der seit Freitagabend nicht mehr durchgelaufen ist. Solange keine Aufträge ankommen, entstehen keine Reservierungen. Der Netto-Warenbestand bleibt konstant hoch, wird brav an alle Kanäle gemeldet, und über ein Wochenende verkauft sich derselbe Bestand mehrfach. Das ist keine Pufferfrage. Da hilft nur, dass jemand merkt, dass seit 18 Stunden kein Auftrag mehr importiert wurde.
Eine simple Überwachung auf „Anzahl importierter Aufträge je Kanal in den letzten zwei Stunden gleich null" fängt mehr Überverkäufe ab als jede Pufferoptimierung. Sie muss allerdings in einem Postfach landen, in das jemand schaut, und nicht in der Sammeladresse für Systemmeldungen.
Kontingente statt Puffer, wenn ein Kanal den anderen leerräumt
Es gibt Fälle, in denen Puffer nicht das richtige Mittel sind. Wenn ein Marktplatz regelmäßig die komplette Verfügbarkeit eines Artikels in wenigen Stunden abräumt und der eigene Shop dann leer dasteht, ist das kein Latenzproblem, sondern eine Verteilungsfrage. Dafür arbeitest du besser mit einer Bestandsbegrenzung je Kanal oder mit getrennten Lagerorten, denen du Mengen fest zuweist. Der Preis dafür ist Verschnitt: Ware, die einem Kanal zugeteilt ist und dort nicht verkauft wird, fehlt dem anderen. Bei Aktionsware und bei Artikeln mit langer Wiederbeschaffungszeit ist das trotzdem der ruhigere Weg.
Bei Stücklisten und Sets wird die Sache unübersichtlich, weil sich der verfügbare Bestand aus mehreren Komponenten ableitet und Puffer dann auf der falschen Ebene sitzen. Und wer parallel FBA fährt, hat ohnehin zwei Bestandswelten, die sich nur bedingt gegenseitig informieren. Beides ist lösbar, aber nicht mit denselben Einstellungen wie oben.
Womit du anfangen würdest
Zieh dir die Aufträge der letzten drei Monate, die vor Versand storniert wurden, und schau nach, welche Artikel darin mehrfach vorkommen. In fast allen Fällen ist das eine überschaubare Liste von Schnelldrehern mit knappem Bestand. Für die lohnt sich ein individueller Puffer; für den Rest des Sortiments reicht meist 0 oder 1. Amazon zieht die Grenze bei einer Stornoquote von 2,5 Prozent vor Versand, und wer da regelmäßig dranstößt, hat ein Ranking-Problem, bevor er ein Lagerproblem hat.
Danach die Zeitachse: Notiere bei einem Testartikel, wie lange es dauert, bis eine Bestandsänderung in PlentyONE auf jedem Kanal sichtbar ist. Einmal an einem Dienstagvormittag, einmal an einem Aktionstag. Die Differenz zwischen beiden Messungen ist die Zahl, nach der du deine Puffer für die Saison bemisst.
KI-generierter Inhalt.