Gelöst WF`s werden scheinbar nicht abgeabeitet

[gnarx]

Hier mal mein WF`s für den Versand:


In den Erweiterten steht das drinne: (Code kann ich nicht posten mehr als 1000 Zeichen)




Nun scheint immer mal wieder der WF nicht ausgeführt zu werden. Ist das ein Zeitproblem, bzw. was kann ich machen?

 

[SebiW]

Hallo CSB, wir haben auch gelegentlich etwas ausufernde Workflows und festgestellt, dass es da bei parallelem BEtrieb manchmal zu wohl Timeout bedingten Problemen kommt.
Ich habe das deutlich reduzieren können indem ich solche Workflows in Nebenzeiten verschoben habe, also bspw alle Rechnungsmails und Versandstati Abends versende.
Ansonsten kannst Du mit der Workflow schraube spielen und die Zeit zwischen den Abgleichen erhöhen um langlaufende Workflows etwas zu verschieben.

 

[gnarx]

Mal ein paar Fragen zu der Schnelligkeit bzw. abarbeiten der WF`s
1. Die Reihenfolge des Abarbeitens wenn nicht Zeitverzögert geht doch von oben nach unten, richtig?
2. Wird gewartet bis ein WF fertig abgearbeitet ist und dann erst der nächste angestossen?
3. Wenn nicht gewartet wird wie lange darf denn ein WF arbeiten damit sich da nichts überschneidet?
4. Wäre es grundsätzlich besser die Abfragen kleiner zu gestalten, um das Problem des Timeouts zu umgehen?
5. In der 1.4 soll ja einiges an den WF`s gemacht werden ist das Timeout Problem damit behoben?
6. Kostet der assign und das jeweilige zurückgreifen bzw. der Umweg der Anweisung auf den assign Zeit? Oder sitzt das im Speicher und deshalb ist die kürze Schreibweise in der Anweisung besser?

Zu 4. Da man ja sowie so pro Versandartänderung einen WF hat, könnte ich ja wie im oberen Code zu sehen den für ES620 (Einschreiben 6,20) nur in einer Erweiterten anlegen alles andere raus.
Ich würde mir denn einfach mehrere Erweiterte anlegen für die jeweilige Versandart. Damit müsste doch dann der WF schneller und gezielter abgearbeitet werden.

Und eins noch kann ich über die Schleife "{% for Item in Vorgang.AuftragsPositionen.ArtikelPositionen %}" den WMS Lagerplatz auslesen?

 

[gnarx]

Zu 4. So würde ich mir das vorstellen (das ES620 wird dann noch gegen eine 1 getauscht):
Hinweis: Der Code ist nun ohne Zeilenumbrüche und Leerzeichen!!!

{% for Item in Vorgang.AuftragsPositionen.ArtikelPositionen %}\
{% if Vorgang.Lieferung.Lieferadresse.LandISO == 'DE' %}{% assign landDE = true %}{% endif %}\
{% if Vorgang.Lieferung.Lieferadresse.LandISO == 'RU' %}{% assign landRU = true %}{% endif %}\
{% assign preis=Vorgang.Zahlungen.GesamtbruttopreisOhneVersandart %}\
{% assign menge=Vorgang.AuftragsPositionen.Positionen.ErstesObjekt.Menge %}\
{% assign waren=Item.Artikel.Warengruppe.Name %}\
{% if waren == "Arbeitsspeicher (RAM)" and landDE !="true" and menge == 1 and preis <= 30,00 %}ES620\
    {% elsif waren == "Arbeitsspeicher (RAM)" and landDE !="true" and menge == 1 and preis >= 30,00 and preis <= 50,00 %}ES620\
    {% elsif waren == "Betriebssystem" and landDE !="true" and menge == 1 %}ES620\
    {% elsif waren == "Controller" and landDE !="true" and menge == 1 and preis <= 30,00 %}ES620\
    {% elsif waren == "Prozessor (CPU)" and landDE !="true" and menge == 1 and preis <= 50,00 %}ES620\
    {% elsif waren == "Gehäuselüfter" and landDE !="true" %}ES620\
    {% elsif waren == "Lüftersteuerung" and landDE !="true" and menge == 1 %}ES620\
    {% elsif waren == "Blende" and landRU =="true" %}ES620\
    {% elsif waren == "Zubehör Sets's" and landRU =="true" and menge == 1 %}ES620\
    {% elsif waren == "Retentionmodul" and landRU =="true" and menge == 1 %}ES620\
    {% elsif waren == "SLI-Brücke" and landRU =="true" and menge == 1 %}ES620\
    {% elsif waren == "Software" and landDE !="true" and menge == 1 %}ES620\
    {% elsif waren == "Soundkarte" and landDE !="true" and menge == 1 %}ES620\
    {% elsif waren == "TV-Karte" and landDE !="true" and menge == 1 %}ES620\  
{% endif %}
{% endfor %}

So css-Umsetzung (hier nochmal ein herzliches danke schön für deine Hilfe) hat ja mal bei einem WF von mir gesagt er würde das als capture Block auslesen. Geht das schneller dann, wäre ja auf alle Fälle weniger Code?

 

[SebiW]

Hallo CSB,
worüber ich an Deiner Stelle bei diesem Aufbau nachdenken würde ist das über einen ganz anderen Weg zu lösen.
Spricht etwas dagegen, bei den Artikeln bzw Artikelgruppen ein eigenes Feld zu führen?
So könntest Du Dir die ganze lange Abfrage sparen und einfach nur auf das Vorhandensein eines Artikels bspw mit der Eigenschaft "ES620=true" zu prüfen und ansonsten nur via Preis/Land/Menge zu filtern.
Diesen könntest Du auch wieder automatisch bei der Anlage / Änderung eines Artikels setzen bzw entfernen lassen.

Hängt natürlich davon ab wie oft sich bei Euch die Preise ändern bzw Artikel neu angelegt werden. Je nachdem ob Du mehr Aufträge einliest oder mehr Artikel anfasst gewinnst oder verlierst Du so Last.

Zu Deinen anderen Punkten:
1. Soweit ich weiß ja
2. Soweit ich weiß ja, kann man im Normalfall auch gut in der Queue beobachten

Zu den restlichen Fragen muss sich JTL äußern.

 

[gnarx]

Danke dir für deine Antwort, ich werde das mal überdenken. JTL hat sich hier dazu geäußert: https://forum.jtl-software.de/threads/ein-paar-fragen-zu-workflows.112261/ falls es dich interessiert.

 

[SebiW]

Habe ich auch mal mit kommentiert, danke für den Hinweis.
Mein Vorschlag kommt daher, dass bei uns bis vor einem halben jahr im Endeffekt genau Deine Art von Workflow lief und wir damit immer wieder Aussetzer hatten.
Ich bin deshalb dazu übergegangen den selben Parameter, den ich auch verwende um im WMS das Picking auf die richtigen Wägen zu verteilen, für den Versand zu verwenden.
Vorteil für uns ist da, dass im Endeffekt der Wert für die Artikelgröße einmal gepflegt wird und so gleich 3 Bereiche, WMS Picking, Versandgröße, SFFP Paketgröße auf einmal erschlagen werden.

 

[gnarx]

Hmm so ganz verstehen tu ich das nicht. Bei uns haben wir verschiedene Picklisten welche durch die Warengruppen richtig angelegt werden. Ich speicher mir das hier mal und würde mich dann mal bei dir melden, wenn ich darf. Kann aber etwas dauern da ich jetzt einen Kunden komplett auf JTL umstelle.

 

[SebiW]

Hu Du, klar gerne.
Im Endeffekt mache ich folgendes: Für das Picking im WMS gibt es ein spezielles Artikelattribut, WMSLagerEigenschaft. Darüber wird der Pick gesteuert bei uns.
Diese Lagereigenschaft habe ich nach unseren Versandgrößen modelliert, in unserem spezifischen Fall auf Amazon SFFP ausgerichtet. Ich habe bei den einzelnen Artikeln also als Eigenschaft XS-XL hinterlegt

Wir verwenden Pickwägen in mehrern Größen. Für die Boxenwägen definiere ich über diese Lagereigenschaft, welche Artikelgrößen auf welchen Wägen gepickt werden können.
Gleichzeitig werte ich bei neuen Aufträgen aus welche Artikelgröße in den Aufträgen enthalten sind und weise über den Parameter, natürlich beeinflußt durch Stückzahl etc, die nötige Paketgröße zu.
Da Artikel nur gepickt werden können wenn der Wert hinterlegt ist (und unser Wareneingang natürlich via Workflow eine Mitteilung erhält wenn ein neuer ARtikel ohne OPickgröße kommt) sorge ich so dafür, dass einerseits immer der nötige Wert beim Artikel geführt ist und andererseits als harter "Kann nicht gepickt werden" Fehler auffällt wenn nicht.

Für Sonderfälle, also bspw deutlich abweichende Stückmengen, habe ich natürlich einen "Mensch schau Dir das an" Fallback.

 

[gnarx]

Wow!!! Übrigens der Björn will sich den WF Sachen annehmen wenn wir ihm das zeigen können: https://forum.jtl-software.de/threads/ein-paar-fragen-zu-workflows.112261/