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:
- Sold-to with reference to Sender: Buyer ACME Corp 7089900000016 -> SAP Sold-to, Customer number 211
- 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
Nenhum comentário:
Postar um comentário