Magento 2, MSI und inventory_reservation nach der ERP-Integration

Magento 2 mit MSI kann Multi-Source-Inventar, Reservierungen und salable quantity sehr gut verwalten. Das Problem beginnt dann, wenn dieser Mechanismus in einer Implementierung landet, in der die eigentliche Quelle der Wahrheit über Bestände nicht Magento, sondern ein ERP oder ein externes WMS ist. In diesem Modell funktioniert die Reservierungslogik technisch oft noch, geschäftlich wird sie jedoch überflüssig. Statt zu helfen, verzerrt sie das Bild der Verfügbarkeit.

Das ist eines dieser Probleme, die lange unauffällig wirken. Der Shop läuft, Bestellungen kommen herein, Bestandsimporte funktionieren korrekt und trotzdem tauchen mit der Zeit Fragen auf:

• warum salable quantity nicht mit dem Bestand aus dem ERP übereinstimmt
• warum ein Produkt nicht verfügbar ist, obwohl das ERP Verfügbarkeit zeigt
• warum in inventory_reservation Hunderttausende oder Millionen von Einträgen vorhanden sind
• warum die Diagnose von Bestandsproblemen in Magento immer schwieriger wird

In der Praxis ist das ein sehr häufiges Szenario in Shops, die integrationsseitig bereits reif sind und in einem ERP-first-Modell arbeiten.

Wo das Problem beginnt

Im Standard-Magento 2 mit MSI entstehen Einträge in inventory_reservation, wenn Bestellungen aufgegeben werden, und werden später durch weitere Operationen wie Versand oder Stornierung kompensiert. Theoretisch ist alles konsistent. In der Praxis, wenn der Shop Bestände regelmäßig aus dem ERP überschreibt, ist Magento nicht mehr die einzige Quelle der Wahrheit und verwaltet Bestände nicht mehr eigenständig.

Das bedeutet, dass zwei Logiken parallel zu arbeiten beginnen:

• das ERP bestimmt die tatsächliche Verfügbarkeit
• Magento hält weiterhin seine eigene Reservierungsschicht aufrecht

Wenn diese Architektur nicht bewusst geordnet wurde, entstehen Abweichungen. Nicht immer sofort, aber mit der Zeit fast immer.

Symptome, die wir in Projekten sehen

Meist zeigt sich das Problem in einer von mehreren Formen.

1. salable quantity ist niedriger als der Bestand im ERP

Das ist der häufigste Fall. Das Team im Shop sieht, dass das ERP Verfügbarkeit anzeigt, Magento den Verkauf aber trotzdem blockiert oder die kaufbare Menge reduziert.

2. Die Tabelle inventory_reservation wächst ständig

In Shops mit höherem Bestellvolumen kann diese Tabelle sehr schnell wachsen. Das Wachstum allein ist noch kein Fehler, aber in einem ERP-first-Modell wird es oft einfach zu einem unnötigen Wartungsaufwand und zu einem weiteren Ort, der das reale Bild des Bestands verschleiert.

3. Aufwendigere Diagnose von Lagerproblemen

Wenn die Produktverfügbarkeit gleichzeitig vom ERP-Import, von der Magento-Indexierung und von gespeicherten MSI-Reservierungen abhängt, ist die Diagnose nicht mehr einfach. Das Team muss analysieren, ob das Problem beim Import, beim Index, beim Stock, bei der Source-Zuordnung oder in der Tabelle inventory_reservation selbst liegt.

4. Konflikte zwischen Import und der aktuellen Magento-Logik

In manchen Implementierungen verhält sich Magento aus Sicht seiner eigenen Regeln korrekt, aber nicht so, wie es das Business erwartet. Das ist eine wichtige Unterscheidung. Ein System muss technisch nicht kaputt sein, um in einem bestimmten Betriebsmodell falsch zu funktionieren.

Warum der Standardansatz nicht immer ausreicht

Theoretisch könnte man sagen: Wenn Magento MSI hat, dann sollte man es einfach arbeiten lassen. Das Problem ist, dass MSI nicht speziell für jedes ERP-Integrationsmodell entwickelt wurde. In manchen Implementierungen ist es die ideale Architektur. In anderen muss sie bewusst vereinfacht werden.

Es geht nicht darum, gegen Magento zu arbeiten. Es geht darum, aus dem Prozess jene Elemente zu entfernen, die in einer bestimmten Implementierung keinen Mehrwert mehr liefern und stattdessen Schaden anrichten.

In einem ERP-first-Umfeld sind in der Regel wichtiger:

• Konsistenz mit dem Bestand im ERP
• vorhersehbares Verhalten
• schnelle Automatisierung
• wenige Stellen, an denen Abweichungen entstehen können

Wenn MSI-Reservierungen nicht wirklich als Schutzmechanismus für Bestände verwendet werden, ist ihre regelmäßige Bereinigung oft einfach die praktischste Lösung.

Wie wir an die Lösung herangehen

In solchen Projekten versuchen wir nicht, "MSI zu reparieren" oder die Reservierungshistorie wiederherzustellen. Das führt meist nur zu unnötiger Komplexität. Stattdessen beginnen wir mit der Frage, welches Betriebsmodell der Shop tatsächlich hat.

Wenn der Shop nach folgendem Modell arbeitet:

• ERP als Quelle der Wahrheit
• zyklischer Import der Bestände nach Magento
• Akzeptanz einer kurzen Verzögerung zwischen ERP und Shop
• keine Notwendigkeit, dauerhafte Reservierungen auf Magento-Seite zu halten

dann ist die sinnvollste Richtung eine kontrollierte, schnelle und sichere Bereinigung von inventory_reservation.

Was bei einer solchen Lösung wichtig ist

Das reine "Löschen von Datensätzen" reicht nicht aus. Eine solche Lösung muss betrieblich vorhersehbar sein.

Deshalb achten wir auf mehrere Aspekte:

• Möglichkeit zur automatischen Ausführung per CRON
• Möglichkeit zur manuellen Ausführung per CLI
• Schutz vor paralleler Ausführung
• Diagnosemodus ohne Datenlöschung
• optionale Reindexierung nach dem Prozess
• Möglichkeit, das Ganze nur in bestimmten Umgebungen auszuführen
• ein sinnvolles Performance-Modell für große Tabellen

Genau aus diesem Ansatz ist unser Modul entstanden.

Kowal Reservation Cleaner für Magento 2

Für Projekte, in denen das Problem mit MSI-Reservierungen regelmäßig wiederkehrte, haben wir unser eigenes Modul vorbereitet: Kowal Reservation Cleaner für Magento 2.

Dieses Tool haben wir speziell für ERP-first-Implementierungen entwickelt, in denen inventory_reservation sauber oder zumindest vollständig unter Kontrolle gehalten werden soll.

Das Modul entfernt MSI nicht aus Magento und verändert auch nicht den Core. Seine Aufgabe ist es, die Reservierungsschicht so zu ordnen, dass der Shop Folgendes behält:

• Konsistenz mit dem gewählten Bestands-Synchronisationsmodell
• vorhersehbares Verhalten nach dem ERP-Import
• einfachere Verfügbarkeitsdiagnose
• geringeres Risiko einer zu niedrigen salable quantity

Wie unser Modul funktioniert

Das Modul unterstützt drei grundlegende Betriebsmodi.

full_reset

Das ist der einfachste und meist auch praktischste Modus. Wenn die Bereinigung alle Stocks umfassen soll, verwendet das Modul das sehr schnelle:

TRUNCATE TABLE inventory_reservation

Das ist wichtig, weil in großen Shops mit großen Tabellen ein normales massenhaftes DELETE unnötig schwergewichtig sein kann.

log_only

Dieser Modus dient der Diagnose. Er löscht keine Daten, erlaubt aber zu beobachten, wie schnell die Reservierungstabelle wächst und ob die Implementierung tatsächlich eine automatisierte Bereinigung braucht.

clean_after_erp_sync

Das ist die Variante für Teams, die den Bereinigungszeitpunkt klar mit dem ERP-Importplan verknüpfen wollen. Beispiel: Das ERP synchronisiert Bestände um 02:00 Uhr, und das Modul bereinigt die Reservierungen um 02:10 Uhr.

Bereinigung nur für ausgewählte Stocks

Das ist eine der Funktionen, die sich besonders gut in komplexeren Multi-Stock-Implementierungen bewährt.

Nicht jeder Shop möchte die gesamte Tabelle inventory_reservation bereinigen. Manchmal betrifft das Problem nur ausgewählte Stocks, bestimmte Kanäle oder ein separates Logistikmodell. In solchen Situationen erlaubt das Modul, die Bereinigung nur auf bestimmte stock_id zu beschränken.

Das bedeutet:

• für alle Stocks kann das sehr schnelle TRUNCATE genutzt werden
• für ausgewählte Stocks wechselt das Modul zu selektivem DELETE

Das ist ein Kompromiss zwischen Performance und Kontrolle. In vielen Implementierungen ist genau dieser Kompromiss nötig.

CRON, CLI und Prozesssicherheit

Das Modul kann automatisch über Magento CRON oder manuell über CLI gestartet werden. Das ist wichtig, weil verschiedene Shops unterschiedliche Integrationsmodelle haben.

In der Praxis begegnen wir meist zwei Szenarien:

• Bereinigung wird zu einer konkreten Zeit aus dem Magento-Zeitplan gestartet
• Bereinigung wird direkt nach dem ERP-Import durch ein Integrationsskript ausgelöst

Das Modul ist ausgestattet mit:

• einem Lock-Mechanismus
• Logging in eine Datei
• Kontrolle der Ausführungszeit
• dry-run
• optionaler Reindexierung
• optionalem Cache-Clean

Das sind Details, die in einer Produktbeschreibung technisch wirken, aber im produktiven Betrieb darüber entscheiden, ob eine Lösung stressfrei wartbar ist.

Was das geschäftlich bringt

Aus operativer Sicht sind die wichtigsten Vorteile ziemlich konkret:

• weniger Probleme mit der Produktverfügbarkeit
• bessere Konsistenz zwischen Magento und ERP
• weniger Zeitverlust bei der Bestandsdiagnose
• ein einfacheres Modell für die Pflege von MSI im Shop
• die Möglichkeit, den Prozess ohne Core-Änderungen zu automatisieren

Das ist kein Modul "für jeden Magento-Shop". Und genau das ist seine Stärke. Es wurde für einen konkreten Typ von Implementierung entwickelt, der wirklich mit diesem Problem zu kämpfen hat.

Wann man eine solche Lösung in Betracht ziehen sollte

Wenn in Ihrem Shop:

• Bestände regelmäßig aus dem ERP überschrieben werden
• Magento nicht die Hauptschicht für die Bestandsverwaltung sein sollte
• inventory_reservation wächst und die Analyse erschwert
• salable quantity vom realen Bestand abweicht
• das Team ein einfacheres Betriebsmodell braucht

dann kann eine regelmäßige Bereinigung von Reservierungen ein sinnvoller Weg sein.

Natürlich nicht immer. In Shops, die auf die native MSI-Logik als zentralen Mechanismus zur Bestandskontrolle angewiesen sind, ist dieser Ansatz nicht der richtige. Deshalb muss man zuerst das Geschäftsmodell verstehen und erst danach die Lösung wählen.

Zusammenfassung

Das Problem mit inventory_reservation in Magento 2 liegt meist nicht daran, dass MSI "schlecht" ist. Es liegt daran, dass ein Mechanismus, der für ein bestimmtes Betriebsmodell entwickelt wurde, in einem anderen Modell verwendet wird – meist stark mit ERP integriert.

In solchen Implementierungen ist nicht maximale Komplexität entscheidend, sondern Vorhersehbarkeit und Konsistenz mit dem realen Lagerprozess. Deshalb ist in manchen Shops nicht der Ausbau der MSI-Logik die beste Lösung, sondern ihre bewusste Vereinfachung.

Wenn Sie nach einer fertigen Lösung für dieses Szenario suchen, sehen Sie sich unser Modul an: Kowal Reservation Cleaner für Magento 2.

Wenn Sie dagegen zuerst prüfen möchten, ob Ihr Shop dieses Problem tatsächlich hat, lohnt es sich, mit einer Analyse des Bestands-Synchronisationsmodells, der Nutzung von MSI und dem Verhalten von salable quantity nach dem ERP-Import zu beginnen.

Quellen

• Produktseite Kowal Reservation Cleaner dla Magento 2: https://kowal.store/kowal-reservation-cleaner-dla-magento-2