MSI: Probleme mit der Lagerverwaltung in Magento 2.3

Das mit Magento 2.3.2 eingeführte Multi Source Inventory (MSI) verursacht immer wieder Probleme in der Lagerverwaltung. Wir erklären, was genau schief läuft, warum das passiert und unter welchen Umständen Fehler beziehungsweise Inkonsistenzen auftreten. – Und Lösungsmöglichkeiten haben wir dafür auch parat.

Was ist das Multi Source Inventory (MSI)?

Das seit 2017 (wir berichteten) in enger Zusammenarbeit mit der Community entwickelte Multi Source Inventory (MSI) wurde mit dem Release von Magento 2.3.0 für den Produktiveinsatz freigegeben und ist seit Magento 2.3.2 vorinstalliert. Seither unterstützt Magento als neues wichtiges Feature bei Bedarf mehr als nur ein Lager, also beispielsweise mehrere Standorte für das Sortiment des Shops. Das heißt, Warenbestände, die in mehreren physischen Lagern vorgehalten werden, lassen sich dank MSI zentral verwalten und nach definierten Kriterien für unterschiedliche Verkaufskanäle (zum Beispiel mehrere Storeviews des Shops beziehungsweise Marktplätze) zur Verfügung stellen. Detaillierte Informationen über die Konfiguration des Multi (beziehungsweise Single) Source Inventory liefert Magento im User Guide für Magento 2.3.

Was hat sich durch das MSI geändert?

Händler, die Magento weiterhin so nutzen wir zuvor, also mit nur einem Lager, sehen sich nun durch das für sie gar nicht relevante MSI mit einem neuen Fallstrick konfrontiert, der seitens Magento nicht transparent kommuniziert worden ist. Die veränderte Sachlage lässt sich am besten in einem Vorher-Nachher-Vergleich erklären:

Vorher: Die Situation ohne MSI

Wenn Kunden im Shop Produkte in den Warenkorb gelegt und bestellt haben, war dieser Prozess vor der Einführung des MSI ganz einfach:

1. Der Kunde legt ein Produkt in den Warenkorb.
   Es erfolgt eine erste Lagerbestandsprüfung, jedoch keine Reservierung der Menge.
2. Der Kunde schließt die Bestellung ab.
   Es erfolgt eine zweite Lagerbestandsprüfung und der direkte Abzug des Lagerbestands.
3. Der Shopbetreiber erstellt im Backend gegebenenfalls die Rechnung.
4. Der Shopbetreiber löst im Backend gegebenenfalls den Versand aus.

Nachher: Die Situation mit MSI

Mit dem MSI ist dieser Prozess nun komplizierter geworden. Damit die Bestandsaktualisierung über mehrere Läger hinweg konsistent funktioniert, wurde eine Reservierung der Bestände eingeführt. Das heißt, die Bestände werden zunächst in einer neuen Tabelle lediglich reserviert, aber nicht direkt verrechnet. Daraus ergibt sich im Backend die neue Spalte „Salable Quantity“ (verkaufbare Menge), die den Lagerbestand über alle Läger nach Abzug der reservierten Menge darstellt. Damit stellt sich der Kaufprozess in Magento mit dem MSI nunmehr so dar:

1. Der Kunde legt Ware in den Warenkorb.
   Es erfolgt eine erste Lagerbestandsprüfung, aber noch keine Reservierung der Menge.
2. Der Kunde schließt die Bestellung ab.
   Es erfolgt eine zweite Lagerbestandsprüfung und die Reservierung des Lagerbestands.
3. Der Shopbetreiber erstellt im Backend gegebenenfalls die Rechnung.
4. Der Shopbetreiber löst im Backend gegebenenfalls den Versand aus.
   Die Reservierung wird mit dem Lagerbestand verrechnet.

Dieser auf den ersten Blick nur wenig komplexer gewordene Prozess birgt – je nach Anwendungsfall – die Gefahr, dass es zu Fehlern und Inkonsistenzen in der Lagerverwaltung kommt, die den Betrieb des Shops empfindlich beeinträchtigen können.

Das erste Problem: Falsche Lagerbestände wegen nicht berücksichtigter Bestellungen

Das erste aus dem beschriebenen veränderten Ablauf erwachsende Problem: Reservierte Produkte werden erst dann mit dem Bestand verrechnet, wenn in Magento die jeweilige Sendung angelegt wird. Das führt zu einem schwerwiegenden Problem: Es entsteht ein womöglich unbegrenzter Zeitraum, in dem der Lagerbestand am Produkt nicht „stimmt“, weil es offene Reservierungen gibt, die noch nicht verrechnet worden sind, obwohl die entsprechenden Bestellungen bereits eingegangen und möglicherweise sogar schon Rechnungen erstellt worden sind.

Da die Reservierungen erst verrechnet werden, wenn in Magento eine Sendung angelegt wird, kann es passieren, dass an einem bestimmten Punkt gar keine Produkte mehr gekauft werden können. Wenn nämlich Sendungen aus bestimmten Gründen nicht in Magento erstellt werden (beispielsweise weil der Shopbetreiber diesen Prozess in Magento gar nicht benötigt oder extern durch ein ERP-System zum Anlegen von Sendungen löst). Denn dann erscheinen in der Lagerverwaltung nach wie vor Bestände, die bereits verkauft und versandt worden sind, während die Produkte für die Kunden (aufgrund der weiterhin bestehenden Reservierungen) gleichwohl nicht mehr bestellbar sind.

Das zweite Problem: Inkonsistenzen durch automatischen Bestandsabgleich

Ein weiteres Problem ergibt sich seit der Einführung des MSI im Zuge von Bestandsabgleichen, die etwa über einen Cronjob vorgenommen werden: Da der eigentliche Bestand am Produkt erst mit der Sendungserstellung verrechnet wird, ist der Lagerbestand vom Zeitpunkt der Bestellung bis zum Versand nicht konsistent, selbst wenn in der Zwischenzeit der aktualisierte Lagerbestand eingespielt wird. Hierfür ein Beispiel:

1. Regelmäßiger Lagerbestandsimport: Das Produkt A hat einen Bestand von 5.
2. Ein Kunde kauft ein Produkt A; der Bestand wird entsprechend reserviert: Der Lagerbestand bleibt 5, zudem gibt es eine Reservierung (korrekt).
3. Der Auftrag wird an das angebundene ERP-System übermittelt.
4. Regelmäßiger Lagerbestandsimport: Das Produkt A hat einen Bestand von 4, da das ERP den Bestand inzwischen abgezogen hat. Die verkaufbare Menge ist 4 – 1 = 3 und damit falsch beziehungsweise inkonsistent.
5. Die Sendung wird in Magento erstellt; die Reservierung wird verrechnet: Die verkaufbare Menge ist 4 – 0 = 4 und damit wieder korrekt.
6. Regelmäßiger Lagerbestandsimport: Das Produkt A hat einen Bestand von 4 (wieder korrekt).

Welche Lösungsmöglichkeiten gibt es?

Wer das Multi Source Inventory nicht nutzen möchte, kann das MSI Modul aus Magento deinstallieren. Die beschriebenen Probleme treten dann im Shop nicht auf.

Abhilfe bietet alternativ die Extension magento2-disable-stock-reservation von Ampersand. Die Erweiterung implementiert in Magento 2.3 das alte Verhalten (siehe oben, “Vorher: Die Situation ohne MSI”). Das heißt, es werden nie Reservierungen angelegt, sondern der Lagerbestand wird bei Bestelleingang direkt abgezogen.
Wer als Händler einen Magento 2.3 Shop mit nur einem Lager betreibt und die beschriebene Quelle für Inkonsistenzen und Fehler ausräumen möchte, kann seinen Shop damit mit dieser Extension schnell und unkompliziert für die korrekte Lagerbestandsverwaltung umrüsten.

Können wir Sie unterstützen?

Haben Sie in ihrem Magento 2.3 Onlineshop bereits Fehler in der Lagerverwaltung festgestellt? Oder befürchten Sie, dass auch ihr Shop von den hier beschriebenen Problemen betroffen sein könnte? Wenden Sie sich an uns! Wir helfen Ihnen gern weiter.

Jetzt Kontakt aufnehmen!