Przejdź do treści

© navision.pl | Opracowano na podstawie: Microsoft Learn (CC BY 4.0)

Szczegóły projektowania: przesunięcia w planowaniu

Zlecenia przesunięcia są również źródłem podaży podczas pracy na poziomie SKU. Podczas korzystania z wielu lokalizacji (magazynów) system uzupełniania SKU można ustawić na Przesunięcie, co oznacza, że lokalizacja jest uzupełniana przez przenoszenie towarów z innej lokalizacji. W sytuacji z większą liczbą magazynów może wystąpić łańcuch przesunięć. Dostawy do lokalizacji ZIELONY są przesyłane z ŻÓŁTY, dostawy do ŻÓŁTY są przesyłane z CZERWONY i tak dalej. Na początku łańcucha występuje system uzupełniania Zlec. prod. lub Zakup.

Example of transfer flow.

Uwaga

Ten artykuł używa nazw lokalizacji z wcześniejszej wersji firmy demonstracyjnej w Business Central. Te nazwy nie odpowiadają bezpośrednio lokalizacjom w bieżącej firmie demonstracyjnej. Zachęcamy do korzystania z artykułu w celu poznania lokalizacji, a nie jako instrukcji krok po kroku dotyczących korzystania z firmy demonstracyjnej.

Porównując następujące sytuacje, jest jasne, że zadanie planowania w drugiej z nich może stać się złożone:

  • Zamówienie podaży bezpośrednio odpowiada zamówieniu popytu
  • Zamówienie sprzedaży jest realizowane przez łańcuch przesunięć SKU

Jeśli popyt ulegnie zmianie, może to spowodować efekt domina w całym łańcuchu. Wszystkie zlecenia przesunięcia, a także zamówienie zakupu i zlecenie produkcyjne na przeciwnym końcu łańcucha, będą musiały zostać zaktualizowane w celu ponownego zrównoważenia popytu i podaży.

Example of supply/demand balance in transfers.

Dlaczego przesunięcie jest przypadkiem szczególnym?

Zlecenia przesunięcia są podobne do innych zamówień, takich jak zamówienia zakupu i zlecenia produkcyjne. Jednak za kulisami różnią się one.

Jedna różnica polega na tym, że wiersz przesunięcia reprezentuje zarówno popyt, jak i podaż. Część wychodząca, która jest wysyłana, stanowi popyt. Część przychodząca, która jest odbierana w nowej lokalizacji, stanowi podaż w tej lokalizacji.

Content of the Transfer Order page.

Gdy Business Central zmienia stronę podaży przesunięcia, musi dokonać podobnej zmiany po stronie popytu.

Przesunięcia są popytem zależnym

Relacja popytu i podaży jest podobna do komponentów w wierszach zleceń produkcyjnych. Różnica polega na tym, że komponenty w wierszach zleceń produkcyjnych znajdują się na następnym poziomie planowania i mają inny zapas. Dwie części przesunięcia znajdują się na tym samym poziomie dla tego samego zapasu.

Ważne podobieństwo polega na tym, że komponenty i przesunięcia są popytem zależnym. Popyt z wiersza przesunięcia jest podyktowany stroną podaży przesunięcia. Jeśli podaż ulegnie zmianie, popyt zostanie bezpośrednio zmieniony.

Jeśli elastyczność planowania nie jest ustawiona na Brak, wiersz przesunięcia nie powinien być traktowany jako niezależny popyt w planowaniu.

W procedurze planowania popyt przesunięcia powinien być brany pod uwagę dopiero po przetworzeniu strony podaży przez system planowania. Przed tym przetworzeniem rzeczywisty popyt nie jest znany. Sekwencja zmian jest ważna dla zleceń przesunięcia.

Sekwencja planowania

Poniższy obraz przedstawia przykład łańcucha przesunięć.

Example of simple transfer flow.

W tym przykładzie nabywca zamawia zapas w lokalizacji ZIELONY. Lokalizacja ZIELONY jest zaopatrywana poprzez przesunięcie z centralnego magazynu CZERWONY. Centralny magazyn CZERWONY jest zaopatrywany przez przesunięcie z produkcji w lokalizacji NIEBIESKI.

W tym przykładzie system planowania rozpoczyna od popytu nabywcy i przetwarza wstecz przez łańcuch. Popyty i podaże są przetwarzane dla jednej lokalizacji naraz.

Supply planning with transfers.

Kod poziomu przesunięcia

Kod poziomu przesunięcia SKU określa sekwencję, w której system planowania przetwarza lokalizacje.

Kod poziomu przesunięcia jest polem wewnętrznym. Pole jest obliczane i zapisywane w SKU podczas tworzenia lub modyfikowania SKU. Obliczenia są wykonywane dla wszystkich SKU dla danej kombinacji zapasu i wariantu zapasu. Obliczenie wykorzystuje kod lokalizacji i kod przesunięcia z, aby określić trasę do użycia dla SKU. Obliczenie zapewnia, że wszystkie popyty są przetwarzane.

Kod poziomu przesunięcia wynosi 0 dla SKU z systemem uzupełniania Zakup lub Zlec. prod. i wynosi -1 dla pierwszego poziomu przesunięcia, -2 dla drugiego itd. W przykładzie opisanym w poprzedniej sekcji poziomy wynosiłyby -1 dla CZERWONY i -2 dla ZIELONY, jak pokazano na poniższej ilustracji.

Content of SKU Card page.

Podczas aktualizowania SKU system planowania wykrywa, czy systemy uzupełniania SKU mają odwołania cykliczne.

Planowanie przesunięć bez SKU

W przypadku mniej zaawansowanych konfiguracji magazynowych można używać lokalizacji i wykonywać ręczne przesunięcia między lokalizacjami, nawet jeśli nie używa się SKU. Na przykład przesunięcie może obejmować zamówienie sprzedaży w tej lokalizacji. System planowania reaguje na zmiany popytu.

W przypadku ręcznych przesunięć system planowania analizuje zlecenia przesunięcia, a następnie planuje kolejność przetwarzania lokalizacji. Wewnętrznie system planowania używa tymczasowych SKU, które mają kody poziomu przesunięcia.

Transfer level code.

Jeśli istnieje kilka przesunięć do lokalizacji, pierwsze zlecenie przesunięcia określa kierunek planowania. Przesunięcia w przeciwnym kierunku są anulowane.

Zmiana ilości z rezerwacjami

Podczas zmiany ilości w podaży system planowania uwzględnia rezerwacje. Zarezerwowana ilość stanowi dolny limit określający, o ile można zmniejszyć podaż.

Podczas zmiany ilości w wierszu zlecenia przesunięcia należy pamiętać o dolnym limicie. Dolny limit to najwyższa zarezerwowana ilość z wierszy przesunięcia wychodzącego i przychodzącego.

Na przykład wiersz zlecenia przesunięcia na 117 sztuk jest zarezerwowany dla następujących wierszy:

  • Wiersz sprzedaży na 46
  • Wiersz zakupu na 24

Nawet jeśli strona przychodząca może mieć nadwyżkę podaży, nie można zmniejszyć wiersza przesunięcia poniżej 46.

Reservations in transfer planning.

Zmiana ilości w łańcuchu przesunięć

Oto przykład tego, co dzieje się po zmianie ilości w łańcuchu przesunięć.

Punktem wyjścia jest zrównoważona sytuacja z łańcuchem przesunięć zaopatrującym zamówienie sprzedaży na 27 w lokalizacji CZERWONY. Istnieje odpowiadające zamówienie zakupu w lokalizacji NIEBIESKI. Oba przesunięcia przechodzą przez lokalizację RÓŻOWY. Istnieją dwa zlecenia przesunięcia: NIEBIESKI-RÓŻOWY i RÓŻOWY-CZERWONY.

Changing the quantity in transfer planning 1.

Teraz planista w lokalizacji RÓŻOWY wybiera rezerwację dla zakupu.

Changing the quantity in transfer planning 2.

Rezerwacja zazwyczaj oznacza, że system planowania ignoruje zamówienie zakupu i popyt przesunięcia. Nie ma problemu, dopóki istnieje równowaga. Ale co się stanie, gdy lokalizacja CZERWONY zmieni zamówienie z 27 na 22?

Changing the quantity in transfer planning 3.

Gdy system planowania uruchomi się ponownie, powinien pozbyć się nadwyżki podaży. Jednak rezerwacja blokuje zakup i przesunięcie na ilości 27.

Changing the quantity in transfer planning 4.

Przesunięcie RÓŻOWY-CZERWONY zostało zmniejszone do 22. Część przychodząca przesunięcia NIEBIESKI-RÓŻOWY nie jest zarezerwowana, ale część wychodząca jest. Rezerwacja oznacza, że nie można zmniejszyć ilości poniżej 27.

Obliczanie czasu realizacji

Podczas obliczania terminu realizacji zlecenia przesunięcia uwzględniane są różne rodzaje czasu realizacji.

Następujące czasy realizacji są aktywne podczas planowania zlecenia przesunięcia:

  • Czas obsługi magazynu wychodzącego
  • Czas wysyłki
  • Przychodzący czas obsługi magazynu

W wierszu planowania następujące pola są używane do dostarczania informacji o obliczeniach:

  • Data wysyłki przesunięcia
  • Data początkowa
  • Data końcowa
  • Termin wymagalności

Data wysyłki wiersza przesunięcia jest wyświetlana w polu Data wysyłki przesunięcia. Data przyjęcia wiersza przesunięcia jest wyświetlana w polu Termin.

Daty początkowa i końcowa opisują rzeczywisty okres transportu.

Poniższy obraz przedstawia interpretację daty i godziny początkowej oraz daty i godziny końcowej w wierszach planowania dla zleceń przesunięcia.

Central date-times in transfer planning.

Przykład przedstawia następujące obliczenia:

  • Data wysyłki + Obsługa wychodząca = Data początkowa
  • Data początkowa + Czas wysyłki = Data końcowa
  • Data końcowa + Obsługa przychodząca = Data przyjęcia

Zapas czasu bezpieczeństwa

Pole Domyślny zapas czasu bezpieczeństwa na stronie Ustawienia produkcji i powiązane pole Zapas czasu bezpieczeństwa na stronie Kartoteka zapasu nie są uwzględniane w obliczeniach zleceń przesunięcia. Jednak zapas czasu bezpieczeństwa wpływa na cały plan. Zapas czasu bezpieczeństwa wpływa na zamówienie uzupełnienia (zakup lub produkcja) na początku łańcucha przesunięć. Jest to punkt, w którym zapasy zostały umieszczone w lokalizacji, z której będą przenoszone.

Elements of the transfer due date.

W wierszu zlecenia produkcyjnego Data końcowa + Zapas czasu bezpieczeństwa + Przychodzący czas obsługi magazynu = Termin.

W wierszu zamówienia zakupu Planowana data przyjęcia + Zapas czasu bezpieczeństwa + Przychodzący czas obsługi magazynu = Oczekiwana data przyjęcia.

Przeplanowanie

Podczas przeplanowania wiersza przesunięcia system planowania znajduje część wychodzącą i zmienia datę i godzinę.

Uwaga

Jeśli zdefiniowano czas realizacji, wystąpi przerwa między wysyłką a przyjęciem. Czas realizacji może składać się z wielu elementów, takich jak czas transportu i czas obsługi magazynu. Na osi czasu system planowania cofa się w czasie, równoważąc elementy.

Changing the due date in transfer planning.

Po zmianie terminu w wierszu przesunięcia należy obliczyć czas realizacji, aby zaktualizować stronę wychodzącą przesunięcia.

Numery seryjne i partie w łańcuchach przesunięć

Jeśli popyt używa numerów seryjnych lub partii i uruchomisz mechanizm planowania, utworzy on zlecenia przesunięcia. Aby uzyskać więcej informacji na temat tej koncepcji, zobacz Atrybuty zapasu. Jeśli jednak numery seryjne lub partie zostaną usunięte z popytu, zlecenia przesunięcia nadal będą używać numerów seryjnych lub partii, a planowanie je zignoruje (nie zostaną usunięte).

Powiązania zamówienie z zamówieniem

W tym przykładzie jednostka SKU BLUE jest skonfigurowana z zasadą ponownego zamawiania Zamówienie. Jednostki SKU PINK i RED mają zasadę ponownego zamawiania Partia na partię. Utworzenie zamówienia sprzedaży na 27 w lokalizacji RED prowadzi do łańcucha przesunięć. Ostatnie przesunięcie jest w lokalizacji BLUE i jest zarezerwowane z powiązaniem. W tym przykładzie rezerwacje nie są twardymi rezerwacjami utworzonymi przez planistę w lokalizacji PINK. System planowania tworzy powiązania. Ważna różnica polega na tym, że system planowania może zmienić te ostatnie.

Order-to-order links in transfer planning.

Jeśli popyt zostanie zmieniony z 27 na 22, system planowania zmniejszy ilość w całym łańcuchu. Rezerwacja powiązania również zostanie zmniejszona.

Powiązane informacje

Szczegóły projektowania: parametry planowania
Szczegóły projektowania: tabela przypisania planowania
Szczegóły projektowania: obsługa zasad ponownego zamawiania
Planowanie z lokalizacjami lub bez nich
Szczegóły projektowania: Główne koncepcje systemu planowania
Szczegóły projektowania: Równoważenie podaży i popytu
Szczegóły projektowania: Planowanie dostaw

Znajdź bezpłatne moduły e-learningowe dla Business Central tutaj