eazybusiness von innen: die Tabellen, die dein Reporting trägt.

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. Dieser Überblick zeigt, welche eazybusiness-Tabellen dafür konkret gelesen werden.

01 - Was eazybusiness ist

eazybusiness ist die MS-SQL-Datenbank der JTL-WaWi, in der alle Auftrags-, Versand-, Pick- und Rechnungsdaten liegen. Jede JTL-WaWi-Installation läuft technisch auf dieser Datenbank auf Microsoft SQL Server - kein Fremdsystem, keine Zwischenschicht, sondern eine gewöhnliche relationale Datenbank mit dem üblichen Rechte- und Abfragesystem. Wer versteht, wie eazybusiness aufgebaut ist, kann eigene SQL-Abfragen schreiben, statt sich auf mitgelieferte Standardreports zu verlassen.

Für Fulfiller ist das relevant, weil die drei Kernbereiche des Tagesgeschäfts - Auftrag, Kommissionierung, Abrechnung - jeweils in eigenen, klar abgrenzbaren Tabellengruppen liegen. Wer diese Struktur kennt, kann SLA-Quoten, Versandleistung und Abrechnungsmengen direkt aus der Datenbank ableiten, statt sie manuell aus der WaWi-Oberfläche zusammenzutragen.

02 - Auftrag und Auftragsposition

Was dort liegt. Der Auftrag ist die zentrale Einheit im eazybusiness-Schema. In Verkauf.tAuftrag steht ein Datensatz pro Auftrag mit Zeitstempeln, Status und Mandantenbezug; die einzelnen bestellten Artikel liegen in Verkauf.tAuftragPosition, verknüpft über den Schlüssel kAuftrag. Ergänzende Felder, die nicht direkt am Auftrag hängen - etwa bestimmte Zusatzangaben, die für Cutoff- oder SLA-Logik relevant sein können - liegen zusätzlich in tAuftragEckdaten.

Typischer Fallstrick. tAuftragEckdaten wird beim ersten Entwurf einer Abfrage gern übersehen, weil der Auftragskopf allein schon plausible Ergebnisse liefert. Fehlt diese Tabelle im JOIN, fehlen aber genau die Felder, die für eine sauber modellierte SLA-Regel oft gebraucht werden - die Abfrage liefert dann Zahlen, nur eben nicht die vollständigen.

03 - Pickliste und Kommissionierung

Was dort liegt. Die Kommissionierung hat ein eigenes Tabellentrio: tPickliste für den Kopf einer Pickliste (wann angelegt, von wem bearbeitet, welcher Status), tPicklistePos für die einzelnen zu entnehmenden Positionen und tPicklisteStatus für den Lebenszyklus einer Pickliste von der Anlage bis zum Abschluss. Diese drei Tabellen sind die Grundlage für jede Auswertung der Versandleistung pro Mitarbeiter.

• tPickliste - Kopfdaten: Anlagezeitpunkt, zuständiger Mitarbeiter, aktueller Status
• tPicklistePos - Positionsebene: welcher Artikel, welche Menge, welcher Lagerplatz
• tPicklisteStatus - Statusverlauf, relevant um Bearbeitungszeit von reiner Wartezeit zu trennen

Warum das für Kennzahlen zählt. Wer Picks pro Stunde sauber rechnen will, braucht nicht nur die Menge aus tPicklistePos, sondern auch belastbare Zeitstempel aus tPickliste und tPicklisteStatus - und im Idealfall ein Mapping auf echte Stempelzeiten aus der Zeiterfassung, nicht nur auf die Scan-Spanne innerhalb der Pickliste selbst. Wie diese Messung im Detail sauber aufgebaut wird, steht im Leitfaden zur Mitarbeiterleistung.

04 - Rechnung und Abrechnung

Was dort liegt. Rechnungsdaten liegen in Rechnung.tRechnung, ebenfalls über kAuftrag mit dem zugehörigen Auftrag verknüpfbar. Für einen Fulfiller ist diese Tabelle der Ausgangspunkt für jede mengenbasierte Abrechnung gegenüber dem eigenen Auftraggeber - unabhängig davon, ob intern nach Paketen, Picks oder Lagerplätzen abgerechnet wird.

Typischer Fallstrick. Rechnungsdaten und Versanddaten laufen zeitlich nicht zwangsläufig synchron - eine Rechnung kann vor, mit oder nach dem tatsächlichen Versand entstehen, je nach Prozess. Wer Abrechnungsmengen direkt aus Rechnung.tRechnung ableitet, sollte diesen Zeitversatz kennen und nicht stillschweigend mit dem Versanddatum aus dem Auftrag gleichsetzen.

05 - Das offizielle Tabellen-Vergleichstool

JTL stellt unter wawi-db.jtl-software.de ein offizielles Tabellen-Dokumentations- und Vergleichstool bereit. Dort lassen sich Tabellen- und Spaltennamen nachschlagen und über Versionsstände hinweg vergleichen. Für jede eigene Abfrage, die auf ein unbekanntes Feld trifft, eine leere Ergebnismenge liefert oder nach einem JTL-Update bricht, ist das der richtige erste Anlaufpunkt - vor dem Raten und vor dem Durchsuchen von Community-Foren.

Wie ein solcher Bruch nach einem konkreten Versionswechsel aussieht und welches Tabellen-Mapping dahintersteht, steht im Leitfaden zu JTL-Schema-Updates.

06 - VIEWs statt direkter JOINs

Warum VIEWs die robustere Basis sind. JTL liefert für viele Standardauswertungen eigene VIEWs mit, die mehrere Basistabellen bereits sinnvoll zusammenführen. Diese VIEWs kapseln die interne Tabellenstruktur und sind bei Schema-Änderungen tendenziell stabiler als eigene JOINs direkt auf Verkauf.tAuftrag, tPickliste und Co., weil JTL Änderungen an der Innenstruktur eher hinter der VIEW-Schnittstelle abfängt, statt diese selbst zu brechen.

• Vor dem eigenen JOIN prüfen, ob JTL bereits eine passende VIEW für den Anwendungsfall mitliefert
• Wo eine VIEW existiert, ist sie einer eigenen Mehrfach-JOIN-Konstruktion vorzuziehen
• Eigene Abfragen dokumentieren, welche Basistabellen referenziert werden - das beschleunigt jedes spätere Update-Mapping

07 - Die kMandant-Falle

Was es ist. Praktisch jede relevante Tabelle im eazybusiness-Schema führt kMandant als Feld für die Mandantentrennung, sobald mehrere Auftraggeber im selben JTL-System verwaltet werden. Die Falle: Beim Verknüpfen mehrerer Tabellen wird der Mandanten-Filter oft nur auf einer Seite des JOINs gesetzt oder schlicht vergessen.

Eine Abfrage über Auftrag, Pickliste und Rechnung läuft technisch fehlerfrei und liefert Ergebnisse. Nur eben Aufträge, Picks und Rechnungen aus mehreren Mandanten gemeinsam - unbemerkt, bis eine Auswertung oder eine Rechnung offensichtlich nicht zu einem einzelnen Kunden passt.

Warum das so leicht passiert. Der Fehler zeigt sich nicht als Fehlermeldung, sondern als plausibel aussehendes, aber falsches Ergebnis. Gerade bei mehrstufigen JOINs über Auftrag, Position, Pickliste und Rechnung reicht eine einzige vergessene kMandant-Bedingung, damit sich Daten mehrerer Mandanten vermischen. Der Filter gehört deshalb in jede einzelne beteiligte Tabelle des JOINs, nicht nur in die äußerste.

08 - Schema kennen ist nicht Schema pflegen

Wer bis hierhin gelesen hat, kennt die wichtigsten Tabellen für Auftrag, Pick und Abrechnung - und weiß, wie ehrlich der Aufwand dahinter ist. Das Schema einmal zu verstehen ist die eine Sache. Es über Jahre und über mehrere JTL-Versionen hinweg zu pflegen, ist eine andere: Tabellen werden umbenannt, in neue Schemata verschoben, Felder wandern, VIEWs ändern sich. Wer selbst gebaute SQL-Reports dauerhaft betreibt, zieht dieses Mapping bei jedem Update von Hand nach.

Genau hier setzt max.dash an: Das Mapping auf Verkauf.tAuftrag, tPickliste, Rechnung.tRechnung und die konsequente kMandant-Trennung sind Teil der Leseschicht, die zentral gepflegt wird - nicht bei jedem Kunden neu gebaut. SLA-Reporting, Versandleistung, Kundenportal und Abrechnungs-Mengen-Export laufen auf dieser Basis weiter, auch wenn JTL das Schema beim nächsten Update wieder anfasst.

Wie das Cockpit auf dieser Datenbasis konkret aussieht, zeigt die JTL-Dashboard-Übersicht. Wie ein Schema-Update zwischen Versionen im Detail aussieht, steht im Leitfaden zu JTL-Schema-Updates. Wie ein sicherer, rein lesender Zugriff auf diese Tabellen eingerichtet wird, erklärt JTL-WaWi read-only auslesen. Weitere Fachbegriffe rund um Fulfillment und JTL stehen im Glossar.