General Construction of the IDoc

An IDoc is comprised of a number of data records in two tables:

Control record table EDI_DC

Data record table EDI_DD

A control record entry EDI_DC exists for each IDoc. This contains important data, such as the ID of the transmitting and receiving systems, and other IDs. A data record entry EDI_DD exists for each data record. This is made up of a header section which is 55 bytes long and a user data section which can hold up to 1000 bytes. The reference between data record and control record is created with an IDoc number. For each control record with document number DOCNUM, data records with the same document number DOCNUM must exist. There is, therefore, a 1:N relationship between control types and data types. The data records must be entered into table EDI_DD in exactly the same sequence as required by the hierarchical structure of the corresponding IDoc categories. For further information on the hierarchy, see Overview of IDoc Structure .

Not all fields in EDI_DC or EDI_DD are mandatory. Make sure that you do not initialize fields that need to be filled.

If you are transmitting an IDoc from the external system to SAP, then you have to define a logical system as communication partner in the SAP system (SALE-> Distribution model -> Logical systems) and a partner profile for inbound processing that agrees with this partner number. The partner number of the destination system (here SAP) is not actually mandatory, but we recommend that you specify it, so that communication procedures can be carried out correctly. The logical system of the SAP system is maintained per client in table T000 (SM31).

The partner profiles can be used to provide a non-standard function module for processing IDocs in the table for inbound processing methods in the ALE service level.

When creating IDocs in the SAP system using transaction WE30, three structures are created and numbered automatically for each IDoc segment. For example: Delivery header has E1TPDLH, E2TPDLH and E3TPDLH. E1 TPDLH is release-independent, E2TPDLH is release-dependent and E3 TPDLH is used for documentation. When segment names are transferred, you must specify the E2 segment names in order to be working independently of SAP release.

Overview of Transferred Message

The messages listed below are transferred from the SAP system to the transportation planning system. The names used are those specified for the basic IDoc categories and logical message types:

The messages listed below are transferred from the transportation planning system to the SAP system:

When transferring documents between the SAP system and a transportation planning system, you must follow these basis guidelines regardless of the direction of transfer:

Delivery and shipment documents must all be fully transferred when added to or changed.

If, for example, a delivery is changed in the SAP system after it has been transferred to the subsystem, the whole document is fully transferred with the all data, not just the changes. Changed shipments must also be fully retransferred from the planning system.

If documents are deleted, they must be transferred with at least the entire header information.

The item segment can be ignored for documents to be deleted.

If fields in the IDoc have the initial values, then they are also initial in the underlying document

Transferring a document using messages

Normally, you are not allowed to combine document in a single IDoc. In other words, each IDoc is only allowed to contain a single header segment. IDoc TPSLOC01 is an exception to this rule because it can transfer several master data records.

Taking the serialization of message into account

This is done to ensure that older IDoc versions for a document are not posted again after a more recent document has been processed.

Deliveries may not be split in planning

The SAP system does not currently support delivery split in the shipment. For this reason, the planning system can only plan complete deliveries into a shipment. If this is not possible, then the delivery must be changed in the SAP system.

Client-dependence of the planning data must be taken into account

Take special care during communication to a transportation planning system with several SAP clients and/or SAP systems. The data from the different clients must not get mixed up (see also the section EDI_DC   IDoc Control Record )

Transfer of all data in CHAR format

All data are transferred to the IDocs in character format. There are, for example, no 8 byte sliding decimals.

Transfer of all units of measure according to ISO standard

All units of measure, country codes and currency codes are transferred in the IDoc according to the ISO guidelines (for example, KGM instead or KG for the kilogram unit).

Shipment number from number range

Shipment document numbers that are issued by a transportation planning system must fall within a number range that can be set within the SAP system.

Overview of IDoc Structure

The following sections describe the structures of the different IDocs. The indentations in the Segment column indicate the hierarchical structure of the IDoc; that is, a segment with an indentation to the right is lower in the hierarchy than the previous segment further to the left. Subordinate mandatory segments are only mandatory if the segment superior in the hierarchy is also available.

TPSDLS01 - Planning / Changing / Deallocating Delivery

TPSLOC01 - Adding/Changing Location Master Data

TPSSHT01 - Create / Delete / Change Shipment - Set Shipment Status

SYSTAT01 - Status Information for Conversion / Possible Errors