In Diskussion WARENPOST 2.0 ... Vorsicht, es werden wohl fehlerhafte Versandetiketten nicht bei Deutschen Post storniert

[dcnetstores]

Kurz unsere Erfahrung dazu:
Wir sind quasi durch WP1 schon vorbelastet und achten akribisch auf Fehler und Doppelabrechnungen. Oben bereits zur Genüge genannten Doppelabrechnungen sind keine Seltenheit. So auch bei uns. Wir prüfen nur bei jeder Kleinigkeit direkt und korrigieren, sofern noch vor Tagesabschluss.

Heute kam es erneut zu einem Vorfall. Aus der WaWi heraus wurden 44 WaPo2 im Bulk versandt. In weißer Voraussicht wurde der Labeldrucker angehalten.

Alle 44 Label wurden korrekt von DHL angelegt. JTL gab dagegen nur 23 DHL-Label aus. Der Rest wurde als Fehler behandelt, obwohl bei DHL korrekt erstellt.

Normal würde man hier erneut exportieren und eine weitere Anlage des Labels bei DHL provozieren, was ohne Prüfung unweigerlich zur erneuten Berechnung führen würde.

Wir haben alle offenen Label dann manuell abgeschlossen (Übernahme Sendungsnummer aus GKP) und die erstellten Label aus dem GKP heraus gedruckt.

Das ganze wiederholte sich heute noch 2 Mal.

Erst ein später Durchlauf heute Abend lief fehlerfrei durch.

 

[SebiW]

Ja, weil ihr auch komplett anders arbeitet als die Allgemeinheit, Etiketten/Labels nachts drucken, da ist der Service auch meistens verfügbar, dann dürft ihr euch glücklich schätzen.

Ich kenne bereits einige Warenpost 2.0 Kunden, die das Problem haben und einige Hundert EUR haben liegen lassen.

Wir wären zb dabei, allerdings hat unser Außendienstler eingelenkt und wir kriegen die Fehlbuchungen bis zur Meldung letzte Woche erstattet.
Allen, die das gleiche Problem haben, kann ich deshalb nur empfehlen: Geht Eurem Ansprechpartner auf die Eier.

Unabhängig davon haben wir unseren Ablauf jetzt angepasst. Alles was Fehlermeldung erzeugt wird storniert. Stand jetzt allerdings nur aus der Wawi heraus. Ich werde am Ende der Woche prüfen, wieviel zu viel dann am Ende noch auf dem Kassenbon steht. Wenn das 2-3 sind, Schwamm drüber, das macht keinen Unterschied.
Wenn der Kostenblock allerdings so relevant ist, dass wir am Ende ein paar hundert im Monat draufzahlen, wird rechnerisch nochmal mit dem Maxibrief verglichen. Wenn das halbwegs Pari ist geht die WP 2.0 den Weg alles irdischen, beim diesjährigen Bestellaufkommen kann ich mit ein paar Euro mehr Versandgebühr deutlich besser leben als mit zusätzlicher Arbeitszeit.

 

[wawi-dl]

Danke SebiW, werden wir dann nochmals tun, wegen ein paar Sendungen sagen wir auch nichts.

Bitte beachte, dass wir den Fehler mit überlastetem JTLWebAPI Service hatten, das sollte ein Zeichen sein dann definitiv zu prüfen, machte bei uns über 90% der Sendungen aus.
Hier hat sich DHL nur kulant gezeigt, was ich gut finde .... der Fehler muss aber seitens JTL gelöst werden.

 

[Stephan K.]

Der Fehler ist nicht neu und JTL schon lange bekannt. WP 2.0 gibt es schließlich schon seit Juli.

 

[wawi-dl]

Danke, ist mir alles bekannt, hilft aber keinem ... bislang keine weiteren Doppelberechnungen, vielleicht hat man hier bereits nachgebessert, wir bleiben dran.

 

[Stephan K.]

Danke, ist mir alles bekannt, hilft aber keinem ... bislang keine weiteren Doppelberechnungen, vielleicht hat man hier bereits nachgebessert, wir bleiben dran.

Wie kommst du denn darauf? Natürlich passiert das immer noch. Mehrmals die Woche. Bei DHL sind sie alle schön brav hinterlegt, nur JTL sagt "Nein" und man soll nochmal machen. Wo ist denn das Werbevideo, das die Zeitersparnis und Effizienzsteigerung mit JTLShipping verspricht? Vielleicht sollte man das mal als Kunden auf die Beine stellen. Das gefällt dann aber dem Chef wieder nicht, wenn man einen monatealten bug als Satire anspricht.

Diese Woche gab es mehrmals die Meldung, dass Statuscode "0" nicht erkannt wurde mit viel bla bla. Es ist immer was Neues. Zu 90% wird dabei trotzdem ein Label kostenpflichtig erzeugt.

 

[Rektor]

Ja, weil ihr auch komplett anders arbeitet als die Allgemeinheit, Etiketten/Labels nachts drucken, da ist der Service auch meistens verfügbar, dann dürft ihr euch glücklich schätzen.

Ich kenne bereits einige Warenpost 2.0 Kunden, die das Problem haben und einige Hundert EUR haben liegen lassen.

Wir arbeiten nicht anders als andere, sondern aus Erfahrung produktiver als andere.

Spaß beiseite.

Wie bereits erwähnt, gibt es eigentlich bei uns nur 2 Fehlermeldungen, "Adresse stimmt nicht, meistens Postleitzahl" , wodurch kein Etikett erstellt wird, bzw. nicht abgerechnet wird, oder Fehler "15", wodurch der Nachdruck über die Wawi problemlos möglich ist.

Erklär doch einfach mal deine Fehlermeldungen, wobei doppelt berechnet wird.

Das Problem kennen wir nicht, konnte auch bisher nicht ermittelt werden, bzw. gab es bei uns bisher nicht, außer die 2 vorgenannten Fehlermeldungen.

 

[wawi-dl]

...
Erklär doch einfach mal deine Fehlermeldungen, wobei doppelt berechnet wird.
...

Habe ich oben, liegt an JTLWebAPI-Service ...

 

[Rektor]

Na ja, die Meldung "Fehler" bei JTL kann soviel wie alles bedeuten. Auch JTL wird für verschiedene Übertragungsfehler einen Code bereitstellen, welcher genau zugeordnet werden kann. Diesen kann ich bei dir nicht erkennen.

Bitte versteh das nicht falsch, jedoch ohne Fehlercode ist es schwierig, einen Fehler zu ermitteln.

 

[wawi-dl]

Lies bitte oben meinen Post und schau dir das Bild an bzgl. API-Fehler, dieser konnte bei 90% der Sendungen zum Störungsfall zugeordnet werden.

Diese Sendungen wurden doppelt berechnet, weil kein Response zurück kam, da JTL API-Service down war.

 

[wawi-dl]

JTL-Support hat sich gemeldet und unseren Verdacht bestätigt.

Sobald es Probleme auf dem Kommunikationsweg gibt, kann es passieren dass fehlende Infos im Nachgang nicht mehr abgerufen/geprüft werden können.
Bedeutet z.B. es gehen EDI Daten an DHL, es kann aber keine Rückmeldung verarbeitet werden, somit erhält JTL keine Nummer und man kann auch nichts stornieren.

Wir haben nun den Fall, dass 90% der mehrfach Berechnungen einen JTLWebAPI-Service Fehler hatten, lassen uns daher per Workflows eine Email + Logfile senden,
dann wissen wir zumindest ob wir ins GKP müssen um manuell zu stornieren.

Wir bleiben dran, vielleicht kann JTL hier wenigstens eine Abhilfe schaffen.

 

[wawi-dl]

@SebiW
Kannst du mal bitte mitteilen, ob ihr ab dem 02.11.2020 noch Doppel-Berechnungen hattet?
Unsere letzten Fälle waren 02.11.2020 vormittags.

JTL teilte uns mit, dass Änderungen an der Schnittstelle am 02.11.2020 erfolgt sind, seitdem ist bislang bei uns Ruhe.

 

[Thomas.B]

Hallo zusammen,

wir haben am 3.11 am Server eine Änderung vorgenommen, mit der wir deutlich länger auf eine Antwort von DHL warten. Vorher haben wir nach 30 Sekunden abgebrochen. (Eigentlich darf die Antwort der API nicht so lange dauern). Im Normalfall ist die Antwort ja auch sehr schnell. Es gab aber an den Tagen wo die DHL Server Probleme hatten einige Fälle, wo die Antwort erst nach 1-2 Minuten zurück kam. Somit wurden diese Label auf DHL-Seite gebucht, jedoch bei uns war es nicht bekannt. Dies waren auch die Fälle, die wir mit wawi-dl untersucht hatten. Seit dem 3.11 ist uns kein Fall mehr bekannt. Eine Erhöhung des Timeouts auf eine so hohe Zeit ist jedoch keine gute Lösung, weil gerade an Tagen wo es bei den DHL Servern Probleme gibt, wird das ganze noch verstärkt wenn die einzelnen Anfragen zu lange offen bleiben. Daher ist dies kein Allheilmittel.

Wichtig: Es gibt jedoch auch vereinzelte Fälle, wo wir keine Antwort von DHL erhalten, jedoch trotzdem bei DHL Etiketten erstellt worden sind. Wir haben in diesen Fällen keinerlei Handhabe oder irgendwelche Nummern oder Daten, um zu erahnen, dass ein Etikett erstellt wurde und somit abgerechnet wurde. Diese Fälle sind jedoch zum Glück sehr selten (Promillebereich).

Wir hoffen, dass DHL in Zukunft die Warenpost 2.0 genauso behandelt wie sonstige DHL Produkte, so dass nur abgerechnet wird wenn die Ware auch eingeliefert wurde. Damit wäre allen geholfen und es gibt keine Probleme mehr. Wir haben diesen Wunsch auch noch mal an DHL kommuniziert.

Viele Grüße,
Thomas

 

[SebiW]

@SebiW
Kannst du mal bitte mitteilen, ob ihr ab dem 02.11.2020 noch Doppel-Berechnungen hattet?
Unsere letzten Fälle waren 02.11.2020 vormittags.

JTL teilte uns mit, dass Änderungen an der Schnittstelle am 02.11.2020 erfolgt sind, seitdem ist bislang bei uns Ruhe.

Schau ich mir an sobald wir die Liste für die Meldung machen und geb Dir dann Bescheid.

 

[wawi-dl]

Vielen Dank für das Statement!
Wir können bestätigen, dass bislang keine Warenpost-Doppelbuchungen aufgetreten sind, die Timeouts bei uns lagen glaub bei ca. 1-2 Minuten, aber definitiv höher als 30Sek, was das Problem bestätigt.

Ich kann nur von unserem Depot im Raum Heilbronn sprechen.
Als wir richtig Luft abgelassen hatten, standen am nächsten Tag auch 2 Ansprechpartner von DHL da und haben uns etwas aufgeklärt.

Zitiere:
Seit November gibt es einen Zusammenschluß von DHL und Deutsche Post, es gibt hier Kollegen die noch geschult werden müssen, weil die Produkte für beide Seiten Neuland sind.
Zudem werden seit kurzem erst neue Laufbänder speziell für Warenpost aufgestellt, die noch nicht alle einwandfrei und vollständig im Betrieb sind.
Hinzu kommt, dass Sendungen 1-3cm maschinell verarbeitet werden können, 3-5cm dagegen nur händisch.
OnTop kommt dazu, das VIELE Mitarbeiter weder einen Scanner, noch genügend geschult sind für Warenpost 2.0, was bei uns 50% der Sendungen erklärt, die nicht gescannt werden.

Bleibt also abzuwarten, wann hier evtl. sogar Warenpost 3.0 kommt

 

[wawi-dl]

Wir hatten gestern 06.12.2020 zwischen 19 Uhr bis 21 Uhr wieder Störungen, es kam bei DHL Paketen (4x) und Warenpost (4x) zu Doppelberechnungen.

Sendungsnummern sind alle im GKP einsehbar, in JTL kamen diese Nummern aber nicht an, es erscheint jetzt ein neuer Fehler:

error message: The system cannot find the file specifiedstatus code: 0status description: response status: Errorcontent: -------------exception message:The system cannot find the file specified
exception type:System.Net.NetworkInformation.NetworkInformationException

Pakete werden nur berechnet, wenn diese ein Laufband gesehen haben, Warenpost müssen wir aber nun stornieren.

 

[SebiW]

Hallo @wawi-dl wir hatten im November seit dem 02.11. nur eine Fehlbuchung.
Scheint also als wäre das Problem größtenteils weg.
Da bin ich jetzt bei ner Fehlerquote von 1/1000 -> ich werde das bei Gelegenheit wieder mal prüfen, ist aber mit der JTL Änderung auf unserer Seite kein akutes Problem mehr.

 

[wawi-dl]

Danke @SebiW !
Es wurde lediglich der TimeOut erhöht, man kann seitens JTL keine Fehler ausschließen, siehe Post von uns, gestern wieder 8 Berechnungen, aber neuer Fehler.

Ich kann daher nur raten, richtet euch einen Workflow ein, damit ihr eine Warn-Email erhaltet, wann ihr defintiv tätig werden müsst!
Wir haben uns dazu dies entwickelt:

1.) Workflow unter "Versand" bei "Versendet" anlegen
2.) Erweiterte Eigenschaft "ShippingFehler" anlegen mit dieser Abfrage:

{% assign Lieferscheinnummer = Vorgang.Lieferscheinnummer -%}\
{% capture query -%}
SELECT      Shipping.tShippingMessage.kShippingMessage
FROM        tBestellung INNER JOIN
            tLieferschein ON tBestellung.kBestellung = tLieferschein.kBestellung INNER JOIN
            tVersand ON tLieferschein.kLieferschein = tVersand.kLieferschein INNER JOIN
            Shipping.tShippingMessage ON tVersand.kVersand = Shipping.tShippingMessage.kVersand INNER JOIN
            tversandart ON tVersand.kVersandArt = tversandart.kVersandArt
WHERE       tLieferschein.cLieferscheinNr = '{{ Lieferscheinnummer }}'
AND         (Shipping.tShippingMessage.cMessageContent like '%JtlWebApi.svc ist nicht verfügbar%'
OR          Shipping.tShippingMessage.cMessageContent like '%The system cannot find the file specifiedstatus code%')
ORDER BY    tLieferschein.cLieferscheinNr,
            Shipping.tShippingMessage.kShippingMessage
{% endcapture -%}
{% assign result = query | DirectQueryScalar -%}\
{{result}}

3.) Bedingung diese "erweiterte Eigeschaft" auswählen und prüfen auf "ist nicht leer"
4.) Aktion "Email senden" definieren


@Thomas.B
Wäre klasse wenn sich JTL dazu auch nochmals äußern könnte ... was nun hier das Problem war.
Laut diverser Meldeportale, gab es gestern wohl Störungen.

 

[wawi-dl]

JTL konnte Störungen seitens DHL bestätigen, Zeitraum 20 Uhr bis 4 Uhr.

Die Fehlermeldung trat bei vielen Kunden auf, der Abruf der Labels (ein anderer DHL Server) scheiterte, man versucht jetzt zu prüfen,
ob man im Vorfeld einen Workaround schaffen kann, damit man solche doppelte Label-Berechnungen im Vorfeld schon vermeiden kann.

 

[wawi-dl]

Heute Morgen gegen 10 Uhr gab es wieder eine Störung des JTL Services "JtlWebApi.svc",
es kann daher zu Doppelberechnungen gekommen sein.