B2B-Shop und ERP verbinden: Datenflüsse, Scope und Integrationsrisiken

Ein B2B-Shop wird nicht durch möglichst viele Schnittstellen belastbar. Entscheidend ist, dass Produktdaten, Preise, Verfügbarkeiten, Kundenkonditionen und Aufträge einen klaren Ursprung, eine definierte Richtung und einen prüfbaren Fehlerweg haben.

Warum B2B-Commerce andere Datenfragen stellt

Im B2B-Geschäft unterscheiden sich Sortimente, Preise, Mindestmengen, Lieferorte, Freigaben und Zahlungsbedingungen häufig nach Kunde oder Markt. Ein Storefront kann diese Regeln verständlich darstellen, sollte aber nicht unbemerkt zum zweiten ERP werden. Umgekehrt ist das ERP selten die beste Oberfläche für Produkterklärung, Suche oder Kaufentscheidung.

Die Architektur beginnt deshalb nicht mit einem Connector, sondern mit einer fachlichen Zuordnung: Welches System ist für welches Objekt führend, welche Informationen sind abgeleitet und welche dürfen Nutzer im Shop verändern?

Sieben Datenflüsse, die vor dem Build geklärt sein müssen

1. Produkte und Varianten: Identifikatoren, Beziehungen, Einheiten und Status brauchen über Systemgrenzen hinweg eine eindeutige Bedeutung.
2. Produktinhalte: Technische Stammdaten, Marketingtexte, Medien, Übersetzungen und Dokumente können unterschiedliche Eigentümer und Freigaben haben.
3. Preise und Konditionen: Listenpreise, kundenspezifische Preise, Rabatte, Währungen, Steuern und Gültigkeitszeiträume dürfen nicht zu einer scheinbar einfachen Zahl zusammenfallen.
4. Bestand und Lieferbarkeit: Physischer Bestand, reservierte Menge, erwarteter Zugang und angezeigtes Lieferfenster sind verschiedene Aussagen.
5. Kunden und Rollen: Organisation, Käufer, Kostenstellen, Lieferadressen und Freigaberechte müssen getrennt modelliert werden.
6. Warenkorb und Auftrag: Der Übergabepunkt bestimmt, wann aus einer Auswahl eine verbindliche Bestellung, eine Anfrage oder ein Angebot wird.
7. Status und Nachlauf: Auftragsstatus, Teillieferungen, Tracking, Rechnungen, Retouren und Stornos benötigen einen Rückkanal.

Ein belastbarer Integrationsvertrag

HTTP unterscheidet unter anderem sichere und idempotente Methoden. Für eine Geschäftsoperation reicht dieses Protokollmerkmal allein jedoch nicht: Ein erneut gesendeter Auftrag muss auf Anwendungsebene gegen doppelte Anlage geschützt und mit einer nachvollziehbaren Referenz quittiert werden.

Echtzeit ist eine fachliche Anforderung, kein Qualitätslabel

Nicht jeder Datenfluss muss synchron sein. Produkttexte können geplant publiziert werden, während kundenspezifische Verfügbarkeit vor einer verbindlichen Bestellung aktuell geprüft werden muss. Eine synchrone Kopplung erzeugt unmittelbare Abhängigkeit: Ist das ERP nicht erreichbar, kann auch die Kaufstrecke blockieren.

Die richtige Frage lautet deshalb nicht „Können wir Echtzeit?“, sondern: Welche Entscheidung darf mit welchem Datenalter getroffen werden, welcher Fallback ist verständlich und wann muss ein Vorgang sicher gestoppt werden?

Fail closed bei geschäftskritischen Unsicherheiten

Wenn ein Preis nicht eindeutig, eine Kundenzuordnung ungültig oder eine verbindliche Lieferzusage nicht prüfbar ist, sollte die Strecke keine scheinbar erfolgreiche Bestellung erzeugen. Ein kontrollierter Anfrageweg kann besser sein als falsche Verbindlichkeit. Weniger kritische Inhalte dürfen dagegen mit klar gekennzeichnetem letzten bekannten Stand weiterarbeiten.

Akzeptanztests entlang echter Geschäftsvorgänge

1. Ein neues oder geändertes Produkt erscheint mit korrekter Identität, Einheit, Sprache und Status.
2. Kundenspezifische Preise und Berechtigungen werden nur dem richtigen Konto zugeordnet.
3. Eine Bestellung wird genau einmal angelegt und erhält eine referenzierbare Bestätigung.
4. Teilfehler bleiben sichtbar; verworfene Datensätze verschwinden nicht unbemerkt.
5. Wiederholungen nach Timeout erzeugen weder Doppelauftrag noch widersprüchlichen Status.
6. Geplante Wartung und Ausfall eines Systems führen in einen dokumentierten, verständlichen Zustand.
7. Monitoring erkennt fachliche Abweichungen, nicht nur technische Erreichbarkeit.

Scope vor Plattform

HEAVY CAMPAIGNS hat B2B-Websites, E-Commerce-Systeme und Integrationen mit ERP, CRM und spezialisierter Software für unterschiedliche Branchen geplant, entwickelt, relauncht, betrieben und optimiert. Diese Erfahrung ersetzt keine Systemanalyse. Sie hilft, Produktmodell, Datenverantwortung, Fehlerfälle, Sicherheit, Migration und Betrieb vor der Plattformentscheidung sichtbar zu machen.

Primärquellen und Aussagegrenzen

• RFC 9110: HTTP Semantics – sichere und idempotente Methoden sowie Protokollsemantik.
• OWASP API Security Top 10 – 2023 – typische Risiken bei Autorisierung, Ressourcenverbrauch, Konfiguration und API-Inventar.
• GS1: Global Trade Item Number – standardisierte Identifikation von Handelsartikeln.

Der Beitrag beschreibt ein Planungs- und Delivery-Modell. Er bestätigt keine Kompatibilität mit einem konkreten ERP oder Shopsystem und verspricht keine Echtzeitfähigkeit, Fehlerfreiheit oder wirtschaftliche Wirkung ohne projektspezifische Prüfung.