Definicja Hook Contract dla elementów zapotrzebowania jest używana do integracji nowych dokumentów lub zamówień, dla których dane dostępności i rezerwacji mają być zarządzane z ogólnym zarządzaniem danymi zapotrzebowania przy użyciu implementacji Hook Contract.
Niniejszy artykuł opisuje, jakie usprawnienia można wprowadzić za pomocą definicji Hook Contract oraz jakie ograniczenia i funkcje specjalne należy wziąć pod uwagę.
Informacje na temat infrastruktury Hook można znaleźć w artykule Hook Contracts.
Grupa docelowa
- Programiści
Opis
Konkretne elementy zapotrzebowania i ogólne dane zapotrzebowania
Z punktu widzenia logistyki magazynowej wiele procesów biznesowych polega na planowaniu i wykonywaniu przesunięć towarów. Na początku takiego procesu otwarte zamówienia lub dokumenty zapowiadają przyszłe zmiany zapasów; na końcu generowane są transakcje magazynowe, a zapasy są zwiększane lub zmniejszane.
Różne zamówienia i dokumenty w modelu danych odzwierciedlają również w różny sposób, ile artykułów i właścicieli zapotrzebowania należy zgłosić z wyprzedzeniem (planowana realizacja) w magazynie w określonym terminie lub ile zapotrzebowania zostanie zaspokojone (planowane przyjęcie). Te konkretne zamówienia lub dokumenty (najczęściej ich pozycje, np. niekompletna pozycja zamówienia sprzedaży) są określane jako konkretne elementy zapotrzebowania.
Istnieje kilka konkretnych elementów zapotrzebowania, które również reprezentują planowane wydania i przyjęcia, ale nie są zamówieniami ani dokumentami. Nie pojawiają się one w zestawie wartości OrderType i zdefiniowano dla nich dodatkowy zestaw wartości NoOrderType:
- NoOrderType.INVENTORY_TRANSACTION dla transakcji magazynowych
- NoOrderType.INVENTORY_TRANSACTION_ERROR dla transakcji magazynowych z błędami
- NoOrderType.FREE_DEMAND dla zapotrzebowania bez dowodu
- NoOrderType.ONHAND dla samego zapasu, jako pokrycie zapotrzebowania specjalnego
Każdy specyficzny element zapotrzebowania jest identyfikowany przez unikalną kombinację {orderType, noOrderType, headerGuid, detailGuid}.
Do pracy z rezerwacjami dla każdego konkretnego elementu zapotrzebowania tworzone są dodatkowo instancje specjalnych obiektów biznesowych, które przechowują dane dotyczące zapotrzebowania, pokrycia zapotrzebowania oraz rezerwacji w uogólnionej formie.
Interfejs API rezerwacji udostępnia metody umożliwiające wykonywanie operacji na tych ogólnych danych zapotrzebowania (tworzenie nowych ogólnych danych zapotrzebowania, przenoszenie ilości zapotrzebowania pomiędzy ogólnymi elementami zapotrzebowania, rezerwowanie itp.) bez konieczności znajomości konkretnych elementów zapotrzebowania. Niezbędne do tego informacje i parametry są przekazywane za pośrednictwem interfejsu API. Niektóre parametry są jednak zdefiniowane na stałe dla danego typu zamówienia lub mogą być zmieniane, dzięki czemu nie trzeba ich każdorazowo przekazywać ani przechowywać w modelu danych.
Typ rezerwacji danych zapotrzebowania (rezerwacja automatyczna/rezerwacja ręczna itp.) może zostać zastąpiony ręcznie. Z tego powodu możliwe jest zresetowanie typu rezerwacji w aplikacji Rezerwacje do wartości, która jest aktualnie zdefiniowana przez dane podstawowe.
Ze względu na elastyczność, sam termin nie jest zapisywany w danych zapotrzebowania dla typu rezerwacji Automatycznie z okresem rezerwacji, ale jest określany na podstawie konkretnych danych zamówienia, jeśli to konieczne.
Zdarza się również, że zmiany w ogólnych danych zapotrzebowania powodują określone zmiany w określonych elementach zapotrzebowania.
Podczas reorganizacji danych zapotrzebowania, identyfikatory GUID zapotrzebowania, które są zwykle zapisywane w określonych elementach zapotrzebowania, muszą zostać zastąpione identyfikatorami ZEROGUID.
Zarezerwowane zapotrzebowanie może zostać pozbawione swojej rezerwacji w procesie o wysokim priorytecie (np. przy księgowaniu ujemnej różnicy inwentaryzacyjnej, gdy cały zapas jest zarezerwowany). To, czy jest to w ogóle dozwolone oraz w jaki sposób konkretne elementy zapotrzebowania mają zostać o tym „poinformowane”, zależy od typu zamówienia.
Poniższa definicja Hook Contract służy do mapowania między ogólnymi i szczegółowymi danymi zapotrzebowania:
com.cisag.app.inventory.reservation.hook.log.DemandElement
Implementacja powinna istnieć dla każdego konkretnego elementu zapotrzebowania z określoną wartością orderType.
Hook DemandElement
Dla każdego konkretnego elementu zapotrzebowania w standardzie istnieje jedna implementacja definicji Hook Contract com.cisag.app.inventory.reservation.hook.log.DemandElement, np. com.cisag.app.sales.order.log.DemandElementSalesOrderImpl dla zamówień sprzedaży. Standardowe implementacje mogą być używane jako szablon dla nowych elementów zapotrzebowania.
Definicja Hook Contract składa się z dwóch interfejsów Hook. Interfejs com.cisag.app.inventory.reservation.hook.log.DemandElementHook powinien być zawsze zaimplementowany. Zaimplementowana klasa umożliwia zapytanie o ogólne właściwości zapotrzebowania (getReservationCreationType(), getHighestcom.cisag.app.inventory.reservation.hook.log.DemandElementBindingHookionSupportLevel() itp.), zmianę identyfikatora GUID elementu zapotrzebowania w konkretnym elemencie zapotrzebowania (setDemandGuid()) lub reakcję na zewnętrzną zmianę rezerwacji w przypadku źródła zapotrzebowania (reservationChanged()).
Interfejs Hook com.cisag.app.inventory.reservation.hook.log.DemandElementBindingHook powinien być również zaimplementowany dla typów zamówień, które są ze sobą trwale powiązane w procesie biznesowym (np. zlecenie produkcyjne i zamówienie sprzedaży w produkcji związanej z zamówieniem).
Każda implementacja Hook musi być oznaczona adnotacją com.cisag.app.inventory.reservation.log.DemandProperties (właściwości orderType, demandOrigin i demandCoverage).
