Ecommerce von Ende zu Ende: Wie Produkte, Bestände, Zahlungen und Retouren durch die Systemlandschaft fließen

Ein Onlineshop ist selten ein einzelnes System. Was der Kunde als eine nahtlose Oberfläche wahrnimmt, ist im Betrieb eine komplexe Kette aus Datenquellen, Übergabepunkten und Statuswechseln. Produktdaten entstehen an einer Stelle, Bestände an einer zweiten, Zahlungen an einer dritten und der Versandstatus kommt aus einer vierten zurück. Wer den Ecommerce-Betrieb verstehen oder optimieren will, benötigt keine lexikalische Definition, sondern eine operative Landkarte: Welches System besitzt welches Datenobjekt, wohin fließt es und an welcher Stelle bricht die Kette, wenn Fehler auftreten.

Dieser Text zeichnet genau diese Landkarte. Er analysiert die sieben typischen Systemrollen, folgt dem Datenfluss vom Produkt bis zur Zustellung sowie dem Rückfluss von der Retoure bis zur Erstattung und benennt die kritischen Bruchstellen in der Praxis.

Die sieben Rollen in der Systemlandschaft

Die folgenden Bezeichnungen beschreiben funktionale Rollen, nicht zwingend separate Softwareprodukte. In kleinen Setups übernimmt ein Shopsystem oft drei dieser Rollen mit, in großen Enterprise-Umgebungen sind es sieben eigenständige Anwendungen mit eigenen Datenbanken.

Die entscheidende Spalte ist die der Datenhoheit. Ein Datenobjekt sollte genau ein führendes System haben, während alle anderen Systeme lediglich eine Kopie halten. Sobald zwei Systeme dasselbe Objekt gleichzeitig ändern dürfen, entstehen Synchronisationskonflikte, die kaum zuverlässig gelöst werden können.

Produktdaten: vom PIM in den Kanal

Der Vorwärtsfluss beginnt lange vor der ersten Bestellung. Ein Artikel entsteht kaufmännisch im ERP, meist als bloße Nummer mit Einkaufspreis, Steuerschlüssel und Lieferantenbezug. Verkaufsfähig wird er erst im PIM (Product Information Management): Hier kommen Attribute, Varianten, Texte, Bilder, Klassifikationen und Übersetzungen hinzu. Das Shopsystem konsumiert dieses Ergebnis, es erzeugt es nicht.

Der Übergabepunkt vom PIM zum Shop ist ein häufiger Fehlerherd. Drei Faktoren entscheiden über die Qualität:

1. Vollständigkeitsregeln: Welche Attribute müssen zwingend gefüllt sein, damit ein Artikel im Shop erscheint? Ohne diese Regeln landen unvollständige Datensätze im Frontend und werden dort manuell nachgepflegt, wodurch die Datenhoheit unbemerkt vom PIM zum Shop wandert.
2. Kanaldifferenzierung: Marktplätze fordern oft andere Pflichtfelder als der eigene Shop. Werden diese Unterschiede im Shop statt im PIM abgebildet, entsteht für jeden Kanal ein neues Datensilo.
3. Änderungsverfolgung: Erfolgt die Übertragung des gesamten Katalogs periodisch oder nur die Differenz? Vollübertragungen sind technisch einfacher und verdecken oft, welches System eine Änderung ausgelöst hat.

Zur modernen Produktlandkarte gehört auch die digitale Zugänglichkeit. Das Barrierefreiheitsstärkungsgesetz erfasst nach § 1 Absatz 3 auch Dienstleistungen im elektronischen Geschäftsverkehr; die konkreten Pflichten und Ausnahmen müssen anhand des jeweiligen Angebots geprüft werden (BFSG § 1). Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen, sind nach § 3 Absatz 3 BFSG grundsätzlich von den Anforderungen des Gesetzes ausgenommen (BFSG § 3). Operativ bedeutet das: Alternativtexte und strukturierte Attribute sind integrale Produktdaten und gehören ins PIM.

Bestände: Verfügbar ist nicht gleich vorhanden

Der Begriff Bestand führt oft zu Missverständnissen, da es drei verschiedene Kennzahlen gibt:

• Physischer Bestand: Liegt im WMS und beschreibt, was tatsächlich auf einem Lagerplatz steht.
• Buchhalterischer Bestand: Liegt im ERP und beschreibt, was bilanziert und bewertet ist.
• Verfügbarer Bestand: Dies ist eine Kalkulation: physischer Bestand minus reservierte Mengen, offene Aufträge und gesperrte Ware, gegebenenfalls plus erwartete Zugänge mit festem Termin.

Nur der verfügbare Bestand darf im Shop angezeigt werden. Wer den physischen Bestand synchronisiert, riskiert Überverkäufe, da Ware verkauft wird, die bereits einem anderen Auftrag zugeordnet ist. Die Reservierung ist daher der Kern der Bestandsführung: Sie entsteht im Moment der Bestellung und löst sich erst auf, wenn die Ware das Lager verlässt oder der Auftrag storniert wird.

Der Aktualisierungsweg verläuft meist vom WMS über ERP und OMS zum Shop. Dieser Prozess ist bewusst asymmetrisch: Bestandsminderungen müssen in Echtzeit durchschlagen, während Bestandserhöhungen eine kurze Verzögerung tolerieren können, um Fehlbestände im Shop zu vermeiden.

Kundendaten: Eine Person, mehrere Rollen

Kundendaten entstehen an verschiedenen Stellen: als Konto im Shop, als Debitor im ERP, als Kontakt im CRM, als Zahler beim PSP und als Empfängeradresse im WMS. Die Aufgabe besteht darin, diese Rollen einer Person zuzuordnen, ohne die Datensätze beliebig zu verschmelzen.

Der rechtliche Rahmen ist hier eine Designvorgabe. Artikel 5 DSGVO nennt unter anderem Rechtmäßigkeit, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung und Sicherheit als Grundsätze der Verarbeitung personenbezogener Daten (Artikel 5 DSGVO). Auf die Systemlandkarte übersetzt ergibt dies:

• Zweckbindung: Eine für den Versand erhobene Adresse darf nicht automatisch als Werbeadresse ins CRM fließen. Der Datentransfer benötigt ein explizites Einwilligungsfeld.
• Speicherbegrenzung: Löschfristen müssen in jedem System einzeln definiert sein, einschließlich aller Kopien in Suchindizes oder Exportdateien.
• Richtigkeit: Eine Adresskorrektur muss an einer zentralen Stelle erfolgen und von dort aus alle Kopien aktualisieren.

Ein praktischer Test ist die Auskunftsanfrage: Wenn nicht sofort benannt werden kann, in welchen Systemen die Daten einer Person liegen, ist die Landkarte lückenhaft.

Bestellung und Zahlung: Der Zusammenfluss der Datenströme

Im Checkout treffen alle Ströme aufeinander. Der Shop liefert Warenkorb, Adresse, Versandart und Zahlart, während der PSP (Payment Service Provider) die Transaktion steuert. Aus diesen Daten entsteht der Auftrag.

Zwei rechtliche Punkte prägen diesen Schritt. Ein Fernabsatzvertrag liegt nach § 312c BGB grundsätzlich vor, wenn Unternehmer und Verbraucher für Vertragsverhandlungen und Vertragsschluss ausschließlich Fernkommunikationsmittel verwenden (BGB § 312c). Zudem muss bei zahlungspflichtigen Verbraucherverträgen im elektronischen Geschäftsverkehr die Bestellsituation nach § 312j BGB bestimmte Informationen klar hervorheben und die Zahlungspflicht eindeutig kenntlich machen (BGB § 312j). Die Checkout-Seite ist somit ein Punkt, an dem die korrekte Anzeige der Auftragsdaten eine gesetzliche Pflicht erfüllt.

Der Zahlungsvorgang gliedert sich in zwei Schritte: die Autorisierung (Reservierung des Betrags) und die Belastung (Einzug des Geldes). Idealerweise liegt der Logistikprozess zwischen diesen Schritten. Wenn die Belastung erst beim Versand erfolgt, stimmen Teillieferungen und Stornos automatisch mit den Zahlungsdaten überein. Bei einer Belastung direkt beim Bestelleingang führen Abweichungen zu manuell aufwendigen Erstattungen.

Bei grenzüberschreitenden Verkäufen kommt die steuerliche Komponente hinzu. Das EU-One-Stop-Shop-Verfahren ermöglicht es Unternehmen, bestimmte grenzüberschreitende B2C-Umsätze zentral über einen Mitgliedstaat zu erklären und die Umsatzsteuer abzuführen (Europäische Kommission). Systemtechnisch bedeutet das: Der Auftrag muss Lieferland, Kundentyp und Steuerschlüssel je Position tragen und diese Werte unverändert an das ERP übergeben, da die steuerliche Meldung aus dem Beleg und nicht aus dem Shop erfolgt.

Auftragsorchestrierung, Kommissionierung und Versand

Nach dem Bestelleingang übernimmt das OMS (Order Management System). Es trifft die Entscheidung, aus welchem Bestand welche Position bedient wird, basierend auf Lagerorten, Lieferfähigkeit und Versandkosten. Das Ergebnis sind eine oder mehrere Lieferanweisungen an das WMS.

Das WMS führt die physische Arbeit aus: Kommissionierung, Verpackung und Labeldruck. Zurück fließen drei kritische Informationen:

1. Die tatsächlich versandte Menge (führt zur endgültigen Bestandsminderung).
2. Die Sendungsnummer (wird an den Kunden im Shop kommuniziert).
3. Der Versandzeitpunkt (löst die Belastung beim PSP und die Rechnung im ERP aus).

Der Versandstatus ist die Information, die aus einer Bestellung eine nachvollziehbare Lieferung macht und gleichzeitig die Fristenlauf sowie die kaufmännische Abrechnung startet.

Der Rückwärtsfluss: Retouren

Retouren sind kein Sonderfall, sondern der Prozess in umgekehrter Richtung. Sie decken jede Schwäche der Landkarte auf, da sie fast alle Systeme erneut berühren.

Der Auslöser ist oft der Widerruf. Die regelmäßige Widerrufsfrist beträgt nach § 355 BGB 14 Tage, sofern ein gesetzliches Widerrufsrecht besteht und keine Ausnahme greift (BGB § 355). Für die Systeme bedeutet dies, dass ein Auftrag auch nach dem Versand in einem offenen Zustand verbleiben muss.

Der Retourenfluss durchläuft vier Stationen:

1. Anmeldung: Der Kunde meldet die Rücksendung im Shop. Es entsteht ein Retourenvorgang mit Bezug auf die spezifische Auftragsposition.
2. Wareneingang: Das WMS erfasst die Ware und prüft den Zustand. Erst die Entscheidung über die Wiederverkaufsfähigkeit darf den verfügbaren Bestand wieder erhöhen.
3. Kaufmännische Buchung: Das ERP erzeugt die Gutschrift und korrigiert Umsatz, Steuer und Bestandswert.
4. Erstattung: Der PSP führt die Rückzahlung durch, idealerweise mit Referenz auf die ursprüngliche Transaktion.

Wo Systemlandschaften in der Praxis brechen

Über alle Stationen hinweg wiederholen sich bestimmte Fehlermuster:

• Doppelte Datenhoheit: Ein Attribut wird sowohl im PIM als auch im Shop gepflegt. Bei der nächsten Synchronisation wird eine der Änderungen überschrieben, ohne dass dies dokumentiert wird.
• Inkonsistente Statusmodelle: Der Begriff Offen bedeutet im Shop, im OMS und im ERP jeweils etwas anderes. Berichte, die diese Zustände aggregieren, führen so zu Fehlinterpretationen.
• Fehlende Idempotenz: Wenn dieselbe Nachricht zweimal zugestellt wird, entstehen zwei Aufträge oder doppelte Buchungen. Jede Schnittstelle benötigt einen fachlichen Schlüssel, damit Wiederholungen folgenlos bleiben.
• Einseitige Rückkanäle: Der Weg vom Shop zum Lager wird streng überwacht, der Weg zurück jedoch nicht. Verlorene Statusmeldungen fallen oft erst durch Kundenbeschwerden auf.
• Vernachlässigung von Edge-Cases: Teillieferungen, Stornos nach der Kommissionierung oder Ersatzartikel werden oft als Ausnahme behandelt, sind aber im Tagesgeschäft Normalität.

Die eigene Landkarte zeichnen

Um eine Ecommerce-Landschaft beherrschbar zu machen, empfiehlt sich eine Analyse-Tabelle mit vier Spalten: Datenobjekt, führendes System, konsumierende Systeme und Auslöser der Änderung. Aufgenommen werden sollten: Artikel, Preis, Bestand, Kunde, Einwilligung, Auftrag, Zahlung, Lieferung, Retoure und Gutschrift.

Für jedes Objekt muss die Frage beantwortet werden: Was passiert, wenn die Übertragung ausfällt? Bleibt der Zustand kurzzeitig konsistent, ist der Fluss belastbar. Führen Ausfälle sofort zu inkonsistenten Daten, muss entweder eine Wiederholungslogik mit fachlichem Schlüssel implementiert oder die Verantwortlichkeit auf ein einziges System zentralisiert werden.