Gelöst Wer nutzt die neue FiFo-Funktion aus JTL-Wawi 1.2 und wie ist euer Feedback dazu?

[Stetto]

Wer nutzt die neue FiFo-Funktion aus JTL-Wawi 1.2 und wie ist euer Feedback dazu?

 

[Jörg Westmeier]

Ich bitte um Entschuldigung, aber verstehe die Frage nicht. Wir liefern grundsätzlich die ältesten Aufträge zuerst und nun die Frage:
Kann man das in JTL einschalten und wenn ja wie ?
Geht es ohne ein zugekauftes Modul oder welches muss zugekauft werden? (Retouren nur mit Packtisch möglich)

 

[IchBinEs]

Du kannst es unter Globale Einstellungen und da unter Vorgänge aktivieren.
Und nein es kostet nichts EXTRA

 

[Stetto]

Hi Jörg, für weitere Infos siehe auch hier:
https://blog.jtl-software.de/jtl-wawi-1-2-fifo/

 

[Jörg Westmeier]

Na, da kann ich ja nur Danke sage, das ich das nun JTL überlassen kann und nicht mehr händisch machen muss.

Ein bescheidener und glücklicher Nutzer

 

[elcheffe]

FIFO, LIFO,... völlig egal.

Solange es nicht möglich ist einzelne Aufträge "abzukoppeln" hat man doch ständig das Problem, dass große Aufträge (mit langer Lieferzeit) den Lagerbestand blockieren.

 

[Stetto]

Du kannst bei einem großen Auftrag die Priorität verringern oder bei einem normalen Auftrag die Priorität erhöhen.

Kommen deine Aufträge also immer mit Prio 0 in die Wawi und du setzt den Großauftrag auf Prio -5, werden die kleinen Aufträge immer direkt verschickt und der Bestand nicht blockiert.

Kommt dann die Warenlieferung für die Großbestellung änderst du die Prio einfach entsprechend und der große Auftrag wird verschickt.

 

[elcheffe]

Du kannst bei einem großen Auftrag die Priorität verringern oder bei einem normalen Auftrag die Priorität erhöhen.

Kommen deine Aufträge also immer mit Prio 0 in die Wawi und du setzt den Großauftrag auf Prio -5, werden die kleinen Aufträge immer direkt verschickt und der Bestand nicht blockiert.

Kommt dann die Warenlieferung für die Großbestellung änderst du die Prio einfach entsprechend und der große Auftrag wird verschickt.

Nö. Bekomme ich so nicht hin!? Aber nochmal etwas ausführlicher, damit wir nicht aneinander vorbei reden:

Lagerbestand: 1000 Stk.
Bestellung vom einem Kunden: 10000 Stk.
Überverkäufe ermöglichen: NEIN

Jetzt ist der Lagerbestand von 1000 Stk. im Shop so lange blockiert, bis die 10000 Stk. für den einen Kunden nach 3 Mon. eingehen. Von dem Lagerbestand könnte aber theoretisch die ganze Zeit abverkauft werden, wenn man die Eine (10000 Stk. Bestellung) abkoppeln könnte.

Da nützt mir hinten heraus eine Automatisierung mit FIFO gar nichts, wenn vorne über den Shop gar keine Bestellungen eingehen können.

 

[3po]

Na wenn Du mehr verkaufen willst als Du hast muss Du logischerweise auch Überverkäufe auf ja setzen

 

[Stetto]

Ok, so sieht das natürlich wieder ganz anders, behandelt aber ein grundsätzlich anderes Thema! Eventuell wird es hier mit JTL-Wawi 1.4 oder 1.5 neue Möglichkeiten geben. Die Details der Aufträge, Angebote, Rechnungen und Rechnungskorrekturen werden zur Zeit neu gemacht, dabei werden auch zahlreiche Kundenwünsche aus der Vergangenheit einfließen.

 

[Freaky]

Für uns leider unbrauchbar. Haben FiFo schon in der Pilotphase wieder deaktiviert und unseren Workflow wieder laufen lassen.

Wir brauchen FiFo auf Artikelebene. Wenn ein Kunde telefonisch einen Artikel in eine alte vorhandene Bestellung hinzufügt, wird der Artikel für ihn reserviert, was aber nicht sein sollte.
Das selbe wenn Aufträge zusammengefasst werden.

Das ist für uns leider immer noch ein mega aufwendiges Thema.

 

[Stetto]

Warum legt ihr dann nicht einfach eine neue Bestellung an?

Alte Bestellung = erledigt. Rechnung existiert eventuell schon. Dann sollte daran doch nichts mehr manipuliert werden?!

 

[Freaky]

Ja, die Kunden arbeiten ja immer knapp an der Versandkosten-Frei Grenze.
Wenn man einen Artikel hinzufügt, wäre die Bestellung versandfrei, bei einem kleinen Artikel in einem neuen Auftrag kämen jedoch wieder Versandkosten drauf.

Wir haben es immer wieder dass Artikel storniert werden, da sich der Erscheinungstermin verschiebt oder halt auch Artikel hinzugefügt werden, die ebenfalls nicht lieferbar sind.

 

[Stetto]

Klingt in meinem Kopf nun nicht nach einem Wawi-Problem

Wenn Artikel geändert werden müssen, weil nicht lieferbar, ist der Kunde halt knapp unter Versandkostenfrei, bekommt es aber trotzdem kostenlos zugeschickt. Senkt die Bürokratie, steigert so die Performance und die Zufriedenheit des Kunden - dieser kauft gerne wieder. Lüppt.

Also ich sehe durch diese manuellen Eingriffe jetzt keine "Bugs" in JTL-Wawi oder im integrierten Auftrags-FIFO.

 

[Freaky]

Ja, einen 5€ Artikel kann ich leider nicht kostenlos per versichertem Versand verschicken. Und da es da nicht nur um Ausnahmen geht, sondern dies ein großer Teil unseres Geschäftes ist, ist das für uns halt ein Problem.
Nein, ein Bug ist das nicht. Es ist halt kein "FiFo" sondern "Auftragsbasiertes FiFo".

Dass es Artikelbezogen natürlich viel mehr Programmieraufwand ist, ist mir schon klar. Aber als JTL vor 3-4 Jahren mal schrieb "FiFo ist mega aufwändig, deswegen wird es noch sehr lange dauern", hatte ich schon Hoffnung

Naja, wie dem auch sei, Ihr habt gefragt wie wir es finden, für uns ist es halt unbrauchbar

 

[Stetto]

Ja, es ist "Auftrags-FIFO" gemeint. Schon damals und heute wurde es umgesetzt.

Grundsätzlich wird aber immer die älteste Ware ausgebucht, sowohl in JTL-Wawi (standardmäßig, ältester Eintrag aus tWarenLagerEingang) als auch in JTL- WMS (optional über die Picklistenvorlage). Artikel-FIFO ist also sowieso schon drin.

Aus deinem Beispiel oben beschreibst du aber weder Artikel-FIFO, noch Auftrags-FIFO sondern fast schon Positions-FIFO - wenn ich dich richtig verstanden habe.

Kunde 1 - Auftrag 1
Pos 1 mit Artikel X
Pos 2 mit Artikel Y

Kunde 2 - Auftrag 2
Pos 1 mit Artikel Z

Jetzt ist Y nicht lieferbar und der Kunde nimmt alternativ Artikel Z - deiner Meinung nach sollte nun aber trotzdem Auftrag 2 zuerst ausgeliefert werden, weil dieser Artikel Z zuerst bestellt hat. Stattdessen wird Auftrag 1 verschickt, weil der Kunde zuerst bestellt hat. Korrekt?

 

[Freaky]

Jetzt ist Y nicht lieferbar und der Kunde nimmt alternativ Artikel Z - deiner Meinung nach sollte nun aber trotzdem Auftrag 2 zuerst ausgeliefert werden, weil dieser Artikel Z zuerst bestellt hat. Stattdessen wird Auftrag 1 verschickt, weil der Kunde zuerst bestellt hat. Korrekt?

Oh man, das wäre ein Traum

Momentan sperren wir halt über einen Workflow alles was Lagerbestand hat aber nicht verfügbar ist. Was telefonisch hinzubestellt wird, da sperren wir die Aufträge dann manuell.
Wenn ein Artikel einen Wareneingang hat, müssen wir die Aufträge halt manuell durchgehen und freischalten. Ist natürlich recht komplex, je mehr solcher Artikel es gibt, desto komplexer.
Für Teillieferungen, wovon der Kunde aber im schlimmsten Fall einen Artikel nicht bekommt, der lagernd ist, müssen wir diese Artikel erst im WMS in ein "Gesperrt" Regal umbuchen, dann teilliefern und den Artikel wieder zurück buchen.
Sehr aufwendig.

Boxen Kommissionierung würde da helfen, da wirklich alles reserviert werden würde, allerdings sammeln Kunden die Bestellungen im schlimmsten Fall über 1 Jahr, da bräuchte ich ein Boxenlager.
Zudem ändert sich die Kundenmeinung durch diesen Zeitraum natürlich hin und wieder, da müsste man nicht nur die Aufträge ändern, sondern auch noch die Boxen wieder stornieren/ändern.

 

[Stetto]

Das klingt schon sehr krass individuell und vor allem sehr kompliziert. Was verkauft ihr noch gleich, dass sich dieser Mehraufwand lohnt? Und die Lieferzeiten der Nachbestellungen sind so hoch, dass es keine andere Option gibt?
Und wieso will man Ware ein Jahr lang für einen Kunden reservieren? Das ist doch eure Lagerfläche und die kosten auch einen Haufen miete..

 

[Maekaey]

Mir ist erst aufgefallen dass JTL kein FIFO anwendet, als es als Neuerung für 1.2 bekannt gegeben wurde. Bevor 1.2 dann released wurde gab es aber dann tatsächlich 2 Fälle wo das fehlende fifo Probleme verursacht hatte. Wir haben aber insgesamt nur selten das Problem gehabt, dass FIFO nicht vorhanden war, aber die paar mal wo es vorgekommen ist sind jetzt ausgeschlossen.

Für uns funktioniert es tadellos und wir sind froh über die Neuerung

 

[dmc]

Wird verwendet und passt für uns wie implementiert.

Grüße