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

web-nf

Aktives Mitglied
17. Juni 2017
28
1
Von mir auch ein voller Respekt für die Lösung. Ich werde auch versuchen das zum laufen zu bringen.
Auch für mich sind die Buchung des größeren JTL Tarifes "nur" um mein DHL Tarif weiter zu nutzen nicht relevant. Das möchte ich so nicht unterstützen.
 
Zuletzt bearbeitet:

NikuTRAX

Gut bekanntes Mitglied
13. Juli 2023
35
31
Auch wenn ich aktuell selbst kein DHL nutze, möchte ich an dieser Stelle einmal ein ausdrückliches Lob aussprechen!

Vielen Dank, dass du mit einem solchen Tool den blutsaugenden Investoren wie HG auf diese Weise den Stinkefinger zeigst.

Mich ärgert es schon seit Längerem, dass immer mehr elementare Funktionen, die ursprünglich selbstverständlicher Bestandteil der Software waren, in zusätzliche kostenpflichtige Pakete ausgelagert werden, nur um auch noch das letzte Quäntchen aus den ohnehin schon belasteten Händlern herauszupressen.

Diese zunehmende Monetarisierung bestehender Funktionen geht meiner Meinung nach völlig an den Interessen der langjährigen JTL-Nutzer vorbei.

Umso erfreulicher ist es, wenn engagierte Entwickler solchen Entwicklungen mit eigenen Lösungen etwas entgegensetzen.

Ich persönlich würde mir ein solches Tool auch für GLS wünschen!
@Merlin84
Vielen Dank für dein positives Feedback! 👍

Genau das war auch mein Gedanke bei der Entwicklung des DHL-Workers. Viele Händler haben ohnehin schon mit steigenden Kosten und sinkenden Margen zu kämpfen. Da muss man nicht auch noch für jede zusätzliche Funktion ein kostenpflichtiges Paket buchen.

Ich finde, dass gerade grundlegende Funktionen wie die Versandabwicklung möglichst unkompliziert und ohne zusätzliche laufende Kosten nutzbar sein sollten.

Deshalb habe ich den DHL-Worker entwickelt und stelle ihn der Community kostenlos zur Verfügung. Mir geht es nicht darum, mit solchen Tools Geld zu verdienen, sondern eine funktionierende Alternative anzubieten.

Und zu deinem Wunsch nach GLS:

Das ist tatsächlich eine interessante Idee! 😊

Der bestehende DHL-Worker ist bereits so aufgebaut, dass sich grundsätzlich auch weitere Versanddienstleister integrieren lassen. Eine zusätzliche GLS-Anbindung wäre daher technisch durchaus denkbar.

Allerdings gibt es dabei eine kleine Herausforderung: Ich selbst nutze GLS nicht und habe auch keinen GLS-Geschäftskundenvertrag.

Somit fehlen mir die entsprechenden Zugangsdaten und vor allem die Möglichkeit, den gesamten Versandprozess unter realen Bedingungen selbst zu testen.

Ich habe mich aber bereits ein wenig mit der technischen Umsetzung beschäftigt.

GLS bietet mit der neueren ShipIT-Farm-API eine Schnittstelle zur automatischen Erstellung von Versandlabels und zur Verarbeitung von Versandaufträgen.

Interessant ist dabei, dass GLS auch eine Sandbox- beziehungsweise Testumgebung zur Verfügung stellt. Darüber sollten sich zumindest grundlegende Funktionen wie die Kommunikation mit der API und die Erstellung von Testlabels entwickeln und überprüfen lassen.

Ob ein solcher Testzugang auch ohne bestehenden GLS-Geschäftskundenvertrag vollständig genutzt werden kann, müsste allerdings noch geklärt werden.

Mein Gedanke wäre folgender:

Ich würde den bestehenden DHL-Worker entsprechend erweitern, sodass künftig beide Versanddienstleister über denselben Worker genutzt werden können.

Die JTL-Wawi würde anhand der hinterlegten Versandart erkennen, ob eine Sendung über DHL oder GLS abgewickelt werden soll.

Anschließend würden die Versandlabels automatisch erstellt, die Sendungsnummern in die JTL-Datenbank zurückgeschrieben und die Versandinformationen wie bisher über JTL an die jeweiligen Marktplätze übermittelt.

Natürlich müsste die bisherige DHL-Funktion dabei vollständig erhalten bleiben.

Was ich dafür allerdings benötigen würde, wäre die Unterstützung von jemandem aus der Community, der GLS tatsächlich nutzt.

Wenn jemand einen GLS-Geschäftskundenvertrag besitzt und bereit wäre, eine solche Erweiterung später unter realen Bedingungen zu testen, wäre das eine große Hilfe.

Idealerweise könnte man zunächst gemeinsam mit der Sandbox arbeiten und anschließend mit einem echten GLS-Zugang überprüfen, ob die komplette Versandabwicklung zuverlässig funktioniert.

Ich möchte allerdings noch nichts versprechen. Erst einmal müsste geklärt werden, welche API-Funktionen verfügbar sind und welche Voraussetzungen GLS für die Nutzung verlangt.

Aber eines steht für mich fest: Sollte ich die GLS-Erweiterung umsetzen und zuverlässig zum Laufen bekommen, wird auch diese kostenlos für die Community zur Verfügung gestellt.

Vielleicht finden sich hier ja ein paar GLS-Nutzer, die Interesse daran haben und bei den Tests unterstützen würden. Dann könnte daraus durchaus etwas werden! 👍

Viele Grüße
Christian
 
  • Gefällt mir
Reaktionen: microline

NikuTRAX

Gut bekanntes Mitglied
13. Juli 2023
35
31
Klasse Arbeit! So etwas für DPD wäre mein Traum
@microline
Vielen Dank für dein Lob! 👍😊

DPD wäre tatsächlich eine interessante Erweiterung meines JTL-Versandworkers!

Die gute Nachricht: DPD bietet eine eigene API inklusive Sandbox-Testumgebung an. Damit könnte ich die Anbindung zunächst entwickeln und testen, ohne echte Pakete verschicken zu müssen.

Allerdings nutze ich selbst kein DPD und habe auch keinen entsprechenden Geschäftskundenvertrag. Ob ich sämtliche Testzugänge ohne Vertrag bekomme, müsste ich noch klären.

Mein Ziel wäre ein universeller, kostenloser JTL-Versandworker für DHL, GLS und DPD.

Der Worker soll automatisch den Versanddienstleister erkennen, Versandlabels erstellen und die Sendungsnummern direkt an die JTL-Wawi zurückgeben.

Dafür bräuchte ich allerdings Unterstützung aus der Community!

Wenn du DPD nutzt und bereit wärst, die Erweiterung später mit deinem Geschäftskundenzugang unter realen Bedingungen zu testen, wäre das ideal.

Ich werde mir die Schnittstelle genauer ansehen. Versprechen möchte ich noch nichts, aber technisch sieht es durchaus machbar aus.

Und selbstverständlich würde auch die DPD-Erweiterung kostenlos bleiben! 👍

DPD-Sandbox:
https://esolutions.dpd.com/entwickler/dpdcloudwebservice/sandbox.aspx?allowcloud=true

Viele Grüße
Christian
 
  • Gefällt mir
Reaktionen: microline

Alex R

Aktives Mitglied
15. Januar 2020
16
11
Von mir auch ein voller Respekt für die Lösung!!
Ich habe die JTL WaWi-Version 2.0.5.0. Der Export CSV unter „Versand → Import/Exportvorlagen“ ist bei mir komplett gesperrt. Diese Funktion ist also in der JTL WaWi Start Edition ab 2.0 Versionen deaktiviert.

Deshalb bin ich einen anderen Weg gegangen: Über „Admin → Druck, E-Mail, Exportvorlagen“ kann man im Unterbereich „Lieferschein → Exportieren“ eine eigene CSV-Datei erstellen.

Diese Datei lässt sich dann beim Versenden eines Pakets exportieren. Dabei spielt es keine Rolle, ob man den Lieferschein tatsächlich ausdruckt oder nicht. Man muss lediglich das Häkchen bei „Exportieren“ setzen, und schon funktioniert alles.
1.JPG2.JPG3.png4.png5.png6.png
 

Anhänge

Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: TheEnd und elcheffe

Merlin84

Gut bekanntes Mitglied
25. Oktober 2013
47
82

@ NikuTRAX ich kann das dann gerne testen mit GLS ich könnte ggf. auch bei der Entwicklung mitwirken falls nötig.​

Eine wichtige Info ist sicher noch das wir die Wawi in Version 1.5.55.8 verwenden, ich weiß nicht ob JTL zwischenzeitlich in dem Bereich Änderungen an der Datenbank vorgenommen hat.

Setzt bzw. übermittelt dein Worker auch automatisch die Sendungsnr. je nach Auftrag z.B. an Ebay bzw. Amazon?
 
Zuletzt bearbeitet:

Vape & Make

Aktives Mitglied
15. Januar 2016
61
10
@microline
Vielen Dank für dein Lob! 👍😊

DPD wäre tatsächlich eine interessante Erweiterung meines JTL-Versandworkers!

Die gute Nachricht: DPD bietet eine eigene API inklusive Sandbox-Testumgebung an. Damit könnte ich die Anbindung zunächst entwickeln und testen, ohne echte Pakete verschicken zu müssen.

Allerdings nutze ich selbst kein DPD und habe auch keinen entsprechenden Geschäftskundenvertrag. Ob ich sämtliche Testzugänge ohne Vertrag bekomme, müsste ich noch klären.

Mein Ziel wäre ein universeller, kostenloser JTL-Versandworker für DHL, GLS und DPD.

Der Worker soll automatisch den Versanddienstleister erkennen, Versandlabels erstellen und die Sendungsnummern direkt an die JTL-Wawi zurückgeben.

Dafür bräuchte ich allerdings Unterstützung aus der Community!

Wenn du DPD nutzt und bereit wärst, die Erweiterung später mit deinem Geschäftskundenzugang unter realen Bedingungen zu testen, wäre das ideal.

Ich werde mir die Schnittstelle genauer ansehen. Versprechen möchte ich noch nichts, aber technisch sieht es durchaus machbar aus.

Und selbstverständlich würde auch die DPD-Erweiterung kostenlos bleiben! 👍

DPD-Sandbox:
https://esolutions.dpd.com/entwickler/dpdcloudwebservice/sandbox.aspx?allowcloud=true

Viele Grüße
Christian
Bitte Internetmarke nicht vergessen (falls möglich). DANKE!
 

KristinaS

Gut bekanntes Mitglied
8. Mai 2017
133
18
Hallo @KristinaS ,

vielen Dank für deine ausführliche Rückmeldung und das Testen! 😊

Ich habe die v1.14 noch einmal überprüft.

1. Premium und Filialrouting

Premium für V66WPI ist bereits in der Funktion Build-OrderBody enthalten (ab Zeile 1191).

Du hast aber recht: Das Filialrouting parcelOutletRouting für V62KP fehlt noch. Das werden wir ergänzen, einschließlich der Prüfung der Empfänger-E-Mail-Adresse.

Eine optionale Aktivierung über die Config ist ebenfalls sinnvoll.

2. Amazon-Versandstatus

Die experimentelle SQL-Funktion ist tatsächlich bereits in der v1.14 enthalten.

Du findest sie innerhalb von Write-JtlTracking:

  • Zeile 692: Prüfung von EnableExperimentalShippingStatusSql
  • Zeile 737: Auslesen von AmazonPlatformId
  • Ab Zeile 740: Amazon-spezifische SQL-Verarbeitung
  • Zeile 1017: Protokollierung der vorgemerkten Versandmeldung
Allerdings gibt es einige Sicherheitsbedingungen. Beispielsweise verarbeitet die Funktion derzeit nur Amazon-Aufträge mit genau einer Bestellposition.

Die Übermittlung wird im Zusammenhang mit dem Eintragen der DHL-Sendungsnummer vorbereitet. Voraussetzung ist unter anderem, dass die Plattform-ID stimmt und die zugehörige Amazon-Bestellung in der JTL-Datenbank eindeutig gefunden wird.

Die eigentliche Übertragung an Amazon erfolgt anschließend über die JTL-Verarbeitung. Ob diese erfolgreich ausgeführt wird, muss gesondert geprüft werden.

Schau bitte einmal in dein Worker-Log, ob dort die Meldung

Amazon-Versandstatus SQL vorgemerkt

erscheint oder ob eine Fehlermeldung protokolliert wird.

Bitte teste die experimentelle SQL-Funktion vorerst nur mit entsprechendem Datenbank-Backup und überprüfter JTL-Datenbankstruktur.

Vielen Dank noch einmal für deine Unterstützung! 🤗

Viele Grüße
Christian
Hallo Christian,

ganz herzlichen Dank für Deine tolle Arbeit am Worker! 😊

Ich war ein paar Tage im Urlaub, daher kann ich jetzt erst weitermachen. Das Amazon-Update funktioniert jetzt auch bei mir bei Bestellungen mit einem Artikel einwandfrei – super, vielen Dank! Der Fehler neulich lag übrigens bei mir, bitte entschuldige. 😉

Wäre es möglich, die Versandstatusübermittlung auch auf Amazon-Bestellungen mit mehreren Artikeln zu erweitern? Ich mache keine Teillieferungen, sondern versende die Bestellungen immer vollständig in einem Paket. Daher wäre es klasse, wenn auch diese Bestellungen automatisch berücksichtigt werden könnten, ggf. durch optionale Schalterstellung konfigurierbar, falls es jemand sicherheitshalber nicht so haben möchte.

Für eine DPD-Lösung stehe ich ebenfalls gern für Tests zur Verfügung. Ich habe einen iloxx-Vertrag mit Anbindung über die DPD Cloud und könnte das Ganze damit in der Praxis testen.

Außerdem wäre eine Anbindung an die Deutsche Post Internetmarke für mich noch interessant. Besonders wichtig wären mir zunächst die Inlandstarife Kompaktbrief, Großbrief und Bücher- und Warensendung (BüWa).

Vielen Dank noch einmal für Dein Engagement und dafür, dass du den Worker kontinuierlich weiterentwickelst. Das hilft gerade kleineren Händlern wie mir wirklich sehr! 🤗
 

Alex R

Aktives Mitglied
15. Januar 2020
16
11
Hallo Christian,

nochmals vielen Dank für deine tolle Arbeit an diesem Worker!

Ich habe deinen Worker inzwischen im Bereich der DHL-Paketgewichtsstufen erweitert.

Der Hintergrund dafür ist, dass ich mit DHL einen Vertrag habe, in dem für unterschiedliche Gewichtsstufen verschiedene Versandpreise vereinbart sind. Diese Preisstufen möchte ich auch in meiner eigenen Preiskalkulation berücksichtigen und an meine Kunden weitergeben können. So kann ich bereits im Voraus abhängig vom Paketgewicht unterschiedliche Versandkosten für meine Kunden festlegen und diese Kosten bei meiner Kalkulation und Preisgestaltung berücksichtigen.

Bisher wurde das Gewicht einer Sendung anhand des in der CSV-Datei angegebenen Gewichts übernommen. Jetzt habe ich sechs feste Gewichtsstufen für den nationalen DHL-Paketversand ergänzt:

  • DHL Paket bis 1 kg Inland
  • DHL Paket bis 3 kg Inland
  • DHL Paket bis 5 kg Inland
  • DHL Paket bis 10 kg Inland
  • DHL Paket bis 20 kg Inland
  • DHL Paket bis 31,5 kg Inland
Wichtig ist, dass diese Versandart-Bezeichnungen in JTL-Wawi exakt so geschrieben und hinterlegt werden, damit der Worker sie korrekt erkennt.

Wenn eine dieser sechs Versandarten in JTL ausgewählt wird, erkennt der Worker automatisch die entsprechende Gewichtsstufe und übermittelt an DHL das jeweilige Höchstgewicht dieser Stufe – unabhängig davon, welches Gewicht in der CSV-Datei steht.

Alle sechs neuen Versandarten verwenden das bestehende DHL-Produkt V01PAK und die bereits hinterlegte Abrechnungsnummer. Sie sind ausschließlich für Sendungen innerhalb Deutschlands vorgesehen.

Alle bisherigen Versandarten und deren Verarbeitung bleiben unverändert.

Viele Grüße
 

Anhänge

wawi-dl

Sehr aktives Mitglied
29. April 2008
6.802
838
Vorweg, erstmal eine gute Sache, wir haben kürzlich unsere PackSoftware auch nochmals neu entwickelt mit Versand-Anbindung.

Was mir bei der Lösung überhaupt nicht gefällt, ist die Anbindung an JTL per SQL.
Macht das bitte NICHT, schreiben nur auf minimalstes beschränken!

Bitte keinesfalls versuchen direkt in die SQL Tabelle zu schreiben (nur wenn zwingend erforderlich), auch keine JTLWawiExtern.dll verwenden, da hier schnell interne Prozesse übersprungen werden.
Wir hatten uns das auch lange überlegt und darum nicht gemacht.

Erst @mvh hat den entscheidenden Tipp mit "jtlCore.dll" geliefert, schaut euch diese an, diese haben wir angebunden und diese feuert auch alle internen Prozesse ab!
Versanddaten schreiben wir in eigene Arbeitstabellen, diese werden dann abgeholt und über offizielle interne Prozesse auch an alle Plattformen übermittelt.

Wir schreiben daher wirklich nur "Sendungsnummer" und "Versanddatum" rein, dann wird die "jtlCore.dll" gefeuert die dann alles macht.
Nur als Tipp, nicht dass sich mal jemand wundert warum Worker, SP, Trigger etc. nicht gelaufen sind.
 

Ähnliche Themen