Fehler in Versandmodulen GLS und DPD

[dmun]

Hallo,

wie mir heute aufgefallen enthält das GLS und DPD Versandmodule einen kleinen Fehler, der möglicherweise zu falschen Versandkosten führt. Der Fehler passieren nur wenn mit PLZ Bereichen gearbeitet wird die unterschiedliche Versandkosten haben (z.B. Inselzuschlag) und die PLZ numerisch ist.

Hier die Problemstelle als Beispiel aus dem GLS Modul ab ca. Zeile 80:

Code: PHP  [Auswählen]

if(strlen($country_length_result['gls_weight_ref']) == 3){
$query_string ="SELECT w.gls_weight_price_string, w.gls_free_shipping_over, w.gls_shipping_subsidized FROM gls_weight w, gls_postal_to_weight pw, gls_country_to_postal cp WHERE cp.gls_postal_reference = pw.gls_postal_reference AND pw.gls_weight_ref = w.gls_weight_ref AND cp.gls_postal_reference = pw.gls_postal_reference AND cp.gls_country = '" . $dest_country . "' AND '" . $dest_postal_code . "' BETWEEN pw.gls_from_postal AND pw.gls_to_postal";

Die Variabel $dest_postal_code wird in der SQL Abfrage in Hochkomma eingeschlossen und somit als String übergeben was aber auf der DB-Seite zu einer Konvertierung und einem falschen Integerwert führt da '38112' nicht = 38112 ist.
In diesem Beispiel würde eine PLZ-Bereich von 0 bis 6999 bei '38112' einen Treffer bringen bei 38112 aber nicht.

Zur Vermeidung dieser Problematik müsste zuerst die $dest_postal_code auf Integer oder String geprüft und gleich mit Hochkomma versehen werden wenn String.

Lösungsvorschlag:

Code: PHP  [Auswählen]

         
if (!is_int($dest_postal_code)) {$dest_postal_code = "'" . $dest_postal_code . "'";}

if(strlen($country_length_result['gls_weight_ref']) == 3){
$query_string ="SELECT w.gls_weight_price_string, w.gls_free_shipping_over, w.gls_shipping_subsidized FROM gls_weight w, gls_postal_to_weight pw, gls_country_to_postal cp WHERE cp.gls_postal_reference = pw.gls_postal_reference AND pw.gls_weight_ref = w.gls_weight_ref AND cp.gls_postal_reference = pw.gls_postal_reference AND cp.gls_country = '" . $dest_country . "' AND " . $dest_postal_code . " BETWEEN pw.gls_from_postal AND pw.gls_to_postal";

Wichtig ist, dass die ' und ' um die $dest_postal_code in der SQL Query auch raus genommen werden, sonst Fehler bei der Abfrage.

Wie gesagt betrifft dieses Problem die bei Modified enthaltene DPD und GLS Modul wenn PLZ Gebiete verwendet werden und alle anderen Versandmodule die auf den beiden genannten Modulen aufbauen.

Viele Grüße, Dirk



Linkback: https://www.modified-shop.org/forum/index.php?topic=29792.0

[Matt]

Hier liefern beide Abfragen das exakt gleiche Ergebnis. Alles andere hätte mich auch überrascht. Schließlich sind ja gls_from_postal und gls_to_postal auch varchar-Felder.

Deine Abfrage nach is_int() dürfte neue Probleme aufwerfen. Wenn, dann willst du is_numeric() verwenden.

[dmun]

Hallo,

auch wenn die DB Felder vom Typ VAR sind, machte es bei einer BETWEEN Abfrage einen Unterschied ob Int oder String geprüft wird.
Wenn man eine Zahl mit einander vergleicht, dann ist 20 kleiner als 30, 40 kleiner als 50. Nimmt man nun aber einen String dann entscheidet nicht der Wert der in dem String steht sondern der alphabetische Vergleich, weshalb dann '10' kleiner als '5' ist. Daher bekomme ich auch einen Treffer bei meinem Beispiel mit '0 bis 6999 bei '38112' wo dann ein Datensatz angezeigt wird bei dem  die PLZ bei '0' anfängt und bei '6999' aufhört, denn in diesem Fall ist der String 38112 "kleiner" als der String '6999'.
Es müssen also verschiedene Voraussetzungen gegeben sein, damit der Fehler auftritt.

Und wer es nicht glaubt, dann bitte mal auf dem MySQL Prompt folgende Abfragen ausführen:

einmal:
SELECT CASE 1
WHEN '39999' < '699'
THEN 'kleiner'
ELSE 'grösser' END;

und einmal:
SELECT CASE 1
WHEN 39999 < 699
THEN 'kleiner'
ELSE 'grösser' END;

Und nein, ich meine Prüfung auf !is_int.

Viele Grüße, Dirk

[noRiddle (revilonetz)]

...
Deine Abfrage nach is_int() dürfte neue Probleme aufwerfen. Wenn, dann willst du is_numeric() verwenden.

Verstehe ich jetzt auch nicht.
Soweit ich das sehe hat dmun völlig Recht und alles korrekt analysiert.

dmun, würdest du bitte ein Ticket dafür erstellen oder zumindest den "Moderator informieren"-Button klicken ?

Gruß,
noRiddle

[jannemann]

Hallo noRiddle,

besser ist es, wenn dmun dafür ein Ticket erstellt, dann bleibt es gespeichert und kann bearbeitet werden.

Schöne Grüße,
Jan

[noRiddle (revilonetz)]

Jau, da sich aber manche schwertun mit dem Esrtellen eines Tickets, denke ich, daß es ein Moderator machen könnte wenn es denn nicht selbst gemacht wird, besser als wenn es untergeht.

Gruß,
noRiddle

[web28]

@dmum

Vielen Dank für den Hinweis.

Diese Zeiel ist mir aber unverständlich

Code: PHP  [Auswählen]

if (!is_int($dest_postal_code)) {$dest_postal_code = "'" . $dest_postal_code . "'";}

Als Ergebnis bekommt man doch wieder einen String.

Meiner Meinung nach sollte das hier ausreichen:

Code: PHP  [Auswählen]

 "' AND " . (int)$dest_postal_code . " BETWEEN

Vielleicht kann das jemand mal testen.

Gruss Web28

[dmun]

Hallo,

ich muss erst einmal eine kleine Entwarnung geben.
Das oben beschriebene Problem tritt nur auf wenn PLZ mit unterschiedlicher Länge verwendet werden.
Bei dem genannten Beispiel war, wie ich jetzt nach erneuter Prüfung fest gestellt habe, durch den Export und Import der Daten (DB <-> Excel) die führende Null verloren gegangen, was zu diesem falschen Treffer geführt hat.
Wenn also die Länge der PLZ des Landes immer gleich ist, dann ist alles OK. Ich weis jetzt (noch) nicht ob bei allen Ländern die in Betracht kommen, die PLZ immer gleiche Länge hat oder nicht. Dies werde ich aber noch prüfen.

Allerdings gibt es eine Unschönheit mit Großbritanien (wen wundert's ).
Im Modul wird die PLZ bei GB auf die zwei ersten Stellen reduziert, allerdings gibt es zumindest bei DPD laut aktueller Versandinfo Sondergebiete bei denen die erste beiden Stellen gleich sind und die Unterscheidung nur in den beiden folgenden Stellen statt findet. Beispiel: bei Loch Lemond der Bereich FK17 - FK21. Dieser Bereich würde in der aktuellen Version nicht richtig erkannt werden.

Es müsste reichen wenn die Begrenzung auf 4 Stellen geändert wird. Also:

Code: PHP  [Auswählen]

if($dest_country == 'GB') {
          $dest_postal_code = substr($dest_postal_code, 0, 2);
        }

auf

Code: PHP  [Auswählen]

if($dest_country == 'GB') {
          $dest_postal_code = substr($dest_postal_code, 0, 4);
        }

Ich konnte dies bis jetzt nur auf der DB testen. Ich versuche im Lauf des Tages ein paar weitere Test zu fahren.

@web28: . (int)$dest_postal_code . wäre der falsche Ansatz, da damit auch die alphanumerischen PLZ wie in GB oder NL nach Int convertiert werden, was dann MySQL dazu veranlasst die Strings aus den VON BIS Spalten ebenfalls nach Int zu konvertieren und dies dann zu einem falschen Ergebnis führen würde.

Viele Grüße, Dirk

[dmun]

Hallo nochmal,

mal etwas weiter getestet mit England und mit der o.a. Änderung auf 4 Stellen lassen sich die genannten Sondergebiete ebenfalls abdecken aber danach greifen die Gebiete nicht mehr bei denen VON BIS gleich ist. Beispiel: 'ZE', 'ZE'. Damit dieses Gebiet wieder funktioniert, müsste man die Daten auf 'ZE00', 'ZE99' ändern.
Ich beiße noch in die Tischplatte...

Viele Grüße, Dirk

[Matt]

Das oben beschriebene Problem tritt nur auf wenn PLZ mit unterschiedlicher Länge verwendet werden.

Deshalb hat es bei mir gestern auch zweimal das gleiche Ergebnis geliefert

Außerdem dachte ich die Daten kamen aus einem Formular, deshalb der Hinweis auf get_numeric(). Dem ist aber anscheinend nicht so.

[dmun]

Hallo Matt,

nein die Daten werden bei der Installation des aktuellen DPD und GLS Versandmoduls in die DB geschrieben.
Wie schon gesagt, kann für das erste Problem Entwarnung gegeben werden.

Nimmt man aber die aktuellen Daten von DPD was die Sondergebiete betrifft und hinterlegt diese, dann muss man die bereits erwähnten Änderungen machen, damit alles Sondergebiete berücksichtige werden.
Versendet man nur innerhalb D, dann ist alles kein Problem. Aber wenn man auch Kunden von den den englischen Inseln hat, dann muss man nachbessern. Da für die Inselzustellung teilweise deutliche Aufschläge anfallen, kann das auch schnell recht teuer werden.

Viele Grüße, Dirk