Automatyczny Reschedule w VL02N

[Fox]

Witam,
Po utworzeniu dostawy zmieniane są daty transportu i dostawy do klienta. W momencie pobrania materiałów, daty które były zaplanowane na np. miesiąc do przodu, automatycznie są zmieniane przez system po pobraniu. Poniżej przykład. Czy ktoś wie dlaczego tak się dzieje?
W załączeniu screeny obrazujące zmianę.

Pzdr
Rafał

[mrcb]

Sprawdź ustawienia parametru ponownego harmonogramowania na typie dostawy TVLK-NEUTE i dodatkowo rzuć okiem na notę 2180337 - Actions that trigger a new scheduling, która opisuje różne dziwne przypadki zmiany harmonogramu dostawy. (np. w momencie potwierdzania zlecenia magazynowego tworzącego podział partii w dostawie).

pozdr.m.

[dominik.tylczynski]

W Twoim przypadku harmonogram dostawy jest zmieniany po potwierdzeniu zleceń przeniesienia na pobranie dostawy:

Deliveries:
4. Confirming a transfer order (Warehouse Management). Please check SAP note 530701.

Z punktu widzenia procesu logistycznego, moim zdaniem taka zmiana harmonogramu ma sens. Picking był zaplanowany na 10.05.2024. Z jakiegoś powodu zdecydowałeś o uruchomieniu kompletacji ok. 2 miesiące wcześniej. Zatem logicznie powinieneś towar wysłać te 2 miesiące wcześniej i dotrze on do odbiorcy również z tak dużym wyprzedzeniem. W magazynach zwykle nie ma zbyt dużo miejsca w strefie załadunku. Stąd przetrzymywanie tam dostaw skompletowanych z wyprzedzeniem nie ma uzasadnienia.

[mrcb]

Z punktu widzenia procesu logistycznego, moim zdaniem taka zmiana harmonogramu ma sens. Picking był zaplanowany na 10.05.2024. Z jakiegoś powodu zdecydowałeś o uruchomieniu kompletacji ok. 2 miesiące wcześniej. Zatem logicznie powinieneś towar wysłać te 2 miesiące wcześniej i dotrze on do odbiorcy również z tak dużym wyprzedzeniem. W magazynach zwykle nie ma zbyt dużo miejsca w strefie załadunku. Stąd przetrzymywanie tam dostaw skompletowanych z wyprzedzeniem nie ma uzasadnienia.

Nie sprawdzałem, ale wg wspomnianej noty, zmiana harmonogramu dostawy przez TO następuje tylko przy tworzeniu nowych pozycji (np. podział partii). Jeżeli faktycznie tak jest, to ja tu bardziej widzę babola, niż celowe działanie systemu.

pozdr.m.

[dominik.tylczynski]

Nie sprawdzałem, ale wg wspomnianej noty, zmiana harmonogramu dostawy przez TO następuje tylko przy tworzeniu nowych pozycji (np. podział partii).

Nota 2180337 stwierdza, że harmonogramowanie jest wykonywane ponownie po potwierdzeniu zlecenia przeniesienia. Nie mówi nic o podziale partii.

Natomiast nota 530701 mówi, że to harmonogramowanie jest wykonywane niepoprawnie, jeśli pozycje podziału partii są generowane w wyniku potwierdzenia zlecenia przeniesienia i koryguje ten błąd. Nota nie precyzuje jednak na czym dokładnie polega tutaj problem z ponownym harmonogramowaniem.

Nadal uważam, że ponowne harmonogramowanie przy wcześniejszym pobraniu ma sens - skoro dostawa została pobrana z wyprzedzeniem, to również z wyprzedzeniem powinna zostać załadowana i z wyprzedzeniem dotrze do odbiorcy. To właśnie odzwierciedlają daty po ponownym harmonogramowaniu.

[Fox]

Zgadzam się, że to prawidłowe działanie systemu i tak powinien działać proces, ale co w momencie kiedy magazyn zaczyna pobierać częściowo dostawę, ponieważ ma wolne capacity a reszta towaru zejdzie z produkcji za tydzień. W poprzedniej wersji harmonogramowanie to nie było robione. System zaczął zmieniać daty automatycznie po upgrade do EC6.
Szukałem jakiś not, które by to wyłączyły, ale niestety nic nie znalazłem.

Rafał

[dominik.tylczynski]

W poprzedniej wersji harmonogramowanie to nie było robione. System zaczął zmieniać daty automatycznie po upgrade do EC6.

A może w poprzedniej wersji miałeś ponowne harmonogramowanie wyłączone jakimś rozszerzeniem czy modyfikacją standardowego kodu i ta modyfikacja została skasowana podczas upgrade'u?

[mrcb]

Zgadzam się, że to prawidłowe działanie systemu i tak powinien działać proces...
...Szukałem jakiś not, które by to wyłączyły, ale niestety nic nie znalazłem.

Z całym szacunkiem, ja nie uważam, że tak powinien działać system.

Oczywiście mogę sobie wyobrazić sytuację o której wspomniał Dominik, że przygotowaną dostawę należy jak najwcześniej wypchnąć z magazynu (kojarzy mi się z ecommerce), ale bardziej przemawia do mnie inny przypadek, że dostawę kompletujemy wcześniej, bo transport jest planowany raz/dwa razy w tygodniu i dostawy przygotowujemy z wyprzedzeniem pod te transporty i nie widzę tu konieczności aktualizacji harmonogramu dostaw. Fajne podejście niesie ze sobą ASR (TM) gdzie proces wydań może być realizowany w wariancie transport lub warehouse driven, ale tu mamy jasny podział, który obszar rozpoczyna pierwszy i wiemy czego się spodziewać. W Twoim przypadku, zmiana harmonogramu dzieje się nieoczekiwanie, po wykonaniu operacji magazynowej, być może częściowej, bez żadnej kontroli.

Czy udało Ci się zidentyfikować przyczynę ponownego harmonogramowania dostawy?
Czy faktycznie jest to potwierdzenie zlecenia przeniesienia na pobranie, które generuje dodatkową pozycję partii w dostawie? Jeżeli tak, to sprawdź notę 530701 Confirmation of transfer order causes change to shipping deadlines, która opisuje, że harmonogramowanie jest uruchamiane podczas tworzenia pozycji dostawy, w wyniku potwierdzenia TO generującego podział partii.
Nota jest modyfikacją, która nie jest ujęta w standardowym kodzie, dlatego faktycznie może być nadpisana podczas upgrade wersji lub podnoszenia service pack'ów.

pozdr.m.