1 Themenübersicht
Die Hook-Contract-Definition für Bedarfselemente dient der Einbindung von neuen Belegen oder Aufträgen, für die Verfügbarkeits- und Reservierungsdaten geführt werden sollen, in die allgemeine Bedarfsdatenverwaltung durch Hook-Contract-Implementierungen.
In dieser Dokumentation ist beschrieben, welche Erweiterungen Sie mit der Hook-Contract-Definition vornehmen können und welche Einschränkungen und Besonderheiten Sie beachten müssen.
Informationen zur Hook-Infrastruktur finden Sie in der Dokumentation „Hook Contracts“.
2 Zielgruppe
3 Beschreibung
3.1 Konkrete Bedarfselemente und allgemeine Bedarfsdaten
Viele Geschäftsprozesse bestehen aus der Sicht der Lagerlogistik darin, Warenbewegungen zu planen und durchzuführen. Am Anfang eines solchen Prozesses kündigen offene Aufträge oder Belege künftige Bestandsänderungen an, am Ende werden Materialbuchungen erzeugt und der Bestand wird erhöht oder reduziert.
Unterschiedliche Aufträge und Belege bilden in ihrem Datenmodell auch unterschiedlich ab, wie viel Bedarf eines Artikels und eines Bedarfseigentümers sie an einem Lagerort zu einem Termin „voranmelden“ (geplanter Abgang) oder wie viel Bedarf gedeckt wird (geplanter Zugang). Diese konkreten Aufträge oder Belege (am häufigsten ihre Positionen, z. B. eine nicht komplett gelieferte Vertriebsauftragsposition) werden als „konkrete Bedarfselemente“ bezeichnet.
Hinweis:
Mit dem Begriff „Bedarf“ werden nicht die Daten bezeichnet, mit denen die Materialbedarfsplanung operiert.
Es gibt einige wenige konkrete Bedarfselemente, die zwar auch geplante Ab- und Zugänge darstellen, aber keine Aufträge oder Belege sind. Sie kommen in dem Valueset OrderType nicht vor und für sie wurde ein zusätzliches Valueset NoOrderType definiert:
- INVENTORY_TRANSACTION für Materialbuchungen
- INVENTORY_TRANSACTION_ERROR für fehlerhafte Materialbuchungen
- FREE_DEMAND für beleglose Bedarfe
- ONHAND für den Bestand selbst, als spezieller Bedarfsdecker
Jedes konkrete Bedarfselement wird durch eine eindeutige Kombination {orderType, noOrderType, headerGuid, detailGuid} identifiziert.
Für die Arbeit mit Reservierungen werden für jedes konkrete Bedarfselement zusätzlich Instanzen von speziellen Business Objects erzeugt, die Bedarfs-, Bedarfsdeckungs- und Reservierungsdaten in einer generalisierten Form speichern.
Das Reservierungs-API stellt Methoden zur Verfügung, die Operationen an diesen allgemeinen Bedarfsdaten durchführen (Erstellung von neuen allgemeinen Bedarfsdaten, Übertragung der Bedarfsmengen zwischen allgemeinen Bedarfselementen, Reservieren etc.), ohne konkrete Bedarfselemente kennen zu müssen. Die dafür notwendigen Informationen und Parameter werden über das API mit übergeben. Einige Parameter sind jedoch entweder fest für den jeweiligen Auftragstyp definiert oder aber können geändert werden, so dass sie nicht immer wieder mit zu übergeben werden und nicht im Datenmodell gespeichert werden.
Beispiel 1:
Der Reservierungstyp der Bedarfsdaten (automatische Reservierung/manuelle Reservierung etc.) kann manuell übersteuert werden. Deswegen gibt es die Möglichkeit, in der Anwendung „Reservierungen“ den Reservierungstyp auf den Wert zurückzusetzen, der aktuell durch Stammdaten definiert wird.
Beispiel 2:
Aus Gründen der Flexibilität wird bei dem Reservierungstyp „Automatisch mit Reservierungsfrist“ die Frist selbst nicht in den Bedarfsdaten gespeichert, sondern sie wird, wenn notwendig, aus den konkreten Auftragsdaten ermittelt.
Auch kommt es vor, dass Änderungen in den allgemeinen Bedarfsdaten spezielle Änderungen an konkreten Bedarfselementen nach sich ziehen.
Beispiel 1:
Beim Reorganisieren von Bedarfsdaten müssen die Bedarfs-GUIDs, die normalerweise in konkreten Bedarfselementen gespeichert werden, durch ZEROGUIDs ersetzt werden.
Beispiel 2:
Einem reservierten Bedarf kann seine Reservierung in einem hoch priorisierten Prozess weggenommen werden (z. B. das Buchen der negativen Inventurdifferenz, wenn der gesamte Bestand reserviert ist). Es hängt dann vom Auftragstyp ab, ob dies überhaupt erlaubt sein soll und wie das konkrete Bedarfselement darüber „informiert“ werden soll.
Für das Mapping zwischen allgemeinen und konkreten Bedarfsdaten wird die folgende Hook-Contract-Definition bereitgestellt:
com.cisag.app.inventory.reservation.hook.log.DemandElement
Für jedes konkrete Bedarfselement mit einem konkreten orderType-Wert soll eine Implementierung existieren.
3.2 Hook „DemandElement“
Für jedes konkrete Bedarfselement im Standard gibt es je eine Implementierung der Hook-Contract-Definition com.cisag.app.inventory.reservation.hook.log.DemandElement, z. B. com.cisag.app.sales.order.log.DemandElementSalesOrderImpl für Vertriebsaufträge. Die Standard-Implementierungen können als Vorlage für neue Bedarfselemente dienen.
Hinweis:
Der Hook ersetzt den Callback-Mechanismus. Implementierungen der Interfaces com.cisag.app.inventory.reservation.log.FixedReservationAvailabilityCallback, com.cisag.app.inventory.reservation.log.DemandCallback sowie com.cisag.app.inventory.reservation.log.OrderBindingCallback sind nicht mehr notwendig.
Die Hook-Contract-Definition besteht aus zwei Hook-Interfaces. Das Interface com.cisag.app.inventory.reservation.hook.log.DemandElementHook sollte in jedem Fall implementiert werden. Die implementierte Klasse ermöglicht die Abfrage von allgemeinen Bedarfseigenschaften (getReservationCreationType(), getHighestcom.cisag.app.inventory.reservation.hook.log.DemandElementBindingHookionSupportLevel() etc.), das Ändern der Bedarfselement-GUID im konkreten Bedarfselement (setDemandGuid()) oder die Reaktion auf die externe Änderung von Reservierungen im Falle eines Bedarfsverursachers (reservationChanged()).
Für die Auftragstypen, die im Geschäftsprozess miteinander fest verbunden werden (z. B. ein Produktionsauftrag und ein Vertriebsauftrag bei der auftragsbezogenen Fertigung), sollte zusätzlich das Hook-Interface com.cisag.app.inventory.reservation.hook.log.DemandElementBindingHook implementiert werden.
Jede Hook-Implementierung muss mit der Annotation com.cisag.app.inventory.reservation.log.DemandProperties (Eigenschaften „orderType“, „demandOrigin“ und „demandCoverage“) gekennzeichnet werden.