- SAP Managed Tags:
Sales area and Sales Order type determination for inbound orders are managed using t-code VOE2 and table EDSDC. This is a well-known standard setting step for EDI implementation. Therefore, it's an important and powerful tool that SAP provides, offering at least three options to set it up in different ways. Do you know all three options?
I want to share my experience on this topic:
- What are the business cases?
- How to set SAP EDSDC mapping in three different ways
- What parameters might be used to distinguish orders from X12 and EDIFACT
This article complements my previous article dedicated to EDPAR and partner determination.
Business Requirements to Select Sales Area and Sales Order Type
Some projects need only one sales area and sales order type, but I have several representative examples where more flexible logic was required.
A Sales area in SAP SD is a combination of Sales Organization, Distribution Channel, and Division.
Sales for Reselling and Internal Consumption
One of my clients, a global dairy producer, sold its products to retailers both "on the shelf" for resale and "in the kitchen" for culinary use and preparation of semi-finished products. Even if the customer was the same, such sales had to be distinguished into two different SAP sales channels: Retail and Industry. Usually, on the customer side, these sales were also related to different contracts. In this case, we used a contract number as a parameter for determination.
Sales for Trade and Service departments
While doing a project for an international manufacturing company, we encountered a requirement for sales to a DIY retailer. They ordered equipment for resale and also ordered spare parts for maintenance by their own service department. For the manufacturer, these sales had to be considered as different sales organizations, Wholesale and Aftermarket, and different sales order types were required. Initially, the DIY retailer didn’t distinguish orders for these cases, even though orders were made by different departments. Based on our request, they added the Ordering Department from their ERP system to the sales order, and we used this field for determination.
Sales to Stores and for Drop-ship
A multiband consumer goods company supported both standard orders to distribution centers and stores and a Drop-ship scenario, where products were shipped directly from the supplier to the customer, skipping the seller's warehouse. A special order type was used for Drop-ship, and the appropriate field was available in the 850 Orders messages.
Settings for SAP ERP, ECC and S/4
The described settings are relevant for IDOC ORDERS processing using process code ORDE and FM IDOC_INPUT_ORDERS.
In my previous article, I described in detail partner determination based on the EDPAR table, t-code VOE4. Explaining EDSDC logic, I will use the same model organization example: buyer ACME Group and supplier Wholesaler ASA. Only one partner, Sold-to party, is involved in EDSDC determination; it is ACME Corp, GLN 7089900000016, with SAP number 211 in the supplier’s ERP. Wholesaler ASA, GLN 7088800010002, is relevant for Sales Organization 1000. Usually, Buyer and Seller GLNs or other external identifiers are available in inbound ORDERS, and the EDI provider maps them to IDOC fields. During implementation, we might request mapping based on planned SAP settings. In any case, the Sold-to party is mapped from GLN to SAP number by EDPAR, VOE4, and the Vendor might be set up in a different way. Let’s see which options are available.
Vendors are mapped by EDPAR, then Sales area and Order type are determined by EDSDC.
I consider this option the most common and widely used. In this case, external codes are mapped in the same way for all partners, and the logic seems consistent.
The inbound IDOC contains Partner type and external numbers in E1EDKA1-PARVW and E1EDKA1-LIFNR, respectively. The logic works based on AG (Sold-to party) and LF (Vendor) with the relevant GLNs.
In the EDPAR table, t-code VOE4, partners are displayed as language-dependent codes. As a result, the system value AG is displayed as SP for Sold-to party, and LF is displayed as VN for Vendor. The SAP Customer number is 211, determined based on the Buyer’s GLN, and the internal number 1000 is assigned to the Vendor’s GLN. 1000 is set to show the connection with Sales org 1000; however, any other code might be assigned, e.g., SOrg1. The logic will work if the same code is used later in the EDSDC table.
In this example, EDPAR is set based on the LS approach, as I described in the article dedicated to Partner determination. For the KU approach, relevant mapping for Sold-to party and Vendor will work the same way.
Mapping in the EDSDC table, t-code VOE2, must then be set based on the Sold-to party:
In this example, Sold-to 211 and Vendor number 0000001000 determine Sales area 1000/10/00 and Sales order type ZOR. Please be aware that leading zeros in the Vendor number field are mandatory if the value is numeric! I remember spending hours trying to understand why EDSDC didn’t work before realizing that leading zeros are mandatory. However, this is important for numeric values only. If SOrg1 is used in EDPAR instead of 1000, the same SOrg1 would work instead of 1000.
Sales Area and Order Type Determined by EDSDC Based on Vendor External Number
The second option is to map the external vendor code directly to the EDSDC Vendor number if the vendor's external number is contained in the E1EDKA1-PARTN field (instead of E1EDKA1-PARVW).
In this case, an LF (VN) partner record shouldn’t be created in EDPAR, and only an entry in EDSDC is needed.
In this example, Sold-to 211 and Vendor number 7088800010002 determine Sales area 1000/10/00 and Sales order type ZOR.
Also, one surprising option is available using this logic: the external number might not exist, and an “empty” value will work anyway. As you can see below, the LF segment must exist, but it contains no values other than the partner type LF.
Then an EDSDC entry with an empty Vendor number must be created.
Sales Area and Order Type Determined by EDSDC Based on Buyer External Number
EDSDC determination works even if the vendor partner LF isn’t included in the message at all. In this case, the Sold-to party's external number E1EDKA1-LIFNR is used to determine the EDSDC record.
Then an entry with the Sold-to SAP number as the customer and the Sold-to’s GLN as the Vendor number must be added to EDSDC.
In this example, Sold-to 211 and Vendor number 7089900000016 determine Sales area 1000/10/00 and Sales order type ZOR.
An important restriction of this approach is that only one sales area/order type might be set up for one customer.
Setting Up Several Sales Areas
As I illustrated before, based on business examples, more than one Sales area might be required. To implement such requirements, special mapping must be done on the EDI provider’s or middleware side. A typical solution is as follows: the Vendor external number might be concatenated as GLN + an attribute by the EDI provider and then mapped via EDPAR and EDSDC to the proper sales areas and types. For example, the Buyer sends attribute G for ordering goods and S for ordering services. In this case, for the EDPAR+EDSDC approach:
- Vendor GLN: 7088800010002, attributes for goods and services G and S
- EDI provider or middleware populates E1EDKA1-PARVW with GLN+attribute: 7088800010002_G or 7088800010002_S
- EDPAR: 7088800010002_G -> 1000_G, 7088800010002_S -> 1000_S
- EDSDC: 1000_G -> 1000/10/00/ZOR, 1000_S -> 1000/20/00/ZOR2
Determination Error
If EDSDC logic isn’t set up completely, it will lead to an error during IDOC processing. The error message is VG204, and the description contains variables used for determination: VKORG, VTWEG, SPART cannot be determined for customer 0000000211, supplier 0000001000.
Sometimes this error is caused by a preceding error. In this case, the root error must be fixed, and the EDSDC error might disappear after reprocessing if the other setup is consistent. In the example below, I spoiled the GLN of the Sold-to party. The Sold-to wasn’t determined, and as a result, partners and the sales area weren’t determined as well. In this case, the first AG determination must be adjusted and the IDOC reprocessed; other errors shouldn’t be analyzed before this.
Finding Attributes for Determination
When I need to prepare logic for different sales areas or order types, I usually start by requesting and comparing order examples that have to be processed differently. When I find some candidates to be an attribute, I check them with specifications and discuss them with the business, EDI provider, and, if available, the counterparty team, to find out if they are reliable enough. Sometimes no attributes are available in the current interchange, and I request the counterparty to add additional data to the message.
In most cases, three types of parameters are in use:
- Contract number: Several contracts might match several Sales areas on the Supplier side.
- Supplier’s Code by Buyer (code assigned to the Supplier in Buyer’s ERP): Different codes might distinguish different business processes.
- Order type: Usually reflects the business scenario.
EDIFACT Attributes
Typical candidates for EDIFACT ORDERS are a Contract number and Supplier’s code by Buyer.
- Contract number is contained in a header reference segment RFF, before the partner section. Typically, a Reference code qualifier is CT (Contract number), but it might also be VC (Vendor contract number), BC (Buyer's contract number), or another custom code.
- Supplier’s code by Buyer is contained in a reference segment RFF inside the partner section. This segment specifies reference numbers related to the party specified in the previous NAD segment, SU (Supplier) in this case. I often encountered qualifier YC1 for this purpose. By the way, YC1 (Additional party identification) is a GS1 code not listed in the current EDIFACT ORDERS specification.
For distinguishing by Order type, the following segments might be used:
- BGM (Beginning of message), element 1001: BGM+<Document name code> (220 Order, 402 Cross docking order)
- ALI (Additional information), element 4183: ALI+++ <Special condition code> (148 Supply direct delivery)
A wide variety of custom uses of RFF segments are also possible.
X12 Attributes
For X12 850 Purchase Order, similar options are available.
Contract number might be in:
- BEG-06 (Contract Number)
- REF-02 when REF-01= CT (Contract Number Qualifier) and other qualifiers
- N9-02 when N9-01= CT (Contract Number Qualifier) and other qualifiers
Supplier’s Code by Buyer
- N1-04 (Identification Code)
- REF-02 when REF-01 = IA, VR, CR, VN, etc.
Order type
- BEG-02 (Purchase Order Type Code)
Custom use of REF (Reference Information) or MTX (Text) segments is also applicable.
Acknowledgements and System Overview
Thanks to my colleagues at Capgemini and others who explored this topic with me across numerous projects. Also, thanks to Capgemini for providing me with a sandbox system, which was S4HANA ON PREMISE Release 2022 SP 01 (02/2023) FPS, SAP S/4HANA 2022.
