JTL-Wawi an den Onlineshop anbinden: Sync planen

Die meisten Probleme bei der Kopplung von JTL-Wawi und Shop entstehen nicht durch fehlende Technik, sondern durch fehlende Planung. Der JTL-Connector richtet die Verbindung zwar in überschaubarer Zeit ein, doch die entscheidenden Fragen -- welches System führt, welches Feld gewinnt bei einem Widerspruch, wie werden Artikel und Kunden eindeutig zugeordnet -- werden oft erst geklärt, wenn die ersten Fehler auftreten. Dann liegen bereits doppelte Datensätze in beiden Systemen, und der Aufwand, sie wieder zu bereinigen, übersteigt den einer sauberen Erstplanung deutlich.

Vier Muster treten dabei wiederholt auf. Erstens die doppelte Artikelanlage: Ein Produkt existiert im Shop unter einer anderen Artikelnummer als in der Wawi, der Abgleich erkennt es nicht als dasselbe und legt es ein zweites Mal an. Zweitens Bestandsdifferenzen, wenn Shop und Wawi denselben Lagerbestand unabhängig voneinander verändern -- etwa durch eine Bestellung im Shop und eine gleichzeitige Korrektur in der Wawi. Drittens Dubletten bei Varianten, weil Farb- und Größenkombinationen unterschiedlich strukturiert sind. Und viertens doppelte Kundendatensätze, wenn ein Kunde im Shop nicht eindeutig einem vorhandenen Wawi-Kunden zugeordnet werden kann.

Der Aufwand ist real: Bereits jeder fünfte Konsument plant eine Retoure von vornherein ein (ECC Köln). Damit ein Retouren- oder Statusprozess reibungslos läuft, müssen Bestellung, Zahlungsstatus und Versandstatus in beiden Systemen denselben Stand zeigen. Das gelingt nur, wenn vorab feststeht, welches System welchen Wert führt -- und nicht beide gleichzeitig glauben, im Recht zu sein.

Der wichtigste Beschluss einer JTL-Anbindung ist die Festlegung des führenden Systems, oft Master genannt. Er beantwortet die Frage: Wenn zwei Systeme denselben Datensatz kennen und beide ihn ändern könnten, wessen Version ist die verbindliche? Für den Standardfall gibt die Herstellerdokumentation eine klare Empfehlung. Ab dem initialen Datentransfer ist JTL-Wawi das führende System; Änderungen am Datenbestand sollen ausschließlich in der Wawi und nicht mehr im Admin-Bereich des Shops erfolgen (JTL-Software GmbH Produktdokumentation).

Diese Regel klingt streng, ist aber die eigentliche Voraussetzung für einen konfliktfreien Betrieb. Wird ein Artikelpreis versehentlich im Shop-Backend geändert, obwohl die Wawi führt, überschreibt der nächste Abgleich diese Änderung wieder mit dem Wawi-Wert. Für das Team im Shop wirkt das wie ein Fehler -- tatsächlich arbeitet die Anbindung korrekt, nur wurde die Pflege am falschen Ort vorgenommen. Deshalb gehört zur technischen Einrichtung auch eine organisatorische: Wer pflegt was, in welchem System?

Selbst bei klarer Master-Regel gibt es Momente, in denen zwei Systeme denselben Datensatz kurz hintereinander verändern. Für diese Fälle braucht eine Anbindung eine definierte Konfliktstrategie. Drei Ansätze haben sich bewährt, die sich je nach Datenobjekt kombinieren lassen. Bei der Master-wins-Strategie gewinnt schlicht das führende System -- passend für Preise und Bestände, die ohnehin aus der Wawi kommen. Bei der zeitstempelbasierten Auflösung gewinnt die jüngste Änderung, sinnvoll bei Statusfeldern, die in beiden Systemen fortschreiten können. Und bei der feldweisen Auflösung wird pro Feld entschieden, welche Quelle führt -- die genaueste, aber auch aufwendigste Variante.

Entscheidend ist, dass die Strategie nicht dem Zufall überlassen wird. Eine Anbindung, die Konflikte still im Hintergrund auflöst, ohne dass jemand die Regel kennt, erzeugt genau die schwer auffindbaren Differenzen, die Wochen später als vermeintlicher Softwarefehler gemeldet werden. Sinnvoller ist es, Konflikte protokollieren zu lassen und regelmäßig zu sichten. Wie sich solche Abläufe zwischen Punkt-zu-Punkt-Kopplung und zentraler Middleware unterscheiden, behandelt der Vergleich REST-API und Middleware.

Eine belastbare JTL-Wawi-Shop-Anbindung entsteht in einer nachvollziehbaren Reihenfolge. Am Anfang steht nicht die Technik, sondern die Bestandsaufnahme der Datenobjekte, ihrer Richtung und ihres führenden Systems. Erst danach folgt die technische Einrichtung, der Testlauf und schließlich der überwachte Produktivbetrieb. Dieses Vorgehen zahlt sich aus, denn der Markt wächst weiter: Für 2026 rechnen die Verbände mit einem nominalen Wachstum des E-Commerce-Warenumsatzes von 3,8 Prozent (bevh), das Branchenszenario für den Onlinehandel liegt in einem Korridor von 2,7 bis 5,7 Prozent (IFH Köln). Wer seine Anbindung sauber aufsetzt, kann dieses Wachstum ohne wachsenden Pflegeaufwand mitgehen.

Wer diese Reihenfolge einhält, verwandelt eine gewachsene Kopplung in eine geplante Integration. Für angrenzende Themen lohnt der Blick auf die Bestandssynchronisation über mehrere Lager, auf die Absicherung der Schnittstelle mit OAuth 2.0 sowie auf die kommenden Datenpflichten rund um den digitalen Produktpass nach der ESPR. Reicht der Standard-Connector nicht aus -- etwa bei Marktplätzen, DATEV oder individuellen Feldregeln --, verbinden wir die Systeme über eine zentrale Middleware und eine passende API-Entwicklung. Die Anbindung weiterer Kanäle deckt unsere Marktplatz-Anbindung ab, die buchhalterische Seite die DATEV-Anbindung, und den Gesamtrahmen bildet unsere Systemintegration. Wie sich eine Warenwirtschaft grundsätzlich an einen Shop koppeln lässt, zeigt zudem unsere Seite zur Warenwirtschaft-Shop-Anbindung.