IDoc Description
General Construction of the IDoc
An IDoc is comprised of a number of data records in two tables:
A control record entry EDI_DC exists for each IDoc. This contains important data such as the ID of the transmitting and receiving systems, among other IDs. A data record entry EDI_DD exists for each data record. It is made up of a header section which is 55 bytes long and a data section which can hold up to 1000 bytes. The reference of data record to control record is created with an IDoc number. For each control record with document number DOCNUM, data records with the same document number 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 the Overview of IDoc Structure section.
Not all fields in EDI_DC or EDI_DD are required entry fields. Some fields are not to contain values. Make sure to leave these fields blank.
If you are transmitting an IDoc from an external system to SAP, then you have to define a logical system as a communication partner in the R/3 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 (SAP in this case) 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 for each 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 R/3 system using transaction WE30, three structures are created and numbered automatically for each IDoc segment. For example, the delivery header might have E1TPDLH, E2TPDLH and E3TPDLH. E1TPDLH is release-independent, E2TPDLH is release-dependent and E3TPDLH is used for documentation. When segment names are
transmitted , you must specify the E2 segment names in order to be working independently of the SAP release.Data Transmission Format
Data is
transmitted via the interface using CHAR format only. Conversion is carried out in the SAP system with the necessary adjustments for the entry fields in CHAR formats. The following table gives the required entries for the more important data categories.
Field |
Length |
Possible entry value |
NUMC |
Ex: 18 |
'000000000012345678' |
CHAR |
Ex: 18 |
'Bordeaux__________' char format left-aligned with subsequent spaces |
QUAN |
Ex: 18 |
'2456.12___________' or ‘2456.12-__________‘ Fixed decimal point left-aligned with decimal point as decimal symbol, possibly with subsequent +/- sign or spaces |
DATUM |
8 |
YYYYMMDD format (19961231 for Dec 31, 1996, for example) |
UZEIT |
6 |
HHMMSS format (174809 for 5:48:09 p.m., for example) |
See also:
IDoc Control Record EDI_DC Special Fields in the Control Segment EDI_DC EDI_DD - IDoc Data RecordOverview of Transmitted Message
The messages listed below are
transmitted from the SAP R/3 System to the transportation planning system. The names used are those specified for the basic IDoc types and logical message types:
Action |
IDoc name |
Message type |
Plan/change/deallocate deliveries |
TPSDLS01 |
TPSDLS |
Add/change location master data (customer, vendor) |
TPSLOC01 |
TPSLOC |
Set transportation planning status |
TPSSHT01 |
SHIPPL |
Status information about transmission/possible errors |
SYSTAT01 |
STATUS |
The messages listed below are
transmitted from the transportation planning system to the SAP R/3 System:
Action |
IDoc name |
Message type |
Create/change/delete shipment |
TPSSHT01 |
SHIPPL |
Status information about transmission/possible errors |
SYSTAT01 |
STATUS |
When transmitting documents between the R/3 system and a transportation planning system, you must follow these basic guidelines regardless of the direction of transmission:
If, for example, a delivery is changed in the R/3 System after it has been transmitted to the subsystem, the whole document is fully transmitted with all the data, not just the changes. Changed shipments must also be fully re-transmitted from the planning system.
Item segments can be ignored if the document is to be deleted.
Normally, you are not allowed to combine documents in a single IDoc. In other words, each IDoc may only contain a single header segment. IDoc TPSLOC01 is an exception to this rule because it can transmit several master data records.
This is done to ensure that older IDoc versions for a document are not posted again after a more recent document has been processed.
Take special care during communication to a transportation planning system with several R/3 clients and/or R/3 Systems that data from different clients does not get mixed up (see also the EDI_DC IDoc Control Record section).
All data is transmitted to the IDocs in character format. For example, there are no 8-byte sliding decimals.
All units of measure, country codes and currency codes are transmitted into the IDoc according to the ISO guidelines (e.g. KGM instead of KG for the kilogram unit).
Shipment document numbers that are issued by a transportation planning system must fall within a number range that can be set within the R/3 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, which means that an indented segment is lower in the hierarchy than the previous segment further toward the margin. Subordinate mandatory segments are only mandatory if the segment superior in the hierarchy is present.
TPSDLS01 - Plan/Change/Deallocate Deliveries TPSLOC01 - Add/Change Location Master Data TPSSHT01 - Create/Change/Delete Shipment SYSTAT01 - Status Information for Transmission