MODUL: DHL Versand & Label-Erstellung

[Tomcraft]

Wir schauen uns das am Montag nochmal an.
Danke für die ausführlichen Tests dazu!

Grüße

Torsten

[Bonner]

Ich habe mal in unserem Shop (modified eCommerce Shopsoftware v2.0.6.0 rev 13500) ein Update des Moduls auf die neueste Version gemacht.

Folgende Dinge sind mir aufgefallen, die man eventuell verbessern könnte/sollte:

1. EU Versand
Beim Paketversand innerhalb der EU wird nach unserem Vertrag und meines Wissens nach ist das dort bei allen Geschäftskunden gültig, das Paket im Premiumservice versendet. Derzeit muss bei jedem EU-Paket im Backend nochmals diese Einstellung gesondert ausgewählt werden. Derzeit gibt es zwar die Möglichkeit in den Grundeinstellungen des Moduls
grundsätzlich den Premiumversand als Standard auszuwählen, was dann aber neben den EU Paketen auch für den Bereich "Welt" gilt.
Hier wäre es meines Erachtens sinnvoll,  einen Split zwischen EU und Welt zu machen, so dass man in den Grundeinstellungen gesondert für die Zonen EU und Welt jeweils einen Standard festlegen kann.

2. E-Mail Benachrichtigung D/EU/WELT
Gleiches gilt für die Mailbenachrichtigungen, die man in den Grundeinstellungen nur allgemein ein oder ausschalten oder individuell im Backend je Paket festelgen kann.
Aufgrund der DSVGO ist das innerhalb von D relativ problematisch ohne Kundenzustimmung. Innerhalb der EU gilt das ebenso, ist aber nach unseren Erfahrungen eigentlich Standard, das das gewünscht wird. Zone Welt ist dahingehend unproblematisch.
Deshalb fände ich es sinnvoll, in den Grundeinstellungen die Mailbenachrichtigungen je Zone D/EU/WELT allgemein steuern zu können.

3. Vorausverfügung EU/WELT
Beim Auslandversand ist generell eine Vorausverfügung erforderlich, die reglet was bei Unzustellbarkeit passieren soll (Rücksendung oder Verwertung).
Diese Einstellung fehlt in den Grundeinstellungen vollkommen und wird im GK-Portal grundsätzlich als Fehler bemängelt.

Bonner

[Tomcraft]

Das Modul aus Beitrag 1 wurde aktualisiert.
Eingeflossen sind die Korrekturen aus r14308, r14309 & r14310.
Vorausverfügung für Auslandssendungen wurde ergänzt.
Die Umlautfehler im CN23 Formular für latin1 Shops wurden korrigiert.

Grüße

Torsten

[Viol]

Okay, wollte mich nur absichern, damit ich nicht in eine falsche Richtung steuere.

Hallo, ich wäre immer noch daran interessiert, dass die Zoll- und Gewichtsangaben in der Bestellung festgelegt werden können. Bist Du da noch dran? Ich stelle mich auch gerne als Tester zur Verfügung. Im Moment ist es eben relativ blöd, weil man beim Export diese Daten nicht mit dabei hat, und daher auch nicht importieren kann.
Könnte man da evt. auch etwas mit sql machen? Mit into oder update? Es ist bei mir so, dass viele Produkte ein identisches Gewicht haben. Ebenso haben habe ich für meine Produkte im Prinzip 2 verschiedene Zolltarifnummern und die Zollinhaltsbeschreibung könnte der englische Artikelname sein. Es wäre z.B. so:
Alle Artikel, die im Namen (products_name in der Tabelle products_description) " Hersteller Produktbezeichung" haben , bekommen das Gewicht 0.003 (Spalte weight in der Tabelle products), die Zolltarifnummer 92025000(Spalte products_tariff in der Tabelle products) und das Herstellerland (Spalte products_origin in der Tabelle products) "Germany" und den englischen Artikelnamen (products_name language id 1 in der Tabelle products_description) für die Beschreibung der Ware (Spalte products_tariff_title in der der Tabelle products).
Für Tipps wäre ich dankbar..

[Onlineshopper]

Servus zusammen,

jetzt hab ich bei dem Modul das Update eingespielt und wenn ich das erstellte Label aufrufen möchte, bekomme ich die Meldung im Screenshot.

VG
Nils

[Timm]

Dann wird die Zeit abgelaufen sein, bis zu der der Link gültig ist. Danach kannst du es nur noch im DHL Gk Portal ansehen.

Oder wurde das Label gerade erst erstellt?

Gruß Timm

[Onlineshopper]

Der ist von gestern gewesen.

VG
Nils

[crewshop24]

Kurze Frage zu folgendem Problem:

Kunde gibt folgende Straße im Shop ein:

Hoejdevej 35, 3.tv

Druckt man das Label aus dem Shop heraus als Warenpost Int., verschwindet die 5 und aus der Straße wird

Hoejdevej 5, .tv 3

Siehe Anhänge.

Post kommt natürlich zurück und der Kunde ist sauer.

Jemand eine Idee wie das sein kann?

Grüße
Easy

[Tomcraft]

Ich sehe da kaum eine Möglichkeit die Funktion parse_street_address() in der Datei "/includes/external/dhl/DHLBusinessShipment.php" derart umzubauen, dass sie das abfängt, aber vielleicht hat ja jemand dazu eine Idee?

Grüße

Torsten

[online-beobachter]

Ich kenne das Problem auch und fände es gut wenn man so eine Art Checkbox hätte wo man einmalig für dieses Label die Prüfung deaktivieren kann, wenn man schon vorher sieht, dass diese Straße aufgrund der Komplexität Probleme macht.
Bisher ist das immer reines Glücksspiel was da raus kommt. Oft kopiere ich die ganze Straße schon vorher noch in das Zusatzfeld darunter damit ich dann die vermurkste Straße auf dem Label durchstreichen kann, die korrekte steht ja dann immer noch darunter.

[noRiddle (revilonetz)]

[...]
Kunde gibt folgende Straße im Shop ein:

Hoejdevej 35, 3.tv

Druckt man das Label aus dem Shop heraus als Warenpost Int., verschwindet die 5 und aus der Straße wird

Hoejdevej 5, .tv 3
[...]

@Tomcraft
Einfach Komma und Punkt hinzufügen (zum ersten preg_match_all) ?
Also statt:

Code: PHP  [Auswählen]

preg_match_all("! [0-9]{1,5}[/ \- 0-9 a-z A-Z]*!m", $street_address, $matches, PREG_SET_ORDER);

(wofür sind eigtl. die ganzen Leerzeichen ? Eines reicht doch)

so:

Code: PHP  [Auswählen]

preg_match_all("![0-9]{1,5}[/ \-0-9a-zA-Z,\.]*!m", $street_address, $matches, PREG_SET_ORDER);

Getestet mit https://regex101.com/.

Gruß,
noRiddle

[Timm]

Moin

Wenn wir schon dabei sind...

Hab auch noch eine Adresse, die über den Shop kein Label erstellen lässt, da dann nicht leitcodierbar.

Str. 50/15c
13125 Berlin

Str. 50 15c
13125 Berlin

Hab es dann mit der zweiten Version über das Geschäftskundenportal probiert und da ging es sofort.

Ähnliche Adressen wird es auch in Mannheim geben, wo die Strasse nur aus einem Buchstaben mit Zahl und folgender Hausnummer bestehen.

Kann der neue Regex das abbilden?

Grüße Timm

[noRiddle (revilonetz)]

Ich verstehe vielleicht nicht.
Die Strasse heißt "50" in deinem Beispiel und die Hausnummer "15C" ?
Wenn ja kann man das nicht abfangen weil eine Nummer nun mal eine Nummer ist. Da Code nicht denken kann wird es kaum eine Möglichkeit geben zu erkennen, daß eine Nummer nun der Strassenname sein soll.

Evtl. geht es mit einem negativen Lookbehind nach dem expliziten String "Str.", hab' aber nicht wirklich eine Lösung.
Das z.B. reicht bei "Str. 50 15c" nicht aus:

Code: PHP  [Auswählen]

"!(?<!str\. )[0-9]{1,5}[\/ \-0-9a-zA-Z,\.]*!im"

(hier mit der i Option für case insensitive)

Weil dann die Nummer so abgespalten würde "0 15C", also lediglich die 5 zum Strassennamen gerechnet würde.
Mittels eines Lookahead nach einem Leerzeichen oder einem Slash zu schauen hülfe nicht, da ein Leerzeichen ja gerade erlaubt sein muß (vorhanden in der zweiten Einklammerung), z.B. für Hausnummer 15 C.

Gruß,
noRiddle

[Timm]

[...]
Die Strasse heißt "50" in deinem Beispiel und die Hausnummer "15C" ?
[...]

Korrekt. Vermutlich gehts im GK Portal, weil dort Straße und Hausnummer separate Felder sind.

Gruß Timm

[esoversum]

Starkes Modul!

Ist es vielleicht auch geplant, ähnliches für die österreichische Post oder DHL bzw. DPD Österreich zu erstellen?

Nachtrag: Vielleicht ist vorrangig für DPD was in Arbeit?

Hat da jemand Erfahrung? Oder vielleicht auch eine Alternatividee, wie der Versand aus Österreich relativ schonend und übers backend ablaufen könnte?

Gruß,
eso