In Diskussion Workflow besteht alle Test wird nur nicht ausgeführt

[SaschaR1987]

Wir haben einen Workflow erstellt der uns Helfen soll den Aktuellen Lagerbestand bei einem Bestimmten Lieferanten zu HALTEN
Heißt wenn ein Artikel versendet wird soll er in der Anzahl in der er versendet wurde auf die Einkaufliste gesetzt werden
Anbei der Workflow und die Simulation alles sieht gut aus aber es passiert leider nichts

Jemand eine Idee hat es was mit der Umstellung zu tun auf die neue Preis Struktur wir sind im 99 € Paket

Wenn wir am Ende der Simulation sagen Workflow ausführen wird der Artikel auch auf die Einkaufsliste gesetzt, jedoch nur dann nicht automatisch

 

[frankell]

Hallo @SaschaR1987,

wo hast Du den Workflow angelegt, also unter welchem Trigger (Ereignis)?

Die Begrenzung von Workflows betrifft nur die manuellen und die CustomWorkflows, nicht die automatischen (ohne CustomWorkflow), aber auch erst ab der Wawi-Version 1.10.

 

[SaschaR1987]

 

[frankell]

Den Anhang 115045 betrachten

Ich habe das mal interessehalber nachgebaut. Bei mir funktioniert die Automatik. Zwar mit einer anderen Buchungsart (Korrekturbuchung), aber das zeigt zumindest, dass es grundsätzlich funktioniert. Ob aber in Deiner Version 1.8.12.2 vielleicht noch ein Bug vorhanden war, der erst mit einer späteren Version gefixt wurde, kann ich nicht sagen. Du könntest da ggf. den Issuetracker mal durchforsten.

Oder probier es mal mit einer anderen Buchungsart, vll. Warenausgang.

Ansonsten: Ticket bei JTL aufmachen.

 

[Star Piercing]

Evtl hilft dir das hier auch weiter: https://forum.jtl-software.de/threads/minusbuchung-workflow-loest-nicht-aus.126619/

wenn kch das richtig verstehe muss der Workflow unter versand rein.

 

[wawi-dl]

Die Korrekturbuchung funktioniert immer, weil dies ein "manueller Eingriff" ist im Warenbestand.

Beim Auslieferungsprozess wird aber auf Datenbankebene der Bestand verrechnet, hier gibt es schon lange das Problem, dass der "Warenausgang" nicht als Trigger erkannt wird.
Lediglich der "Wareneingang" wird erkannt, hier berechnen wir voll automatisiert alle VK Preise für die Artikel.

Über "Lieferscheine" also Versand kommt man an die Artikel und Trigger ran, man muss nur die verschiedenen Artikeltypen mal prüfen.

Unser Tipp:
Wir haben unter "Aufträge erstellt" eine Überwachung per Workflow gebaut, diese prüft ob unser normale oder globale Mindestlagerbestand unterschritten ist, sofern ja dann wird die Differenz auf die Einkaufsliste gesetzt.

Alternativ bieten wir auch CustomWorkflows an, mit denen man sich Reports schicken lassen kann, welche Artikel als Liste den Mindestbestand unterschritten haben.

 

[frankell]

Evtl hilft dir das hier auch weiter: https://forum.jtl-software.de/threads/minusbuchung-workflow-loest-nicht-aus.126619/

wenn kch das richtig verstehe muss der Workflow unter versand rein.

Ach guck, nur 8,5 Jahre alt, das Ticket: https://issues.jtl-software.de/issues/WAWI-10099

 

[wawi-dl]

Ach guck, nur 8,5 Jahre alt, das Ticket: https://issues.jtl-software.de/issues/WAWI-10099

... das Thema ist auch wohl nur für einen kleineren Teil der Community relevant, bei 10 Votes pro Jahr muss man sich nicht wundern, es wäre was anderes wenn hier paar Hundert stehen würden.

 

[frankell]

... das Thema ist auch wohl nur für einen kleineren Teil der Community relevant, bei 10 Votes pro Jahr muss man sich nicht wundern, es wäre was anderes wenn hier paar Hundert stehen würden.

Bei Feature Requests kann ich das zumindest logisch halbwegs nachvollziehen. Aber es handelt sich um einen Bug. Da sollte es nicht interessieren, ob und wie viele dafür voten oder nicht.

 

[wawi-dl]

JTL schaut zunächst mal, ob die Funktion bereits existent war und funktioniert hatte, dann Bug ansonsten neues Feature.

So hatte ich auch erst kürzlich einen Fall, die Wichtigkeit ist hier aber definitiv nicht sehr groß, betrifft ja nicht viele Anwender.

 

[frankell]

Sorry, aber das geht in die Richtung "defending the indefensible". Denn wenn in einer Software bzw. genauer gesagt in deren GUI eine Funktion sichtbar ist, dann muss ich davon ausgehen können, dass diese die proklamierte Funktion erfüllt. Ist das nicht der Fall oder nur teilweise, ist das ein Bug.

Ich finde es gelinde gesagt unprofessionell, quasi einen Button in die GUI einzubauen, der keine (vollständige) Funktion hat, und es 8,5 Jahre nicht zu schaffen, entweder die Funktion nachzuliefern bzw. zu komplettieren (was man erwarten können muss) oder den Button aus der GUI zu entfernen oder ihn entsprechend klar zu kennzeichnen. Disclaimer: Das Wort "Button" dient nur der besseren Veranschaulichung, ist also lediglich passende Analogie.

 

[wawi-dl]

Gebe ich dir teils recht, ich nenne es irreführend, JTL sollte es dann ausblenden bis es fertig ist dann gibt es keine Diskussionen.

Ändert aber nichts an der Tatsache wie bereits beschrieben, dass diese Funktion nur ein sehr kleiner Teil der 50.000 Kunden braucht.
Rechnen wir mal 500 Kunden, sprechen wir von 1% Relevanz, warum sollte JTL also alles stehen und liegen lassen dafür? Da gibt es wichtigeres ... das Ticket ist ja nur onHold und nicht gestoppt, VOTET und die Relevanz steigt.

 

[chefsalat]

Wenn ich ab jetzt für ein Produkt zahlen muss, dann erwarte ich daß alle bekannten Bugs asap behoben werden und nicht noch dafür gevotet werden muss. Das lasse ich mir bei einem kostenlosen Produkt gefallen, aber ab sofort ist JTL am Zug und muss liefern. Bang for Bucks, so einfach ist das. Und 8 Jahre sind genug Zeit, selbt einen noch so "unwichtigen" Bug zu fixen

 

[Enrico W.]

Bei all der Diskussion ob Bug oder nicht Bug bitte ich zu bedenken: Die Minusbuchung ist ein eigenständiger Prozess und der Versand ist ein eigenständiger Prozess.
Ich wäre zu 10000% dabei, wenn der Punkt schlicht "Bestandsreduzierung" oder so hieße.
Das bedeutet, dass - um alle Fälle abzudecken - zwei Workflows nötig sind. Einer für die Minusbuchung und einer für den Versand.

Aktuell kann man z.B. problemlos einen Kontroll- Workflow bauen, der z.B. eine Infomail versendet oder was weiß ich, wenn eine Minusbuchung durchgeführt wird, ohne dass dieser auch bei Versand getriggert wird - das dürfte nach einer Umstellung nicht mehr so ohne Weiteres möglich sein, es sei denn, es muss explizit im Workflow dann angehakt werden, ob er für Minusbuchungen, Versand oder beides gelten soll.
Ebenso kann man problemlos einen Workflow für den Versand erstellen, der triggert, wenn ein Artikel verschickt wurde.

 

[frankell]

Bei all der Diskussion ob Bug oder nicht Bug bitte ich zu bedenken: Die Minusbuchung ist ein eigenständiger Prozess und der Versand ist ein eigenständiger Prozess.
Ich wäre zu 10000% dabei, wenn der Punkt schlicht "Bestandsreduzierung" oder so hieße.
Das bedeutet, dass - um alle Fälle abzudecken - zwei Workflows nötig sind. Einer für die Minusbuchung und einer für den Versand.

Aktuell kann man z.B. problemlos einen Kontroll- Workflow bauen, der z.B. eine Infomail versendet oder was weiß ich, wenn eine Minusbuchung durchgeführt wird, ohne dass dieser auch bei Versand getriggert wird - das dürfte nach einer Umstellung nicht mehr so ohne Weiteres möglich sein, es sei denn, es muss explizit im Workflow dann angehakt werden, ob er für Minusbuchungen, Versand oder beides gelten soll.
Ebenso kann man problemlos einen Workflow für den Versand erstellen, der triggert, wenn ein Artikel verschickt wurde.

Es geht nicht nur um den zu weit gefassten Begriff "Minusbuchung", sondern hier im konkreten Fall, dass eine der in der Wawi zur Auswahl gestellten Bedingungen für diese Minusbuchung der "Versandprozess WMS" ist.

Dass nicht alle zur Auswahl gestellten Bedingungen funktionieren, ist ein Bug. Punkt. Ist seit 8,5 Jahren bekannt, aber es wird sich darauf ausgeruht, dass es ja Workarounds gebe. Diese stehen nur nicht in der Wawi. Was also passiert? Die Leute probieren, probieren und probieren und geben dann entweder entnervt auf oder melden sich hier. Nur um dann zu erfahren, dass die Auswahlmöglichkeit gar nicht funktioniert, es aber Workarounds gebe.

Ich bleibe dabei, es ist unprofessionell.

Nehmt erstens raus, was nicht funktioniert, und zweitens benennt Minusbuchung um. Diese Distinktion zwischen Versand und Minusbuchung ist für Otto-Normal-User keine und ist auch nicht verständlich und schon gar nicht antizipierbar.

 

[Enrico W.]

Wie lautet dein Vorschlag?
Die Minusbuchung ist schon seit jeher in der Wawi und auch als solche im Guide zu finden - sowohl für die Wawi als auch für WMS.
Wie soll die Minusbuchung dann heißen? Und wie soll der Workflow dann zwischen einer echten Minusbuchung und dem Versand unterscheiden?

 

[frankell]

Wie lautet dein Vorschlag?
Die Minusbuchung ist schon seit jeher in der Wawi und auch als solche im Guide zu finden - sowohl für die Wawi als auch für WMS.
Wie soll die Minusbuchung dann heißen? Und wie soll der Workflow dann zwischen einer echten Minusbuchung und dem Versand unterscheiden?

Meinst Du das ernst?

Ich und mit mir alle Nutzer der Software erwarten schlicht, dass proklamiere Funktionen auch tatsächlich funktionieren, oder dass sie rausgenommen werden und das Verbliebene nicht erkennbar leicht missverstanden werden kann, oder kurz: dass man nicht in die Iree geführt wird. Wie Ihr das eine oder das andere umsetzt, ist Euer selbstgewähltes Problem/Schicksal und damit von Euch nicht auf die Nutzer abzuwälzen.

Die von Dir gemachte Distinktion ist doch von Euch selbst nicht vorgesehen, sonst hätte es der "Versandprozess" wohl erst gar nicht unter die möglichen Bedingungen für Minusbuchungen geschafft.

Und wenn ich das iwem er erzähle, dass eine Ausbuchung beim Versand für JTL keine Minusbuchung darstellt, dann ernte ich entweder schallendes Gelächter oder ungläubiges Kopfschütteln. Da halte ich es mit Wolff Fuss: "Das darfst Du keinem erzählen!"

 

[Enrico W.]

Die Workflows orientieren sich an den Begriffen, die es bereits seit über 10 Jahren in der Wawi gibt.
Deshalb - ja. Wie lautet Dein Vorschlag? Wie sollte ein Workflow aussehen, der alles bisherige auch abbilden kann.

Und beachte bitte, dass du bisherige Workflows dann auch entsprechend mit migrieren musst. Die müssen ja weiterhin funktionieren.

 

[frankell]

Die Workflows orientieren sich an den Begriffen, die es bereits seit über 10 Jahren in der Wawi gibt.
Deshalb - ja. Wie lautet Dein Vorschlag? Wie sollte ein Workflow aussehen, der alles bisherige auch abbilden kann.

Und beachte bitte, dass du bisherige Workflows dann auch entsprechend mit migrieren musst. Die müssen ja weiterhin funktionieren.

Netter Versuch, die Verantwortung für das eigene Handeln auf Dritte abzuwälzen, die im Zweifel überhaupt nicht wissen können, wie Ihr was organisiert/codiert habt.

Der Kern ist und bleibt, dass Ihr selbst den Pfad "Warenlagerausgang - Minusbuchung - Versandprozess" in der Wawi angebt, aber der letzte Teil dessen nicht funktioniert. Dann versuchst Du erst, das durch eine völlig aus der Luft gegriffene Distinktion zu rechtfertigen, deren genaues Gegenteil sich bereits aus dem angegebenen Pfad ergibt. Das beiseite legend kommt der nächste Versuch der Verantwortungsabwälzung, der Kunde möge doch bitte sagen, wie man das Ganze benennen soll, wenn man nicht irreführen soll. Frei formuliert: "Ja, wie soll ich denn bitte nicht irreführen?!"

Und dabei könnte es so einfach sein: Funktion einbauen. Wie es ja offenkundig selbst von Euch geplant war. Also, einfach mal in die Hände spucken und machen, das steigert ggf. ganz nebenbei noch das Bruttosozialprodukt.

Abschließend und hoffentlich zum letzten Mal: Verantwortung für das eine oder das andere: 100 % bei Euch.

"Howgh, ich habe gesprochen!"

 

[Verkäuferlein]

... das Thema ist auch wohl nur für einen kleineren Teil der Community relevant, bei 10 Votes pro Jahr muss man sich nicht wundern, es wäre was anderes wenn hier paar Hundert stehen würden.

Ändert aber nichts an der Tatsache wie bereits beschrieben, dass diese Funktion nur ein sehr kleiner Teil der 50.000 Kunden braucht.
Rechnen wir mal 500 Kunden, sprechen wir von 1% Relevanz, warum sollte JTL also alles stehen und liegen lassen dafür? Da gibt es wichtigeres ... das Ticket ist ja nur onHold und nicht gestoppt, VOTET und die Relevanz steigt.

So hatte ich auch erst kürzlich einen Fall, die Wichtigkeit ist hier aber definitiv nicht sehr groß, betrifft ja nicht viele Anwender.

Häh, das Ticket, dass nach Votes auf Platz 14 ist, ist nicht relevant?

Von den 13 Tickets davor ist aber auch nur eines umgesetzt und das Ticket mit den meisten Votes hat 237 Votes in 8 Jahren, also knappe 0,5% der kolportierten 50000 Nutzer. Entweder ist also der Issue-Tracker nicht relevant (weder für Kunden noch für JTL), oder es stimmt irgendwas an der Basis zur Ermittlung der Relevanz nicht.

Und wie kommst Du zu dem Schluss, dass ein Wawi-System mit Workflowfunktion nicht in diesem Workflowsystem auf jede Bestandsveränderung am Artikel reagieren können sollte, also nur wenige Anwender betroffen sind bzw. profitieren könnten?

Die Aufgabe eines Warenwirtschaftssystems ist doch die Warenwirtschaft und damit unter anderem die Bestandsverwaltung von Artikeln, es liegt also nichts näher, als in einem eingebauten Workflowsystem eben auch auf diesen Kernprozess vollumfänglich reagieren zu können.

Im übrigen ploppt das Thema hier (gefühlt) einmal die Woche im Forum mit einem neuen Thread auf.

Wie lautet dein Vorschlag?
Die Minusbuchung ist schon seit jeher in der Wawi und auch als solche im Guide zu finden - sowohl für die Wawi als auch für WMS.
Wie soll die Minusbuchung dann heißen? Und wie soll der Workflow dann zwischen einer echten Minusbuchung und dem Versand unterscheiden?

Das Problem habt Ihr doch selber schon erkannt und theoretisch gelöst, nur die vollumfängliche Umsetzung fehlt noch:
https://issues.jtl-software.de/issues/WAWI-51411
https://issues.jtl-software.de/issues/WAWI-24438

oder man macht in der Workflow-Verwaltung unter Artikel einen Oberpunkt unter dem alle negativen Bestandsänderungen ausgelöst werden und einen Unterpunkt, bei dem nur bei (manueller) Minusbuchung ausgelöst wird.

Und beachte bitte, dass du bisherige Workflows dann auch entsprechend mit migrieren musst. Die müssen ja weiterhin funktionieren.

Ihr wisst doch (hoffentlich), was die Wawi aktuell kann und was sie dann kann. Dann behält der Workflow halt die bisherige Funktion und weitere Buchungsarten lassen sich zusätzlich anhaken (schreibst Du ja selber) oder der Workflow lässt sich halt in eine Oberkategorie verschieben, in der er für alle Buchungsarten auslöst. Damit entsteht dann für niemanden eine Verschlechterung.