In Bearbeitung [WAWI-50281] Schwerer Fehler in dot liquid führt zu Fehlberechnungen - Typen Deklaration Problem

[John]

Seit ca. Wawi 1.5.30.1 gibt es einen Bug in Dotliquid.

{% assign zahl = 100 -%}
{% assign faktor = 0.01 -%}\

{% assign ergebnis_1 = faktor | Times: zahl  -%}\
{% assign ergebnis_2 = zahl | Times: faktor  -%}\
{{ ergebnis_1 }} = {{ ergebnis_2 }}

Dieser Code liefert 1 = 0

Offenbar ist der Typ der Ergebnis Variable nur noch anhängig vom ersten Faktor. BÖSE. Ticket mache ich gleich auf...

John

 

[John]

Ticket#202010191000276 ist offen. Der Fehler ist auch in der aktuellen 1.5.31.1 noch zu finden.

John

 

[NETZdinge.de]

Der Typ des Wertes für die Times Funktion wird int sein... blöd...

 

[John]

Addition ist ebenfalls betroffen

{% assign zahl = 100 -%}
{% assign faktor = 0.01 -%}\

{% assign ergebnis_1 = faktor | Plus: zahl  -%}\
{% assign ergebnis_2 = zahl | Plus: faktor  -%}\
{{ ergebnis_1 }} = {{ ergebnis_2 }}

100,01 = 100

...vermutlich alle Rechenarten.

 

[John]

Es hilft auch nicht, die Variablen durch erstmalige Initialisierung auf einen passenden Datentyp zu zwingen.

Wie kann das sein? Wird der Datentyp im nachhinein auf Integer umdeklariert? Wird ja immer schlimmer!

{% assign zahl = 100 -%}
{% assign faktor = 0.01 -%}\

{% assign ergebnis_1 = 0.1 -%}
{% assign ergebnis_2 = 0.1 -%}

{{ ergebnis_1 }} = {{ ergebnis_2 }}

{% assign ergebnis_1 = faktor | Plus: zahl  -%}\
{% assign ergebnis_2 = zahl | Plus: faktor  -%}\

{{ ergebnis_1 }} = {{ ergebnis_2 }}

liefert

0,1 = 0,1

100,01 = 100

 

[Dominic Nelle]

{% comment -%}
Hier ist "zahl" ein Integer.
{% endcomment -%}
{% assign zahl = 100 -%}
{% assign faktor = 0.01 -%}\
{% assign ergebnis_1 = faktor | Times: zahl  -%}\
{% assign ergebnis_2 = zahl | Times: faktor  -%}\
{{ ergebnis_1 }} = {{ ergebnis_2 }}

{% comment -%}
Hier ist "zahl" ein Double.
{% endcomment -%}
{% assign zahl = 100.00 -%}
{% assign faktor = 0.01 -%}\
{% assign ergebnis_1 = faktor | Times: zahl  -%}\
{% assign ergebnis_2 = zahl | Times: faktor  -%}\
{{ ergebnis_1 }} = {{ ergebnis_2 }}

So geht es

 

[John]

@Dominic Nelle danke für das Beispiel, aber es lässt sich so nicht in die Praxis übertragen, weil man nicht sicherstellen kann, daß alle Variablen einer Berechung als Double initialisiert werden.

Beispiel aus einem Workflow im Bereich Rechung

{% assign WarenWertNettoGesamt = 0 -%}\
{%- for pos in Vorgang.Auftrag.Positionen -%}\
{% assign WarenWertNettoGesamt = WarenWertNettoGesamt | Plus: pos.NettopreisGesamt  -%}\
{%- endfor -%}\

{{ WarenWertNettoGesamt }}

pos.NettopreisGesamt kommt mit Sicherheit nicht Integer daher. Trotzdem wird er als solcher aufsummiert. Das hier erzeugt im Ergebnis einen Rundungsfehler

Ich finde, den Bug eindeutig. Aktuell wird das Kommutativgesetz der Mathematik verletzt und das geht nicht.
In einer Umgebung mit expliziter Typendeklaration, ja, da bin ich selbst für korrekte Typen verantwortlich. Das ist aber in dotliquid nicht der Fall. Ich kann gar nicht deklarieren. Also müßt ihr Euch darum kümmern und zwar korrekt.

Viele Grüße

John

 

[Gelöschter Benutzer 52062]

Hi John,

pos.NettopreisGesamt kommt mit Sicherheit nicht Integer daher

Schau dir das Beispiel von Dominic nochmal an. Es geht in erster Linie nicht um die Variable dir wir zur Verfügung stellen.
Der von dir deklarierte "WarenWertNettoGesamt" = 0 ist der Integer der hier Probleme bereitet. Versuch die gleiche Berechnung bitte einmal mit 0.00 als initialem Wert.

weil man nicht sicherstellen kann, daß alle Variablen einer Berechung als Double initialisiert werden.

Dafür gibt es in DotLiquid einen eigenen Filter: ToDouble https://guide.jtl-software.de/jtl-wawi/vorlagen/filter-in-dotliquid/#als-zahl-todouble

Also müßt ihr Euch darum kümmern und zwar korrekt

Hier würde ich dir sogar Recht geben, wenn wir Einfluss darauf hätten. Wäre DotLiquid meine eigene Library würde ich einiges anders machen.
In der JTL-Wawi verwenden wir aktuell DotLiquid in der Version 1.7.0.0
Siehe dazu auch:
http://dotliquidmarkup.org/
https://github.com/dotliquid/dotliquid


Nach meinem Verständnis ist Liquid eine Template-Sprache für Shopify-Themes. (https://shopify.github.io/liquid/)
Die .Net-Portierung DotLiquid gibt unseren Kunden eine einfach zugängliche Möglichkeit E-Mail und Designvorlagen dynamisch zu gestalten.
Für die meisten Textoperationen in Workflows oder dem Amazon Lister ist sie auch ausreichend.

Falls du allerdings mit dem ToDouble-Filter nicht zufrieden bist gibt es immer noch die Möglichkeit auf SQL auszuweichen.

Mit DirectQuery oder DirectQueryScalar könntest du Berechnungen in SQL durchführen und das Ergebnis dann nochmal in Liquid behandeln.
Mir selbst fallen Berechnungen in SQL auch wesentlich leichter als mit umständlichen Filtern und nicht klar erkennbaren Datentypen in Liquid.


Viele Grüße,
Daniel

 

[John]

@daniel.barredo.diaz Danke für Deine Ausführungen aber was mache ich, wenn ich einen Variable, die durch Euch als Integer bereitgestellt wird (z.B. Anzahl der Positionen im Auftrag) mit einer Fließkommazahl verrechnen muß? Bsp:

{% assign test = 0.0 -%}
{% assign test = Vorgang.Auftrag.Positionen.Anzahl | Plus: 0.01 -%}

Funktioniert nicht. Ja, ich kann die Summanden hier umdrehen. Aber das kann es ja wohl nicht sein.
Dein Vorschlag mit ToDouble erwartet als Eingabe einen String. Soll ich den Integer in einen String konvertieren, um ihn dann in einen Double zu wandeln?!?

Bitte beachte auch: Das Problem gab es z.B. mit Wawi 1.5.26.0 noch nicht. Aus meiner Sicht hat sich da ein Bug eingeschlichen, ob nun bei Euch oder in der externen Bibliothek.

Viele Berechnungen, die es hier im Forum als Beispiele gibt oder die draussen bei Kunden laufen, werden Fehler nach dem Wawi Update liefern.

Ich melde mich ja hier auch nur, weil es bei Kunden von mir gekracht hat und vorher lief.

Viele Grüße

John

 

[Gelöschter Benutzer 52062]

Hi John,

mir sind keine Änderungen bekannt. Die DotLiquid 1.7.0.0 verwenden wir schon ewig.
Auch an dem Feld Anzahl hat sich nichts geändert.

Viele Berechnungen, die es hier im Forum als Beispiele gibt oder die draussen bei Kunden laufen, werden Fehler nach dem Wawi Update liefern

Das wäre nicht gut. Ich werde das mal in der 1.5.26.0 nachstellen.
Du sagst dein erster Beitrag in diesem Post lieferte in der alten Version noch das richtige Ergebnis?

Ticket#202010191000276 ist offen

Btw. das Ticket finde ich leider in unserem System nicht. Könntest du nochmal darauf antworten?


Viele Grüße,
Daniel

 

[T4DT.GmbH]

{% assign test = 0.0 -%}
{% assign test = Vorgang.Auftrag.Positionen.Anzahl | Plus: 0.01 -%}

Nein das stimmt nicht:
Vorgang.Auftrag.Positionen.Anzahl ist definiert als integer. Egal welche Operation du auf int ausführst, das Ergebnis bleibt int. Das nennt sich Typensicherheit und ist so korrekt und gewollt.

 

[John]

Hier noch deutlicher:

{% assign test = 0.01 -%}
{% assign test = Vorgang.Auftrag.Positionen.Anzahl | Plus: test | Plus: 0.01 -%}
{{test}}

berechnet in betroffenen Versionen falsch. Hingegen

{% assign test = 0.01 -%}
{% assign test = test | Plus: Vorgang.Auftrag.Positionen.Anzahl | Plus: 0.01 -%}
{{test}}

berechnet auch in betroffenen Versionen richtig.

@T4DT.GmbH und wie addiert man dann einen int und einen double, außer die Reihenfolge der Summanden entsprechend halten?
Btw. die Operation wird ja nicht auf dem int ausgeführt, sondern in meinem Beispiel auf der Variablen "Test", die in der ersten Zeile als Double initialisiert wurde. Durch die Verrechnung mit dem int wird sie aber vom Double zum int und das ist imho fatal.

@daniel.barredo.diaz Alle meine Beispiele habe ich eben mit 1.5.24.1 getestet. Funktioniert darin. Mit 1.5.26.x gehts imho auch noch, habe ich ber nicht mehr zur Hand. Die Änderung ist irgendwann am danach.

Ticket#2020101910002763 - offen seit gestern. Bei der Nennung oben fehlte die letzte Ziffer.

Viele Grüße

John

 

[T4DT.GmbH]

So aus dem Kopf:
Vorgang.Auftrag.Positionen.Anzahl | ToDouble | Plus:0.1 (ungetestet)

 

[John]

@T4DT.GmbH nope. ToDouble erwartet einen String.

Egal wie man da herumschiffen kann, ich bin gespannt, warum sich das Verhalten geändert hat.

 

[Gelöschter Benutzer 52062]

ch bin gespannt, warum sich das Verhalten geändert hat.

Ich auch. Hab es auf meiner To-do-Liste stehen.

Melde mich morgen hier erneut.

 

[ple]

War bei mir auch nach einem Update.
https://forum.jtl-software.de/threads/1-5-29-0-dotliquid-kann-nicht-mehr-rechnen.137151/#post-767658

 

[Gelöschter Benutzer 52062]

Seit ca. Wawi 1.5.30.1 gibt es einen Bug in Dotliquid.

{% assign zahl = 100 -%}
{% assign faktor = 0.01 -%}\

{% assign ergebnis_1 = faktor | Times: zahl  -%}\
{% assign ergebnis_2 = zahl | Times: faktor  -%}\
{{ ergebnis_1 }} = {{ ergebnis_2 }}

Dieser Code liefert 1 = 0

Offenbar ist der Typ der Ergebnis Variable nur noch anhängig vom ersten Faktor. BÖSE. Ticket mache ich gleich auf...

John

Guten Morgen,

ich habe das Skript mal in der 1.5.24.1 und der zukünftigen 1.5.33.0 verglichen.

Ergebnis in 1.5.24.1: 1,00 = 1,00
Ergebnis in 1.5.33.0: 1 = 0

Für die Version 1.5.28.0 wurden die Filter in DotLiquid erweitert.
Möglicherweise hatte diese Anpassung ein paar ungewünschte Nebeneffekte. Die genaue Ursache kann ich dir noch nicht sagen.

Meine Kollegen prüfen das Problem bereits und sobald ich ein passendes Ticket habe wird hier im Thread natürlich aktualisiert.

@John Vielen Dank für den Hinweis auf das Problem!
Meine Workarounds helfen dir eventuell trotzdem erstmal weiter.
Mit
{% assign zahl = 100.00 -%}
bekomme ich aktuell 1 = 1 als Ergebnis.

Viele Grüße,
Daniel

 

[Gelöschter Benutzer 52062]

Hi,

das Problem wird in folgendem Ticket behandelt:
https://issues.jtl-software.de/issues/WAWI-50281

Nicht wundern, in der Ticketbeschreibung und dem dort zu sehenden Skript geht es um den Plus-Filter.
Betroffen sind folgende Filter: Times, DivideBy, Plus, Minus

Viele Grüße,
Daniel

 

[John]

Mit dem heutigen Update der Version 1.5.32.1 wurde das Problem gelöst.

Vielen Dank!