Wer eine Umsatzzahl aus JTL-WaWi braucht, landet früher oder später bei SQL. Die Datenbank ist offen, ein MSSQL-Client reicht, und die Rohdaten liegen alle drin. Das Problem zeigt sich erst beim zweiten Blick: Die erste Abfrage liefert fast immer einen Wert, der plausibel aussieht - aber nicht mit dem übereinstimmt, was das WaWi-Cockpit oder die Finanzbuchhaltung zeigt. Die Ursache sind fast immer dieselben vier Fehler.
Was eine Umsatzauswertung per SQL ist
Eine Umsatzauswertung per SQL zieht die Auftrags- und Rechnungswerte direkt aus der eazybusiness-Datenbank der JTL-WaWi. Statt über die WaWi-Oberfläche oder einen fertigen Report zu gehen, greift eine SQL-Abfrage unmittelbar auf die zugrundeliegenden Tabellen zu - Aufträge, Auftragspositionen und Rechnungen - und aggregiert die Werte selbst. Das gibt maximale Flexibilität bei Zeiträumen, Filtern und Gruppierungen, verlagert aber auch die gesamte fachliche Korrektheit (Mandant, Steuersatz, Storno-Status, Tabellenstruktur) in die Abfrage selbst.
- Umsatz per SQL heißt: direkter Zugriff auf Verkauf.tAuftrag, Verkauf.tAuftragPosition und Rechnung.tRechnung in eazybusiness.
- Fehler 1: kMandant-Filter fehlt - mehrere Mandanten werden in einer Summe vermischt.
- Fehler 2: Storno- und Retourenpositionen bleiben in der Summe stehen.
- Fehler 3: Netto- und Bruttobeträge sowie Rabatte werden verwechselt oder doppelt verrechnet.
- Fehler 4: Abfragen gegen tBestellung/tRechnung laufen nach dem WaWi-1.6-Update ins Leere.
01 - kMandant-Filter vergessen
Der Fehler. JTL-WaWi ist mandantenfähig: eine Installation, mehrere rechtlich oder organisatorisch getrennte Einheiten, jede mit eigener Kundennummer, eigenem Shop, eigener Rechnungsnummerierung. In den zentralen Tabellen steht dafür die Spalte kMandant. Wer sie in der WHERE-Klausel vergisst, summiert automatisch über alle Mandanten hinweg - die Abfrage läuft fehlerfrei durch, das Ergebnis ist trotzdem falsch.
Warum das teuer wird. Für einen Fulfillment-Dienstleister mit mehreren Mandanten in einer WaWi-Instanz ist das kein Randfall, sondern der Normalfall. Ein Umsatzbericht ohne Mandantentrennung zeigt eine Zahl, die keinem einzelnen Kunden zuzuordnen ist - und die bei der nächsten Abrechnung oder dem nächsten Kundengespräch nicht standhält. Besonders tückisch: Wenn ein neuer Mandant angelegt wird, läuft die alte, ungefilterte Abfrage klaglos weiter und mischt den neuen Umsatz einfach mit ein.
Die Regel. Jede Auswertung, die mandantenscharf sein soll, braucht WHERE kMandant = @kMandant in jeder beteiligten Tabelle mit dieser Spalte - nicht nur in der äußersten Abfrage, sondern auch in Subqueries und Joins, wo sie sonst über eine ungefilterte Zwischentabelle wieder hereinkommt.
02 - Storno und Retoure nicht abgezogen
Der Fehler. Ein Auftrag, der storniert wurde, bleibt in den meisten Fällen als Datensatz in Verkauf.tAuftrag stehen - er wird nicht gelöscht, sondern über ein Statusfeld als storniert markiert. Wer stur über alle Auftragspositionen summiert, ohne den Storno-Status zu prüfen, zählt stornierte Aufträge als Umsatz mit. Retouren liegen noch eine Ebene komplizierter: Sie erscheinen oft als eigener Beleg oder als Gutschrift, nicht als Änderung am ursprünglichen Auftrag.
Warum das teuer wird. Der Effekt ist in der Praxis nicht klein. Bei Sortimenten mit hoher Retourenquote - Bekleidung liegt erfahrungsgemäß deutlich höher als etwa Nahrungsergänzung oder technisches Zubehör - kann der Unterschied zwischen brutto gezähltem und tatsächlich realisiertem Umsatz zweistellig im Prozentbereich liegen. Eine Umsatzzahl, die Stornos und Retouren mitzählt, ist damit kein Rundungsfehler, sondern strukturell zu hoch.
Die Regel. Stornierte Aufträge über das entsprechende Statusfeld ausschließen, und Retouren/Gutschriften als eigenen, gegenläufigen Posten führen statt sie stillschweigend zu verrechnen. Für eine belastbare Zahl braucht es beide: den Bruttoumsatz aus den Aufträgen und die Korrektur aus Storno und Retoure, getrennt sichtbar - nicht nur eine bereits verrechnete Endsumme, bei der niemand mehr nachvollziehen kann, wie viel davon Korrektur war.
03 - Netto/Brutto und Rabatte verwechselt
Der Fehler. In den Auftragspositionen liegen Preise teils netto, teils brutto, je nachdem, welches Feld man greift und wie der Mandant konfiguriert ist. Dazu kommen Rabatte, die auf Positionsebene, auf Auftragsebene oder als Gutschein wirken können - und je nach Feldwahl entweder schon im Positionspreis verrechnet sind oder separat abgezogen werden müssen. Wer Bruttopreise nimmt, aber mit einer Nettoformel weiterrechnet, oder einen bereits rabattierten Preis nochmal um den Rabatt kürzt, bekommt eine Zahl, die in sich schlüssig aussieht und trotzdem falsch ist.
Warum das teuer wird. Der Fehler ist gefährlich, weil er sich nicht durch einen Plausibilitätscheck entlarvt - die Summe wirkt vernünftig, sie ist nur um den Mehrwertsteuersatz oder um doppelt verrechnete Rabatte verschoben. Bei 19 Prozent Regelsteuersatz bedeutet eine Netto/Brutto-Verwechslung sofort eine Abweichung von rund 16 Prozent in die eine oder andere Richtung - genug, um jede Monatsauswertung unbrauchbar zu machen, ohne dass es auf den ersten Blick auffällt.
Die Regel. Vor jeder Abfrage festlegen, ob netto oder brutto ausgewertet wird, und diese Entscheidung durch die gesamte Kette (Position, Auftrag, Rechnung) konsistent durchziehen. Rabatte einmal und nur einmal verrechnen, und dokumentieren, auf welcher Ebene das geschieht - sonst rechnet die nächste Abfrage, die auf dieser aufbaut, den Rabatt ein zweites Mal heraus.
04 - Veraltete Tabellennamen nach dem WaWi-1.6-Update
Der Fehler. Ältere Anleitungen, Forenbeiträge und selbst gebaute Abfragen aus der WaWi-1.5-Zeit greifen auf Tabellen wie tBestellung und tRechnung zu. Mit dem Schema-Update in JTL-WaWi 1.6 wurden zentrale Bereiche des Datenmodells umstrukturiert und in Schemas gruppiert. Diese alten Tabellennamen existieren in aktuellen Installationen nicht mehr. Eine Abfrage, die sie referenziert, bricht entweder sofort mit einem Fehler ab oder - schlimmer - läuft gegen eine Kompatibilitätsansicht, die nicht alle Fälle abdeckt und stillschweigend unvollständige Ergebnisse liefert.
Warum das teuer wird. Der Umstieg betrifft nicht nur Neuabfragen. Jede bestehende, über Jahre gewachsene Reporting-Abfrage, jedes Excel-Makro mit fest verdrahteter SQL-Verbindung, jedes selbst gebaute Skript ist nach dem Update ein Kandidat für stillen Ausfall. Details zum Umfang der Umstellung und zur Migration bestehender Abfragen stehen im Leitfaden zum JTL-Schema-Update.
Die Regel. Aktuelle Umsatzabfragen arbeiten gegen Verkauf.tAuftrag (Auftragskopf), Verkauf.tAuftragPosition (Positionen mit Menge und Preis) und Rechnung.tRechnung (Rechnungsbelege), verknüpft über den Schlüssel kAuftrag. Wer eine Abfrage aus der Vor-1.6-Zeit übernimmt, sollte sie grundsätzlich gegen das aktuelle Schema prüfen, nicht nur gegen einen einzelnen Testfall - die Struktur der gesamten eazybusiness-Datenbank hat sich an mehreren Stellen verschoben, nicht nur bei diesen beiden Tabellen.
Selbst bauen oder Cockpit nutzen
Eine SQL-Abfrage auf die eazybusiness-Datenbank ist grundsätzlich machbar - die Datenbank ist offen, ein MSSQL-Client genügt, und mit den vier Punkten oben lässt sich eine korrekte Umsatzabfrage schreiben. Der eigentliche Aufwand entsteht nicht beim ersten Schreiben, sondern bei der Pflege: Jedes WaWi-Update kann Tabellen verschieben, jeder neue Mandant kann einen vergessenen Filter aufdecken, und jede Abfrage, die einmal "ungefähr richtig" aussah, bleibt oft jahrelang unbemerkt falsch, bis eine Abrechnung nicht mehr zusammenpasst. Einen tieferen Vergleich der beiden Wege - eigene SQL-Pflege gegen ein fertiges Cockpit - findest du im Artikel SQL vs. Cockpit.
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. Die Mandantentrennung, der Storno-/Retourenabzug und die Anpassung an aktuelle Tabellennamen sind darin fest eingebaut und werden bei jedem WaWi-Update mitgepflegt, statt bei jedem Fulfiller einzeln neu geschrieben zu werden. Wie ein solches Cockpit auf der eazybusiness-Datenbank aufsetzt, zeigt das JTL-Dashboard.
Häufige Fragen
Kann ich Umsatz direkt per SQL aus der JTL-WaWi auswerten?
Ja, die eazybusiness-Datenbank ist eine normale MSSQL-Datenbank und per SQL abfragbar. Die Rohdaten liegen in Verkauf.tAuftrag, Verkauf.tAuftragPosition und Rechnung.tRechnung. Der Aufwand steckt nicht im Verbindungsaufbau, sondern darin, Mandant, Storno, Steuersatz und Tabellenstruktur bei jeder Abfrage korrekt zu behandeln.
Warum zeigt meine SQL-Abfrage einen höheren Umsatz als das WaWi-Cockpit?
Meistens fehlt der Ausschluss stornierter oder retournierter Positionen, oder es wird über alle Mandanten ohne kMandant-Filter summiert. Beide Fehler zeigen einen zu hohen Wert im Vergleich zur bereinigten WaWi-Auswertung.
Welche Tabellen wurden mit JTL-WaWi 1.6 umbenannt?
Die alten Tabellen tBestellung und tRechnung existieren in aktuellen WaWi-1.6-Versionen nicht mehr. Bestelldaten liegen jetzt in Verkauf.tAuftrag und Verkauf.tAuftragPosition, Rechnungsdaten in Rechnung.tRechnung, verknüpft über kAuftrag.