Issue angelegt [WAWI-41992] Prüfung auf gültige Leitcodierung

[gnarx]

Ich habe das mal so gebaut und hoffe das es funktioniert:

 

[Verkäuferlein]

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?

 

[bauti]

Gibts schon seit langem für die Wawi:

https://www.jtl-software.de/extension-store/adressvorschlag

https://www.jtl-software.de/extension-store/automatische-adresspruefung

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?

 

[bauti]

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?

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...

 

[T4DT.GmbH]

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?

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

 

[T4DT.GmbH]

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...

Wir halten nur Aufträge zurück, welche von DHL genauso auch beanstandet worden wären. Wir verwenden 1 zu 1 denselben Algorithmus

 

[bauti]

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

 

[T4DT.GmbH]

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

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).

 

[bauti]

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.

 

[T4DT.GmbH]

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.

 

[Tsuc]

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.

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.

 

[spaxxilein]

Hallo @gnarx ,

Packstationen können nicht über den Workflow geprüft werden. Die Daten für die Packstationen sind nicht in der Datei vorhanden, die in die Wawi eingelesen wird. Man könnte die Prüfung der Leitcodierung in einem manuellen Workflow vornehmen, der durch einen "Auftrag Erstellt"-Workflow getriggert wird. In dem "Auftrag Erstellt"-Workflow kann man die Bedingungen vorab prüfen und nur wenn die Bedingungen erfüllt sind, wird der manuelle Workflow ausgelöst.

Diese Bedingungen können z.B. sein:

Auftrag\Lieferung\Lieferadresse\Land\ISO enthält DE
Auftrag\Lieferung\Versandart\Name enthält DHL
Auftrag\Lieferung\Lieferadresse\Straße enthält nicht Packstation

Wir werden den Guide-Beitrag zu diesem Thema überarbeiten.

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?

 

[T4DT.GmbH]

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

 

[spaxxilein]

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.

 

[Verkäuferlein]

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.

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.

 

[Tsuc]

Wie genau und in welcher Konstellation setzt Du das denn ein?
Und bei welcher Wawi-Version?

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?

 

[T4DT.GmbH]

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

 

[Tsuc]

Ich habe eben die Straße auf "str." gekürzt.
Der Workflow greift einfach nicht.

 

[Verkäuferlein]

Ich habe eben die Straße auf "str." gekürzt.
Der Workflow greift einfach nicht.

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...

 

[schmiede]

@Tsuc das Problem es fehlt die Logik bei der Prüfung, wir prüfen auch und setzen den Auftrag auf zurückgehalten. Und lösen mit Workflow unsere Prüfung aus, dann kommen die Vorschläge mit Score, dann sieht man auch ggf. den Fehler besser. Wie in deinem Fall (Allgäu) in der Adresse fehlt.