Ansicht
Dokumentation
CHANGEDOCUMENT_OPEN - Change document: Open change document creation
rdisp/max_wprun_time - Maximum work process run time TXBHW - Original Tax Base Amount in Local CurrencyThis documentation is copyright by SAP AG.
This function module has been released.
The documentation is being revised so that it conforms to the requirements for released function modules.
The change document creation for an object characteristic must start with the callup of this function module. Internal fields are initialized and the object characteristic is reported.
Example call:
DATA: OBJECTCLASS LIKE CDHDR-OBJECTCLAS,
OBJECTID LIKE CDHDR-OBJECTID.
OBJECTCLASS = 'BANF'.
OBEJCTID = '30'.
CALL FUNCTION 'CHANGEDOCUMENT_OPEN'
EXPORTING OBJECTCLASS = OBJECTCLASS
OBJECTID = OBJECTID
EXCEPTIONS ...
General information on the change document creation
In the R/3 System, change documents are created object-related. Here the terms Object class, Object ID, and Object characteristic are distinguished:
- Object class
An object class consists of one or several tables or structures defined in the DDIC. The tables or structures must have a key. The tables for an object class should have a common foreign key.
- Example:
Object class Purchase requisition = PReq consists of the DDIC tables EBAN (purchase requisition) and EBKN (purchase requisition account assignment). The common key is the purchase requisition number.
- Object ID
The object ID of an object class is the common key of the respective tables.
- Example:
For the object class = PReq, the object ID is the purchase requisition number.
- Object characteristic
An object characteristic of an object class consists of all lines of the respective tables with the same object ID.
- Example:
The object characteristic PReq = 30 consists of all lines of the tables EBAN and EBKN whose purchase requisition number is = 30.
Thus, the first step for the change document creation must be the definition of suitable object classes. The object classes are not to be maintained in the DDIC.
The central part of the change document creation consists of the function modules of the function group
CDOK. A change is to be transferred to the function modules by specifying the old unchanged status and the new changed status.
Text changes are an exception, which are dealt with separately. The transfer of the old and new status
is always carried out for each table. Here, you can decide whether the transfer is carried out in the
form of work areas (WORKAREA_OLD, WORKAREA_NEW) or internal tables (TABLE_OLD, TABLE_NEW). In the first
case, one speaks of "Single case", in the second of "Multiple case". Correspondingly, the DDIC tables of the object classes are called "Single case table" or "Multiple case table".
The function modules distinguish whether it is an entry operation, a deletion, or change operation:
When entering, only a change document with key information of the entered record is created.
For deletion, you can choose between two options. Either the creation of change documents is carried out the same way as when entering or each field, defined in ADIC as relevant to change document, of the deleted record is documented (individual field documentation).
When carrying out a change operation, a change document is created for each field defined in ADIC as relevant to change document; this change document contains the old and the new contents of the field.
When changing texts (in this case, long texts), it is only documented that the corresponding text has been changed. The old and new status is not stored. For this reason, an internal table is to be created for text changes of an object characteristic and the corresponding function module is to be called.
When creating change documents, the currencies and units are to be documented if the corresponding value fields change. Since the function modules are called for every table, this does not cause any problems if the referenced fields were defined in the same table structure. If this is not the case, it is possible to transfer a second DDIC structure to the function modules, which contains the referenced currency fields and units fields. So that the correct reference from the function modules can be made, the field names of the additional structure must be assembled from the names of the corresponding reference tables and the names of the reference fields. In the "Single Case", transfer reference information in the form of two additional work areas (old, new). In the "Multiple Case", the internal tables are to be extended by the reference structure.
- Example: Table X4711
Field PREIS gets the currency from table T001, field WAERS. Thus, a structure of the category INTTAB must be created in DDIC, for example, R4711 that contains the field T001WAERS. In the application program, the fields T001WAERS of reference structure (old and new) must then be supplied with T001-WAERS in a suitable position.
Notes:
It is important that the sequence in which the individual function modules are to be called for the change document creation for an object characteristic is kept:
- CHANGEDOCUMENT_OPEN
-
in any sequence
CHANGEDOCUMENT_SINGLE_CASE (for each changed Single case table)
CHANGEDOCUMENT_MULTIPLE_CASE (for each changed Multiple case table)
CHANGEDOCUMENT_TEXT_CASE (for text changes) - CHANGEDOCUMENT_CLOSE
To generate the update task for an object class automatically, the generation has be to triggered in transaction SCDO.
Internally, the change documents are stored in three tables.
The first table is called CDHDR and contains header information, such as the object class, the object ID, the change date, and so on. To indicate that the change document is UNICODE-compatible, the system language when the change document was written is entered in the LANGU field.
The second table is called CDPOS and contains the individual items, for example, the table and structure name, the field name of the changed field, the old and new value, and so on.
Since the introduction of UNICODE for change documents, the handling of the relevant table key has changed. Before UNICODE, the modules of the change document creation came from a key stored character by character. This key had to be at the start of the table/structure. Using the key length stored in the DDIC, the table key was cut from the transferred structure or table line. In this process, inconsistent CHAR fields were not stored correctly as KEY. With UNICODE, this method is no longer guaranteed because the length specification cannot be used reliably. Therefore, since UNICODE, the field TABKEY is compiled field by field from the individual key fields, in a CHAR field. When the CHAR fields are obtained on a field by field basis, modules of the function group SCD8 are used. The information defining a KEY field is taken from the DDIC of the corresponding table/structure. If the TABKEY to be compiled is longer that 70 CHAR, a third table is required, which can accept a KEY of up to a maximum of 254 CHAR.
Since the introduction of UNICODE for change documents, the third table CDPOS_UID is required to accept a table key of up to a maximum of 254 CHAR. If such a case occurs, the GUID for the CDPOS_UID record is stored in the TABKEY field in CDPOS. The 254 CHAR table key is then stored for this GUID in CDPOS_UID. In the corresponding CDHDR record, the Version field is also filled with '001' to indicate the presence of a long table key (longer than 70 CHAR).
All three table components for a change document are to be identified by a common CHANGENUMBER that is created uniquely each time.
Parameters
OBJECTCLASSOBJECTID
PLANNED_CHANGE_NUMBER
PLANNED_OR_REAL_CHANGES
Exceptions
SEQUENCE_INVALIDFunction Group
SCD0CL_GUI_FRONTEND_SERVICES - Frontend Services ABAP Short Reference
This documentation is copyright by SAP AG.
Length: 8953 Date: 20240523 Time: 114724 sap01-206 ( 220 ms )
