- Mandantentrennung heißt: Kennzahlen mehrerer Händler auf einer JTL-WaWi strikt pro Marke getrennt auswerten und anzeigen.
- Ein Mandant pro Kunde trennt sauber, kostet aber JTL-WMS-Lizenzen pro Packer und pro Mandant - 119 Euro netto pro Monat und Lizenz.
- Ein Mandant mit Firmen-Zuordnung spart Lizenzkosten, die Trennung ist dann aber teils nur logisch, nicht technisch erzwungen.
- Ein Cross-Mandanten-Report ist in JTL-WaWi kein Standardfeature - er muss extern über eine read-only Schicht zusammengeführt werden.
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.
Was Mandantentrennung im Fulfillment bedeutet
Mandantentrennung im Fulfillment bedeutet, dass die Kennzahlen mehrerer Händler auf einer JTL-WaWi-Instanz strikt pro Marke getrennt ausgewertet und angezeigt werden. Ein 3PL-Dienstleister betreut selten nur einen Kunden. Meist laufen fünf, zehn oder fünfzig Händler über dieselbe Lagerinfrastruktur, dieselben Packplätze und dasselbe JTL-System - aber jeder Händler hat eigene Bestände, eigene Bestellungen, eigene SLA-Regeln und ein eigenes Recht darauf, dass niemand außer ihm seine Zahlen sieht.
Damit entsteht eine doppelte Anforderung, die sich auf den ersten Blick widerspricht: Der Dienstleister braucht die Gesamtsicht über alle Mandanten, um Kapazität zu planen, Personal einzuteilen und den Betrieb zu steuern. Jeder Mandant braucht gleichzeitig die Garantie, dass seine Daten nicht bei einem anderen Kunden auftauchen. Beides gleichzeitig zu liefern ist die eigentliche Aufgabe - und genau hier liegt der Punkt, an dem viele Fulfiller mit Excel oder Bordmitteln scheitern.
Das Modell-Dilemma: ein Mandant pro Kunde oder ein Mandant für alle
Bevor man über Reporting spricht, muss man über das zugrunde liegende JTL-Setup sprechen. Es gibt im Kern zwei Wege, mehrere Händler in einer JTL-WaWi abzubilden, und beide haben handfeste Vor- und Nachteile. Es gibt hier kein pauschal richtig - die Wahl hängt von Kundenzahl, Lizenzbudget und dem Einsatz von JTL-WMS ab.
Modell A: Ein Mandant pro Kunde
Jeder Händler bekommt einen eigenen JTL-Mandanten. Bestände, Bestellungen, Belegnummernkreise und Benutzerrechte sind auf Datenbankebene getrennt, nicht nur logisch. Für die Datentrennung ist das die sauberste Lösung - eine Fehlzuordnung zwischen Kunden ist strukturell kaum möglich.
Der Haken liegt im Lizenzmodell von JTL-WMS: Lizenzen werden pro Packer und pro Mandant fällig, mit 119 Euro netto pro Monat und Lizenz. Bedient ein Lagermitarbeiter fünf Mandanten, braucht er im Zweifel fünf Lizenzen. Bei einer größeren Kundenzahl und mehreren Packplätzen wird das schnell zum spürbaren Kostenblock - unabhängig vom eigentlichen Versandvolumen.
Modell B: Ein Mandant mit Firmen-Zuordnung
Alle Händler laufen in einem gemeinsamen JTL-Mandanten, die Trennung passiert über eine Firmen- beziehungsweise Kundenzuordnung je Artikel, Lager oder Auftrag. Das spart die Mandanten-Lizenzkosten von JTL-WMS vollständig - ein Packer braucht nur eine Lizenz, egal wie viele Marken er bedient.
Der Preis dafür ist Disziplin: Die Trennung ist teils nur logisch, nicht durch die Datenbankstruktur erzwungen. Wird eine Zuordnung falsch gepflegt oder ein Filter im Report vergessen, können Zahlen oder Bestände versehentlich vermischt werden. Das Modell funktioniert gut, verlangt aber saubere Prozesse und ein Reporting, das die Zuordnung zuverlässig respektiert.
Beide Modelle sind in der Praxis verbreitet, und beide sind legitim. Manche Fulfiller fahren sogar eine Mischform - größere Mandanten mit eigenem JTL-Mandanten, kleinere über Firmen-Zuordnung gebündelt. Was in jedem Fall bleibt: Egal welches Modell man fährt, das Reporting muss beide Anforderungen gleichzeitig erfüllen - die Gesamtsicht für den Betrieb und die strikte Trennung für den Kunden.
Warum konsolidiertes Reporting über Mandanten nativ schwierig ist
Hier liegt der eigentliche Engpass. JTL-WaWi ist mandantenfähig gebaut - und genau das macht die mandantenübergreifende Auswertung technisch unbequem. Jeder Mandant lebt in seinem eigenen Datenkontext: eigene Belegnummernkreise, eigene Benutzeranmeldung, eigene Sicht auf Bestände und Aufträge. Das ist im Tagesgeschäft richtig, weil es genau die Trennung erzwingt, die ein Mandant vertraglich erwartet.
Für den Dienstleister bedeutet das aber: Es gibt keinen JTL-Standardreport, der "Versandvolumen über alle Mandanten" oder "Pakete pro Kunde diesen Monat" auf einen Blick liefert. Wer diese Zahl braucht, muss sich in jeden Mandanten einzeln einloggen, jeweils exportieren und die Ergebnisse händisch in Excel zusammenführen. Das funktioniert bei drei Mandanten mit Mühe. Bei zehn oder zwanzig wird daraus eine Fleißaufgabe, die jeden Monat neu beginnt und bei jeder Struktur- oder Preisänderung bricht.
Kommt das Firmen-Zuordnungs-Modell dazu, wird es nicht einfacher, sondern anders schwierig: Jetzt liegen zwar alle Daten in einem Mandanten, aber ein sauberer Report pro Kunde verlangt, dass jede Auswertung konsequent nach der Firmen-Zuordnung filtert - und dass diese Zuordnung fehlerfrei gepflegt ist. Ein einziges falsch zugeordnetes Feld reicht, um einem Kunden die Zahlen eines anderen zu zeigen.
Wie man es sauber löst: konsolidiert und getrennt zugleich
Die Lösung ist keine neue JTL-Funktion, sondern eine zusätzliche Schicht: ein read-only Reporting-Layer, der oberhalb der WaWi liegt und die Daten aus allen Mandanten - unabhängig vom gefahrenen Modell - an einem Ort zusammenführt. Diese Schicht greift nicht schreibend in JTL ein, sie liest nur, spiegelt die Daten und rechnet zwei Sichten gleichzeitig aus derselben Quelle:
- Die konsolidierte Sicht für den Betrieb. Gesamt-Versandvolumen über alle Mandanten, Pakete pro Kunde im Vergleich, Gesamt-Lagerwert, Retourenquote über den ganzen Betrieb. Das ist die Steuerungssicht, die nur der Fulfiller selbst sieht.
- Die getrennte Sicht für jeden Händler. Jeder Mandant bekommt im Kundenportal ausschließlich seine eigenen Zahlen - unabhängig davon, ob dahinter technisch ein eigener JTL-Mandant oder eine Firmen-Zuordnung innerhalb eines gemeinsamen Mandanten steht. Der Login ist fest an die Marke gebunden, fremde Daten werden gar nicht erst geladen.
Der entscheidende Punkt: Diese Trennung sitzt nicht in einer Excel-Formel oder in der Disziplin, jeden Filter richtig zu setzen, sondern in der Datenabfrage selbst. Genau das leistet das mandantengetrennte Kundenportal von max.dash - egal ob du ein Mandant pro Kunde fährst oder ein Mandant mit Firmen-Zuordnung. Die Reporting-Schicht bildet dein bestehendes JTL-Modell ab, statt dir ein neues aufzuzwingen. Es gibt keine Migration, kein Plugin, keinen Systemwechsel - max.dash liest, was in deiner eazybusiness-Datenbank bereits vorhanden ist, und macht daraus zwei konsistente Sichten aus derselben Quelle.
Für die betriebliche Steuerung ergänzt das SLA-Reporting pro Mandant die Kapazitätssicht: Cutoff, Werktage und Feiertage sind je Mandant unterschiedlich hinterlegt, die Quote wird aber trotzdem konsolidiert vergleichbar gemacht. Und für die kaufmännische Seite liefert der Abrechnungs-Mengen-Export die Pakete, Retouren und Sonderpositionen sauber getrennt je Mandant - als Exportgrundlage für die Rechnung, nicht als Rechnung selbst.
Praxis: Versand pro Mandant und Summe Lager
So sieht die konsolidierte Sicht in der Praxis aus - eine Zeile pro Mandant, eine Summenzeile für den Betrieb. Genau diese Aggregation existiert in JTL-WaWi nicht als Standardauswertung, weil sie mandantenübergreifend rechnet.
Der Fulfiller sieht die Summenzeilen und plant danach Kapazität und Personal. Mandant A loggt sich im Kundenportal ein und sieht ausschließlich seine 4.812 Pakete und seinen Lagerwert von 128.400 Euro - keine Zeile von Mandant B oder C erscheint in seiner Ansicht. Beide Sichten stammen aus derselben Datenbasis, demselben Sync, derselben Nacht - nur die Berechtigung entscheidet, was wer sieht.
Häufige Fragen
Kann JTL mehrere Mandanten konsolidiert auswerten?
Nicht nativ als Standardreport. JTL-WaWi trennt Mandanten strikt in eigenen Datenkontexten, das ist für die tägliche Arbeit richtig, aber ein Report über alle Mandanten hinweg - zum Beispiel das Gesamt-Versandvolumen über alle Kunden - muss extern zusammengeführt werden, etwa über eine read-only Reporting-Schicht wie max.dash.
Ein Mandant oder mehrere - was ist besser für Fulfiller?
Es gibt kein pauschal richtig. Ein Mandant pro Kunde trennt Daten und Berechtigungen sauber, kostet aber JTL-WMS-Lizenzen pro Packer und pro Mandant. Ein Mandant mit Firmen-Zuordnung spart Lizenzkosten, verlangt aber Disziplin bei der Zuordnung, weil die Trennung teils nur logisch ist. Die Entscheidung hängt von Kundenzahl, Lizenzbudget und WMS-Einsatz ab.
Sieht ein Händler-Kunde die Zahlen anderer Mandanten?
Nein, wenn das Reporting sauber gebaut ist. Im mandantengetrennten Kundenportal von max.dash ist jeder Login fest an eine Marke gebunden - unabhängig davon, ob dahinter technisch ein eigener JTL-Mandant oder eine Firmen-Zuordnung innerhalb eines Mandanten steht. Fremde Bestellungen, Bestände oder Kennzahlen werden gar nicht erst geladen.