This article focuses on an EDI-related perspective of the topic. For more SAP-related details, including a detailed description of the EDPAR (VOE4) techniques, please refer to my post, "SAP ERP Functionality for EDI Processing: Partner Determination for Inbound Orders," on the SAP Community Enterprise Resource Planning Blogs. I'll add the link in the first comment.
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 and describe some interesting cases from my experience.
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 usually 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.
The main task of processing is to map external partner identification from the EDI message to internal numbers for your ERP system, e.g. SAP ERP. For this, we need to match both partner roles and partner identifiers with partner roles and identifiers on ERP side. Usually, partner roles mapping is implemented on the EDI provider side or middleware, which diverse converts diverse customers inbound EDI messages to a standard, applicable for ERP system.
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. For partner identification ACME uses GLNs:
- ACME Group, GLN 7089900000009
- ACME Corp, GLN 7089900000016
- ACME DC, GLN 7089900000023
To create a sales order in the SAP system, external identifiers (e.g., GLN) must be mapped to SAP master data:
- Sender -> SAP Sender (Customer or Logical system)
- Buyer -> SAP Sold-to Party
- Delivery point -> SAP Ship-to Party
- Supplier -> internal business division
Partner Roles in Different EDI Standards
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.
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.
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.
Acknowledgements
Thanks to my colleagues at Capgemini and others who explored this topic with me across numerous projects: David Knight , Corey Legault , Uwe Schieferstein , Ralf Helm , Jekaterina Bule, and many other experts from SAP and EDI worlds.
Nenhum comentário:
Postar um comentário