Neu Wer kann helfen - Workflow - Betreff

  • Wenn Ihr uns das erste Mal besucht, lest euch bitte zuerst die Foren-Regeln durch.

swopper-shop

Gut bekanntes Mitglied
10. Mai 2010
185
1
#1
Hallo, wir erstellen gerade einen Workflow, der bei einer Plusbuchung von einer Retoure ausgelöst werden soll. Das funktioniert auch alles und ist ja sehr einfach.
Nur damit der Mitarbeiter etwas mit der Email anfangen kann, benötigen wir im Betreff der Mail oder im Text die Retourennummer oder das interne Kommentarfled was bei der WMS zur Verfügung stellt.
Leider steht die Variable nicht zur Verfügung.

Der JTL Support hat uns geantwortet nur funktioniert das leider nicht und ich bin leider absoluter Leihe.
JTL hat uns folgendes geschrieben:
Ich kann ihnen folgendes Beispiel an die Hand geben.

{% capture query -%}
SELECT tRMRetoure.cKommentarExtern AS kommentar
FROM tRMRetoure
JOIN tBestellung ON tBestellung.kBestellung = tRMRetoure.kBestellung
WHERE tBestellung.cBestellNr = '{{ Vorgang.Stammdaten.Auftragsnummer | SqlEscape }}'
{% endcapture -%}
{% assign result = query | DirectQuery -%}
{% for row in result.Daten -%}
{{ row.kommentar }}
{% endfor -%}

Den Text habe ich jetzt siehe Bild eingegeben aber ohne Erfolg muss ich noch etwas anpassen?

1549888971184.png
 
6. November 2018
96
14
Hannover
#2
Mit den erweiterten Eigenschaften, kannst du erst einmal Felder festlegen, auf die du dann in den Workflows zugreifen kannst. Du kannst an dieser Stelle dir die Vorschau hiervon augeben lassen und gucken ob das stimmt.
 

gutberle

Sehr aktives Mitglied
29. März 2011
1.242
305
#7
Hallo @swopper-shop,

falls ich mich nicht sehr irre, kann der Code nicht funktionieren, da ein Warenlagereingang - auch aus einer Retoure heraus - keinen Bezugsauftrag hat, der als Variable mit an den Workflow übergeben wird. Was aber übergeben wird, ist die ursprüngliche Lieferscheinnummer und da die Wawi die Lieferschein-Nummern ja von der Auftragsnummer ableitet, kann man die benutzen, siehe unten.

Und dann versucht der Code auch noch statt einem Eintrag gleich eine ganze Liste von Einträgen zurückzugeben, was für mich nun gar keinen Sinn macht (oder ich raff nicht, wann/warum das Sinn machen könnte. Dass das dann auch noch die externen Kommentare sind und nicht die internen Kommentare oder die Retourennummern, die Du haben willst, macht den Kohl dann auch nicht mehr fett ... ;)

Versuch's mal mit folgendem Code ...
SQL:
{% capture query -%}
SELECT tRMRetoure.cRetoureNr AS RetoureNr FROM tRMRetoure
JOIN tBestellung ON tBestellung.kBestellung = tRMRetoure.kBestellung
WHERE tBestellung.cBestellNr=SUBSTRING('{{ Vorgang.Lieferscheinnummer }}',1,LEN('{{ Vorgang.Lieferscheinnummer }}')-4)
{% endcapture -%}
{% assign EmailBetreff = query | DirectQueryScalar -%}
{{ EmailBetreff -}}
Der holt sich den Lieferschein, der zum Warenlagereingang gehört, also zur Retoure und liefert Dir so wie er oben steht die Retourennummer zurück. Falls Du den internen Kommentar haben willst, ersetzte Du oben ...
SQL:
SELECT tRMRetoure.cRetoureNr AS RetoureNr FROM tRMRetoure
... durch ...
SQL:
SELECT tRMRetoure.cKommentarIntern AS KommentarIntern FROM tRMRetoure
P.S. Dass Du Dir im Fenster der Erweiterten Eigenschaft erst unten rechts einen Warenlagereingang für die Vorschau laden musst, weil die Vorschau sonst immer grau bleibt, weil sie keine Daten hat, weißt Du?

Gruß,
Ingmar
 

swopper-shop

Gut bekanntes Mitglied
10. Mai 2010
185
1
#8
Hallo @swopper-shop,

falls ich mich nicht sehr irre, kann der Code nicht funktionieren, da ein Warenlagereingang - auch aus einer Retoure heraus - keinen Bezugsauftrag hat, der als Variable mit an den Workflow übergeben wird. Was aber übergeben wird, ist die ursprüngliche Lieferscheinnummer und da die Wawi die Lieferschein-Nummern ja von der Auftragsnummer ableitet, kann man die benutzen, siehe unten.

Und dann versucht der Code auch noch statt einem Eintrag gleich eine ganze Liste von Einträgen zurückzugeben, was für mich nun gar keinen Sinn macht (oder ich raff nicht, wann/warum das Sinn machen könnte. Dass das dann auch noch die externen Kommentare sind und nicht die internen Kommentare oder die Retourennummern, die Du haben willst, macht den Kohl dann auch nicht mehr fett ... ;)

Versuch's mal mit folgendem Code ...
SQL:
{% capture query -%}
SELECT tRMRetoure.cRetoureNr AS RetoureNr FROM tRMRetoure
JOIN tBestellung ON tBestellung.kBestellung = tRMRetoure.kBestellung
WHERE tBestellung.cBestellNr=SUBSTRING('{{ Vorgang.Lieferscheinnummer }}',1,LEN('{{ Vorgang.Lieferscheinnummer }}')-4)
{% endcapture -%}
{% assign EmailBetreff = query | DirectQueryScalar -%}
{{ EmailBetreff -}}
Der holt sich den Lieferschein, der zum Warenlagereingang gehört, also zur Retoure und liefert Dir so wie er oben steht die Retourennummer zurück. Falls Du den internen Kommentar haben willst, ersetzte Du oben ...
SQL:
SELECT tRMRetoure.cRetoureNr AS RetoureNr FROM tRMRetoure
... durch ...
SQL:
SELECT tRMRetoure.cKommentarIntern AS KommentarIntern FROM tRMRetoure
P.S. Dass Du Dir im Fenster der Erweiterten Eigenschaft erst unten rechts einen Warenlagereingang für die Vorschau laden musst, weil die Vorschau sonst immer grau bleibt, weil sie keine Daten hat, weißt Du?

Gruß,
Ingmar
Danke,hat leider nicht funktioniert: Es kommt folgende Meldung: Fehler im Befehl: Es wurde ein ungültiger Längenparameter an die substring-Funktion übergeben.
Habe es auch mit
SQL:
SELECT tRMRetoure.cKommentarIntern AS KommentarIntern FROM tRMRetoure
probiert, Meldung ist identisch

Hast Du ne Idee?
 

gutberle

Sehr aktives Mitglied
29. März 2011
1.242
305
#9
Hi @swopper-shop,

ja klar, die Fehlermeldung sagt es ja eigentlich schon: Du hast mit Sicherheit unten rechts keinen "Vorschau-Warenlagereingang" ausgewählt. Dann ist Vorgang.Lieferschein leer und seine Länge 0, was ungültig ist. Bei den Workflows ist es anders als bei den Vorlagen, wo die Wawi ja standardmäßig immer den letzten Auftrag, Angebot, Lieferschein, ... in die Vorlage lädt. Hier, bei den Workflows ist erst einmal nichts geladen, das musst Du selbst tun, wenn Du den Workflow testen willst.

Jetzt ist es aber auch gar nicht einfach, aus der Liste der Warenlagereingänge, den/die rauszufinden, die auf Retouren basieren, weil schlicht alle gelistet werden und dann auch nur die ersten 500, was ein Killer sein kann, denn dann kann es gut sein, dass Du Deinen Wunsch-Wareneingang gar nicht zum Testen finden kannst.

Aber mach mal folgendes: Kopier mal den Code von unten einfach vor Deinen Worklow Code, am besten mit einer Leerzeile dazwischen, damit Du den Überblick behältst. Dann wechselst Du in das Vorschau Fenster und oben werden Dir dann alle Deine Warenlagereingänge gelistet, die auf Retouren basieren.
SQL:
{% capture query -%}
SELECT retpos.kRMRetoure AS retoure, CONVERT(DATETIME,wle.dErstellt,104) AS datum, bst.cBestellNr AS bestellnr,
    art.cArtNr AS artikelnr, artbs.cName AS artikelname, CONVERT(INT,retpos.fAnzahl) AS anzahl FROM tWarenLagerEingang wle
    JOIN tRMRetourePos retpos ON retpos.kRMRetourePos=wle.kRMRetourePos
    JOIN tArtikel art ON art.kArtikel=retpos.kArtikel
    JOIN tArtikelBeschreibung artbs ON artbs.kArtikel=art.kArtikel
    JOIN tLieferscheinPos lspos ON lspos.kLieferscheinPos=retpos.kLieferscheinPos
    JOIN tLieferschein ls ON ls.kLieferschein=lspos.kLieferschein
    JOIN tBestellung bst ON bst.kBestellung=ls.kBestellung
    WHERE wle.kRMRetourePos>0 AND artbs.kPlattform=1 AND artbs.kSprache=1
    ORDER BY retpos.kRMRetoure DESC
{% endcapture -%}
{% assign result = query | DirectQuery -%}
{% for row in result.Daten -%}
{{ row.datum }}   {{ row.retoure }}   {{ row.bestellnr }}   {{ row.artikelnr }}   {{ row.anzahl }}   {{ row.artikelname }}
{% endfor -%}
Da drunter steht immer noch die Fehlermeldung Deines Workflow-Codes, es ist ja noch nichts ausgewählt. Aus dieser Liste suchst Du Dir dann Datum und Uhrzeit Deines Wunsch-Wareneingangs zum Testen aus. Dann klickst Du unten rechts auf "Vorschau-Warenlagereingang wählen" und suchst den Warenlagereingang mit exakt dem Datum+Uhrzeit. Den wählst Du aus und schon sollte im Vorschau Fenster unten die Fehlermeldung verschwinden und Deine Retourennummer erscheinen.

Funktioniert das, kannst Du den oberen Code-Teil mit der Liste der Retouren wieder löschen. Achte auch darauf, dass Du auch eine eventuell eingefügte Leerzeile wieder löscht. Und klar, diesen Ganzen Aufwand musst Du natürlich nur zum Testen treiben. Später, wenn eine Retoure einen Warenlagereingang auslöst, sollte Vorgang.Lieferscheinnummer automatisch gesetzt sein und alles "von alleine" funktionieren.

Gruß,
Ingmar
 

swopper-shop

Gut bekanntes Mitglied
10. Mai 2010
185
1
#10
Hi @swopper-shop,

ja klar, die Fehlermeldung sagt es ja eigentlich schon: Du hast mit Sicherheit unten rechts keinen "Vorschau-Warenlagereingang" ausgewählt. Dann ist Vorgang.Lieferschein leer und seine Länge 0, was ungültig ist. Bei den Workflows ist es anders als bei den Vorlagen, wo die Wawi ja standardmäßig immer den letzten Auftrag, Angebot, Lieferschein, ... in die Vorlage lädt. Hier, bei den Workflows ist erst einmal nichts geladen, das musst Du selbst tun, wenn Du den Workflow testen willst.

Jetzt ist es aber auch gar nicht einfach, aus der Liste der Warenlagereingänge, den/die rauszufinden, die auf Retouren basieren, weil schlicht alle gelistet werden und dann auch nur die ersten 500, was ein Killer sein kann, denn dann kann es gut sein, dass Du Deinen Wunsch-Wareneingang gar nicht zum Testen finden kannst.

Aber mach mal folgendes: Kopier mal den Code von unten einfach vor Deinen Worklow Code, am besten mit einer Leerzeile dazwischen, damit Du den Überblick behältst. Dann wechselst Du in das Vorschau Fenster und oben werden Dir dann alle Deine Warenlagereingänge gelistet, die auf Retouren basieren.
SQL:
{% capture query -%}
SELECT retpos.kRMRetoure AS retoure, CONVERT(DATETIME,wle.dErstellt,104) AS datum, bst.cBestellNr AS bestellnr,
    art.cArtNr AS artikelnr, artbs.cName AS artikelname, CONVERT(INT,retpos.fAnzahl) AS anzahl FROM tWarenLagerEingang wle
    JOIN tRMRetourePos retpos ON retpos.kRMRetourePos=wle.kRMRetourePos
    JOIN tArtikel art ON art.kArtikel=retpos.kArtikel
    JOIN tArtikelBeschreibung artbs ON artbs.kArtikel=art.kArtikel
    JOIN tLieferscheinPos lspos ON lspos.kLieferscheinPos=retpos.kLieferscheinPos
    JOIN tLieferschein ls ON ls.kLieferschein=lspos.kLieferschein
    JOIN tBestellung bst ON bst.kBestellung=ls.kBestellung
    WHERE wle.kRMRetourePos>0 AND artbs.kPlattform=1 AND artbs.kSprache=1
    ORDER BY retpos.kRMRetoure DESC
{% endcapture -%}
{% assign result = query | DirectQuery -%}
{% for row in result.Daten -%}
{{ row.datum }}   {{ row.retoure }}   {{ row.bestellnr }}   {{ row.artikelnr }}   {{ row.anzahl }}   {{ row.artikelname }}
{% endfor -%}
Da drunter steht immer noch die Fehlermeldung Deines Workflow-Codes, es ist ja noch nichts ausgewählt. Aus dieser Liste suchst Du Dir dann Datum und Uhrzeit Deines Wunsch-Wareneingangs zum Testen aus. Dann klickst Du unten rechts auf "Vorschau-Warenlagereingang wählen" und suchst den Warenlagereingang mit exakt dem Datum+Uhrzeit. Den wählst Du aus und schon sollte im Vorschau Fenster unten die Fehlermeldung verschwinden und Deine Retourennummer erscheinen.

Funktioniert das, kannst Du den oberen Code-Teil mit der Liste der Retouren wieder löschen. Achte auch darauf, dass Du auch eine eventuell eingefügte Leerzeile wieder löscht. Und klar, diesen Ganzen Aufwand musst Du natürlich nur zum Testen treiben. Später, wenn eine Retoure einen Warenlagereingang auslöst, sollte Vorgang.Lieferscheinnummer automatisch gesetzt sein und alles "von alleine" funktionieren.

Gruß,
Ingmar
Hi Ingmar, Du gibst Dir soviel Mühe schon einmal großes Danke.
Ich habe unten schon einen Auftrag ausgewählt mit 100% Retoure, welcher auch in Deiner Liste erscheint, der Fehler bleibt leider der gleiche.

1549964513353.png
 

gutberle

Sehr aktives Mitglied
29. März 2011
1.242
305
#11
Kopiere mal ...
SQL:
|{{ Vorgang.Lieferscheinnummer }}|
... vor Deinen Workflow-Code und wähle den Test-Wareneingang wieder aus. Dann sollte zwischen den beiden senkrechten Strichen Deine Lieferscheinnummer stehen und falls die leer ist, also die senkrechten Striche das Einzige sind, was angezeigt wird, dann hat Dein Warenlagereingang keine zugeordnete Lieferscheinnummer und dann müssten wir alle noch einmal nachdenken, wie wir sicher zur korrekten Information kommen ...
 

swopper-shop

Gut bekanntes Mitglied
10. Mai 2010
185
1
#12
Kopiere mal ...
SQL:
|{{ Vorgang.Lieferscheinnummer }}|
... vor Deinen Workflow-Code und wähle den Test-Wareneingang wieder aus. Dann sollte zwischen den beiden senkrechten Strichen Deine Lieferscheinnummer stehen und falls die leer ist, also die senkrechten Striche das Einzige sind, was angezeigt wird, dann hat Dein Warenlagereingang keine zugeordnete Lieferscheinnummer und dann müssten wir alle noch einmal nachdenken, wie wir sicher zur korrekten Information kommen ...
Bleibt leider leer :(
 

gutberle

Sehr aktives Mitglied
29. März 2011
1.242
305
#13
Hi,

das würde eigentlich bedeuten, dass Deine Retoure auf keiner Lieferung basiert und vielleicht solltest Du mal in der Retoure nachschauen ob und falls ja, was da in der Spalte "Lieferschein-Nr." steht, denn da sollte dann auch nichts stehen und dann fehlt mir ein wenig die Phantasie, wie das zustande kommt ...

Aber egal, probier' mal den untenstehenden Code. Der nimmt nicht mehr die Lieferscheinnummer, sondern Datum und Uhrzeit, zu denen der Warenlagereingang stattgefunden hat und da die Uhrzeit auch Sekunden enthält, sollte schon einmal eindeutig sein. Dann wird auch noch darauf geprüft, dass es der richtige Artikel und die richtige Artikel-Anzahl ist und dass in der Zeile des betreffenden Warenlagereingangs auch hinterlegt sein muss, dass es sich um eine Retoure gehandelt hat.
SQL:
{% capture query -%}
SELECT ret.cRetoureNr AS RetoureNr FROM tWarenLagerEingang wle
    JOIN tRMRetourePos retpos ON retpos.kRMRetourePos=wle.kRMRetourePos
    JOIN tRMRetoure ret ON ret.kRMRetoure=retpos.kRMRetoure
    WHERE CONVERT(VARCHAR(10),wle.dErstellt,104)+' '+CONVERT(VARCHAR(8),wle.dErstellt,108)='{{ Vorgang.Angelegt }}'
        AND wle.kartikel={{ Vorgang.Artikel.Allgemein.Stammdaten.InterneArtikelnummer }}
        AND wle.fAnzahl={{ Vorgang.Menge }}
        AND wle.kRMRetourePos>0
{% endcapture -%}
{% assign EmailBetreff = query | DirectQueryScalar -%}
{{ EmailBetreff -}}
Ein echter direkter Verweis auf den richtigen Warenlagereingang als Variable im Workflow wäre mir natürlich lieber, aber den gibt es halt nicht und das hier ist auch so schon praktisch 100% sicher.

Gruß,
Ingmar
 

swopper-shop

Gut bekanntes Mitglied
10. Mai 2010
185
1
#14
Hi,

das würde eigentlich bedeuten, dass Deine Retoure auf keiner Lieferung basiert und vielleicht solltest Du mal in der Retoure nachschauen ob und falls ja, was da in der Spalte "Lieferschein-Nr." steht, denn da sollte dann auch nichts stehen und dann fehlt mir ein wenig die Phantasie, wie das zustande kommt ...

Aber egal, probier' mal den untenstehenden Code. Der nimmt nicht mehr die Lieferscheinnummer, sondern Datum und Uhrzeit, zu denen der Warenlagereingang stattgefunden hat und da die Uhrzeit auch Sekunden enthält, sollte schon einmal eindeutig sein. Dann wird auch noch darauf geprüft, dass es der richtige Artikel und die richtige Artikel-Anzahl ist und dass in der Zeile des betreffenden Warenlagereingangs auch hinterlegt sein muss, dass es sich um eine Retoure gehandelt hat.
SQL:
{% capture query -%}
SELECT ret.cRetoureNr AS RetoureNr FROM tWarenLagerEingang wle
    JOIN tRMRetourePos retpos ON retpos.kRMRetourePos=wle.kRMRetourePos
    JOIN tRMRetoure ret ON ret.kRMRetoure=retpos.kRMRetoure
    WHERE CONVERT(VARCHAR(10),wle.dErstellt,104)+' '+CONVERT(VARCHAR(8),wle.dErstellt,108)='{{ Vorgang.Angelegt }}'
        AND wle.kartikel={{ Vorgang.Artikel.Allgemein.Stammdaten.InterneArtikelnummer }}
        AND wle.fAnzahl={{ Vorgang.Menge }}
        AND wle.kRMRetourePos>0
{% endcapture -%}
{% assign EmailBetreff = query | DirectQueryScalar -%}
{{ EmailBetreff -}}
Ein echter direkter Verweis auf den richtigen Warenlagereingang als Variable im Workflow wäre mir natürlich lieber, aber den gibt es halt nicht und das hier ist auch so schon praktisch 100% sicher.

Gruß,
Ingmar
Du bist ein Genie, das funktioniert :)
 

gutberle

Sehr aktives Mitglied
29. März 2011
1.242
305
#15
Super, das freut mich! - Könntest Du aber bitte doch noch einmal schauen, ob diese eine Retoure oder vielleicht sogar Deine Retouren insgesamt keine Lieferscheinnummern in den Retourendetails angegeben haben?
Ich wüsste nämlich gerne, ob das Problem zwischen meinen Ohren liegt, oder ob hier vielleicht ein Bug lauert ...
 
Zustimmungen: swopper-shop

swopper-shop

Gut bekanntes Mitglied
10. Mai 2010
185
1
#16
Super, das freut mich! - Könntest Du aber bitte doch noch einmal schauen, ob diese eine Retoure oder vielleicht sogar Deine Retouren insgesamt keine Lieferscheinnummern in den Retourendetails angegeben haben?
Ich wüsste nämlich gerne, ob das Problem zwischen meinen Ohren liegt, oder ob hier vielleicht ein Bug lauert ...

Die Lieferscheinnummer wird bei der Retoure angezeigt:

1549972532632.png