Neu JTL-Wawi DHL Worker – DHL API, DirectJTL, OTTO-Retoure & Auto-Druck – All-in-One

[NikuTRAX]

Hallo zusammen,

ich habe einen kleinen DHL-Worker für JTL-Wawi gebaut, den ich hier neutral zur Verfügung stellen möchte.

Der Worker übernimmt einen CSV-Export aus JTL-Wawi, erzeugt die Sendungen direkt über die DHL Paket API und schreibt anschließend Trackingnummer und Versanddatum direkt in die JTL-Datenbank zurück.

Damit ist kein Versanddatenimport und auch kein automatischer Import in JTL erforderlich.

Der Worker arbeitet dabei unabhängig von JTL Shipping 2.0. Für die eigentliche Versandabwicklung wird keine JTL Shipping 2.0 API und keine JTL-REST-API benötigt.

Die Kommunikation erfolgt im Wesentlichen direkt zwischen:

JTL-Wawi
↓
CSV-Export
↓
DHL-Worker
↓
DHL Paket API
↓
Tracking + Versanddatum direkt zurück nach JTL

Die DHL-Versandabwicklung erfolgt damit unabhängig von der in JTL integrierten Versand-API.

Funktionen​

Unterstützt werden aktuell:

• DHL Paket DE
• DHL Kleinpaket
• DHL Paket International / EU
• OTTO-Versand mit DHL-Retoure
• direkter Tracking-Eintrag in JTL
• automatisches Versanddatum
• optionaler automatischer Labeldruck über separaten Print-Agent
• Schutz gegen Doppelbuchungen
• Sandbox- und Production-Modus

Wichtig: kein Versanddatenimport in JTL​

Bei den verwendeten Versandarten sollte kein Versanddatenimport / Tracking-Import eingerichtet werden.

Auch ein automatischer Import ist nicht notwendig.

Der Ablauf ist:

JTL-Wawi
↓
CSV-Export
↓
DHL-Worker
↓
DHL Paket API
↓
Tracking + Versanddatum direkt zurück nach JTL

Die CSV dient also ausschließlich als Übergabe von JTL an den Worker.

Es findet anschließend kein CSV-Rückimport nach JTL statt.

Kein JTL Shipping 2.0 / keine JTL-REST-API erforderlich​

Der Worker verwendet für die Versandabwicklung nicht JTL Shipping 2.0 und nicht die JTL-REST-API.

Die Versanddaten werden aus dem CSV-Export übernommen und direkt an die DHL Paket API übertragen.

Nach erfolgreicher Erstellung der Sendung werden Trackingnummer und Versanddatum direkt in der JTL-Datenbank aktualisiert.

Verwendet werden damit im Wesentlichen:

• JTL-Wawi CSV-Export
• DHL Paket API
• direkter SQL-Zugriff auf die JTL-Datenbank

Eine zusätzliche JTL-Versand-API ist für diesen Ablauf nicht erforderlich.

DirectJTL​

Nach erfolgreicher DHL-Buchung wird die Trackingnummer direkt in:

tVersand.cIdentCode

geschrieben.

Bei einer OTTO-Retoure zusätzlich in:

tVersand.cEnclosedReturnIdentCode

Das Versanddatum wird ebenfalls gepflegt.

Ist:

tVersand.dVersendet

noch leer, wird der aktuelle Zeitpunkt gesetzt.

Anschließend wird derselbe Wert nach:

tBestellung.dVersandt

übernommen.

Dadurch erscheint das Versanddatum auch in der normalen JTL-Auftragsübersicht.

OTTO​

Für OTTO kann eine eigene Versandart verwendet werden, z. B.:

DHL Otto

Der Worker erzeugt dabei:

Hinweg:

tVersand.cIdentCode

Retoure:

tVersand.cEnclosedReturnIdentCode

Das Retourenlabel wird nicht zusammen mit dem normalen Versandlabel gedruckt.

Die Retouren-Sendungsnummer bleibt trotzdem erhalten und kann von JTL bzw. OTTO verwendet werden.

Print-Agent​

Im Paket befindet sich zusätzlich ein kleiner Print-Agent.

Dieser überwacht den Labelordner und druckt neue DHL-PDFs automatisch über PDF24 auf einen frei konfigurierbaren Drucker.

Druckername, Labelordner und PDF24-Pfad werden separat konfiguriert.

Nach erfolgreichem Druck werden die Dateien archiviert, damit sie beim nächsten Start nicht erneut gedruckt werden.

Retouren-Dateien mit entsprechenden Dateinamen werden vom automatischen Druck ausgeschlossen.

Sicherheitsmechanismen​

Der Worker prüft vor einer Buchung unter anderem:

• PaketRef
• Lieferschein
• Versandart
• vorhandene Trackingnummer
• vorhandenen State

Nach einer erfolgreichen DHL-Buchung wird sofort ein lokaler State gespeichert.

Falls anschließend beispielsweise der SQL-Zugriff fehlschlägt, wird beim nächsten Lauf nicht erneut bei DHL gebucht, sondern nur das fehlende JTL-Update nachgeholt.

Die Datenbankänderungen erfolgen innerhalb einer SQL-Transaktion.

Damit soll verhindert werden, dass bei einem Fehler nach erfolgreicher DHL-Buchung versehentlich eine zweite Sendung erzeugt wird.

Installation​

1. ZIP-Datei entpacken, z. B.:

C:\JTL-DHL\

1. config.example.json nach config.json kopieren.
2. Eigene Daten eintragen:

• DHL API-Zugang
• DHL-Abrechnungsnummern
• SQL-Server
• JTL-Datenbank
• Absenderadresse
• Ordner
• OTTO-Retourenadresse
• OTTO-Retouren-Abrechnungsnummer

1. Zunächst Sandbox verwenden:

"Environment": "Sandbox"

1. JTL-CSV-Export einrichten.
2. Testauftrag erzeugen und Sandbox testen.
3. Erst danach Production-Zugang einrichten.
4. Production zunächst nur im Validierungsmodus testen.
5. Erst nach erfolgreicher Prüfung den automatischen Production-Betrieb aktivieren.

JTL-Versandarten​

Bei den Versandarten, die über den Worker verarbeitet werden, sollte kein zusätzlicher automatischer Versanddatenimport eingerichtet werden.

Insbesondere sollte nicht parallel versucht werden, dieselben Trackingdaten über einen separaten CSV-Import wieder in JTL einzulesen.

Der Worker trägt die Trackingnummer direkt selbst in JTL ein.

Auch ein automatischer Import der erzeugten Trackingdateien ist daher nicht erforderlich.

CSV-Export​

Erwartete Kopfzeile:

PaketRef;Lieferschein;Versandart;Vorname;Nachname;Firma;Adresszusatz;Strasse;Hausnummer;PLZ;Ort;LandISO;Email;Telefon;Mobil;Gewicht

Beispiel:

P1234;1234-001;Versicherter Versand DHL;Max;Mustermann;;;Musterstrasse;1;12345;Musterstadt;DE;;;;0,50

PaketRef entspricht dem jeweiligen kVersand.

Beispiel:

P1234 → kVersand 1234

Enthalten​

Das All-in-One-Paket enthält:

• Server / Worker
• Print-Agent / Client
• Beispielkonfigurationen
• Production-Zugang-Setup
• Sandbox-Startdateien
• Production-Validierung
• Production-Automatik
• CSV-Beispiel
• CSV-Kopfzeile
• README

Technischer Ablauf​

Der komplette Ablauf sieht vereinfacht so aus:

JTL-Wawi erzeugt CSV
↓
Worker erkennt neue CSV
↓
Versanddaten werden geprüft
↓
Sendung wird direkt über die DHL Paket API erzeugt
↓
DHL liefert Label und Trackingnummer
↓
Label wird gespeichert
↓
Trackingnummer wird direkt in tVersand.cIdentCode geschrieben
↓
Versanddatum wird in tVersand.dVersendet gesetzt
↓
Versanddatum wird nach tBestellung.dVersandt übernommen
↓
optional druckt der Print-Agent das Label automatisch

Ein zusätzlicher Versanddatenimport nach JTL ist nicht notwendig.

Hinweis​

Der Worker greift direkt schreibend auf die JTL-Datenbank zu.

Daher bitte unbedingt zuerst:

• Datenbanksicherung erstellen
• Testauftrag verwenden
• Sandbox testen
• SQL-Zugang prüfen
• Production zunächst nur validieren
• erst danach Production freigeben

Der Worker verwendet für die Versandabwicklung nicht JTL Shipping 2.0 und nicht die JTL-REST-API, sondern kommuniziert direkt mit der DHL Paket API.

Die Rückmeldung von Trackingnummer und Versanddatum erfolgt anschließend direkt über die JTL-Datenbank.

Das Ganze ist kein offizielles JTL- oder DHL-Plugin, sondern eine eigene Automatisierung.

Bei Änderungen an der JTL-Datenbankstruktur oder an der DHL API kann eine Anpassung notwendig werden.

Nutzung daher auf eigene Verantwortung und bitte zunächst immer mit Testaufträgen bzw. in der Sandbox prüfen.

Aktueller Stand des Pakets:

v1.13 All-in-One Server + Client

 

[KristinaS]

Tolle Arbeit, Dankeschön. Läuft 🎉 und fühlt sich fast genauso an im Betrieb wie die Shipping 1.0 Anbindung, vielleicht 1-2 Sekunden langsamer. Stört hier aber nicht, weil hier in der Zwischenzeit ohnehin schon die Ware für die nächste Auslieferung zurechtgelegt wird.

Amazon Kunden aufgepasst: Zumindest bei mir wird die Sendungsnummer erst nach Veranlassung der Versanddatenübermittlung an Amazon eingetragen, so dass die erste automatische Übermittlung fehlschlägt. Am Tagesende oder nach Versandschluss daher einmal alle Auslieferung MFN an Amazonkunden im Versandmenü einmal im Block anwählen und die erneute Übertragung der Versanddaten an Amazon veranlassen. Ob es geklappt hat, seht ihr ein paar Minuten später in Eurer Sellercentral Auftragsübersicht. Vielleicht gibts dafür auch noch eine automatische Lösung? Dann her damit, ich habe noch keine gefunden.

Um es Euch ein wenig einfacher zu machen, gibt es von mir noch
- die Exportvorlage für den JTL-Versand-Export zum DHL-Worker
=> siehe unten angehängte zip-Datei
- den Codeblock für die Datei JTL-DHL-Worker.ps1 für die Aktivierung des Zusatzservices "Filial-Routing" zum DHL Kleinpaket (wer es braucht, kann es auch für Pakete auf gleiche Weise ergänzen) und "Premium" zur Warenpost International:
(ersetze in deiner Funktion den Bereich ab $shipment = [ordered]@{ bis einschließlich der drei schließenden Klammern darunter durch diesen Code):

$shipment = [ordered]@{
product = $Product
billingNumber = $Billing
refNo = ([string]$Row.Lieferschein)
shipper = $shipper
consignee = (Build-Consignee $Row)
details = [ordered]@{
weight = [ordered]@{
uom = 'kg'
value = $WeightKg
}
}
}

# DHL-Zusatzservices je Produkt
switch ($Product) {
'V62KP' {
$recipientEmail = ([string]$Row.Email).Trim()

if ([string]::IsNullOrWhiteSpace($recipientEmail)) {
throw "Filialrouting für DHL Kleinpaket benötigt die Empfänger-E-Mail-Adresse aus der CSV."
}

$shipment['services'] = [ordered]@{
parcelOutletRouting = $recipientEmail
}
}

'V66WPI' {
$shipment['services'] = [ordered]@{
premium = $true
}
}
}

- den zusätzlichen Codeblock für die Datei JTL-DHL-Worker.ps1 zur Integration von Warenpost International Premium (nur EU) (falls jemand nur einfache Warenpost International (EU) benötigt, das Premium weglassen und den Codeblock für den zusätzlichen Service "Premium" (vorangegangener Block) nicht einbauen):

'Warenpost International Premium' {
if ($country2 -eq 'DE') {
throw "Versandart 'Warenpost International Premium' ist für EU-Ausland gedacht, Ziel ist aber Deutschland."
}
if (-not (Test-IsEuCountry $country2)) {
throw "Versandart 'Warenpost International Premium' wird nur für EU-Länder automatisch gebucht. Ziel '$country2' bleibt für Zoll/International bewusst manuell."
}
if ($WeightKg -gt 1) {
throw "DHL Paket International Premium darf in diesem Worker höchstens 1 kg wiegen. CSV: $WeightKg kg."
}
return @{
Product = 'V66WPI'
Name = 'Warenpost International Premium'
Country = $country2
IsOtto = $false
}
}

Allen gutes Gelingen!

MfG Kristina

 

[dc-nico]

Hallo, ich hatte mir auch schon einen Export über Worker gebastelt, jedoch sieht es hier ja nun deutlich besser aus.
Werde das Ganze dann ein mal probieren.
Es wundert mich, dass so wenig Resonanz vorhanden ist, da hier ja enorme Mehrkosten auf alle User der Shipping 2.0 Schnittstelle zukommen.
Da es bei der Internetmarke auch zu Mehrkosten kommt, war ich auch hier schon dabei, ein Programm zu schreiben.
Mich wundert es nur etwas, dass die API freigeschalten wird, jedoch bei der Internetmarke noch kein Programm zur Freigabe angezeigt wird.

Gruß, Nico

 

[KristinaS]

Für alle, die sofort eine Lösung brauchen für bestimmte häufig genutzte Internetmarken und wegen preissensibler Kunden
(die kennen wir alle: das Porto kostet doch nur 1,80 € - warum wird mir mehr berechnet - eure Mitarbeiter in Versand und Buchhaltung arbeiten doch alle umsonst und Steuern oder Verpackungslizenzgebühren müsst ihr ja auch nicht bezahlen 😅 **Ironie aus**)
hier noch eine ganz pragmatische (Zwischen)Lösung zur Internetmarke:

• die am häufigsten genutzten Internetmarkentarife umstellen auf manuelle Trackingnummerneingabe und ohne Versanddatenexport aber mit Versandetikettdruck (reines Adressetikett)
• gleich eine ordentliche Anzahl Internetmarken im Post Onlineshop auf Vorrat kaufen
• euren Stammnummernkreis der Internetmarken (Markennummern ohne die letzen 3-4 Stellen) in der Zwischenablage anpinnen und dann
• ganz normal ohne Versanddatenexport versenden. Packtisch+ fragt dann nach Sendungsnummer, ihr sucht euch eine vorab gekaufte Marke aus, fügt per Copy&Paste Euren Nummernkreisstamm aus der Zwischenablage ein + die letzten 3-4 Stellen eurer soeben ausgewählten Marke
• Marke aufkleben
• FERTIG 😀.

Es mag nun jeder selbst entscheiden, ob der seperate Markenkauf auf Vorrat und das Eingeben von den paar Ziffern 0,10 € pro Marke wert ist...

Für alle, die wirklich viel versenden, ist dann eine Workerlösung natürlich besser, aber bis dahin können wir es erst einmal pragmatisch angehen... 💪

 

[dc-nico]

Wer seine Produktpreise nicht dauerd anheben möchte, muss eben auf diese ständigen Preiserhöhungen achten und reagieren.
Das mit der Internetmarke ist eigentlich eine Kleinigkeit.
Nur muss man die API erst an die Internetmarke angebunden bekommen, was etwas Umständlich ist.
Wenn ich es geschafft habe, kann ich das kleine Programm aber gerne auch hier bereitstellen.
Allerdings über einen kleinen Export aus der Wawi, da ich jetzt nicht direkt auf die DB zugreifen möchte.

 

[NikuTRAX]

JTL-DHL-Worker v1.14 – DHL Shipping API v2 mit direkter JTL-Anbindung​

Hallo zusammen,

ich stelle eine aktualisierte Version meines PowerShell-basierten DHL-Workers für JTL-Wawi zur Verfügung.

Der Worker verarbeitet CSV-Versanddaten aus JTL-Wawi, erstellt DHL-Versandlabels über die DHL Shipping API v2 und schreibt die Trackingnummern automatisch in die JTL-Datenbank zurück.

Zusätzlich kann er den Versandstatus für angebundene Verkaufskanäle wie Amazon, eBay, Kaufland und den eigenen Onlineshop zur Übermittlung vormerken.

Die Lösung wurde unter JTL-Wawi 2.1.2 entwickelt. Die automatische Versandstatus-Rückmeldung funktioniert in meiner Installation bereits erfolgreich.

Changelog v1.14​

• DHL Warenpost International Premium für EU-Ziele ergänzt
• Verbesserte Behandlung von DHL-API-Warnungen
• Erweiterte Protokollierung der DHL-API-Parameter
• Optimierte Übermittlung von Empfängernamen
• Automatische Tracking-Rückschreibung in JTL-Wawi
• Versandstatus-Rückmeldung für Marktplätze optional aktivierbar
• Amazon-Versandmeldung über die entsprechende JTL-SQL-Struktur
• Mandantenspezifische Firmenangaben und feste Abrechnungsnummern entfernt
• Schutz vor parallelem automatischem Produktionsbetrieb

1. Vorhandenen DHL-Worker sichern​

Vor dem Austausch unbedingt den bisherigen Worker beenden.

Falls er über die Windows-Aufgabenplanung oder ein Startskript automatisch gestartet wird, zunächst diesen automatischen Start deaktivieren.

Im bisherigen Programmverzeichnis befindet sich beispielsweise:

JTL-DHL-Worker.ps1

Diese Datei umbenennen in:

JTL-DHL-Worker-v1.13-Backup.ps1

Damit bleibt die vorherige Version erhalten.

Wichtig: Die vorhandene config.json, DHL-Zugangsdaten, Labelverzeichnisse, Tracking-Sicherungen und Statusdateien nicht löschen oder überschreiben.

2. Neue Version installieren​

Die heruntergeladene Datei:

JTL-DHL-Worker-v1.14.ps1

in das bisherige Worker-Verzeichnis kopieren.

Anschließend die neue Datei umbenennen in:

JTL-DHL-Worker.ps1

Dadurch kann die vorhandene Aufgabenplanung beziehungsweise das bisherige Startskript in der Regel weiterverwendet werden, sofern dort genau dieser Dateiname hinterlegt ist.

Wer beide Versionen parallel aufbewahren möchte, kann auch den neuen Dateinamen beibehalten. Dann müssen allerdings die entsprechenden Startbefehle angepasst werden.

Achtung: Beide Versionen dürfen nicht gleichzeitig produktiv laufen.

3. Konfiguration übernehmen und prüfen​

Die vorhandene config.json kann grundsätzlich weiterverwendet werden, sofern sie alle vom Worker benötigten Einstellungen enthält.

Vor dem Start kontrollieren:

• DHL-API-Zugangsdaten
• Sandbox- und Production-Einstellungen
• DHL-Abrechnungsnummern je Versandprodukt
• Export-, Label-, Import- und Statusverzeichnisse
• JTL-SQL-Server und Mandantendatenbank
• Absenderreferenz beziehungsweise Absenderdaten
• Verwendete Versandartbezeichnungen aus JTL

Für DHL Warenpost International muss die passende Abrechnungsnummer für das DHL-Produkt V66WPI hinterlegt sein.

Bei Verwendung von OTTO-Retouren müssen außerdem OttoReturnBillingNumber und OttoReturnAddress in der Konfiguration vorhanden sein.

Es sind keine festen Zugangsdaten oder mandantenspezifischen Abrechnungsnummern in der Community-Version hinterlegt.

4. Automatische Marktplatz-Versandmeldung aktivieren​

Standardmäßig ist die zusätzliche SQL-basierte Versandstatus-Rückmeldung deaktiviert.

Die reguläre Erstellung von DHL-Labels und die direkte Tracking-Rückschreibung in JTL bleiben davon unberührt.

Wer auch den Versandstatus für angebundene Verkaufskanäle automatisch vormerken möchte, ergänzt in seiner config.json auf oberster Ebene:

"EnableExperimentalShippingStatusSql": true,
"AmazonPlatformId": 51
Die Angabe AmazonPlatformId: 51 stammt aus meiner Installation.

Wichtig: Die Plattform-ID muss vor der Aktivierung anhand der eigenen JTL-Datenbank geprüft werden. Sie ist nicht für jede Installation verbindlich.

Der Amazon-Sonderweg unterstützt in dieser Version ausschließlich eindeutig zuordenbare Bestellungen mit einer Position. Mehrpositions- und Teillieferungen werden aus Sicherheitsgründen nicht automatisch über diesen Weg gemeldet.

Wer die Amazon-Sonderlogik nicht verwenden möchte, setzt:

"AmazonPlatformId": 0
Die zusätzliche SQL-Rückmeldung sollte ausschließlich aktiviert werden, wenn die betreffenden Datenbanktabellen und Zuordnungen überprüft wurden.

5. Neue Version zunächst testen​

Nach dem Austausch sollte zunächst eine DHL-Validierung ohne echte Labelbuchung durchgeführt werden.

Beispiel für einen einmaligen Test mit einer vorhandenen CSV-Datei:

.\JTL-DHL-Worker.ps1 -ValidateOnly -SpecificFile "test.csv"
Dabei müssen die Einstellungen in config.json zur gewählten Sandbox- beziehungsweise Production-Umgebung passen.

Eine erfolgreiche API-Validierung bedeutet noch nicht, dass die vollständige Tracking-Rückschreibung oder Marktplatzmeldung getestet wurde.

Diese Funktionen anschließend mit einer geeigneten Testbestellung kontrollieren.

Vor einem produktiven Test unbedingt eine vollständige Sicherung der JTL-Datenbank erstellen.

6. Produktivbetrieb wieder aufnehmen​

Nach erfolgreicher Prüfung kann der bisherige automatische Worker-Start wieder aktiviert werden.

Dabei kontrollieren:

1. Wird die CSV-Datei korrekt erkannt?
2. Wird das richtige DHL-Produkt ausgewählt?
3. Wird genau ein Versandlabel erstellt?
4. Wird die Trackingnummer in JTL übernommen?
5. Wird das Versanddatum korrekt gesetzt?
6. Wird bei aktivierter Zusatzfunktion die Versandmeldung an den jeweiligen Verkaufskanal übermittelt?

Das Log enthält zusätzliche Angaben zum verwendeten DHL-Produkt, zur Abrechnungsnummer und zum Premium-Service.

Bei Problemen den automatischen Betrieb zunächst stoppen und die Logdateien sowie gespeicherten Versandstatusdaten prüfen.

Bereits bei DHL gebuchte Sendungen dürfen nicht versehentlich erneut gebucht werden.

7. Wichtige technische Hinweise​

Der Worker verwendet eine direkte SQL-Anbindung an JTL-Wawi.

Diese Vorgehensweise ist nicht mit einer offiziell dokumentierten und versionsstabilen JTL-Schnittstelle gleichzusetzen. Datenbankänderungen durch JTL-Updates können Anpassungen erforderlich machen.

Die automatische Versandstatus-Rückmeldung wurde in meiner ursprünglichen Installation erfolgreich eingesetzt. Daraus lässt sich jedoch keine allgemeine Kompatibilität mit anderen Mandanten oder JTL-Versionen ableiten.

Die zusätzliche SQL-Funktion ist deshalb in der Community-Ausgabe standardmäßig deaktiviert.

DHL Warenpost International wird aktuell nur für EU-Auslandssendungen bis 1 kg automatisch unterstützt. Eine vollständige Zollabwicklung für Drittländer ist noch nicht implementiert.

8. Haftung und Support​

Bei diesem Worker handelt es sich um ein kostenlos bereitgestelltes Community-Projekt.

Es ist keine offizielle Erweiterung von JTL oder DHL.

Die Verwendung erfolgt auf eigene Verantwortung. Vor einem Produktiveinsatz sollten die Datenbankstruktur, DHL-Vertragsprodukte und Versandprozesse sorgfältig geprüft werden.

Verbesserungsvorschläge, Fehlermeldungen und Erfahrungen mit weiteren JTL-Versionen sind willkommen.

Datei: JTL-DHL-Worker-v1.14.ps1

Getestete Ausgangsumgebung: JTL-Wawi 2.1.2, Windows/PowerShell, DHL Paket Shipping API v2.

 

[John]

@NikuTRAX tolle Arbeit! Etwas verwirrend, weil die erste Version, die Du hier gepostet hast auch bereits mit Version 1.13 benannt war...

 

[NikuTRAX]

@NikuTRAX tolle Arbeit! Etwas verwirrend, weil die erste Version, die Du hier gepostet hast auch bereits mit Version 1.13 benannt war...

@John
Vielen Dank! 😊

Du hast natürlich recht, die Versionsbezeichnung war etwas unglücklich gewählt.

Die erste Veröffentlichung war bereits als v1.13 bezeichnet. Bei der anschließenden Überarbeitung hatte ich die Versionsnummer versehentlich beibehalten.

Ich habe die aktuelle Datei deshalb jetzt in v1.14 umbenannt, damit die Versionen eindeutig unterschieden werden können.

Künftig werde ich die Versionsnummer bei jeder Änderung konsequent hochzählen.

Danke für den Hinweis und das positive Feedback!

 

[KristinaS]

JTL-DHL-Worker v1.13 – DHL Shipping API v2 mit direkter JTL-Anbindung​

Hallo zusammen,

ich stelle eine aktualisierte Version meines PowerShell-basierten DHL-Workers für JTL-Wawi zur Verfügung.

Wow @NikuTRAX - das ging ja mal schnell! DANKESCHÖN für die rasche Umsetzung! Solche Geschwindigkeiten sind wir als JTL-Nutzer gar nicht gewöhnt 🤣 Und dann auch noch ohne Servicelevelbuchung! ✨

Die neue Version werde ich noch heute abend testen!

Vielleicht sollten uns alle auch außerhalb dieses Forums vernetzen, für den Fall, dass diesem Chat hier aus Gründen demnächst etwas zustößt...oder zumindest schon mal eine Headline für GitHub vereinbaren, damit man sich auch unabhängig von diesem Forum hier für solche Projekte wiederfinden kann... Schreibt mir gerne eine PN, wenn ihr das auch so seht...

🤗 Kristina

 

[Morimus]

oder zumindest schon mal eine Headline für GitHub vereinbaren

ch weiß zwar nicht, was du mit einer „Headline für GitHub“ meinst, aber dass das Projekt kein öffentliches Git-Repository hat, ist tatsächlich einer der Gründe, warum ich es mir bislang nicht genauer angeschaut habe.
Dabei ist das Ganze echt clever gebaut! 😀


@NikuTRAX
Die DHL-Sandbox ist weiterhin nicht sauber von der JTL-Datenbank getrennt.
Wer die DHL-Sandbox testet, während der Worker auf die produktive JTL-Datenbank zeigt, kann bei einem regulären Lauf ohne -ValidateOnly echte Versanddaten verändern.

Hier würde ich mir eine zusätzliche Absicherung wünschen, die SQL-Schreibzugriffe im Sandbox-Modus grundsätzlich verhindert.


Eine doppelte DHL-Buchung ist weiterhin möglich.
Du versuchst das mit den JSON-Statusdateien zu verhindern.
Der Ansatz ist auch gut, allerdings ist die Reihenfolge problematisch.

Zeile 1460: Die DHL-Sendung wird erstellt.

Zeilen 1476–1477: Label und Tracking-Backup werden gespeichert.

Zeile 1497: Erst jetzt wird die Statusdatei geschrieben.

Wenn DHL die Sendung erfolgreich angelegt hat, danach aber beispielsweise das Speichern des Labels scheitert, existiert möglicherweise noch keine Statusdatei.
Beim nächsten Versuch kann der Worker dieselbe Sendung erneut buchen, sofern auch JTL noch keine Trackingnummer enthält.
Dein Schutz funktioniert also in vielen Fällen, aber nicht zuverlässig in sämtlichen Fehlersituationen.


Interessant finde ich auch die SQL-Profiler-Mitschnitte vom 05.10.2026, auf deren Grundlage du offenbar Teile der internen JTL-Versandprozesse nachgebildet hast.
Grundsätzlich ein interessanter Ansatz! 😅

Allerdings wäre hier wichtig zu wissen, auf welcher konkreten JTL-Wawi-Version diese Mitschnitte durchgeführt wurden.
Gerade bei direkten SQL-Eingriffen können sich Änderungen an der Datenbankstruktur oder den internen Abläufen zwischen verschiedenen JTL-Versionen schnell zum Problem entwickeln.

Und genau deshalb würde ich mir für dieses Projekt ein öffentliches GitHub-Repository wünschen.
Mit einer vernünftigen README, einer nachvollziehbaren Versionshistorie, Angaben zu unterstützten JTL-Versionen und idealerweise dokumentierten Testfällen.

Das soll keine Kritik an deiner Arbeit sein.
Im Gegenteil, ich finde es klasse, dass du eine solche Lösung kostenlos zur Verfügung stellst!

 

[John]

Gibts für "als verschickt setzen" wirklich keine StoredProcedure, die man nutzen kann?
Oder irgendetwas anderes, das man nutzen könnte?

Das alles händisch in SQL sieht mir pflegeintensiv aus.
Wenn ich die Fallunterscheidung für unterschiedliche Spalten in der pf_amazon_bestellung schon sehen....puh.

 

[Morimus]

Zumindest eine Stored Procedure, die in diese Richtung geht, gibt es.

Auslieferung.spPicklistenAusliefern_PaketeErzeugen
Die hat folgende Parameter:
@Pakete xml
@nVersandSetzen int
@kBenutzer int
@kSessionId int

Wenn @nVersandSetzen > 0 ist, wird beim Erzeugen der Pakete das Versanddatum gesetzt.

Das ding ist, die Prozedur arbeitet mit INSERT INTO dbo.tVersand.
Sie erzeugt also neue Paketdatensätze im Rahmen der Picklisten-Auslieferung und aktualisiert nicht einfach bereits vorhandene Sendungen.

Glaube ich...

 

[John]

Hmm, wie tot ist die jtlWawiExternal.dll?

https://developer.jtl-software.com/...on/jtl-wawi-legacy/VersanddatenimportBeispiel

 

[Morimus]

Puh, ich habe 2025 aufgehört mit der dll zu arbeiten, weil manche Workflows darüber nicht zuverlässig ausgelöst wurden.

Hat WMS nicht ohnehin einen integrierten Versanddatenimport?

 

[TheEnd]

@NikuTRAX Ich muss ebenfalls deine kreative Lösung loben, darauf bin ich nicht gekommen. 😀

Die komplette Architektur halte ich jedoch für sehr instabil, besonders weil sich der Code zu sehr auf einige wenige Abhängigkeiten stützt.
Auf der einen Seite hat JTL Geld investiert, um an den Starter Kunden mehr Geld zu verdienen, auf der anderen Seite benötigt JTL in der Regel 3-5 Jahren für eine wichtige Änderung, wenn es denn überhaupt geändert wird. Die Chancen stehen also gut, dass ihr mit der Taktik gut durchkommen werdet.. 😂

 

[ple]

Github würde ich auch begrüßen. Issues Template noch machen für Bugs, Feature Request, Idee und ab gehts.
Ich muss mal schauen, ob man es nicht eben in electron packt und die Edge Cases betrachtet. Die Vorlage der Funktionen hast du ja schon gemeistert 🙂
Aber schon mal danke dafür.

 

[KristinaS]

Die neue Version werde ich noch heute abend testen!

🤗 Kristina

Hallo @NikuTRAX ,

vielen Dank für die neue Worker-Version! Ich habe heute abend schon ein wenig getestet (erst mal nur die Kleinpakete ohne WP International)

Hierzu zwei Punkte:

1. Zusatzservices Premium und Filialrouting

Mir ist das Filialrouting für DHL Kleinpaket (V62KP) wichtig. Dafür wird die Empfänger-E-Mail aus der CSV als parcelOutletRouting an DHL übergeben. Fehlt die E-Mail-Adresse, soll der Worker mit einer verständlichen Fehlermeldung abbrechen.

Der Zusatzservice-Block sieht so aus:

# DHL-Zusatzservices je Produkt
switch ($Product) {
'V62KP' {
$recipientEmail = ([string]$Row.Email).Trim()

if ([string]::IsNullOrWhiteSpace($recipientEmail)) {
throw "Filialrouting für DHL Kleinpaket benötigt die Empfänger-E-Mail-Adresse aus der CSV."
}

$shipment['services'] = [ordered]@{
parcelOutletRouting = $recipientEmail
}
}

'V66WPI' {
$shipment['services'] = [ordered]@{
premium = $true
}
}
}

Bitte diese beiden Zusatzservices bei weiteren Änderungen beibehalten und vielleicht optional konfigurierbar gestalten.

2. Erneute Übermittlung des Versandstatus an Amazon

Ich habe in der Config folgende Werte eingetragen:

"EnableExperimentalShippingStatusSql": true,
"AmazonPlatformId": 51,
(habe noch das Schlusskomma angehängt, 51 ist auch die ID laut meiner Datenbank für Amazon.de)

Die erneute Übermittlung des Versandstatus wird bei mir jedoch offenbar nicht angestoßen. In der v1.14-Datei konnte ich keine Verarbeitung dieser beiden Konfigurationswerte finden.

Kannst du bitte prüfen, ob die experimentelle SQL-Funktion korrekt in der Datei enthalten ist? An wwelcher Stelle finde ich sie? Welche Voraussetzungen müssen erfüllt sein, damit die erneute Übermittlung ausgelöst wird - nur der Erhalt der Sendungsnummer von DHL?

Vielen Dank für deine Arbeit am Worker!🙏
🤗GLG Kristina

GLG Kristina