Gelöst gesperrtes WMS Lager blockiert Einkaufsliste

[akBenutzer]

Hallo,

ich habe entdeckt, dass Artikel, die in einem gesperrten WMS-Lager enthalten sind ("Für verfügbaren Bestand sperren"), nicht auf die Einkaufsliste kommen.

Ist dieses Verhalten gewollt? Kann ich dies irgendwie umgehen, da diese Artikel doch auf die Einkaufsliste sollen, da ja kein verfügbarer Bestand vorhanden sein soll?

 

[JTL_fwenzl]

Die Option "Für verfügbaren Bestand sperren" sollte keine Auswirkungen auf die Einkaufsliste haben.
Bei der Einkaufsliste ist ja auch noch nicht klar in welches Lager der Artikel evtl. mal eingelagert wird.

In meiner Version scheint das auch zu funktionieren. Liegt evtl. an einer anderen Einstellung.

Gruß,
Frank

 

[akBenutzer]

@JTL-fwenzl Hallo Frank,

ich habe das Gefühl, du gehst nicht ganz auf meine Fragestellung ein. Entweder ich verstehe dich falsch oder umgekehrt^^ Oder ich habe die Fragestellung/ das Problem falsch erläutert.

Die Option "Für verfügbaren Bestand sperren" sollte Auswirkungen auf die Einkaufsliste haben, da:
Bei der Option "Fehlbestand des Auftrags..." wird ja nach dem Fehlbestand geguckt und dieser dann auf die Einkaufsliste gesetzt. Da der Artikel aber sozusagen "nicht vorhanden" ist, da er ja gesperrt in dem einen Lager vorliegt, sollte der Artikel bestellt werden müssen/können.

Es ist ja egal in welches Lager der Artikel gebucht wird. Solange kein Bestand da ist, muss dieser Artikel bestellt werden.

Gruß
Artur

 

[Stetto]

Hi Artur,

es dürfte hier keinen Unterschied zwischen dem Lagerbestand in einem Wawi-Standardlager und dem Lagerbestand in einem WMS-Lager geben.

Falls es reproduzierbar doch einen Unterschied gibt oder das Problem ebenfalls mit einem Wawi-Standardlager auftritt, wäre das ein Thema für das JTL-Wawi Unterforum: https://forum.jtl-software.de/forums/arbeitsablaeufe-in-jtl-wawi.196/

 

[JTL_fwenzl]

Hallo Artur,

ja, ich habe eher auf den Titel geantwortet.

Die Option "Für den verfügbaren Lagerbestand sperren" blockiert die Funktion der Einkaufsliste NICHT.
Bedeutet, die Einkaufsliste sollte normal funktionieren.

Wenn ein Lager (mit Bestand) gesperrt ist und in keinem anderen Lager Bestand des Artikels da ist und man wählt bei der Einkaufsliste
"fehlenden Auftragsbestand", dann wird die komplette Auftragsmenge auf die Einkaufsliste gesetzt
So als wäre der Bestand in allen Lagern 0, das gesperrte Lager wird also ignoriert.

Und die Einkaufsliste ist ja auch keine ausgefuchste Bestellplanung, sondern eher ein Merkzettel.

Aber das Ganze wäre, wie Stephan schon schrieb, nur dann ein WMS Problem, wenn sich WMS- und Standardlager inkonsistent verhalten würden.

Gruss,
Frank

 

[akBenutzer]

Danke für die bisherigen Antworten. Die Hypothesen/Fakten die Ihr aufgestellt habt sind richtig. Ich stelle auch keinen Unterschied zwischen Standardlager und WMS-Lager fest. Was ich sage ist: Die Sperre der Artikel für den verfügbaren Bestand funktioniert nicht.

Angenommen es kommt ein Auftrag rein über einen Artikel
Lieferantenbestand = 10 ;
WMS Lager1: 0;
WMS Lager2: 1; (Hier ist der verfügbare Bestand gesperrt)

Es wird sogar im Auftrag am Artikel der Fehlbestand von 1 gesetzt. Wenn man jetzt per Workflow den Artikel auf die Einkaufsliste setzen möchte, SOLLTE dieser doch auf die Einkaufsliste gehen, da wir keinen Artikel auf Lager haben.

Dies geschieht nicht! Der Artikel geht nicht auf die Einkaufsliste.

 

[Stetto]

Deinem Beispiel ist "Lieferantenbestand" zu entnehmen. Hast du die globale Option aktiviert "Lieferantenbestand zum eigenen Bestand hinzuaddieren"? Falls ja, dürfte dadurch das Problem entstehen.

Der eigentliche Bug, falls reproduzierbar, dürfte dann weder WMS, noch Lagerbestand, noch Bestellvorschläge/Einkaufsliste sein, sondern eine DotLiquid-Variable in den JTL-Workflows, die den Lieferantenbestand fälschlicherweise als eigenen verfügbaren Bestand berücksichtigt.

Du könntest auch die eingestellten Bedingungen in deinem JTL- Workflow prüfen. Für Lagerbestand gibt es einige Variablen, die teilweise sehr unterschiedlich funktionieren - aber auch hierfür haben wir eine Fachabteilung, mit einem eigenen Unterforum - oder einfach ein JTL-Workflow- Ticket über das JTL-Kundencenter erstellen.

Für den WMS-Bereich setze ich den Thread deshalb auf erledigt.

 

[akBenutzer]

Ja die Option "zum eigenen Bestand hinzuaddieren" ist angehakt. Dies hat aber noch nie! Probleme verursacht. Es ist das WMS-Lager welche die Sperre nicht durchführt:

Ausganslage 1:
Lieferantenbestand = 10 ;
WMS Lager1: 0;
WMS Lager2: 0; (Hier ist der verfügbare Bestand gesperrt)
-> Artikel kommt auf die Einkaufsliste = Alles in Ordnung

Ausganslage 2:
Lieferantenbestand = 10 ;
WMS Lager1: 1;
WMS Lager2: 0; (Hier ist der verfügbare Bestand gesperrt)
-> Artikel kommt nicht auf die Einkaufsliste = Alles in Ordnung

Ausganslage 3:
Lieferantenbestand = 10 ;
WMS Lager1: 0;
WMS Lager2: 1; (Hier ist der verfügbare Bestand gesperrt)
-> Artikel kommt nicht auf die Einkaufsliste = Fehler/Bug -> Kein erwartetes Ergebnis

An den Workflows kann es auch nicht liegen. Wenn man nämlich versucht mit der Ausgangslage 3 manuell einen Artikel auf die Einkaufsliste zu setzen, gibt es bei der Option "Fehlbestand des Auftrags" keinen Vorschlag für die Einkaufsliste.

Ich danke dennoch für die Hilfe. Ich eröffne ein Ticket.

 

[Stetto]

So - und wenn nun in Beispiel 3 das Warenlager ein Standardlager oder Fulfillment-Lager oder FBA-Lager ist, tritt das Problem nicht auf? Ja, dann ist das WMS-Lager Schuld, "weil es die Sperre nicht durchführt".

Da ich davon ausgehe, dass es jeden Lagertyp betrifft, würde ich mich wiederholen mit meiner vorherigen Aussage Wäre dann ein Thema für das Team "Lagerbestand/Datenbank", wenn dort eine Berechnung defekt ist, sind JTL-Workflows, Variablen, WMS automatisch mit betroffen.

Danke dir für das Ticket, konntet ihr den Fehler denn schon nachstellen oder gar eine Lösung finden?

 

[akBenutzer]

So - und wenn nun in Beispiel 3 das Warenlager ein Standardlager oder Fulfillment-Lager oder FBA-Lager ist, tritt das Problem nicht auf? Ja, dann ist das WMS-Lager Schuld, "weil es die Sperre nicht durchführt".

Ja so ist es.

Mit der neuen Wawi-Version 1.4.27.3 tritt dieser Fehler nicht auf.

Ich hatte vor ein Ticket zu eröffnen, kam aber noch nicht dazu. Da wir aber nun ein Wawi-Update 1.3.21.0 -> 1.4.27.3 gemacht haben, hat sich das für uns erledigt.

Closed.