ERP an Shopify anbinden: Datenhoheit, Muster, Betrieb

Datenhoheit heißt: Für jedes Objekt gibt es genau ein System, dessen Wert im Zweifel gilt. Ohne diese Festlegung schreiben beide Seiten dasselbe Feld, und der letzte Schreibvorgang gewinnt, nicht der richtige. Die meisten sogenannten Sync-Probleme sind in Wahrheit ungeklärte Zuständigkeiten und keine technischen Fehler.

Die Antwort fällt pro Objekt, nicht pro System. Ein ERP kann für Artikelstamm und Bestand führend sein und trotzdem nichts über Produktbeschreibungen sagen. Shopify kann für Aufträge führend sein und trotzdem keine Belegnummern vergeben, die in der Buchhaltung gelten. Beides gleichzeitig ist der Normalfall, nicht die Ausnahme.

Zwei Fragen entscheiden fast jeden Einzelfall: Wer legt das Objekt an, und wer korrigiert es, wenn etwas falsch ist. Wird eine Rückerstattung in der Buchhaltung gebucht, gehört sie ins ERP. Wird sie im Shopify-Admin ausgelöst, muss Shopify sie führen und das ERP folgt der Bewegung nach.

Wer ein Objekt anlegt, hat meist auch die Hoheit darüber. Artikel entstehen im Einkauf, also im ERP. Bestellungen entstehen im Checkout, also in Shopify. Kundenkonten entstehen an beiden Enden, deshalb ist genau dieses Objekt in fast jedem Projekt der Punkt, an dem die Diskussion beginnt.

Die zweite Frage ist die härtere: Wer korrigiert im Fehlerfall. Wenn die Buchhaltung eine falsche Rechnungsadresse im ERP ändert und diese Änderung nicht in Shopify ankommt, arbeitet der Shop weiter mit dem alten Stand. Wer korrigiert, muss auch schreiben dürfen, sonst bleibt die Korrektur folgenlos.

Bei geteilten Objekten hilft es, die Hoheit auf Feldebene zu schneiden statt auf Objektebene. Beim Kunden führt das ERP Debitorennummer, Zahlungsziel und Kreditlimit, Shopify führt Login, Newsletter-Zustimmung und die Adressen des Kontos. Beide Seiten schreiben ausschließlich ihre eigenen Felder und lassen die fremden unangetastet.

Vier Muster kommen praktisch vor: ein nativer Connector des ERP-Herstellers, eine iPaaS-Plattform, eine eigene Middleware und die direkte Kopplung über die APIs beider Seiten. Die Wahl hängt weniger am Budget als daran, wie weit Deine Prozesse vom Standard abweichen und wer die Anbindung nach dem Livegang betreibt.

Ein Connector ist der schnellste Weg, solange Deine Prozesse dem Standard entsprechen. Sobald kundenspezifische Preise, mehrere Lager oder eine eigene Auftragslogik dazukommen, endet dieser Standard. Dann lautet die eigentliche Frage, ob sich der Connector an dieser Stelle erweitern lässt oder ob Du ihn dort umgehen musst.

Eine Frage entscheidet häufiger als die Technik: Wer meldet sich am Montagmorgen, wenn seit Freitag keine Aufträge mehr im ERP angekommen sind. Wo darauf keine klare Antwort existiert, ist das Muster mit dem größten Eigenbauanteil meist das falsche, auch wenn es fachlich am besten passen würde.

Ereignisgesteuert heißt: Ein Vorgang löst sofort eine Übertragung aus, in der Regel über Webhooks. Das passt für alles, was schnell sein muss: eine Bestellung ins ERP, eine Bestandsänderung nach dem Verkauf. Der Preis dafür ist, dass Du verlorene und doppelt zugestellte Ereignisse selbst abfangen musst.

Intervallabgleiche laufen in festen Abständen und holen alles, was sich seit dem letzten Lauf geändert hat. Das ist robuster gegen Ausfälle und schont die API-Kontingente, kostet aber Aktualität. Für Artikelstamm und Preise reicht es fast immer, für Bestand bei knapper Ware oft nicht.

Der nächtliche Vollabgleich ist das Sicherheitsnetz. Er vergleicht beide Seiten vollständig und meldet, was tagsüber auseinandergelaufen ist. Ohne ihn merkt niemand, dass seit Wochen eine Handvoll Artikel einen falschen Bestand führt. Mit ihm ist die Abweichung morgens ein Report statt später eine Reklamation.

Jede Schnittstelle überträgt irgendwann dieselbe Nachricht zweimal. Ein Timeout, ein Neustart, oder ein erneut zugestellter Webhook lässt sich nicht verhindern, nur abfangen. Idempotenz heißt, dass der zweite Durchlauf zum selben Ergebnis führt wie der erste und keinen zweiten Auftrag im ERP anlegt.

Technisch trägt das ein fachlicher Schlüssel, der auf beiden Seiten gespeichert wird: die Shopify-Bestellnummer als Referenz am ERP-Auftrag, die ERP-Belegnummer als Metafeld an der Bestellung. Vor jedem Schreibvorgang wird geprüft, ob dieser Schlüssel bereits existiert. Erst wenn er fehlt, wird angelegt.

Wiederholläufe brauchen Abstand. Ein fehlgeschlagener Aufruf, der sofort und endlos wiederholt wird, verbrennt Dein API-Kontingent und verdeckt die eigentliche Ursache. Üblich sind wenige Versuche mit wachsendem Abstand; danach landet der Vorgang in einer sichtbaren Warteschlange für Fehlerfälle statt im Nichts.

Der gefährlichste Zustand einer Integration ist nicht der Absturz, sondern die Stille. Ein Prozess, der nichts mehr überträgt und dabei keinen Fehler wirft, fällt oft erst auf, wenn jemand reklamiert. Deshalb überwachst Du neben Fehlern auch das Ausbleiben erfolgreicher Übertragungen.

Fehler brauchen ein Ziel. Ein Vorgang, der nach allen Versuchen scheitert, gehört in eine sichtbare Warteschlange mit Nutzlast, Zeitpunkt und Fehlermeldung, nicht in eine Logzeile, die niemand liest. Aus dieser Warteschlange muss sich ein einzelner Vorgang erneut anstoßen lassen, ohne den ganzen Lauf zu wiederholen.

Nützlich ist die Trennung zwischen fachlichen und technischen Fehlern. Ein fehlendes Varianten-Mapping ist ein Datenproblem und braucht einen Menschen. Eine Zeitüberschreitung ist ein technisches Problem und löst sich meist beim nächsten Versuch. Wer beides in denselben Kanal kippt, ignoriert nach kurzer Zeit beides.

Die teuren Fehler sind selten exotisch. Sie entstehen fast immer daraus, dass ein Modell im ERP feiner oder gröber geschnitten ist als in Shopify und beim Mapping etwas verloren geht. Wer diese Stellen vor dem Bau benennt, spart sich die Suche danach im laufenden Betrieb.

Besonders unangenehm sind Fehler, die Geld bewegen. Eine doppelt ausgeführte Rückerstattung fällt niemandem auf außer der Buchhaltung im Monatsabschluss. Genau deshalb gehört jeder geldbewegende Vorgang hinter einen Schlüssel, der die zweite Ausführung blockiert, statt sich auf saubere Bedienung zu verlassen.

Die Reihenfolge folgt dem Risiko. Zuerst kommt, was ohne Rückwirkung auf Geld und Kunden bleibt, zuletzt das, was im Fehlerfall Buchungen erzeugt. So sammelst Du Vertrauen in die Datenqualität, bevor die Schnittstelle Vorgänge auslöst, die jemand von Hand rückgängig machen muss.

Nicht jede Marke braucht das volle Programm. Bei wenigen Bestellungen am Tag und einem überschaubaren Sortiment ist eine geordnete manuelle Übergabe oft günstiger als eine Anbindung, die betrieben werden will. Die Rechnung kippt, sobald doppelte Pflege Fehler erzeugt statt nur Zeit zu kosten.