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.
- 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.
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.
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.
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/
Nenhum comentário:
Postar um comentário