Verfügbare Bestände im Onlineshop: So bestätigen Sie ATP

Verfügbare Bestände im Onlineshop sind mehr als die Warenmenge im Warenwirtschaftssystem. Für Käufer ist wichtig, welche Menge Sie tatsächlich als Bestellung annehmen können und wann Sie diese versenden. Dazu müssen Sie physischen Bestand, Reservierungen und Einschränkungen des Lagers aufeinander abstimmen und anschließend prüfen, ob ein konkreter Auftrag erfüllt werden kann.

Available-to-promise, kurz ATP, bezeichnet die Verfügbarkeit, die Sie einem Kunden zusagen können: unter Berücksichtigung der Bestände, erwarteter Zugänge und bereits angenommener Nachfrage. Es ist nicht der Name einer bestimmten, zwingend erforderlichen Software. Im Folgenden geht es um einen praktischen Ansatz zur Anbindung eines bestehenden Shops an die Warenwirtschaft: welche Daten übertragen werden, wo Reservierungen bestätigt werden und wie aus einer ungefähren Prognose kein verbindlicher Liefertermin wird.

Verfügbare Bestände: vom tatsächlichen Lagerbestand zur Zusage

Die Warenwirtschaft beantwortet die Frage „Was ist im Lager?“, die vertriebliche Verfügbarkeit dagegen „Was kann diesem Käufer unter diesen Bedingungen verkauft werden?“. Ware kann physisch im Regal liegen, aber reserviert, beschädigt oder einem anderen Kanal zugeordnet sein. Auch die Summe aller Lagerbestände bedeutet nicht, dass die gesamte Charge von einem Standort aus versendet werden kann.

Unterscheiden Sie drei Ergebnisse der Integration. Das erste ist die Menge, die jetzt für einen neuen Verkauf freigegeben ist. Das zweite ist die künftige Verfügbarkeit zu einem bestimmten Datum. Das dritte ist eine bestätigte Zusage für einen konkreten Auftrag. Eine Bestandsanzeige auf der Produktseite erzeugt keine Reservierung, und die ATP-Berechnung allein bestätigt keine Buchung beim Transportdienstleister.

Die Dokumentation zu Microsoft Inventory Visibility unterscheidet zwischen weichen Reservierungen und der Prognose künftiger Verfügbarkeit. Eine Reservierung verringert die noch zusagbare Menge, ohne den physischen Bestand zu verändern. Dieses Prinzip ist für die Konzeption nützlich; die konkreten Felder und Regeln hängen jedoch von Ihrem System ab.

Klären Sie zuerst die Bedeutung der Daten, nicht die Austauschfrequenz

Legen Sie fest, welches System für welche Kennzahl verantwortlich ist: Das ERP führt die Ressourcenbestände, das WMS steuert die Lagerabläufe und der Shop nimmt Onlinebestellungen an. Für jede Kennzahl muss eine maßgebliche Datenquelle festgelegt sein. Andernfalls zieht die Website eine Reservierung ab, die das ERP bereits berücksichtigt hat, oder gibt Ware wieder zum Verkauf frei, die nach einer Rückgabe noch nicht geprüft wurde.

Einheitliche Einheiten und Statuswerte

Der Austauschschlüssel muss Artikelnummer und Produktvariante, Lager sowie Verkaufseinheit eindeutig bestimmen. Wenn die Warenwirtschaft Stückzahlen übermittelt, die Website aber Kartons verkauft, brauchen Sie eine abgestimmte Umrechnung und Rundungsregel. Ein Set erfordert eine gesonderte Prüfung seiner Bestandteile: Die Verfügbarkeit des vollständigen Sets darf nicht mit dem Bestand seiner am häufigsten vorkommenden Komponente gleichgesetzt werden.

Eine Formel ohne doppelten Abzug

Für ein erstes Modell können Sie vom freigegebenen physischen Bestand ausgehen und überschneidungsfreie Reservierungen, Sperrmengen und einen Sicherheitspuffer abziehen. Das ist eine Diskussionsgrundlage, keine universelle Formel. Wenn die Quelle bereits den freien Bestand übermittelt, wäre ein erneuter Abzug seiner Bestandteile ein Fehler. Dokumentieren Sie gesondert, ob Sperren und Reservierungen dieselben Einheiten betreffen können.

Bestätigen Sie Reservierungen dort, wo über den Verkauf entschieden wird

Selbst eine aktuelle Produktseite schließt einen gleichzeitigen Kauf über einen anderen Kanal nicht aus. Deshalb muss die Warenreservierung Teil der Auftragsannahme sein: Das System prüft die Verfügbarkeit und schreibt die Reservierung in einem zusammenhängenden Vorgang fest. Die Abfolge „Bestand lesen, kurz warten, Auftrag erfassen“ lässt ein Zeitfenster für Konflikte offen.

Benennen Sie eine verantwortliche Komponente für Reservierungen: das bestehende Warenwirtschaftssystem oder einen separaten Dienst. Alle Kanäle müssen die gemeinsamen Zusagen berücksichtigen. Eine Reservierung ausschließlich auf der Website schützt nicht vor einem parallelen Verkauf durch einen Vertriebsmitarbeiter.

Adobe Commerce beschreibt Reservierungen als Zurückhalten einer Menge bis zum Versand oder zur Stornierung, nicht als sofortigen physischen Bestandsabgang. Das ist ein Beispiel für die Trennung von Zuständen, keine Konfigurationsanleitung für Drupal. In Ihrem Projekt müssen Sie den Reservierungszeitpunkt, die Gültigkeitsdauer und den Übergang zur Lagerabwicklung gesondert festlegen.

Wenn es konkret um die Auswahl eines zusätzlichen Systems geht, lesen Sie, wann ein Shop ein OMS benötigt. Hier geht es um die korrekte Verfügbarkeit und die Zusagen innerhalb der bestehenden Systemlandschaft.

Verbinden Sie Reservierung, Zahlung und Stornierung zu einem Prozess

Definieren Sie für jeden Übergang den Auslöser und das Ergebnis. Nach der Reservierung setzt der Shop die Zahlungsabwicklung nach dem vereinbarten Ablauf fort. Eine fehlgeschlagene Zahlung muss die Reservierung freigeben. Wird eine Zahlung erst nach Ablauf der Reservierung bestätigt, muss die Verfügbarkeit erneut geprüft werden.

Wiederholte Nachrichten und eine unbekannte Antwort

Eine API — die Schnittstelle zum Austausch zwischen Systemen — kann eine Antwort nicht rechtzeitig liefern, obwohl der Vorgang bereits ausgeführt wurde. Vor einer erneuten Reservierung muss das Ergebnis anhand der Anfragekennung geprüft werden. Eine wiederholte Nachricht mit demselben Schlüssel muss dasselbe Ergebnis zurückgeben, statt eine weitere Reservierung anzulegen. Diese Eigenschaft heißt Idempotenz; sie muss umgesetzt und geprüft werden und darf nicht einfach vorausgesetzt werden.

Die Microsoft-Dokumentation zu Reservierungen beschreibt deren Erstellung, Anpassung und Freigabe gesondert. Erstellen Sie für Ihre eigene Integration eine entsprechende Lebenszyklusübersicht. Prüfen Sie Teilstornierungen, Mengenänderungen und Teilsendungen, nicht nur den erfolgreichen Kauf eines einzelnen Produkts.

Eine Stornierung vor dem Versand hebt die entsprechende Verpflichtung auf, eine Rückgabe nach der Lieferung folgt jedoch einem anderen Ablauf. Allein eine Erstattung belegt nicht, dass die Ware wieder verkaufsfähig ist. Die zurückgegebene Einheit muss den Wareneingang und die erforderliche Zustandsprüfung durchlaufen. Website, Warenwirtschaft und Kundendienst müssen diese Regel einheitlich verstehen.

Machen Sie aus Verfügbarkeit eine ehrliche Kundenzusage

Das Versanddatum hängt nicht nur von der Menge ab. Benötigt werden das ausführende Lager, die Annahmeschlusszeit für Bestellungen, der Arbeitskalender, die Kommissionierkapazität und Regeln für die Aufteilung von Lieferungen. Die Zustellung wird gesondert unter Berücksichtigung des verfügbaren Transportdienstes hinzugerechnet. Setzen Sie das Datum der Paketübergabe nicht mit dem Empfangsdatum beim Käufer gleich.

ATP für ein künftiges Datum muss sich auf abgestimmte Zugänge und bereits angenommene Nachfrage stützen. Bezeichnen Sie einen geplanten Einkauf nicht als garantierten Bestand. Hat der Lieferant keinen Termin bestätigt, ist „Termin wird geklärt“ angemessener, als automatisch eine angenommene Frist zum heutigen Datum zu addieren. Legen Sie für kritische Aufträge eine manuelle Bestätigung durch eine verantwortliche Person fest.

Ein hypothetisches Szenario: Ein Teil der Charge liegt im örtlichen Lager, der Rest wird aus einem anderen erwartet. Bieten Sie den Versand in Teilen oder nach Zusammenstellung der gesamten Charge an. Die Angabe „auf Lager“ erklärt nicht den Unterschied bei Lieferzeiten und Versandkosten.

Speichern Sie im Auftrag die ursprünglich angezeigte Zusage sowie deren Berechnungsgrundlage: Lager, Verfügbarkeitsversion und Bestätigungszeitpunkt. Erfassen Sie einen neuen Prognosetermin separat. Wenn Sie das alte Datum einfach überschreiben, zeigt die Auswertung keine Verletzungen der ursprünglichen Vereinbarungen mehr. Eine Änderungsmitteilung sollte dem Kunden seine Handlungsmöglichkeiten erklären, statt nur die Verzögerung festzustellen.

Prüfen Sie die Integration vor dem Start auf Konflikte

Begrenzen Sie den Piloten auf eine Gruppe von Artikeln und Kanälen, beziehen Sie aber komplexe Szenarien ein. Halten Sie das erwartete Ergebnis im Shop, in der Warenwirtschaft und im Reservierungsdienst fest, damit die Teams Erfolg einheitlich bewerten.

1. Gleichen Sie Produktschlüssel, Einheiten und freigegebene Lager ab. Weisen Sie eine unbekannte Artikelnummer zurück, statt stillschweigend einen falschen Bestand anzulegen.
2. Starten Sie über verschiedene Kanäle parallele Bestellungen für die letzte verfügbare Menge. Stellen Sie sicher, dass das System keine unvereinbaren Reservierungen bestätigt.
3. Wiederholen Sie eine Anfrage nach dem Verlust der Antwort. Prüfen Sie, dass nur eine Verpflichtung besteht und diese anhand des ursprünglichen Schlüssels auffindbar ist.
4. Ändern Sie die Reihenfolge der Bestandsnachrichten. Eine ältere Version darf bereits verkaufte Ware nicht wieder verfügbar machen.
5. Prüfen Sie verspätete Zahlung, Teilstornierung und Versand. Jede Änderung muss die richtige Menge freigeben oder verbrauchen.
6. Unterbrechen Sie die Verbindung zur Quelle. Prüfen Sie das vereinbarte Shopverhalten, die Benachrichtigung des Verantwortlichen und die Wiederherstellung nach dem Ausfall.

Gleichen Sie nach den Tests Bestand, Reservierung und Erfüllungsstatus jedes Auftrags ab. Ein technischer Ausfall darf einen Käufer, der bereits bezahlt hat, nicht ohne verständlichen Status und Kontaktmöglichkeit für Hilfe zurücklassen.

Risiken und Kontrolle nach der Aktivierung

Die wichtigste Einschränkung ist die Qualität der tatsächlichen Lagerbestandsdaten. Eine Integration findet keinen verlorenen Karton und korrigiert keinen Fehler beim Wareneingang. Regelmäßige Bestandsabgleiche und eine verantwortliche Person für die Behebung von Abweichungen sind notwendig. Bei seltenen, manuell abgewickelten Verkäufen aus einem Lager kann ein einfacherer Austausch mit Bestätigung durch einen Vertriebsmitarbeiter genügen, sofern Käufern keine sofortige Reservierung zugesagt wird.

Vereinbaren Sie eine Überwachung der Datenaktualität: Erfassen Sie den Ereigniszeitpunkt in der Quelle getrennt vom Empfangszeitpunkt auf der Website. Eine erfolgreiche Verbindung beweist nicht, dass neue Änderungen eingegangen sind. Wird die zulässige Verzögerung überschritten, muss der Shop in einen festgelegten Modus wechseln: die Menge begrenzen, den verbindlichen Termin entfernen oder eine Anfrage zur Klärung entgegennehmen. Entscheidend sind die Kosten eines Fehlers, nicht die Bequemlichkeit des Entwicklers.

Überwachen Sie Austauschfehler, hängengebliebene Reservierungen und Verletzungen der ursprünglichen Zusage. Unterscheiden Sie die Ursachen: fehlende Ware, Verzögerungen bei der Kommissionierung oder bei der Zustellung. Legen Sie Grenzwerte anhand Ihres eigenen Prozesses fest, ohne fremde „Genauigkeitsnormen“ zu übernehmen.

Zeitplanung, Kostenbestandteile und Grenzen der ersten Phase

Die Zeitplanung hängt nicht allein von der Anzahl der Felder ab, sondern davon, ob die erforderlichen Vorgänge in den Systemen verfügbar sind. Die Arbeitsfolge lautet: Regeln abstimmen, Schnittstellen und Daten prüfen, Reservierungen und Austausch umsetzen, Konflikte testen, einen kontrollierten Piloten durchführen und erweitern. Der Zeitplan wird nach Prüfung des Zugangs zur Testumgebung und der Mitwirkung des Warenwirtschaftsanbieters geschätzt.

Gliedern Sie die Integrationskosten in Geschäftsanalyse, Stammdatenbereinigung, Austauschadapter, Verfügbarkeitsberechnung, Anpassungen am Bestellabschluss, Monitoring und Ausfalltests. Zu den Betriebskosten zählen Infrastruktur, mögliche Gebühren für externe Dienste, Support und Bestandsabgleiche. Schätzen Sie die Wiederherstellung nach einem Ausfall gesondert ab: Sie darf keine unbestimmte manuelle Aufgabe bleiben.

Beginnen Sie mit einem geprüften Verkauf des aktuellen Bestands und einem transparenten Verhalten im Fehlerfall. Ergänzen Sie Zugangsprognosen, sobald verlässliche Daten vorliegen. Das Ergebnis ist eine nachvollziehbare Entscheidung zu jedem Auftrag, nicht ein weiterer Zähler auf der Website.

Wenn Sie diese Regeln mit Ihrem Shop verbinden müssen, besprechen Sie mit GL.ua (Glyanets) die Entwicklung und Integration Ihres Websystems. Bereiten Sie eine Übersicht der Bestandsquellen, eine Liste der Vertriebskanäle und Beispiele für konfliktbehaftete Bestellungen vor: Das hilft, den Pilotumfang und die erforderlichen Arbeiten festzulegen, ohne die gesamte Warenwirtschaftslandschaft vorzeitig zu ersetzen.