Wer: Mariusz Szatkowski und das WPPoland-Team, WooCommerce-Entwickler, die Shops im DACH-Raum an die Warenwirtschaft JTL-Wawi anbinden.
Was: Eine belastbare Schnittstelle zwischen WooCommerce und JTL-Wawi, mit Mehrlager-Bestandsrouting, One-Stop-Shop-Steuerlogik und Marktplätzen über BaseLinker, bei der JTL-Wawi die einzige Bestandswahrheit bleibt.
Wo: Remote für Händler in Deutschland, Österreich und der Schweiz. Wir binden die Schnittstelle des JTL-Setups an, das Sie bereits betreiben, ohne Ihre Warenwirtschaft umzubauen.
Wie viel: Individuelles Angebot, nachdem wir Lagerstruktur, Marktplatzkanäle, Steuerfälle und die vorhandene JTL-Konfiguration erfasst haben. Wir beginnen mit einer kurzen Scoping-Analyse.
WooCommerce JTL-Wawi Anbindung für Omnichannel-Händler
Diese Seite behandelt einen konkreten technischen Fall: die Anbindung von WooCommerce an die Warenwirtschaft JTL-Wawi. Nicht den allgemeinen Shop-Aufbau, sondern die Datenschicht, die Bestand über mehrere Lager, die korrekte MwSt je Zielland und den Marktplatzverkauf über Amazon und eBay mit einer einzigen Bestandswahrheit in Einklang hält.
Wenn Sie eine breitere Einordnung aller Warenwirtschafts- und ERP-Szenarien suchen, beginnen Sie beim Überblick WooCommerce-Integrationen mit ERP-Systemen. Dort steht JTL-Wawi neben SAP Business One, Dynamics 365 und Odoo als ein Fall unter vielen. Hier gehen wir gezielt tiefer in die JTL-spezifischen Fragen, die im Überblick nur angerissen werden.
Wen Sie beauftragen
- Kommerzielles WordPress seit 2006, vor Gutenberg und der REST API
- Senior-geführt: der Ingenieur aus dem Discovery ist auch in Woche sechs am Code
- Kein Offshore-Handoff, keine PM-Schicht in Rechnung gestellt
- WordCamp-Europe-Organisator, WordPress Foundation Credits Mentor
Was JTL-Wawi ist und warum die WooCommerce-Anbindung zählt
JTL-Wawi ist eine im DACH-Raum weit verbreitete Warenwirtschaft für den Online- und Omnichannel-Handel. Sie verwaltet Artikelstämme, Bestände über ein oder mehrere Lager, Einkauf, Aufträge, Rechnungen und den Versand. Für viele deutsche Händler ist JTL-Wawi das operative Rückgrat des Geschäfts, in dem die Wahrheit über Bestand und Preise liegt. WooCommerce ist in diesem Bild die Verkaufsfront, nicht die Datenquelle.
Genau daraus entsteht der Bedarf für eine saubere Anbindung. Der Shop soll zeigen, was tatsächlich lieferbar ist, zum Preis, den die Warenwirtschaft vorgibt, mit der Steuer, die für das Zielland gilt. Ohne verlässliche Schnittstelle pflegt jemand Bestände doppelt, korrigiert Preise von Hand und trägt Bestellungen manuell in JTL-Wawi nach. Das skaliert nicht und erzeugt genau die Fehler, die im Handel am teuersten sind: Überverkäufe, falsche Rechnungen und stornierte Bestellungen.
Eine JTL-Wawi-Anbindung beantwortet drei Fragen konkret. Erstens, welche Daten fließen (Artikel, Varianten, Bestand je Lager, Preise, Aufträge, Rechnungen, Versandstatus). Zweitens, in welche Richtung (Bestand und Preise meist von JTL-Wawi zum Shop, Bestellungen zurück in die Warenwirtschaft). Drittens, mit welcher Taktung (häufiger, leichter Abgleich für Bestand und Preise, seltener und schwerer für den vollständigen Katalog).
JTL-Connector oder individuelle API-Schnittstelle, wann welcher Weg
JTL bietet einen nativen Connector, der ursprünglich für das JTL-Shop-Ökosystem gedacht ist und über eine Erweiterung auch WooCommerce anbindet. Für einen klar strukturierten Standardfall ist das der schnellste Weg: ein Lager, überschaubare Variantenzahl, eine Preisliste, kein paralleler Marktplatzbetrieb mit eigener Logik. In dieser Konstellation deckt der Connector Artikel-, Bestands- und Auftragssynchronisation solide ab, und alles Weitere wäre unnötiger Aufwand.
Der Connector hat allerdings Grenzen, die bei wachsenden Setups sichtbar werden. Er bildet die Standardobjekte von JTL-Wawi auf die Standardobjekte von WooCommerce ab und lässt wenig Raum für abweichende Geschäftslogik. Mehrlager-Routing nach Postleitzahl, kundengruppenabhängige B2B-Preise, eine Sonderbehandlung bestimmter Steuerfälle oder ein zusätzlicher Kanal, der nicht ins Connector-Modell passt, lassen sich damit nicht sauber abbilden. Auch bei sehr großen Katalogen mit häufigen Aktualisierungen wird die reine Connector-Synchronisation träge, weil sie nicht auf Ihr Volumen und Ihre Änderungsraten hin gebaut ist.
Hier setzt eine individuelle API-Schicht an, entweder ergänzend zum Connector oder an seiner Stelle. Sie spricht die Schnittstelle von JTL-Wawi sowie die WooCommerce REST API an und trägt die Logik, die der Standard nicht kennt: Delta-Synchronisation, die nur geänderte Artikel überträgt, statt bei jedem Lauf den kompletten Katalog zu importieren, ein Routing, das den Bestand mehrerer Lager berücksichtigt, und eine Preisberechnung, die Kundengruppe und Aktionszeitraum einbezieht. Für tiefer gehende Architekturmuster bei großen Volumina, etwa Queueing und Caching, siehe die Enterprise-Lösungen.
Die ehrliche Regel lautet: Nutzen Sie den Connector, solange er passt, und bauen Sie individuell erst dort, wo eine konkrete Geschäftsanforderung ihn überfordert. Wir entscheiden das nach einem kurzen Scoping und nicht nach Prinzip.
Mehrlager-Routing nach Postleitzahl
Sobald ein Händler aus mehreren Lagern versendet, wird die Bestandsführung anspruchsvoll. Der Shop muss anzeigen, was insgesamt verfügbar ist, aber beim Auftrag muss entschieden werden, aus welchem Lager tatsächlich versendet wird. Diese Entscheidung hat direkte Folgen für Versandzeit und Kosten.
Unser Ansatz hält JTL-Wawi als führende Bestandsquelle je Lager und legt darüber eine Routing-Logik. Die Schnittstelle liest den Bestand pro Lager, aggregiert ihn für die Verfügbarkeitsanzeige im Shop und wählt beim Auftragseingang anhand der Kunden-Postleitzahl algorithmisch das Lager mit dem schnellsten Versandweg. Ein Kunde aus dem Rheinland wird bevorzugt aus einem westdeutschen Lager beliefert, ein Kunde aus Bayern aus einem süddeutschen Standort, sofern der Artikel dort vorrätig ist. Ist das nächstgelegene Lager leer, greift eine definierte Fallback-Reihenfolge auf das nächstbeste Lager mit Bestand zurück.
Der heikle Teil ist die Bestandssynchronität. Der aggregierte Shop-Bestand darf nicht länger als lieferbar zeigen, was in Summe längst reserviert oder verkauft ist. Deshalb arbeiten wir mit Reservierungen beim Checkout, idempotenten Bestandsupdates, damit doppelt eintreffende Meldungen nicht doppelt buchen, und einem regelmäßigen Abgleich, der Drift zwischen Shop-Anzeige und JTL-Bestand aufdeckt und meldet. Kein Cache ersetzt diesen Abgleich, er bestätigt lediglich, dass die schnelle Sicht und die Warenwirtschaft übereinstimmen.
One-Stop-Shop und die MwSt-Berechnung je Zielland
Seit der EU-weiten One-Stop-Shop-Regelung müssen grenzüberschreitende B2C-Verkäufe innerhalb der EU oberhalb der Umsatzschwelle mit dem Steuersatz des Ziellandes abgerechnet werden. Ein Verkauf nach Frankreich trägt französische MwSt, ein Verkauf nach Österreich die österreichische. Für einen Shop, der über WooCommerce verkauft und in JTL-Wawi abrechnet, muss beides zusammenpassen: die im Checkout ausgewiesene Steuer und die in JTL erzeugte Rechnung.
Die Anbindung sorgt dafür, dass die Steuerlogik nicht auseinanderläuft. Sie ermittelt anhand des Ziellandes den korrekten Satz und übergibt ihn so an JTL-Wawi, dass die dort erzeugte Rechnung den One-Stop-Shop-Anforderungen entspricht. Die Steuerregeln liegen als explizite, pflegbare Konfiguration vor, nicht als fest verdrahteter Wert im Code, damit eine Satzänderung oder ein neues Zielland eine Konfigurationsänderung bleibt und keine Entwicklung erfordert.
Zu klären ist außerdem, welches System die Steuer autoritativ berechnet. Wenn WooCommerce den im Checkout gezeigten Betrag ermittelt, JTL-Wawi aber die rechtlich verbindliche Rechnung, dürfen sich beide nicht widersprechen. Wir legen im Datenvertrag fest, dass eine Quelle die Steuer je Position berechnet und die andere sie übernimmt, statt zweimal unabhängig zu rechnen und Cent-Differenzen zu riskieren, die sich über hunderte Bestellungen zu einem Buchhaltungsproblem summieren.
BaseLinker parallel zu WooCommerce für Amazon und eBay
Viele JTL-Händler verkaufen nicht nur über den eigenen WooCommerce-Shop, sondern auch über Amazon und eBay. Für die Marktplatzanbindung ist BaseLinker im DACH- und CEE-Raum ein verbreitetes Werkzeug. Damit entsteht eine Konstellation mit mehreren Verkaufskanälen, die alle denselben physischen Bestand teilen: WooCommerce, Amazon und eBay über BaseLinker, dahinter JTL-Wawi als Warenwirtschaft.
Der gefährliche Fall in dieser Konstellation ist die Race Condition um die letzte Einheit. Ein Artikel ist einmal vorrätig, ein Kunde kauft ihn im WooCommerce-Shop, und eine Sekunde später bestellt jemand denselben Artikel über Amazon, bevor der Bestand über die Kanäle hinweg aktualisiert ist. Ohne klare Hierarchie führt das zu Überverkäufen, stornierten Bestellungen und, bei Amazon, zu Kennzahlen, die den Verkäuferstatus beschädigen.
Die Lösung ist eine strikte Bestandshierarchie. JTL-Wawi ist die einzige Bestandswahrheit, WooCommerce und BaseLinker sind nachgelagerte Kanäle. Ein Verkauf auf einem Kanal reduziert den verfügbaren Bestand zeitnah auf allen anderen, bevorzugt ereignisgesteuert statt durch reines Polling. Bei hoher Kanalfrequenz kann eine kurzlebige Verfügbarkeitssicht als Cache vor die Warenwirtschaft treten, die jeder Kanal vor dem Warenkorbabschluss prüft. Diese Sicht ersetzt aber nicht die Reservierungs- und Abgleichsregeln in JTL-Wawi, denn kein Cache garantiert, dass jede externe Aktualisierung tatsächlich ankam.
Bestellungen, Rechnungen und Versandlabels synchron halten
Die Bestandssynchronisation ist nur die eine Hälfte. Die andere ist der Bestellrückfluss. Eine bezahlte WooCommerce-Bestellung wird zum Auftrag in JTL-Wawi, wo Rechnung und Lieferschein entstehen. Der Versandstatus und die Sendungsnummer fließen zurück in den Shop und in die Kundenkommunikation, damit der Kunde eine Tracking-Information erhält und der Support nicht in zwei Systemen nachsehen muss.
Dieser Rückfluss muss gefahrlos wiederholbar sein. Ein Timeout nach dem Übergeben einer Bestellung beweist nicht, dass JTL-Wawi sie abgelehnt hat, und ein blinder Wiederholungsversuch kann einen doppelten Auftrag erzeugen. Deshalb vergeben wir eine stabile externe Referenz je Bestellung, prüfen vor einem erneuten Versand, ob der Auftrag schon existiert, und speichern die Bestätigung aus JTL-Wawi. Teillieferungen, Stornierungen, Erstattungen und Korrekturbelege werden ausdrücklich modelliert, nicht als Sonderfall im Nachhinein behandelt.
Wer die Lagerlogistik über JTL-WMS abwickelt, kann auch den Kommissionier- und Packprozess einbinden. Dann spiegelt der Auftragsstatus im Shop nicht nur, dass eine Rechnung erzeugt wurde, sondern den tatsächlichen Fortschritt in der Lagerabwicklung bis zur Übergabe an den Versanddienstleister.
Artikelnummer- und SKU-Mapping bei variablen Produkten
Der häufigste Stolperstein einer JTL-Wawi-Anbindung ist das Mapping variabler Produkte. WooCommerce modelliert ein variables Produkt als ein Elternprodukt mit mehreren Variationen, jede mit eigener SKU. JTL-Wawi kennt dafür den Vaterartikel mit mehreren Kindartikeln, jeder mit eigener Artikelnummer und meist eigener EAN. Beide beschreiben dieselbe Realität, aber mit unterschiedlicher Struktur, und genau an dieser Bruchstelle entstehen die typischen Fehler.
Ein sauberes Mapping braucht einen stabilen Schlüssel, der einen JTL-Kindartikel eindeutig mit einer WooCommerce-Variation verbindet, in der Regel die Artikelnummer oder die EAN. Ändert sich dieser Schlüssel im laufenden Betrieb, etwa weil im Backend eine Artikelnummer angepasst wird, verliert die Zuordnung ihren Anker, und Bestand oder Preis landen auf der falschen Variation. Deshalb legen wir im Datenvertrag ausdrücklich fest, welches System den Schlüssel führt und ob er überhaupt geändert werden darf.
Zwei Detailfälle sind besonders fehleranfällig. Erstens, Reihenfolge und Vollständigkeit: Trifft eine Variation vor dem zugehörigen Vaterartikel ein oder fehlt eine EAN, darf kein halbes Produkt veröffentlicht werden, sondern der Datensatz geht in eine Quarantäne mit klarer Fehlermeldung. Zweitens, Dubletten: Verwenden zwei Kindartikel versehentlich dieselbe EAN, muss die Synchronisation das erkennen und melden, statt stillschweigend Bestände zu vermischen.
Zwei Fälle aus der Praxis
Omnichannel-Händler mit drei Lagern. Ein Händler für Haushaltswaren verkaufte über WooCommerce sowie über Amazon und eBay per BaseLinker, mit Beständen in drei über Deutschland verteilten Lagern in JTL-Wawi. Das Problem war nicht der Verkauf, sondern die Zuordnung: Bestellungen wurden zu oft aus dem falschen, weiter entfernten Lager kommissioniert, was Versandzeit und Kosten trieb. Die Anbindung führte ein Routing nach Postleitzahl ein, das den aggregierten Bestand für die Shop-Anzeige beibehielt, beim Auftrag aber das nächstgelegene Lager mit Bestand wählte und bei Leerstand definiert auf das nächstbeste zurückfiel. JTL-Wawi blieb dabei die führende Bestandsquelle, der aggregierte Shop-Bestand wurde durch idempotente Updates und einen nächtlichen Abgleich gegen Drift abgesichert.
Überverkauf zwischen Shop und Amazon. Ein Händler mit knappen, teils einzelstückigen Artikeln kämpfte mit wiederkehrenden Überverkäufen. Der Ablauf war typisch: Ein Artikel war einmal vorrätig, wurde im WooCommerce-Shop verkauft, und Sekunden später bestellte ein Kunde denselben Artikel über Amazon, bevor der Bestand über die Kanäle aktualisiert war. Die Folge waren Stornierungen und eine belastete Amazon-Verkäuferkennzahl. Wir setzten eine strikte Hierarchie durch, in der JTL-Wawi die einzige Bestandswahrheit ist und WooCommerce sowie BaseLinker nachgelagerte Kanäle sind, ergänzt um eine kurzlebige Verfügbarkeitssicht, die jeder Kanal vor dem Warenkorbabschluss prüft, sowie um Reservierungs- und Abgleichsregeln in der Warenwirtschaft. Die Überverkäufe verschwanden nicht durch einen schnelleren Cache allein, sondern durch die klare Hierarchie plus Reservierung.
Wann Sie diese Anbindung brauchen und wann nicht
Eine individuelle WooCommerce-JTL-Wawi-Schnittstelle lohnt sich, wenn mindestens einer dieser Punkte zutrifft:
- Sie versenden aus mehreren Lagern und wollen die Zuordnung nach Postleitzahl statt nach Zufall oder Handarbeit.
- Sie verkaufen parallel über Amazon oder eBay per BaseLinker und hatten bereits Überverkäufe oder Race Conditions.
- Sie verkaufen grenzüberschreitend in der EU und brauchen die korrekte One-Stop-Shop-MwSt je Zielland, konsistent zwischen Checkout und JTL-Rechnung.
- Ihr Katalog ist groß, die Preise ändern sich häufig, und der native Connector wird dabei zu langsam.
- Sie führen kundengruppenabhängige B2B-Preise, die der Standard-Connector nicht sauber abbildet.
Umgekehrt ist die individuelle Schnittstelle Aufwand, den Sie sich sparen können, wenn Ihr Setup schlicht ist: ein Lager, eine Preisliste, kein Marktplatzparallelbetrieb, überschaubare Variantenzahl. In diesem Fall reicht der native JTL-Connector, und wir würden Ihnen davon abraten, für einen Bedarf zu bauen, den Sie nicht haben. Der ehrliche Weg beginnt mit der Frage, welche Ihrer heutigen Fehler Geld kosten, und nicht mit der Frage, wie viel Technik möglich ist.
Wenn Sie über die reine JTL-Anbindung hinaus allgemeine Weiterentwicklung Ihres Shops brauchen, etwa Performance, Erweiterungen oder Wartung, ist die Seite WooCommerce-Entwickler der richtige Ausgangspunkt.
