Navigating the Complexity of Units of Measure in EDI Projects

This article focuses on a cross-functional perspective of the topic. For more SAP-related details, please refer to my post, "SAP ERP Functionality for EDI Processing: UoMs Determination for Inbound Orders", on the SAP Community Enterprise Resource Planning Blogs. I'll add the link in the first comment.

Why is UoMs determination challenging?

Let's begin with a quick quiz: if your EDI partner has used the Unit of measure ST in the EDI message, what might it mean? You can find my take in the paragraphs below.

When starting to sort out the conversion of Units of Measures (UoMs) for EDI implementation, the initial thought is to find a standard describing this coding. Is it possible? My answer is "yes, but". There are several EDI framework standards, such as EDIFACT and X12, different ERP systems with coding that might be considered industry standard, and atop that, local legal and language-dependent practices.

As my focus is on EDI trade standards and SAP ERP, I would mention two basic standards:

UN EDIFACT: This standard defines a QTY Quantity segment, containing the 6411 Measurement unit code element. Instead of providing its own UoM list, UN EDIFACT references UN/ECE Recommendation 20, Codes for Units of Measurement Used in International Trade. Sales units defining the quantity of goods are listed in Annex II/III. Also, some of them are relevant to UN/ECE Recommendation 21, Codes for Passengers, Types of Cargo, Packages, and Packaging Materials. For example, BX (box), CT (carton), and PK (pack) are considered a part of Recommendation 21 and included in Recommendation 20 as informative units.

X12: The Accredited Standards Committee X12 (also known as ASC X12), chartered by the American National Standards Institute (ANSI), has developed and maintained the X12 Electronic Data Interchange (EDI) standard. This standard defines an element 355 Unit or Basis for Measurement Code widely used within different messages. Starting from 325 UoMs according to the release 2010 published in 1987, the current 8050 release (2024) lists 927 UoMs. All the UoMs codes related to this element are 2-characters long.

The situation on the SAP side is not so straightforward. SAP ERP, both S/4 and ECC, uses two UoM coding schemes. The so-called ISO code is a list of external codes that can be assigned to internal ones. The internal code is a list of UoMs that can be assigned to countable items, represented as an unconverted technical code, invisible to users, and as a language-dependent name. Frankly speaking, I haven't found the source of the SAP UoM code systems; please add your comment if you know.

Here is my answer to the question regarding the UoM code ST:

• Set for X12 (equivalent to a piece or some package)
• Sheet for?EDIFACT Rec 20 and Rec 21 and SAP ISO
• Piece (Stuk) for?SAP?unconverted value

As you can see, establishing UoM conversion for EDI interchange requires considering which standards and systems are involved. An additional layer of complexity is added by the wide variety of customer approaches. In a simple case, all customers order pieces and just use different codes for this (PC, PCE, ST, EA). More challenging is when a vendor has several levels of packaging, and customers order boxes (BX, PK, CT), requiring the vendor to match the type of packaging required for each specific customer. The most complicated case is when a customer uses the same code with different meanings for different materials. For example, Set might be a trading item containing several objects inside, e.g., a set of tools, and the same customer might use Set for some retail packaging of 5 trading items. As a result, Set must be mapped to EA for one material and to 5 EA or 1 PK for another material.

How to Deal with UoM Complexity for EDI Projects

As you can see, high level of complexity is a rule depending on both UoM, customer and material. However, it not reasonable to maintain such detailed mapping.

Typically, the rule sequence is built to embrace complexity with reasonable effort. Let's list the mapping levels:

• no conversion, my favorite, when the same UoMs are used without any conversion. E.g. EA means Each for X12, EDIFACT Rec 20, and for SAP ISO, SAP unconverted, and converted to English.
• UoM conversion: a constant rule to convert, e.g. inbound BX (box) to SAP relevant CT (Carton)
• Customer/UoM conversion: inbound PK is converted to EA for customer A and to CT for customer B
• Material/UoM conversion: inbound ST is converted to EA for material M and to CT for material N
• Customer/Material/UoM - inbound EA is converted to CT for Customer A and material M, however for other materials this customer orders EA meaning EA

Based on my experience, there is a high risk of underestimating complexity if only the simplest levels are expected. My approach is to do the best during preliminary analysis and collecting requirements. It is necessary to collect as wide an example set as possible and to question thoroughly business users, the support team of the legacy system, the EDI provider support team, and, if possible, the counterparty's team. Then, the required complexity can be determined, as well as mitigation steps for some exclusions. E.g., if the Customer/Material/UoM case is exceptional, with just several examples, it might be reasonable to implement a patch on Middleware rather than develop a complicated solution on the ERP side.

UoM Determination in SAP ERP

While SAP ERP, both ECC and S/4, provides a sufficiently powerful solution for material determination, UoM determination isn't as holistic and flexible.

Basic UoM Determination: CUNI and ISO Code

The basic UoM setting are maintained by T-Code?CUNI (Units of measure), also available in?IMG?SPRO > SAP NetWeaver > General settings > Check Units of Measurement. This data is stored in?T006?Units of Measurement?table and some other related tables. As you can see below, unconverted system units KAR and ST are assigned to language-dependent codes CAR and PC, which are visible for user logged in English, as well as language-dependent descriptions.

And drilling down to the UoM record you will find CT and PCE, which are used in the IDOC, e.g. ORDERS.

Carton, CAR, KAR, assigned to CT

Piece, PC, ST, assigned to PCE

To sum up, for inbound order processing customers use external codes, called ISO code by SAP, and during IDOC processing SAP internal UoM is determined based on CUNI settings and displayed to user with language-dependent code and description. This step is specific for IDOC ORDERS processing.

Trade-offs and Benefits of Standard UoM Determination

Let me recup the basic technique and its subsequent trade-offs and benefits:

1. Customers orders goods in pieces using external codes PCE and EA.?
2. By CUNI settings, PCE and EA are converted to PC and EA, accordingly. Within the basic technique, it's not possible to convert both PCE and EA to the internal PC.
3. Both EA and PC are determined for the material with the same meaning (1 PC = 1 EA)
4. Sales orders are created using PC for some customers and EA for others.?

This approach has its benefits and drawbacks.

The main and, I can say, only drawback is that a multi-UoMs approach must be accepted by the entire organisation. Sales, accounting, logistic execution - all departments must be prepared to handle situations when both PC and EA, both CT and BX, are applicable with the same meaning but for different customers.?

However, there are some benefits:

• First, it allows for simple and transparent UoM processing by SAP-standard technique
• Second, it meets customer requirements for both inbound and outbound transactions. Typically, if a customer sends EA in the sales order, they expect EA in subsequent outbound messages, such as ORDRSP, DESADV, and INVOICE (or, for X12, 855 Purchase Order Acknowledgment, 856 Ship Notice, and 810 Invoice). Sometimes, they also require their UoMs in paper documents and labels. Keeping the customer's UoMs in SAP documents allows direct use for outbound transactions, without special adjustments.
• Furthermore, using several UoMs doesn't affect Material Management and Logistics execution processes. Regardless of the Sales UoM used for an order item, the basic UoM is always determined and then used for interchange with other SAP modules.

Unfortunately, even "multi-UoM" approach can't solve all possible cases. For example, customers might send the same UoM with different meaning, or one customer uses a UoM with different meaning. Fortunately,?some alternatives and advanced techniques might be applied for such and other sophisticated requirements.?

Other options and advanced techniques

If the basic technique isn't enough to meet business requirements, the following options might be considered:

• UoM mapping by EDI Service provider (EDI VAN)
• UoM mapping by middleware
• SAP ERP advanced technique: conversion by Converting Data Between Sender and Receiver by ALE for IDOCs (SALE > Modelling and Implementing Business Processes > Converting Data Between Sender and Receiver)
• SAP ERP techniques as part of Material substitution technique (VB12)

All these options have their benefits, limitations, and trade-offs.

For a detailed description and more examples, please find my post "SAP ERP Functionality for EDI Processing: UoMs Determination for Inbound Orders" on the SAP Community Enterprise Resource Planning Blogs. I'll add the link into the first comment.

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 used for investigations, creation of test examples, and preparing screenshots. The sandbox was SAP S/4HANA 2022 (S4HANA ON PREMISE Release 2022 SP 01 (02/2023) FPS).