Hallo
@KrisZap,
danke für Deine Tests und die verwirrenden Ergebnisse, denn rein von der Logik her waren meine Bedingungsabfragen schon alle OK, bis auf den Bug mit dem Vergleich auf "Ende>Heute" statt "Ende>=Heute", aber das hatten wir ja schon.
Ich habe auf Basis Deiner Tests jetzt einmal genauer geschaut, was die
Wawi in der Datenbank macht, wenn Kombinationen von Optionen an- und ausgeschaltet werden und dabei ist mir klar geworden, was hier passiert und wo die Fehler herkommen.
Die Wawi setzt manche Optionen nämlich nicht von 1=an auf 0=aus zurück, sondern setzt den Wert statt auf 0 auf NULL. Damit fliegt einem aber jeder Bedingungsvergleich um die Ohren, der das nicht explizit abfängt, weil immer dann, wenn einer der Werte in einer Query-Bedingung unabgefangen NULL hat, die Query schlicht NICHTS zurückliefert. - Und in diesem Fall, also wenn NICHTS zurückgeliefert wird, greift bei mir der Alternativwert 2=abgelaufen, wie Du bei Deinen Tests ja gefunden hast.
Es ist mir jetzt auch gelungen ist, Situationen zu erzeugen, bei denen meine Datumsvergleiche mit der Wandlung nach
varchar(10) tatsächlich NICHT funktionieren. Ich habe keine Ahnung warum, denn der Datums-Vergleich über
"CONVERT(varchar..." ist absoluter Standard im MS SQL Server Bereich. Das schaue ich mir aber später an, für hier ist das egal, denn der Vergleich über die Wandlung mit
"CONVERT(date..." funktioniert auch bei mir immer, also habe ich das entsprechend geändert.
Ich habe all diese Änderungen jetzt umgesetzt und alles ausgiebig in der Wawi und auch direkt im SQL Editor getestet und alle Deine Tests laufen jetzt OK durch. Die
Workflow Query sieht jetzt wie folgt aus ...
Code:
{% capture query -%}
SELECT CASE t3.nAktiv WHEN 0 THEN 0
ELSE ISNULL((SELECT nAktiv FROM tArtikelSonderpreis AS t1
JOIN dbo.vLagerbestandEx AS t2 ON t2.kArtikel=t1.kArtikel
WHERE t1.nAktiv=1
AND ((ISNULL(t1.nIstDatum,0)=0) OR ((t1.nIstDatum=1) AND (CONVERT(DATE, ISNULL(t1.dEnde,'31.12.1899'), 104) >= CONVERT(DATE, GETDATE(), 104))))
AND ((t1.nIstAnzahl=0) OR ((t1.nIstAnzahl=1) AND (t2.fVerfuegbar>=t1.nAnzahl)))
AND t1.kArtikel={{ Vorgang.Allgemein.Stammdaten.InterneArtikelnummer }}),2)
END SonderPreisStatus
FROM tArtikelSonderpreis AS t3 WHERE kArtikel={{ Vorgang.Allgemein.Stammdaten.InterneArtikelnummer }}
UNION
SELECT 0 as SonderPreisStatus WHERE NOT EXISTS (SELECT nAktiv FROM tArtikelSonderpreis WHERE kArtikel={{ Vorgang.Allgemein.Stammdaten.InterneArtikelnummer }})
{% endcapture -%}
{% assign SonderpreisStatus = query | DirectQueryScalar -%}
{{ SonderpreisStatus }}
Achtung: Dem aufmerksamen Leser ist eventuell aufgefallen, dass in der Query im Vergleich zu vorher eine ganze Zeile in den Bedingungs-Tests fehlt, nämlich
"AND (CONVERT(DATE, t1.dStart, 104) <= CONVERT(DATE, GETDATE(), 104))". Der Grund dafür ist, dass die Wawi (meines Erachtens) einen Bug bei der Auswertung der Bedingung hat, dass nur das Startdatum gesetzt ist, aber in die Zukunft zeigt.
Damit ist der Sonderpreis aktuell, soll heißen jetzt/hier/heute eigentlich NICHT aktiv, denn er ist ja noch nicht angelaufen. Er wird aber demnächst aktiv und nach der weiter oben beschriebenen Logik aus dem
JTL Guide müsste der Sonderpreis-Status damit eigentlich "abgelaufen" sein, um dann später wieder nach "aktiv" zu wechseln.
Da ich hier aber nicht den Besserwisser spielen will und der Workflow genau DAS zurückliefern soll, was die Wawi zum Sonderpreis-Status sagt, habe ich die Zeile mit dem Test auf einen "noch nicht" aktiven Sonderpreis für's Erste rausgenommen und liefere genau wie die Wawi für diesen Fall 1=aktiv zurück.
Ich werde die Frage, ob das ein Bug ist, aber an JTL weiterleiten und falls es tatsächlich ein Bug ist und der korrigiert wird, dann muss die Zeile einfach nur wieder in die Gruppe der AND Bedingungen eingefügt werden.
So, ich hoffe, wir haben es jetzt und nochmals vielen Dank für Deine Hilfe!
Gruß,
Ingmar
