Ansicht
Dokumentation
BANK_OBJ_CHDOC_PREPARE_HISTORY - API: Historientabellen aufbereiten
Addresses (Business Address Services) CL_GUI_FRONTEND_SERVICES - Frontend ServicesDiese Dokumentation steht unter dem Copyright der SAP AG.
Funktionalität
In Historientabellen wird die Historie eines Objektes festgehalten. Der Funktionsbaustein erstellt aus solchen Historientabellen Änderungsbelege. Diese Änderungsbelege existieren temporär, d.h. sie werden nicht auf die Datenbank geschrieben. Das Ergebnis sind gelesenen Änderungsbelege, die in der internen Tabelle des Parameters C_TAB_CHDOCREAD abgelegt sind.
Mittels des Parameters C_TAB_HISTORY_ATTACH beschreiben Sie die Historientabellen. Sie können also in einem Schritt mehrer Historientabellen aufbereiten lassen. Jeder Zeile der internen Tabelle beschreibt eine Historientabelle. Für das Versorgen der Felder der Tabellenzeile sind zwei Fälle zu betrachten.
- Für die Historientabelle werden keine Änderungsbelege geschrieben, d.h. es wurde kein Änderungsbelegobjekt angelegt.
- OBJECTCLAS
- fiktives Änderungsbelegobjekt, welches jedoch über alle in diesem Verarbeitungsschritt anzuzeigenden Änderungsbelege unikat sein muss.
- OBJECTCLASTEXT
- Beschreibung des fiktiven Änderungsbelegobjektes.
- OBJECTID
- gewünschter Objektwert, zu dem die Änderungsbelege erzeugt werden
- OBJECTIDTEXT
- Aufbereiteter Objektwert, wenn er nicht vom Tool ermittelt werden soll
- REF_TO_HISTORY
- Verweis auf die interne Tabelle mit den Historien
- Liegt der internen Tabelle eine Struktur zu Grunde, sollte sie die Struktur BANK_STR_CD_HISTORY_CHANGEDATA mit den Änderungsinformationen inkludieren. Sollen beim Erstellen der Änderungsbelege Gültigkeitsinformationen dargestellt werden, so sind sie in den Feldern der Struktur BANK_STR_CD_HISTORY_VALIDITY abzulegen, die ebenfalls nur in diesem Fall mit in die Struktur der Historie eingebunden werden muss. Die Schlüsselfelder sind in der richtigen Reihenfolge am Anfang der Struktur der Historie zu platzieren und in der Definition des Tabellentyps als Schlüsselfelder zu kennzeichnen.
- Es empfiehlt sich nicht die Datenbanktabelle, in der die Historie auf der Datenbank gespeichert ist, als Grundlage für die interne Tabellen zu verwenden, sondern eine geeignete Struktur anzulegen. In dieser Struktur sollten dann alle Schlüsselfelder, alle änderungsbelegrelevanten Felder, die Änderungsinformationen und bei Bedarf die Gültigkeitsinformationen abgelegt sein.
- REF_TO_HISTORY_CHANGEDATA
- Verweis auf die interne Tabelle mit Änderungsinformationen zur Historie; i.d.R. in diesem Fall nicht notwendig, da die Änderungsinformationen in der Historie angegeben werden können.
- OBJECTKEYSTRUC
- Name der Struktur , in der die Felder des Objektwertes beschrieben sind
- FOR_ALL_FIELDS
- die Änderungen aller Nicht-Schlüsselfelder werden protokolliert, ansonsten gelten die Einstellungen am Datenelement für das Erstellen von Änderungsbelegen
- MULTCASE
- Im "Single Case"-Fall werden die Einträge in der Historie als eine Folge betrachtet. Im "Multiple Case"-Fall bilden die Einträge zu jedem Schlüsselwert eine separate Folge (siehe auch Online-Dokumentation der Änderungsbelege).
- HISTORY_SORTED
- die Historie liegt nach Schlüssel und Zeit sortiert vor; der Schalter muss gesetzt werden, wenn ein Verweis auf Änderungsinformationen zur Historie angeben wurde
- VALIDITY_DAILY
- es gilt eine tägliche Gültigkeit; die Angabe ist nur relevant, wenn in der Historie Gültigkeitsangaben gemacht worden sind
- FUNCTIONMODULE
- Namen des Funktionsbausteins, der die Namen der Call-Back-Methoden bereitstellt; dieser Funktionsbaustein wird als Kopie des Funktionsbausteins BANK_API_CHDOC_FUMO_HIST_GET erstellt.
- Für die Historientabelle werden Änderungsbelege geschrieben, d.h. es wurde ein Änderungsbelegobjekt angelegt.
- OBJECTCLAS
- Sie geben das Änderungsbelegobjekt an.
- OBJECTCLASTEXT
- keine Angabe notwendig, da die Beschreibung aus der Definition des Änderungsbelegobjektes ermittelt wird
- OBJECTID
- gewünschter Objektwert, zu dem die Änderungsbelege erzeugt werden
- OBJECTIDTEXT
- Aufbereiteter Objektwert, wenn er nicht vom Tool ermittelt werden soll
- REF_TO_HISTORY
- Verweis auf die interne Tabelle mit den Historien
- In diesem Fall muss der internen Tabelle auf einem Zeilentyp einer Datenbanktabelle aufbauen, die im Änderungsbelegobjekt spezifiziert wurde. Die notwendigen Schlüsselinformationen werden aus der Datenbanktabelle abgeleitet. In der Regel sind in Datenbanktabellen, für die Änderungsbelege erzeugt werden, keine Änderungsinformationen abgelegt. Deshalb sind sie unter REF_TO_HISTORY_CHANGEDATA bekannt zu machen.
- REF_TO_HISTORY_CHANGEDATA
- Verweis auf die interne Tabelle mit Änderungsinformationen zur Historie
- Jeder Eintrag in den Änderungsinformationen referiert auf den entsprechenden Eintrag in der Historie. D.h. in den Änderungsinformationen und der Historie müssen gleich viele Einträge vorhanden sein und die Historie muss nach dem Schlüssel und der Zeit sortiert sein, da durch das sonst notwendige Sortieren diese Beziehung zerstört werden würde.
- OBJECTKEYSTRUC
- Name der Struktur , in der die Felder des Objektwertes beschrieben sind
- FOR_ALL_FIELDS
- die Änderungen aller Nicht-Schlüsselfelder werden protokolliert, ansonsten gelten die Einstellungen am Datenelement für das Erstellen von Änderungsbelegen
- MULTCASE
- Im "Single Case"-Fall werden die Einträge in der Historie als eine Folge betrachtet. Im "Multiple Case"-Fall bilden die Einträge zu jedem Schlüsselwert eine separate Folge (siehe auch Online-Dokumentation der Änderungsbelege).
- HISTORY_SORTED
- die Historie liegt nach Schlüssel und Zeit sortiert vor; der Schalter muss gesetzt werden, wenn ein Verweis auf Änderungsinformationen zur Historie angeben wurde
- VALIDITY_DAILY
- keine Angabe notwendig, da für Tabellen zu den Änderungsbelege erstellt werden, Gültigkeitsangaben nicht sinnvoll erscheinen.
- FUNCTIONMODULE
- keine Angabe notwendig, da die Namen der Call-Back-Methoden aus der Definition des Änderungsbelegobjektes der Änderungsbelegtools ermittelt werden
Beispiel
Der unter dem Parameter C_TAB_HISTORY_ATTACHdargestellte 2. Fall ist dann sinnvoll, wenn aus Performancegründen zu einem bestimmten, einmaligen und sehr häufig vorkommenden Zustandswechsel keine Änderungsbelege geschrieben werden sollen. In diesem Fall sind die notwendigen Änderungsinformationen bei diesem Zustandswechsel mit in der Datenbank abzulegen. Aus diesen Informationen kann dann der fehlende Änderungsbeleg rekonstruiert und zusammen mit den in der Datenbank abgelegten Änderungsbelegen dargestellt werden. So erhält der Endanwender einen vollständigen Verlauf seiner Änderungen dargestellt.
Hinweise
Weiterführende Informationen
Parameter
C_TAB_CHDOCREADC_TAB_HISTORY_ATTACH
Ausnahmen
FIELD_MISSINGINTERNAL_ERROR
KEYLENGTH_IS_NULL
NO_FLAT_STRUCT_TYPE
NO_TABLE_TYPE
OUTPUTLENGTH_IS_INITIAL
TABLE_DESCRIPTON_NOT_FOUND
TABLE_NOT_DEFINED
Funktionsgruppe
BANK_OBJ_CHDOCFill RESBD Structure from EBP Component Structure RFUMSV00 - Advance Return for Tax on Sales/Purchases
Diese Dokumentation steht unter dem Copyright der SAP AG.
Length: 10137 Date: 20240523 Time: 114611 sap01-206 ( 149 ms )