1. Was MSI in Magento 2 wirklich modelliert

MSI Magento 2 steht für Multi Source Inventory und trennt erstmals sauber zwischen physischen Quellen, logischen Stocks und verkaufbarer Menge. Das ist wichtig, weil Bestände in realen Projekten selten nur aus einer einzigen Zahl bestehen. Es gibt Lagerorte, Filialen, Fulfillment-Partner, Pufferbestände und Reservierungen durch noch nicht vollständig abgeschlossene Bestellungen.

Genau deshalb darf man MSI Magento 2 nicht als bloßen Ersatz für das alte Stock-Feld lesen. Eine Source ist ein physischer oder organisatorischer Herkunftsort. Ein Stock bündelt Verfügbarkeit für einen Verkaufskanal. Die salable quantity entsteht dann nicht einfach aus „Bestand minus irgendwas“, sondern aus mehreren Schichten, inklusive Reservierungen. Wer diese Schichten vermischt, baut zwangsläufig falsche Reports oder fehlerhafte Integrationen.

In Projekten zeigt sich das oft erst unter Last. Solange wenige Produkte und wenige Bestellungen existieren, wirkt alles intuitiv. Sobald Retouren, Teillieferungen, unterschiedliche Fulfillment-Wege oder externe ERP-Synchronisationen dazukommen, wird klar, dass MSI Magento 2 eine fachliche Modellierung ist und keine reine Admin-Maske für Lagerbestände.

2. Custom Source in Magento 2 anlegen und denken

Eine Custom Source Magento 2 anzulegen ist technisch machbar, sollte aber fachlich sauber vorbereitet sein. Die Kernfrage lautet nicht nur: Wie erstelle ich eine neue Quelle? Sondern: Welche reale oder logische Funktion repräsentiert diese Quelle im Geschäftsprozess? Ein Lager in Berlin, ein Dropshipping-Partner oder ein Retourenlager sind unterschiedliche Fachobjekte mit unterschiedlichen Folgen für Verfügbarkeit und Versand.

Gerade deshalb sollte eine Custom Source Magento 2 nicht als schneller Workaround für beliebige Sonderfälle missbraucht werden. Wenn die Quelle in Wahrheit nur ein Attribut an einem Bestand oder eine Lieferpräferenz abbildet, ist eine neue Source oft die falsche Modellierung. Quellen sind mächtige Strukturelemente. Sie sollten nur eingeführt werden, wenn sie im Betrieb, in der Logistik oder in der Integrationslogik tatsächlich eine eigenständige Rolle spielen.

<?php
declare(strict_types=1);

use Magento\InventoryApi\Api\Data\SourceInterfaceFactory;
use Magento\InventoryApi\Api\SourceRepositoryInterface;

$source = $sourceFactory->create();
$source->setSourceCode('warehouse_berlin');
$source->setName('Warehouse Berlin');
$source->setEnabled(true);
$source->setCountryId('DE');
$source->setPostcode('10115');
$source->setCity('Berlin');
$source->setStreet('Example Street 1');

$sourceRepository->save($source);

Das Beispiel zeigt nur die Grundidee. In echten Projekten reicht das nicht. Eine Custom Source Magento 2 muss in Zuweisung, Source-Items, Stocks, Fulfillment-Regeln und Integrationen mitgedacht werden. Nur weil eine Quelle existiert, ist sie noch nicht korrekt in den fachlichen Fluss eingebunden.

3. Reservierungen in Magento 2 verstehen

Reservierungen sind einer der am häufigsten missverstandenen Teile von MSI Magento 2. Viele Entwickler erwarten, dass jede Bestellung sofort direkt den physischen Quellbestand reduziert. Tatsächlich arbeitet Magento mit Reservations, um die verkaufbare Menge zu beeinflussen, bevor der gesamte Fulfillment-Prozess endgültig verbucht ist. Das ist wichtig, weil Bestellung, Zahlung, Shipment, Storno und Retouren zeitlich auseinanderfallen können.

Praktisch bedeutet das: Die salable quantity reagiert oft früher als der physische Bestand einer konkreten Quelle. Genau diese Differenz ist kein Fehler, sondern Teil des Modells. Wenn man Reservierungen ignoriert, wirken Reports oder API-Werte schnell widersprüchlich. Versteht man sie, ergibt das Verhalten von MSI Magento 2 eine nachvollziehbare Kette: Verkaufbarkeit wird gesichert, bevor endgültige Lagerbuchungen vollendet sind.

bin/magento inventory:reservation:list-inconsistencies
bin/magento inventory:reservation:create-compensations

Diese Kommandos sind in Projekten extrem wertvoll, weil sie helfen, Unstimmigkeiten zwischen Bestellfluss und Reservierungszustand zu erkennen. Gerade bei Importen, Migrationsfällen oder fehlerhaften Drittmodulen ist das oft die Ebene, auf der die Wahrheit sichtbar wird.

4. Datenfluss zwischen Source Items, Stocks und Salable Quantity

Ein gutes Verständnis von MSI Magento 2 entsteht erst, wenn man den Datenfluss komplett denkt. Source Items beschreiben die Zuordnung eines Produkts zu einer Quelle und die jeweilige Menge. Stocks bündeln Quellen für einen Verkaufskanal. Die salable quantity ergibt sich aus Beständen, Zuordnungen und Reservierungen. Diese Ebenen sind verwandt, aber nicht identisch.

Genau hier machen viele Teams Fehler in Eigenentwicklungen und Integrationen. Sie lesen nur einen Wert aus einer Tabelle und nennen ihn „Bestand“, obwohl sie fachlich eigentlich Verkaufbarkeit meinen. Oder sie schreiben Quellmengen direkt um, obwohl das Problem in Reservierungen oder Stock-Zuweisungen liegt. Wer mit MSI Magento 2 arbeitet, muss deshalb immer fragen: Welcher Bestand interessiert mich genau? Physisch, kanalbezogen oder verkaufbar?

<?php
declare(strict_types=1);

use Magento\InventoryApi\Api\SourceItemsSaveInterface;
use Magento\InventoryApi\Api\Data\SourceItemInterfaceFactory;

$sourceItem = $sourceItemFactory->create();
$sourceItem->setSourceCode('warehouse_berlin');
$sourceItem->setSku('demo-sku');
$sourceItem->setQuantity(25.0);
$sourceItem->setStatus(1);

$sourceItemsSave->execute([$sourceItem]);

Solche Updates sollten nie isoliert gesehen werden. Jede Mengenänderung in einer Source wirkt auf nachgelagerte Verfügbarkeitsberechnungen. Gute Implementierungen behandeln MSI Magento 2 deshalb als System von Zuständen, nicht als einzelne Spalten mit Zahlen.

5. Typische Erweiterungsfälle mit MSI

Typische Projekte erweitern MSI Magento 2 bei Filialverfügbarkeit, Dropshipping, B2B-Verfügbarkeiten, externem ERP, Marktplatzanbindungen oder kanalabhängigen Fulfillment-Regeln. In all diesen Fällen ist die Kernaufgabe nicht nur „Bestand schreiben“, sondern eine stabile Übersetzung zwischen externen Geschäftsprozessen und dem MSI-Modell.

Eine gute Erweiterung fragt deshalb zuerst nach der Domäne. Soll eine Quelle einen realen Standort abbilden? Soll sie nur ein bestimmtes Fulfillment-Muster abgrenzen? Braucht das Projekt echte kanalbezogene Stocks oder nur differenzierte Reporting-Ebenen? Diese Fragen entscheiden, ob MSI Magento 2 zum Problemlöser wird oder zur zusätzlichen Komplexität.

Besonders riskant sind Integrationen, die „zur Sicherheit“ alte Single-Stock-Annahmen behalten und MSI nur oberflächlich bedienen. Dann werden Source Items zwar geschrieben, aber Salable Quantity oder Reservierungen werden in Reporting, Export oder Checkout-Logik ignoriert. Genau dort entstehen später die teuren Inkonsistenzen.

6. Typische Fehler

Die häufigsten Fehler sind konzeptionell. Teams verwechseln Quelle und Stock. Sie interpretieren salable quantity als physischen Bestand. Sie ignorieren Reservierungen. Sie führen neue Sources ein, obwohl eigentlich keine neue Quelle, sondern nur ein anderer Prozesszustand modelliert werden müsste. Oder sie überschreiben Daten direkt in Tabellen und umgehen die fachlichen APIs von MSI Magento 2.

Ein weiterer häufiger Fehler ist, das Debugging auf die falsche Ebene zu legen. Wenn ein Produkt als nicht verfügbar erscheint, wird oft nur auf Source-Mengen geschaut. Vielleicht liegt das Problem aber in Stock-Zuweisungen, im Reservierungszustand oder in einem fehlerhaften Kompensationslauf. Gute Diagnose beginnt bei der Fachfrage und sucht dann die passende Ebene im MSI-Modell.

Auch Drittmodule sind ein Risiko. Erweiterungen, die auf das alte Bestandsdenken optimiert wurden, können mit MSI Magento 2 unklare Seiteneffekte erzeugen. In solchen Fällen reicht ein Bugfix an einer Stelle oft nicht. Dann muss die Lagerlogik als Gesamtbild geprüft werden.

7. MSI vs. klassisches Single-Stock-Denken

Der Unterschied zwischen MSI Magento 2 und klassischem Single-Stock-Denken ist nicht nur technische Mehrstufigkeit, sondern fachliche Präzision. Single Stock kennt im Kern eine Lagerzahl. MSI trennt dagegen Herkunft, Kanalzuordnung und Verkaufbarkeit. Das ist aufwendiger, aber für realistische Fulfillment-Szenarien oft unverzichtbar.

MSI ist also kein Selbstzweck. Es lohnt sich genau dort, wo die Geschäftsrealität mehr ist als eine einzige Lagerzahl. Wer das verstanden hat, kann das System schlank und präzise nutzen, statt es unnötig zu übermodellieren.

9. Zusammenfassung

MSI Magento 2 trennt Quellen, Stocks und Verkaufbarkeit bewusst voneinander. Wer diese Ebenen respektiert, kann Multi-Lager-, Kanal- und Fulfillment-Szenarien sauber modellieren. Wer sie vermischt, produziert früher oder später Bestandsfehler, kaputte Integrationen oder falsche Reports.

Die wichtigste Praxisregel bleibt: Nicht nur Mengen anschauen, sondern immer die fachliche Ebene benennen. Geht es um physischen Bestand, kanalbezogene Verfügbarkeit oder salable quantity? Erst mit dieser Klarheit wird MSI im Projekt beherrschbar.

10. FAQ: MSI in Magento 2