Chat with us, powered by LiveChat
11 minute read

Understand and Interpret the SAP IDoc Control Record EDI_DC40

About SAP IDocs

IDocs are used to import and export data from an SAP ERP system. We have already highlighted the structure and types of IDocs in a previous article. 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 who 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
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 used company-wide for the classification of the logical systems. For the most time, the schema follows the 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 Employer Service 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 IDoc Ports
SAP IDoc Ports

SAP supports multiple types of ports, 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
Administration of IDoc ports in WE21

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). Therefore it is 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
Example of a partner agreement with the customer Daimler

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
Example for an outbound partner agreement

In addition to the partner number, the partner type and the 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
Example of an inbound partner agreement

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 will 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
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 file for an inbound DELFOR.

<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 is number 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. In our case 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 partner type of the receiver. 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 does not 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 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 any 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 assisting you!

subjects

most read

keep on reading

Cookie Settings

All marketing cookies
LinkedIn (cn_LinkedINActive)
LinkedIn uses cookies so as to provide you with a personalised user experience and show you relevant content.
Google Analytics (cn_AnalyticsActive)
Used to send data to Google Analytics about the visitor's device and behaviour. Tracks the visitor across devices and marketing channels.
Facebook (cn_FacebookActive)
Used by Facebook to display a range of promotional products, such as third-party real-time bidding.
Google Adwords (cn_AddWordsActive)
Used to identify users visiting the website via Google Ads.
Pardot (cn_PardotActive)
Pardot uses cookies to make your interactions with our website more meaningful. They help us better understand what you’re looking for, so we can tailor content for you