Beantwortet Workflow Bedingung greift seit der 1.6 nicht mehr

[jendris]

Hallo,

die Bedingung im Workflow lautet: Auftrag\Auftragspositionen\IstKomplettDropshippingLieferbar = True
Im Artikel ist der Lieferant ein eingetragener Dropshipper und der Haken, dass "Droppshipping möglich" ist, ist auch gesetzt.
Nichts wurde gegenüber der 1.5 verändert. Bis dahin lief alles problemlos.

Nun sagt der WF Test, das die o.g. Bedingung False ist.

Wurde hier irgendwas verändert? True kann ja nicht plötzlich False sein.

 

[Enrico W.]

Acuh wenn das jetzt 1.6 ist verschieb ich das Thema mal zu den Workflows, damit die Kollegen das eher sehen.

 

[Verkäuferlein]

Nun sagt der WF Test, das die o.g. Bedingung False ist.

Das verstehe ich nicht ganz: Die Bedingung, dass der Workflow ausgeführt wird ist doch
Auftrag\Auftragspositionen\IstKomplettDropshippingLieferbar = True

Wenn dann
Auftrag\Auftragspositionen\IstKomplettDropshippingLieferbar = False
wird der Workflow nicht ausgeführt.

Wenn ich Dich richtig verstehe, steht genau das im Test-Durchlauf!?

Also musst Du ja eigentlich gucken, was dazu führt, dass der Auftrag nicht komplett per Dropshipping lieferbar ist.

 

[jendris]

Es ist leider genauso, wie ich oben beschrieben habe.
Wir haben mit der 1.6 ja nichts an unseren Abläufen oder den Einstellungen im Lieferanten verändert.
Und geprüft habe ich auch, ob der Lieferant immer noch Dropshipper ist.

Der Workflow macht es einfach falsch herum.
Völlig entnervt, habe ich alle betroffenen WFs komplett neu aufgebaut, und habe diese Bedingung rausgeworfen.

 

[Verkäuferlein]

Es ist leider genauso, wie ich oben beschrieben habe.
Wir haben mit der 1.6 ja nichts an unseren Abläufen oder den Einstellungen im Lieferanten verändert.
Und geprüft habe ich auch, ob der Lieferant immer noch Dropshipper ist.

Der Workflow macht es einfach falsch herum.
Völlig entnervt, habe ich alle betroffenen WFs komplett neu aufgebaut, und habe diese Bedingung rausgeworfen.

Hab's gerade mal selbst probiert. Der Workflow macht es aber nicht falsch herum, die Logik scheint nur eine andere zu sein.

Wenn ich den Haken bei Dropshipping möglich drin habe, den Bestand des Lieferanten aber auf 0, kommt "FALSE" raus. Habe ich den Lieferanten-Bestand auf 1 (Menge im Auftrag), kommt "TRUE" heraus.

Das komische ist jedoch wenn man:
Auftrag\Auftragspositionen\IstKomplettDropshippingLieferbarOhneFreiposition = True

als Bedingung setzt, kommt auch vorher schon "TRUE" als Ergebnis. Da wird das Verhalten dann irgendwie unlogisch.

 

[jendris]

Wenn ich den Haken bei Dropshipping möglich drin habe, den Bestand des Lieferanten aber auf 0, kommt "FALSE" raus. Habe ich den Lieferanten-Bestand auf 1 (Menge im Auftrag), kommt "TRUE" heraus

Ach ne, guck an.
Der Lieferantenbestand war und ist bei uns immer auf 0, weil wir den nicht pflegen müssen.
Der Bestand hatte auf die WF Bedingung nie Einfluß.
Entscheidend war der Dropshipping Haken im Artikel UND im Lieferanten. Mehr nicht.

Warum zum Himmel ändert man das?

 

[Verkäuferlein]

Warum zum Himmel ändert man das?

Entweder ist es ungewollt oder irgendwem ist aufgefallen, dass das unlogisch ist, dass bei 0 = lieferbar ist...

Macht sich ja auch keiner einen Kopf drum, was das in der Praxis bedeutet.
Erst soll man alles mit einem Workflow oder Workaround lösen und dann hinterher fällt einem das auf die Füße, weil JTL bemerkt, dass die Warenwirtschaft erstmal logisch und gleichmäßig arbeiten muss, damit das sinnvoll und dauerhaft funktioniert und man nicht tausende von Abhängigkeiten schafft, die keiner mehr überblickt, weil jeder seine eigene (Un-)Logik um die Logik von JTL drumherumgebaut hat.

Man kann ja auch immer noch ausliefern, wenn der Bestand 0 ist und es macht ja an sich auch nur Sinn, wenn man den Bestand zum eigenen Bestand hinzufügt. Daher muss man eigentlich den Lieferantenbestand und die Verfügbarkeit beim Lieferanten abtrennen. Wir haben viele Lieferanten, die gar keine Bestände bekannt geben, sondern nur melden, wenn ein Artikel nicht mehr verfügbar ist oder wieder verfügbar ist.

An Deiner Stelle würde ich davon ausgehen, dass sich das in nächster Zeit noch mindestens 3x ändert, weil da scheinbar aktuell dran geschraubt wird (also am Dropshipping).

 

[jendris]

Wir haben viele Lieferanten, die gar keine Bestände bekannt geben, sondern nur melden, wenn ein Artikel nicht mehr verfügbar ist oder wieder verfügbar ist.

Wie bei uns.

Entweder ist es ungewollt oder irgendwem ist aufgefallen, dass das unlogisch ist, dass bei 0 = lieferbar ist...

Was ist schon logisch. Es gibt noch eine ähnliche Bedingung mit Dropshipping, jedenfalls vom Wortlaut her.
Bei den Massen an Bedingungen kann man doch eh nur erahnen, oder aber testen, was sich dahinter verbirgt.
Wenn der Test dann positiv ist, ok, wenn er das in der neuen Version nicht mehr ist...Asche.
Eine Hilfe gibt es nicht, die wäre wohl auch dicker als ein Telefonbuch.

Es ist wie schon immer bei JTL. Ein Update dauert Ewigkeiten, kommt dann völlig überlagert mit neuen Funktionen, und eben auch mit reichlich viel Bugs.
Ich kann den Kram von Pilotversionen und Pilotkunden nicht mehr hören. Das hat noch nie was genützt. Ich darf das behaupten, denn ich habe wirklich schon oft gelitten, nach einem Update.

Ganz nebenbei, fliegt mit auch die Ameise seit der 1.6 regelmäßig um die Ohren. Da greifen mehrere Vorlagen einfach nicht mehr. Importe werden nicht erkannt, weil die EAN Zuordnung nicht mehr aktiv ist, und und und.

Ich bin kein Programmierer oder Softwareentwickler, aber würden kleinere, häufiger erscheindene Updates nicht viel überschaubarer und weniger fehleranfällig sein?

 

[Gökhan Basoglu]

Hallo jendris,

es haben sich Kunden gemeldet das es keinen Dropshipping Lieferantenbestand gibt und die Variable trotzdem meldet das es lieferbar wäre, womit sie auch logisch gesehen recht hatten. Diese Kunden haben natürlich den Lieferantenbestand gepflegt. Dies wurde mit dem Ticket https://issues.jtl-software.de/issues/WAWI-44326 angepasst. Es wird jetzt auch der Lieferantenbestand beachtet. D.h der Lieferantenbestand muss größer gleich der offenen Gesamtmenge eines Artikels sein. Der Lieferantenbestand ist die Summe des Lieferantenbestandes aller Dropshipping-Lieferanten dieses Artikels. Mit einer erweiterten Eigenschaft können Sie trotzdem ihr gewünschtes Kriterium in einer Bedingung prüfen zum Beispiel ob alle Artikel eines Auftrages einen Dropshipping Lieferanten aufweisen.

 

[jendris]

Danke für die Rückmeldung.

Woher soll ich wissen, dass JTL die WF Bedingung geändert hat? Diesen Jira Link sehe ich zu ersten Mal und muß mich da erstmal registrieren.
Meine Bedingung hat über Jahre funktioniert, aber weil ein paar Kunden diese unlogisch finden, ändert ihr diese einfach, und lasst anderen Kunden ins offene Messer laufen.
Besser wäre es gewesen, ihr hättet den wenigen Kunden eine "NEUE" + "LOGISCHE" Bedinung zusätzlich eingebaut.
Ich kann doch nicht nach jedem Update all meine WF testen.

Welche Bedingung wäre denn die richtige für mich? Die Bedingung soll sein, dass der Artikel ein Dropshipping Artikel ist, und einem Dropshipping Lieferanten zugeteilt ist.
Der Lieferantenbestand ist unwichtig.

 

[Verkäuferlein]

Hallo jendris,

es haben sich Kunden gemeldet das es keinen Dropshipping Lieferantenbestand gibt und die Variable trotzdem meldet das es lieferbar wäre, womit sie auch logisch gesehen recht hatten. Diese Kunden haben natürlich den Lieferantenbestand gepflegt. Dies wurde mit dem Ticket https://jira.jtl-software.de/browse/WAWI-44326 angepasst. Es wird jetzt auch der Lieferantenbestand beachtet. D.h der Lieferantenbestand muss größer gleich der offenen Gesamtmenge eines Artikels sein. Der Lieferantenbestand ist die Summe des Lieferantenbestandes aller Dropshipping-Lieferanten dieses Artikels. Mit einer erweiterten Eigenschaft können Sie trotzdem ihr gewünschtes Kriterium in einer Bedingung prüfen zum Beispiel ob alle Artikel eines Auftrages einen Dropshipping Lieferanten aufweisen.

Danke für die Rückmeldung.

Woher soll ich wissen, dass JTL die WF Bedingung geändert hat? Diesen Jira Link sehe ich zu ersten Mal und muß mich da erstmal registrieren.
Meine Bedingung hat über Jahre funktioniert, aber weil ein paar Kunden diese unlogisch finden, ändert ihr diese einfach, und lasst anderen Kunden ins offene Messer laufen.
Besser wäre es gewesen, ihr hättet den wenigen Kunden eine "NEUE" + "LOGISCHE" Bedinung zusätzlich eingebaut.
Ich kann doch nicht nach jedem Update all meine WF testen.

Welche Bedingung wäre denn die richtige für mich? Die Bedingung soll sein, dass der Artikel ein Dropshipping Artikel ist, und einem Dropshipping Lieferanten zugeteilt ist.
Der Lieferantenbestand ist unwichtig.

Der Jira-Link ist ein Verweis auf ein internes Ticket bei JTL. Hier findest Du das Ticket im öffentlichen Issue-Tracker:
https://issues.jtl-software.de/issues/WAWI-44326

Aber genau das ist das Problem, was ich immer an JTL kritisiere, es macht sich keiner Gedanken über die Abhängigkeiten und bereits gebastelte Workflows und Workarounds, wenn irgendwas nicht funktioniert, soll man sich einen Workflow basteln und dann wird hier ein kleines Schräubchen geändert und da ein kleines Schräubchen und plötzlich läuft das alles nicht mehr.

Das eigentlich zugrundeliegende Problem ist aber nicht diese Workflow-Bedingung oder die unbedachte Änderung daran, sondern eine unfertige Dropshipping-Abwicklung in der Wawi.

Es gibt ja faktisch keine Möglichkeit, einen Lieferantenartikel als nicht verfügbar zu kennzeichnen, außer der 0 im Bestand. Und nicht alle Lieferanten stellen Bestände zur Verfügung.

Soll heißen:
Das ist eine selbstgebaute Falle, weil die eine Hälfte der Kunden sich daran gewöhnt hat und keine praktische Möglichkeit hat die Verfügbarkeit beim Lieferanten zu pflegen, außer den Haken bei "Dropshipping möglich" rauszunehmen und die andere Hälfte sich wundert, warum ein Ausliefern bei Bestand 0 per Dropshipping möglich ist.

JTL löst aber nicht das zugrundeliegende Problem, sondern spielt jetzt "Kunden-Ping-Pong" und ändert das einfach, dann beschwert sich die erste Hälfte und es wird wieder zurückgeändert,... Anstatt einfach mal klare Abläufe zu schaffen und das zugrundeliegende Problem zu lösen.

Am Ende wundern sich dann alle, warum die Entwicklung nicht vorwärts schreitet und es 120000 unerledigte Tickets gibt...

Der Name des Tickets kann dann nebenbei auch noch alles oder nichts bedeuten...

Es wäre mal sinnvoll, dass alle umgreifend relevanten Punkte bei einem Update auch entsprechend dokumentiert sind, damit man weiß, auf welche veränderten Verhaltensweisen man sich einstellen muss.

 

[jendris]

Aber genau das ist das Problem, was ich immer an JTL kritisiere, es macht sich keiner Gedanken über die Abhängigkeiten und bereits gebastelte Workflows und Workarounds, wenn irgendwas nicht funktioniert, soll man sich einen Workflow basteln und dann wird hier ein kleines Schräubchen geändert und da ein kleines Schräubchen und plötzlich läuft das alles nicht mehr.

Genauso ist es.
Es wird immer wieder betont - bau dir einen Workflow. Und dann schrauben sie an deinen WF rum und verändern die komplette Struktur damit.
Erstaunlich ist, das JTL immer ein Erklärung parat hat, (s.o.).
Vielleicht erwartet man noch, das ich jetzt sage: Gut gemacht, da freuen sich dann die anderen Kunden, auch wenn mir meine Abläufe um die Ohren fliegen.

Aber komm, was solls. Wir kennen JTL seit Jahr und Tag. Es ist immer so gewesen, es wird immer so bleiben.
Ganz offenbar ist das "Kunden-Ping-Pong" gewollt.
Wenn es geht, lässt man die Finger von Updates, oder man muß sie nehmen wie sie sind, was gefährlich und teuer werden kann.

 

[Enrico W.]

Auch wenn es aus eurer Sicht (verständlicherweise) gerade anders aussieht: Ich möchte Euch bitten, beim Thema zu bleiben und Unterstellungen und Vermutungen wie z.B. "keiner macht sich Gedanken" etc. zu unterlassen.
Es gibt Gründe für Entscheidungen und oft ist es zwangsläufig notwendig, dass man irgend einen Tod stirbt, denn ALLEN kann man es nie recht machen. Manchmal ist es auch die Entscheidung zwischen Pest und Cholera. Und dass man manchmal auch die falschen Entscheidungen trifft liegt in der Natur der Sache. Nur wer nicht arbeitet macht keine Fehler.

Daher mein Wunsch:
Bitte beachtet dazu unsere Forumregeln.
https://forum.jtl-software.de/help/terms/

Aus gegebenem Anlaß möchte ich das noch mal klar stellen: Jegliche Diskussionen, die nicht das ursprüngliche Thema - also den Workflow - behandeln, werden moderiert - d.h. im Zweifelsfall gelöscht. Beachtet dazu die Forumregeln:

Was wir nicht dulden​

Unangemessenes Verhalten: Beleidigungen, Belästigungen, Unterstellungen und Vorwürfe werden nicht toleriert.

Gerüchteküche
Vermutungen und Verbreitung von Gerüchten sind weder förderlich für die Community noch für das Wissen, dass wir mit diesem Forum einer breiten Masse zugänglich machen möchten.

Schwarzmalerei
Kontinuierliche Beschwerden und Nörgelei wirken sich schnell negativ auf den Grundton einer Gemeinschaft aus. Da wir eine positive und konstruktive Wissensplattform für JTL-Nutzer bieten wollen, bitten wir Euch, auf eine konstruktive und positive Grundhaltung innerhalb des Forums zu achten.

Anprangern und Fingerzeigen
Bitte seht vom Fingerzeigen auf andere User, aber auch Dritte ab. Solltet Ihr Klärungsbedarf oder Probleme mit einem anderen User haben, kommuniziert dies bitte mit privaten Nachrichten.

Eigenwerbung
Verzichtet auf Eigen-Promotion – das Forum dient nicht als Medium für Eigenwerbung und SPAM. Beiträge dieser Art werden umgehend gelöscht.