General information on the change document creation
In the R/3 System, change documents are created object-related. Herethe terms Object class, Object ID, and Object characteristic aredistinguished:

• Object class

An object class consists of one or several tables or structures definedin the DDIC. The tables or structures must have a key. The tables foran object class should have a common foreign key.
Example:
Object class Purchase requisition = PReq consists of the DDIC tablesEBAN (purchase requisition) and EBKN (purchase requisition accountassignment). The common key is the purchase requisition number.

• Object ID

The object ID of an object class is the common key of the respectivetables.
Example:
For the object class = PReq, the object ID is the purchase requisitionnumber.

• Object characteristic

An object characteristic of an object class consists of all lines ofthe respective tables with the same object ID.
Example:
The object characteristic PReq = 30 consists of all lines of the tablesEBAN and EBKN whose purchase requisition number is = 30.
Thus, the first step for the change document creation must be thedefinition of suitable object classes. The object classes are not to bemaintained in the DDIC.
The central part of the change document creation consists of thefunction modules of the function group CDOK. A change is to betransferred to the function modules by specifying the old unchangedstatus and the new changed status.
Text changes are an exception, which are dealt with separately. Thetransfer of the old and new status is always carried out for eachtable. Here, you can decide whether the transfer is carried out in theform 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 ofthe object classes are called "Single case table" or "Multiple casetable".
The function modules distinguish whether it is an entry operation, adeletion, or change operation:
When entering, only a change document with key information ofthe entered record is created.
For deletion, you can choose between two options. Either thecreation of change documents is carried out the same way as whenentering 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 iscreated for each field defined in ADIC as relevant to change document;this change document contains the old and the new contents of thefield.
When changing texts (in this case, long texts), it is only documentedthat the corresponding text has been changed. The old and new status isnot stored. For this reason, an internal table is to be created fortext changes of an object characteristic and the corresponding functionmodule is to be called.
When creating change documents, the currencies and units are to bedocumented if the corresponding value fields change. Since the functionmodules are called for every table, this does not cause any problems ifthe referenced fields were defined in the same table structure. If thisis not the case, it is possible to transfer a second DDIC structure tothe function modules, which contains the referenced currency fields andunits fields. So that the correct reference from the function modulescan be made, the field names of the additional structure must beassembled from the names of the corresponding reference tables and thenames of the reference fields. In the "Single Case", transfer referenceinformation in the form of two additional work areas (old, new). In the"Multiple Case", the internal tables are to be extended by thereference structure.
Example: Table X4711
Field PREIS gets the currency from table T001, field WAERS. Thus, astructure 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 besupplied with T001-WAERS in a suitable position.

Notes:
It is important that the sequence in which the individual functionmodules are to be called for the change document creation for an objectcharacteristic 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, thegeneration 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, suchas the object class, the object ID, the change date, and so on. Toindicate that the change document is UNICODE-compatible, the systemlanguage when the change document was written is entered in the LANGUfield.
The second table is called CDPOS and contains the individual items, forexample, the table and structure name, the field name of the changedfield, the old and new value, and so on.
Since the introduction of UNICODE for change documents, the handling ofthe relevant table key has changed. Before UNICODE, the modules of thechange document creation came from a key stored character by character.This key had to be at the start of the table/structure. Using the keylength stored in the DDIC, the table key was cut from the transferredstructure or table line. In this process, inconsistent CHAR fields werenot stored correctly as KEY. With UNICODE, this method is no longerguaranteed because the length specification cannot be used reliably.Therefore, since UNICODE, the field TABKEY is compiled field by fieldfrom the individual key fields, in a CHAR field. When the CHAR fieldsare obtained on a field by field basis, modules of the function groupSCD8 are used. The information defining a KEY field is taken from theDDIC of the corresponding table/structure. If the TABKEY to be compiledis longer that 70 CHAR, a third table is required, which can accept aKEY of up to a maximum of 254 CHAR.
Since the introduction of UNICODE for change documents, the third tableCDPOS_UID is required to accept a table key of up to a maximum of 254CHAR. If such a case occurs, the GUID for the CDPOS_UID record isstored in the TABKEY field in CDPOS. The 254 CHAR table key is thenstored for this GUID in CDPOS_UID. In the corresponding CDHDR record,the Version field is also filled with '001' to indicate the presence ofa long table key (longer than 70 CHAR).
All three table components for a change document are to be identifiedby a common CHANGENUMBER that is created uniquely each time.
Name of the object class for which change documents are tobe created (e.g. "BANF" for purchase requisition).
Object class ID or value.
Example:
Object class,, = "BANF".
Object ID,, = "30".

Description
This parameter specifies whether the changes which are logged areactual or planned changes.

Value range
Valid values are:
'R',,actual (real) changes.
'P',,planned changes.
SPACE,,if a plan number exists,
,,planned change; if no plan number exists,
,,actual change.

Default
The parameter has the default value SPACE, i.e. it depends onthe plan number whether the changes are planned or or actual.