Möglicher Bug in Versandkostenregeln

[cooper64]

Hi Leute,

wir sind da über was gestolpert, was evtl. ein Bug sein könnte und darum möchte ich das hier mal teilen…
Wir benötigen drei Versandkosten-Abstufungen für Normal/Überlängen.

• Normale Pakete → Artikel->Erweitert->Maße (L:B:H) gepflegt auf 0,0,0 (Paketpreis soll sein 4,95 €)
• Überlänge → Artikel->Erweitert->Maße (L:B:H) gepflegt auf 1.2,0.05,0.05 (Paketpreis soll sein 6,95 €)
• XXL Überlänge → Artikel->Erweitert->Maße (L:B:H) gepflegt auf 2.1,0.05,0.05 (Paketpreis soll sein 16,95 €)

Versandkostenregeln entsprechend angelegt mit der Bedingung (Größe zw. 2m und 999m = 16,95, Größe zw. 1m und 2m = 6,95, und der Rest 4,95)

Das scheitert aber daran, dass der Shop hier nicht nur die Länge berücksichtigt, sondern ein Gurtmaß aus allen drei Seitenlängen errechnet und dann noch erschwerend, dass das Ganze auch noch auf die Anzahl der Artikel aufmultipliziert wird. Wenn man nach Volumen versendet, ist das sicher brauchbar, aber man kann damit nicht wirklich eine Versandkostenregel hinterlegen, die sich auf Überlänge eines Paketes bezieht. Bei all unseren Versanddienstleistern ist kostentechnisch das Thema Überlänge immer schon das wichtigere gewesen. Gurtmaße ist nur selten von Relevanz…

Aber nun zum Bug:
Aus meiner Sicht wird das Gurtmaß in der Funktion Model->Article->getSize() falsch berechnet.
Die Werte oxlength, oxwidth, oxheight können hier nicht multipliziert werden!?
Wenn ich eine Leuchtröhre anbieten, die 1,20 m lang ist und in der Höhe/Tiefe jeweils 0,05 m, dann erhalte ich aus der Multiplikation ein Maß von 0,003 m.

Ich denke, die Werte gehören an der Stelle eher addiert. Oder liege ich da falsch?

cooper

[vanilla_thunder]

Hier hat jemand vor Jahren “Volume” als Größe übersetzt. Immerhin nicht Lautstärke

Wenn ich es richtig verstanden habe, brauchst du eine Logik basierend auf der größten Abmessung von allen Artikeln, egal wie viele Artikel es sind?

[marco.steinhaeuser]

Ich glaube nicht, dass “Größe” ein Wert ist, um das Gurtmaß abzubilden. Ich würde es viel eher so sehen, dass man damit die Möglichkeit hat, unabhängig vom echten Abmaß der Produkte verschiedene Versandarten zuordnen zu können. Alternativ hätte man damit eine Grundlage, eigene kompliziertere Versandarten per Modul selbst zu stricken.

Es gibt ja im Stückgut-/Paketversand eintausend verschiedene Möglichkeiten der Berechnung:

• Realgewicht
• Gurtmaß
• Überlängen (Bandfähigkeit)
• Volumengewicht (LBH/5000 oder /6000 ← je nachdem ob national oder international)
• Palettengewicht => 151 kg pro Europalette, es sei denn, es ist drüber
• usw.

Da sich die Bandfähigkeit (längste Seite z.B. > 120 cm) von Spediteur zu Spediteur unterscheiden und auch ständig wechseln kann, hätte man über die vorhandenen Optionen die Möglichkeit, unreale Größen, Längen, Gewichte etc. im Shop festzulegen oder man schreibt sich selbst ein Modul für seine spezielle Anforderung.