MODUL: DHL Versand & Label-Erstellung

[Timm]

@onlineshopper
Erstell mal bitte übers Backend eine Bestellung mit dem Versandland Afghanistan. Und versuche dann ein Label zu drucken. Schau, ob sich die Fehlermeldung ändert.

Wenn es dann geht oder sich die Fehlermeldung ändert, dann hätte ich den Grund vielleicht.

Gruss Timm

[weichen-walter]

@ noRiddle

Bei weichen-walter stellt sich die Frage was das genau heißt:
Kollation in der DB

[ Für Gäste sind keine Dateianhänge sichtbar ]

includes/configure.php:

[ Für Gäste sind keine Dateianhänge sichtbar ]

und im Shop wird mir bei Sprache iso-8859-15 angezeigt

[ Für Gäste sind keine Dateianhänge sichtbar ]

[...]
Schreib euren Firmenort mal mit ue statt ü und teste erneut.
[...]

Das habe ich auch schon versucht.

Code: [Auswählen]

ERROR - Code: Client Message: SOAP-ERROR: Encoding: string 'Uhldingen-M\xfc...' is not a valid utf-8 string
Wird im Ortsname ü durch ue ersetzt, kommt dann die Fehlermeldung bei der Zollbeschreibung (Modellbahnzubehör):

Code: [Auswählen]

ERROR - Code: Client Message: SOAP-ERROR: Encoding: string 'Modellbahnzubeh\xf6...' is not a valid utf-8 string
Ja, die aktuelle Version 1.15 habe ich aufgespielt.

Danke für Eure Hilfe!

[Timm]

Hast du das Ü im Ort und das ö in Modellbahnzubehör mal gleichzeitig geändert in den Moduleinstellungen und dann probiert?

Nachdem was @noRiddle geschrieben hat müsste es ja mit den charset Einstellungen, wenn auch unterschiedlich, funktionieren. Aber da kenn ich mich nicht aus und noRiddle kann da sicher mehr zu sagen.

Gruss Timm

EDIT: Und die Frage wäre bei dir, ob es auch nur bei non EU Ländern nicht geht oder generell. Dadurch könnte man Gemeinsamkeiten in den Fehlern finden.

[weichen-walter]

@FräuleinGarn
Hab das grade versucht. Wenn beide Umlaute, also ü im Ort und ö in Modellbahnzubehör ersetzt sind funktioniert es!
Das Problem gibts nur bei non EU-Ländern.

[noRiddle (revilonetz)]

Die Collation ist nur bedingt aussagekräftig.
Sicherheitshalber also: Was kommt heraus wenn du den Befehl absetzt ?

[...]
Das kann man nämlich nicht so ohne weiteres sehen, lediglich anhand der Collations rückschließen.
Setze mal diesen Befehl in phpMyAdmin ab:

Code: SQL  [Auswählen]

SELECT default_character_set_name FROM information_schema.SCHEMATA WHERE schema_name = "DATENBANK_NAME";

Bei "DATENBANK_NAME" den Namen deiner DB angeben.
[...]

Da dein Shop ohne Kodierungsprobleme läuft dürfte allerdings alles in Ordnung sein.
Wenn die DB wirklich auf UTF8 läuft könntest du die DB-Verbindung
(DB_SERVER_CHARSET in der /includes/configure.php)
auf 'utf8' setzen und im Backend bei den Sprachen auf UTF-8 (im Gegensatz zu der DB-Verbindung mit Bindestrich !!) stellen.
Wenn du danach einmal die Session killst/wechselst* ist alles okay und es gibt keine scheinbar widersprüchlichen Einstellungen mehr. Evtl. ist dann auch das
"ERROR - Code: Client Message: SOAP-ERROR: Encoding: string '.....' is not a valid utf-8 string"
Problem gelöst.
Allerdings sollte das vorliegende Modul die Daten auch bei einem "ISO-8859-15"-Shop richtig senden, also in UTF-8 umwandeln bevor sie an die DHL-API gesendet werden. Das müsste sich dann GTB mal ansehen.

@FräuleinGarn
Das mit der DB-Verbindung hatte ich hier schon mal beschrieben: SHOP UTF-8 ...


* Session killen/wechseln:
Entweder

• bei Einstellung im Backend => Erw. Konfiguration => Sessions => "Session erneuern" auf 'Ja'
  - was empfehlenswert ist -
  einmal aus- und wieder einloggen
  oder
• im Browser einmal die Session-Cookies löschen.

Cookies im Browser löschen
-------------------------------

• Chrom: Irgendein Frontend-Inhalt => Rechte Maustaste => Untersuchen => Tab "Application" => links bei "Cookies" rechte Maustatste => "clear" (oder "löschen")
  
• Safari: Irgendein Frontend-Inhalt => Rechte Maustaste => Element Informationen => Tab "Ressourcen" => links "Cookies" anklicken => rechts mittels rechter Maustaste Cookies löschen
• Firefox: Irgendein Frontend-Inhalt => Rechte Maustaste => Element untersuchen => Tab "Web-Speicher" => links bei "Cookies" rechte Maustatste => "Alles löschen"
• Opera: Irgendein Frontend-Inhalt => Rechte Maustaste => Element untersuchen => Tab "Application" => links bei "Cookies" rechte Maustatste => "clear" (oder "löschen")

Alternativ auf Windows-Rechnern: STRG + SHIFT + ENTF und Cookies löschen. Dann sind allerdings alle Cookies gelöscht, auch die anderer Webseiten.

[Timm]

Moin

@noRiddle
Und in der .htaccess noch umstellen auf utf8, oder?

@gtb @tomcraft
Ist ja schon auffällig, dass beide eine Latin1 Codierung nutzen und nur die non EU Sendungen nicht gehen, aber alle anderen Sendungen schon. Vielleicht habt ihr einen latin1 Shop zum testen.

Bei @onlineshopper tippe ich darauf, dass es an seinen Steuersätzen für non EU Ländern liegt, da das DHL Modul das CN23 Formular nur erstellt, wenn der Steuersatz auf 0 steht. Zumindest hab ich den Code so gedeutet. Deshalb der Test mit Afghanistan, da dort der Steuersatz noch korrekt bei 0% angegeben ist. Das war ein Wunsch seines Chefs zb für die Schweiz dennoch deutsche MwSt zu berechnen. Grund weiß ich nicht mehr. Übrigens könnte es auch daran liegen dass eure Verkäufe ins Ausland gesunken sind, da es dadurch für die Kunden viel teurer ist, und nicht am schlecht sichtbaren OSS Modul lag, wie du vermutet hattest.

Gruß Timm

[Tomcraft]

[...]
@gtb @tomcraft
Ist ja schon auffällig, dass beide eine Latin1 Codierung nutzen und nur die non EU Sendungen nicht gehen, aber alle anderen Sendungen schon. Vielleicht habt ihr einen latin1 Shop zum testen.
[...]

Wir schauen uns das nochmal an. Kann sein, dass wir eine Code-Stelle übersehen haben.

Grüße

Torsten

[noRiddle (revilonetz)]

[...]
@noRiddle
Und in der .htaccess noch umstellen auf utf8, oder?
[...]

Ja, für weichen-walter also in der Root-.htaccess des Shops dann

Code: [Auswählen]

##-- Default charset
#AddDefaultCharset UTF-8
AddDefaultCharset ISO-8859-15
auch entsprechend anpassen.

Danke für den Hinweis, FräuleinGarn.

Gruß,
noRiddle

[weichen-walter]

[...]
Das kann man nämlich nicht so ohne weiteres sehen, lediglich anhand der Collations rückschließen.
Setze mal diesen Befehl in phpMyAdmin ab:

Code: SQL  [Auswählen]

SELECT default_character_set_name FROM information_schema.SCHEMATA WHERE schema_name = "DATENBANK_NAME";

Bei "DATENBANK_NAME" den Namen deiner DB angeben.
[...]

Ergebnis:

default_character_set_name    
utf8mb4

Die .htaccess brauchte nicht angepasst zu werden

Habe nun
- die configure.php auf 'utf8' geändert
- im Backend Sprache auf UTF-8 geändert

- Session erneuert
- Browsercookies gelöscht
- Umlaute wieder auf ü/ö geändert
- in der Bestellung Artikel gelöscht und wieder neu eingefügt
 ( das sonst in der Datenbank noch oe in der Zollbeschreibung liegen würde)

Bingo! Alles funktioniert!

[EDIT Tomcraft 08.04.2022: Zitat korrigiert.]

[Timm]

Die .htaccess musst du auch anpassen. Das Beispiel von @noRiddle zeigt, wie es bei latin1 ist. Wenn der Shop auf utf8 läuft, dann muss die Raute bei utf8 weg und vor iso. Also quasi eine Zeile tiefer, denn die Raute sorgt dafür, dass etwas ignoriert wird.

Gruß Timm

[noRiddle (revilonetz)]

[...]
Bingo! Alles funktioniert!
[...]

Das freut mich.
Endlich mal jemand der wirklich alles liest und es genauso macht.

In der Tat ist FräuleinGarns Hinweis, um sicher zu gehen, richtig, denn ich habe mich zu allgemein ausgedrückt mit:

[...]
Ja, für weichen-walter also in der Root-.htaccess des Shops dann

Code: [Auswählen]

##-- Default charset
#AddDefaultCharset UTF-8
AddDefaultCharset ISO-8859-15
auch entsprechend anpassen.
[...]

weil ich davon ausging du, weichen-walter, wissest schon was ich mit "entsprechend anpassen" meine.
Wenn du also das da stehen hast:

Code: [Auswählen]

##-- Default charset
AddDefaultCharset UTF-8
#AddDefaultCharset ISO-8859-15
ist es korrekt, sonst ändern wie zuletzt gezeigt.

Gruß,
noRiddle

[Onlineshopper]

[...]
Bei @onlineshopper tippe ich darauf, dass es an seinen Steuersätzen für non EU Ländern liegt, da das DHL Modul das CN23 Formular nur erstellt, wenn der Steuersatz auf 0 steht. Zumindest hab ich den Code so gedeutet. Deshalb der Test mit Afghanistan, da dort der Steuersatz noch korrekt bei 0% angegeben ist. Das war ein Wunsch seines Chefs zb für die Schweiz dennoch deutsche MwSt zu berechnen. Grund weiß ich nicht mehr. Übrigens könnte es auch daran liegen dass eure Verkäufe ins Ausland gesunken sind, da es dadurch für die Kunden viel teurer ist, und nicht am schlecht sichtbaren OSS Modul lag, wie du vermutet hattest.
[...]

Ahhhaaaa das könnte es dann wohl sein @Timm.

Wir haben ja für ALLE nicht EU Länder 19% MwSt. eingestellt. Warum frag mich nicht. Chef sagt er will das so.
Da werd ich ihn dann noch mal drauf ansprechen, dass es vielleicht daran liegt und wir dann die Steuer auf 0% setzen.

Warum nun nur Afghanistan noch 0% hatte ist mir ein Rätsel. Sollte eigentlich auch 19% sein.
Hab es nun aber auf 19% gestellt.

Wenn ich mit Rücksprache vom Chef die Steuer auf 0% setzen kann und es dann funktioniert, dann geb ich hier nächste Woche nochmal Rückmeldung.

VG
Nils

[Timm]

[...]
Wenn ich mit Rücksprache vom Chef die Steuer auf 0% setzen kann und es dann funktioniert, dann geb ich hier nächste Woche nochmal Rückmeldung.
[...]

Das wäre Zucker 

Es haben sich mehrere um dein Problem gekümmert. Mich allein hat das vielleicht ne Stunde gekostet um eine mögliche Ursache zu entwickeln, deinen Shop darauf hin anzuschauen, im Code die Stelle dafür zu finden und dann hier einen Text zu formulieren.

Und du schaffst es nicht eine Testbestellung mit einem Land, das noch den Steuersatz 0% hat zu erstellen und zu berichten? Stattdessen aber die Zeit bei dem Land den Steuersatz zu erhöhen. Du hast ein Problem für das du keinen Entwickler ansetzen möchtest, wir helfen und sollen dann immer warten und uns wieder ins Thema einlesen?

So funktioniert das nicht im Forum. Von einem nicht vorhandenen einfachen Danke mal ganz zu schweigen.

Ich bin bei deinem Problem raus, sofern es nicht noch einen Mehrwert für die Community gibt.

Gruss Timm

[Onlineshopper]

Was ist dir denn über die Leber gelaufen?     

Entschuldige bitte, dass ich nicht sofort eine Testbestellung gemacht habe, da ich noch anderes auf dem Zettel hatte.

Ich hab jetzt mal alles so gemacht, wie Du sagtest und erhalte folgende Fehlermeldung als Afghane:

Code: [Auswählen]

ERROR - Code: Client Message: SOAP-ERROR: Encoding: string 'M\xfc...' is not a valid utf-8 string
Wenn Du nicht weiter helfen möchtest und Du jetzt "raus" bist, dann ist das für mich in Ordnung.

Möchte das Problem hier in der Community niemand "öffentlich" lösen, weil ich nicht sofort etwas umgesetzt habe, dann werde ich schon einen Entwickler von modified per Auftrag und Zahlung beauftragen, so wie ich das immer mache, wenn etwas benötigt wird oder nicht funktioniert in unserem Shop.

Zum Anderen habe ich mich immer bedankt, wenn mir geholfen wurde. Das ich vielleicht jetzt noch nicht danke gesagt habe, wenn das Problem noch gar nicht gelöst wurde. Ja was soll ich sagen ... Es tut mir leid, niemand ist perfekt.

Nils

[Timm]

Da nun die falschen Steuersätze nicht mehr den anderen Fehler hervorrufen und die gleiche Fehlermeldung wie bei @weichen-walter auftritt, ist klar, dass es ein Problem mit Umlauten in latin1 Shops bei non EU Sendungen gibt und das Team kann es für alle fixen.

Wenn du die Absenderadresse mit ue schreibst (siehst du an der Fehlermeldung, dass er nach dem M das ü bemängelt und dort abbricht), dann sollte es funktionieren sofern die non EU Länder einen Steuersatz von 0% erhalten. Es wird auch mit einem Fix des Teams nicht funktionieren solange die non EU Länder nicht einen 0% Steuersatz haben. Dein Chef muss also überlegen was ihm wichtiger ist.

Gruss Timm