Bestand ist keine Zahl.

Ein Shop zeigt häufig eine einfache Aussage: verfügbar, nicht verfügbar oder „noch 3 Stück". Im Hintergrund ist Bestand jedoch selten eine einzelne Zahl.

Ein Unternehmen kann 100 Einheiten physisch im Lager haben, davon 30 für offene Aufträge reservieren, 20 als Sicherheitsbestand zurückhalten und 15 einem anderen Vertriebskanal zuweisen. Zusätzlich sind 50 Einheiten bestellt, deren Wareneingang erst in einer Woche erwartet wird.

Für Commerce ist deshalb nicht der Lagerbestand entscheidend, sondern die Frage:

Die wichtigsten Bestandsbegriffe

Physischer Bestand

Tatsächlich im Lager vorhandene Menge.

Reservierter Bestand

Menge, die bereits offenen Aufträgen, Kommissionierung oder anderen Vorgängen zugeordnet ist.

Sicherheitsbestand

Menge, die bewusst nicht vollständig verkauft werden soll, um Schwankungen, Ausschuss oder andere Kanäle abzusichern.

Kanalbestand oder Kontingent

Menge, die einem bestimmten Markt, Shop, Händler oder Vertriebskanal zugewiesen ist.

Erwarteter Wareneingang

Menge, die bestellt oder produziert wurde und zu einem erwarteten Zeitpunkt verfügbar werden soll.

Available to Sell

Menge, die jetzt verkauft werden darf.

Available to Promise

Menge, die unter Berücksichtigung geplanter Zugänge für einen bestimmten Termin zugesagt werden kann.

Diese Werte können sich unterscheiden und müssen nicht alle im Shop sichtbar sein.

Verfügbarkeit ist eine Geschäftsregel

Eine vereinfachte Formel könnte lauten:

  physischer Bestand
- Reservierungen
- Sicherheitsbestand
- andere Kontingente
= aktuell verkaufbare Menge

In der Praxis kommen weitere Regeln hinzu:

• Mindestbestellmenge,
• Verpackungseinheit,
• Lagerort,
• Lieferregion,
• Priorität bestimmter Kundengruppen,
• Produktions- oder Beschaffungszeit,
• Cut-off-Zeit des Versanddienstleisters,
• geplante Inventur,
• Qualitäts- oder Freigabestatus.

Damit wird deutlich: Verfügbarkeit ist keine reine Datenreplikation. Sie ist Fachlogik.

Wann wird reserviert?

Der Zeitpunkt der Reservierung beeinflusst Überverkaufsrisiko und Nutzererlebnis.

Bei Warenkorbanlage

Vorteil: Bestand ist früh gesichert. Nachteil: liegengebliebene Warenkörbe blockieren Ware.

Beim Start des Checkouts

Vorteil: nur kaufnahe Nutzer reservieren. Nachteil: bei langen Checkouts muss die Reservierung ablaufen und erneuert werden.

Bei Zahlungsautorisierung

Vorteil: Reservierung erfolgt erst bei hoher Abschlusswahrscheinlichkeit. Nachteil: konkurrierende Käufer können denselben letzten Bestand sehen.

Bei Bestellung oder ERP-Annahme

Vorteil: klare operative Buchung. Nachteil: Shop kann zuvor mehr verkaufen, als tatsächlich verfügbar ist.

Häufig ist eine zeitlich begrenzte Soft Reservation sinnvoll, die bei erfolgreicher Bestellung in eine verbindliche Reservierung überführt und bei Abbruch freigegeben wird.

Mehrere Kanäle erhöhen die Komplexität

Wenn derselbe Bestand über Shop, Marktplätze, Vertrieb und stationären Handel verkauft wird, konkurrieren mehrere Systeme.

Mögliche Modelle:

Zentrale Echtzeitverfügbarkeit

Alle Kanäle fragen eine gemeinsame Bestandsinstanz ab und reservieren dort.

Kontingente je Kanal

Jeder Kanal erhält eine zugewiesene Menge. Das reduziert Laufzeitabhängigkeit, kann aber ungenutzten Bestand in einem Kanal blockieren.

Hybrides Modell

Grundkontingente werden verteilt, bei Bedarf kann zusätzlicher Bestand zentral freigegeben werden.

Welche Variante passt, hängt von Volumen, Margen, Aktualitätsanforderung und technischer Landschaft ab.

Bestandskopien brauchen ein zulässiges Alter

Shopware hält Verfügbarkeitsinformationen häufig lokal, damit Listings, Suche und Checkout schnell reagieren. Diese Kopie ist nur so gut wie ihre Aktualität.

Für jede Bestandsinformation sollte definiert sein:

• Quelle,
• letzter Aktualisierungszeitpunkt,
• erwartetes Intervall,
• maximal zulässiges Alter,
• Verhalten bei Überschreitung,
• fachlicher Status bei Ausfall.

Mögliche Reaktionen auf veraltete Daten:

• weiterhin verkaufen,
• nur geringe Mengen zulassen,
• „Lieferzeit auf Anfrage" anzeigen,
• Bestellung in eine Prüfung leiten,
• Verkauf blockieren.

Ereignisse statt vollständiger Dauerimporte

Bei großen Sortimenten ist es ineffizient, permanent den gesamten Bestand zu importieren. Ereignis- oder deltaorientierte Updates übertragen nur relevante Änderungen.

Beispiele:

• Reservierung angelegt,
• Reservierung freigegeben,
• Wareneingang gebucht,
• Bestand korrigiert,
• Auftrag storniert,
• Kontingent geändert.

Damit diese Verarbeitung stabil bleibt, benötigt sie:

• eindeutige Ereignis-IDs,
• idempotente Verarbeitung,
• Reihenfolge- oder Versionslogik,
• Wiederholungsmechanismen,
• Abgleichsläufe als Sicherheitsnetz.

Ein regelmäßiger vollständiger Reconciliation-Lauf kann Abweichungen erkennen, auch wenn einzelne Ereignisse verloren gingen.

Lieferzeit ist mehr als Bestand

Ein Produkt ohne physischen Bestand kann trotzdem bestellbar sein, wenn Beschaffung oder Produktion zuverlässig planbar sind. Umgekehrt kann vorhandener Bestand wegen Qualitätsprüfung oder Transportzeit nicht sofort lieferbar sein.

Eine Lieferzusage kann berücksichtigen:

• aktueller Bestand,
• Lagerstandort,
• Bearbeitungszeit,
• erwarteter Zugang,
• Produktionskalender,
• Feiertage,
• Versandart,
• Zielland,
• Bestellzeitpunkt.

Die Oberfläche sollte diese Komplexität nicht vollständig ausbreiten, aber eine verlässliche und verständliche Aussage liefern.

Bestell-Snapshot und spätere Änderungen

Bei Abschluss einer Bestellung sollte gespeichert werden:

• zugesagte Menge,
• zugesagte Lieferzeit,
• verwendete Bestandsquelle,
• Reservierungs-ID,
• Zeitpunkt der Berechnung,
• relevante Regeln.

Verändert sich der Bestand später, bleibt nachvollziehbar, was dem Kunden ursprünglich zugesagt wurde.

Fachliches Monitoring

Neben API-Erreichbarkeit sind folgende Signale relevant:

• negative verfügbare Mengen,
• ungewöhnlich viele Reservierungen ohne Abschluss,
• Reservierungen über ihrer Ablaufzeit,
• Abweichung zwischen Shop und ERP,
• sprunghafte Bestandsänderungen,
• hohe Zahl nachträglich korrigierter Lieferzusagen,
• Überverkäufe,
• Produkte mit veraltetem Bestandszeitpunkt,
• Ereignisrückstau.

Diese Kennzahlen zeigen, ob der Bestandsprozess funktioniert – nicht nur, ob die Schnittstelle läuft.