Sales Area Determination in SAP SD: Real-world Business Cases and Settings by EDSDC

 

This article focuses on an EDI-related perspective of the topic. For more SAP-related details, including a detailed description of the EDSDC (VOE2) techniques, please refer to my post, "SAP ERP Functionality for EDI Processing: Sales area and Sales Order type for Inbound Orders", on the SAP Community Enterprise Resource Planning Blogs. I'll add the link in the first comment.

A Sales area in SAP SD is a combination of Sales Organization, Distribution Channel, and Division. It's an SAP-specific approach to arranging a company’s sales activities. Compared with my previous articles dedicated to Partner, Material and UoM determination, this topic contains fewer "general EDI" aspects and more SAP-specific settings. However, structuring sales activities might be applicable to every ERP. I would like to share some business cases from my experience and useful ideas. Let's start with the business cases.

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.

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.

EDIFACT

1. 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.
2. 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.

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. In this article I'll describe the most common technique. For two other options please refer to my post "SAP ERP Functionality for EDI Processing: Material Determination for Inbound Orders" on the SAP Community Enterprise Resource Planning Blogs. I'll add the link into the first comment.

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.

IDOC ORDERS

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.

EDPAR VOE4

Mapping in the EDSDC table, t-code VOE2, must then be set based on the Sold-to party:

EDSDC VOE2

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.

For two other ways of setting and more examples, please find my post "SAP ERP Functionality for EDI Processing: Material Determination for Inbound Orders" on the SAP Community Enterprise Resource Planning Blogs. I'll add the link into the first comment.

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.

https://www.linkedin.com/pulse/sales-area-determination-sap-sd-real-world-business-cases-kalyabin-sozlf/

SAP ERP Functionality for EDI Processing: Partner Determination for Inbound Orders

 Partners are a mandatory part of any sales order and key data elements for EDI interchange. At first, this topic doesn't seem sophisticated. However, having worked as an EDI and SAP Logistics consultant since 2013, I have implemented a wide variety of business scenarios and technical requirements.  In this article, I will describe some general ideas of EDI standards X12 and EDIFACT, compare them with the SAP-recommended approach, and detail several options available in SAP ERP, both ECC and S/4. I hope you find the following overview valuable.

Partner Determination at a Glance

An EDI partner is a technical, business, or other type of entity involved in message interchange and related business processes. Usually, but not always, EDI partners correspond to partner master records in the SAP system. First of all, I would distinguish between Communication and Business partners.

Communication partners are the sender and the receiver, described in the Interchange Control Header part of the message, outside of business data (segments ISA for X12 and UNB for EDIFACT, both of which are officially not included in the message specifications). Even if you know that your sender and supplier are the same entity, they will be separate objects for both EDI standards and the SAP approach.

Business partners are all types of counterparties involved and required for the relevant process. Some of them are mandatory: Supplier (aka Vendor or Seller), Buyer (aka Sold-to party), and Delivery point (aka Ship-to party). Others are optional or required for specific processes only, such as Bill-to party or Invoicee, Carrier, or Ultimate destination for Cross-Dock.

When working with SAP systems, it is also important to mention the company's organizational units. A customer sends an order to a Vendor, but it might be addressed to a certain division or process on the Vendor's side. In the SAP ERP world, this is reflected by Sales organization, Distribution channel, and Division. The SAP-standard approach (EDSDC, VOE2) allows for their determination based on EDI Vendor data and Sales order type. Generally, I prefer to address this matter together because organizational units are determined based on Vendor partner data from the EDI message. However, to keep this article clearer, I decided to postpone the EDSDC determination topic for a separate article.

The main task of processing is to map external partner identification from the EDI message to internal SAP partner numbers. For this, we need to match both partner roles and partner identifiers with partner roles and identifiers on the SAP side. Usually, partner roles mapping is implemented on the EDI provider side or middleware, which converts inbound EDI messages to, for example, IDOC. This conversion might present interesting challenges for an EDI consultant, but it is more relevant to EDI than to SAP, and I'll describe it at the end of this article. Once we have an IDOC with partner segments and external identifiers provided by the EDI provider or middleware, let's discover how this determination works out-of-the-box in SAP ERP, ECC, and S/4.

Key Partners in EDI Orders Processing

I prepared a model organization example below to describe key roles and ideas. This example is based on GLN identification, reflecting my main experience in the European market. As an SD consultant, I'm "thinking from a wholesaler's point of view."

Let's imagine your company is a supplier and you have the following customer: ACME Group is a huge multi-division company operating in different markets. They like to use economies of scale and employ a group entity to work with their EDI provider. In your market, they are represented by the legal entity ACME Corp, and you send goods to their distribution center, ACME DC.

ACME sends you sales orders through their EDI provider, who converts them and sends them to your EDI provider. Your EDI provider converts the messages to IDOCs which must be processed by your SAP system. As is traditional for Europe, they use GLNs for both communication and business parties. Please find more details regarding GLN below:

GLNs (Global Location Numbers for partner identification) are maintained and administered by  GS1, a not-for-profit international organization. GLNs are used to identify parties, including legal entities, functions and groups, and physical locations, such as warehouses, distribution centers, stores, etc. GLN usage is flexible; for example, if a legal entity and a warehouse are located in the same place, a company can use the same or two different GLNs for identification.

A GLN comprises a GS1 Company Prefix, Location Reference, and Check Digit. In my example, ACME uses Company Prefix 708990 and Location Reference 0000000 for the group, 0000001 for the legal entity, and 0000002 for the distribution center. The wholesaler has Company Prefix 7088800 and Location Reference 01000, which internally reflects Sales Organization 1000. A shorter Company Prefix is more expensive but allows for a longer Location Reference.

The first 1-3 digits of the Company Prefix are the GS1 country code; however, this only determines the country of the GS1 office that granted this prefix and does not guarantee a location in the related country. Before starting the interchange, the counterparty needs to learn the applicable GLN list, which might also be provided by the EDI provider. In the case of EDI interchange, GLN is mandatory data for the Partner master record. GS1 provides a service, Verified by GS1, which allows for checking GLNs.

Master records have already been created in the Supplier's SAP ERP:

• ACME Group, GLN 7089900000009 - 246
• ACME Corp, GLN 7089900000016 - 211
• ACME DC, GLN 7089900000023 - 212

Additionally:

• Logical system 221 has been created for the supplier's EDI provider 2. 
• Supplier's GLN 7088800010002 is relevant for Sales organization 1000 

 

To create a sales order in the SAP system, external identifiers (e.g., GLN) must be mapped to SAP master data:

• Sender -> SAP Group Customer or Logical system
• Buyer -> SAP Sold-to Party
• Delivery point -> SAP Ship-to Party
• Supplier -> SAP Sales Organization, Distribution Channel (by EDSDC, postponed for the next article)

Partner Determination: Customer as Sender

I assume this method is the "most classical" logic implemented by SAP for IDOCs. To maintain the conversion, a Partner Profile must be created for the sender representing the customer in this case (t-code WE20). Then, external numbers (GLNs) need to be mapped to SAP partner numbers in the EDPAR table (t-code VOE4). Let's explore this in detail:

• A new partner needs to be created at Partner level with Partner type KU. 

To be assigned to a specific partner, the IDOC must contain the required Sender partner number and partner type, as shown in the screenshot below. The partner number is internal, and the mapping from Sender GLN 7089900000009 to internal number 246 must be provided by the EDI provider or middleware.

• Mapping of partner numbers must be added to EDPAR table with reference to Sender, transaction code VOE4 
  • Buyer ACME Corp 7089900000016 -> SAP Sold-to, Customer number 211
  • Delivery point ACME DC 7089900000023 -> SAP Ship-to, Customer number 212

Any other standard or custom partners might be mapped in the same way.

Additionally, the seller's GLN 7088800010002 is mapped to SAP Sales Organization 1000. It's mandatory for IDOC processing if an LF partner exists in the IDOC. However, the internal number for the vendor partner is dedicated to the EDSDC table and can be defined freely, e.g., 1000.01 or ACME_NO.

The IDOC contains Partner type and external numbers in E1EDKA1-PARVW and E1EDKA1-LIFNR accordingly.

This approach has trade-offs:

• mapping of Senders to be maintained on EDI Provider or middleware side
• KU Partner records must be created for every sender

At the same time this approach provides more flexibility, e.g. Customer-related settings for Converting Data Between Sender and Receiver as described in my UoM post

Partner Determination: EDI Provider as Sender

I assume this method is the "second" approach because it requires SAP Note installation or a specific workaround. However, this method is also widely used and has reasonable benefits. To maintain the conversion, only one Partner Profile must be created, representing the source of messages (t-code WE20). In other words, the EDI provider is considered the sender for every customer as a Logical System. Then, external numbers (GLNs) need to be mapped to SAP partner numbers in the EDPAR table (t-code VOE4). Let's explore this in detail:

• A new partner needs to be created at the Partner profiles with Partner type LS. 

To be assigned to a specific partner, the IDOC must contain the required Sender partner number and partner type, as shown in the screenshot below. The partner number is internal, and the required internal number 221 must be set by the EDI provider or middleware as a constant value.

• Mapping of partner numbers must be added to the EDPAR table (transaction code VOE4) in two steps:
  
  1. Sold-to with reference to Sender: Buyer ACME Corp 7089900000016 -> SAP Sold-to, Customer number 211
  2. Other partners with reference to Sold-to: Delivery point ACME DC 7089900000023 -> SAP Ship-to, Customer number 212

Any other standard or custom partners might be mapped in the same way, with reference to Sold-to. Additionally, the seller's GLN 7088800010002 is mapped to SAP Sales Organization 1000. It's mandatory for IDOC processing if an LF partner exists in the IDOC. However, the internal number for the vendor partner is dedicated to the EDSDC table and can be defined freely, e.g., 1000.01 or ACME_NO.

The IDOC contains Partner types and external numbers in E1EDKA1-PARVW and E1EDKA1-LIFNR accordingly.

 

Important Notice: This approach can't work directly out-of-the-box. By the standard t-code VOE4 check, the value in the Customer column must exist in the KNA1 table. As a result, only Customer master records can be added, not a logical system (LS) partner. To add an LS partner, the following SAP Note must be implemented: 398022 - SD-EDI: Maintenance of EDPAR II. Also, a workaround is available, which I use for tests and sandboxes: create a customer with the same number as the logical system to overcome the check.

The benefits of this approach include the simplification of EDI master data maintenance; you don't need to add a record to WE20 for every new customer. Only new records need to be added for a new customer working through the same EDI provider or middleware. Additionally, sender mapping is not required on the EDI provider side; only one constant for the LS partner is sufficient. However, this approach might provide less flexibility than the KU-based approach.

Partner roles in EDI Messages

Partner roles usage varies significantly across different markets, standards, and customers. Sometimes, it poses challenges. Let me provide you with an overview and examples from my practice.

For an overview, please find below fragments of fictional messages, which contain the same data as the IDOCs above:

• ACME Group - GLN 7089900000009
• ACME Corp - GLN 7089900000016
• ACME DC - GLN 7089900000023
• Wholesaler ASA - GLN 7088800010002

EDIFACT partners

EDIFACT ORDERS contains the sender and receiver in the Interchange Control Header part of the message, segment UNB. Business partners are located in the Partner section, segments NAD. Usually, it's the header partner section, but sometimes the item level partner section is used.

I might be biased, but I find the EDIFACT approach and GLN-based determination pretty logical and consistent...

X12 partners

... unlike X12.

 

X12 850 also contains the sender and receiver in the Interchange Control Header part of the message, segment ISA. However, they widely use different identification systems. In the example below, DUNS numbers are used for the sender (with a suffix for extra flexibility) and the receiver. DUNS (the Data Universal Numbering System) is an international identification system managed by Dun & Bradstreet and applicable only to legal entities.

Business partners are located in the Partner section, segments N1 - N4. As you can see below, some internal coding is used. The item level might also be used, as well as the SDQ segment for the Cross-dock process.

One specific trait I encountered during X12 implementation: the business partner section doesn't contain the Sold-to party. There is a BT partner in my example below; however, BT is Bill-to, and some customers don't send it. As a result, only the ST Ship-to party is available in X12 850. Consequently, it's reasonable to use the sender as a source for Sold-to mapping, even if the ISA segment isn't officially included in the 850 transaction set. Yes, in Europe we call it a message, but in US X12, they call it a transaction set.

Proprietary XML (ECOD)

I also prepared an example of a proprietary XML ORDER message. Sometimes, an EDI provider offers to use something like this for interchange with the SAP ERP system. As you can see, this format is much more readable and convenient than the traditional global standards. The only drawback is that the provider's formats are not global. The example below is based on ECOD by COMARCH. Unfortunately, I don't have an example with the Control header part, so only business partners are shown.

Challenges of Partner Determination

Mapping partner types can be tricky. The EDIFACT party function code qualifier can be selected from 624 values (Release D21A). Similarly, the Entity Identifier Code of X12 release 8050 can be selected from 1524 values. Although only a few dozen of these values are relevant for sales order partners, different customers may use different codes for the same purpose or the same codes for different purposes. Custom codes may also appear. Sometimes, the logic can be sophisticated. For example, in X12, the OB (Ordered By) is used as Ship-to, but in some messages, the ST (Ship To) appears, and in this case, OB needs to be ignored. As a result, customer-specific mapping usually takes place. Typically, conversion between codes is processed by the EDI provider or middleware, but it’s better to understand the holistic picture, even when working on the ERP side.

I would like to describe some tricky cases from my practice.

X12 Sold-to

In a simple X12 850 purchase order, there are ST (Ship-to party) and BT (Bill-to party). BT usually means the legal entity, so it initially seems reasonable to map BT as Sold-to for the SAP sales order. However, in some cases, several BTs are used in sales for the same legal entity. And, for instance, Walmart, a significant customer in the US market, sends only one partner in the message, which is BY (Buying Party). As a result, the most reliable source of Sold-to is the sender from the ISA segment.

EDIFACT BY Buyer as Ship-to

I have never encountered EDIFACT ORDERS without a BY (Buyer) partner, and in most cases, it means the legal entity and is mapped to Sold-to. However, for some retail chains, every store is considered a Buyer, so BY equals DP (Delivery party). As a result, IV (Invoice) might be used as the Sold-to party if applicable, or the sender from the UNB segment.

Fictional GLNs of Buyer for Product Group

Once, several ORDERS failed with a Sold-to determination error for a well-known customer who hadn't announced any changes. The investigation revealed that they started using specific BY identifiers for some product groups, even if the legal entity was the same, and sent a new GLN-like number with the wrong control digit. They also required this fictional GLN to be received back in ORDRSP and subsequent messages. To solve this on the SAP ERP side, I mapped all these fictional GLNs to the same Sold-to and added a new header sales text to store and send back the fictional GLN. The EDI provider then populated this new sales text for inbound messages and used it for outbound messages.

Fictional GLN of Supplier for a purpose of procurement 

A European sales chain ordered the same products for resale and internal use and sent two different internal GLN-like numbers instead of the Supplier GLN. In that project, we implemented a Z adjustment, but today I would offer a solution similar to the previous case: an extra EDPAR record for inbound determination and a sales text to send it back in outbound messages.

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.

Appendix 1: IDOC Address Data - Be Careful

For partner determination, it is enough to have a partner role and number and match them to the SAP partner. However, EDI messages might contain detailed address data, and it may seem reasonable to map this to the relevant IDOC field. Be cautious: if the IDOC contains address data, this data will be copied to the partner data directly in the sales order. This can lead to extra storage space usage, as every sales order will contain its own address details instead of a reference to master data. Additionally, depending on the outputs implementation, it might affect outbound messages, printing forms, etc.

This feature has a specific area of usage: for Sales to One-Time Customer (OTC), such as in a drop-ship process, an inbound EDI message is the only source of address data.

Appendix 2: GLNs in EDPAR vs. GLNs in Master Record

It is worth noting that GLNs in standard outbound messages, such as ORDRSP or INVOICE, are populated from the GLN fields of the customer master record and are not connected with the EDPAR table. As a result, GLNs might need to be maintained twice, and often, EDPAR and partner master records are maintained by different teams. This may seem redundant, but it makes sense because inbound processing requires unambiguous matching and is needed only for EDI customers. Meanwhile, several master records might be created with the same GLN, for example, if Sold-to and Ship-to require different account groups. Additionally, GLNs in customer master records might be required for non-EDI customers for transportation, warehouse, or billing outputs.

Source: https://community.sap.com/t5/enterprise-resource-planning-blogs-by-members/sap-erp-functionality-for-edi-processing-partner-determination-for-inbound/ba-p/13717698