In older releases, different methods were used to define IDoc types. The differences with regard to extensions, in particular, are greater and must be taken into account during processing.

• Releases 2.1/2.2

These releases did not feature extensions for basic types, that is to say each IDoc type (then referred to as intermediate structure) was also a basic type and was identified by the DOCTYP field.

• Releases 3.0/3.1

These releases used extensions (then referred to as extension types) for the first time. These extensions were combined with basic types (then referred to as basic IDoc types) to form new IDoc types. The IDOCTYP (basic type), CIMTYP (extension) and DOCTYP (IDoc type) fields were used for identification.

• R/2 System

An R/2 System can work with the control records from R/3 Releases 3.0/3.1, that is to say the system recognizes the fields IDOCTYP, CIMTYP and DOCTYP. However, the R/2 System does not support extensions and identifies the IDoc type via only the DOCTYP field.

From Release 4.0 the IDoc type is identified via the IDOCTYP and CIMTYP fields and no longer via the DOCTYP field. Therefore, the different identification fields must be assigned to each other so that new extensions can be used for communication with older releases.

The outbound processing module derives the DOCTYP field from IDOCTYP and CIMTYP in a conversion table. If only one basic type is used, the values for DOCTYP and IDOCTYP are the same.

The port set in the partner profile determines the release to which the IDoc is sent (via the version in the port definition). The (release-specific) format (the "record types") for the IDocs is derived from these entries.

An error (with subsequent exception handling) occurs if the DOCTYP field is not known:

• Releases 2.1/2.2 (Port version 1) and R/2 System (Port type "CPI-C")

If the basic type does not correspond to the previous IDoc type (intermediate structure), processing is interrupted with an error. A combination of a basic type and an extension is highly unlikely to correspond exactly to a former IDoc type - if this is the case, however, this assignment must be defined in the conversion table to prevent an error being returned.

• Releases 3.0/3.1 or R/2 System (Port version 2)

If the basic type and extension are defined but do not correspond to the previous IDoc type, processing is interrupted with an error.

If the field values are not present, the system tries to determine the values for fields IDOCTYP, and if necessary CIMTYP, from DOCTYP. This can be done as follows:

• If an entry exists in the conversion table, the entry is used to determine IDOCTYP and, if necessary, CIMTYP.
• If no entry is found, IDOCTYP is set to the same value as DOCTYP. This is the case, in particular, when IDocs are received from an R/3 System with Release 2.1/2.2.

An error always occurs if the basic type used (as identified from the IDOCTYP field) is not defined. Errors can also occur if the extension (CIMTYP field) cannot be combined with the basic type.

IDOCTYP and CIMTYP must be converted to DOCTYP in the following cases:

• You are communicating with an R/3 System with Release 3.0/3.1.
• You or your business partner are using an external system (for example an EDI subsystem) with an older release status.
• You are communicating with an R/3 System with Release 2.1/2.2 or an R/2 System which has defined and therefore "recognizes" your extended IDoc type (as a former intermediate structure). This case is extremely rare.