Die Antwort in Kürze
Für jede Datenart braucht eine ERP-Shop-Integration ein führendes System, eine Übertragungsrichtung und klare Fehlerregeln. Middleware lohnt sich besonders bei mehreren Shops, Marktplätzen oder Partnern, weil Mapping, Orchestrierung und Monitoring zentral verwaltet werden können.
Eine ERP-Shop-Integration ist ein Betriebsprozess mit klaren Datenverantwortungen
Die technische Verbindung zweier APIs ist nur der sichtbare Teil einer Integration. Vorher muss geklärt sein, welches System Artikel, Preise, Bestand, Kunden und Aufträge führt. Ohne diese Entscheidung entstehen Rückkopplungen, manuelle Überschreibungen und schwer erklärbare Unterschiede. Ein Datenobjekt braucht deshalb eine führende Quelle, definierte Empfänger und eine Regel für Korrekturen.
Im produktiven Betrieb zählen vor allem Ausnahmen. Teilstorno, Teillieferung, Rundungsdifferenz, ungültige Adresse, Dublette oder verzögerte Zahlung müssen nachvollziehbar verarbeitet werden. Für jeden Fall braucht es Status, Verantwortlichkeit und einen sicheren Wiederholungsweg. Eine Integration, die nur den idealen Auftrag überträgt, ist eine Demo – noch kein belastbarer Geschäftsprozess.
Zusätzlich empfiehlt sich ein regelmäßiger Abgleich unabhängig vom laufenden Nachrichtentransport. Dabei werden Auftragszahlen, Summen, Bestände und Versandstatus zwischen den Systemen verglichen. Solche Reconciliation-Läufe erkennen verlorene oder doppelte Vorgänge und schaffen eine zweite Sicherheitsebene. Monitoring wird damit nicht zur technischen Zusatzfunktion, sondern zur Voraussetzung für verlässlichen Commerce-Betrieb.
Abnahme einer ERP-Shop-Verbindung
- Führendes System je Datenobjekt
- Testkatalog für Sonder- und Fehlerfälle
- Protokollierung mit eindeutiger Vorgangsreferenz
- Regelmäßiger Mengen- und Statusabgleich
Warum eine Integration mehr als Datentransport ist
Technisch lassen sich viele Systeme per API, Webhook oder Datei verbinden. Die schwierigere Frage lautet, welche fachliche Bedeutung ein Datensatz auf beiden Seiten hat. Ein Auftrag kann im Shop bezahlt, im ERP reserviert, im Lager geteilt und beim Carrier teilweise zugestellt sein. Jeder Status braucht eine eindeutige Übersetzung.
Eine belastbare Integration modelliert Ereignisse, Regeln und Verantwortlichkeiten. Sie verhindert nicht jeden Fehler, sorgt aber dafür, dass Fehler sichtbar, einordenbar und wiederholbar lösbar sind.
Für jedes Datenobjekt ein führendes System festlegen
Artikelstamm, Marketingtext, Preis, Bestand, Kunde, Auftrag, Zahlung und Versandstatus können in unterschiedlichen Systemen entstehen. Ohne festgelegte Führung überschreiben Systeme einander oder erzeugen widersprüchliche Werte.
Eine Datenverantwortungsmatrix dokumentiert Quelle, Ziel, Richtung, Auslöser, Frequenz, Pflichtfelder und Konfliktregel. Sie wird von Fachbereich und Technik gemeinsam freigegeben.
- SKU, EAN, Varianten und Einheiten
- Titel, Beschreibungen, Kategorien und Medien
- Preise, Kundengruppen und Aktionen
- physischer, reservierter und verkaufbarer Bestand
- Kunden, Aufträge, Zahlungen und Steuern
- Lieferungen, Tracking, Storno und Retouren
Produktdaten und Varianten konsistent halten
Variantenmodelle unterscheiden sich zwischen ERP und Shop. Farbe und Größe können eigenständige Artikel, Varianten eines Masters oder freie Attribute sein. Das Mapping muss stabile Schlüssel verwenden und neue, geänderte und deaktivierte Produkte behandeln.
Bilder und Marketingtexte liegen häufig näher am Shop oder PIM, während SKU, EAN, Gewicht und Beschaffungsdaten aus dem ERP kommen. Die Integration darf diese Verantwortlichkeiten nicht durch einen pauschalen Vollabgleich verwischen.
Preise, Steuern und Aktionen beherrschbar abbilden
Preise hängen von Land, Währung, Kundengruppe, Steuer, Staffel, Gültigkeit und Kanal ab. Ein Feldtransfer reicht nur bei einfachen Modellen. Komplexe Regeln müssen im führenden System berechnet oder als klar begrenzte Logik in der Integrationsschicht umgesetzt werden.
Promotions, Gutscheine, Rundungen und Versandkosten werden mit realen Bestellungen getestet. Das ERP muss nachvollziehen können, wie der im Shop bezahlte Gesamtbetrag entstanden ist, ohne die Kalkulation stillschweigend neu zu erfinden.
Bestand ist eine Berechnung, keine Zahl
Der physische Bestand ist nicht automatisch online verkaufbar. Reservierungen, Qualitätsprüfung, Sicherheitsbestand, offene Retouren, Dropshipping und Kanalpuffer beeinflussen die verfügbare Menge. Die Formel muss fachlich dokumentiert sein.
Synchronisationsfrequenz richtet sich nach Abverkauf und Risiko. Webhooks können Änderungen schnell melden; regelmäßige Kontrollabgleiche erkennen verlorene Nachrichten. Beide Mechanismen ergänzen sich.
Aufträge vollständig und idempotent importieren
Ein Auftrag umfasst mehr als Positionen: Shop-ID, Kundenzuordnung, Adressen, Steuer, Währung, Rabatte, Zahlart, Versandservice und Marktplatzreferenzen. Pflichtfelder und Ersatzregeln werden vor dem Go-live abgestimmt.
Idempotenz verhindert doppelte Aufträge, wenn eine Nachricht erneut gesendet wird. Stabile externe Schlüssel und definierte Aktualisierungsregeln sind unverzichtbar. Ein bereits kommissionierter Auftrag darf nicht durch eine verspätete Shopänderung unkontrolliert überschrieben werden.
Versand, Storno und Retouren als Rückkanal
Nach dem Import beginnt der Rückfluss. ERP oder WMS melden Bearbeitung, Teilmengen, Pakete, Carrier und Tracking. Bei Teillieferungen muss klar sein, welches Paket welche Position enthält.
Storno und Retoure benötigen Zeitgrenzen und Zuständigkeiten. Vor Freigabe im Lager kann ein Auftrag eventuell automatisch gestoppt werden; danach braucht es einen kontrollierten Ausnahmeprozess. Erstattung, Wareneingang und Wiederverfügbarkeit sind getrennte Ereignisse.
API, Standardconnector oder Middleware?
Ein Standardconnector passt bei üblichen Prozessen und einem klar begrenzten Systempaar. Individuelle API-Integration bietet Freiheit, erhöht aber Entwicklungs- und Wartungsverantwortung. Middleware lohnt sich, wenn mehrere Kanäle, gemeinsame Regeln, Transformationen und zentrales Monitoring zusammenkommen.
Die Entscheidung sollte nicht nur den Startaufwand vergleichen. Updates, neue Felder, API-Änderungen, Support, Beobachtbarkeit und der Ausbau auf weitere Partner bestimmen die Gesamtkosten.
Monitoring und Betrieb von Anfang an entwerfen
Eine grüne Serveranzeige beweist nicht, dass alle Aufträge angekommen sind. Fachliches Monitoring prüft Mengen, Alter, Status und Plausibilität. Kritische Abweichungen lösen verständliche Meldungen mit Verantwortlichem und nächstem Schritt aus.
Logs benötigen Korrelation über Systeme hinweg. Wiederholungslogik, Dead-Letter-Fälle, manuelle Korrektur und Reprocessing werden getestet und dokumentiert.
- gesendete, empfangene und fehlerhafte Datensätze
- älteste unverarbeitete Nachricht
- Abgleich von Shop- und ERP-Aufträgen
- Bestandsabweichungen bei kritischen Artikeln
- Alarmierung mit Priorität und Besitzer
- erneuter Versand ohne Dubletten
Der Testkatalog für den Go-live
Der Standardauftrag ist nur der Anfang. Ein belastbarer Testkatalog umfasst Varianten, Gutscheine, Gastkunden, internationale Adressen, Nullbestand, Teilversand, Storno, Retoure, Zeitüberschreitung und doppelte Nachrichten.
Go-live-Kriterien verbinden technische und fachliche Abnahme. Außerdem braucht es Rückfallplan, Supportzeiten und kontrollierten Ramp-up. Ein begrenztes Sortiment kann die ersten Betriebstage absichern.
Zum Abschluss
Häufige Fragen zum Thema
Wie oft sollten Bestände synchronisiert werden?+
Abhängig von Abverkauf, Puffer, Kanalvorgaben und Schnittstelle. Ereignisbasierte Updates plus regelmäßiger Kontrollabgleich sind häufig sinnvoll.
Was kostet eine ERP-Shop-Integration?+
Der Aufwand hängt von Datenobjekten, Prozessabweichungen, Volumen, Systemversionen, Testfällen und Betriebsanforderungen ab.
Wann brauche ich Middleware?+
Besonders bei mehreren Shops, Marktplätzen, Logistik- oder EDI-Partnern und wenn Mapping, Regeln, Monitoring und Wiederholungen zentral verwaltet werden sollen.
Wie verhindert man doppelte Bestellungen?+
Durch stabile externe IDs, idempotente Verarbeitung, dokumentierte Update-Regeln und Tests mit wiederholt zugestellten Nachrichten.