Issue angelegt [WAWI-41992] Prüfung auf gültige Leitcodierung
- Ersteller des Themas xadoX
- Erstellungsdatum
Wir haben jetzt auch mal den Workflow für die Prüfung der Leitcodierbarkeit in der Wawi scharf geschaltet und getestet.
Allerdings ist das Ergebnis eher mau. Der Workflow läuft auf niedrigster Stufe (Keine Übereinstimmung (NoMatch) > Leitcodierung ist nicht möglich) zum Sperren des Auftrags und es wird trotzdem fast jedes 2. Paket ausgefiltert.
Lassen wir die Pakete dann trotzdem ohne Änderung über JTL-Shipping/Versenden und das DHL GKP laufen, werden die Adressen einwandfrei akzeptiert und leitcodiert.
Häufig tritt sowas auf wie "Frankfurt" statt "Frankfurt am Main" oder auch "Mühlheim" statt "Mühlheim an der Ruhr", aber auch Abkürzungen in Straßennamen (Bgm.-XY-Str.) oder aber auch angefügte Bundesländer oder Ortsteile. Bei Allem meckert der Workflow und trotzdem gehen diese Dinge problemlos bei DHL durch und die Sendung wird leitcodiert. Daher vermute ich mal, dass es bei DHL Versenden eine integrierte Fehlertoleranz (Autokorrektur) mit den häufigsten Adressfehlern gibt, die bei dem reinen Abgleich mit der Leitcode-Datenbank nicht greift.
Wie werden denn eigentlich ggf. vorgenommene Adressänderungen im Wawi-Auftrag protokolliert?
Allerdings ist das Ergebnis eher mau. Der Workflow läuft auf niedrigster Stufe (Keine Übereinstimmung (NoMatch) > Leitcodierung ist nicht möglich) zum Sperren des Auftrags und es wird trotzdem fast jedes 2. Paket ausgefiltert.
Lassen wir die Pakete dann trotzdem ohne Änderung über JTL-Shipping/Versenden und das DHL GKP laufen, werden die Adressen einwandfrei akzeptiert und leitcodiert.
Häufig tritt sowas auf wie "Frankfurt" statt "Frankfurt am Main" oder auch "Mühlheim" statt "Mühlheim an der Ruhr", aber auch Abkürzungen in Straßennamen (Bgm.-XY-Str.) oder aber auch angefügte Bundesländer oder Ortsteile. Bei Allem meckert der Workflow und trotzdem gehen diese Dinge problemlos bei DHL durch und die Sendung wird leitcodiert. Daher vermute ich mal, dass es bei DHL Versenden eine integrierte Fehlertoleranz (Autokorrektur) mit den häufigsten Adressfehlern gibt, die bei dem reinen Abgleich mit der Leitcode-Datenbank nicht greift.
Wie werden denn eigentlich ggf. vorgenommene Adressänderungen im Wawi-Auftrag protokolliert?
Sind die beiden Erweiterungen auch für JTL 1.6 geeignet? Es steht nur was von 1.5
Bei der Erweiterung "Adressvorschlag" steht "Für den korrekten Einsatz ist das Produkt Leitcodierung prüfen zwingend erforderlich" Ist damit "die automatische-Adressprüfung" von euch gemeint?
Ich habe es auch kurz angetestet und kann das bestätigen. Für mich bringt dass so denke ich nichts...
Wie verhält es sich bei der Lösung von T4DT.GmbH ? Werden dort nur die Adressen beanstandet welche wirklich nicht als Leitcodierbar akzeptiert werden, oder verhält es sich ähnlich wie bei der JTL eigenen Lösung? Die Datengrundlage ist ja die selbe...
Zuletzt bearbeitet:
ja das ist korrekt (wenngleich missverständlich von uns formuliert, entschuldige die Verwirrung).
Beide Erweiterungen sind grundsätzlich auch 1.6 kompatibel. Die automatische Adressprüfung ist aber technisch fast identisch zu unserer Lösung "automatische Adressprüfung" (das nehmen wir, nachdem wir es bereits seit drei Jahren anbieten einfach mal als Kompliment von JTL). Wenn man es korrekt einrichtet, sollte es auch ein identisches Resultat, wie unsere Lösung, ergeben. Im Moment haben wir bei unserer Lösung ungefähr eine Quote von 1 Issue-Ticket je 100.000 validierte Aufträge. Das ist aber nicht statistisch erfasst, sondern nur pessimistisch geschätzt.
Das GUI-Tool baut in der jetzigen Version auf unser eigenes Adressprüfungsmodul auf. Dieser Umstand wird aber noch verändert, sodass es zum JTL-eigenen Modul kompatibel sein soll. Da letzteres aber noch blutjung ist, hatten wir noch keine Gelegenheit das umzusetzen.
LG
Wir halten nur Aufträge zurück, welche von DHL genauso auch beanstandet worden wären. Wir verwenden 1 zu 1 denselben Algorithmus
Danke für die Rückmeldung.
Ich bin mir nicht ganz sicher ob ich es richtig verstanden habe.
Soll es heißen:
Wir halten nur Aufträge zurück, welche von DHL genauso auch beanstandet worden wären. Wir verwenden 1 zu 1 denselben Algorithmus
oder doch
Wir halten nur Aufträge zurück, welche vom JTL-plugin genauso auch beanstandet worden wären. Wir verwenden 1 zu 1 denselben Algorithmus
Ich bin mir nicht ganz sicher ob ich es richtig verstanden habe.
Soll es heißen:
Wir halten nur Aufträge zurück, welche von DHL genauso auch beanstandet worden wären. Wir verwenden 1 zu 1 denselben Algorithmus
oder doch
Wir halten nur Aufträge zurück, welche vom JTL-plugin genauso auch beanstandet worden wären. Wir verwenden 1 zu 1 denselben Algorithmus
Was meinst du mit JTL-Plugin?
JTL Shipping selbst beanstandet keine Aufträge, sondern DHL beanstandet die übermittelten Daten und gibt keinen Leitcode zurück. Dadurch wirft JTL den Fehler.
Wir prüfen, ob DHL einen Leitcode erstellt hätte. Wenn nicht, wird der Auftrag zurück gehalten (mit dem anderen Plugin machen wir leitcodierbare Näherungsvorschläge).
Mit JTL-Plugin meinte ich die neue Möglichkeit bei den Workflows in JTL 1.6. Sorry, das war natürlcih nicht korrekt und sehr verwirrend ausgedrückt von mir.
Der Workflow von JTL verwendet nahezu denselben Algorithmus wie wir (seit Jahren). Der entspricht dem von DHL recht genau. Wenn der Workflow korrekt eingerichtet wurde, wird er auch genau dieselben Aufträge als fehlerhaft markieren, die DHL in der Leitcodierung ablehnt. Dasselbe trifft auf unser Add-On zu.
Das ist bei uns auch so.
Übergeben wurde der Ort: "Kempten"
Dort ist, obwohl alle anderen Daten korrekt sind, die Leitcodierung fehlgeschlagen.
Ergebnis hätte "Kempten (Allgäu)" sein müssen.
Wenn ich in DotLiquid nur die Variable {{ Vorgang.Lieferung.Lieferadresse.DHL-Leitcodierung.Ort.Gefundener_Ort }} für diesen Auftrag ausgeben lasse, dann zeigt er den Ort: "Kempten (Allgäu)" an.
Also die Variable funktioniert. Aber warum sagt dann Leitcodierung, dass es keine korrigierbare Übereinstimmung gibt?
Eigentlich hätte das in "Kempten (Allgäu)" korrigiert werden können, oder verstehe ich da etwas falsch?
Update: "Frankfurt" wird in "Frankfurt am Main" korrigiert, wenn man die Bedingungen nicht einrichtet. Aber das kann ja keine Lösung sein.
Zuletzt bearbeitet:
Moin! In der Datei die man aus dem GKP herunterladen kann ist doch auch eine PACKSTAT.DAT Datei - dort sind die ganzen Daten der Packstationen gespeichert.
Wieso kann man diese Datei nicht nutzen für die Leitcodierung von Packstationen?
Klar könnte man es. Wir haben es aber bislang nicht implementiert. Und da JTL das Modul selbst nachbaut, werden wir es in Zukunft auch nicht implementieren
Moin,
die Frage war auch eher an JTL gerichtet, da ich natürlich verstehe dass für dich die Weiterentwicklung nur noch bedingt Sinn macht, wenn es eine "Hauseigene"-Funktion ist.
Eigentlich ist das ja erst die nächste Frage.
Wenn schon das Prüfen auf Leitcodierbarkeit als Workflowbedingung negativ beschieden wird, kommt man ja gar nicht erst zum Korrigieren.
Wie genau und in welcher Konstellation setzt Du das denn ein?
Und bei welcher Wawi-Version?
Habe jetzt noch einmal ein paar Problemfälle durchlaufen lassen und es wurde einmal aus Frankfurt => Frankfurt am Main, allerdings war dann die Straße das Problem, weil diese als ...str. abgekürzt war und keine automatische Korrektur vorgeschlagen wurde. Beim Anderen Fall ist es Mühlheim => Mühlheim am Main, aber auch hier wird die Straße nicht akzeptiert / korrigiert, obwohl laut Google Maps existent und ohne Probleme von DHL bei der Labelerstellung akzeptiert.
Der Workflow, siehe das Bild unten, ist unter "Aufträge erstellt" nach der Guide Anleitung eingerichtet und läuft unter Version 1.6.41.0
Bedingungen greifen leider nicht. 😕
Hier mal die Adresse.
Habe ich da einen Fehler mit dem Workflow gemacht? Oder liegt es an JTL?
Keine Ahnung. Aber DHL ersetzt Straße, Strasse immer durch STR bevor es validiert wird. Das sollte also eigendlich nicht in die Validierung mit einzählen. Wenn doch, macht JTL es falsch. Bei unserem Modul wird exakt der DHL Algo benutzt. Vielleicht korrigiert JTL sich hier noch entsprechend
Das Ergebnis ist ja scheinbar auch ein "NoMatch" für die Adresse und da Du in den Bedingungen nur auf RoutableMatch und FixableMatch als Ausführungsbedingung prüfst, läuft der Workflow nicht.
Aber dennoch ist die Adresse ungerechtfertigt ein NoMatch, was leider bei vielen Adressen vorkommt, die von DHL selber problemlos leitcodiert werden. Im DHL-Geschäftskundenportal lässt sich die Adresse leitcodieren.
Ich mach mal ein Ticket bei JTL mit verschiedenen Beispielen auf...
