Zum Inhalt wechseln
All-in-One-Suite für E-Commerce & Fulfillment
Für 3PL-DienstleisterbeeShip Fulfillment SuiteKundenportale, Leistungsabrechnung & mehrWohin möchtest du?
Demo vereinbaren
Made in GermanyDSGVO-konformAndroid & Apple
Wohin möchtest du?
Im Backend stehen zwei Zahlen nebeneinander: Quantity und Salable Quantity. Dass die Magento Salable Quantity von der Menge im Regal abweicht, ist kein Fehler – es ist Magentos Bauart. Zum Problem wird es erst, wenn der Versand außerhalb von Magento stattfindet.
Magento führt den physischen Bestand je Source und leitet daraus je Stock die verkaufbare Menge ab.
Der physische Bestand an einem konkreten Lagerort. Diese Zahl ändert sich erst, wenn ein Shipment erzeugt wird.
Jede Bestellung legt einen Eintrag im Reservierungs-Hauptbuch an. Er bleibt liegen, bis die Bestellung versendet oder storniert wird.
Summe der Source-Mengen, abzüglich aller offenen Reservierungen und abzüglich der Schwelle Notify for Quantity Below.
Magento legt eine Reservierung an. Salable Quantity sinkt, Quantity bleibt unverändert – korrekt, die Ware liegt ja noch im Regal.
Das Paket geht raus. Physisch stimmt jetzt nichts mehr, aber Magento weiß davon nichts.
Wird der Versand in einem externen System abgewickelt und dort kein Shipment nach Magento zurückgeschrieben, bleibt die Reservierung bestehen – und die Quantity ebenfalls.
Quantity zeigt Ware, die längst unterwegs ist. Salable Quantity hält Mengen fest, die nie mehr versendet werden. Adobe nennt diesen Zustand „quantities held in stasis“ – nicht verkaufbar und nie versendet.
Das ist der Kern. Nicht Magento rechnet falsch. Es fehlt das Ereignis, das die Reservierung auflöst: das Shipment.
| Ereignis | Wirkung auf die Reservierung | Wirkung auf Quantity |
|---|---|---|
| Bestellung aufgegeben | Reservierung wird angelegt | keine |
| Bestellung storniert | Kompensation, Menge kehrt zurück | keine |
| Shipment erzeugt | Reservierung wird aufgelöst | Quantity am Source sinkt |
| Credit Memo | Kompensation | Menge wird zurückgebucht |
| Nichts davon | bleibt offen stehen | bleibt unverändert |
Adobe liefert inventory:reservation:list-inconsistencies und create-compensations mit. Das repariert den Zustand – es verhindert ihn nicht. Wer das als Cronjob betreibt, hat die Ursache nicht behoben.
Es gibt Erweiterungen, die den Reservierungsmechanismus deaktivieren. Damit verliert man die Überverkaufssicherung, die MSI eigentlich liefern soll.
Der häufigste Rat in Foren. Man wirft damit die Mehrlagerfähigkeit weg, um ein Symptom loszuwerden.
Ein Lagersystem, das außerhalb von Magento versendet, muss das Ereignis nachliefern, das Magento erwartet.
Sobald das Paket am Packtisch abgeschlossen ist, erzeugt beeShip in Magento das Shipment – mit den tatsächlich versendeten Positionen.
Magento verbucht das Ereignis selbst: Reservierung weg, Quantity am Source reduziert, Salable Quantity wieder korrekt.
Wenn das Ereignis kommt, muss niemand hinterher Inkonsistenzen suchen.
Bevor du an Einstellungen drehst, lohnt der Blick auf die Zahlen selbst: Die Magento Salable Quantity ist immer eine Rechnung, nie ein gespeicherter Wert.
Öffne einen Artikel, der dir auffällt, und vergleiche drei Werte: die Menge je Source, die Summe der offenen Reservations und die angezeigte verkaufbare Menge. Klafft dort eine Lücke, gehört sie fast immer zu Bestellungen, die längst versendet wurden, ohne dass jemals ein Shipment in Magento entstanden ist. Wie diese Einträge zustande kommen, steht ausführlich auf Magento Reservations; warum die Bestellung dabei in Processing hängen bleibt, erklärt Bestellstatus.
Die Mengenlogik selbst beschreibt Adobe in der offiziellen Dokumentation zur Bestandsverwaltung: Der Bestand je Source ist die physische Menge, die verkaufbare Menge die daraus abgeleitete. Sobald das Lager das Shipment zurückschreibt, korrigiert sich die Magento Salable Quantity von selbst – ohne Kompensationslauf und ohne Eingriff in die Datenbank. Wer den Versand in beeShip abwickelt, bekommt dieses Ereignis in dem Moment, in dem der Karton zugeht.
Wie das Reservierungs-Hauptbuch genau funktioniert, steht auf Magento Reservations; die Grundsatzfrage behandelt MSI – abschalten oder anbinden?
Quantity ist der physische Bestand an einem Source. Salable Quantity ist die daraus berechnete verkaufbare Menge je Stock: Summe der Source-Mengen minus offene Reservierungen minus die Schwelle Notify for Quantity Below.
Weil Reservierungen offen geblieben sind, die nie durch ein Shipment, eine Stornierung oder ein Credit Memo aufgelöst wurden. Häufigste Ursache: Der Versand läuft extern und es wird kein Shipment nach Magento zurückgeschrieben.
Er repariert den Zustand, beseitigt aber nicht die Ursache. Wer ihn regelmäßig laufen lassen muss, behandelt ein Symptom.
Das ist der häufigste Ratschlag in Foren und selten der beste. Du verlierst damit die Mehrlagerfähigkeit und die Überverkaufssicherung. Sinnvoller ist, das fehlende Ereignis nachzuliefern.
Erst wenn ein Shipment erzeugt wird. Eine Bestellung allein verändert die physische Menge nicht.
beeShip erzeugt das Magento-Shipment beim Abschließen des Pakets – mit den tatsächlich versendeten Positionen. Damit löst Magento die Reservierung selbst auf, und die verkaufbare Menge bleibt korrekt.
In der Demo packen wir eine Bestellung und du siehst, wie Reservierung und Salable Quantity sich in Magento auflösen.
Von der Bestellung bis zum Versand — ein System für dein ganzes Business. Weniger Tools, weniger Chaos, mehr Wachstum.
Alle Preise pro Monat, zzgl. MwSt. · Jahresvertrag: 12 Monate Laufzeit, monatliche Zahlung. Monatstarif: monatlich kündbar.