In Diskussion Workflow Gesamtzahl der Artikel im Auftrag zählen

[smarte]

Hallo,

Wir versuchen aktuell einen Workflow zu erstellen der die Gesamtzahl der Artikel im Auftrag zählt.
Heißt es gibt 2 Positionen im Auftrag die jeweils 5 mal bestellt worden sind, dann sollte die Ausgabe 10 sein.

In den anderen Threads habe ich bereits diese Methode gefunden: {{ Vorgang.AuftragsPositionen.ArtikelPositionen.Anzahl }}

Diese gibt allerdings nur die Anzahl der Positionen im Auftrag aus, nicht addiert mit den bestellten Mengen.

Kennt jemand eine Lösung?

Vielen Dank!

 

[keinbenutzername]

versuchs mal damit
{% for position in Vorgang.Auftrag.Positionen | Limit:10 -%}{{ position.Menge | Nummer }}; {{ position.Artikel.Bezeichnung }} ;{% endfor -%};

 

[smarte]

Hey,

danke für dein Vorschlag! Leider bekomme ich damit kein Ergebnis.

Anbei noch ein paar Screenshots.

 

[keinbenutzername]

Hi,

entschuldige bitte, ich war grad bei einer Ausgabe nicht bei einer Workflow Bedingung.
Was soll denn danach mit den Aufträgen passieren?
Alternativ hier ein Screenshot von der Ausgabe in einer csv Datei mit der Artikelmenge, Bezeichnung und Auftragsnummer
Der komplette Inhalt wäre dann:
{% for position in Vorgang.Auftrag.Positionen | Limit:10 -%}{{ position.Menge | Nummer }}; {{ position.Artikel.Bezeichnung }} ;{% endfor -%}; {{ Vorgang.Auftrag.Auftragsnummer }};

 

[smarte]

Ich bräuchte es leider als Bedingung, da ich z.B ab 5 Artikel in einer Bestellung eine andere Lieferschein Vorlage benutzen möchte.
Die Vorlage zu wechseln ist auch kein Problem aber die Gesamtanzahl der Artikel herauszubekommen kriege ich einfach nicht hin.
Vielleicht hast du dafür auch eine Lösung?

Vielen Dank!

 

[keinbenutzername]

Leider fällt mir hierzu aktuell auch keine Variable ein.
Wenn es sich nur um einen Artikel handelt:
Bedingung Artikelnummer xy
Gewicht mehr als xy
-> Vorlage ändern

 

[Frieda]

Hallo.
Über erweiterte Eigenschaft lege "Gesamtmenge" an und füge ein:

HTML clipboard {% assign Gesamtmenge = 0 -%}
{% for Artikelbeschreibungen in Vorgang.AuftragsPositionen.ArtikelPositionen -%}
{% assign Gesamtmenge = Gesamtmenge | Plus: Artikelbeschreibungen.Menge -%}
{% endfor -%}
{{ Gesamtmenge | Floor }}

Dann als Bedingung, so wie es gebraucht wird anlegen.
Es werden alle Mengen aus allen Artikelpositionen gezählt.

 

[Dano]

Hallo,

gibt es womöglich einen Code für die eigenen Übersichten?

 

[Cassiopeia]

Möchte das Thema gerne nochmal aufgreifen, wir würden gerne Aufträge zurückhalten wo die Positionen zusammengezählt mehr als Anzahl 10 haben.
Leider funktionieren die oben genannten Workflows nicht, mache ich da vielleicht was falsch ?

Die Doku zu Schleifen und Workflows bei JTL ist leider noch sehr ausbaufähig.

Ich muss bestimmt eine Schleife laufen lassen die alle Positionen zählt und die Anzahl der Artikel darin und diese dann addiert und ausgibt, aber wie ?

 

[Cassiopeia]

Möchte das Thema gerne nochmal aufgreifen, wir würden gerne Aufträge zurückhalten wo die Positionen zusammengezählt mehr als Anzahl 10 haben.
Leider funktionieren die oben genannten Workflows nicht, mache ich da vielleicht was falsch ?

Die Doku zu Schleifen und Workflows bei JTL ist leider noch sehr ausbaufähig.

Ich muss bestimmt eine Schleife laufen lassen die alle Positionen zählt und die Anzahl der Artikel darin und diese dann addiert und ausgibt, aber wie ?

UPDATE:
Als Rückgabewert musste ich noch Zahl ausgeben statt Text, jetzt scheint es zu gehen.

 

[Christian_BD]

Hallo zusammen,
ich würde das Thema gerne nochmals aufgreifen:
Funktioniert das bei euch?

Hintergrund:
Sowohl mit der erweiterten Eigenschaft als auch dem Feld aus der Datenbank {{ Vorgang.AuftragsPositionen.ArtikelPositionen.Anzahl }} kommt nie der passende Wert raus.
5 Positionen mit jeweils 1 Artikel und als Ergebnis kommt 9.

 

[Cassiopeia]

Hallo zusammen,
ich würde das Thema gerne nochmals aufgreifen:
Funktioniert das bei euch?

Hintergrund:
Sowohl mit der erweiterten Eigenschaft als auch dem Feld aus der Datenbank {{ Vorgang.AuftragsPositionen.ArtikelPositionen.Anzahl }} kommt nie der passende Wert raus.
5 Positionen mit jeweils 1 Artikel und als Ergebnis kommt 9.

Hi also mein Workflow sieht so aus

 

[Christian_BD]

Wir machen das jetzt über eine erweiterte Eigenschaft, da kommen auch korrekte Werte raus. Wichtig ist nur, dass die Versandart auch immer als ein Artikel mitgezählt wird:

{% capture query -%}select SUM(nAnzahl) from tbestellpos
join tBestellung on tBestellung.kBestellung=tbestellpos.tBestellung_kBestellung
where cBestellNr='{{ Vorgang.Stammdaten.Auftragsnummer }}'{% endcapture -%}{{ query | DirectQueryScalar | Round |FormatNumber: 'N0', 'en-US' }}

Viele Grüße

 

[WebFischer]

Wir machen das jetzt über eine erweiterte Eigenschaft, da kommen auch korrekte Werte raus. Wichtig ist nur, dass die Versandart auch immer als ein Artikel mitgezählt wird:

{% capture query -%}select SUM(nAnzahl) from tbestellpos
join tBestellung on tBestellung.kBestellung=tbestellpos.tBestellung_kBestellung
where cBestellNr='{{ Vorgang.Stammdaten.Auftragsnummer }}'{% endcapture -%}{{ query | DirectQueryScalar | Round |FormatNumber: 'N0', 'en-US' }}

Viele Grüße

für 1.5.50.1 geht auf jeden Fall als weitere Bedingung :
" tbestellpos.ntype ='1' " => es werden somit bei uns keine Freipositionen, wie z.B. Versandarten, mitgezählt

 

[Shop-Schmied]

Kann mir jemand den Code nennen, um alle Artikelnummern eines Auftrages aus LS-POS auszugeben?
Ich möchte beim Verkauf von Artikeln eines festgelegten Lieferanten (soweit bin ich schon) eine .txt-Datei schreiben, die von den verkauften Positionen allle Artikelnummern enthält.

Ich finde immer nur den Weg die erste Position auszugeben. Das reicht aber leider nicht aus.

Ich habe jetzt folgendes gemacht, was leider nur beim Test funktioniert - und sobald ich tatsächlich an der Kasse verkaufe eben nicht. Was kann ich tun?:

 

[Cassiopeia]

Hatte das gleiche Problem, leider sind Workflows und CO. bei JTL nahezu nicht dokumentiert, aber ich habe mir beholfen in dem ich eine Schleife hab laufen lassen über die Auftragspositionen.
Dadurch geht er in jeden Auftrag rein und nicht nur den ersten:

Das sieht dann so aus und du musst dann rauslöschen was du nicht willst:




Ich kenne deinen Fall jetzt nicht speziell aber das Stichwort ist hier zum suchen:

Schleifen bzw. Schleife.

 

[Shop-Schmied]

Ja, auf das mit der Schleife bin ich irgendwo gestoßen und habe das bislang so gelöst... beim Testlauf funktioniert das auch noch. Aber beim Test unter Realbedingungen nicht. Wenns dann läuft gäbe es noch einiges an Verbesserungspotential (z.B. die tatsächlich verkaufte Stückzahl auszulesen, statt automatisch -1 zu schreiben, was aber meist der Fall ist). Hier mal mein Inhalt fürs Schreiben der .txt:

Artikelnummer;Lagerbestand;
{% for Artikelbeschreibungen in Vorgang.AuftragsPositionen.ArtikelPositionen %}
{{ Artikelbeschreibungen.Artikelnummer }};-1;
{% endfor %}

Im Grunde brauche ich nur die Lagernummern, besser auch noch die verkaufte Anzahl. Dann wäre noch spannend, was bei Retouren passiert... denn die würden ja dann falsch vom Bestand abgezogen (sofern noch vorhanden).

 

[Shop-Schmied]

Ich glaube inzwischen, dass der Fehler weiter oben liegt... in den Bedingungen. Ich verstehe es nur nicht:

Sonstiges.Plattform.Name gleich LS-POS

Auftragspositionen.ArtikelPositionen.enthält.Artikel.Lieferantenzuordnung.Standard_Lieferant.Firma gleich XXXXX

Diese Zeilen müssten doch bewirken, dass beim Verkauf von Artikeln des gewählten Lieferanten (an der Kasse) die gewünschten Aktionen ausgeführt werden. Ist es ggf. ein Problem, dass ich für mein Testszenario einen Lieferanten mit Dropshipping gewählt habe? Das dürfte doch keinen Einfluss darauf haben.

Wie bereits erwähnt. Im Testlauf funktioniert das schon wie gewollt. Nur nicht, bei den Testbuchungen unter realen Bedingungen.

UPDATE:
Bin endlich mal darauf gekommen, dass mir die Workflow-Logs wohl weiterhelfen 🤐. Ich hatte ein Verständnisproblem... aber der Reihe nach.
Ich habe den Workflow auf zwei aufgeteilt. Jetzt schreibt der erste nur die Datei. Der zweite (manuelle) Workflow wird vom ersten angestoßen und mit leichtem Zeitversatz ausgeführt.
Dabei habe ich dann aber außer acht gelassen, dass der Kassen-PC den ersten Workflow ausführt --- und demzufolge konnte dieser die Datei nicht auf meinem Desktop speichern.
Als das behoben war (einfach den Kassendesktop mal als Speicherort gewählt) konnte natürlich wiederrum der Server, der den zweiten workflow ausführt nicht auf die nötigen Pfade zugreifen.
Das ganze hat etwas gutes... denn nebenbei habe ich bemerkt, dass ich von LS-POS bzw. Wawi am Kassen-PC aus nicht auf unser NAS-Laufwerk zugreifen konnte und dieses Problem gelöst.
Drückt mir mal die Daumen für morgen, da müsste das ans Laufen kommen 🤞.
Ich dachte halt die ganze Zeit, die Workflows würden eh nur vom Server ausgeführt ...

Das ist schon einmal ein Erfolg. Wenn ich jetzt noch die Anzahl der verkauften Artikel pro Artikelnummer im Auftrag auslesen und ein minus-1 davor schreiben könnte, dann würde das sogar auch mit Mehrfachartikeln funktionieren. So bekomme ich jetzt immer ne Mail zur Kontrolle...