Bestellung nach der ERP-Übergabe geändert: sauber nachziehen

Rund um Black Friday und Cyber Week bestellen viele Menschen in kurzer Zeit. Für 2025 wollte rund jede und jeder Zweite, nämlich 52 Prozent (Bitkom) der Internetnutzerinnen und -nutzer ab 16 Jahren, die reduzierten Preise nutzen, die allermeisten davon online. Wer in diesen Tagen schnell bestellt, bemerkt einen Fehler oft erst danach: eine alte Lieferadresse, eine falsche Größe, einen vergessenen Artikel. Die Änderungswünsche betreffen dann Bestellungen, die das ERP längst übernommen hat, und sie kommen in einer Phase, in der Lager und Kundenservice ohnehin ausgelastet sind.

Wie empfindlich das Thema Lieferung ist, zeigt dieselbe Befragung: Bei der Auswahl eines Online-Shops nennen 53 Prozent (Bitkom) der befragten Online-Shopper Versand und Lieferung sehr wichtig, knapp hinter den Zahlungsmöglichkeiten mit 54 Prozent (Bitkom). Eine Adressänderung, die im Shop bestätigt wurde, im Lager aber nicht angekommen ist, trifft genau diesen Punkt. Das Paket geht an die falsche Anschrift, und die Kundin hält eine Bestätigung in der Hand, die etwas anderes sagt.

Rechtlich ist eine Änderung nach Vertragsschluss kein Verwaltungsvorgang, sondern eine Vereinbarung. Zur Änderung des Inhalts eines Schuldverhältnisses ist ein Vertrag zwischen den Beteiligten erforderlich (§ 311 Abs. 1 BGB). Der Shop darf die Bestellung also nicht einseitig umschreiben, und der Wunsch der Kundin wird erst zur Änderung, wenn der Händler ihn annimmt. Ob der Vertrag zu diesem Zeitpunkt schon geschlossen ist, hängt von den eigenen Bedingungen ab: Die Bestätigung über den Zugang der Bestellung, die der Shop unverzüglich auf elektronischem Wege schicken muss (§ 312i Abs. 1 BGB), ist nicht automatisch schon die Annahme. Technisch folgt daraus in beiden Fällen dasselbe: Eine Änderung braucht eine Antwort. Sie kann angenommen oder abgelehnt werden, und beides muss bei der Kundin ankommen.

Hinzu kommt die Datenlage. Nach der Übergabe führen zwei Systeme dieselbe Bestellung. Der Shop kennt Warenkorb, Kundenkonto und Zahlung, das ERP kennt Auftrag, Reservierung, Kommissionierung und später Lieferschein und Rechnung. Welche Seite für welches Feld führend ist, beschreibt der Beitrag zu Datenkonflikten bei bidirektionaler Synchronisation. Hier geht es um den Sonderfall, dass sich der Inhalt einer bereits übergebenen Bestellung ändert, und um den Prozess, der diese Änderung in beide Systeme bringt, ohne dass eines von beiden etwas verliert.

Die wichtigste Grenze ist der Beginn der Kommissionierung. Bis dahin ist eine Änderung eine Korrektur am Auftrag. Danach ist sie ein Eingriff in einen laufenden Arbeitsgang: Ware liegt im Kommissionierwagen, ein Versandetikett ist vielleicht schon gedruckt, ein Paket steht womöglich an der Rampe. Eine Adressänderung, die jetzt noch durchgeht, erreicht das Paket nur, wenn jemand es im Lager wieder aufhält.

Den Zeitpunkt kennt nur das ERP oder das Lagerverwaltungssystem, der Shop sieht ihn von sich aus nicht. Im Shopware-Quellcode kennt der Lieferzustand die Werte open, shipped_partially, shipped, returned, returned_partially und cancelled, der Bestellzustand die Werte open, in_progress, completed und cancelled (Shopware-Quellcode). Einen eigenen Zustand für die Kommissionierung gibt es in diesem Standard nicht. Die Zustandsautomaten lassen sich zwar über die API anpassen (Shopware-Dokumentation), doch dann muss das ERP den Wechsel auch melden. Ohne Rückmeldung aus dem Lager steht eine Lieferung im Shop bis zum Versand auf open, auch wenn sie längst gepackt wird. Wie Aufträge und Statusmeldungen zwischen den Systemen laufen, beschreibt die Seite zur Warenwirtschaft-Anbindung.

Daraus folgt eine einfache Regel: Die Entscheidung, ob eine Änderung noch möglich ist, trifft das ERP, nicht der Shop. Der Shop fragt vor dem Speichern an, das ERP prüft den Auftragsstand und antwortet. Läuft die Kommissionierung schon, lehnt es ab. Für eine HTTP-Schnittstelle gibt es dafür einen passenden Statuscode: 409 (RFC 9110) bedeutet, dass die Anfrage wegen eines Konflikts mit dem aktuellen Zustand der Zielressource nicht ausgeführt werden konnte. Die Norm sieht dazu vor, dass der Server Angaben mitliefern soll, an denen sich die Ursache des Konflikts erkennen lässt (RFC 9110). Im Fall der Bestellung sind das der Auftragsstand und der Zeitpunkt, ab dem gesperrt ist.

Der vierte Punkt ist der, an dem Projekte in der Praxis hängen bleiben. Ist das ERP während der Bestellspitze langsam oder kurz nicht erreichbar, darf der Shop die Änderung nicht einfach selbst übernehmen. Er nimmt sie als Anfrage entgegen, zeigt sie im Kundenkonto als „in Prüfung“ an und wartet auf die Entscheidung. Wie sich ein Shop verhält, wenn das ERP ganz ausfällt, beschreibt der Beitrag zum Notbetrieb bei einem ERP-Ausfall.

Die naheliegende Lösung ist oft die schlechteste: die geänderte Bestellung einfach noch einmal exportieren. Je nach ERP-Anbindung passiert dann eines von drei Dingen. Das ERP legt einen zweiten Auftrag an, weil es die Bestellung als neu erkennt. Oder es lehnt den Import als Dublette ab, und die Änderung verschwindet still. Oder es überschreibt den bestehenden Auftrag vollständig und verliert dabei, was nur im ERP stand: Reservierungen, Lagerplatz, interne Vermerke und den Kommissionierstand.

Besser ist ein eigenes Ereignis, das nur die Änderung transportiert und sich auf den bestehenden Auftrag bezieht. Es enthält die Bestellnummer aus dem Shop und die Auftragsnummer im ERP, eine fortlaufende Änderungsnummer je Bestellung, den Stand, auf den sich die Änderung bezieht, die geänderten Felder mit altem und neuem Wert, die Quelle und den Zeitpunkt. Ein vereinfachtes Beispiel:

Drei Felder tragen die Sicherheit. Die eventId bleibt bei Wiederholungen gleich; so arbeitet auch Shopware bei Webhooks, deren eventId sich nicht ändert, wenn der Versand erneut versucht wird (Shopware-Dokumentation). Das ERP erkennt damit doppelte Zustellungen und verwirft sie, wie im Beitrag zu Idempotenz und Retry-Strategien beschrieben. Die changeNumber legt die Reihenfolge fest: Kommt Änderung drei vor Änderung zwei an, wartet das ERP oder fordert den fehlenden Stand nach. Und baseRevision nennt den Stand, auf den sich die Änderung bezieht.

Das letzte Feld folgt dem Prinzip bedingter Anfragen in HTTP. Ein Client kann Vorbedingungen an den aktuellen Zustand einer Ressource knüpfen und so verhindern, dass eine Methode auf einen inzwischen veränderten Stand angewendet wird; scheitert die Bedingung, antwortet der Server mit 412 (RFC 9110). Übertragen auf Bestellungen: Hat das ERP den Auftrag inzwischen selbst geändert, etwa weil eine Position nicht lieferbar ist, passt der Bezugsstand nicht mehr. Die Änderung aus dem Shop wird dann nicht blind darübergeschrieben, sondern neu bewertet.

Ob das Ereignis per Webhook, über eine Warteschlange oder über eine Middleware läuft, ist zweitrangig. Wichtig ist, dass es einen eigenen Typ hat und nicht als Bestellexport getarnt ist. Wie Ereignisse zwischen Shop und ERP gepuffert werden, beschreiben die Beiträge zu Webhooks und Polling und zur ereignisgesteuerten Architektur. Die Umsetzung selbst ist typische Arbeit für eine Middleware oder eine eigene API-Entwicklung.

Ein Storno vor dem Versand ist die weitreichendste Änderung und zugleich die einfachste, wenn sie richtig modelliert ist. Der Fehler, der in Schnittstellen regelmäßig auftaucht, ist das Löschen: Die Bestellung verschwindet im Shop oder im ERP, und die andere Seite erfährt davon nichts oder findet später einen Auftrag ohne Gegenstück.

Shopware führt das Storno als Zustand: Bestellung und Lieferung kennen jeweils den Zustand cancelled (Shopware-Quellcode). Bei einer Bestellung starten mindestens drei Zustandsautomaten, für Bestellung, Zahlung und Lieferung (Shopware-Dokumentation). Ein Storno ist deshalb ein Wechsel in diesen Automaten und kein Löschvorgang. Die Schnittstelle überträgt es genau so: als Statuswechsel mit Grund und Zeitpunkt, auf den das ERP mit dem Storno seines Auftrags antwortet.

Auch steuerlich ist Löschen der falsche Weg. Eine Buchung oder Aufzeichnung darf nicht so verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist (§ 146 Abs. 4 AO). Ein stornierter Auftrag bleibt darum mit Stornovermerk stehen. Ist schon eine Rechnung erzeugt, folgt ein Korrekturbeleg, statt die Rechnung zu löschen; Rechnungen und Korrekturbelege sind als Buchungsbelege acht Jahre aufzubewahren (§ 147 Abs. 3 AO). Welches System die Rechnung erzeugt und damit auch den Korrekturbeleg, klärt der Beitrag Rechnung aus Shop oder ERP.

Ein Storno auf Wunsch der Kundin ist außerdem vom Widerruf zu trennen. Verbraucher haben bei Fernabsatzverträgen in der Regel ein Widerrufsrecht, die Widerrufsfrist beträgt 14 Tage (§ 355 Abs. 2 BGB). Ein Händler, der ein Storno vor dem Versand ablehnt, kann die Ware deshalb ohnehin zurückbekommen, nur später und mit Hin- und Rücksendung. Ob ein Storno als Kulanz angenommen oder als Widerruf behandelt wird, ist eine Geschäftsentscheidung; technisch sollte die Schnittstelle beide Wege kennen. Den Widerruf als eigenen Datensatz beschreibt der Beitrag zum Widerrufsbutton im Shop.

Weil Shopware beim Zusammenführen ältere Versionen löscht, taugt die Versionierung nicht als Verlauf inhaltlicher Änderungen. Zustandswechsel hält Shopware zwar in einer eigenen Historie mit altem und neuem Zustand fest (Shopware-Quellcode), eine geänderte Adresse oder Menge steht dort aber nicht. Und weil das ERP meist nur den aktuellen Auftrag zeigt, bleibt dort oft nur ein Änderungsdatum stehen. Das Protokoll gehört deshalb in die Schnittstelle oder die Middleware, als Liste unveränderlicher Einträge je Bestellung. Ein Eintrag enthält:

Ein solches Protokoll erfüllt zwei Zwecke. Es macht Rückfragen beantwortbar, wenn eine Kundin wissen will, warum ihre Änderung nicht angekommen ist. Und es erfüllt die Anforderung, dass der ursprüngliche Inhalt einer Aufzeichnung feststellbar bleiben muss (§ 146 Abs. 4 AO). Wo die Schnittstelle in der Verfahrensdokumentation auftaucht, beschreibt der Beitrag zur GoBD-Verfahrensdokumentation für Schnittstellen.

Das Protokoll enthält Adressen und damit personenbezogene Daten. Es braucht darum eine festgelegte Speicherdauer, die sich an den Aufbewahrungspflichten orientiert, einen eingeschränkten Kreis von Lesenden und nicht mehr Felder als nötig. Für die Fehlersuche genügt meist die Kennung der Änderung; die vollständige Adresse muss nicht in jedem technischen Log stehen, wenn sie im Protokoll steht.