Das klingt trocken. Im Betrieb spart genau diese Disziplin die meisten Eskalationen.
Ein Punkt wird fast immer zu spät geklärt: die Versionierung von Mapping-Regeln. Sobald Preislogik, Steuerbehandlung oder Variantenstruktur geändert werden, muss nachvollziehbar bleiben, nach welcher Regel ein Auftrag importiert wurde. Ohne diese Spur wird jede spätere Fehleranalyse zur Rekonstruktion aus Logdateien und Einzelwissen.
Wo Shop-Anbindungen im Betrieb wirklich scheitern
Die meisten Integrationen brechen nicht beim ersten Export, sondern in Randfällen. Deshalb sind hübsche Demo-Synchronisationen als Kaufargument fast wertlos.
Doppelte Aufträge entstehen oft durch wiederholte Webhooks oder verspätete Antworten. Wenn dieselbe externe Bestellnummer nicht als eindeutiger Schlüssel gespeichert wird, legt das ERP denselben Auftrag mehrfach an. Technisch ist die Gegenmaßnahme simpel: Idempotenz. Operativ wird sie erstaunlich oft vergessen. Für HTTP-Verarbeitung reichen die Grundlagen zu Statuscodes und Wiederholungen aus der HTTP-Dokumentation von MDN völlig aus.
Falsche B2B-Preise sind fast immer ein Prioritätsproblem. Der Shop zeigt einen Aktionspreis, das ERP erwartet eine individuelle Preisliste, zusätzlich greift ein Kundenrabatt. Ohne feste Regel wird der Auftrag entweder falsch importiert oder im Backoffice korrigiert. Beides kostet.
Ein konkretes Muster aus dem Betrieb: Im technischen Großhandel mit rund 8.000 Artikeln und zwei Verkaufskanälen war nicht der Erstimport das Problem, sondern die Preis- und Statuslogik. Die eigentliche Reibung lag nicht in der Lizenz, sondern in mehreren Abstimmungsrunden zu Varianten, Teilversand und B2B-Konditionen, bevor der Rollout überhaupt sauber freigegeben werden konnte.
Teilversand wird regelmäßig unterschätzt. Viele Shops können versandt oder nicht versandt, aber keinen echten Teilversand. Wenn das ERP eine Bestellung in zwei Lieferungen aufteilt, kippt der Shop-Status schnell in eine fachlich falsche Darstellung. Dann sieht der Kunde abgeschlossen, obwohl Positionen offen sind.
Storno nach Folgebeleg ist der nächste Klassiker. Ein Kunde storniert im Shop, während im ERP bereits kommissioniert oder fakturiert wurde. Wer hier bidirektional und blind synchronisiert, produziert Belegchaos. Die Regel muss hart sein: automatische Stornos nur bis zu einem definierten Prozesspunkt, danach manueller Prüffall.
Ein Muster, das in echten Integrationen ständig auftaucht: Nicht der Datenimport verursacht die meiste Reibung, sondern Reservierungen, Varianten und Statusübersetzung. Teams investieren gern zuerst in sichtbare Synchronisation. Die eigentlichen Kosten entstehen später in den unsichtbaren Ausnahmen.
Wenn diese Regeln fehlen, hilft kein schönes Frontend. Dann ist eine ERP-nahe Umsetzung meist sinnvoller als ein allgemeines Shop-Setup. Wer an dieser Stelle zu generisch einkauft, kauft oft doppelt.
Typische Randfälle, die vor dem Go-live getestet werden müssen
Viele Abnahmen sind zu freundlich. Es wird ein Artikel angelegt, eine Testbestellung importiert, ein Versandstatus zurückgeschrieben. Das beweist fast nichts. Eine belastbare API Integration für E-Commerce muss mit absichtlich unangenehmen Fällen geprüft werden.
- Bestellung mit Rabatt und Gutschein: Prüfen, ob Summen, Steuer und Positionswerte im ERP fachlich korrekt ankommen.
- Bestellung mit Firmenkunde: Prüfen, ob Debitor, Preisgruppe und Rechnungsadresse sauber zugeordnet werden.
- Teilweise lieferbare Bestellung: Prüfen, ob Reservierung, Teilversand und Restmenge konsistent bleiben.
- Storno nach Zahlungsfreigabe: Prüfen, bis zu welchem Prozesspunkt Automatik erlaubt ist.
- Wiederholter Webhook: Prüfen, ob der Auftrag exakt einmal angelegt wird.
- Bestandsänderung unter Last: Prüfen, ob neuere Werte nicht von älteren Updates überschrieben werden.
Wer diese Fälle nicht testet, verschiebt Qualitätssicherung in den Live-Betrieb. Das ist keine Agilität, sondern Nachlässigkeit.
Zusätzlich sollte mindestens ein Test mit absichtlich fehlerhaften Daten laufen. Eine unbekannte Variante, eine fehlende Steuerzuordnung oder eine ungültige Zahlungsart zeigt schneller als jede Demo, ob die Integration kontrolliert scheitert oder still falsche Daten erzeugt. Saubere Schnittstellenarchitektur erkennt man nicht daran, dass alles grün ist, sondern daran, dass Fehler geordnet behandelt werden.
Betriebsmodell, Monitoring und Fehlerbehandlung sind Teil der Integration
Eine Integration ist nicht fertig, wenn Daten fließen. Belastbar wird sie erst, wenn Fehler sichtbar, zuordenbar und reproduzierbar behandelt werden können. Gerade beim Bestandsabgleich zwischen ERP und Shop reicht ein stilles Scheitern über Nacht, um am nächsten Morgen falsche Verfügbarkeiten im Shop zu haben.
Mindestens drei Ebenen sollten überwacht werden: technische Zustellung, fachliche Validierung und zeitliche Verzögerung. Technische Zustellung meint, ob ein Ereignis überhaupt verarbeitet wurde. Fachliche Validierung prüft, ob etwa eine Bestellung wegen fehlender Steuerklasse oder unbekannter Variante zurückgestellt wurde. Zeitliche Verzögerung zeigt, ob ein Prozess zwar läuft, aber zu langsam ist, um operativ noch brauchbar zu sein.
Ein sauberes Monitoring braucht keine überladene Plattform. Schon ein kompaktes Dashboard mit Fehlertyp, Anzahl offener Vorgänge, ältestem Fehler und letzter erfolgreicher Synchronisation bringt mehr als zehn verstreute Logdateien. Für Teams mit mehreren Kanälen lohnt zusätzlich ein täglicher Abgleichbericht für Bestände, offene Aufträge und Preisabweichungen.
In Projekten mit wachsendem Volumen zeigt sich immer wieder derselbe Fehler: Es wird in die Erstintegration investiert, aber nicht in den Betrieb. Dann hängt die Stabilität an einer Person, die Logdateien lesen kann. Ausfälle, Vertretung und Fehleranalyse hängen dann an Einzelwissen statt an dokumentierten Prozessen. Genau dadurch steigen Betriebsrisiken, weil Störungen nicht reproduzierbar bearbeitet werden und jede Abwesenheit zur Eskalation werden kann.
Validierungsregeln vor dem Schreiben ins ERP
Gerade beim Auftragsimport aus dem Onlineshop sollten Daten nicht blind ins ERP geschrieben werden. Vor dem Anlegen eines Belegs sind Prüfungen nötig, die fachliche Schäden verhindern. Dazu gehören mindestens:
- Existiert jede SKU im ERP und ist sie verkaufbar?
- Ist die Steuerlogik vollständig, insbesondere bei abweichenden Lieferländern?
- Ist die Zahlungsart zulässig und korrekt auf ERP-Logik gemappt?
- Ist der Kunde eindeutig zuordenbar oder muss ein neuer Debitor angelegt werden?
- Ist die Bestellung idempotent und wurde nicht bereits verarbeitet?
Fehlt eine dieser Prüfungen, landet der Fehler später tiefer im Prozess, oft erst bei Versand oder Rechnung. Dann ist die Korrektur teurer, weil bereits Folgebelege oder Kundenkommunikation existieren.
Für anspruchsvollere Setups lohnt zusätzlich eine fachliche Vorprüfung gegen definierte Geschäftsregeln. Dazu gehört etwa, ob ein B2B-Kunde ohne gültige Preisgruppe bestellen darf, ob ein Auftrag mit negativer Marge blockiert werden soll oder ob bestimmte Zahlungsarten für bestimmte Länder ausgeschlossen sind. Solche Regeln gehören nicht in manuelle Nacharbeit, sondern in die Integrationslogik.
Worauf Sie vor der Entscheidung wirklich achten sollten
Die Kosten hängen seltener von der Artikelzahl ab als von der Zahl der Ausnahmen. Ein großer Katalog mit sauberen Stammdaten ist oft leichter integrierbar als ein kleiner Shop mit chaotischen Varianten, Sonderpreisen und manuellen Belegumwegen.
Vor der Entscheidung zwischen Konnektor, Middleware und Systemwechsel sollten vier Punkte geklärt sein: eindeutige Identifikatoren, Variantenmodell, Verfügbarkeitslogik und Preisquelle. Wenn einer dieser Punkte offen bleibt, verschieben Sie Aufwand nur in den Betrieb.
Die sinnvolle Reihenfolge ist klar. Zuerst Identifikatoren und Varianten. Danach Bestandslogik. Dann Auftragsimport mit Dublettenprüfung und Statusmapping. Content-Synchronisation, Bilder oder Marketingfelder kommen später. Viele Teams machen es umgekehrt, weil Bestellungen sichtbarer wirken. Das ist ein Fehler.
Für die Kaufentscheidung reicht am Ende ein nüchterner Filter: Bleiben Prozesse einfach und einkanalig, kann GT mit schlanker Anbindung wirtschaftlich sauber bleiben. Wachsen Kanäle, Preislogik und Ausnahmen, ist Middleware meist die vernünftigere Investition. Steht ein neues Setup mit Ausbauplänen an, ist nexo PRO oft die robustere Basis als ein später geflickter GT-Unterbau.
Die unbequeme Kaufempfehlung lautet deshalb: Wenn Sie heute schon wissen, dass B2B-Preislogik, mehrere Kanäle oder tiefe Prozessautomatisierung kommen, ist ein billiger Konnektor meist die falsche Entscheidung. Er spart am Anfang Budget und verbrennt es später im Betrieb. Darüber kann man streiten. In der Praxis ist genau das aber der häufigere Verlauf.
Entscheidungsrelevant ist am Ende nicht die niedrigste Einstiegssumme, sondern die Frage, ob Ihr Setup bei zwei oder mehr Kanälen, kundenspezifischen Preisen oder einer spürbaren Ausnahmequote stabil bleibt. Wenn Preislogik kanalabhängig ist, Teilversand vorkommt oder Bestände nicht nur aus einem simplen Lagerwert bestehen, sollte die Auswahl auf Architektur und Fehlerbehandlung fallen, nicht auf den billigsten Erstanschluss.
