Gelöst [WAWI-16430] [WAWI-20025] DotLiquid: Abfrage gibt seltsamen String aus

[SebiW]

Hallo zusammen,
ich komme wohl gerade wieder einmal an meine DotLiquid Grenzen und wollte fragen ob einer von Euch vielleicht behilflich sein kann.

Ich bastele an einer automatischen Kalkulation. In Schritt 1 möchte ich erstmal nur Vorschalgswerte erzeugen. Dazu setze ich mit folgender erweiterten Eigenschaft einen Wert in ein Funktionsattribut der Klasse "Preis":

{% assign EK = Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | FormatNumber: 'N4', 'de-DE' -%}
{% if EK <= 0,01 %}
{{Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: 9 | FormatNumber: 'N4', 'de-DE'}}
{% elsif EK > 0,01 and EK <= 0,02 %}
{{Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: 6.5 | FormatNumber: 'N4', 'de-DE'}}
.
.
.
{% else -%}
{{Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: 2.17 | FormatNumber: 'N4', 'de-DE'}}
{% endif %}

Daraus ableitend wollte ich nun in einem weiteren Workflow einen Mindestabverkaufspreis in ein weiteres Funktionsattribut vom Typ Preis folgendermaßen setzen:

{{Vorgang.Attribute.Global.Autokalkulation.KALK-Abverkauf.Einsprachig | Times: 0.79 | FormatNumber: 'N4', 'de-DE'}}

Allerdings ist der Wert, der hier aus Vorgang.Attribute.Global.Autokalkulation.KALK-Abverkauf.Einsprachig ausgelesen wird eine 15stellige Zahl. Ich vermute mir fehlt hier nur irgendein Parameter? Der Wert beim Artikel öffnen und in allen sonstigen Abgleichen sieht richtig aus und funktioniert problemlos.

Ich habe ein ähnliches Problem hier dokumentiert gefunden:
https://forum.jtl-software.de/threa...eines-artikels-vom-typ-fliesskommazahl.98022/

Ist das tatsächlich ein Bug?

 

[Rico Giesler]

Hallo @SebiW
Scheinbar gibt es tatsächlich einen Fehler im Zusammenhang mit Fließkommazahlen.
Es gibt dazu bereits ein Ticket welches hier eingesehen werden kann https://issues.jtl-software.de/issues?query=WAWI-16430
Dieses ist schon als gelöst markiert für die Version 1.3

 

[gutberle]

@SebiW - Dann würde ich Dich bitten, hier Deinen kompletten DotLiquid Code zu posten, denn dann probiere ich gerne schnell durch, ob das Problem in der 1.3.3.0 tatsächlich gelöst ist...

 

[SebiW]

Hi Gutberle, klar kein Problem:

Als Vorarbeit habe ich zwei Funktionsattribute des Datentyps "Preis" mit den Namen KALK-Mindestpreis und KALK-Abverkauf erzeugt. Diese befülle ich in zwei Schritten. KALK-Mindestpreis befülle ich so:

{% assign EK = Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | FormatNumber: 'N4', 'de-DE' -%}
{% if EK <= 0,01 %}
{{Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: 9 | FormatNumber: 'N4', 'de-DE'}}
{% elsif EK > 0,01 and EK <= 0,02 %}
{{Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: 6.5 | FormatNumber: 'N4', 'de-DE'}}
{% elsif EK > 0,02 and EK <= 0,04 %}
{{Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: 5 | FormatNumber: 'N4', 'de-DE'}}
{% elsif EK > 0,04 and EK <= 0,1 %}
{{Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: 4 | FormatNumber: 'N4', 'de-DE'}}
{% elsif EK > 0,1 and EK <= 0,5 %}
{{Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: 3 | FormatNumber: 'N4', 'de-DE'}}
{% elsif EK > 0,5 and EK <= 1 %}
{{Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: 2.3 | FormatNumber: 'N4', 'de-DE'}}
{% elsif EK > 1 and EK <= 5 %}
{{Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: 2.2 | FormatNumber: 'N4', 'de-DE'}}
{% else -%}
{{Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: 2.17 | FormatNumber: 'N4', 'de-DE'}}
{% endif %}

In einem zweiten Workflow Schritt lese ich dann das Feld aus um es modifiziert in KALK-Abverkauf zu schreiben:

{{ Vorgang.Attribute.Global.Autokalkulation.KALK-Mindestpreis.Einsprachig | TIMES: 0.66 | FormatNumber: 'N4', 'de-DE'}}

In meinem Beispiel Artikel wird hier aus dem Wert 7,92 entspannt die Zahlt 792.000.000.000.000,0000

Da ich jetzt mit der Umsetzung dieses Systems nicht beliebig warten kann werde ich wohl mit einem Freitextfeld arbeiten müssen. Das macht die ganze Geschichte gleich nochmal komplizierter, sehr unfein. Jetzt dachte ich endlich das letzte große Problem der Wawi für uns behoben zu haben und dann grätscht so ein Mist dazwischen, verdammich

 

[gutberle]

Hallo @SebiW,

an Deinen DotLiquid Künsten liegt es nicht, das Einzige, was Du am oberen Teil noch verbessern kannst, ist hinten am Ende der {% elseif ... %} Zweige jeweils ein "-" zu ergänzen, denn aktuell wird vor dem eigentlichen Preis noch eine Leerzeile erzeugt. Das schluckt der Workflow aber wie's scheint auch wie es aktuell ist, der Vorschlag ist also eher "kosmetisch", oder sagen wir mal "hygienisch" ...

Das Funktionsattribut KALK-Mindestpreis wird bei mir sowohl in der 1.2.3.7 wie auch in der 1.3.3.0 BETA2 korrekt gesetzt, aber da wo die 1.2.3.7 bei der Abfrage des KALK-Mindestpreis Wertes noch immer eine ~verdammt große Zahl~ mit 12 Nullen vor dem Komma daraus macht, ist (zumindest) dieser Fehler in der 1.3.3.0 BETA2 behoben.

Aber zu früh gefreut, denn was auch in der 1.3.3.0 BETA2 nicht funktioniert ist das Multiplizieren des Wertes mit 0.66. Egal, was ich für einen Teiler nehme, also Dezimal- oder Ganzzahl, um auch das zu prüfen ...

{{ Vorgang.Attribute.Global.Autokalkulation.KALK-Mindestpreis.Einsprachig | TIMES: 0.66 | FormatNumber: 'N4', 'de-DE'}}

... der Rückgabewert ist und bleibt immer gleich dem aus KALK-Mindestpreis gelesenen Originalwert.

@Rico Giesler - Hier ist definitiv ein Bug Zuhause. Soll ich das im Rahmen des Pilotprogramms berichten, oder willst Du das prüfen und dann ggfls. intern machen?

Gruß,
Ingmar

 

[SebiW]

Hallo Gutberle,

danke für Dein Feedback. Da das meine erste größere DotLiquid Aktion ist lag es erstmal Nahe von einem Fehler meinerseits auszugehen. Gut zu wissen, dass ich erstmal grundsätzlich nichts falsch gemacht habe.

Danke auch für Deinen Tip mit dem -%, ich hab mich wirklich schon gewundert wo das her kam, mir jetzt aber einfach mit nemm Zwischenworkflow geholfen gehabt:

{{ Vorgang.Attribute.Global.Autokalkulation.KALK-Mindestpreis.Einsprachig | StripNewlines }}

Wenn Du vielleicht noch 2 Tipps für mich hättest wäre ich enorm dankbar:
Wie krieg ich denn das Leerzeichen nach dem Datenfeld weg? Derzeit sieht die Ausgabe bei mir so aus:
"7,9200
"
und wenn ich mir obigen Workaround sparen kann spar ich ihn mir lieber. Ich vermute da fehlt am Ende des Datenfeldes einfach noch ein Endzeichen, richtig?

Und zweitens:
Eigentlich hatte ich vor die Ergebnisse gleich noch zu runden, dann in eine csv zu schreiben und via Ameise automatisch wieder importieren zu lassen (da man ja, warum auch immer, nur den Nettopreis via Workflow setzen kann).
Dazu hatte ich eigentlich die nötigen Funktionen ceil / floor und round ausgemacht. Ich kriege die aber ums verrecken nicht zum funktionieren. Sind die in JTL vielleicht gar nicht implementiert? Spätestens dann wirds mit der Autokalkulation langsam aber sicher wirklich schwierig...

 

[Rico Giesler]

Hallo @gutberle ich melde es gern (dafür bin ich ja da).
Du kannst gern drüber schauen ob ich es so korrekt zusammengefasst habe.
Das Ticket gibt’s hier: https://issues.jtl-software.de/issues?query=WAWI-20025

 

[gutberle]

@SebiW - Das Leerzeichen hinter dem Wert ist auch noch ein Newline und die grundsätzliche Regel lautet, dass alle Zeilen, die bei ihrer Ausgabe KEIN Newline erzeugen sollen, mit einem "-" abgeschlossen werden, das gilt also auch für Deine Zuweisungen. Hinter jedes "... DE'" muss also noch ein "-".

Die DotLiquid Funktionen round, ceil und floor (siehe hier) scheint es in der Wawi tatsächlich nicht zu geben, genau wie auch alle andere Math Filter aus der Liquid Sprache. Wenn Du im Editor Fenster hinter Deiner Variable nur ein "|" eingibst und dann einen (kurzen) Moment wartest, dann wird Dir ja ein Intellisense Fenster mit allen verfügbaren Funktionen angezeigt. Dort sind die drei aber natürlich auch nicht dabei, was extrem schade ist, aber dieses Fenster erspart Dir zumindest das Rätselraten.

Ich mache es normalerweise so, dass ich mir damit behelfe, das ganze in SQL nachzubilden, denn dort gibt es natürlich mit CEILING(Value2Ceil), FLOOR(Value2Floor) und ROUND(Value2Round,Decimals2Round) die notwendigen Funktionen. Das jetzt aber hier auszuführen, geht an einem Arbeitstag mit (gottseidank) eingehenden Aufträgen leider nicht. - Vielleicht finde ich Heute Abend die Zeit, Dir hier ein paar Beispiele zu posten ...

 

[SebiW]

Hallo Gutberle,

danke nochmal für Deine Hilfe. Ich habs ja schon fast befürchtet, aber gut zu wissen, dass ich im Endeffekt an dieser Stelle mit der Arbeit aufhören kann. Von SQL Aktionen in einer erweiterten Eigenschaft habe ich leider keinerlei Ahnung.

Leider sind auch die Rundungsgruppen in der Ameise für uns nicht zu gebrauchen, da ein Gutteil unserer Artikel unter 10 Euro kostet und hier schlicht eine "Runde auf auf x,x9" Rundung fehlt.
Die Preiskalkulation in JTL bleibt also für uns weiterhin ein Drama, dass sich dank ständig variierender EKs immer weiter verschärft. Mist.

Wieso eine sonst do flexible und moderne Wawi eine solch RIESEN Lücke hat erschließt sich mir absolut nicht.

 

[gutberle]

Hi @SebiW,

ok, hier also nun wie versprochen ein paar Beispiele, wie man mit SQL Queries die in JTL's DotLiquid Implementierung fehlenden Funktionen ceil, floor und round "nachrüsten" kann. Erst kommen drei Code-Stücke, die jeweils einen der Werte zurückliefern und danach noch eine ökonomischere Variante, die alle drei Werte gleichzeitig berechnet und zurückliefert ...

CEILING(<Value>)

{% assign Value = Vorgang.Allgemein.PreiseEinheiten.VK-Brutto | FormatNumber: 'N14','en-US' -%}
{% assign CeilValue = 'SELECT CEILING(' | Append: Value | Append: ')' | DirectQueryScalar -%}

CeilValue({{ Value }})={{ CeilValue }}
>> CeilValue(5.39070024967194)=6

FLOOR(<Value>)

{% assign Value = Vorgang.Allgemein.PreiseEinheiten.VK-Brutto | FormatNumber: 'N14','en-US' -%}
{% assign FloorValue = 'SELECT FLOOR(' | Append: Value | Append: ')' | DirectQueryScalar -%}

FloorValue({{ Value }})={{ FloorValue }}
>> FloorValue(5.39070024967194)=5

ROUND(<Value>,<Decimals>)

{% assign Value = Vorgang.Allgemein.PreiseEinheiten.VK-Brutto | FormatNumber: 'N14','en-US' -%}
{% assign Decimals = '2' -%}
{% assign RoundValue = 'SELECT ROUND(' | Append: Value | Append: ',' | Append: Decimals | Append: ')' | DirectQueryScalar -%}

RoundValue({{ Value }},{{ Decimals }})={{ RoundValue | FormatNumber: 'N2','de-DE' }}
>> RoundValue(5.39070024967194,2)=5,39

Zur Funktion:

1. In der ersten Zeile lade ich meine Wunschvariable aus DotLiquid, hier also den VK-Brutto meines Artikels in eine Variable namens "Value" und formatiere sie gleich mit 14 Nachkommastellen und im US Format. Das klingt dämlich, aber was ich hier tatsächlich mache, ist die Variable so zu belassen, wie sie in der Datenbank vorliegt, nur eben als String, also als Text und mit Dezimalpunkt, denn so braucht es die SQL Abfrage.
2. Bei der ROUND() Funktion definiere ich in der zweiten Zeile noch die Dezimalstellen, auch als String=Text.
3. Dann stückele ich mir den SQL Query-String zusammen, bei CEILING() und FLOOR() noch nur mit Klammern um den Wert "Value" bei ROUND() auch noch mit den Dezimalstellen, mit Komma getrennt. Das ganze ergibt aber nur einen einfachen Textstring, der dann auch gleich über "DirectQueryScalar" als SQL Befehl ausgeführt wird.
4. In der jeweils letzten und etwas abgesetzten Zeile gebe ich das Ganze formatiert aus. Das sieht vielleicht kompliziert aus, sieht aber nur so aus, weil ich eine ganze Zeile mit Definition und Wert ausgeben. In Wirklichkeit wird der CeilValue z.B. völlig normal nur mit {{ CeilValue }} ausgegeben, die anderen ebenso einfach.

Ökonomischere Variante ...

Und hier noch eine Variante, bei der gleichzeitig alle drei Werte berechnet und dann zusammen in einer einfach abzufragenden Struktur zurückgeliefert ...

{% assign Value = Vorgang.Allgemein.PreiseEinheiten.VK-Brutto | FormatNumber: 'N14','en-US' -%}
{% assign Decimals = 2 -%}
{% capture query -%}
SELECT CEILING({{ Value}}) CeilVal, FLOOR({{ Value}}) FloorVal, ROUND({{ Value}},{{ Decimals }}) RoundVal
{% endcapture -%}
{% assign SQLValues = query | DirectQuery -%}

Wie Du siehst, ist die eigentliche Abfrage aller drei Werte in einer einzigen SQL Abfrage eigentlich sogar kürzer und leichter zu verstehen. Das liegt daran, dass ich hier mit dem DotLiquid Befehl "capture" arbeite, der es mir erlaubt, Text viel einfacher aus einzelnen Teilen zusammenzustückeln.

Die Werte werden dann wie folgt abgefragt ...

Value={{ Value }}
>> Value=5.39070024967194
Decimals={{ Decimals }}
>> Decimals=2
CeilVal({{ Value }})={{ SQLValues.Daten[0].CeilVal }}
>> CeilVal(5.39070024967194)=6
FloorVal({{ Value }})={{ SQLValues.Daten[0].FloorVal }}
>> FloorVal(5.39070024967194)=5
RoundVal({{ Value }},{{ Decimals }})={{ SQLValues.Daten[0].RoundVal | FormatNumber: 'N2','de-DE' }}
>> RoundVal(5.39070024967194,2)=5,39

Die Abfrage dieser Werte gestaltet sich ein bißchen anders, weil hier ein Vektor von Werten zurückgegeben wird. Deshalb greift man hier z.B. mit SQLValues.Daten[0].CeilVal auf den Ceiling Wert zu. Ist ja aber auch einfach, oder?

Gruß,
Ingmar

 

[SebiW]

Wo Gutberle,

vielen Dank für diesen riesen Block Information. Zu meinem Erschrecken scheine ich sogar teilweise zu begreifen wie ich das umsetze

Im Ernst, Wahnsinn, danke. Sieht so aus als würde ich meine Autokalkulation doch noch umsetzen können.

Vielen, vielen Dank!

 

[Rico Giesler]

Wir haben und das Thema https://forum.jtl-software.de/threa...gibt-seltsamen-string-aus.102280/#post-567110 nochmal angeschaut und festgestellt, dass "Times" dort komplett groß geschrieben war. Also "TIMES".
Korrekt muss es aber "Times" lauten. Dann geht es auch.