Before looking in detail at control record EDI_DC40, it is first necessary to understand how IDocs work. IDocs are used to import and export data from an SAP ERP system. In the context of EDI, IDocs play a very important role. For example, they can be used to import purchase order documents or to export invoice documents from the SAP ERP system.
In general, a differentiation is made between inbound and outbound IDocs in an SAP ERP system. As shown in the following image, IDocs that are exiting the system are called outbound IDocs. IDocs which are being imported into the system are called inbound IDocs.
SAP ERP: In- and Outbound IDocs
For incoming IDocs, the correct transfer and control of the corresponding processing routine in the SAP system is controlled with the information in element EDI_DC40. Element EDI_DC40 plays a vital role with outbound IDocs as well, as the EDI provider will start the conversion and routing based on the information displayed there.
Now we will have a more detailed look into the control record EDI_DC40. We will highlight which values are set automatically by SAP and what needs to be set by the EDI service provider during document conversion.
SAP know-how
In order to understand all the individual values in element EDI_DC40, a few basic SAP terms need to be clarified, which we will define below.
Logical system
A logical system is a unique identification and is used to identify individual clients in an SAP environment. Logical systems are managed with the help of transaction BD54. Usually, a uniform schema is used company-wide for the classification of the logical systems. Mostly the schema follows this pattern:
<Name of the instance> + CLNT + <Client Nr.>
Assuming the name of the instance is P01 and the client 100, this results in the logical system P01CLNT100.
Partner type
As the name already implies, partner type defines the type of partner during the exchange of IDocs. the partner type serves as the identification of the type of partner.
Partner types are managed with the help of transaction WE44. By default the following partner types are available.
| Partner Type | Description |
|---|---|
| B | Bank |
| BP | Benefits provider |
| GP | Business Partner |
| KU | Customer/Debtor |
| LI | Supplier/Creditor |
| LS | Logical System |
| US | User |
IDoc ports
Ports are a fundamental necessity for IDoc communication. Every external system (as is the EDI provider), which wants to communicate with the SAP system, must have at least one defined port. The following image visualizes the underlying concept:
SAP supports multiple port types, e.g file, XML file, Remote Function Call (RFC), ABAP programming interface (ABAP-PSS) etc. These IDoc ports can be managed in SAP in transaction WE21.
Administration of IDoc ports in WE21
© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.
In case the port is a file, the IDoc will be written into a file which can then be processed by an external service. Another possibility is ABAP-PSS. In that case the IDoc is forwarded to an ABAP application, which will process the IDoc, e.g. sending it over HTTPS to an EDI service provider.
Partner profile
To exchange EDI data with an EDI service provider, partner profiles for the different partners need to be configured in the SAP system. Typically, partner profiles are created for customers (creditors) and suppliers (debtors). As a result it’s possible to create outbound partner profiles (for sent IDocs) and inbound partner profiles (for received IDocs). The partner profile further specifies the IDoc type, over which port, and which role is being used for the sending or receiving.
The creation of partner profiles is done with the help of transaction WE20. The following image shows a partner agreement with the customer Daimler.
Example of a partner agreement with the customer Daimler
© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.
As seen on the right side, two IDoc types are configured. Outbound DESADV (Despatch Advice) and inbound DELINS (Delivery Schedules). This example represents a classic scenario in the automotive industry. The customer sends delivery schedules (DELFOR) and Just-In Time schedules (DELJIT), and expects despatch advices (DESADV) in return. DELINS is the SAP message type for DELFOR and DELJIT.
The following image shows the outbound DESADV configuration in detail.
Example for an outbound partner agreement
© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.
In addition to the partner number, partner type and partner role, the properties message type and receiver port are also defined here. In the example from above, the receiver port is ECOSIO and is from the type ABAP programming interface.
The following image shows the configuration for inbound DELINS in further detail.
Example of an inbound partner agreement
© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.
There is a close relation between the parameters configured in the partner agreement and the entries in the control record EDI_DC40, which we will explain in the following section.
Control record EDI_DC40
Here we analyse the most important sub elements of EDI_DC40, which are relevant for processing the IDoc on either the SAP system or the EDI provider. For the complete list of elements please refer to the official IDoc documentations. The documentation for a specific IDoc can be exported in SAP via transaction WE60. The control record is structured the same for all IDoc types. In an SAP system, the multiple control records for different IDocs can be found in table EDIDC.
For a better understanding of the in and outbound IDocs we will take the following SAP setup.
SAP example setup with an EDI provider
As for the IDoc documents to be exchanged, we use an inbound DELFOR message and an outbound DESADV message in this example.
EDI_DC40 for inbound IDocs
Example of an inbound DELFOR file:
<DELFOR02>
<IDOC BEGIN="1">
<EDI_DC40 SEGMENT="1">
<TABNAM>EDI_DC40</TABNAM>
<DIRECT>2</DIRECT>
<IDOCTYP>DELFOR02</IDOCTYP>
<MESTYP>DELINS</MESTYP>
<SNDPOR>ECOSIO</SNDPOR>
<SNDPRT>KU</SNDPRT>
<SNDPRN>10000254</SNDPRN>
<SNDLAD>9853254125456</SNDLAD>
<RCVPOR>SAPP01</RCVPOR>
<RCVPRT>LS</RCVPRT>
<RCVPRN>P01CLNT100</RCVPRN>
<RCVLAD>45325412545687</RCVLAD>
<CREDAT>20170825</CREDAT>
<CRETIM>152814</CRETIM>
<REFINT>15599156</REFINT>
<REFMES>15845251560001</REFMES>
<SERIAL>20170809545852</SERIAL>
</EDI_DC40>
...
</DELFOR02>
SNDPOR: sender port (SAP system, external subsystem)
In this element the EDI provider needs to specify the sender port which was configured in transaction WE21. In our case it has the value ECOSIO.
SNDPRT: partner type of sender
This field needs to contain the description of sender partner type, e.g. KU for customer or LI for supplier.
The combination of SNDPFC, SNDPRN and SNDPRT is the unique identification of the sender. This combination needs to be set in the SAP as partner profile (defined in transaction WE20). In case this setting is missing in the SAP, or the parameters are set incorrectly in the IDoc, the processing of the IDoc will fail.
SNDPFC: partner function of sender
This serves for the optional identification of the partner function, e.g. LF for the seller or AG for the ordering party. This field can be left empty and is also optional in the partner profile in transaction WE20.
SNDPRN: partner number of sender
In this case the internal partner number of the sender must be specified in this field, identical to its value in the SAP system. E.g. the customer or creditor number. In our case it’s 10000254.
SNDSAD: sender address (SADR)
This is a reference to the SAP directory service and is usually not in use.
SNDLAD: logical address of sender
The UNB Sender ID is entered in this field (in case EDIFACT is being used). Otherwise, it is the corresponding logical sender identifier, which is used in ANSI ASC X12, XML, CSV etc. This field is optional. We use the fictional GLN 9853254125456.
RCVPOR: receiver port
The receiver port of the receiver. For inbound IDocs this is the SAP system, identified through the combination SAP + System-ID – e.g. SAPP01 in our example.
RCVPRT: partner type of receiver
The receiver’s partner type. For incoming IDocs this is the SAP system. Therefore, the value for this field is set to LS (logical system).
RCVPFC: partner function of recipient
The partner function of the receiver. Since the recipient is the SAP system, no partner function is used. Thus, the sending system (typically the EDI provider) should leave this field empty.
RCVPRN: partner number of receiver
This is the partner number of the receiver. Since the receiver is the SAP system, there is no specific partner number as with the debtor or creditor. Instead, one uses the description for the logical system. In our case the description for the logical system is P01CLNT100.
RCVSAD: recipient address (SADR)
Reference to the SAP Directory Service. Currently not used.
RCVLAD: logical address of recipient
This field can be used to transmit the UNB receiver ID (if EDIFACT is used). Otherwise it would be the respective logical ID used in ANSI ASC X12, XML, CSV et cetera. This field is optional. In our example we are using the fictional GLN 45325412545687.
EDI_DC40 with outbound IDocs
Example for an outbound IDoc.
<DESADV01>
<IDOC BEGIN="1">
<EDI_DC40 SEGMENT="1">
<TABNAM>EDI_DC40</TABNAM>
<MANDT>100</MANDT>
<DOCNUM>0000000046615484</DOCNUM>
<DOCREL>700</DOCREL>
<STATUS>30</STATUS>
<DIRECT>1</DIRECT>
<OUTMOD>2</OUTMOD>
<IDOCTYP>DESADV01</IDOCTYP>
<MESTYP>DESADV</MESTYP>
<SNDPOR>SAPP01</SNDPOR>
<SNDPRT>LS</SNDPRT>
<SNDPRN>P01CLNT100</SNDPRN>
<SNDLAD>7844849473214</SNDLAD>
<RCVPOR>ECOSIO</RCVPOR>
<RCVPRT>KU</RCVPRT>
<RCVPFC>SP</RCVPFC>
<RCVPRN>100542101</RCVPRN>
<RCVLAD>95412163215412</RCVLAD>
<CREDAT>20170822</CREDAT>
<CRETIM>064159</CRETIM>
<SERIAL>20170822064159</SERIAL>
</EDI_DC40>
...
</DESADV01>
SNDPOR: sender port
For outbound IDoc this field contains the ID of the sending SAP system. In our example it is SAPP01.
SNDPRT: partner type of sender
The partner type of the sending SAP system, usually set to LS, standing for logical system.
SNDPFC: partner function of sender
For outgoing IDocs the sender is the SAP system and doesn’t have a partner function. Therefore, this field is usually left empty.
SNDPRN: partner number of sender
This is the partner number of the sender. As the sender is the SAP system, the value used here is the description of the logical system – in our case P01CLNT100.
SNDSAD: sender address (SADR)
Reference to the SAP Directory Service. Is usually not in use.
SNDLAD: logical address of sender
Used to transmit the UND Sender ID (if EDIFACT is in use). Otherwise, the respective ID, which is in use with ANSI ASC X12, XML, CSV etc. In our example it is the fictional GLN 7844849473214.
RCVPOR: receiver port
For outbound IDocs this port is determined based on the port set in the partner profile, which is configured in transaction WE20. The value is automatically set by the SAP system in the IDoc. In our case the port is ECOSIO.
RCVPRT: partner type of receiver
The partner type of the receiver – e.g. KU for customer or LI for supplier.
The combination of RCVPFC, RCVPRN and RCVPRT serves as a unique identification of the receiver. This combination needs to be set as an outbound partner profile (defined in transaction WE20) in the SAP.
RCVPFC: partner function of recipient
The partner function of the receiver – e.g. LF for seller and AG for the ordering party.
RCVPRN: partner number of receiver
The partner number of the receiver as it is configured in the SAP system. E.g. in the Creditor or Debtor master data settings. In our example it is number 100542101.
RCVSAD: recipient address (SADR)
Reference to the SAP Directory Service. Usually not in use.
RCVLAD: logical address of the recipient
Used to transmit the UNB receiver ID (if EDIFACT is used). Otherwise, it would be the respective logical ID used in ANSI ASC X12, XML, CSV et cetera. This field is optional. In our example, we are using the fictional GLN 95412163215412.
Any questions?
Do you still have questions regarding the topic of IDocs or Electronic Data Interchange with an SAP ERP system? Please contact us or check out our chat – we look forward to helping you!
SAP ERP and SAP S/4HANA are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in several other countries.
