Wer als Fulfillment-Dienstleister mit JTL-WaWi arbeitet, stößt früher oder später auf das JTL-Fulfillment-Network. Es klingt nach einer Lösung für genau das Problem, das jeden 3PL-Betrieb beschäftigt: Händler anbinden, Bestand synchron halten, Leistung nachweisen. Das FFN löst den ersten Teil gut. Den zweiten Teil - was am Ende des Monats an SLA-Nachweis, Mitarbeiterleistung und Abrechnung auf dem Tisch liegen muss - deckt es nur teilweise ab.
Das JTL-Fulfillment-Network (JTL-FFN) verbindet Händler-Systeme mit Fulfillment-Dienstleistern und standardisiert Anbindung, Lager und Abrechnung.
- Das JTL-FFN standardisiert die technische Anbindung zwischen Händler-Shop und Fulfiller-Lager in der JTL-WaWi.
- Teilnahme als Dienstleister läuft über eazybusiness mit FFN-Modul und ein Fulfiller-Profil im Netzwerk.
- Das FFN-Portal zeigt Händlern Bestand, Retouren und eingehaltene Cut-Off-Zeiten - aus Sicht des einzelnen Mandanten.
- Vertragsfeste SLA-Quote, Mitarbeiterleistung und ein betriebsweiter Blick über alle Mandanten fehlen nativ.
- max.dash liegt read-only obendrauf und schließt genau diese Lücke - mit oder ohne FFN-Teilnahme.
01 - Was das JTL-Fulfillment-Network ist
Was es ist. Das JTL-FFN ist eine Vermittlungs- und Anbindungsschicht innerhalb des JTL-Ökosystems. Sie bringt Händler, die ihre Ware auslagern wollen, mit Fulfillment-Dienstleistern zusammen, die freie Lagerkapazität und Kommissionierleistung anbieten. Beide Seiten arbeiten dabei mit JTL-WaWi beziehungsweise eazybusiness, wodurch Aufträge, Bestand und Versandmeldungen ohne Dateiexport oder manuelle Übergabe zwischen den Systemen fließen.
Warum es entstanden ist. Vor dem FFN lief die Anbindung eines Fulfillers an einen Händler meist über individuelle Schnittstellen oder manuelle Prozesse: CSV-Import, E-Mail-Bestelllisten, eigene API-Anbindungen. Das FFN ersetzt diesen Wildwuchs durch ein standardisiertes Verfahren, das beide Seiten in ihrer jeweiligen JTL-Installation abbilden. Für den Fulfiller bedeutet das: ein Weg, neue Mandanten technisch anzubinden, statt für jeden neuen Händler eine eigene Lösung zu bauen.
Was es konkret regelt. Drei Bereiche stehen im Zentrum: die Anbindung (Auftragsübergabe vom Händler-System ins Fulfiller-Lager), der Lagerabgleich (Bestandsstände zwischen beiden Systemen synchron halten) und die Grundlage der Abrechnung (welche Mengen und Leistungen zwischen Händler und Fulfiller in Rechnung gestellt werden). Das FFN ist damit in erster Linie eine Prozess- und Datenbrücke, keine eigenständige Auswertungsplattform.
02 - Als Dienstleister teilnehmen
Voraussetzung. Wer als Fulfiller am JTL-FFN teilnehmen will, braucht eine laufende JTL-WaWi (eazybusiness) mit aktiviertem FFN-Modul. Ohne diese Basis gibt es keinen Zugang zum Netzwerk - das FFN ist kein separates System, sondern ein Aufsatz auf der bestehenden Warenwirtschaft.
Der Ablauf. Der Dienstleister legt ein Fulfiller-Profil im Netzwerk an und hinterlegt darin die Rahmendaten, die für Händler relevant sind: angebotene Leistungen (Kommissionierung, Verpackung, Retourenbearbeitung), Lagerstandorte, Kapazitäten und Konditionen. Über dieses Profil werden Fulfiller für Händler auffindbar und anbindbar. Die eigentliche technische Kopplung - Auftragsübergabe, Bestandsabgleich, Versandrückmeldung - läuft danach automatisiert über die FFN-Schnittstelle zwischen den beiden JTL-Installationen.
- Fulfiller-Profil mit Leistungen und Kapazitäten im Netzwerk anlegen und pflegen
- Mandanten-Setup in der eigenen WaWi so anlegen, dass FFN-Aufträge sauber einem Mandanten zugeordnet sind
- Bestandsführung und Cut-Off-Zeiten technisch mit dem Händler-System abstimmen, bevor der erste Live-Auftrag läuft
Typischer Stolperstein. Die technische Anbindung ist meist schneller erledigt als die organisatorische Vorbereitung. Wer FFN-Mandanten wie klassische 3PL-Mandanten ins bestehende Lager integriert - inklusive eigener Cut-Off-Zeit, eigener SLA-Zusage, eigenem Reporting-Bedarf - vermeidet, dass FFN-Aufträge im Betrieb zu einer Art Sonderfall werden, der separat behandelt werden muss. Wie Mandanten grundsätzlich sauber getrennt und ausgewertet werden, steht im Leitfaden zum Mandanten-Reporting.
03 - Was das FFN-Portal Händlern zeigt
Die Perspektive ist die des Händlers. Das FFN-Portal ist primär für den Händler gebaut, der seine Ware bei einem oder mehreren Fulfillern liegen hat. Er sieht darin im Wesentlichen drei Dinge: den aktuellen Bestand je Lagerort, Retouren, die im Fulfiller-Lager eingegangen sind, und ob die vereinbarten Cut-Off-Zeiten eingehalten wurden.
- Bestand je Artikel und Lager - was aktuell beim Fulfiller verfügbar ist
- Retouren, die dem Fulfiller-Lager zugegangen sind und den Bestand wieder erhöhen
- Eine Ja/Nein-Sicht auf eingehaltene Cut-Off-Zeiten je Auftrag oder Zeitraum
Was das für den Fulfiller bedeutet. Diese Sicht ist mandantenbezogen und bewusst schmal gehalten: Sie beantwortet dem Händler seine Frage ("Ist meine Ware da, kommt sie pünktlich raus"), nicht die Frage des Fulfillers ("Wie steht mein Betrieb insgesamt da, über alle Mandanten hinweg, und was beweise ich im nächsten Vertragsgespräch"). Das FFN-Portal ist ein Kunden-Frontend, kein Betriebs-Cockpit.
04 - Wo die native FFN-Auswertung endet
Kein vertragsfestes SLA-Reporting. "Eingehaltene Cut-Off-Zeit" ist eine binäre Information, keine belastbare SLA-Quote. Es fehlt die Logik, die ein Reporting vertragsfest macht: Werktage von Wochenenden und Feiertagen trennen, Rückhalte und Stornos aus der Wertung nehmen, unterschiedliche Fristen je Mandant sauber abbilden. Ohne diese Regeln ist jede Quote entweder zu streng (jedes Wochenende zählt als Bruch) oder zu grob, um im Kundengespräch zu bestehen.
Kein betriebsweiter Blick. Das FFN-Portal zeigt jedem Händler seine eigene Sicht - es aggregiert nicht über alle Mandanten hinweg zu einer Betriebssicht. Für den Fulfiller, der wissen muss, wie das gesamte Lager an einem Tag läuft, welcher Mandant welchen Anteil der Kapazität bindet und wo Engpässe entstehen, liefert die native FFN-Auswertung keine Antwort.
Keine Versandleistung pro Mitarbeiter. Personalsteuerung ist im FFN gar nicht vorgesehen. Wie viele Pakete ein Mitarbeiter pro Stunde schafft, wo Leistungsschwankungen zwischen Schichten liegen, welche Mandanten überproportional Kapazität binden - all das bewegt sich außerhalb dessen, was FFN als Anbindungsschicht abbilden soll.
Keine abrechnungsfeste Mengenbasis über Mandanten hinweg. Das FFN liefert die Grundlage der Abrechnung zwischen Händler und Fulfiller für den jeweiligen Mandanten. Ein konsolidierter Mengen-Export für die eigene Rechnungsstellung, der alle Mandanten - FFN und klassisch - in einer Struktur zusammenführt, ist damit nicht automatisch gegeben.
05 - Wie max.dash die Lücke schließt
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.
Das heißt konkret: Die Cut-Off-Information, die das FFN-Portal binär zeigt, wird im SLA-Reporting zu einer vertragsfesten Quote - mit Werktagslogik, Feiertagen und den individuellen Fristen jedes Mandanten. Die fehlende Betriebssicht entsteht im JTL-Dashboard, das alle Mandanten - FFN-Aufträge eingeschlossen - in einer gemeinsamen Ansicht zusammenführt, statt sie mandantenweise zu isolieren. Und die Mengenbasis für die eigene Rechnungsstellung liegt strukturiert in der Abrechnung, unabhängig davon, ob der Auftrag über das FFN oder klassisch angebunden wurde.
max.dash ersetzt das FFN dabei nicht - es liest neben der WaWi auch die über FFN abgewickelten Daten mit und ergänzt die Auswertungsebene, die das Netzwerk nicht mitbringt. Kein Plugin, keine Migration, kein Eingriff in die laufende Anbindung.
06 - Auch ohne FFN relevant
Die beschriebene Lücke - fehlendes SLA-Reporting, fehlender betriebsweiter Blick, fehlende Mitarbeiterleistung - besteht unabhängig davon, ob ein Fulfiller überhaupt am JTL-FFN teilnimmt. Wer ausschließlich klassische 3PL-Mandanten ohne FFN-Anbindung betreut, steht vor derselben Auswertungsfrage: Die JTL-WaWi speichert die Rohdaten, liefert aber keine vertragsfeste SLA-Quote und keine mandantengetrennte Leistungsauswertung von Haus aus. max.dash setzt an dieser Stelle unabhängig von der Anbindungsart an - für FFN-Mandanten genauso wie für Mandanten, die auf klassischem Weg angebunden sind.
Häufige Fragen
Was ist das JTL-Fulfillment-Network (JTL-FFN)?
Das JTL-FFN ist eine Vermittlungs- und Anbindungsschicht von JTL, die Händler-Systeme mit Fulfillment-Dienstleistern verbindet. Es standardisiert die technische Anbindung, den Bestandsabgleich und die Grundlagen der Abrechnung zwischen Händler und Fulfiller.
Wie wird man als Dienstleister Teil des JTL-Fulfillment-Network?
Voraussetzung ist eine laufende JTL-WaWi (eazybusiness) mit FFN-Modul. Der Dienstleister registriert sich als Fulfiller im Netzwerk, hinterlegt Leistungen, Lagerorte und Konditionen, und wird darüber von Händlern als Fulfillment-Partner gefunden und angebunden.
Was sieht ein Händler im FFN-Portal?
Händler sehen im FFN-Portal im Wesentlichen Bestand je Lager, Retouren und ob eingehaltene Cut-Off-Zeiten erfüllt wurden. Die Ansicht ist auf den einzelnen Händler zugeschnitten, nicht auf den Betrieb des Fulfillers als Ganzes.
Was fehlt in der nativen FFN-Auswertung für Fulfiller?
Die native FFN-Auswertung liefert keine vertragsfeste SLA-Quote mit Werktags- und Feiertagslogik, keinen betriebsweiten Blick über alle Mandanten hinweg und keine Versandleistung pro Mitarbeiter. Sie zeigt Bestand und Bewegung, aber keine Leistungs- und Vertragskennzahlen.
Brauche ich max.dash nur, wenn ich am JTL-FFN teilnehme?
Nein. max.dash liest die JTL-WaWi read-only aus und funktioniert unabhängig davon, ob ein Fulfiller FFN-Aufträge, klassische 3PL-Mandanten oder beides betreut. Die Reporting-Lücke bei SLA, Mitarbeiterleistung und Abrechnung besteht in beiden Fällen gleich.