Gelöst [WAWI-18606] BUG: Vergleiche "größer als" und "kleiner als" fehlerhaft...

[gutberle]

Ich habe einen Workflow geschrieben, der in zwei Bedingungen prüft, ob ein Wert entweder größer als 0,05 ist, oder aber ob er kleiner als -0,05 ist, siehe Screenshot.



Simuliere ich den Workflow jetzt aber mit einem Datensatz, bei dem der Kriteriumswert -5,00 ist, dann meldet mir der Workflow, dass die erste Bedingung eingetroffen ist, weil -5,00 ja größer als 0,05 sei.



Naja, das ist so sicher nicht ganz richtig, aber wenn ich einen anderen Testdatensatz nehme, bei dem der Kriteriumswert 0,00 ist, dann schlägt konsequenterweise auch die andere Vergleichsrichtung voll danbeben und erklärt, Workflow Bedingung 2 sei eingetreten, weil 0,00 ja kleiner als -0,05 sei.



Ähem, das ist leider auch nicht so "richtig" richtig. Und führe ich den Workflows mit den selben Datensätzen auch aus und simuliere ihn nicht nicht, dann wird der Workflow auch genauso falsch ausgeführt wie simuliert, egal ich ihn aus dem Simulationsmodus heraus oder aus der Wawi ausführe.

Vielleicht könntet Ihr mal schauen, was da los ist ...

 

[gutberle]

Nachtrag: Das Problem betrifft nicht nur "kleiner als" und "größer als", sondern genauso auch "kleiner gleich" und "größer gleich".
Alle anderen Vergleiche scheinen zu funktionieren, inklusive "ungleich", der ganz ähnlich ist, aber der sieht mir wie ein String-Vergleich aus...

 

[Björn Ponsen]

Guten Morgen gutberle,

poste bitte mal deine Erweiterte Eigenschaft die du hier für DotLiquid angelegt hast.

 

[gutberle]

Guten Morgen Björn,

hier die Erweiterte Eigenschaft. Es geht darum, das Gesamtkundensaldo bestehend aus offenen Rechnungsbeträgen plus zugehörigen Gebühren und Zinsen aus der DB zu holen...

{% capture query %}\
    SELECT SUM(ROUND(fWert,2)-ROUND(fZahlung,2)-ROUND(fGutschrift,2)+Round(vBestellungEckdaten.fGutschein,2)) FROM vBestellungEckdaten \
        JOIN tBestellung ON vBestellungEckdaten.kBestellung=tBestellung.kBestellung \
        WHERE tBestellung.cType='B' AND tBestellung.tRechnung_kRechnung>0 AND tBestellung.tKunde_kKunde={{ Vorgang.InterneKundennummer }}\
{% endcapture -%}
{% assign OffenerWert = query | DirectQueryScalar | Plus: 0 %}

{% capture query %}\
    SELECT SUM(ROUND(ISNULL(tZahlungsErinnerung.fGebuehr, 0.0),2)) FROM tBestellung
    LEFT JOIN trechnung ON trechnung.tBestellung_kBestellung=tBestellung.kBestellung
    LEFT JOIN tZahlungsErinnerung ON tZahlungsErinnerung.kRechnung=trechnung.kRechnung
        AND NOT EXISTS
            (SELECT * FROM dbo.tZahlungsErinnerung tmp WHERE tmp.kRechnung = tRechnung.kRechnung
                AND tmp.nMahnstufeAktuell > dbo.tZahlungsErinnerung.nMahnstufeAktuell)
    WHERE tBestellung.cType='B' AND tBestellung.tRechnung_kRechnung>0 AND tBestellung.tKunde_kKunde={{ Vorgang.InterneKundennummer }}\
{% endcapture -%}
{% assign OffenerZins = query | DirectQueryScalar | Plus: 0 %}

{% assign OffenerBetrag = OffenerWert | Plus: OffenerZins %}
{{ OffenerBetrag | FormatNumber: 'N2', 'de-DE' }}

... der Fehler zeigt sich aber auch, wenn Du einfach Zahlenwerte im Fenster der Erweiterten Eigenschaft anlegst und zurückgibst.

Gruß,
Ingmar

 

[Björn Ponsen]

Guten Morgen Ingmar,

du kannst in DotLiquid mit allen Werten arbeiten, der Ausgabe Wert ist jedoch immer ein String.

 

[gutberle]

Hallo Björn,

falls Du damit sagen willst, dass man Werte, die man sich über "Erweiterte Eigenschaften" ziehen muß, weil sie in der Wawi fehlen, schlicht nicht bezüglich ihres numerischen Inhalts interpretieren kann, dann gehe ich mal vorsichtshalber davon aus, dass auch Du das für eine höchst unzufriedenstellende Antwort hältst, oder?

Hast Du vielleicht einen Vorschlag für mich, wie man in einer solchen Situation zum Ziel kommen kann? Die Wawi DB speichert ja nicht nur Strings sondern vor allem Zahlenwerte und "Business" definiert sich auch nicht über die Betrachtung und den Vergleich von Texten, sondern über den Vergleich von Zahlen. Es ist also wohl nicht allzu weit hergeholt, dass ich einen Wert (sic!) aus der Datenbank holen will und dann schauen möchte, ob er größer oder kleiner als ein Zielkritierium ist, oder? ...

Gruß,
Ingmar

 

[Xantiva]

Temporärer Kompromiss: Erledige den Vergleich in der Erweiterten Eigenschaft:
kleiner -0,05 machst Du zu 1
größer 0,05 machst Du zu 3
den Rest zu 2

Dann sollte ein Textvergleich erst mal wieder funktionieren. Allerdings ist das in der Tat eine eher unbefriedigende Lösung.

 

[Björn Ponsen]

Guten Morgen Ingmar,

da hast du recht aber aktuell keine ich dir keine andere Antwort dazu geben. Ich werde die Problematik aber Intern einmal ansprechen das wir hier eine adäquate Lösung finden.

 

[gutberle]

Hallo Björn,

danke für Deine Rückmeldung und danke auch, dass Du das Problem intern ansprechen willst. Ich (und mit mir andere...) weiß das zu schätzen!

In diesem speziellen Fall kann man sich tatsächlich mit einem Konstrukt wie dem von @Xantiva vorgeschlagenen behelfen, aber was wäre zum Beispiel wenn ich ein Datum aus der Datenbank holen muss. Mit Datumsangaben ist schon mit den bisher implementierten Funktionen/Bedingungen in Dotliquid schwer zu arbeiten, mit einem String-Datum, ähem, da fehlt mir im Moment die Phantasie. Das wären prototypisch die Fälle, wo man mit String-Rückgaben wirklich an die Wand läuft.

Gruß,
Ingmar

 

[gutberle]

@Xantiva - Danke für den super Hinweis. Klar, so kann man das hier lösen. Ich habe es jetzt ein bißchen näher an der eigentlichen Intention benannt, aber es ist das Gleiche.

Falls irgendjemand anderes auch Kundenkonto Ausdrucke machen möchte, hier ist der ganze Workflow Code und hier ist der Thread, in dem wir eine Vorlage erarbeitet haben, die einen Kundenkonto-Ausdruck realisiert. Der Weg hier wäre dann alle auszuwertenden Kunden im Bereich "Kunden" zu markieren und den manuellen Workflow "Kontoauszug drucken..." auszulösen. Das geht bei mir ziemlich schnell, ich habe aber auch nur ~350 Kunden, also Vorsicht beim Probieren mit 23.000 Kunden!!!

{% capture query -%}\
    SELECT SUM(ROUND(fWert,2)-ROUND(fZahlung,2)-ROUND(fGutschrift,2)+Round(tBestellungEckdaten.fGutschein,2)) FROM tBestellungEckdaten \
        JOIN tBestellung ON tBestellungEckdaten.kBestellung=tBestellung.kBestellung \
        WHERE tBestellung.cType='B' AND tBestellung.tRechnung_kRechnung>0 AND tBestellung.tKunde_kKunde={{ Vorgang.InterneKundennummer }}\
{% endcapture -%}
{% assign OffenerWert = query | DirectQueryScalar | Plus: 0 -%}
{% capture query -%}\
    SELECT SUM(ROUND(ISNULL(tZahlungsErinnerung.fGebuehr, 0.0),2)) FROM tBestellung
    LEFT JOIN trechnung ON trechnung.tBestellung_kBestellung=tBestellung.kBestellung
    LEFT JOIN tZahlungsErinnerung ON tZahlungsErinnerung.kRechnung=trechnung.kRechnung
        AND NOT EXISTS
            (SELECT * FROM dbo.tZahlungsErinnerung tmp WHERE tmp.kRechnung = tRechnung.kRechnung
                AND tmp.nMahnstufeAktuell > dbo.tZahlungsErinnerung.nMahnstufeAktuell)
    WHERE tBestellung.cType='B' AND tBestellung.tRechnung_kRechnung>0 AND tBestellung.tKunde_kKunde={{ Vorgang.InterneKundennummer }}\
{% endcapture -%}
{% assign OffenerZins = query | DirectQueryScalar | Plus: 0 -%}
{% assign Kontostand = OffenerWert | Plus: OffenerZins -%}
{% if Kontostand > 0.05 -%}
    {{ 'Soll' | Trim }}
{% elseif Kontostand < -0.05 -%}
    {{ 'Haben' | Trim }}
{% else -%}
    {{ 'Null' | Trim }}
{% endif -%}

Hier wird also "Soll" für Soll, "Haben" für Haben und "Null" für Null zurückgegeben und die Vergleiche im Workflow selbst sind dann einfache String Vergleiche ...



Gruß,
Ingmar

 

[Björn Ponsen]

https://issues.jtl-software.de/issues/WAWI-18606