Onlineshop an die Warenwirtschaft anbinden: was Arbeit macht

Welche Daten fließen zwischen Shop und Warenwirtschaft, und in welche Richtung?

Es sind sechs Datenarten, und sie fließen nicht alle in dieselbe Richtung: Artikel und Preise laufen aus der Warenwirtschaft in den Shop, Bestände ebenfalls, Aufträge und Kunden laufen vom Shop in die Warenwirtschaft, Belege und Versandinformationen wieder zurück in den Shop. Diese Aufteilung klingt banal, entscheidet aber über die gesamte Architektur, weil jede Richtung eine eigene Auslösung, eine eigene Fehlerbehandlung und einen eigenen Takt braucht.

In Vorgesprächen hören wir oft den Satz, man wolle die Systeme einfach synchron halten. Das ist kein Ziel, sondern eine Beschreibung des Problems. Synchron heißt in der Praxis: Für jedes einzelne Feld ist verabredet, wer es ändern darf, wie schnell die Änderung auf der anderen Seite ankommen muss und was passiert, wenn beide Seiten es gleichzeitig geändert haben. Ohne diese Verabredung entsteht kein Datenfluss, sondern eine Endlosschleife aus gegenseitigem Überschreiben.

Artikel und Katalog

Der Artikelstamm ist der Teil, der am schnellsten fertig aussieht und am längsten nachhallt. Technisch geht es um wenige Felder: Artikelnummer, EAN, Bezeichnung, Steuerklasse, Gewicht, Maße, Variantenzuordnung. Fachlich geht es um die Frage, welches System den Artikel überhaupt anlegen darf. JTL beschreibt den JTL-Connector als Schnittstelle für den bidirektionalen Austausch von Artikeln, Kategorien und Kundendaten zwischen JTL-Wawi und einem Shopsystem, mit fertigen Lösungen für Shopware 6, WooCommerce, Shopify und PrestaShop. Bidirektional bedeutet dort nicht, dass beide Seiten alles dürfen, sondern dass in beide Richtungen Daten wandern.

Variantenartikel sind der Punkt, an dem Modelle auseinanderlaufen. Eine Warenwirtschaft kennt oft einen Vaterartikel mit Merkmalen und daraus abgeleiteten Kindartikeln, ein Shop kennt ein Produkt mit Optionen. Solange die Merkmalskombinationen vollständig gepflegt sind, ist die Abbildung mechanisch. Sobald ein Kindartikel im Shop existiert, den es in der Warenwirtschaft nicht mehr gibt, oder umgekehrt eine Variante ohne Preis, hat der Abgleich einen Sonderfall, den ein Mensch entscheiden muss. Wir planen dafür von Anfang an eine Liste der Artikel ein, die nicht übertragbar sind, mit Grund und Verantwortlichem. Ohne diese Liste laufen solche Fälle still ins Nichts.

Marketingtexte, Bilder und Kategorien gehören nach unserer Erfahrung nicht in die Warenwirtschaft. Sie werden dort ungern gepflegt, sind schlecht versionierbar und blockieren jede Änderung am Shopdesign. Wer viele Artikel und viele Kanäle bedient, trennt die Katalogpflege sauber ab, entweder im Shop selbst oder in einem eigenen System für Produktinformationen; wie das aussieht, haben wir im Beitrag zu PIM und Dropshipping mit Shopify ausführlicher beschrieben.

Bestände

Bestände sind die einzige Datenart, bei der Verzögerung direkt Geld kostet. Deshalb bekommen sie einen eigenen, kurzen Takt und eine eigene Warteschlange. Die Zahl, die in den Shop gehört, ist selten der physische Lagerbestand. Sie ist der verfügbare Bestand, also physischer Bestand minus reservierte Mengen minus Sicherheitsbestand plus gegebenenfalls erwartete Zugänge mit Termin. Xentral arbeitet in diesem Sinne mit Reservierungen bei Auftragsfreigabe und bucht den Bestand erst mit dem Lieferschein aus. Das ist sinnvoll, verlangt aber eine klare Antwort auf die Frage, welche der Zahlen der Shop sehen soll.

Preise

Preise sind fachlich einfach und organisatorisch heikel. Die Warenwirtschaft führt den Listenpreis, der Shop führt die Aktion. Sobald jemand im Shopbackend einen Preis von Hand korrigiert, weil es schnell gehen muss, ist die Hoheit gebrochen und der nächste Abgleich überschreibt die Korrektur. Diese eine Situation erklärt einen großen Teil der Anrufe, die mit dem Satz beginnen, die Schnittstelle habe Preise kaputt gemacht. Sie hat getan, was verabredet war.

Bei mehreren Ländern oder Währungen wächst die Preislogik schneller als erwartet. Runden, Bruttopreisstellen, länderspezifische Steuersätze und eigene Preislisten je Markt gehören vor der ersten Zeile Code geklärt. Für Shopify haben wir die Architekturfragen dazu im Beitrag zu Multishop-Setups zusammengestellt.

Aufträge, Kunden und Belege

Der Auftrag ist der einzige Datensatz, der im Shop entsteht und in der Warenwirtschaft zur Wahrheit wird. Ab dem Moment der Übernahme führt die Warenwirtschaft den Vorgang, der Shop zeigt nur noch Status an. Genau an dieser Übergabe entstehen die Felder, die niemand vorher auf dem Zettel hat: Zahlart und Zahlungsstatus, Versandart und Versandkosten, Steuerkennzeichen je Position, Rabatte auf Positions- und auf Auftragsebene, Gutscheine, Kundenkommentare, Wunschtermine, abweichende Lieferadresse, USt-IdNr bei Geschäftskunden. Für jedes dieser Felder braucht es ein Ziel im Zielsystem oder eine bewusste Entscheidung, es fallen zu lassen.

Warum muss die Richtung der Wahrheit je Feld festgelegt werden?

Weil zwei Systeme dasselbe Feld nur dann gemeinsam führen können, wenn eine Regel entscheidet, wessen Wert gewinnt, und diese Regel nur feldweise sinnvoll formuliert werden kann. Auf Ebene ganzer Datensätze funktioniert es nicht: Ein Artikel hat Felder, die eindeutig ins Lager gehören, und Felder, die eindeutig in die Redaktion gehören. Wer die Hoheit auf Satzebene vergibt, erzwingt Kompromisse, die im Alltag unterlaufen werden.

In der Umsetzung ist die Feldhoheit eine Tabelle, keine Philosophie. Sie hat vier Spalten: Feld, führendes System, Übertragungsrichtung, Verhalten bei Konflikt. Diese Tabelle wird mit dem Kunden zusammen gefüllt, sie wird abgenommen, und sie ist später die Grundlage jeder Fehleranalyse. Wenn ein Wert im Shop anders steht als in der Warenwirtschaft, gibt es nur zwei Möglichkeiten: entweder die Übertragung ist gescheitert, oder jemand hat gegen die Hoheit gearbeitet. Beides ist eine klare Aussage. Ohne die Tabelle ist es Meinungssache.

Ohne verabredete Feldhoheit ist eine Schnittstelle kein Datenfluss, sondern ein Wettlauf zwischen zwei Systemen, die sich abwechselnd überschreiben.

Ein Sonderfall verdient eine eigene Zeile: die Artikelnummer. Sie ist der Schlüssel, über den beide Seiten sich verstehen, und sie darf sich nie ändern. Wer sie im Shop als sprechende Nummer pflegt und im Lager als technische Nummer, braucht eine Zuordnungstabelle, und die muss irgendwo leben, gepflegt werden und Konflikte melden können. Wir legen diese Zuordnung bewusst in die Middleware oder in ein Feld im Shop, nie in eine Tabellenkalkulation.

Was macht den Bestandsabgleich so fehleranfällig?

Der Bestandsabgleich ist fehleranfällig, weil er der einzige Teil der Anbindung ist, bei dem zwei Systeme gleichzeitig dieselbe endliche Ressource verplanen und keines von beiden auf das andere wartet. Der Shop verkauft weiter, während das Lager pickt, und jede Übertragung beschreibt einen Zustand, der beim Ankommen schon veraltet ist.

Überverkauf

Überverkauf entsteht in dem Zeitfenster zwischen zwei Bestandsläufen. Bei einem Artikel mit zwei Stück Restbestand und einem Abgleich alle 15 Minuten kann der Shop innerhalb dieser 15 Minuten fünf Stück verkaufen. Kein Übertragungsintervall löst das, es verkleinert nur die Wahrscheinlichkeit. Drei Mittel helfen wirklich: ein Sicherheitsbestand bei knappen Artikeln, ereignisgesteuerte Sofortmeldung bei jeder Bestandsänderung statt fester Intervalle, und ein Abgleich, der den erwarteten Vorwert mitschickt, sodass gleichzeitige Änderungen erkannt statt überschrieben werden.

Für den letzten Punkt gibt es auf Shopseite technische Unterstützung. Shopify dokumentiert für die Mutation inventorySetQuantities ein Vergleichsfeld compareQuantity und schreibt dazu, dass ein Verzicht auf diese Prüfung bei gleichzeitigen Anfragen zu falschen Bestandsmengen führen kann. Wer die Prüfung nutzt, bekommt bei einem Konflikt einen Fehler statt eines stillen Datenverlusts. Das ist genau die Sorte Fehler, die man haben will.

Reservierungen

Reservierungen sind der Grund, warum der physische Bestand die falsche Zahl ist. Ein Auftrag, der freigegeben aber noch nicht kommissioniert ist, bindet Ware. Xentral beschreibt genau diesen Ablauf, dort entstehen Reservierungen bei der Auftragsfreigabe und die Bestandsbuchung erfolgt mit dem Lieferschein. In der Anbindung muss also entschieden werden, ob der Shop den physischen oder den verfügbaren Bestand sieht. Die Antwort ist fast immer der verfügbare. Wer trotzdem den physischen Bestand überträgt, verkauft Ware, die längst einem anderen Auftrag gehört.

Teillieferungen, Stornos und Rücksendungen

Teillieferungen brechen die Annahme, dass ein Auftrag einen Belegstatus hat. Sobald von drei Positionen zwei versandt sind, braucht der Shop einen Status je Position und je Sendung, sonst zeigt er dem Kunden entweder offen oder abgeschlossen, und beides ist falsch. Shopify bildet das über Fulfillment-Objekte je Sendung ab und dokumentiert dafür einen eigenen Objektbereich für Aufträge und Auftragsabwicklung. WooCommerce kennt in der Standardinstallation dagegen nur einen Auftragsstatus, dort landen Teilsendungen in Zusatzfeldern oder in Erweiterungen. Wer Teillieferungen fährt, prüft diesen Punkt vor der Systemauswahl, nicht danach.

Stornos und Rücksendungen sind zwei verschiedene Dinge, die oft in einen Topf geworfen werden. Ein Storno passiert vor dem Versand und gibt reservierte Ware frei. Eine Rücksendung passiert nach dem Versand, erzeugt eine Gutschrift, führt Ware in den Bestand zurück oder eben nicht, wenn sie beschädigt ist, und berührt die Buchhaltung. Für die Anbindung heißt das: Der Rückweg braucht eigene Nachrichtenarten, eigene Statuswerte und die Entscheidung, ob eine Retoure den Shopbestand erhöht. Bei Ware, die zuerst geprüft wird, lautet die Antwort nein, und dann muss die Prüfstufe im Lager sichtbar sein.

Wie läuft der Auftragsabgleich technisch ab?

Der Auftragsabgleich läuft in zwei Stufen: Der Shop meldet einen neuen Auftrag ereignisgesteuert, und ein regelmäßiger Nachlauf holt alles, was diese Meldung verpasst hat. Nur diese Kombination ist belastbar, denn Ereignismeldungen kommen zuverlässig, aber nicht garantiert an.

Shopify formuliert das in den eigenen Empfehlungen deutlich: Die Zustellung von Webhooks ist nicht immer garantiert, und eine App kann Ereignisse aus verschiedenen Gründen verpassen. Empfohlen werden Abgleichläufe, die die Daten regelmäßig aktiv abrufen, sowie das Aussortieren doppelter Zustellungen über die Webhook-Kennung im Kopf der Anfrage. Für die Zustellung selbst nennt Shopify konkrete Zahlen: eine Sekunde Verbindungszeitüberschreitung, fünf Sekunden für die gesamte Anfrage, acht Wiederholungen über vier Stunden, und nach acht aufeinanderfolgenden Fehlversuchen wird ein per Admin-API angelegtes Abonnement automatisch gelöscht.

Diese fünf Sekunden sind der Grund, warum ein Webhook-Empfänger niemals selbst die Warenwirtschaft ansprechen darf. Er prüft die Signatur, legt die Nachricht in eine Warteschlange und antwortet. Alles andere passiert danach. Wer im Webhook synchron einen ERP-Aufruf macht, verliert Aufträge, sobald das ERP langsam wird, und verliert nach acht Fehlversuchen zusätzlich das Abonnement. WooCommerce arbeitet nach demselben Muster mit eigenen Webhooks und einer REST-API in der Version wc/v3, die Produkte, Aufträge und Kunden als JSON liefert.

Ein Punkt, der auf WooCommerce-Seite in älteren Projekten regelmäßig Ärger macht, ist die Auftragsspeicherung. Seit WooCommerce 8.2 vom Oktober 2023 ist die High-Performance Order Storage offiziell freigegeben und für neue Installationen standardmäßig aktiv, Aufträge liegen dann in eigenen Tabellen statt in den WordPress-Beitragstabellen. Erweiterungen, die direkt auf die alten Tabellen zugreifen, arbeiten damit auf veralteten Daten, sobald der Kompatibilitätsmodus abgeschaltet wird. Bei jeder Übernahme eines bestehenden Shops gehört dieser Schalter auf die Prüfliste.

Statusmodell und Übersetzungstabellen

Zwischen Shopstatus und ERP-Status liegt immer eine Übersetzung, und diese Übersetzung ist Projektarbeit, nicht Konfiguration. Ein Shop kennt Zustände wie offen, bezahlt, in Bearbeitung, versandt, abgeschlossen, storniert, erstattet. Eine Warenwirtschaft kennt Auftragsstatus, Lieferstatus, Rechnungsstatus und Zahlungsstatus getrennt. Die Abbildung ist selten eins zu eins. Dasselbe gilt für Zahlarten, Versandarten, Steuerschlüssel und Länderkennzeichen. Diese vier Übersetzungstabellen sind erfahrungsgemäß der unterschätzte Aufwandsposten jeder Anbindung, weil sie mit jeder neuen Zahlart und jedem neuen Versanddienstleister wachsen und niemand sie pflegt, solange sie unsichtbar in Code stehen.

Wie kommen Zahlungen und Buchhaltung zusammen?

Zahlungen und Buchhaltung kommen zusammen, indem drei getrennte Größen abgeglichen werden: der Auftragswert im Shop, die Zahlung beim Dienstleister und die Auszahlung auf dem Bankkonto, wobei letztere um Gebühren gekürzt und meist gesammelt erfolgt. Wer nur Auftrag und Bankeingang vergleicht, findet nie eine passende Zahl.

Der klassische Bruch liegt bei den Gebühren. Ein Kunde zahlt 119,00 Euro, auf dem Konto landen als Teil einer Sammelauszahlung 116,53 Euro, und die Differenz ist Aufwand, der als eigene Buchung mit eigenem Steuerschlüssel gehört. Stripe stellt dafür die Arten von Kontobewegungen dokumentiert bereit, von der Zahlung über die Gebühr bis zur Auszahlung und zur Rückbuchung. Ohne diesen Bericht ist ein Zahlungsabgleich Handarbeit. Mit ihm ist er eine Zuordnung über Referenznummern, die man automatisieren kann.

Skonti und Teilzahlungen

Skonto ist im Shopgeschäft selten und im Geschäftskundengeschäft normal. Der Vorgang ist unangenehm, weil die Zahlung nicht zur Rechnung passt und die Differenz kein Fehler ist. Zwei Millionen Cent Restbeträge in der Offene-Posten-Liste sind kein technisches Problem, sondern ein Prozessproblem: Es fehlt die Regel, bis zu welcher Differenz automatisch ausgeglichen und ab welcher Differenz nachgefasst wird. Diese Regel gehört in die Anbindung, nicht in die Geduld eines Menschen in der Buchhaltung. Dasselbe gilt für Teilzahlungen und für Überzahlungen.

DATEV und der Weg in die Finanzbuchhaltung

Für den Weg in die Finanzbuchhaltung gibt es zwei Wege, und die Wahl ist eine Entscheidung des Steuerberaters, nicht der IT: Export im DATEV-Format als Datei oder Übergabe über einen DATEV-Datenservice. Das DATEV-Format ist im DATEV-Entwicklerportal beschrieben, mit einer Kopfzeile, die unter anderem Kennung, Formatversion, Beraternummer, Mandantennummer und den Beginn des Wirtschaftsjahres trägt, und einem Buchungsstapel, der je Zeile Umsatz, Soll-Haben-Kennzeichen, Konto, Gegenkonto, Buchungsschlüssel, Belegdatum, Belegfeld und Buchungstext führt. Ein Skontofeld ist ebenfalls vorgesehen. Für die programmatische Übergabe dokumentiert DATEV die Schnittstellenanforderungen für den Buchungsdatenservice getrennt.

Praktisch heißt das: Die Schnittstelle liefert keine Buchungen, sondern Belege mit Konten. Welche Erlöskonten, welche Steuerschlüssel, welche Debitorenkonten und wie Zahlungsdienstleister als Konten geführt werden, legt der Steuerberater fest. Wir fragen diese Zuordnung in Projekten vor der Umsetzung ab und lassen sie schriftlich bestätigen. Änderungen daran sind später teuer, weil bereits erzeugte Buchungsstapel im Zweifel korrigiert werden müssen.

Auf Seiten der Buchhaltungssysteme unterscheiden sich die Zugänge deutlich. Die Lexware API ist als REST-Schnittstelle mit Belegen, Rechnungen, Gutschriften, Kontakten, Zahlungen und Buchungskategorien dokumentiert und begrenzt Clients ausdrücklich auf zwei Anfragen pro Sekunde, darüber antwortet sie mit Code 429. Für Sage 100 liegen die Beschreibungen in der deutschen Onlinehilfe getrennt für Warenwirtschaft und Rechnungswesen. Wer mit solchen Grenzen plant, baut die Übergabe von Anfang an als Stapelverarbeitung und nicht als Einzelaufruf pro Beleg.

Was passiert bei einem Ausfall, und wie wird eine Schnittstelle wiederholbar?

Bei einem Ausfall darf nichts verloren gehen und nichts doppelt entstehen, und das erreicht man nur mit zwei Bausteinen: einer Warteschlange, die Nachrichten aufbewahrt, bis sie bestätigt sind, und Idempotenz, also der Eigenschaft, dass dieselbe Nachricht mehrfach verarbeitet dasselbe Ergebnis erzeugt wie einmal verarbeitet.

Der Unterschied zwischen einer Schnittstelle, die nachts anrufen lässt, und einer, die man vergisst, liegt fast vollständig in diesen zwei Punkten. Ein direkter Aufruf ohne Warteschlange bedeutet: Ist das Zielsystem für zwanzig Minuten nicht erreichbar, sind zwanzig Minuten Aufträge weg oder hängen im Fehlerprotokoll. Mit einer Warteschlange bedeutet es: Zwanzig Minuten Nachrichten stehen an und laufen danach durch. Die Warteschlange muss keine große Infrastruktur sein. In kleineren Projekten ist eine Tabelle in der Datenbank mit Status, Versuchszähler und nächstem Versuchszeitpunkt völlig ausreichend und deutlich leichter zu betreiben als ein zusätzlicher Dienst.

Eine Schnittstelle ohne Warteschlange ist eine Schnittstelle, die genau so lange funktioniert, wie beide Systeme gleichzeitig gesund sind.

Idempotenz braucht einen Schlüssel, an dem das Zielsystem einen Wiederholungsversuch erkennt. Stripe beschreibt das Prinzip präzise: Der Client erzeugt einen eindeutigen Schlüssel, der Server speichert Statuscode und Antwort des ersten Versuchs, spätere Anfragen mit demselben Schlüssel bekommen dasselbe Ergebnis zurück, und abweichende Parameter mit gleichem Schlüssel führen zu einem Fehler, um versehentliche Fehlnutzung zu verhindern. Schlüssel dürfen bis 255 Zeichen lang sein und werden nach mindestens 24 Stunden aus dem System entfernt. PayPal dokumentiert ein vergleichbares Verfahren für seine REST-Schnittstellen.

In Warenwirtschaften ohne eigenen Idempotenzmechanismus übernimmt die externe Auftragsnummer diese Rolle. Vor dem Anlegen wird geprüft, ob ein Auftrag mit dieser Shopnummer existiert. Das ist weniger elegant als ein Schlüssel im Kopf der Anfrage und in der Praxis vollkommen tragfähig, solange die Prüfung und die Anlage gegen gleichzeitige Läufe geschützt sind. Ohne diesen Schutz reicht ein doppelt gestarteter Abgleich, um jeden Auftrag zweimal anzulegen.

Wiederholungen, Ablage für Unzustellbares und Alarmierung

Wiederholungen brauchen wachsende Abstände, sonst hämmert die Schnittstelle ein schwaches Zielsystem in den Boden. Übliche Staffelung: nach einer Minute, nach fünf, nach fünfzehn, nach einer Stunde, dann stündlich. Nach einer festgelegten Zahl von Versuchen wandert die Nachricht in eine Ablage für Unzustellbares und löst eine Meldung aus. Diese Ablage muss ein Mensch ansehen können, mit dem vollständigen Inhalt der Nachricht und der Fehlermeldung. Eine Schnittstelle, die Fehler nur in eine Protokolldatei schreibt, hat keine Fehlerbehandlung, sondern eine Fehlerablage.

Zur Alarmierung gehören zwei Dinge, die gerne fehlen. Erstens eine Meldung, wenn nichts passiert: Kommen seit zwei Stunden keine Aufträge, obwohl sonst stündlich fünf kommen, ist das eine Störung, auch wenn kein Fehler geworfen wurde. Zweitens eine tägliche Kennzahl, die jemand liest, mit Zahl der übertragenen Aufträge, Zahl der Bestandsänderungen, Zahl der Fehlversuche und ältestem unbearbeiteten Vorgang. Wer diese Zahl täglich sieht, merkt Drift, bevor der Kunde sie merkt.

Die Ratenbegrenzungen der beteiligten Systeme gehören ebenfalls in die Warteschlangenlogik. Shopify weist für die GraphQL-Admin-API Punktbudgets je Sekunde nach Tarif zu, dokumentiert sind 100 Punkte pro Sekunde im Standardtarif, 200 bei Advanced, 1000 bei Plus und 2000 für Enterprise-Verträge. PlentyONE begrenzt lesende Aufrufe je Nutzer und Minute gestaffelt nach Vertrag, dokumentiert von 80 im Tarif Basic bis 280 im Tarif Plus, schreibende Aufrufe von 40 bis 120, und liefert bei Überschreitung einen Retry-After-Hinweis. Business Central nennt für OData je Umgebung 600 Anfragen pro Minute in der Produktion und 300 in der Sandbox, dazu Nutzerlimits über ein Zeitfenster von fünf Minuten, und antwortet bei Überschreitung mit 429. Eine Schnittstelle, die diese Codes nicht auswertet und nicht abwartet, produziert Datenlücken, sobald der Katalog wächst.

Wie viel Arbeit macht die Stammdatenpflege wirklich?

Die Stammdatenpflege macht mehr Arbeit als die Schnittstelle, und sie hört nie auf. In fast allen Projekten, die wir übernehmen, ist der technische Datenfluss nach wenigen Wochen stabil, und der Grund für anhaltende Reibung liegt in Artikeln ohne Gewicht, Kategorien ohne Zuordnung, Varianten ohne Preis und Kundendatensätzen, die es dreimal gibt.

Eine Anbindung deckt Datenqualität schonungslos auf. Ein Artikel ohne Gewicht funktioniert in der Warenwirtschaft jahrelang, weil jemand das Paket schätzt. Im Shop mit gewichtsabhängigen Versandkosten wird er zum Fehler. Ein Artikel mit falscher Steuerklasse fällt in der Warenwirtschaft nicht auf, in der Rechnung aus dem Shop schon. Es ist deshalb sinnvoll, vor der Anbindung eine Datenprüfung zu fahren und die Pflichtfelder festzuschreiben, die ein Artikel haben muss, um überhaupt in den Shop zu dürfen. Diese Prüfung ist eine der wenigen Aufgaben, die man vollständig automatisieren kann und die sofort Geld spart.

Zur Pflege gehört auch die Frage, wer sie tut. Eine Anbindung verschiebt Arbeit, sie beseitigt sie nicht. Wenn die Warenwirtschaft künftig Preise führt, muss dort jemand Preise pflegen können, mit Rechten, mit Vieraugenprinzip bei Aktionen und mit einer Möglichkeit, eine Änderung zeitgesteuert zu planen. Fehlt diese Fähigkeit im ERP, wird die Hoheit im Alltag unterlaufen, und dann ist die schönste Feldtabelle Papier. Wir prüfen diesen Punkt inzwischen früh, weil er häufiger über Erfolg entscheidet als die Wahl der Schnittstellentechnik.

• Pflichtfelder je Artikel schriftlich festlegen und maschinell prüfen, bevor Daten übertragen werden
• Doppelte Kunden vor der ersten Übertragung zusammenführen, nicht danach
• Eine Liste der nicht übertragbaren Artikel erzeugen und wöchentlich abarbeiten
• Einheiten, Gewichte, Maße und Zolltarifnummern früh vervollständigen, sie werden für Versand und Ausfuhr gebraucht
• Steuerklassen je Artikel prüfen, insbesondere bei Büchern, Lebensmitteln und Dienstleistungen
• Verantwortliche Person je Datenart benennen, nicht je System

Middleware oder Direktanbindung: was lohnt sich wann?

Eine Direktanbindung lohnt sich bei einem Shop, einem ERP und überschaubarer Sonderlogik, eine Middleware lohnt sich ab dem zweiten Kanal, ab dem ersten Systemwechsel im Blickfeld und immer dann, wenn Übersetzungs- und Feldlogik so umfangreich wird, dass sie eine eigene Stelle mit eigenem Protokoll braucht. Die Grenze liegt erfahrungsgemäß nicht bei der Datenmenge, sondern bei der Zahl der Sonderregeln.

Für eine Direktanbindung spricht die kürzere Kette. Weniger Teile, weniger Betrieb, weniger Kosten, klarere Fehlersuche. Dagegen spricht, dass die gesamte Logik in einem der beiden Systeme oder in einem kleinen eigenen Dienst landet und beim Wechsel des Shops oder des ERP mitgenommen werden muss. Fertige Konnektoren wie der JTL-Connector sind hier der Mittelweg, sie sind Direktanbindung mit gepflegter Logik, solange die eigene Anforderung in deren Modell passt. Sobald Sonderfelder, eigene Preislogik oder ein zweiter Marktplatz dazukommen, wird aus dem Konnektor ein Konnektor plus eigene Zusatzstrecke, und dann ist die Middleware oft die ehrlichere Antwort.

Für eine Middleware spricht, dass Übersetzungstabellen, Warteschlange, Wiederholungslogik, Protokoll und Feldhoheit an einer Stelle liegen und dort sichtbar sind. Sie ist außerdem der einzige Ort, an dem sich ein Systemwechsel sauber abfedern lässt: Wer den Shop tauscht, tauscht eine Seite der Middleware statt alles. Dagegen sprechen Betriebskosten, ein zusätzliches Stück Software, das aktuell gehalten werden muss, und die Versuchung, dort Geschäftslogik abzulegen, die in ein Fachsystem gehört.

Bei den Integrationsplattformen aus der Cloud gilt eine einfache Rechnung: Sie sparen Bauzeit und kosten laufend. Solange die Zahl der Vorgänge klein ist und die Logik in deren Bausteine passt, ist das ein guter Tausch. Bei sehr vielen Vorgängen oder bei Logik, die sich nicht in Bausteine fassen lässt, kippt die Rechnung. Wir rechnen in Angeboten beide Varianten über drei Jahre, weil die Entscheidung fast nie an den Bauaufwand hängt, sondern an die Betriebskosten und daran, wer die Strecke im Krankheitsfall weiterbetreiben kann.

Was kostet eine Anbindung je Ausbaustufe?

Der Aufwand hängt fast vollständig an der Zahl der Sonderregeln, und deshalb sind belastbare Zahlen nur je Ausbaustufe möglich: Eine Grundanbindung mit Artikeln, Beständen und Aufträgen ist ein Vorhaben von wenigen Wochen, während Zahlungsabgleich, Retourenprozess und Buchhaltungsübergabe den Umfang jeweils spürbar erhöhen. Die folgenden Zahlen sind Erfahrungswerte aus unseren Projekten und keine Herstellerangaben, sie ersetzen keine Schätzung an Ihrem Fall.

Zwei Posten fehlen in dieser Tabelle bewusst, weil sie stark schwanken. Der erste ist die Datenbereinigung vor dem Start, sie reicht von einem Tag bis zu mehreren Wochen, je nachdem wie lange der Artikelstamm gewachsen ist. Der zweite ist der Testlauf mit echten Aufträgen im Parallelbetrieb. Wir planen dafür mindestens zwei Wochen ein, in denen beide Wege laufen und täglich verglichen wird. Diese zwei Wochen sind der Grund, warum eine Anbindung selten kurz vor dem Weihnachtsgeschäft in Betrieb geht.

Womit fangen Sie an?

Fangen Sie mit der Feldtabelle an, nicht mit der Technik: Schreiben Sie für jedes relevante Feld auf, welches System es führt, in welche Richtung es fließt und was bei einem Konflikt gelten soll. Diese Tabelle kostet zwei bis drei Termine, sie ist ohne Entwickler machbar, und sie beantwortet nebenbei die Frage, ob Sie eine Middleware brauchen.

Danach folgt eine kurze technische Prüfung: Welche Schnittstellen bieten die beiden beteiligten Systeme, welche Grenzen sind dokumentiert, gibt es einen fertigen Konnektor, und passt der zu Ihrer Feldtabelle. Diese Prüfung liefert die Aufwandsspanne für Stufe 1 und die Entscheidung über die Architektur. Erst dann wird gebaut, und zwar in der Reihenfolge Artikel, Bestand, Auftrag, Beleg, Zahlung, Retoure. Jede Stufe geht in Betrieb, bevor die nächste beginnt.

Wenn Sie eine bestehende Anbindung haben, die Ärger macht, ist der schnellste Weg zu Ruhe fast immer derselbe: Warteschlange nachrüsten, Idempotenz über die externe Auftragsnummer sichern, nächtlichen Vollabgleich für Bestände ergänzen, täglichen Kennzahlenbericht einrichten. Das sind überschaubare Eingriffe mit großer Wirkung, weil sie die drei häufigsten Beschwerden abstellen: fehlende Aufträge, doppelte Aufträge und driftende Bestände. Wenn Sie Ihren Fall besprechen wollen, melden Sie sich über das Kontaktformular, gern mit der Angabe, welche beiden Systeme beteiligt sind und was heute schiefgeht.

Alle Herstellerangaben in diesem Beitrag haben den Stand August 2026 und stammen aus den unten verlinkten Quellen. Tarife, Grenzen und Schnittstellenversionen ändern sich, ein Blick in die Originalquelle gehört deshalb in jede Kalkulation. Die Aufwandszahlen sind Erfahrungswerte aus unseren Projekten. Bei den buchhalterischen und steuerlichen Punkten ersetzt dieser Beitrag keine Beratung durch einen Steuerberater, er zeigt, welche Fragen Sie stellen sollten, bevor die erste Buchung erzeugt wird.