Neu Umstellung auf DHL Versenden 4.0 (REST-API)

[hellomini GmbH]

Tja man muss aber für jeden Artikel dann erstmal die richtigen Codes ermitteln....

Probier mal mit Claude Cowork. Damit bekommt man das eigentlich ziemlich sauber befüllt.

 

[FOC Solutions]

Moin, das mit den HS-Codes (Taric) ist absoluter Mist.
Diese Codes werden nicht für Lieferungen innerhalb der EU benutzt.
Wer nur das tut, braucht die nicht hinterlegen.

Jetzt verlangt JTL das.
Bedeutet:
Man kann alle Artikel nacharbeiten, ein riesiger Aufwand.

Clever wäre eine Abfrage:

Wenn Lieferland in der EU, dann liefer aus.
Wenn Lieferland nicht in der EU, dann verlange den HS-Code.

Bei unseren Kunden richten wir i.d.R. drei DHL Versandarten ein. DHL Paket national, DHL Paket EU, DHL Paket non-EU.

Damit kannst Du beim Paketversand in die EU das Europaket als Produkt wählen und kommst gar nicht mit Taric&Co in Berührung.

 

[Karobube]

Bei unseren Kunden richten wir i.d.R. drei DHL Versandarten ein. DHL Paket national, DHL Paket EU, DHL Paket non-EU.

Damit kannst Du beim Paketversand in die EU das Europaket als Produkt wählen und kommst gar nicht mit Taric&Co in Berührung.

habe den gleichen "Workaround" bei meinen Kunden.

Ergänzung: für die "Paket EU"-Versandart braucht man nichtmal Europaket als Produkt zu wählen - dafür hat nicht jeder eine Abrechnungsnr. Man kann dort weiterhin "Paket International" wählen, und nur den Haken bei Exportdokumente in den Shippinglabelkonfigurationen rausnehmen.

Wenn man Fulfiller ist, nicht vergessen danach die neu erstellten Versandarten im FFN zuzuordnen.

Der Split der International-Versandart in EU/nonEU ist afaik gerade der einzige Weg, dass er nicht plötzlich für EU-Versand Tarics verlangt (obwohl dann wohlgemerkt natürlich keine Zollpapiere rauskommen).

 

[patoc]

Hallo zusammen,

wir haben das Thema, dass seit dem Wechsel auf die 1.11.11 (und auf DHL 4.0), immer wieder - aber nicht systematisch - der bekannte Fehler "[Provider] Parameter refNo (Shipment reference number) must be between 8 and 35 characters long." aufscheint.

Wenn am Packtisch dann die EMAI-ADRESSE (nicht die Referenz!) gelöscht wird, wird das DHL-Label gedruckt. Wenn man dann im DHL-Geschäftskundenportal nachsieht, fehlt die Referenz meistens (aber auch nicht immer) komplett.

Unsere eigentliche Referenz ({{ Auftrag.Rechnung.Rechnungsnummer }} / {{ Auftrag.Rechnung.Auftrag.Auftragsnummer }}) ist garantiert immer > 8 und < 35 Zeichen. Warum auch immer wird hier aber anscheinend die eMail-Adresse auf die Referenz gemappt, und die ist bei Amazon-eMail-Adresse zu 99% > 35 Zeichen. Befragt von Gemini & Co ist hier die Rede davon, dass JTL hier einen Mapping-Fehler hat. Ich Versuche nun zu erzwingen, dass die von unser vorgegeben Referenz (und nicht die eMail-Adresse) verwendet wird, indem ich die Referenz auf Referenz und "Kostenstelle" aufteile und einen Begriff voranstelle:

"Referenznummer:" RECHNUNG: {{ Auftrag.Rechnung.Rechnungsnummer }}
"Kostenstelle:" AUFTRAG: {{ Auftrag.Rechnung.Auftrag.Auftragsnummer }}

Ob das hilft, sehe ich morgen, wenn der Versand wieder anläuft.

Aber kennt jemand diesen Fehler? Wenn es wirklich (mal wieder) ein JTL-Mapping-Fehler ist, weiß jemand ob JTL das schon auf dem Schirm hat?

LG und Dank

 

[8KRL]

Hallo zusammen,

wir haben das Thema, dass seit dem Wechsel auf die 1.11.11 (und auf DHL 4.0), immer wieder - aber nicht systematisch - der bekannte Fehler "[Provider] Parameter refNo (Shipment reference number) must be between 8 and 35 characters long." aufscheint.

Wenn am Packtisch dann die EMAI-ADRESSE (nicht die Referenz!) gelöscht wird, wird das DHL-Label gedruckt. Wenn man dann im DHL-Geschäftskundenportal nachsieht, fehlt die Referenz meistens (aber auch nicht immer) komplett.

Unsere eigentliche Referenz ({{ Auftrag.Rechnung.Rechnungsnummer }} / {{ Auftrag.Rechnung.Auftrag.Auftragsnummer }}) ist garantiert immer > 8 und < 35 Zeichen. Warum auch immer wird hier aber anscheinend die eMail-Adresse auf die Referenz gemappt, und die ist bei Amazon-eMail-Adresse zu 99% > 35 Zeichen. Befragt von Gemini & Co ist hier die Rede davon, dass JTL hier einen Mapping-Fehler hat. Ich Versuche nun zu erzwingen, dass die von unser vorgegeben Referenz (und nicht die eMail-Adresse) verwendet wird, indem ich die Referenz auf Referenz und "Kostenstelle" aufteile und einen Begriff voranstelle:

"Referenznummer:" RECHNUNG: {{ Auftrag.Rechnung.Rechnungsnummer }}
"Kostenstelle:" AUFTRAG: {{ Auftrag.Rechnung.Auftrag.Auftragsnummer }}

Ob das hilft, sehe ich morgen, wenn der Versand wieder anläuft.

Aber kennt jemand diesen Fehler? Wenn es wirklich (mal wieder) ein JTL-Mapping-Fehler ist, weiß jemand ob JTL das schon auf dem Schirm hat?

LG und Dank

Könnte es sein, dass die Rechnungsnummer zu dem Zeitpunkt noch nicht erstellt ist? Bei uns wird Rechnung und Label gleichzeitig erstellt und wenn du die RE Nummer nutzt, kann es zu diesem Konflikt kommen, dass das Label schnelle ist.
Wir nehmen daher die Auftragsnummer, diese ist bereits vorher da.

 

[revay]

Also die Nummer mit der TARIC haben wir auch, obwohl Paket international. Es nervt. Davon ab, wie gehe ich damit um? Ich glaube, wenn ich die 2 installiere ist eins gefixt aber 20 neue Sachen brennen, oder?

der Fehler, den Sie beim Einrichten von DHL Versenden 4.0 erhalten und als Errorlog mitgesendet haben, ist ein bekanntes Problem in der WaWi-Version 1.11.7. Der Fehler tritt in der Konfigurationsmaske beim Schließen des Versandeinstellungs-Dialogs auf und verhindert das korrekte Speichern der DHL-4.0-Konfiguration.

Das Problem wurde in WaWi 2.0.0 behoben. Für die 1.11.x-Linie ist kein Patch geplant, ein Update auf die 2.0-Linie ist daher notwendig. Wir raten dringend dazu, direkt auf die aktuellste Version 2.0.4 zu aktualisieren.

Als kurzfristige Möglichkeit, den Versand ohne Update wieder aufzunehmen: Prüfen Sie bitte, ob Sie in den DHL-4.0-Einstellungen auf eine Absenderreferenz aus dem DHL-Geschäftskundenportal verzichten und stattdessen einen manuellen Absender hinterlegen können. In vergleichbaren Fällen hat das die Fehlermeldung umgangen. Ob das in Ihrer Konfiguration funktioniert, lässt sich ohne weiteres Testen nicht sicher sagen.

 

[Morimus]

Also die Nummer mit der TARIC haben wir auch, obwohl Paket international.

Nicht obwohl Paket International, sondern weil Paket International.

wie gehe ich damit um?

Deine Artikel brauchen eine TARIC.

 

[revay]

Nicht obwohl Paket International, sondern weil Paket International.



Deine Artikel brauchen eine TARIC.

Innerhalb der EU totaler Quatsch. War in 3.0 auch nicht

 

[Karobube]

Also die Nummer mit der TARIC haben wir auch, obwohl Paket international. Es nervt. Davon ab, wie gehe ich damit um? Ich glaube, wenn ich die 2 installiere ist eins gefixt aber 20 neue Sachen brennen, oder?

wie gesagt, die Versandart International in International EU und International nonEU splitten, und bei EU in den Shippinglabelkonfigurationen den Haken bei Exportdokumente raus, dann braucht er für die EU keine TARICs.

Für nonEU natürlich schon, das war auch in der 3.0 so, ohne Leerzeichen und am besten einheitlich 10 Stellen.

 

[BSG-JTL]

@Drollinger
""Object reference not set to an instance of an object."" ist eine BUG bei JTL was eigentlich Serverseitig behoben werden sollte gestern.

Lösung den Haken bei Fehleretikett drucken herausnehmen

Mfg Arne Janson

Das hat bei mir leider nicht geholfen, wenn ich ein Kleinpaket drucken möchte kommt nun immer noch folgender Fehler:

Originalmeldung Meldung: The value entered is too long and has been shortened.
Code: Warning
ID: ecbf7f31-7d30-4cc3-b0a8-1b6197bd6db3 Originalmeldung Meldung: The service entered is unknown.
Code: Error
ID: ecbf7f31-7d30-4cc3-b0a8-1b6197bd6db3 Originalmeldung Meldung: The value entered is too long and has been shortened.
Code: The value entered is too long and has been shortened.
ID: ecbf7f31-7d30-4cc3-b0a8-1b6197bd6db3 Originalmeldung Meldung:
Code: The service entered is unknown.
ID: ecbf7f31-7d30-4cc3-b0a8-1b6197bd6db3

 

[revay]

wie gesagt, die Versandart International in International EU und International nonEU splitten, und bei EU in den Shippinglabelkonfigurationen den Haken bei Exportdokumente raus, dann braucht er für die EU keine TARICs.

Für nonEU natürlich schon, das war auch in der 3.0 so, ohne Leerzeichen und am besten einheitlich 10 Stellen.

Kann ich für 3.0 nicht bestätigen. Bis 31.05. ging das.

 

[bilder_lf]

Object reference not set to an instance of an object​

Internetmarke 2.0 Beta mit WAWI 1.11.10. In der Portokasse ist alles aktiviert und freigegeben.

 

[k.scholz]

Irgendwie läuft der Internationale Versand nicht rund.

Aktueller Fall:
Wir erhalten seit gestern bei allen Internationalen Paketen (nicht EU) die Meldung: "Meldung: Parameter hsCode must be between 4 and 11 characters long."
Okay, Meldung kennen wir schon. Taric Code im Artikel nicht gepflegt. Eigentlich läuft es dann.

In diesem Fall sind sämtliche Artikel der Bestellung mit Taric Code gepflegt.
Trotzdem erhalten wir die Meldung und können folglich keinen Label erstellen.

Hat noch jemand eine Idee?

 

[unblack]

Irgendwie läuft der Internationale Versand nicht rund.

Aktueller Fall:
Wir erhalten seit gestern bei allen Internationalen Paketen (nicht EU) die Meldung: "Meldung: Parameter hsCode must be between 4 and 11 characters long."
Okay, Meldung kennen wir schon. Taric Code im Artikel nicht gepflegt. Eigentlich läuft es dann.

In diesem Fall sind sämtliche Artikel der Bestellung mit Taric Code gepflegt.
Trotzdem erhalten wir die Meldung und können folglich keinen Label erstellen.

Hat noch jemand eine Idee?

Checken, ob der HS Code 6, 8, 10 oder 11 Stellen und nur Zahlen (keine Leerzeichen oder Punkte) hat.

 

[k.scholz]

Schon erledigt. Sogar nochmals per Hand gelöscht, gespeichert, neu eingetragen, gespeichert.
8 Ziffern ohne Leerzeichen, Punkte, Sonderzeichen oder sonstiges.

Erfolglos. 🙁

 

[unblack]

Schon erledigt. Sogar nochmals per Hand gelöscht, gespeichert, neu eingetragen, gespeichert.
8 Ziffern ohne Leerzeichen, Punkte, Sonderzeichen oder sonstiges.

Erfolglos. 🙁

Zeig mal einen screenshot der Fehlermeldungen des letzten Versuchs. Ursprungsland als ISO2 hinterlegt?

 

[k.scholz]

Ein Screenshot:



Ursprungsland ist auch bei allen Artikeln als ISO2 hinterlegt.

 

[unblack]

Ein Screenshot:



Ursprungsland ist auch bei allen Artikeln als ISO2 hinterlegt.

Dann muss ich auch passen. Außer Du hast Positionen zusammenfassen angehakt, dann könnte es natürlich daran liegen...

 

[k.scholz]

Nein, leider auch nicht. Positionen werden nicht zusammengefasst.
Bei dem Artikel handelt es sich im übrigen um einen Stücklistenartikel...
Aber sowohl der Stücklistenartikel selber, als auch alle einzelnen Artikel sind voll mit Taric und Herkunftsland bestückt.

Leider sind die Fehlerausgaben so beschränkt das man absolut nix nachvollziehen kann.
Würde man den Datensatz der übermittelt wird, bei so einem Fall sehen können, käme man dem Problem sicherlich sehr schnell auf die Spur.
Aber so steht mal wieder alles still und Rätselraten ist angesagt.

 

[k.scholz]

hm... Im Lieferschein ist noch eine Freiposition "Versandkosten"...
Ob da versucht wird einen Taric Code zu übermitteln? Jemand eine Idee wie man das prüfen könnte?