Ok, auch wenn
@argy vielleicht noch etwas Positives rausbekommt, scheint es mir doch, als gäbe es allerlei Hemmnisse und Beschränkungen, wenn man versucht, hier mit Workflows weiterzukommen.
Wenn ich mal zusammenfasse, dann kann man ...
1. Keinen
Workflow erstellen, der regelmäßig, also z.B. meine 9 Uhr täglich von oben prüft, ob eine Bedingung erfüllt ist.
2. Kann man mit Workflow Mitteln auch nicht über alle Artikel hinweg prüfen, weil dem Workflow im Artikel-Bereich nur das eine auslösende Artikel-Objekt übergeben wird.
3. Kann man mit Workflow Mitteln zwar TOP und NEU abfragen aber erst in der "mittleren" Zukunft diese Werte auch setzen.
4. Kennt der Workflow offenbar nicht einmal die tatsächlich relevante Datums-Variable
tArtikel.dNeuImSortiment, womit sich das Ganze auch insgesamt erledigt...
Deshalb poste ich hier jetzt wie oben schon angedroht, doch meinen SQL Code, der auf Basis eines "Eigenen Feldes" mit Einem Ablaufdatum oder alternativ auf Basis eines "Eigenen Feldes" mit einer Ablaufzeit in Tagen ratz-fatz über alle Artikel hinweg diejenigen Artikel findet und mit allen relevanten Daten zurückmeldet, deren "Neu im Sortiment" Zeit abgelaufen ist.
Und natürlich lässt sich das Ganze mit einer Mini-Erweiterung so ändern, dass die Prüfung nur für den übergebenen Artikel geschieht.
Einschränkungen
1. Der SQL Code wird als "Erweiterte Eigenschaft" in einen Workflow eingebaut, läuft also nicht, wie
@dropshipout oben vorschlägt, direkt auf dem SQL Server und über die interne SQL Server Queue. Deshalb gelten auch hier die Einschränkungen, dass es ein auslösendes Ereignis braucht, oder man den Workflow als "Manuell" anlegen und ihn regelmäßig von Hand aufrufen muss.
2. Die zweite Einschränkung ist, dass der Workflow die abgelaufenen Artikel nur meldet, den Zustand "Neu im Sortiment" in der Datenbank aber NICHT ausschaltet, denn auch wenn das nur eine zusätzliche Zeile wäre, ist das Schreiben in die Datenbank für normale Anwender (wie mich) ein absolutes NoNo!!!!
Damit leisten diese SQL Codes zwar nicht das, was
@Micmac wollte, aber sie können sehr hilfreich sein, um sich z.B. per Email zusenden zu lassen, welche Artikel man noch schnell vor Feierabend vom Status "Neu" befreien muß. - Here we go ...
Variante mit Ablaufdatum in einem "Eigenen Feld" mit Namen "Neu im Sortiment Enddatum" und mit Typ Datum:
Code:
{% capture query -%}
SELECT t1.cArtNr, CAST(t1.dNeuImSortiment AS DATE) NeuImSortimentAm, CAST(t3.dWertDateTime AS DATE) NeuImSortimentBis,
CASE WHEN CAST(GETDATE() AS DATE)>CAST(t3.dWertDateTime AS DATE) THEN 'Y' ELSE 'N' END NeuImSortimentAus FROM tArtikel as t1
INNER JOIN tArtikelAttribut AS t2 ON t1.kArtikel=t2.kArtikel
INNER JOIN tArtikelAttributSprache AS t3 ON t2.kArtikelAttribut=t3.kArtikelAttribut
INNER JOIN tAttributSprache AS t4 ON t2.kAttribut=t4.kAttribut
WHERE t1.cNeu='Y' AND t4.cName='Neu im Sortiment Enddatum' AND CAST(GETDATE() AS DATE) > CAST(t3.dWertDateTime AS DATE)
{% endcapture -%}
{% assign NeuImSortimentData = query | DirectQuery -%}
{% for item in NeuImSortimentData.Daten -%}
ArtNr: {{ item.cArtNr }}; Neu-Ab: {{ item.NeuImSortimentAm | Date: 'dd.MM.yyyy' }}; Neu-Bis: {{ item.NeuImSortimentBis | Date: 'dd.MM.yyyy' }}; Neu-Aus: {{ item.NeuImSortimentAus }}
{% endfor -%}
Variante mit Zeitdauer in Tagen in einem "Eigenen Feld" mit Namen "Neu im Sortiment Dauer" und mit Typ Ganzzahl:
Code:
{% capture query -%}
SELECT t1.cArtNr, CAST(t1.dNeuImSortiment AS DATE) NeuImSortimentAm, t3.nWertInt NeuImSortimentDauer, DATEDIFF(day,CAST(t1.dNeuImSortiment AS DATE),CAST(GETDATE() AS DATE)) NeuImSortimentTage,
CASE WHEN DATEDIFF(day,CAST(t1.dNeuImSortiment AS DATE),CAST(GETDATE() AS DATE)) > t3.nWertInt THEN 'Y' ELSE 'N' END NeuImSortimentAus FROM tArtikel as t1
INNER JOIN tArtikelAttribut AS t2 ON t1.kArtikel=t2.kArtikel
INNER JOIN tArtikelAttributSprache AS t3 ON t2.kArtikelAttribut=t3.kArtikelAttribut
INNER JOIN tAttributSprache AS t4 ON t2.kAttribut=t4.kAttribut
WHERE t1.cNeu='Y' AND t4.cName='Neu im Sortiment Dauer' AND DATEDIFF(day,CAST(t1.dNeuImSortiment AS DATE),CAST(GETDATE() AS DATE)) > t3.nWertInt
{% endcapture -%}
{% assign NeuImSortimentData = query | DirectQuery -%}
{% for item in NeuImSortimentData.Daten -%}
ArtNr: {{ item.cArtNr }}; Neu-Ab: {{ item.NeuImSortimentAm | Date: 'dd.MM.yyyy' }}; Neu-Dauer: {{ item.NeuImSortimentDauer }}; Neu-Tage: {{ item.NeuImSortimentTage }}; Neu-Aus: {{ item.NeuImSortimentAus }}
{% endfor -%}
... und falls man einen der beiden Codes auf den aktuell übergebenen Artikel beschränken will, fügt man vor der Zeile mit
{% endcapture -%} einfach noch ...
Code:
AND t1.kArtikel={{ Vorgang.Allgemein.Stammdaten.InterneArtikelnummer }}
... ein. Damit kann man dann z.B. im Bereich
Artikel > Geändert nach jeder Änderung eines einzelnen Artikels automatisch nachschauen lassen, ob der Artikel vielleicht auch noch auf Neu gesetzt, aber schon Alt ist.
>> Erläuterungen dazu, wie man das Ganze in einen Workflow einbaut oder für die Aktion in eine Email einbettet spare ich mir hier, das kann z.B.
hier nachgelesen werden.
Gruß,
Ingmar
