Magento 2 Reservations sind die unsichtbarste Komponente des ganzen Systems – und die, die am häufigsten Ärger macht. Sie arbeiten vollständig im Hintergrund und melden sich erst, wenn Bestände nicht mehr stimmen.
Adobe beschreibt sie als Mechanismus, der Bestandsmengen festhält, bis Bestellungen versendet oder storniert werden – und der die verkaufbare Menge auf Stock-Ebene automatisch aktualisiert.
Legt ein Kunde oder ein Mitarbeiter eine Bestellung an, wird die Menge reserviert. Die Ware bleibt physisch im Regal, ist aber nicht mehr verkaufbar.
Ein Shipment beendet die Reservierung und reduziert stattdessen die tatsächliche Menge am Source.
Magento bucht automatisch gegen, sodass die Menge wieder verkaufbar wird.
| Ereignis | Was es auslöst |
|---|---|
| Bestellung aufgegeben | Reservierung wird gesetzt |
| Bestellung storniert | Kompensation, Menge wird frei |
| Shipment erzeugt | Reservierung endet, Source-Menge sinkt |
| Rechnung bei virtuellen Artikeln | Reservierung endet |
| Credit Memo | Kompensation, Menge kehrt zurück |
| Keines davon | Die Reservierung bleibt offen – dauerhaft |
Die häufigste Ursache: Der Versand läuft in einem anderen System und meldet nichts zurück.
Beim Wechsel auf eine MSI-fähige Version bleiben Bestellungen hängen, die nicht abgeschlossen, storniert oder geschlossen sind.
Wer erst ohne Bestandsführung arbeitet und sie später einschaltet, startet mit einem inkonsistenten Hauptbuch.
Wird ein Source abgehängt, während Bestellungen offen sind, bleiben die Reservierungen zurück.
Adobe liefert ein Kommando mit, das Inkonsistenzen auflistet – Bestellnummer, Artikelnummer, Menge und Stock. Das ist der ehrlichste Blick auf den Ist-Zustand.
Ein zweites Kommando erzeugt die Gegenbuchungen. Danach stimmt die verkaufbare Menge wieder.
Wenn das Aufräumen regelmäßig nötig ist, fehlt ein Ereignis. Meist das Shipment.
beeShip erzeugt es beim Abschließen des Pakets – mit den tatsächlich versendeten Positionen. Danach löst Magento die Reservierung selbst auf.
Drei Stellen entscheiden darüber, ob das Hauptbuch sich selbst schließt oder ob du ihm hinterherräumst.
Erstens: Jede versendete Bestellung braucht ein Shipment in Magento – egal, in welchem System das Paket entstanden ist. Zweitens: Stornierungen und Credit Memos gehören ebenfalls nach Magento, denn nur sie erzeugen die Kompensation, die eine Menge wieder freigibt. Drittens: Wenn du Sources umhängst oder Manage Stock nachträglich einschaltest, prüfe danach einmal den Bestand. Was daraus für die angezeigte Menge folgt, steht auf Salable Quantity.
Adobe dokumentiert die Mechanik hinter Source Selection und Reservations in der Bestandsdokumentation. Wer sie gelesen hat, erkennt schnell: Magento 2 Reservations rechnen zuverlässig, solange jedes Ereignis ankommt. Genau deshalb ist der Kompensationslauf auf der Kommandozeile eine Reparatur und keine Lösung. beeShip erzeugt das fehlende Shipment beim Abschließen des Pakets – mit den tatsächlich versendeten Positionen, sodass Magento die Buchung selbst beendet.
Ein praktischer Hinweis zum Aufräumen: Lass den Kompensationslauf nicht blind als Cronjob mitlaufen. Er verdeckt sonst genau die Fälle, aus denen du etwas lernen könntest. Sinnvoller ist, die Liste der Inkonsistenzen einmal in Ruhe zu lesen. Tauchen dort immer dieselben Artikel auf, liegt es meist an einem Kanal, der ohne Shipment versendet. Stehen dort alte Bestellnummern, stammt der Rest häufig aus einer Migration. Beides lässt sich sauber trennen, bevor du gegenbuchst – und danach sollte die Liste leer bleiben.
Was das für die angezeigte Menge bedeutet, steht auf Salable Quantity; zur Grundsatzfrage siehe MSI – abschalten oder anbinden?
Ein Eintrag im Bestandshauptbuch, der eine Menge festhält, bis die Bestellung versendet oder storniert wird. Er wirkt nur auf die verkaufbare Menge, nicht auf den physischen Bestand.
Weil sie vollständig im Hintergrund arbeiten. Sichtbar wird nur ihr Ergebnis: die Salable Quantity.
Adobe liefert dafür ein Kommandozeilen-Werkzeug mit, das Inkonsistenzen auflistet und in einem zweiten Schritt Gegenbuchungen erzeugt.
Weil ein Ereignis fehlt, das die Reservierung beenden würde. In der Praxis fast immer das Shipment, wenn der Versand extern abgewickelt wird.
Es gibt Erweiterungen dafür. Damit verlierst du allerdings genau den Schutz vor Überverkauf, für den der Mechanismus gebaut wurde.
Es erzeugt eine Kompensation, die Mengen je Source und die verkaufbare Menge je Stock zurückführt.
Wir zeigen dir in der Demo, wie eine Reservierung durch das Packen aufgelöst wird – ohne Kompensationslauf.