Szczegóły projektu: Transfery w planowaniu

Zlecenia transferu są również źródłem zaopatrzenia podczas pracy na poziomie SKU. W przypadku korzystania z wielu lokalizacji (magazynów) system uzupełniania sku można ustawić na Transfer, co oznacza, że lokalizacja jest uzupełniana przez przeniesienie towarów z innej lokalizacji. W sytuacji większej liczby magazynów firmy mogą mieć łańcuch transferów, w którym dostawa do lokalizacji GREEN jest przenoszona z YELLOW, a dostawa do YELLOW jest przenoszona z RED i tak dalej. Na początku łańcucha istnieje system uzupełniania Prod. Zamówienie lub Zakup.

Uwaga

W tym artykule użyto nazw lokalizacji z wcześniejszej wersji firmy demonstracyjnej w Business Central. Nazwy te nie są mapowe bezpośrednio na lokalizacje w obecnej firmie demonstracyjnej. Zachęcamy do skorzystania z tego artykułu, aby dowiedzieć się o lokalizacjach, a nie jako instrukcje krok po kroku, jak korzystać z firmy demonstracyjnej.

Porównując sytuację, w której zamówienie dostawy jest bezpośrednio w obliczu zamówienia popytu, z sytuacją, w której zamówienie sprzedaży jest dostarczane za pośrednictwem łańcucha transferów SKU, oczywiste jest, że zadanie planowania w tej drugiej sytuacji może stać się bardzo złożone. Jeśli popyt ulegnie zmianie, może to spowodować efekt falowania w całym łańcuchu, ponieważ wszystkie zlecenia transferu plus zlecenie zakupu /produkcji na przeciwległym końcu łańcucha będą musiały zostać zmanipulowane, aby przywrócić równowagę między popytem a podażą.

Dlaczego transfer jest przypadkiem specjalnym?

Zlecenie przelewu wygląda podobnie jak każde inne zamówienie w aplikacji. Jednak za kulisami jest zupełnie inaczej.

Jednym z podstawowych aspektów, który sprawia, że transfery w planowaniu różnią się od zleceń zakupu i produkcji, jest to, że linia przesyłowa reprezentuje popyt i podaż w tym samym czasie. Część wychodząca, która jest wysyłana ze starej lokalizacji, to popyt. Część przychodząca, która ma zostać odebrana w nowej lokalizacji, jest dostawą w tej lokalizacji.

Oznacza to, że gdy system manipuluje stroną podażową transferu, musi dokonać podobnej zmiany po stronie popytu.

Transfery są zależne od popytu

Powiązany popyt i podaż są w pewnym stopniu podobne do komponentów linii zlecenia produkcyjnego, ale różnica polega na tym, że komponenty będą na następnym poziomie planowania i z inną pozycją, podczas gdy dwie części transferu znajdują się na tym samym poziomie, dla tego samego towaru.

Ważnym podobieństwem jest to, że tak jak komponenty są zależne od popytu, tak samo jest z popytem transferowym. Popyt z linii przesyłowej jest podyktowany przez stronę podażową transferu w tym sensie, że jeśli podaż zostanie zmieniona, popyt zostanie bezpośrednio naruszony.

O ile elastyczność planowania nie jest żadna, linia przesyłowa nigdy nie powinna być traktowana jako niezależny popyt w planowaniu.

W procedurze planowania popyt na transfer powinien być brany pod uwagę dopiero po przetworzeniu strony podażowej przez system planowania. Wcześniej rzeczywiste zapotrzebowanie nie jest znane. Kolejność wprowadzanych zmian jest zatem bardzo ważna, jeśli chodzi o zlecenia przelewu.

Sekwencja planowania

Na poniższej ilustracji pokazano, jak może wyglądać ciąg transferów.

W tym przykładzie odbiorca zamawia towar w lokalizacji GREEN. Lokalizacja GREEN jest dostarczana poprzez przelew z magazynu centralnego RED. Magazyn centralny RED jest zaopatrywany przelewem z produkcji na miejsce BLUE.

W tym przykładzie system planowania rozpocznie się na żądanie klienta i przejdzie do tyłu przez łańcuch. Zapotrzebowanie i dostawy będą przetwarzane w jednym miejscu na raz.

Kod poziomu transferu

Kolejność przetwarzania lokalizacji w systemie planowania jest określana przez kod poziomu transferu jednostki SKU.

Kod poziomu transferu jest wewnętrznym polem, które jest automatycznie obliczane i przechowywane w jednostce SKU podczas tworzenia lub modyfikowania jednostki SKU. Obliczenia są uruchamiane we wszystkich jednostkach SKU dla danej kombinacji Towar/Wariant i używają kodu lokalizacji i kodu przeniesienia z w celu określenia marszruty, której planowanie będzie musiało użyć podczas przechodzenia przez jednostki SKU, aby zapewnić, że wszystkie żądania zostaną przetworzone.

Kod poziomu transferu będzie równy 0 dla SKU z systemem uzupełniania Zakup lub Prod. Zamówienie i będzie -1 dla pierwszego poziomu transferu, -2 dla drugiego i tak dalej. W łańcuchu transferowym opisanym powyżej poziomy byłyby zatem -1 dla RED i -2 dla GREEN, jak pokazano na poniższej ilustracji.

Podczas aktualizowania jednostki SKU system planowania wykryje, czy jednostki SKU z transferem systemu uzupełniania są skonfigurowane z odwołaniami cyklicznymi.

Planowanie transferów bez jednostek SKU

Nawet jeśli funkcja SKU nie jest używana, możliwe jest używanie lokalizacji i ręczne przesyłanie między lokalizacjami. W przypadku firm z mniej zaawansowaną konfiguracją magazynu system planowania obsługuje scenariusze, w których istniejące zapasy są przenoszone ręcznie do innej lokalizacji, na przykład w celu pokrycia zamówienia sprzedaży w tej lokalizacji. Jednocześnie system planowania powinien reagować na zmiany popytu.

Aby obsługiwać transfery ręczne, planowanie przeanalizuje istniejące zlecenia transferu, a następnie zaplanuje kolejność, w jakiej lokalizacje powinny być przetwarzane. Wewnętrznie system planowania będzie działał z tymczasowymi SKU niosącymi kody poziomu transferu.

Jeśli istnieje więcej transferów do danej lokalizacji, pierwsze zlecenie transferu określi kierunek planowania. Transfery biegnące w przeciwnym kierunku zostaną anulowane.

Zmiana ilości z rezerwacjami

Zmieniając ilości na istniejącej podaży, system planowania uwzględnia zastrzeżenia w tym sensie, że ilość zarezerwowana stanowi dolną granicę tego, o ile można zmniejszyć podaż.

Zmieniając ilość w istniejącym wierszu zlecenia transferu, należy pamiętać, że dolny limit zostanie zdefiniowany jako najwyższa zarezerwowana ilość wiersza transferu wychodzącego i przychodzącego.

Na przykład, jeśli wiersz zamówienia transferu wynoszący 117 sztuk jest zarezerwowany dla wiersza sprzedaży 46 i wiersza zakupu 24, nie jest możliwe zmniejszenie linii transferu poniżej 46 sztuk, nawet jeśli może to stanowić nadwyżkę podaży po stronie przychodzącej.

Zmiana ilości w łańcuchu transferowym

W poniższym przykładzie punktem wyjścia jest zrównoważona sytuacja z łańcuchem transferowym dostarczającym zamówienie sprzedaży 27 w lokalizacji RED z odpowiednim zamówieniem zakupu w lokalizacji BLUE, przekazanym za pośrednictwem lokalizacji PINK. Dlatego oprócz sprzedaży i zakupu istnieją dwa zlecenia przelewu: NIEBIESKO-RÓŻOWY i RÓŻOWO-CZERWONY.

Teraz planista w lokalizacji PINK decyduje się na rezerwację na zakup.

Zwykle oznacza to, że system planowania zignoruje zamówienie zakupu i żądanie transferu. Dopóki istnieje równowaga, nie ma problemu. Ale co się stanie, gdy klient w lokalizacji RED częściowo żałuje zamówienia i zmienia je na 22?

Kiedy system planowania ponownie zadziała, powinien pozbyć się nadmiaru podaży. Rezerwacja spowoduje jednak zablokowanie zakupu i transferu do ilości 27.

Transfer RÓŻOWO-CZERWONY został zredukowany do 22. Część przychodząca przelewu NIEBIESKO-RÓŻOWA nie jest zarezerwowana, ale ponieważ część wychodząca jest zarezerwowana, nie jest możliwe zmniejszenie ilości poniżej 27.

Obliczanie czasu realizacji

Przy obliczaniu terminu płatności zlecenia przelewu brane będą pod uwagę różne rodzaje czasu realizacji.

Czasy realizacji, które są aktywne podczas planowania zlecenia przeniesienia, to:

• Czas obsługi magazynu wychodzącego
• Czas wysyłki
• Czas obsługi magazynu przychodzącego
• W wierszu planowania następujące pola są używane do dostarczania informacji o obliczeniach.
• Data wysyłki przelewu
• Data rozpoczęcia
• Data zakończenia
• Termin

Data wysyłki wiersza przelewu zostanie wyświetlona w polu Data wysyłki transferu, a data otrzymania wiersza przelewu zostanie wyświetlona w polu Data ukończenia.

Daty rozpoczęcia i zakończenia zostaną użyte do opisania rzeczywistego okresu transportu.

Na poniższej ilustracji przedstawiono interpretację daty-godziny początkowej i daty-godziny zakończenia w wierszach planowania związanych z zleceniami przeniesienia.

W tym przykładzie oznacza to, że:

• Data wysyłki + Obsługa wychodząca = Data rozpoczęcia
• Data rozpoczęcia + Czas wysyłki = Data zakończenia
• Data zakończenia + Obsługa przychodząca = Data odbioru

Czas realizacji w zakresie bezpieczeństwa

Pole Domyślny czas realizacji za pomocą bezpieczeństwa na stronie Ustawienia produkcji i powiązane pole Czas realizacji w zakresie bezpieczeństwa na karcie towaru nie będą brane pod uwagę przy obliczaniu zlecenia przeniesienia. Jednak czas realizacji bezpieczeństwa nadal będzie wpływał na całkowity plan, podobnie jak wpłynie na zamówienie uzupełnienia (zakup lub produkcja) na początku łańcucha transferu, gdy towary zostaną umieszczone w miejscu, z którego zostaną przeniesione.

W wierszu zlecenia produkcyjnego Data zakończenia + Czas realizacji bezpieczeństwa + Czas obsługi magazynu przychodzącego = Data ukończenia.

W wierszu zamówienia zakupu planowana data przyjęcia + czas realizacji bezpieczeństwa + czas obsługi magazynu przychodzącego = oczekiwana data przyjęcia.

Harmonogramu

Podczas zmiany terminu istniejącej linii transferu system planowania musi wyszukać część wychodzącą i zmienić datę-godzinę na tej linii. Ważne jest, aby pamiętać, że jeśli czas realizacji został zdefiniowany, między przesyłką a odbiorem wystąpi luka. Jak wspomniano, czas realizacji może składać się z większej liczby elementów, takich jak czas transportu i czas obsługi magazynu. Na linii czasowej system planowania cofnie się w czasie, równoważąc elementy.

W związku z tym przy zmianie terminu płatności na linii transferu należy obliczyć czas realizacji, aby zaktualizować wychodzącą stronę transferu.

Numery seryjne/partii w łańcuchach transferowych

Jeśli popyt zawiera numery seryjne/partii, a silnik planowania jest uruchomiony, spowoduje to powstanie niektórych bezpośrednio utworzonych zleceń transferu. Aby uzyskać więcej informacji na temat tej koncepcji, zobacz Atrybuty elementu. Jeśli jednak numery seryjne/partii zostaną usunięte z popytu, utworzone zlecenia transferu w łańcuchu nadal będą zawierać numery seryjne/partii i dlatego zostaną zignorowane przez planowanie (nie usunięte).

Linki do zamówień na zamówienie

W tym przykładzie BLUE SKU jest skonfigurowany z zasadą zmiany kolejności zamówień, podczas gdy PINK i RED używają Lot-for-Lot. Gdy zamówienie sprzedaży 27 zostanie utworzone w lokalizacji RED, doprowadzi to do łańcucha transferów, w którym ostatni staw w lokalizacji BLUE zostanie zarezerwowany z powiązaniem. W tym przykładzie rezerwacje nie są twardymi rezerwacjami utworzonymi przez planistę w lokalizacji PINK, ale powiązaniami utworzonymi przez system planowania. Ważną różnicą jest to, że system planowania może zmienić to drugie.

Jeśli popyt zostanie zmieniony z 27 na 22, system obniży ilość w dół łańcucha, a wiążąca rezerwacja również zostanie zmniejszona.

Zobacz też

Szczegóły projektu: Parametry planowania
Szczegóły projektu: Planowanie tabeli przydziałów
Szczegóły projektu: Obsługa zasad
ponownego uporządkowaniaSzczegóły projektu: Popyt w pustej lokalizacji
Szczegóły projektu: Centralne koncepcje systemu
planowaniaSzczegóły projektu: Równoważenie popytu i podaży
Szczegóły projektu: Planowanie dostaw