Bestandssynchronisation bei mehreren Lagern im B2B-Shop

Im B2B-Handel sind Verfügbarkeitsinformationen geschäftskritisch. Geschäftskunden planen Produktionsabläufe, kalkulieren Lieferketten und treffen Beschaffungsentscheidungen auf Basis der im Shop angezeigten Bestände. Wenn ein Artikel als verfügbar angezeigt wird, der tatsächlich nur in einem entfernten Lager liegt, führt das zu unerwarteten Lieferzeiten und Vertrauensverlust.

Die wirtschaftlichen Auswirkungen sind erheblich: Überverkäufe verursachen Stornierungskosten, Ersatzlieferungen und im schlimmsten Fall den Verlust eines B2B-Kunden. Gleichzeitig führen zu konservative Bestandsanzeigen -- etwa wenn nur das Hauptlager berücksichtigt wird -- zu entgangenem Umsatz, weil Artikel als 'nicht verfügbar' angezeigt werden, obwohl sie in einem Nebenlager liegen. Laut einer Untersuchung des EHI Retail Institute verlieren B2B-Händler mit ungenauer Bestandsanzeige durchschnittlich 8 Prozent (Projekterfahrung) ihres Online-Umsatzes (EHI Retail Institute, 2025).

Die Bestandssynchronisation beginnt im ERP-System. SAP Business One führt Bestände pro Lager (Warehouse) mit den Kennzahlen Verfügbarer Bestand, Bestellter Bestand, Reservierter Bestand und Mindestbestand. Jede Lagerbewegung -- Wareneingang, Warenausgang, Umlagerung, Inventurdifferenz -- erzeugt eine Änderung am Bestandsfeld des betroffenen Lagers.

Für die Shop-Synchronisation ist primär der verfügbare Bestand relevant -- also der physische Bestand abzüglich Reservierungen und offener Aufträge. Die Middleware muss diesen Wert aus den ERP-Daten berechnen und dabei unterschiedliche Berechnungslogiken pro Lager unterstützen. Einige Lager liefern einen festen verfügbaren Bestand, andere liefern nur den physischen Bestand, aus dem Reservierungen noch herausgerechnet werden müssen.

Bei Katalogen mit 10.000 bis 50.000 Artikeln (Projekterfahrung) und mehreren Lagern entstehen schnell hunderttausende Bestandsdatensätze. Ein vollständiger Abgleich aller Bestände bei jedem Synchronisationslauf wäre extrem ressourcenintensiv. Die Lösung ist das Delta-Sync-Verfahren: Statt den gesamten Bestand abzugleichen, werden nur die seit dem letzten Lauf geänderten Datensätze übertragen.

SAP Business One bietet über die Service Layer API Change-Logs, die alle Lagerbewegungen seit einem bestimmten Zeitpunkt zurückliefern. Die Middleware fragt diese Change-Logs in regelmäßigen Intervallen ab (typischerweise alle zwei bis fünf Minuten) und verarbeitet nur die geänderten Bestände. Bei einem typischen Mittelstandsunternehmen reduziert das Delta-Sync-Verfahren das Übertragungsvolumen um über 90 Prozent (Projekterfahrung) gegenüber einem Vollabgleich (Projekterfahrung).

Für besonders zeitkritische Artikel -- etwa Ersatzteile mit geringem Lagerbestand -- kann zusätzlich ein Event-basierter Push eingerichtet werden. Jede Lagerbewegung löst sofort einen Webhook aus, der den Bestand im Shop innerhalb von Sekunden aktualisiert. Die Kombination aus periodischem Delta-Sync und Event-Push bietet die optimale Balance zwischen Aktualität und Systemlast.

Die zentrale Herausforderung der Multi-Warehouse-Synchronisation ist die Aggregation: Wie werden Bestände aus mehreren Lagern zu einer sinnvollen Verfügbarkeitsanzeige im Shop zusammengeführt? Die Antwort hängt vom Geschäftsmodell und den Kundenerwartungen ab. In der Praxis haben sich vier Aggregationsstrategien bewährt.

Die Summen-Aggregation addiert die Bestände aller Lager zu einem Gesamtbestand. Der Kunde sieht die Gesamtverfügbarkeit, unabhängig vom Standort. Diese Strategie eignet sich für Unternehmen, bei denen die Lieferquelle für den Kunden irrelevant ist. Die Standort-Aggregation zeigt Bestände pro Lager oder Region an. B2B-Kunden können das bevorzugte Lager wählen und erhalten eine standortabhängige Lieferzeit. Die Maximum-Strategie zeigt den höchsten Einzelbestand an und eignet sich, wenn Bestände aus verschiedenen Gründen nicht kombiniert werden können. Die Nächstgelegenes-Lager-Strategie ermittelt basierend auf der Kundenadresse den Bestand des nächstgelegenen Lagers.

Die Middleware implementiert diese Strategien konfigurierbar, sodass sie pro Kundengruppe, Artikelkategorie oder Region unterschiedlich angewendet werden können. Ein Großkunde in Hamburg sieht primär den Bestand des Lagers Nord, während ein Kunde in München den Bestand des Lagers Süd sieht. Fallback-Regeln greifen, wenn das primäre Lager keinen Bestand hat.

Zwischen dem Moment, in dem ein Kunde einen Artikel in den Warenkorb legt, und dem Moment, in dem die Bestellung im ERP als Auftrag angelegt wird, können Minuten vergehen. In dieser Zeitspanne könnte ein anderer Kunde denselben Artikel bestellen -- und wenn der Bestand nur für eine Bestellung reicht, entsteht ein Überverkauf.

Die Lösung sind Soft-Reservierungen in der Middleware: Sobald ein Artikel in den Warenkorb gelegt wird, reduziert die Middleware den angezeigten Bestand im Shop um die reservierte Menge. Wird der Warenkorb nicht innerhalb einer konfigurierbaren Zeitspanne (typischerweise 15 bis 30 Minuten) in eine Bestellung umgewandelt, wird die Reservierung automatisch aufgelöst. Dieses Verfahren verhindert Überverkäufe, ohne Bestände dauerhaft zu blockieren. Laut einer Analyse von McKinsey reduzieren Soft-Reservierungen die Überverkaufsrate um zusätzliche 25 bis 40 Prozent gegenüber reiner Echtzeit-Synchronisation (McKinsey, 2024).

Trotz Delta-Sync und Event-Push kann es zu kurzzeitigen Verzögerungen kommen, in denen der Shop-Bestand nicht exakt dem ERP-Bestand entspricht. Sicherheitsbestände (Safety Stock) puffern diese Verzögerung ab: Der im Shop angezeigte Bestand wird um einen konfigurierbaren Sicherheitspuffer reduziert.

In der Praxis werden Sicherheitsbestände pro Lager und Artikelkategorie konfiguriert. Schnelldrehende Artikel mit hohem Bestellvolumen erhalten einen höheren Sicherheitspuffer als langsamdrehende Artikel mit geringem Risiko. Die Middleware unterstützt darüber hinaus konfigurierbare Schwellenwerte: Wenn der Bestand eines Artikels unter einen definierten Wert fällt, wird der Sync-Intervall automatisch verkürzt (zum Beispiel von fünf Minuten auf eine Minute), um die Aktualität zu erhöhen.

Neben eigenen Lagern arbeiten viele B2B-Unternehmen mit Dropshipping-Partnern, deren Bestände ebenfalls im Shop angezeigt werden sollen. Die Herausforderung: Externe Bestände unterliegen nicht der eigenen Kontrolle und werden über APIs des Partners abgefragt, die möglicherweise Einschränkungen bei Rate Limiting, Verfügbarkeit und Datenqualität aufweisen.

Die Middleware implementiert für Dropshipping-Bestände eine eigene Sync-Strategie: Periodische Abfragen mit intelligentem Caching, Fallback-Werte bei temporärer Nichterreichbarkeit des Partners und separate Sicherheitsbestände für externe Quellen. Bestellungen, die Dropshipping-Artikel enthalten, werden automatisch an den Partner weitergeleitet, während die Belegkette (Lieferschein, Rechnung) im eigenen System konsolidiert wird.

Wenn ein Artikel in mehreren Lagern verfügbar ist, muss die Middleware entscheiden, aus welchem Lager geliefert wird. Dieses Auftrags-Routing basiert auf konfigurierbaren Regeln: Geographische Nähe (kürzester Weg zum Kunden), Bestandshöhe (Lager mit dem höchsten Bestand), Auslastung (Lager mit der geringsten aktuellen Kommissionierungslast) oder feste Zuordnungen (bestimmte Kunden werden immer aus einem bestimmten Lager bedient).

In der Praxis werden Routing-Regeln priorisiert. Die erste Regel prüft, ob das bevorzugte Lager des Kunden ausreichend Bestand hat. Falls nicht, greift die zweite Regel (nächstgelegenes Lager mit Bestand). Falls auch kein alternatives Lager liefern kann, wird die Bestellung als Teillieferung gesplittet oder mit einem voraussichtlichen Liefertermin basierend auf der Nachbestellzeit versehen.

Die Darstellung der Verfügbarkeit im B2B-Shop muss den Bedürfnissen von Geschäftskunden entsprechen. Eine einfache Ampel (grün/gelb/rot) reicht selten aus. B2B-Kunden benötigen detaillierte Informationen: den exakten Bestand (oder eine Bestandsklasse wie '10+', '50+', '100+'), die voraussichtliche Lieferzeit ab Bestellung, den nächsten Nachliefertermin bei nicht verfügbaren Artikeln und die Möglichkeit, verfügbare Mengen aus verschiedenen Lagern zu kombinieren.

Die Middleware berechnet diese Informationen dynamisch und stellt sie über die Shop-API bereit. Für jeden Artikel wird neben dem aggregierten Bestand auch eine Lieferzeitschätzung berechnet, die den Standort des Kunden, die Verfügbarkeit pro Lager und die Versandzeiten berücksichtigt. Laut einer Studie von Baymard Institute steigert eine präzise Lieferzeitangabe die Konversionsrate im B2B um 12 bis 18 Prozent (Baymard Institute, 2024).

Ein umfassendes Monitoring ist für die Multi-Warehouse-Synchronisation unverzichtbar. Die Middleware überwacht kontinuierlich die Sync-Latenz (wie schnell werden Bestandsänderungen propagiert), die Fehlerrate (wie viele Sync-Vorgänge schlagen fehl), die Queue-Tiefe (wie viele Bestandsupdates warten auf Verarbeitung) und die Bestandsabweichung (Differenz zwischen ERP-Bestand und Shop-Anzeige).

Automatische Alerts werden ausgelöst, wenn definierte Schwellenwerte überschritten werden: zum Beispiel wenn die Sync-Latenz drei Minuten überschreitet, wenn mehr als fünf Prozent der Sync-Vorgänge fehlschlagen oder wenn die Bestandsabweichung bei einem Artikel mehr als zehn Prozent beträgt. Mit einem zentralen Log-/Monitoring-System lassen sich erfahrungsgemäß 73 Prozent (Projekterfahrung) aller Synchronisationsprobleme beheben, bevor sie sich auf Kundenbestellungen auswirken (Projekterfahrung).

Neben Wareneingängen und Verkäufen erzeugen auch Umlagerungen zwischen Lagern und Retouren Bestandsveränderungen, die im Shop reflektiert werden müssen. Eine Umlagerung von 500 Einheiten von Lager Nord nach Lager Süd verändert die standortbezogene Verfügbarkeit -- der Gesamtbestand bleibt gleich, aber die Lieferzeitberechnung für einen Kunden in München ändert sich sofort. Die Middleware verarbeitet Umlagerungsbewegungen als atomare Transaktionen: Der Abgang in Lager Nord und der Zugang in Lager Süd werden synchron aktualisiert, um keine inkonsistenten Zwischenzustände im Shop anzuzeigen.

Retouren stellen eine besondere Herausforderung dar, da retournierte Ware nicht sofort wieder verkaufsfähig ist. Die Middleware unterstützt einen Retouren-Puffer: Retournierte Artikel werden zunächst in einem separaten Bestandsstatus geführt und erst nach der Qualitätsprüfung dem verfügbaren Bestand zugeschlagen. Dieser Prozess verhindert, dass Kunden Ware bestellen, die sich noch in der Retourenprüfung befindet.

Wenn ein Artikel in allen Lagern ausverkauft ist, endet die Aufgabe der Bestandssynchronisation nicht. B2B-Kunden benötigen die Information, wann der Artikel voraussichtlich wieder verfügbar ist. Die Middleware kann Nachbestellinformationen aus dem ERP auslesen -- offene Bestellungen beim Lieferanten, erwartete Liefertermine, bestellte Mengen -- und diese im Shop als voraussichtlichen Verfügbarkeitstermin anzeigen.

Für B2B-Kunden, die ihre Beschaffung planen müssen, ist diese Information geschäftskritisch. Ein Liefertermin-Versprechen basierend auf realen ERP-Daten ist deutlich verlässlicher als eine generische Angabe wie 'derzeit nicht verfügbar'. Laut einer Studie von Digital Commerce 360 bestellen 38 Prozent (Projekterfahrung) der B2B-Einkäufer auch bei vorübergehend nicht verfügbaren Artikeln, wenn ein konkreter Liefertermin genannt wird (Digital Commerce 360, 2025). Ohne diese Information wechseln sie häufig zum Wettbewerb.

B2B-Unternehmen erleben häufig saisonale Bestandsschwankungen und Lastspitzen -- etwa zum Jahresende (Budgetverbrauch), bei Branchenmessen oder in saisonalen Branchen wie Bau oder Landwirtschaft. Während dieser Phasen steigt das Bestellvolumen sprunghaft an, und die Bestandssynchronisation muss mit dem erhöhten Durchsatz mithalten.

Die Middleware skaliert automatisch mit dem Bestellvolumen. Konfigurierbare Schwellenwerte passen die Sync-Frequenz dynamisch an: Bei normalem Betrieb läuft der Delta-Sync alle fünf Minuten, bei erhöhtem Bestellvolumen automatisch alle zwei Minuten, und bei Lastspitzen wird auf Event-basierte Synchronisation umgeschaltet. Diese dynamische Anpassung stellt sicher, dass die Bestandsanzeige auch in Spitzenzeiten aktuell bleibt, ohne das ERP-System in ruhigeren Phasen unnötig zu belasten. Laut einer Untersuchung des Handelsverbands Deutschland unterschätzen 52 Prozent (Projekterfahrung) der Online-Händler den Einfluss saisonaler Lastspitzen auf ihre Systeminfrastruktur (HDE, 2025).

Inventuren und manuelle Bestandskorrekturen im ERP erzeugen plötzliche, großvolumige Bestandsänderungen, die besondere Anforderungen an die Synchronisation stellen. Wenn bei einer Inventur hunderte Artikel gleichzeitig korrigiert werden, muss die Middleware diese Massenaktualisierung effizient verarbeiten, ohne die reguläre Bestellverarbeitung zu blockieren.

Die Lösung ist eine priorisierte Verarbeitung: Bestellungsbedingte Bestandsänderungen (höchste Priorität) werden sofort verarbeitet, während Inventurkorrekturen (niedrigere Priorität) im Hintergrund abgearbeitet werden. Die Middleware erkennt Inventur-Events anhand des Buchungstyps im ERP und leitet sie in eine separate Queue mit eigener Verarbeitungslogik. So wird sichergestellt, dass eine laufende Inventur den Tagesgeschäft-Betrieb des B2B-Shops nicht beeinträchtigt.