Henning Groß
Geschäftsführer
Lassen Sie uns herausfinden, ob die Chemie stimmt. Ich melde mich persönlich.
Ein generischer Konnektor, der bezahlte Bestellungen als Merchant-Outbounds ins JTL-Fulfillment-Network überträgt, Status und Tracking-Codes zurückholt und Bestände abgleicht — asynchron, idempotent und upgrade-sicher gegen Shopware 6.6 und 6.7.
Ausgangslage
Wer sein Fulfillment ins JTL-Netzwerk gibt, muss Bestellungen dorthin bringen, Bestände zurückholen und Tracking-Nummern nachtragen. Von Hand ist das täglich, fehleranfällig und skaliert nicht — jede zusätzliche Bestellung macht die Handarbeit teurer, und jeder verpasste Bestandsabgleich riskiert einen Überverkauf.
Die Lösung
Wir haben einen generischen Shopware-Konnektor gebaut, der die JTL-Merchant-API in beide Richtungen bedient. Bezahlte Bestellungen gehen automatisch als Outbound raus, Status und Tracking kommen zurück in die Lieferung, der verkaufbare Bestand wird im festen Takt abgeglichen — asynchron über die Message Queue und idempotent, damit nichts doppelt läuft.
Der Markt zeigt
Ein ausgelagertes Lager entlastet nur dann, wenn Shop und Lager denselben Stand halten — ohne tägliche Handarbeit. Drei Marktzahlen und was mit dem Konnektor aus ihnen wird:
Mit dem Konnektor
0
manuelle Übertragungen
Bezahlte Bestellungen laufen automatisch als Outbound ins FFN — asynchron über die Message Queue. Kein Export, kein Upload, kein Nachtragen von Tracking-Nummern von Hand.
Ohne Anbindung: 60 % der Händler lagern ihr Fulfillment ganz oder teilweise aus. Ab dann müssen Shop und Lager permanent denselben Stand halten — sonst wird jede Bestellung zur Handarbeit.
Quelle: LogisticsMatter — When to Outsource Fulfillment (3PL Decision Guide)Mit dem Konnektor
15 Min.
Takt für Bestand & Status
Scheduled Tasks gleichen Bestand und Status inkrementell ab — im Standard alle 15 Minuten, mit einem Cursor in der Datenbank statt fragilem Datei-Pointer. Der Shop zeigt, was das Lager wirklich hat.
Ohne Anbindung: Im Handel liegt die Bestandsgenauigkeit im Schnitt bei nur 63 % — die häufigste Ursache für Überverkäufe und nachträgliche Stornos.
Quelle: Opensend — Inventory Accuracy Statistics for eCommerceMit dem Konnektor
100 %
der Sendungen mit Tracking
Tracking-Codes kommen aus den FFN-Shipping-Notifications automatisch in die Lieferung — zugeordnet über die gespeicherte Outbound-ID. Shopware verschickt die Versandbestätigung von selbst.
Ohne Anbindung: 86 % der Kunden erwarten Echtzeit-Updates zu ihrer Lieferung. Die Rückmeldung aus dem Lager darf keine Handarbeit sein.
Quelle: Statista 2022 (via proLogistik) — Sendungsverfolgung in EchtzeitDie Marktzahlen stammen aus unabhängigen Branchenquellen und beschreiben den Markt insgesamt. Die Konnektor-Werte beziehen sich auf den automatisierten Datenfluss der Integration, nicht auf ein zugesichertes Geschäftsergebnis.
Funktionsumfang
Sieben Bausteine decken den Kreislauf ab — vom Auftrags-Export über Status und Tracking bis zum Bestandsabgleich, in beide Richtungen und ohne Handarbeit.
Bezahlte Bestellungen gehen automatisch als Merchant-Outbound ins JTL-Fulfillment-Network — asynchron über die Shopware Message Queue, sodass kein API-Call den HTTP-Request blockiert. Die Payload folgt der aktuellen Merchant-API: Adresse, Positionen, Währung, Versandkosten und Kundenkommentar.
Auslöser: Sobald der konfigurierte Zahlungsstatus (Standard: „bezahlt“) erreicht ist — alternativ nur manuell, per CLI oder Administration
Übertragen werden ausschließlich echte Produktpositionen — Promotionen, Zuschläge und leere SKUs entfallen. Identische SKUs werden zu einer Outbound-Position zusammengeführt. Über SKU-Präfixe und exakte Produktnummern lassen sich Pfand- oder virtuelle Artikel gezielt ausschließen.
Auslöser: Bei jedem Export, vor dem Senden an das FFN
Bereits exportierte Bestellungen werden nicht erneut gesendet — außer bewusst mit --force. Fehlgeschlagene Exporte werden protokolliert; auf Wunsch überführt der Konnektor die Bestellung in einen Klärungsstatus, sofern die State Machine ihn kennt. Kein doppeltes Outbound, keine stillen Fehler.
Auslöser: Bei jedem Export sowie im Fehlerfall
Der Konnektor gleicht die Outbound-Änderungen inkrementell aus dem FFN ab und bildet die FFN-Status auf Shopware-Bestell- und Lieferstatus ab. Tracking-Codes kommen aus den Shipping Notifications direkt in die Lieferung — und Shopware verschickt die Versandbestätigung von selbst. Zugeordnet wird über die gespeicherte Outbound-ID, nicht über geratene Bestellnummern.
Auslöser: Scheduled Task, Standard alle 15 Minuten
Inkrementeller Abgleich über die FFN-Stock-Updates, dazu ein vollständiger Lagerabgleich nach Warehouse-ID und die Einzelabfrage einer FFN-SKU zum Vergleich mit Shopware. Der letzte Sync-Zeitpunkt liegt als Cursor in der Datenbank — nicht in einer Plugin-Datei, die ein Deployment überschreibt.
Auslöser: Scheduled Task, Standard alle 15 Minuten · zusätzlich manuell
Ein eigenes Admin-Modul zeigt den Verbindungstest samt verfügbarer Lager, erlaubt den manuellen Bestands- und Statusabgleich und listet alle Outbounds inklusive Fehler und Sync-Status. In der Bestelldetailansicht sitzt eine Karte zum Export bzw. zur erneuten Übertragung — ohne Log-Zugriff.
Auslöser: Manuell im Backend
Für Betrieb und Fehlersuche gibt es Konsolenbefehle für Verbindungstest, Lagerliste, Export, Status- und Bestandssync sowie SKU-Lookup. Ausführliche Vorgänge landen in rotierenden Plugin-Logs unter var/log — sauber getrennt vom Shop-Log.
Auslöser: Automatisch über Scheduled Tasks · on demand über die CLI
Unter der Haube
Der Export ist als saubere Pipeline gebaut — jede Schicht hat genau eine Aufgabe. Das hält den Konnektor upgrade-sicher und nachvollziehbar.
Ein Subscriber nimmt den Zahlungs-Statuswechsel entgegen und dispatcht eine Nachricht — er ruft selbst keine API auf.
Die ExportOutboundMessage wird asynchron abgearbeitet. Der Checkout wartet nie auf das FFN.
Der OutboundExportService baut die Payload, der schlanke HTTP-Client spricht die Merchant-API direkt über Shopwares Symfony-HTTP-Client an.
Die Verbindung Bestellung ↔ FFN-Outbound liegt in netzkom_jtl_ffn_outbound — bewusst ohne Fremdschlüssel auf die versionierte Bestellung.
Statt des offiziellen SDK mit veralteten Abhängigkeiten spricht der Konnektor die REST-API über einen schlanken Client an — weniger Angriffsfläche, nachvollziehbare Requests, store-tauglich.
Der Kern trägt keine kundenspezifische Geschäftslogik, Subscriber und Controller rufen keine API direkt auf — alles läuft über dieselben Services.
Der letzte Sync-Zeitpunkt steht in netzkom_jtl_ffn_sync_cursor statt in einer Plugin-Datei — ein Deployment setzt den Abgleich nicht zurück.
Voraussetzungen & Konfiguration
Alles steckt in der Plugin-Konfiguration — von den Zugangsdaten über das Lager bis zu den Sync-Intervallen. Die Lager-ID liefert ein Konsolenbefehl.
Upgrade-sicher gegen beide Generationen entwickelt.
Aktueller Sprachstand, keine Alt-Abhängigkeiten.
messenger:consume verarbeitet die Exporte asynchron.
Application-ID, Token und Warehouse-ID aus dem JTL-FFN.
API-Basis-URI
Produktiv
https://ffn.api.jtl-software.com/api/v1Sandbox
https://ffn-sbx.api.jtl-software.com/api/v1Konfiguriert werden Aktivierung, Auto-Export und Auslöser, Zugangsdaten, Warehouse-ID und Versandart, SKU-Ausschlüsse sowie Sync-Intervalle, Seitengröße und Fehlerverhalten.
Konsolenbefehle
bin/console netzkom:jtl-ffn:test-connection
bin/console netzkom:jtl-ffn:warehouses
bin/console netzkom:jtl-ffn:export-orders --order-number=10001
bin/console netzkom:jtl-ffn:sync-stock --full
bin/console netzkom:jtl-ffn:sync-status
bin/console netzkom:jtl-ffn:stock --jfsku=JFSKU123Für Betrieb und Fehlersuche: Verbindungstest, Lagerliste, gezielter Export, Bestands- und Statussync sowie SKU-Lookup — dieselben Services wie Admin und Scheduled Tasks.
Einblicke
Der Konnektor bleibt nicht im Hintergrund: vom Verbindungstest mit Lagerliste über die Outbound-Übersicht mit Sync-Status bis zur FFN-Karte in der Bestelldetailansicht ist jeder Zustand direkt im Backend ablesbar.
Das Fulfillment-Netzwerk
Das JTL-Fulfillment-Network verbindet Onlinehändler mit Fulfillment-Dienstleistern: Bestellungen werden als Merchant-Outbounds eingelagert, kommissioniert und versendet, Bestände und Versandstatus fließen über die Merchant-API zurück. Unser Konnektor spricht diese API direkt an — ohne gebündeltes SDK, mit einem schlanken HTTP-Client auf Shopware-Basis. Das ist die Grundlage für den automatischen Auftrags-Export, den Status- und Tracking-Rücklauf und den inkrementellen Bestandsabgleich.
Mehr zum JTL-Fulfillment-NetworkVorgesehen für den Shopware Store. Der Konnektor ist store-tauglich geschnitten: eigenes composer.json ohne gebündelte vendor-Abhängigkeiten, Logs nur unter var/log, Administration mit lesbaren Quellen — und MIT-lizenziert.
Einmal eingerichtet, läuft der Kreislauf von selbst: Bestellung raus ins FFN, Status und Tracking zurück in die Lieferung, Bestand im festen Takt abgeglichen — kein manueller Schritt bleibt übrig, und jeder Kunde bekommt seine Sendungsverfolgung, ohne dass jemand sie abtippt.
Gründer · Persönlich am Telefon