When processing incoming SAP SD sales orders, users are often faced with the challenge that external IDs, such as Global Location Number (GLN), DUNS numbers and similar, are used instead of the internal SAP numbers. In order for automatic processing in SAP to be possible, external numbers must be converted to the internal customer numbers. We show the technical possibilities that an SAP ERP system offers in this case.
SAP SD sample process
The following illustration shows an order process between a buyer and a seller. On the seller’s side, the ordering process is handled in the SAP SD module. The corresponding Sold-To, Ship-To and Bill-To addresses are maintained in the internal customer master. Each address is identified by its own customer number, which is unique in the SAP system.
However, the buyer’s order does not contain internal SAP numbers. Instead, the individual roles of buyer, seller, etc. are identified using DUNS numbers in the example above.
The challenge now is to ensure that the external DUNS numbers are assigned to the correct internal customer numbers.
IDoc ORDERS example
In order for an order to be automatically transferred to the SAP system, it must be transferred to the SAP system as an ORDERS05 IDoc (other options and IDoc types are available too, but for our example we stick to the ORDERS05 IDoc). The individual roles in the IDoc are mapped as element E1EDKA1. The goods recipient role could look as follows:
<E1EDKA1 SEGMENT="1">
<PARVW>WE</PARVW>
<PARTN>70010</PARTN>
<NAME1>Scrimpton Ltd</NAME1>
<NAME2>Central Warehouse</NAME2>
<STRAS>80 Westbury Avenue</STRAS>
<ORT01>London</ORT01>
<PSTLZ>10114</PSTLZ>
</E1EDKA1>
The problem here is that the buyer doesn’t know the Sold-To number 70010. Instead, the buyer uses the DUNS number 341301622 to identify the central warehouse to which the goods are to be delivered. In principle, there are two ways to circumvent this problem.
The first possibility is to convert the external number to the correct internal number during the EDI document mapping. In this case, a lookup table is added to the mapping, allowing to map from external numbers to SAP internal numbers. Although technically possible, this option has a significant disadvantage, as the lookup table is kept decoupled from the ERP system in the document mapping. As soon as a new Ship-To is added, the mapping table must be updated. This process is error-prone, as the appropriate maintenance of the table is often forgotten.
The technically more elegant option is therefore to maintain the mapping table in the SAP system. In this case, the ERP system automatically takes over the conversion of the external numbers to the correct internal debtors. To do this, the IDoc must be changed as follows. The Ship-To party role is again used as an example.
<E1EDKA1 SEGMENT="1">
<PARVW>WE</PARVW>
<LIFNR>341301622</LIFNR>
<NAME1>Scrimpton Ltd</NAME1>
<NAME2>Central Warehouse</NAME2>
<STRAS>80 Westbury Avenue</STRAS>
<ORT01>London</ORT01>
<PSTLZ>10114</PSTLZ>
</E1EDKA1>
Instead of the internal customer number in the PARTN, which the seller doesn’t know, the DUNS number is transferred in the LIFNR element. This adaptation must also be implemented accordingly for the other roles such as AG (Sold-To), RG (Bill-To) and LF (Supplier), so that the external DUNS numbers can also be set here.
When processing the inbound IDoc, SAP now automatically looks for the correct customer numbers. The lookup logic for incoming SD sales orders takes place in the following module:
- Package: VED (Standard EDI)
- Function Group: VEDA
- Function Module: IDOC_ INPUT_ ORDERS
- Form: LVEDAF5T (ZUORDNEN_ ORDERS_ E1EDKA1)
Reading out the allocation table
The central lookup table is called EDPAR. The associated transaction for maintaining EDPAR is VOE4. The following figure shows the structure of the table in transaction SE11.
© 2021. SAP SE or an affiliate company. All rights reserved. Used with permission of SAP SE.
In order to enable an assignment of the external number 341301622 to the internal SAP customer number 70010 for the Ship-To role, the following entry in table EDPAR is necessary.
© 2020. SAP SE or an affiliate company. All rights reserved. Used with permission of SAP SE.
Depending on whether a logical system (LS) or a customer (KU) is set as SNDPRT in EDI_DC40, the lookup is slightly modified. The following SQL pseudo code shows the lookup logic in the module IDOC_ INPUT_ ORDERS for the role SH (Ship-To).
In the case of LS:
Since no customer number is set in EDI_DC40 in the case of a logical system, the customer number is drawn from the internal structure XVBAK instead.
SELECT FROM EDPAR WHERE KUNNR = <KUNNR from internal table XVBAK>
AND PARVW = 'SH'
AND EXPNR = '341301622'`
In the case of KU:
If a KU is set in EDI_DC40, the customer number is taken from the SNDPRN field and the lookup is made on this basis.
SELECT FROM EDPAR WHERE KUNNR = <SNDPRN from the EDI_DC40>
AND PARVW = 'SH'
AND EXPNR = '341301622'
Please note that the entries for all roles must be set correctly. If, for example, new Ship-To addresses are added, the entries in EDPAR must also be updated. By default, the following roles are read from EDPAR in the IDOC_ INPUT_ ORDERS module:
- Client (AG)
- Supplier (LF)
- Consignee (WE)
- Forwarding agent (SP)
- Bill-to party (RE)
- Payer (RG)
- Customer plant (WK)
For outgoing SD documents, such as ORDRSP (Order Response), the lookup logic is similar and is also based on table EDPAR.
Do you still have questions about SAP and EDI?
Do you still have questions about SAP SD and associated EDI processes? Get in touch with us or use our chat – we’re always happy to help!
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.
