Blog

Shipment Order (zlecenie wysyłki wewnętrznej) pozwala zlecić i wykonać wewnętrzny ruch towaru między lokalizacjami i magazynami zdalnymi w tej samej spółce. Strona About Shipment Order z dokumentacji 25R2 podaje cztery scenariusze: lokalizacja do lokalizacji, lokalizacja do magazynu zdalnego, magazyn zdalny do lokalizacji i magazyn zdalny do magazynu zdalnego. Dodaje, że ruch z udziałem magazynu zdalnego może odbywać się w jednej lokalizacji albo między lokalizacjami.

Wykonanie przebiega przez procesy przesyłki i przyjęcia. Według tej strony Shipment Order obsługuje inventory part, no part i non-inventory part, ale nie obsługuje ręcznego tworzenia non-inventory part. Tranzyt i transakcje magazynowe opisane niżej dotyczą inventory part; dla no part i non-inventory part ruch zaczyna się od przyjęcia i transakcji magazynowych nie ma. Wątek społeczności z tagiem 21R1 opisuje Shipment Order jako funkcję wprowadzoną w tym wydaniu, więc w starszym wydaniu jej nie będzie.

Magazyn zdalny (Remote Warehouse) to według strony Remote Warehouse z 25R2 magazyn niezwiązany ściśle z lokalizacją pod względem geograficznym, który ma inny adres niż magazyn centralny. Dokumentacja podaje dwa typowe zastosowania: magazyn mobilny, na przykład samochód serwisowy, oraz magazyn pod innym adresem, który nadal należy do lokalizacji, także tymczasowy, założony u klienta albo na czas projektu.

Shipment Order ma nagłówek i linie, a oba mają jeden z pięciu statusów: Planned, Released, In Progress, Closed albo Cancelled. Zlecenie startuje jako Planned, po zwolnieniu do realizacji staje się Released, w trakcie przesyłki ma status In Progress, a kończy jako Closed, gdy wszystko zostanie przyjęte na stan.

• Nagłówek: wanted receipt date (jest domyślna dla linii), nadawca i odbiorca, czyli lokalizacja albo magazyn zdalny, oraz dane dostawy: ship via, forwarder, shipment type i lead times.
• Linie: części i ilości do przesunięcia. Daty są liczone wstecz od wanted receipt date na podstawie lead times i da się je nadpisać.
• Rezerwacja: dla inventory part rezerwujesz ręcznie na linii, a do Shipment Order można zastosować availability control.

Drugi sposób startu to stan magazynowy. Dokumentacja opisuje opcję Initiate move with Shipment Order from Inventory, która dla części lub jednostek obsługowych (handling units) leżących już na stanie zakłada nowe zlecenie z zarezerwowanym towarem. Działa to dla lokalizacji typu picking, arrival i QA. Gdy ruch zaczyna się z lokalizacji arrival lub QA, na linii zapisuje się przyjęcie zakupu (purchase order receipt), wybrana ilość schodzi z tego przyjęcia, a po przyjęciu Shipment Order wraca do przyjęcia zakupu w nowej lokalizacji. Przydaje się, gdy towar przyjechał pod jeden adres, a właściwe przyjęcie ma nastąpić pod innym.

Zwolniony Shipment Order łączy się z nową lub istniejącą przesyłką (shipment) i od tego miejsca proces wydania jest standardowy: rezerwacja, lista kompletacyjna, kompletacja, pakowanie w jednostki obsługowe, dostawa, wydruk dokumentu dostawy i wysłanie awiza (dispatch advice). Połączenie powstaje automatycznie przy zwolnieniu, poleceniem na stronie przeglądu albo ręcznie z zakładki dostępnych linii na przesyłce, przy czym dwie pierwsze metody respektują reguły typu przesyłki. Jeśli na co dzień pracujesz ze stroną wydania, zajrzyj do artykułów Zaawansowane strategie kompletacji w IFS Cloud i Skonsolidowane wysyłki.

W chwili dostawy inventory part jest w transporcie i można go śledzić. Dokumentacja wylicza, co widać w tranzycie: numer części, partię lub numer seryjny, ilość, nadawcę i odbiorcę, jednostki obsługowe, w które towar jest zapakowany, oraz typ własności, właściciela i jego nazwę. Dopisuje, że to ta sama obsługa internal order transit, której IFS używa dla zamówień wielolokalizacyjnych (multi-site).

Po dotarciu towaru przejmuje proces przyjęcia: Register Arrival, odbiór przychodzącego awiza jako części lub jednostek obsługowych, Manage Receipt in Arrival/QA i wreszcie Move into Stock albo odłożenie na miejsce (putaway).

Dostawa i przyjęcie zapisują sparowane transakcje magazynowe. Strona 25R2 podaje takie kody:

• W obrębie jednej lokalizacji: SHIPODWHS- przy dostawie do magazynu i SHIPODWHS+ przy przyjęciu z magazynu.
• Między lokalizacjami jednej spółki: SHIPODSIT- przy dostawie i SHIPODSIT+ przy przyjęciu, a przy dostawie dodatkowo transakcja INTORDTR.
• Cofnięcie dostawy: UND-SHPODW w obrębie lokalizacji, UND-SHPODS między lokalizacjami i UNINTORDTR w przypadku międzylokalizacyjnym.

Kody pochodzą ze strony dokumentacji, nie z systemu, który sam testowałem, więc zanim zbudujesz na nich raport albo filtr, sprawdź je w swoim wydaniu.

Jedno ustawienie likwiduje ten odstęp w całości. Gdy typ przesyłki ma włączone Automatic Receipt, polecenie Delivery na przesyłce uruchamia też przyjęcie i zamyka Shipment Order. Dla magazynu zdalnego wymaga to Default Receive Case ustawionego dla inventory part wraz z pasującą lokalizacją domyślną oraz klasy komunikatu DESADV na poziomie spółki, bo przeniesienie niesie awizo. Dokumentacja podaje jako przykład odbiór do magazynu zdalnego w samochodzie serwisowym.

Shipment Order jest zleconym ruchem towaru, więc planowanie traktuje go jednocześnie jako popyt i jako podaż. Według dokumentacji popyt to ilość z zamówienia minus ilość wysłana, z terminem w planned due date. Podaż to ilość z zamówienia minus ilość, która dotarła, z terminem w planned receipt date. Towar, który dotarł i czeka w Arrival/QA, liczy się jako podaż z uwzględnieniem lead times w arrival lub QA.

To samo zlecenie może więc pojawić się jako podaż i jako popyt, gdy ruch odbywa się w jednej lokalizacji, z różnymi datami, bo między nimi mieści się lead time. Te elementy uwzględniają zakładki Inventory Part Availability Planning i Availability Check of Shipment Order, a także propozycje zamówień (Order Proposal), MRP i Master Scheduling. Dokumentacja zaznacza również, że Shipment Order może być popytem i podażą jeszcze przed pojawieniem się zapasu, czego nie robi Transport Task.

Magazyn zdalny można wyłączyć z bilansowania (not nettable), nadając mu domyślny part availability control ID, który nie podlega bilansowaniu. Materiał jest wtedy przypisany do tego magazynu i nie stanowi podaży ani popytu poza nim. Dokumentacja podaje jako przykład samochód serwisowy z materiałem przeznaczonym na nadchodzące zlecenia. Szerszy kontekst planowania wielolokalizacyjnego znajdziesz w artykule Rozproszona realizacja zamówień klientów.

Trzy narzędzia różnią się tym, czy ma w nich miejsce krok przesyłki i przyjęcia, czy towar musi już leżeć na stanie i jakich danych podstawowych wymagają. Tabela korzysta wyłącznie ze stwierdzeń ze stron 25R2: About Shipment Order, Distribution Orders i Create Transport Task. Transport Task to zadanie transportowe, czyli przesunięcie zapasu wewnątrz magazynu, a Distribution Order to handel wewnętrzny między lokalizacjami.

Strona o Shipment Order wylicza też, czego nie obsługuje: towaru konsygnacyjnego i części będących własnością dostawcy (Consignment Stock, Supplier Owned Parts), ręcznego tworzenia non-inventory part oraz ruchu między spółkami. Gdy potrzebujesz tego ostatniego, udokumentowaną drogą jest Distribution Order, którego mechanikę opisuje wspomniany wyżej artykuł po angielsku.

Dwa wątki z IFS Community opisują dwa problemy konfiguracji. To pojedyncze zgłoszenia z konkretnych wydań, więc traktuj je jako powód do testu, a nie jako stałą regułę.

• Przyjęcie do lokalizacji wewnątrz magazynu zdalnego. W wątku z tagiem 23R2 użytkownik wysłał towar z magazynu zdalnego do lokalizacji i chciał przyjąć go w lokalizacji magazynu zdalnego należącego do tej lokalizacji. Magazyny zdalne nie pojawiały się na liście wyboru przy przyjęciu Shipment Order, choć na liście przy zamówieniu zakupu były. Odpowiedź oznaczona jako najlepsza wyjaśnia, że odbiorca Shipment Order, lokalizacja albo magazyn zdalny, jest traktowany jako osobny adres, pod którym towar ma zostać przyjęty. Dostawa wprowadza towar do Inventory Part in Internal Order Transit z nadawcą i odbiorcą, więc przyjęcie musi się z nimi zgadzać. Druga odpowiedź w tym samym wątku twierdzi, że to nie kwestia parametryzacji, i podpowiada modyfikację listy wyboru dla tego szczególnego przypadku. Sprawdź zachowanie w swoim wydaniu.
• Obowiązkowe warunki dostawy. W starszym wątku użytkownik zakładał Shipment Order ze stanu magazynu zdalnego do lokalizacji w tej samej spółce i dostał błąd, że nie zdefiniowano warunków dostawy (delivery terms). Odpowiedź cytuje opis pola: źródło wartości domyślnych zależy od typów nadawcy i odbiorcy. Gdy oba końce to lokalizacje, jest to Supply Chain Matrix for Site, a gdy odbiorcą jest magazyn zdalny, zakładka Remote Warehouse tego magazynu. Dla ruchu z magazynu zdalnego do lokalizacji opis podaje „nie dotyczy”, a zakładka Company, Address, Supply Chain Information jest wymieniona jako dodatkowe źródło, gdy żadna wartość domyślna nie została pobrana, a magazyn zdalny powstał automatycznie z Work Task. Autor wątku, którego ruch był właśnie przypadkiem z magazynu zdalnego do lokalizacji, potwierdził, że uzupełnienie informacji o łańcuchu dostaw spółki usunęło błąd. Wątek nie podaje wydania.

W obu przypadkach poprawka leży w danych podstawowych, nie w samym zleceniu. Warto to sprawdzić przed startem produkcyjnym, bo objaw wychodzi akurat wtedy, gdy samochód czeka pod magazynem.

Towar dostarczony na Shipment Order i nigdy nieprzyjęty to wyjątek operacyjny: opuścił lokalizację nadawcy, leży w internal order transit i nie jest dostępny w żadnej lokalizacji. Dokumentacja daje do tego sygnały. Zlecenie ma status In Progress, dopóki wszystko nie zostanie przyjęte, element podaży niesie planned receipt date, a widok tranzytu pokazuje, co wciąż jest w transporcie, wraz z nadawcą i odbiorcą.

Ten widok może przeglądać człowiek co rano. Tę samą kontrolę można uruchomić jako planowy odczyt tych rekordów w porównaniu z planned receipt date i wysyłać spóźnione pozycje do osób, które mogą ponaglić przewoźnika albo rampę odbiorczą. Tak działa monitoring wyjątków w ogóle: dane już są w IFS, a zadanie polega na odczytaniu ich według harmonogramu i powiadomieniu właściwej osoby, zanim planista zauważy dziurę na liście stanów. Która projekcja udostępnia rekordy tranzytu i Shipment Order w Twoim wydaniu, trzeba potwierdzić, zanim zbudujesz taką kontrolę.

Pakiet Automatyzacji SCM opiera się na tej zasadzie: planowy odczyt danych IFS tylko do odczytu przez OData, który zamienia wyjątki w alerty. Nie twierdzę, że ma gotową kontrolę towaru w tranzycie, a to, czy pasuje do Twojego środowiska, ustala się na rozmowie o zakresie. W IFS nie instalujemy żadnego obiektu, więc aktualizacja wydania nie zostawia po Twojej stronie niczego naszego do ponownego przetestowania, a zgodność z nowym wydaniem sprawdzamy my w ramach abonamentu.

Umów 30-minutową rozmowę Zobacz Pakiet Automatyzacji SCM

O pracy z wieloma lokalizacjami szerzej piszę na stronie konsultingowej (po angielsku): Multi-Site IFS Cloud Implementation oraz Flexible Reservations.

• Shipment Order, dokumentacja IFS Cloud 25R2
• Remote Warehouse, dokumentacja IFS Cloud 25R2
• Distribution Orders, dokumentacja IFS Cloud 25R2
• Create Transport Task, dokumentacja IFS Cloud 25R2
• Shipment, dokumentacja IFS Cloud 25R2
• Wątek IFS Community: Receiving shipment order (IFS Cloud 23R2)
• Wątek IFS Community: Shipment Order - Stock Movement from Remote Warehouse to Site
• Wątek IFS Community: Shipment Order in the new IFS 21R1

Dokumentację czytano w wydaniu 25R2. Zachowanie może zmieniać się między wydaniami, więc sprawdź strony dla wydania, z którego korzystasz. Odpowiedzi w społeczności to wypowiedzi pojedynczych użytkowników, nie dokumentacja IFS. Źródła są po angielsku.

Dariusz Myśliwiec: 18 lat praktyki z IFS, obecnie z IFS Cloud. IFS Certified Associate Consultant. PRINCE2® 7. Niezależna praktyka z siedzibą w Krakowie, prowadzona zdalnie dla firm w Europie i poza nią. Rozmawiasz z konsultantem, który to buduje, nie z działem sprzedaży.

Wybrani klienci z mojej pracy z IFS: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.

IFS jest zarejestrowanym znakiem towarowym IFS AB; ta praktyka nie jest powiązana z IFS AB.