Verfügbarer Bestand in Shopware: warum die Lagerzahl nicht reicht

Ertragswerke · Fallstudie aus dem eigenen Shop · August 2026

Shopware führt je Artikel eine Zahl: den Lagerbestand. Für den größten Teil des Handels genügt das. Sobald aber auf feste Termine geliefert wird und zwischen Bestellung und Auslieferung eine Nachlieferung hereinkommt, rechnet diese eine Zahl systematisch falsch — und kostet Umsatz, den niemand als Verlust sieht. Diese Fallstudie beschreibt das Problem, den Rechenweg dahinter und die Lösung, die daraus entstanden ist.

Wer den Bestand nicht nur zählen, sondern vorausschauend planen will, findet die fertige Umsetzung in der Shopware Warenwirtschaft. Wie Liefertermine und Touren dazu passen, steht beim Liefertermin-Plugin.

Die Ausgangslage: eine Zahl für drei Fragen

Shopware 6 speichert je Artikel einen Lagerbestand und zieht bei jeder Bestellung davon ab. Diese eine Zahl muss drei verschiedene Fragen gleichzeitig beantworten:

• Wie viel liegt tatsächlich im Regal?
• Wie viel davon ist durch offene Bestellungen schon versprochen?
• Wie viel kann ich einem neuen Kunden noch zusagen?

Solange sofort nach Bestelleingang versendet wird, fallen diese drei Antworten praktisch zusammen. Deshalb funktioniert der Standard für die meisten Shops.

Ein Warenwirtschaftssystem wird in dem Moment nötig, in dem sie auseinanderfallen. Und noch etwas fehlt im Standard: Es gibt keinen Wareneingang. Wer Ware einbucht, ändert direkt den Bestand — er verändert also das Ergebnis, statt einen Vorgang zu erfassen.

Der Fall, an dem die Zahl bricht

Der Shop, um den es hier geht, liefert auf feste Termine. Der Kunde wählt beim Kauf einen Liefertag. Zwischen Bestellung und Auslieferung liegen also Tage — und in diese Lücke fällt regelmäßig eine Nachlieferung.

Genau hier rechnet Shopware falsch. Die bestellte Menge wird sofort vom Bestand abgezogen, obwohl sie erst in einigen Tagen das Lager verlässt und die Nachlieferung längst da sein wird. Die Folge: Der Shop meldet „nicht verfügbar" für Ware, die zum Lieferzeitpunkt reichlich vorhanden ist.

Der Schaden ist unsichtbar. Es gibt keine Fehlermeldung, keine stornierte Bestellung, keinen Beschwerdeanruf. Es gibt nur einen Kunden, der einen ausgegrauten Button sieht und weiterzieht.

Die Rechnung, durchgespielt

Ein Artikel, ein Zeitraum von einer Woche. So sieht es im Standard aus:

Auf den ersten Blick geht die Rechnung auf. Der Fehler steckt in der Zeile am Montag: Von Montag bis Mittwoch zeigt der Shop 28 Stück als verfügbar an — obwohl am Freitag 38 im Lager liegen werden. Zwei Tage lang sind zehn Stück künstlich blockiert.

Wer in diesem Fenster bestellen will und mehr als 28 braucht, bekommt eine Absage. Wer im Laden steht und drei Stück mitnehmen möchte, steht vor einem Bestand, der rechnerisch knapp ist, obwohl das Regal voll ist.

Ein zweiter, kleinerer Punkt aus demselben Alltag: Um die Nachlieferung einzubuchen, muss man im Standard die Summe eintragen, nicht die gelieferte Menge. Bei 36 vorhandenen und 10 gelieferten Stück tippt man 46 ein — die Addition macht der Kopf. Bei einem Wareneingang mit sechzig Positionen ist das sechzig Mal Kopfrechnen, und jeder Zahlendreher landet unbemerkt im Bestand.

Was am Markt geprüft wurde

Vor der Eigenentwicklung standen die verfügbaren Warenwirtschafts-Lösungen für Shopware auf dem Prüfstand. Das Ergebnis war zweigeteilt.

Den Wareneingang lösen sie. Man legt eine Bestellung an, bucht die gelieferte Menge, das System addiert. Dazu kommen Bestellvorschläge und Auswertungen. Alles solide.

Das eigentliche Problem lösten sie nicht. Die Anforderung war, eine Reservierung wahlweise gegen einen künftigen Wareneingang zu buchen statt gegen den heutigen Bestand — immer dann, wenn der Liefertermin nach dem Wareneingang liegt. Diese Verknüpfung von Bestellung, Liefertermin und Zulauf ließ sich nicht abbilden.

Damit war die Rechnung einfach: Übrig blieb der Komfort beim Einbuchen. Der ist etwas wert, aber nicht den Preis eines Warenwirtschaftssystems — dafür rechnet man auch weiterhin 36 plus 10 im Kopf. Also wurde es selbst gebaut.

Hinweis: Diese Einschätzung bezieht sich auf den damaligen Prüfstand. Ob einzelne Anbieter die Terminlogik inzwischen abbilden, ist nicht geprüft.

Drei Bestände statt einem

Der Kern der Lösung ist, die eine Zahl in drei zu zerlegen — und für jede Frage die richtige zu benutzen:

Erst mit dieser Trennung wird die Frage überhaupt beantwortbar, die im Handel zählt: nicht „wie viel habe ich", sondern „wie viel kann ich zusagen — und für welchen Tag".

ATP: Reservierung gegen den Zulauf

ATP steht für Available to Promise — die Menge, die man einem Kunden verbindlich zusagen kann, bezogen auf einen bestimmten Tag. Die Regel dahinter ist schlicht:

Liegt der Liefertermin einer Bestellung nach einem eingeplanten Wareneingang, wird sie gegen diesen Zulauf reserviert — nicht gegen den heutigen Bestand.

Damit sieht dieselbe Woche so aus:

Der Unterschied steht in der zweiten Zeile: 36 statt 28. Die acht reservierten Stück hängen am Mittwochs-Zulauf, nicht am heutigen Regal. Zwei Tage lang bleiben zehn Stück verkäuflich, die vorher blockiert waren — bei jedem Artikel, in jeder Woche, in der eine Nachlieferung zwischen Bestellung und Liefertag fällt.

Dasselbe Prinzip trägt bei Abonnements: Eine Lieferung, die in drei Wochen fällig ist, muss den heutigen Bestand nicht anfassen. Sie wird als Schattenbestellung geführt und gegen den Zulauf geplant, der bis dahin eintrifft.

Was sich im Alltag geändert hat

• Der Laden kann bedienen. Wer über POS im Geschäft verkauft, greift auf denselben Bestand zu. Solange Terminbestellungen den verfügbaren Bestand blockieren, steht die Kasse ohne Ware da, obwohl das Regal voll ist.
• Kein negativer Bestand mehr. Die verbreitete Notlösung lautet: Überverkauf zulassen und hoffen, dass die Nachlieferung rechtzeitig kommt. Das funktioniert, bis es einmal nicht funktioniert — und dann trifft es die Kunden, die am längsten gewartet haben.
• Der Wareneingang ist ein Vorgang. Gebucht wird die gelieferte Menge, nicht die neue Summe. Das Kopfrechnen entfällt, und jede Buchung bleibt nachvollziehbar.
• Einkauf wird planbar. Wer Zulauf und Reservierungen getrennt führt, sieht, welcher Artikel wann knapp wird — statt es am leeren Regal zu merken.

Häufige Fragen

Was ist der Unterschied zwischen Lagerbestand und verfügbarem Bestand?

Der Lagerbestand ist die Menge, die physisch vorhanden ist. Der verfügbare Bestand ist die Menge, die einem neuen Kunden noch zugesagt werden kann — also der Lagerbestand abzüglich dessen, was durch offene Bestellungen bereits versprochen ist. Shopware führt im Standard nur eine Zahl, die beides gleichzeitig darstellen soll.

Was bedeutet ATP?

ATP steht für Available to Promise: die Menge, die zu einem bestimmten Termin verbindlich zusagbar ist. Sie berücksichtigt neben dem heutigen Bestand auch eingeplante Wareneingänge und bereits vergebene Reservierungen.

Brauche ich das, wenn ich sofort versende?

Vermutlich nicht. Wer nach Bestelleingang direkt kommissioniert und versendet, hat keine Lücke, in die ein Wareneingang fallen könnte. Der Nutzen entsteht mit Lieferterminen, Abos, Vorbestellungen und langen Beschaffungszeiten.

Was passiert, wenn der Zulauf nicht kommt?

Die Reservierung hängt am Zulauf und wird sichtbar, sobald dieser überfällig ist. Statt eines stillen Überverkaufs entsteht eine Warnung, die man bearbeiten kann — Termin verschieben, Kunden informieren oder aus dem physischen Bestand decken.

Funktioniert das auch bei Varianten?

Ja. Bestände, Reservierungen und Zuläufe werden je Artikelnummer geführt, Varianten also getrennt.

Ersetzt das ein vollwertiges ERP-System?

Nein, und das ist auch nicht das Ziel. Es löst die Bestandsführung für einen Shopware-Shop mit eigener Auslieferung. Wer Produktion, Mehrmandantenfähigkeit oder komplexe Zollabwicklung braucht, ist mit einem eigenständigen ERP besser bedient.