1                     Themenübersicht

Die Hook-Contract-Definitionen für Belege dienen der Erweiterung von
Beleganwendungen und Beleg-Cockpitanwendungen auf den Ebenen „Logik“ und „Benutzerschnittstelle“ durch Hook-Contract-Implementierungen.

In dieser Dokumentation ist beschrieben, welche Erweiterungen Sie mit den Hook-Contract-Definitionen vornehmen können und welche Einschränkungen und Besonderheiten Sie beachten müssen.

Dieses Dokument behandelt die folgenden allgemeinen Hook-State-Interfaces:

• cisag.app.general.order.hook.log.EntityState
• cisag.app.general.order.hook.log.HeaderSourceState
• cisag.app.general.order.hook.log.MutableHeaderState
• cisag.app.general.order.hook.log.DetailSourceState
• cisag.app.general.order.hook.log.MutableDetailState
• cisag.app.general.order.hook.log.MakePersistentState

Dieses Dokument behandelt die folgenden allgemeinen Hook-Interfaces:

• cisag.app.general.order.hook.log.EntityHook
• cisag.app.general.order.hook.log.HeaderDependentHook
• cisag.app.general.order.hook.log.HeaderApplyDefaultsHook
• cisag.app.general.order.hook.log.HeaderValidateHook
• cisag.app.general.order.hook.log.HeaderValidateDeleteHook
• cisag.app.general.order.hook.log.MakePersistentHook
• cisag.app.general.order.hook.log.RefreshHeaderHook
• cisag.app.general.order.hook.log.ReorganizationValidateHook
• cisag.app.general.order.hook.log.DetailDependentHook
• cisag.app.general.order.hook.log.DetailApplyDefaultsHook
• cisag.app.general.order.hook.log.DetailValidateHook
• cisag.app.general.order.hook.log.DetailValidateDeleteHook
• cisag.pgm.appserver.hook.BatchActionHook

Das pgm–Interface BatchActionHook wird in diesem Dokument nur bzgl. der Verwendung in Hook Contracts für Beleganwendungen und
Beleg-Cockpitanwendungen betrachtet.

Hinweis:

Beachten Sie, dass nicht alle Belege/Beleganwendungen alle Hook-State-Interfaces/Hook-Interfaces unterstützen. Die jeweils unterstützten Interfaces entnehmen Sie dem relevanten Hook Contract (siehe Kapitel „Hook Contracts“).

Einzelne Anwendungen unterstützen darüber hinaus für z. B. Konvertierungen zusätzliche Hook-Interfaces – diese sind in diesem Dokument in den Kapiteln mit den einzelnen Beleganwendungen aufgeführt.

Eine Schnittstellenbeschreibung finden Sie im jeweils zugehörigen Entwicklungsobjekt vom Typ Hook Contract. Ausführliche Informationen zu den in den Schnittstellen deklarierten Methoden finden Sie als Ergänzung zu diesem Dokument auch als JavaDoc in den einzelnen Java-Interfaces.

Informationen zur Hook-Infrastruktur finden Sie in der Dokumentation „Hook Contracts“.

Im ADO-System stehen zudem für jede in diesem Dokument erwähnte Beleganwendung Beispiele zur Verfügung, die als Muster für eigene Erweiterungen dienen können.

2                     Zielgruppe

Entwickler

3                     Beschreibung

Die Hook-Contract-Definitionen für Beleg-Anwendungen unterstützen aktuell mithilfe entsprechender Implementierungen Folgendes:

• Hinzufügen von Attributen direkt in der Belegbasis.
• Hinzufügen von Attributen direkt in der Belegposition.
• Hinzufügen von Basisdaten in einem zusätzlichen Datenbestand.
• Hinzufügen von Positionsdaten in einem zusätzlichen Datenbestand.
• Übernahme von hinzugefügten Basis- und Positionsattributen bei der
  Konvertierung der folgenden Belege:
• Beschaffungsanfrage è  Beschaffungsangebot
• Beschaffungsangebot è  Beschaffungsauftrag
• Beschaffungsauftrag è  Bestellung/Bestelländerung
• Bestellung/Bestelländerung è  Bestellbestätigung
• Bestellbestätigung è  Beschaffungsauftrag
• Vertriebsschnellerfassungsbeleg è  Vertriebsanfrage
• Vertriebsschnellerfassungsbeleg è  Vertriebsangebot
• Vertriebsschnellerfassungsbeleg è  Vertriebsauftrag
• Vertriebsanfrage è  Vertriebsangebot
• Vertriebsangebot è  Vertriebsauftrag
• Vorschlagswertermittlung für zur Belegbasis hinzugefügte Daten.
• Vorschlagswertermittlung für zur Belegposition hinzugefügte Daten.
• Neue Basis-Prüfungen für bestehende oder neue Daten.
• Neue Positions-Prüfungen für bestehende oder neue Daten.
• Neue Löschprüfungen für Belegbasis.
• Neue Löschprüfungen für Belegposition.
• Neue Prüfung vor der Beleg-Reorganisation
• Berücksichtigung von hinzugefügten Basis- und Positionsattributen beim Bestellstatus des Beschaffungsauftrages.
• Berücksichtigung von hinzugefügten Basis- und Positionsattributen beim Bestätigungsstatus des Beschaffungsauftrages und der Bestellung/Bestell­änderung sowie beim Auftragsänderungsstatus der Bestellbestätigung.
• Hinzufügen von Aktionen, die an eine Hintergrundanwendung entweder
  • die aktuelle Belegbasis (Beleganwendung) oder
  • die selektierten Daten (Beleg-Cockpitanwendung) zur weiteren Verarbeitung übergeben.

• Protokollierung geänderter Daten während des Löschen- und Speichervorgangs
• Aktualisierung der Basis bei Positionsänderungen
• Festlegung von Belegart-Attributen, die nicht mehr änderbar sind, wenn ein Beleg zur verwendeten Art existiert

Die folgenden Unterkapitel enthalten Informationen für jedes dieser Themen.

3.1               Hinzufügen von Attributen direkt in der Belegbasis

Mithilfe des Entwicklungsobjektes „Extension“ können Sie eine vorhandene
Belegbasis (z. B. SalesOrder) um zusätzliche eigene Attribute ergänzen.

Durch die Generierung wird auch automatisch die dazugehörige Objektsicht um die neuen Attribute erweitert. Standardmäßig sind die Attribute sichtbar und änderbar – Sie können dies über die eine entsprechende Objektsicht-Erweiterung bei Bedarf ändern. Damit stehen auch entsprechende Felder in der anpassbaren Anwendung und beim Export/Import zur Verfügung.

Da die Attribute direkt zur Belegbasis gehören werden diese automatisch mit geführt.

Gehören die neuen Attribute zu einer App, dann werden zudem bei der Aktion „Basis duplizieren“ automatisch alle App-Attribute von der Quellbasis in die Zielbasis kopiert.

Hinweis:
Sind die Extension-Attribute keine App-Attribute, dann werden aus Kompatibilitätsgründen die Attribute nicht kopiert.

Ist ein abweichendes Verhalten gewünscht, dann implementieren Sie bei Bedarf die Methode „duplicateHeader“ des Hook-Interfaces HeaderDependentHook.

Bei Bedarf steht für die Vorschlagswertermittlung der neuen Attribute das Hook-Interface HeaderApplyDefaultsHook zur Verfügung – dieses dient auch für die Übernahme von Werten aus einer Quelle (z. B. Vorgänger-Beleg, Import usw.) – siehe auch unten das entsprechende Kapitel.

Die neuen Attribute sollten zudem mithilfe einer Implementierung von HeaderValidateHook geprüft werden.

Bei Bedarf können Sie die neuen Attribute in die Beleganwendung einfügen und die Änderungen im Entwicklungsobjekt „Anwendungserweiterung“ in der Repository-Datenbank speichern und somit in Folgesystem übernehmen.

Beachten Sie zudem, dass das Hinzufügen von Attributen direkt in der Beleg­basis zwar sehr einfach möglich ist, aber unter Umständen zu Problemen bzgl. der maximalen Spaltenanzahl führen kann – dies gilt insbesondere für Apps, von denen es potentiell sehr viele geben kann. Wie Sie zusätzliche Basisdaten in einem eigenen Datenbestand führen können, erfahren Sie im Kapitel „Hinzufügen von Basisdaten in einem zusätzlichen Datenbestand“.

3.2               Hinzufügen von Attributen direkt in der Belegposition

Mithilfe des Entwicklungsobjektes „Extension“ können Sie eine vorhandene
Belegposition (z. B. SalesOrderDetail) um zusätzliche eigene Attribute ergänzen.

Durch die Generierung wird auch automatisch die dazugehörige Objektsicht um die neuen Attribute erweitert. Standardmäßig sind die Attribute sichtbar und änderbar – Sie können dies über die eine entsprechende Objektsicht-Erweiterung bei Bedarf ändern. Damit stehen auch entsprechende Felder in der anpassbaren Anwendung und beim Export/Import zur Verfügung.

Da die Attribute direkt zur Belegposition gehören werden diese automatisch mit geführt.

Gehören die neuen Attribute zu einer App, dann werden zudem bei der Aktion „Duplizieren“ des Positionseditors automatisch alle App-Attribute von der Quellposition in die Zielposition kopiert.

Hinweis:
Sind die Extension-Attribute keine App-Attribute, dann werden aus Kompatibilitätsgründen die Attribute nicht kopiert.
Ist ein abweichendes Verhalten gewünscht, dann implementieren Sie bei Bedarf die Methode „duplicateDetail“ des Hook-Interfaces DetailDependentHook.
Beachten Sie, dass für die Funktionalität „Positionen suchen und hinzufügen“ abweichende Regeln gelten. Weitere Informationen hierzu finden Sie in dem Dokument „Hook-Contract-Definitionen: Positionen suchen und hinzufügen“.

Bei Bedarf steht für die Vorschlagswertermittlung der neuen Attribute das Hook-Interface DetailApplyDefaultsHook zur Verfügung. Dieses dient auch für die Übernahme von Werten aus einer Quelle (z. B. Vorgänger-Beleg, Import usw.). Siehe auch das Kapitel „Vorschlagswertermittlung für zur Belegposition hinzugefügte Daten“.

Die neuen Attribute sollten zudem mithilfe einer Implementierung von DetailValidateHook geprüft werden.

Bei Bedarf können Sie die neuen Attribute in die Beleganwendung einfügen und die Änderungen im Entwicklungsobjekt „Anwendungserweiterung“ in der Repository-Datenbank speichern und somit in Folgesystem übernehmen.

Beachten Sie zudem, dass das Hinzufügen von Attributen direkt in der Beleg­position zwar sehr einfach möglich ist, aber unter Umständen zu Problemen bzgl. der maximalen Spaltenanzahl führen kann. Dies gilt insbesondere für Apps, von denen es potentiell sehr viele geben kann. Wie Sie zusätzliche Positionsdaten in einem eigenen Datenbestand führen können, erfahren Sie im Kapitel „Hinzufügen von Positionsdaten in einem zusätzlichen Datenbestand“.

3.3               Hinzufügen von Basisdaten in einem zusätzlichen Datenbestand

Sie können eine vorhandene Belegbasis (z. B. SalesOrder) um eigene Business Objects ergänzen.

Im einfachsten Fall handelt es sich dabei um ein Objekt, welches als Primärschlüssel die GUID der Belegbasis hat und optional vorhanden ist.

Hinweis:
Über eine entsprechende Datenaktualisierung können Sie auch sicherstellen, dass solch ein Objekt nicht nur optional, sondern immer vorhanden ist.

Damit Sie den zusätzlichen Datenbestand in den Hooks, der anpassbaren Oberflächen, dem Export/Import usw. nutzen können, müssen Sie die vorhandene Objektsicht der relevanten Belegbasis mithilfe des Entwicklungsobjektes „Objektsicht-Erweiterung“ erweitern. Sie können nun entweder für Ihr neues Business Object eine entsprechende Objektsicht definieren und per änderbarer Beziehung referenzieren (die ADO-Beispiele verwenden diese Variante) oder Sie fügen die neuen Attribute als virtuelle Attribute ein, sodass diese direkt in der Objektsicht der Belegbasis zur Verfügung stehen.

Hinweis:
Über dieses Verfahren können Sie die Belegbasis im Prinzip mit einem beliebig komplexen Datenmodell erweitern. Beachten Sie aber, dass die anpassbare Oberfläche aktuell 1-N-Beziehungen nur eingeschränkt unterstützt und somit ggf. spezielle virtuelle Objektsicht-Attribute erforderlich sind.

Die Belegbasisdaten werden mithilfe eines so genannten Entity bearbeitet, wobei die neuen bzw. geänderten Basisdaten der Hook-Implementierungen pro Modul und Beleginstanz in einem EntityHookState gehalten werden. Sie benötigen daher für Ihre eigenen Daten zunächst eine entsprechende Implementierung.

Der jeweils relevante EntityHookState enthält nicht nur die neuen bzw. geänderten Basisdaten, sondern auch die Daten der neuen und geänderten Positionen. Das Hook-Interface EntityHook stellt daher die Methoden „reset“,
„create“ und „load“ zur Verfügung, mit denen der EntityHookState unabhängig von der Erweiterung der Basis bzw. Position initialisiert werden kann.

Hinweis:
Beachten Sie, dass insbesondere die Methode „load“ sehr häufig aufgerufen werden kann, weshalb Sie in diesem Kontext nur die notwendigsten Operationen durchführen sollten (z. B. Merken der GUID der Belegbasis).

Die Bearbeitung der Belegbasis erfolgt immer so, dass dafür ein MutableHeader-Objekt mit eigenem State (MutableHeaderState) erzeugt wird und evtl. Änderungen dann in einem extra Schritt in das Entity übernommen werden. Diese Änderungen werden dann in einem weiteren Schritt gespeichert. Hierfür stehen im Hook-Interface HeaderDependentHook die Methoden initMutableHeader, storeHeader und saveHeader zur Verfügung. Zudem benötigen Sie eine MutableHeaderState-Implementierung, die Daten geänderten Basisdaten ihres Moduls enthält.

Beim Kopieren der Belegbasis dient die Methode duplicateHeader zur Initialisierung des MutableHeader-Objektes (bzw. der MutableHeaderState-Daten) der Zielbasis, welches dann wieder mithilfe storeHeader in das Entity übernommen wird.

Hinweis:
Beachten Sie bitte, dass direkt vorhandene Attribute ggf. automatisch übernommen werden (siehe Kapitel „Hinzufügen von Attributen direkt in der Belegbasis“).

Das Interface HeaderDependentHook enthält zudem die Methoden deleteHeader und reorganizeHeader, welche beim Löschen bzw. Reorganisieren der Belegbasis aufgerufen werden (siehe auch Kapitel „Reduzierte Hook-Interfaces für die Reorganisation“).

Soll der zusätzliche Datenbestand auch beim Export/Import unterstützt werden, dann benötigen Sie zudem eine Hook-Implementierung des Interfaces com.cisag.pgm.bi.hook.DependentAssociationHook.

3.4               Hinzufügen von Positionsdaten in einem zusätzlichen Datenbestand

Sie können eine vorhandene Belegposition (z. B. SalesOrderDetail) um eigene Business Objects ergänzen.

Im einfachsten Fall handelt es sich dabei um ein Objekt, welches als Primärschlüssel die Header- und Detail-GUID der Belegposition hat und optional vorhanden ist.

Hinweis:
Über eine entsprechende Datenaktualisierung können Sie auch sicherstellen, dass solch ein Objekt nicht nur optional sondern immer vorhanden ist.

Damit Sie den zusätzlichen Datenbestand in den Hooks, der anpassbaren Oberflächen, dem Export/Import usw. nutzen können, müssen Sie die vorhandene Objektsicht der relevanten Belegposition mithilfe des Entwicklungsobjektes „Objektsicht-Erweiterung“ erweitern. Sie können nun entweder für Ihr neues Business Object eine entsprechende Objektsicht definieren und per änderbarer Beziehung referenzieren (die ADO-Beispiele verwenden diese Variante) oder Sie fügen die neuen Attribute als virtuelle Attribute ein, sodass diese direkt in der Objektsicht der Belegbasis zur Verfügung stehen.

Hinweis:
Über dieses Verfahren können Sie die Belegbasis im Prinzip mit einem beliebig komplexen Datenmodell erweitern. Beachten Sie aber, dass die anpassbare Oberfläche aktuell 1-N-Beziehungen nur eingeschränkt unterstützt und somit ggf. spezielle virtuelle Objektsicht-Attribute erforderlich sind.

Die Belegpositionsdaten werden mithilfe eines so genannten Entity bearbeitet, wobei die neuen bzw. geänderten Positionsdaten der Hook-Implementierungen pro Modul und Beleginstanz in einem EntityHookState gehalten werden. Sie benötigen daher für Ihre eigenen Daten zunächst eine entsprechende Implementierung.

Der jeweils relevante EntityHookState enthält nicht nur die neuen bzw. geänderten Positionsdaten, sondern auch die Daten einer neuen oder geänderten Belegbasis. Das Hook-Interface EntityHook stellt daher die Methoden „reset“, „create“ und „load“ zur Verfügung, mit denen der EntityHookState unabhängig von der Erweiterung der Basis bzw. Position initialisiert werden kann.

Hinweis:
Beachten Sie hierbei, dass insbesondere die Methode „load“ sehr häufig aufgerufen werden kann, weshalb Sie in diesem Kontext nur die notwendigsten Operationen durchführen sollten (z. B. Merken der GUIDs der Belegposition).

Die Bearbeitung der Belegposition erfolgt immer so, dass dafür ein MutableDetail-Objekt mit eigenem State (MutableDetailState) erzeugt wird und evtl. Änderungen dann in einem extra Schritt in das Entity übernommen werden. Diese Änderungen werden dann in einem weiteren Schritt gespeichert. Hierfür stehen im Hook-Interface DetailDependentHook die Methoden initMutableDetail, storeDetail und saveDetail zur Verfügung. Zudem benötigen Sie eine MutableDetailState-Implementierung, die Daten geänderten Positionsdaten ihres Moduls enthält.

Beim Kopieren der Belegposition dient die Methode duplicateDetail zur Initialisierung des MutableDetail-Objektes (bzw. der MutableDetailState-Daten) der Zielposition, welches dann wieder mithilfe storeDetail in das Entity übernommen wird.

Hinweis:
Beachten Sie bitte, dass direkt vorhandene Attribute ggf. automatisch übernommen werden (siehe Kapitel „Hinzufügen von Attributen direkt in der Belegposition“).

Das Interface DetailDependentHook enthält zudem die Methoden deleteDetail und reorganizeDetail, welche beim Löschen bzw. Reorganisieren der Belegposition aufgerufen werden (siehe auch Kapitel „Reduzierte Hook-Interfaces für die Reorganisation“).

Soll der zusätzliche Datenbestand auch beim Export/Import unterstützt werden, dann benötigen Sie zudem eine Hook-Implementierung des Interfaces com.cisag.pgm.bi.hook.DependentAssociationHook.

3.5               Reduzierte Hook-Interfaces für die Reorganisation

Einige Belege unterstützen in dem relevanten Hook Contract nicht die vollständigen Interfaces HeaderDependentHook bzw. DetailDependentHook für die Führung eigener Daten. Beispielsweise haben einige Belegerzeugungen andere Hook-Interfaces, mit denen eigene Daten geschrieben werden können, und diese sollen im Zuge der Reorganisation geändert oder gelöscht werden.

Dafür stehen die Hook-Interfaces HeaderReorganizationHook und DetailReorganizationHook zur Verfügung. Hierbei erweitert das Hook-Interface HeaderDependentHook das Hook-Interface HeaderReorganizationHook und das Hook-Interface DetailDependentHook erweitert das Interface HeaderReorganizationHook.

Normalerweise enthält ein konkreter Beleg-Hook-Contract entweder die DependentHook-Interfaces oder die ReorganizationHook-Interfaces.

Wenn zunächst nur die ReorganizationHook-Interfaces vorhanden waren und die DependentHook-Interfaces später ergänzt wurden, dann sollte eine konkrete Hook-Implementierung entweder nur die ReorganizationHook-Interfaces oder nur die DependentHook-Interfaces implementieren.

3.6               Beleg-Konvertierung

Eigene Daten, welche die Basis bzw. Position der betrachteten Belege erweitern, können mithilfe je einer Hook-Implementierung für die Basis/Position beim Konvertierungsschritt in dem Source-Objekt der Zielbasis/-position zur Verfügung gestellt werden. Die Daten im Source-Objekt können dann im HeaderApplyDefaultsHook bzw. DetailApplyDefaultsHook im Zielbeleg berücksichtigt werden.

1. B. können Sie die Methode convertProposalHeader des Hook-Interfaces ProposalHeaderConverterHook für ein direkt vorhandenes Attribut wie folgt implementieren:

public void convertProposalDetail(
CustomerProposalDetailView srcDetailView,
ProposalDetailConverterHook.Context detailConversionContext,
TargetSource<SalesOrderDetailView> trgSource) {
…
trgSource.setValue(SalesOrderDetailView.Attribute.$ado_orders_partner,
srcDetailView.getAdo_orders_partner());
trgSource.setValue(SalesOrderDetailView.Attribute.$ado_orders_partnerName,
srcDetailView.getAdo_orders_partnerName());
…
}

Die Übernahme aus dem Source- in das Ziel-Objekt erfolgt folgendermaßen:

public void applyHeaderDefaults(
SalesOrderView previousData, Source<SalesOrderView> sourceData,
SalesOrderAccess currentData) {
…
if ( sourceData != null &&
(sourceData.contains(SalesOrderView.Attribute.$ado_orders_partner) ||
sourceData.contains(SalesOrderView.Relation.$Ado_Orders_Partner))) {
// from source
currentData.setAdo_orders_partner(
sourceData.getData().getAdo_orders_partner());
}

// partner name: optional attribute, from source or partner (if changed only)
if (sourceData != null &&
sourceData.contains(SalesOrderView.Attribute.$ado_orders_partnerName)) {
// from source
currentData.setAdo_orders_partnerName(
sourceData.getData().getAdo_orders_partnerName());
} else {

…
}
…
}

Hinweis:
Im Falle von Belegdependents verwenden Sie in der „applyDefaults“-Methode statt den set-Methoden direkt den MutableHeaderState bzw. den MutableDetailState.

Diese zwei Stufen werden verwendet, da das Source-Objekt im „applyDefaults“-Schritt auch für andere Quellen verwendet wird, z. B. beim Import, bei der Aktion „Positionen suchen und hinzufügen“ usw.

3.7               Vorschlagswertermittlung für zur Belegbasis hinzugefügte Daten

Eigene Basisdaten können mithilfe der Methode applyHeaderDefaults der Klasse HeaderApplyDefaultsHook vorbelegt werden. Die Vorbelegung kann zum einen für neue Daten erfolgen, aber auch im Falle von Änderung an relevanten anderen Attributen.

An diese Methode werden auch die vorherigen Daten übergeben, wobei durchaus sein kann, dass vor dem Erneuten Setzen in das Entity ein erneuter „applyDefaults“-Aufruf erfolgt, wobei die vorherigen Daten nach dem Ende des letzten Aufrufs immer als previousData zur Verfügung stehen.

Hinweis:
Damit dies auch für Daten im MutableHeaderState korrekt funktioniert, muss die dortige Methode clone() mindestens eine Kopie all jener Daten vornehmen, die innerhalb der applyDefaults-Methode bzgl. ihrer Änderung überwacht werden.

Eine Hook-Implementierung sollte zudem das ggf. vorhandene Source-Objekt berücksichtigen, welches z. B. beim Import, bei den Konvertierungen usw. verwendet wird.

Beachten Sie, dass mithilfe dieses Hooks nur eigene Attribute vorbelegt werden können. Diese Einschränkung ist notwendig, da ansonsten verschiedene Hook-Implementierungen nicht unabhängig voneinander wären.

3.8               Vorschlagswertermittlung für zur Belegposition hinzugefügte Daten

Eigene Positionsdaten können mithilfe der Methode applyDetailDefaults der Klasse DetailApplyDefaultsHook vorbelegt werden. Die Vorbelegung kann zum einen für neue Daten erfolgen, aber auch im Falle von Änderung an relevanten anderen Attributen.

An diese Methode werden auch die vorherigen Daten übergeben, wobei es durchaus sein kann, dass vor dem Erneuten Setzen in das Entity ein erneuter „applyDefaults“-Aufruf erfolgt, wobei die vorherigen Daten nach dem Ende des letzten Aufrufs immer als previousData zur Verfügung stehen.

Hinweis:
Damit dies auch für Daten im MutableDetailState korrekt funktioniert, muss die dortige Methode clone() mindestens eine Kopie all jener Daten vornehmen, die innerhalb der applyDefaults-Methode bzgl. ihrer Änderung überwacht werden.

Eine Hook-Implementierung sollte zudem das ggf. vorhandene Source-Objekt berücksichtigen, welches z. B. beim Import, bei den Konvertierungen usw. verwendet wird.

Beachten Sie, dass mithilfe dieses Hooks nur eigene Attribute vorbelegt werden können und zudem keine Strukturänderungen an den Positionen möglich sind (z. B. Hinzufügen/Entfernen von Detailpositionen). Diese Einschränkung ist notwendig, da ansonsten verschiedene Hook-Implementierungen nicht unabhängig voneinander wären.

3.9               Neue Basisprüfungen für bestehende oder neue Daten

Mithilfe der Methode validateHeader der Klasse HeaderValidateHook können beliebige neue Prüfungen für die Belegbasis hinzugefügt werden.

Diese Prüfungen können sich entweder auf eigene Attribute beziehen oder auf bereits im Standard vorhandene.

3.10          Neue Positionsprüfungen für bestehende oder neue Daten

Mithilfe der Methode validateDetail der Klasse DetailValidateHook können beliebige neue Prüfungen für die Belegposition hinzugefügt werden.

Diese Prüfungen können sich entweder auf eigene Attribute beziehen oder auf bereits im Standard vorhandene.

3.11          Neue Löschprüfungen für Belegbasis

Mithilfe der Methode validateDeleteHeader der Klasse HeaderValidateDeleteHook können beliebige neue Lösch-Prüfungen für die Belegbasis hinzugefügt werden.

3.12          Neue Löschprüfungen für Belegposition

Mithilfe der Methode validateDeleteDetail der Klasse DetailValidateDeleteHook können beliebige neue Lösch-Prüfungen für die Belegposition hinzugefügt werden.

3.13          Neue Prüfung vor der Beleg-Reorganisation

Mithilfe der Methode validateReorganization der Klasse ReorganizationValidateHook können beliebige neue Prüfungen hinzugefügt werden, die ggf. das Durchführen der Reorganisation verhindern.

3.14          Hook-Interfaces für Bestellstatus

In der Hook-Contract-Definition des Beschaffungsauftrages stehen für die Berücksichtigung von erweiterten Basis- bzw. Positionsattributen beim Bestellstatus der Beschaffungsauftragsbasis bzw. -position die Hook-Interfaces HeaderCorrespondenceStatusHook und DetailCorrespondenceStatusHook zur Verfügung.

Das Interface DetailCorrespondenceStatusHook dient zudem für die Beeinflussung des Änderungsstatus der Position einer Bestelländerung.

3.15          Hook-Interfaces für Bestätigungsstatus und Auftragsänderung in Bestellbestätigung

In der Hook-Contract-Definition des Beschaffungsauftrages stehen für die Berücksichtigung von erweiterten Basis- bzw. Positionsattributen beim Bestätigungsstatus der Beschaffungsauftragsbasis- bzw. -position sowie der Bestellbasis bzw. -position die Hook-Interfaces HeaderConfirmationStatusHook und DetailConfirmationStatusHook zur Verfügung.

Hinweis:
Die für den Bestätigungsstatus relevanten Eigenschaften können von jenen
abweichen, die für den Bestellstatus relevant sind.

Zudem stehen in der Hook-Contract-Definition der Bestellbestätigung die Hook-Interfaces ChangeOrderHeaderHook und ChangeOrderDetailHook zur Verfügung. Mit diesen können zum einen relevante Änderungen bei der Vorbereitung der Erledigung der Bestellbestätigung gefunden werden. Zum anderen können eigene Basis- bzw. Positionsattributen bei der Übernahme von Daten aus der Bestellbestätigung in den Beschaffungsauftrag bei Bedarf mit übernommen werden.

Hinweis:
Die in diesem Fall relevanten bzw. übernommenen Attribute können von jenen abweichen, die für den Bestell- bzw. Bestätigungsstatus relevant sind.

3.16          Hook-Interface für das Hinzufügen von Aktionen

In den Hook-Contract-Definitionen der Beleganwendungen und Belegcockpit-Anwendungen steht mithilfe des Hook-Interfaces BatchActionHook eine einfache Möglichkeit zur Verfügung, mit derer man die aktuelle Belegbasis (Beleganwendung) bzw. die ausgewählten Basis- bzw. Positionsdaten (Belegcockpit-Anwendung) an eine definierte Hintergrundanwendung zur Weiterverarbeitung übergeben kann.

Diese Hintergrundanwendung kann entweder „Sofort“ und/oder „Im Hintergrund“ ausgeführt werden und zudem optional Ausgabeeinstellungen für eine evtl. notwendige Belegausgabe besitzen.

Optional können zudem Parameter definiert werden, die bei der Ausführung der Hintergrundanwendung übergeben werden.

Weitere Details finden Sie in den jeweiligen Hook-Contract-Definitionen sowie in der Beschreibung des Hook-Interfaces BatchActionHook.

3.17          Hook-Interface für das Protokollieren geänderter Daten während des Löschen- und Speichervorgangs

Um geänderte Daten während des Löschen- und Speichervorgangs protokollieren zu können, steht das Hook-Interface MakePersistentHook sowie das HookState-Interface MakePersistentState zur Verfügung.

Jedes Modul sollte eine MakePersistentState–Implementierung bereitstellen. Diese dient zum Protokollieren der Änderungen beim Speichern bzw. Löschen.

Am Beginn der Speicherung oder Löschung wird eine neue MakePersistentState–Instanz erzeugt und die Methode beginMakePesistent des MakePersistentHook-Interfaces aufgerufen.

Am Ende der Speicherung oder Löschung wird die Methode endMakePersistent des MakePersistentHook-Interfaces aufgerufen. In diesem Rahmen besteht die Möglichkeit, sämtliche protokollierte Änderungen an dem Beleg in einem Block zu berücksichtigen.

Für die eigentliche Protokollierung der Änderungen an der Basis bzw. Position wird eine Implementierung der Methoden saveHeader/deleteHeader am HeaderDependentHook bzw. saveDetail/deleteDetail am DetailDependentHook benötigt. Die an diese Methoden übergebenen Objektsichten implementieren das MakePersistentStateRetriever-Interface, sodass auch darin während der Speicherung/Löschung die relevante MakePersistentState–Instanz zwecks Protokollierung der relevanten Änderungen zur Verfügung steht.

Optional können am MakePersistentHook noch die Methoden mainCommitPerformed und mainRollbackPerformed implementiert werden.

Hinweis:
Beachten Sie bitte, dass in diesen beiden Methoden kein Transaktionskontext aktiv ist.

Danach endet die Lebenszeit der MakePersistentState-Instanz.

3.18          Hook-Interface zur Aktualisierung der Basis bei Positionsänderungen

Basisdaten können von den Positionseigenschaften abhängen (z. B. Zähler, Summen oder Ähnliches). Zur Aktualisierung der Basisdaten steht das Hook-Interface RefreshHeaderHook bereit. Mit diesem werden die vorherigen und die neuen Positionsdaten an alle Hook-Implementierungen übergeben und zudem eine änderbare Basis bereitstellt, die dann im Entity gemerkt wird.

3.19          Hook-Interface zur Festlegung von Belegart-Attributen, die nach erster Belegexistenz nicht mehr änderbar sein sollen

Mithilfe des Hook-Interfaces „com.cisag.app.general.order.hook.log.CriticalTypeAttributesRegistrationHook“ können Sie solche Belegart-Attribute festlegen, die nicht mehr änderbar sein sollen, wenn bereits ein Beleg zur Be-legart besteht.

Hinweis:

Für den ersten Beleg zur Belegart wird auch geprüft, ob zwischen der Erzeugung des Belegs und dem ersten Speichern das entsprechend gekennzeichnete Attribut geändert wurde.

Das Hook-Interface „com.cisag.app.general.order.hook.log.CriticalTypeAttributesRegistrationHook“ steht in folgenden Hook Contracts zur Verfügung:

4                     Hook Contracts

4.1               Ebene „Logik“

Für die folgenden Belege stehen entsprechende Hook-Contract-Definitionen für die Ebene „Logik“ zur Verfügung.

4.2               Ebene „Benutzerschnittstelle“

4.2.1          Beleganwendungen

Für die folgenden Beleganwendungen stehen entsprechende Hook-Contract-Definitionen für die Ebene „Benutzerschnittstelle“ zur Verfügung.

4.2.2          Beleg-Cockpitanwendungen

Für die folgenden Beleg-Cockpitanwendungen stehen entsprechende Hook-Contract-Definitionen für die Ebene „Benutzerschnittstelle“ zur Verfügung.