Nach dem JTL-Update ist deine Abfrage kaputt? Das steckt dahinter.

max.dash ist ein read-only Operations-Cockpit für JTL-Fulfillment-Dienstleister (3PL) im DACH-Raum. Wir lesen die JTL-WaWi (eazybusiness) rein lesend und liefern SLA-Reporting pro Mandant, Versandleistung pro Mitarbeiter, ein mandantengetrenntes Kundenportal und Abrechnungs-Mengen-Export - ohne Systemwechsel. Genau deshalb kennen wir das Schema-Mapping-Problem aus erster Hand: Jedes JTL-Update, das Tabellen umbaut, trifft auch unsere Anbindung - und wir müssen es vor unseren Kunden abfangen, nicht danach reagieren.

01 - Das Problem: das Schema wurde umgebaut

Was passiert ist. Mit JTL-WaWi 1.6 hat JTL die Datenbank nicht nur erweitert, sondern strukturell umgebaut. Die zentralen Tabellen rund um Bestellung und Rechnung wurden aus dem alten Namensraum herausgelöst und in eigene, klar benannte Schemata verschoben. Wer bisher direkt gegen tBestellung, tBestellPos oder tRechnung gearbeitet hat, bekommt nach dem Update schlicht keine Treffer mehr - die Tabellen sind in dieser Form nicht mehr da.

Wen es trifft. Betroffen ist jeder, der eigene Reports auf die JTL-Datenbank gebaut hat: SQL-Abfragen für interne Auswertungen, Power-BI-Dashboards mit direkter Datenbankverbindung, selbst geschriebene Skripte für Abrechnung oder Mengen-Export. Der Bruch zeigt sich nicht als sanfte Warnung, sondern als leere Ergebnismenge oder als Fehlermeldung "Invalid object name" - mitten im Tagesgeschäft, oft am Monatsende, wenn die Abrechnung ansteht.

Eine Abfrage, die seit zwei Jahren zuverlässig lief, liefert nach dem Wochenend-Update plötzlich null Zeilen. Nichts an der Frage hat sich geändert - nur die Tabelle, gegen die sie läuft, heißt jetzt anders und liegt in einem anderen Schema.

02 - Das Tabellen-Mapping im Detail

Die wichtigsten Verschiebungen betreffen genau die Tabellen, auf denen die meisten selbst gebauten Reports aufsetzen: Auftrag, Auftragsposition und Rechnung.

Wie man es liest. Der Primärschlüssel für den Auftrag heißt weiterhin kAuftrag und bleibt das zentrale Bindeglied zwischen Verkauf.tAuftrag, Verkauf.tAuftragPosition und den zugehörigen Rechnungsdaten in Rechnung.tRechnung. Wer bisher über tBestellung.kBestellung verknüpft hat, muss die JOIN-Bedingung entsprechend auf kAuftrag im neuen Schema umstellen. Ergänzende Felder, die früher direkt an der Bestellung hingen, liegen jetzt teils in tAuftragEckdaten - wer diese Tabelle beim Umbau übersieht, verliert stillschweigend Spalten, ohne dass die Abfrage einen Fehler wirft.

• Schema-Präfixe sind nicht kosmetisch: Verkauf. und Rechnung. gehören zwingend vor den Tabellennamen, sonst löst SQL Server die Referenz nicht auf
• Alte Spaltennamen können innerhalb der neuen Tabellen umbenannt worden sein - Mapping auf Tabellenebene reicht allein nicht immer
• Trigger, Sichten oder Stored Procedures, die von Drittsystemen auf die alten Namen zeigen, brechen mit demselben Muster

03 - Hilfsmittel: Vergleichstool und VIEWs

Das offizielle Vergleichstool. JTL stellt unter wawi-db.jtl-software.de ein Tabellen-Vergleichstool bereit, das die Zuordnung zwischen alten und neuen Tabellen- und Spaltennamen über die Versionen hinweg dokumentiert. Für jede eigene Abfrage, die beim Update bricht, lohnt sich zuerst der Blick dorthin, statt die neue Struktur per Trial-and-Error zu erraten.

VIEWs statt direkter JOINs. JTL liefert für viele der zentralen Auswertungsfälle eigene VIEWs mit. Diese kapseln die interne Tabellenstruktur und sind bei Schema-Umbauten tendenziell stabiler als eigene JOINs direkt auf die Basistabellen, weil JTL Änderungen an der Innenstruktur eher hinter der VIEW versteckt, als die VIEW-Schnittstelle selbst zu brechen. Wo eine passende VIEW existiert, ist sie die robustere Basis für eigene Reports als der direkte Zugriff auf Verkauf.tAuftrag und Co.

• Vor dem Neubau einer Abfrage prüfen, ob JTL bereits eine passende VIEW mitliefert
• Abweichungen im Vergleichstool nachschlagen, statt Tabellennamen zu raten
• Eigene Abfragen dokumentieren, welche Basistabellen sie referenzieren - das beschleunigt das nächste Update-Mapping

04 - Die kMandant-Falle

Was es ist. Wer für mehrere Auftraggeber im selben JTL-System arbeitet, kennt die Mandantentrennung über kMandant. Beim Umbau eigener Abfragen auf das neue Schema geht dieser Filter erfahrungsgemäß am schnellsten verloren - der JOIN wird repariert, der WHERE-Filter aber nicht mitgezogen.

Was dann passiert. Ohne den kMandant-Filter liefert die Abfrage Aufträge, Positionen oder Rechnungen aus allen Mandanten gemeinsam zurück. Das fällt nicht sofort auf, weil die Abfrage technisch fehlerfrei läuft und Ergebnisse liefert - nur eben die falschen. In einem 3PL-Betrieb heißt das konkret: Versandzahlen oder Abrechnungsmengen eines Kunden vermischen sich mit denen eines anderen, und das bleibt unbemerkt, bis eine Rechnung oder ein Report offensichtlich nicht zum Kunden passt.

Warum das gerade nach einem Schema-Update passiert. Beim Nachziehen einer kaputten Abfrage liegt der Fokus auf "läuft sie wieder" - nicht auf "filtert sie noch richtig". Der kMandant-Filter gehört deshalb auf jede Checkliste, die nach einem JTL-Update abgearbeitet wird, bevor eine reparierte Abfrage wieder produktiv genutzt wird.

05 - Selbst pflegen oder pflegen lassen

Read-only-SQL direkt gegen die JTL-Datenbank zu bauen ist grundsätzlich machbar - technisch spricht nichts dagegen, solange der Zugriff wirklich lesend bleibt. Der ehrliche Teil der Geschichte ist der Wartungsaufwand danach: Jedes JTL-Update, das Tabellen umbaut, verlangt, dass jemand die betroffenen Abfragen findet, das neue Schema nachschlägt, die JOINs und Filter korrigiert und die Ergebnisse gegenprüft. Das ist kein einmaliger Aufwand, sondern wiederkehrende Arbeit, die bei jedem Versions-Sprung neu ansteht - und die in der Praxis meist genau dann liegen bleibt, wenn im Tagesgeschäft ohnehin schon Druck herrscht.

Genau hier setzt max.dash an: Das Schema-Mapping zwischen JTL-Versionen wird zentral gepflegt, nicht bei jedem einzelnen Kunden neu gebaut. Wenn JTL Tabellen umbaut, ziehen wir das Mapping in unserer Leseschicht nach - deine SLA-Auswertungen, Versandleistungen und Abrechnungs-Exporte laufen weiter, ohne dass du selbst SQL nachbesserst oder auf den nächsten Patch wartest, der deinen Report repariert.

Wie die Leseschicht grundsätzlich auf die JTL-Datenbank zugreift, steht im Leitfaden zum JTL-Datenbank-Auslesen. Wer eigene Power-BI-Reports gegen JTL abwägt, findet den direkten Vergleich unter Power BI gegen JTL-Cockpit. Wie SLA-Reporting, Versandleistung und Abrechnung auf dieser Datenbasis konkret aussehen, zeigen die Auswertungen und die JTL-Dashboard-Übersicht.

FAQ