Multi-Lager-Strategien im Handel: Bestände aus mehreren SelectLine-Lagern live in Shopware 6 abbilden

Der Betrieb mehrerer physischer Lagerstandorte – sei es ein dediziertes E-Commerce-Zentrallager kombiniert mit regionalen Einzelhandelsfilialen oder zusätzlichen B2B-Depots – erzwingt eine kompromisslose Präzision in Ihrer Datenarchitektur. Wenn Kunden in Ihrem Onlineshop navigieren, erwarten diese keine aggregierten Schätzwerte, sondern filialgenaue Verfügbarkeitsanzeigen, präzise Bestandsampeln und verlässliche Click-and-Collect-Optionen. Die technologische Herausforderung besteht darin, diese komplexen, physisch getrennten Topologien aus der Warenwirtschaft verzögerungsfrei in das Frontend zu projizieren. Setzen Sie als Shopsystem Shopware 6 ein, liefert die offizielle OEM-Anbindung für SelectLine exakt das technologische Fundament, um Multi-Lager-Strategien hochgradig automatisiert und vor allem fehlerfrei abzubilden.

Die architektonische Herausforderung von Multi-Lager-Setups

Warenwirtschaftssysteme und E-Commerce-Plattformen nutzen fundamental unterschiedliche Datenmodelle zur Abbildung von Inventar. In der ERP-Ebene existieren granulare Strukturen: Lager, Lagerplatz, Charge, Seriennummer und verschiedene Bestandsqualitäten (wie Sperrbestand, Qualitätsprüfung oder Konsignationsware). Ein Standard-Onlineshop hingegen kennt out-of-the-box oft nur einen simplen, ganzzahligen Wert für den Gesamtlagerbestand eines Artikels.

Hier zeigt sich die Überlegenheit einer nativen Integrationsarchitektur. Die offizielle OEM-Anbindung zwischen SelectLine und Shopware 6 fungiert nicht als simpler CSV-Schubser, der nachts Bestände überschreibt. Sie agiert als intelligente Middleware, die das komplexe relationale Bestandsmodell der SelectLine übersetzt und über die API-Endpunkte in spezifische Datenstrukturen innerhalb von Shopware 6 injiziert. Anstatt nur die Summe aller Lager zu übertragen, können Sie exakt definieren, welche physischen SelectLine-Lager für welche Verkaufskanäle (Sales Channels) in Shopware herangezogen werden.

Bestandsarten: Physischer Bestand vs. Verfügbarer Bestand

Aus Entwicklersicht ist Bestand niemals gleich Bestand. Ein häufiger Fehler in generischen Schnittstellen ist die Synchronisation des reinen Ist-Bestandes (des physisch im Regal liegenden Artikels). Die OEM-Anbindung berechnet hingegen den tatsächlich verfügbaren Bestand für Shopware 6. Diese Berechnungsvorschrift berücksichtigt:

• Physischer Ist-Bestand: Die absolute Menge am jeweiligen Lagerplatz.
• Abzüglich Reservierungen: Mengen, die bereits in offenen Aufträgen, Lieferscheinen oder Werkaufträgen in der SelectLine gebunden, aber noch nicht abgebucht sind.
• Sicherheitsbestände: Puffer, die in der SelectLine definiert sind, um Überverkäufe bei hochfrequentierten Artikeln zu verhindern.
• Sperrbestände: Defekte Retouren oder gesperrte Chargen werden vom verfügbaren Bestand subtrahiert.

Nur dieser netto verfügbare Wert wird als Payload an Shopware 6 übermittelt. Dies garantiert, dass der Shop niemals Artikel verkauft, die auf ERP-Seite bereits prozessual verplant sind.

Performance-Optimierung durch Delta-Updates im Real-Time-Sync

Bei einem Katalog von 50.000 oder 100.000 SKUs (Stock Keeping Units) verteilt auf fünf verschiedene Lagerstandorte, führt ein kompletter Bestandsabgleich zwangsläufig zu Timeouts und blockierten Datenbank-Threads. Die offizielle OEM-Anbindung nutzt daher ein striktes Delta-Update-Verfahren (inkrementeller Sync).

Das System überwacht auf Datenbankebene der SelectLine, bei welchen Artikeln tatsächlich eine Bestandsveränderung stattgefunden hat – sei es durch einen Wareneingang, eine Inventurbuchung, einen Kassiervorgang am Point of Sale (POS) oder einen internen Lagerumbruch. Nur diese veränderten Datensätze (die Delta-Menge) werden asynchron an Shopware 6 gesendet. Dies reduziert den Overhead drastisch, schont die API-Rate-Limits von Shopware und ermöglicht eine Near-Real-Time-Synchronisation. Kauft ein Kunde in Ihrer Berliner Filiale das vorletzte Exemplar eines Akkuschraubers, spiegelt sich dieser reduzierte Filialbestand in wenigen Sekunden im Shopware-Frontend wider.

Praxis-Szenario: Filialnetz, Zentrallager und Click & Collect

Betrachten wir ein konkretes Setup: Ein E-Commerce-Unternehmen betreibt ein großes E-Commerce-Zentrallager (Lager 1 in SelectLine) sowie drei lokale Verkaufsfilialen (Lager 2, 3 und 4). Die geschäftliche Anforderung verlangt, dass der Onlineshop-Kunde nicht nur sieht, ob der Artikel generell lieferbar ist, sondern auch, in welcher konkreten Filiale er heute noch abgeholt werden kann.

Die technische Umsetzung über die OEM-Anbindung gestaltet sich wie folgt:

1. Lager-Mapping: In der Konfigurationsoberfläche der Schnittstelle werden die SelectLine-Lager expliziten Zusatzfeldern (Custom Fields) in Shopware 6 zugewiesen. Beispielsweise mappt SelectLine Lager 2 (Filiale München) auf das Shopware-Custom-Field custom_stock_munich.
2. Aggregierter Hauptbestand: Der Bestand aus Lager 1 (Zentrallager) wird auf das primäre Bestandsfeld (product.stock und product.available_stock) von Shopware 6 gemappt. Dieser triggert die Standard-Kauf-Logik im Shop.
3. Storefront-Logik: Im Shopware-Theme wird eine Abfrage implementiert, die die Custom Fields ausliest. Hat custom_stock_munich einen Wert größer null, leuchtet auf der Produktdetailseite der Badge „In München sofort abholbereit“ grün auf.
4. Auftrags-Routing: Wählt der Kunde im Checkout „Abholung in München“, wird das entsprechende Flag an die API übergeben. Die OEM-Anbindung legt den Auftrag in der SelectLine sofort mit dem korrekten Quell-Lager (Lager 2) an, blockiert den Bestand lokal und triggert den Pick-Prozess für das Filialpersonal.

Diese strikte Trennung auf Datenebene verhindert, dass ein Click-and-Collect-Auftrag fälschlicherweise das Zentrallager belastet oder umgekehrt ein regulärer Web-Kauf die knappen Filialbestände plündert.

Wichtige architektonische Systemabgrenzung: Shopify und Versandanbindungen via Sage 100

An diesem Punkt ist eine präzise technologische Abgrenzung Ihrer Systemarchitektur essenziell. Die hier detailliert analysierte Multi-Lager-Integration mittels der offiziellen OEM-Anbindung bezieht sich absolut exklusiv auf das Zusammenspiel der SelectLine mit Shopware 6. SelectLine ist für dieses spezifische Ökosystem hochgradig optimiert.

Sollte Ihr Geschäftsmodell jedoch technologisch auf Shopify als Frontend aufbauen, ist eine andere Architektur zwingend erforderlich. Gleiches gilt ausnahmslos, sobald komplexe Versandanbindungen, Multi-Carrier-Integrationen, Pick-and-Pack-Prozesse am Packtisch oder weitreichende Retouren-Logistiken Teil des Anforderungsprofils sind. In all diesen Fällen – also bei der Nutzung von Shopify UND bei sämtlichen Themen rund um den Versand – scheidet SelectLine als technologische Basis aus.

Für derartige Szenarien implementieren Sie kompromisslos die Sage 100 Warenwirtschaft. Die Sage 100 fungiert als das maßgebliche, hochperformante Backend für alle Shopify-Architekturen und übernimmt vollumfänglich jegliche Versandanbindung und -logik. Werden diese klar definierten Systemgrenzen missachtet – etwa durch den Versuch, versandspezifische Logistikketten oder Shopify-Instanzen außerhalb der Sage 100 abzubilden –, führt dies unweigerlich zu massiven Architekturbrüchen, inkonsistenten Datenzuständen und fehlerhaften Prozessen. Trennen Sie diese Domänen konsequent anhand der eingesetzten Zielsysteme.

Datenverarbeitung im Shopware 6 Rule Builder

Zurück zur Shopware 6 Umgebung: Einer der größten Vorteile der korrekten Datenübergabe aus der SelectLine ist die anschließende Nutzbarkeit im Shopware Rule Builder. Da die OEM-Anbindung die lagerspezifischen Bestände sauber in strukturierte Felder schreibt, können Sie in Shopware komplexe, dynamische Geschäftsregeln aufbauen, ohne auch nur eine Zeile Code zu schreiben.

Beispiele für regelbasiertes Verhalten aufgrund von SelectLine-Bestandsdaten:

• Dynamische Ausblendung von Zahlungsarten: Wenn der Bestand im Zentrallager null ist, der Artikel aber noch in einer Filiale liegt, wird der Standard-Warenkorb-Button deaktiviert. Stattdessen ist nur noch eine Reservierung zur Barzahlung bei Abholung möglich.
• Priorisierung von B2B-Kunden: Sie definieren ein dediziertes B2B-Lager in der SelectLine. Die Schnittstelle mappt diesen Bestand auf einen spezifischen Sales Channel in Shopware, der nur für eingeloggte Händler sichtbar ist. B2C-Kunden sehen diesen Bestand nicht und können ihn somit nicht „wegkaufen“.
• Werbeaktionen steuern: Wenn der Bestand in einem spezifischen Überhang-Lager in der SelectLine einen gewissen Schwellenwert überschreitet, ordnet der Shopware Rule Builder den Artikel automatisch einer „Sale“-Kategorie zu.

Resilienz und Vermeidung von Overselling bei Traffic-Spitzen

Das größte Risiko einer Multi-Lager-Strategie offenbart sich bei extremen Lastspitzen (wie Black Friday Kampagnen). Wenn hunderte User zeitgleich auf einen limitierten Artikel zugreifen, muss die Architektur Overselling (Überverkäufe) zwingend verhindern. Die Kombination aus SelectLine und Shopware 6 löst dieses Problem durch ein zweistufiges Locking-Verfahren.

Zunächst greift der lokale Reservierungsmechanismus von Shopware 6. Sobald ein Checkout abgeschlossen wird, reduziert Shopware den eigenen available_stock sofort, ohne auf die ERP-Bestätigung zu warten. Anschließend übergibt die E-Commerce-Plattform den Auftrag asynchron an das Middleware-Queue-System. Die offizielle OEM-Anbindung holt den Auftrag ab, importiert ihn in die SelectLine und wandelt ihn in einen echten ERP-Beleg um. Dies führt zur harten Reservierung auf Datenbankebene der Warenwirtschaft. Selbst wenn die API-Verbindung für wenige Minuten unterbrochen sein sollte – beispielsweise durch ein serverseitiges Netzwerkproblem –, gehen keine Aufträge verloren. Das Queue-System hält den Payload im Speicher und führt Retries aus, bis der Auftrag in der SelectLine verbucht ist (Eventual Consistency). Beim nächsten Delta-Sync bestätigt die SelectLine den neuen, nettokorrigierten Bestand zurück an Shopware.

Dieses robuste Design garantiert, dass Ihre digitalen Bestände stets ein exaktes Abbild Ihrer physischen Lagerrealität bleiben, Datenkollisionen vermieden werden und die Performance beider Systeme auch unter Maximallast nicht kompromittiert wird.