In Diskussion Abfrage auf Wert bei allen Artikelpositionen nicht möglich?

[ongnamo]

Hallo,

Ziel des WF ist, das Eigene Feld "Warenpost Nation fähig" abzufragen. Nur wenn alle Artikel der Bestellung Warenpost National fähig sind, soll die Versandart neu gesetzt werden.

Bedingung ist: Auftrag\Auftragspositionen\ArtikelPositionen.enthält\Artikel\ Eigene Felder\Versand\Warenpost_National_fähig Gleich Wahr

Nun habe ich durch Testen bemerkt, dass das Ergebnis bereits dann WAHR ist, wenn nur ein Artikel der Positionsliste Wahr ist.

Keine Ahnung, ob das ein Bug oder Feature ist. Mein Verdacht ist, das hier das Wörtchen "enthält" ausschlaggebend ist.

Die Frage ist, wie erreicht man es, dass die Bedingung insgesamt nur dann WAHR ist, wenn sie für alle Positionen WAHR ist?

 

[frankell]

Hallo,

Ziel des WF ist, das Eigene Feld "Warenpost Nation fähig" abzufragen. Nur wenn alle Artikel der Bestellung Warenpost National fähig sind, soll die Versandart neu gesetzt werden.

Bedingung ist: Auftrag\Auftragspositionen\ArtikelPositionen.enthält\Artikel\ Eigene Felder\Versand\Warenpost_National_fähig Gleich Wahr

Nun habe ich durch Testen bemerkt, dass das Ergebnis bereits dann WAHR ist, wenn nur ein Artikel der Positionsliste Wahr ist.

Keine Ahnung, ob das ein Bug oder Feature ist. Mein Verdacht ist, das hier das Wörtchen "enthält" ausschlaggebend ist.

Die Frage ist, wie erreicht man es, dass die Bedingung insgesamt nur dann WAHR ist, wenn sie für alle Positionen WAHR ist?

Hast Du es mal mit der umgekehrten Logik probiert, also "Keine Bedingung erfüllt" und enthält ... gleich FALSCH?
Die doppelte Verneinung ist eine starke Bejahung, also genau das, was Du brauchst.
Da uns aber die Negierungen schwerer fallen als die positiven Ausdrücke, kann man das auch mit einer selbstdefinierten Erweiteren Eigenschaft erledigen. Es ist nur einfacher mit der doppelten Verneinung. Es sei denn, ich bin jetzt einem Logikfehler aufgesessen. 😂

 

[ongnamo]

Das Problem ist, dass ich nicht nur eine Bedingung habe. Wenn es nur eine Bedingung gäbe, könnte man tatsächlich so arbeiten.

 

[frankell]

Das Problem ist, dass ich nicht nur eine Bedingung habe. Wenn es nur eine Bedingung gäbe, könnte man tatsächlich so arbeiten.

Dann bleibt tatsächlich nur die Nutzung über die Erweiterten Eigenschaften. Weißt Du, wie man damit umgeht?

 

[ongnamo]

Erweiterte Bedingungen kenne ich. Wir haben einige im Einsatz. Doch das Ausformulieren dieser Dotliquid-Abfragen ist nicht so mein Ding. Habe heute nach einer halben Stunde aufgegeben. Da fehlt mir einfach immer wieder das Detailwissen. ChatGPT war auch nicht hilfreich ^^

 

[frankell]

Erweiterte Bedingungen kenne ich. Wir haben einige im Einsatz. Doch das Ausformulieren dieser Dotliquid-Abfragen ist nicht so mein Ding. Habe heute nach einer halben Stunde aufgegeben. Da fehlt mir einfach immer wieder das Detailwissen. ChatGPT war auch nicht hilfreich ^^

Das ist auch nicht ganz so profan, weil das, soweit ich es erkennen kann, nicht ohne den Einsatz von SQL geht. Unter der Annahme, dass das Eigene Feld die Bezeichnung Warenpost_National_fähig hat, könntest Du folgende Erweiterte Eigenschaft anlegen:

{% for Artikelbeschreibungen in Vorgang.AuftragsPositionen -%}
{% assign PTyp = Artikelbeschreibungen.Positionstyp | abs -%}
{% if PTyp == 1 -%}
{% capture SQL -%}
SELECT nWertInt FROM tArtikelAttributSprache AS ARTATTS
LEFT JOIN tArtikelAttribut AS ARTATT ON ARTATTS.kArtikelAttribut = ARTATT.kArtikelAttribut
LEFT JOIN tAttributSprache AS ATTS ON ARTATT.kAttribut = ATTS.kAttribut
WHERE ATTS.cName = 'Warenpost_National_fähig' AND ATTS.kSprache = 0 AND ARTATTS.kSprache = 0 AND ARTATT.kArtikel = {{ Artikelbeschreibungen.InterneArtikelnummer | SqlEsacape }}
{% endcapture -%}
{% assign EF = SQL | DirectQueryScalar -%}
{% if EF == 1 -%}y{% else %}n{% endif -%}
{% endif -%}
{% endfor -%}

Diese müsste dann als Bedingung "enhält nicht" und "n" definiert werden.

Der Code geht alle Auftragspositionen durch und filtert zunächst einmal nach Standardpositionen (Artikel), also so etwas wie Gebühren, Versandkosten, Finanzierungskosten etc. werden nicht beachtet. Dann wird geprüft, ob der Wert für das Eigene Feld 1 ist (= WAHR bei Checkbox als Datentyp) . Wann immer das der Fall ist, wird ein y geschrieben. Ist das nicht der Fall, wird ein n geschrieben. Enthält also das Ergebnis n, ist das Eigene Feld bei mindestens einer Position nicht WAHR.

Das sollte dem Gewünschten entsprechen.

Hinweise:

• Man könnte sich den zweiten JOIN sparen, wenn man den Wert kAttribut für das Eigene Feld kennt.
• Die Verwendung von Unterstrichen in Bezeichnungen ist in SQL kann unglücklich sein, da der Unterstrich eine bestimmte Bedeutung bei der Suche nach einem String hat, wenn man keine exakte Suche verwendet. Er ist dann eine Wildcard für exakt ein beliebiges Zeichen. Wenn es also neben "Warenpost_National_fähig" auch "Warenpost National fähig" oder auch "Warenpost-National-fähig", würden alle diese Werte bei einer Sucher über LIKE gefunden. Wenn man eine exakte Suche benutzt wie oben bei WHERE ATTS.cName = 'Warenpost_National_fähig', wird der Unterstrich auch als Unterstrich verstanden, daher kommt es hier nicht drauf an. Daher ist das hier nur als Hinweis zu verstehen, dass der Unterstrich auch mal Probleme bereiten kann.
• Theoretisch bedarf es der Erweiterten Eigenschaft nicht, Du könntest auch einfach die Prüfung auf das Eigene Feld in einen weiteren Workflow auslagern, bspw. als ersten Workflow, der nur diese Bedingung prüft (ohne die Notwendigkeit einer Erweiterten Eigenschaft) und als Aktion den Aufruf des jetzigen Workflows hat. Ich persönlich bin aber kein großer Fan davon, mehr Workflows als notwendig anzulegen. Und das generell, nicht nur, weil die manuellen Workflows unterhalb von Pro begrenzt oder gar nicht vorhanden sind. Und es ist auch einfach übersichtlicher. Aber nur der Vollständigkeit halber: Es ist auch eine Möglichkeit.

 

[ongnamo]

Was für eine geniale, kollegiale Antwort! Vielen Dank schon allein für diesen Einsatz!

Den Code kann ich gedanklich nachvollziehen. Validieren kann ich ihn nur durch testen, weil mir ja wie gesagt der Tiefgang dafür fehlt. Ich habe dafür meinen Auftrag 4156692 genommen, der 1 nicht WP-fähige und 2 WP-fähige Artikelpositionen enthält. Ergebnis:
nnn
Doch auch wenn alle 3 oder keine der Artikelpositionen WP-fähig ist, es kommt immer "nnn" heraus. Irgendetwas passt da noch nicht. Hast du ein Idee, woran das liegt?

 

[frankell]

Was für eine geniale, kollegiale Antwort! Vielen Dank schon allein für diesen Einsatz!

Den Code kann ich gedanklich nachvollziehen. Validieren kann ich ihn nur durch testen, weil mir ja wie gesagt der Tiefgang dafür fehlt. Ich habe dafür meinen Auftrag 4156692 genommen, der 1 nicht WP-fähige und 2 WP-fähige Artikelpositionen enthält. Ergebnis:
nnn
Doch auch wenn alle 3 oder keine der Artikelpositionen WP-fähig ist, es kommt immer "nnn" heraus. Irgendetwas passt da noch nicht. Hast du ein Idee, woran das liegt?

Gern geschehen!

Ich habe das bei uns mit einem Eigenen Feld getestet, da ging es.

Kannst Du einmal einen Screenshot der Einstellungen des Eigenen Feldes machen, also in Admin - Eigene Felder?

 

[ongnamo]

Na klar: Screenshot anbei.

Es ist ein Flag-Feld und in allen Warengruppen gültig.

 

[frankell]

Na klar: Screenshot anbei.

Es ist ein Flag-Feld und in allen Warengruppen gültig.

Ok, dann kann das auch nicht klappen. Ich schrieb ja:

Unter der Annahme, dass das Eigene Feld die Bezeichnung Warenpost_National_fähig hat, könntest Du folgende Erweiterte Eigenschaft anlegen:

Wenn Du im Code

'Warenpost_National_fähig'

durch

'Warenpost National fähig'

ersetzt, sollte es klappen. Ich war davon ausgegangen, dass die Unterstriche Teil der Bezeichnung sind, aber die sind bei den Feldern automatisch hinzugefügt worden.

 

[frankell]

Das ist auch nicht ganz so profan, weil das, soweit ich es erkennen kann, nicht ohne den Einsatz von SQL geht. Unter der Annahme, dass das Eigene Feld die Bezeichnung Warenpost_National_fähig hat, könntest Du folgende Erweiterte Eigenschaft anlegen:

{% for Artikelbeschreibungen in Vorgang.AuftragsPositionen -%}
{% assign PTyp = Artikelbeschreibungen.Positionstyp | abs -%}
{% if PTyp == 1 -%}
{% capture SQL -%}
SELECT nWertInt FROM tArtikelAttributSprache AS ARTATTS
LEFT JOIN tArtikelAttribut AS ARTATT ON ARTATTS.kArtikelAttribut = ARTATT.kArtikelAttribut
LEFT JOIN tAttributSprache AS ATTS ON ARTATT.kAttribut = ATTS.kAttribut
WHERE ATTS.cName = 'Warenpost_National_fähig' AND ATTS.kSprache = 0 AND ARTATTS.kSprache = 0 AND ARTATT.kArtikel = {{ Artikelbeschreibungen.InterneArtikelnummer | SqlEsacape }}
{% endcapture -%}
{% assign EF = SQL | DirectQueryScalar -%}
{% if EF == 1 -%}y{% else %}n{% endif -%}
{% endif -%}
{% endfor -%}

Diese müsste dann als Bedingung "enhält nicht" und "n" definiert werden.

Der Code geht alle Auftragspositionen durch und filtert zunächst einmal nach Standardpositionen (Artikel), also so etwas wie Gebühren, Versandkosten, Finanzierungskosten etc. werden nicht beachtet. Dann wird geprüft, ob der Wert für das Eigene Feld 1 ist (= WAHR bei Checkbox als Datentyp) . Wann immer das der Fall ist, wird ein y geschrieben. Ist das nicht der Fall, wird ein n geschrieben. Enthält also das Ergebnis n, ist das Eigene Feld bei mindestens einer Position nicht WAHR.

Das sollte dem Gewünschten entsprechen.

Hinweise:

• Man könnte sich den zweiten JOIN sparen, wenn man den Wert kAttribut für das Eigene Feld kennt.
• Die Verwendung von Unterstrichen in Bezeichnungen ist in SQL kann unglücklich sein, da der Unterstrich eine bestimmte Bedeutung bei der Suche nach einem String hat, wenn man keine exakte Suche verwendet. Er ist dann eine Wildcard für exakt ein beliebiges Zeichen. Wenn es also neben "Warenpost_National_fähig" auch "Warenpost National fähig" oder auch "Warenpost-National-fähig", würden alle diese Werte bei einer Sucher über LIKE gefunden. Wenn man eine exakte Suche benutzt wie oben bei WHERE ATTS.cName = 'Warenpost_National_fähig', wird der Unterstrich auch als Unterstrich verstanden, daher kommt es hier nicht drauf an. Daher ist das hier nur als Hinweis zu verstehen, dass der Unterstrich auch mal Probleme bereiten kann.
• Theoretisch bedarf es der Erweiterten Eigenschaft nicht, Du könntest auch einfach die Prüfung auf das Eigene Feld in einen weiteren Workflow auslagern, bspw. als ersten Workflow, der nur diese Bedingung prüft (ohne die Notwendigkeit einer Erweiterten Eigenschaft) und als Aktion den Aufruf des jetzigen Workflows hat. Ich persönlich bin aber kein großer Fan davon, mehr Workflows als notwendig anzulegen. Und das generell, nicht nur, weil die manuellen Workflows unterhalb von Pro begrenzt oder gar nicht vorhanden sind. Und es ist auch einfach übersichtlicher. Aber nur der Vollständigkeit halber: Es ist auch eine Möglichkeit.

Und ein Tippfehler ist da noch im Code von mir: Da steht leider SqlEsacape anstelle von SqlEscape. Warum der Code dann bei mir trotzdem funktioniert hat, weiß ich nicht.

 

[ongnamo]

Ah, cool: Bei 2 WPN-fähigen und 1 nicht-WPN-fähigem Artikel erhalte ich nun das gewünschte Ergebnis: yyn

Und im Workflow:


Mit deiner Hilfe hat das geklappt 1000 Dank dafür 🙏

 

[frankell]

Ah, cool: Bei 2 WPN-fähigen und 1 nicht-WPN-fähigem Artikel erhalte ich nun das gewünschte Ergebnis: yyn

Und im Workflow:

Den Anhang 113701 betrachten
Mit deiner Hilfe hat das geklappt 1000 Dank dafür 🙏

Sehr gerne, so soll das!