Don't ignore Units of measures!
In the previous article on Material determination, I deliberately ignored the requirements and features related to units of measure (UoM). While this topic may seem simple for companies that only use "pieces" in sales orders, most distributors require the flexibility to process at least pieces and boxes. And in some cases, they meet overwhelmingly complicated requirements, such as when "eaches" and "pieces" have different meanings, or when packages must be mapped to different UoMs depending on the customer and material.
It's also important to highlight the specific nature of UoM conversion. Whereas material determination data, as well as partner determination data, clearly relate to Master data, UoM mapping is not as variable and is usually considered as settings. The main outcome of this is that an EDI provider (or EDI VAN in the US) might provide some mapping and processing, which is definitely not applicable for Master Data.
UoMs in SAP Sales and Distribution
Basic UoM determination
The process of handling units of measure (UoM) during the creation of a sales order deserves explanation. Consider the simplest case illustrated below: an IDOC ORDERS containing two items, with quantities of 10 PCE (Piece) and 5 CT (Carton), as shown in the screenshot below (transaction code WE19). The UoM is stored in the field E1EDP01-MENEE.
In the sales order created by this IDOC you will see 10 PC and 5 CAR
And in the VBAP table you can also find ST and KAR as unconverted value for these UoMs.
What's connection between these PCE, PC and ST?
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 were used in the IDOC.
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.
Errors during basic UoM determination
Let's explore potential errors that might occur during this UoM determination step.
In the example below, there are KT (Kit) and CG (Card). These UoM codes are recognized by both ASC X12 and EDIFACT standards; however, in the standard installation of SAP ERP, CG isn't listed as an ISO code, and KT, while listed, isn't assigned to any UoM.
This discrepancy causes the IDOC to fail with the same error for both item lines:
"Message No. VG011 ISO unit of measure CG is not assigned (item )"
To resolve this error within the basic determination technique, an ISO code must be created and assigned to a UoM. This highlights a significant limitation of the basic technique: it's impossible to map multiple external codes to a single system UoM. For instance, if customers send EA and PCE while you only want to process PC, you can set up PCE as the ISO code for PC. However, you can't assign EA as an ISO code to the same PC because the field is already occupied by PCE. Below, I'll suggest several ways to handle such cases, using some tricks and advanced techniques to satisfy this common requirement.
UoM check during Sales order creation
For successful Order creation, it's also crucial that the UoM is determined for the material.
The same as during manual sales order creation, a UoM can be applied to the material, if it's defined in MM03 Material master > Additional data > UoM. In the example below, PCE and CAR are determined for the material, but EA is not.
As a result, this UoM isn't allowed during the creation of a sales order.
As the creation of Sales order during IDOC ORDERS processing works as Batch processing, about the same as manual creation, the same error appears during IDOC processing.
Errors during UoM check
Let's examine the errors that occur during UoM determination. For instance, a customer sends EA (Each), which is converted to EA according to CUNI settings. However, EA is not determined for this material in the master record.
This discrepancy causes the IDOC to fail with the same error for manual creation:
Message No. V1384 Sales unit EA is not defined for item 000010
To address this issue directly, the UoM must be determined for the material. However this solution leads to a challenging trade-off: maintaining several UoMs with the same meaning in the system just to meet customer requirements.
Trade-offs and Benefits of Standard UoM Determination
Let me recup the basic technique and its subsequent trade-offs and benefits:
- Customers orders goods in pieces using external codes PCE and EA.
- 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.
- Both EA and PC are determined for the material with the same meaning (1 PC = 1 EA)
- 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.
UoM conversion by EDI Service Providers or Middleware Mapping Tool
The first option to handle complicated requirements is located outside the SAP ERP core solution. Typically, all EDI messages are processed through EDI Service Providers, also known as EDI Value-Added Network (EDI VAN) in North America. Unlike SAP ERP, EDI providers actually focused on the message transmission and conversion and have convenient tools for mapping. UoMs can be considered as configuration with a fairly limited range of rules to implement, as opposed to master data like material and partner determination. Following the previous example, an EDI provider might implement a rule to convert inbound EA to PCE, resulting in SAP ERP receiving and processing only PCE. Also, an EDI provider might establish a customer-related rule to convert PCE to EA for outbounds. Another useful trick is to copy the customer UoM to the dedicated item sales text. The EDI provider adds such standard SAP text to IDOC ORDERS, then this text is stored in the sales order and copied through standard sales text techniques to subsequent documents. As SAP ERP includes all texts in outbound messages, this data is available for outbounds, and the EDI provider might use the stored value to send it to the customer.
The advantage of this approach is that it keeps SAP ERP simple and clear. The disadvantage is that it usually takes time to implement a rule on the EDI provider's side, up to 2-6 weeks. And such specific mapping might be provided for free as part of the service contract, or it might require an extra cost for adjustment. However, it's usually cheaper than any development on the SAP ERP side.
Similar conversions can also be implemented on some middleware if it's used in a landscape, such as SAP PI/PO/XI, SAP Integration Suite, or one of the wide range of solutions available on the market. Typically, it's maintained by another team, so the advantages and disadvantages in this case are similar.
UoM determination by Material substitution technique (VB12)
The material substitution technique for EDI ORDERS processing, as detailed in my previous article on Material determination , can also apply to UoM determination. If a material substitution rule is activated and the UoM is unspecified in the message, the UoM from the rule is applied.
Let's see how this technique works based on the most valuable business case: EAN based material determination for goods with multiple retail packaging options.
In the example below material 1521 is linked to two EANs: 8427324815219 for a single item and 8427324815226 for a pack, which is a twinpack.
In retail, these differing EANs enable the sale of both single items and twin packs. On the customer side, these are considered distinct products and counted in EA, leading to orders like:
- Item 10: 10 EA of EAN 8427324815219 - ordering 10 single items
- Item 20: 10 EA of EAN 8427324815226 - ordering 10 twin packs
In order to process such order following technique might be applied:
Material substitution records for EANs must be created and PAC UoM is assigned to the relevant EAN.
Then a customer UoM has to be excluded from the inbound IDOC, by an EDI provider, a middleware, or by IDOC ALE technique, which will be described in the next section.
As result for the item 10 UoM PC is applied because this is Sales UoM determined in the material master record. And for the item 20, PAC is determined based on material substitution record.
In the example above determination is set based on material level. For more flexibility also customer/material and other reliable determination levels might be applied.
As you can see, this approach might be pretty valuable if it meets some business conditions. However there are some inconvenient limitations, e.g. ignorance of customer UoM.
Converting Data Between Sender and Receiver by ALE for IDOCs
Special thanks to David Knight for introducing this technique to our current project. Prior to this, I addressed such requirements either through the EDI provider or with ABAP extensions.
This feature is a part of IDoc Interface / Application Link Enabling (ALE) functionally which is available for SAP ERP, both ECC and S/4. This technique provides wide range of conversions and editing options for IDOCs and also suitable for EDI processing. Essentially, this technique allows to establish a rule to replace some value to another value for a certain field of IDOC from a specific sender.
The related settings might be find by following way:
- t-code SALE > Modelling and Implementing Business Processes > Converting Data Between Sender and Receiver
- IMG SPRO > ABAP Platform > Application Server > IDoc Interface / Application Link Enabling (ALE) > Converting Data Between Sender and Receiver > Converting Data Between Sender and Receiver
- Direct access using t-codes:
- BD62 - Define Segment Conversion Rule
- BD79 - Maintain IDoc Conversion Rules
- BD55 - Maintain IDoc Conversion
Let's see how it works base on the following example:
A customer places an order using UoM BX (box, crate), which has to be converted to CAR (Carton), but this UoM is already assigned to ISO code CT. Without additional settings BX fails with an error ISO unit of measure BX is not assigned (item ).
By following configuration, the rule for conversion BX to CT might be added, as result BX will be processed as required.
Create a new rule title: BD62 - Define Segment Conversion Rule
Create a name and short description of the rule and assign to related IDOC segment
- Conversion rule: Z_UOM_CONVERSION_1
- Description: UoM conversion for Inbound sales ORDER
- IDOC segment name: E1EDP01
Define conversion: BD79 - Maintain IDoc Conversion Rules
- Chose Maintain for the conversion rule created above
- Select and drill-down to the field MENEE
- Select Convert sender fields radio button, add field MENEE to "Sender fld"
- Drill down to Conditions, add a record to convert BX to CT (watch out, source value is in the right field, target is in the left field)
- Set up defaults: select Copy sender field and define Sender field MENEE
As a result BX value will be converted to CT while all another values will keep unconverted.
Assign created rule to required interchange: BD55 - Maintain IDoc Conversion
- Select required message type on the first screen.
- Add a record for required interchange. Sender and receiver data are set according to converted IDOC data and assigned to the segment E1EDP01, and conversion rule Z_UOM_CONVERSION_1 created above.
As a result, the conversion rule will be applied to every IDOC that meets conditions described. In this example, sender is set as an LS Logical system, which aligns with the strategy of creating a single LS partner for the EDI provider in WE20 Partner profiles. Consequently, all orders received through this provider will utilize this partner record, and the conversion rule will be applied to all relevant customers. Alternatively, if the KU Customer partner profile is established for every single customer, the created rule might be assigned to one or several customers, with other rules applied to different customers. The second option provides greater flexibility but requires more maintenance effort.
Let's discover conversion example:
According to the conversion rule, BX is converted to CT at the preliminary step of IDOC processing and, as a result, CT is visible in the saved IDOC.
Conversion using IDoc / ALE functionally is widely applicable and flexible, capable of incorporating complex rules and extensions.. However it's pretty far from well known business related transactions, requiring intricate maintenance and lacking transparency for key users.
In conclusion, I need to admit that not all customer or business requirements can be addressed by the techniques mentioned above. I such cases, custom development becomes a necessary last resort. Nonetheless, I hope that a thorough understanding of SAP’s standard features can help minimize unnecessary development, which is often more complex and costly over the system’s lifecycle."
UoMs in Other SAP Modules
One might hope that SAP ERP utilizes a consistent logic for handling messages across all its applications. Ideally, such a holistic approach would simplify processes, but, unfortunately, this is not the case. The logic described earlier, where an external code in an IDOC is mapped to an internal code, applies specifically to Sales and Distribution applications. However, expecting the same behavior from other SAP modules could lead to misunderstandings. Let's delve deeper into this topic.
IDOCs, widely used for external interchange, actually based on "ISO code" approach. For instance, basic types like ORDERS05 and INVOIC02 utilize the same segment type E1EDP01 with a single UoM field, MENEE. Similarly, basic types like DELVRY07 and SHPMNT06 use segment E1EDL24, fields VRKME and MEINS, and basic type DESADV01 use E1EDP09-VRKME. For inbound messages based on these types an ISO code, e.g. PCE, is required, and for outbound messages, the ISO-code is filled by the system. However let's learn a couple of examples with a different approach, more closely related to Warehouse Management System (WMS) or 3PL integration rather than traditional trading interchange.
One such example is MBGMCR03 Post Goods Movements with MB_CREATE_GOODS_MOVEMENT. This message aligns with the BAPI BAPI_GOODSMVT_CREATE, and contains two fields for UoM in the item segment E1BP2017_GM_ITEM_CREATE:
- ENTRY_UOM for the system code, e.g., PC.
- ENTRY_UOM_ISO for ISO code determined in CUNI, e.g. PCE
Another case that initially caught me by surprise, and significantly drew my attention to this topic, involves WMMBID02. This IDOC type, used for stock movements from external systems, contains the segment E1MBXYI, which only has one field for the system code, ERFME (e.g., PC), without a corresponding ISO code field.
Within the SAP environment, this discrepancy typically doesn't cause issues, as both the sending and receiving functionalities are designed to process the required data format. It’s often overlooked that the nature of fields can differ; for example, if EA is assigned as both the system code and the ISO code, neither users nor counterparties may notice that SHPCON and WMMBXY use different data types. However, unexpected system behavior can sometimes lead to surprises.
This became apparent during one of my projects where we set up a series of messages for interchange with a Third-Party Logistics (3PL) provider. We meticulously prepared DESADV based on DELVRY06 and SHPCON based on DELVRY03, then implemented WMINVE, ACC_DOCUMENT, ORDERS, and WMMBXY. The primary UoM for interchange was BX (box), assigned as both the system code and the ISO code. In the rare situations where a box was broken down, the piece UoM was used and, for all messages, was described and tested as PCE. WMMBXY was one of the last messages tested, and the development team on the 3PL side, adjusting their non-SAP system, applied the same logic to WMMBXY. Smoke testing with BXs was successful. However, during User Acceptance Testing, a scenario failed because SAP sent PC in WMMBXY, while PCE was expected! Explaining to external developers why “our SAP” couldn’t use the same UoM for every message, and agreeing on a CR with project managers during the UAT phase, was not straightforward.
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).
Appendix: The Zoo of Units of Measure in EDI Projects
In my EDI projects, I've encountered a wide variety of units of measure (UoMs), far exceeding the range preinstalled in SAP ERP settings. To fully grasp this diversity's origins and compare it with SAP's methodology, it's essential to understand the frameworks governing the EDI world.
There are two main framework standards in EDI world for trading messages: the global UN EDIFACT and ASC X12, which is dominating in North America. Both standards include comprehensive code lists for UoMs.
UN EDIFACT
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 , a global standard for units of measurement in international trade developed by The United Nations Economic Commission for Europe.
Sales units defining quantity of goods belong to "Level 3 – informative units omitted from the normative annex, Annex I, but found in the informative annexes, Annex II and Annex III", and are listed in Annex II/III. Also some of them also 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 as a part of Recommendation 21, and included into Recommendation 20 as informative units. However as Sales units and type of packaging are different entities for SAP ERP data model, I suppose Recommendation 20 is more relevant for understanding of quantity UoMs. UoMs listed in Rec 20 might have length 2 or 3 characters, while all the listed in Rec 21 have length 2 characters. Also, based on my experience, I can conclude, that all the UoMs which are relevant for sales order quantity, are 2 characters long.
ASC X12
The Accredited Standards Committee X12 (also known as ASC X12) is chartered by the American National Standards Institute (ANSI) and have developed and maintained the X12 Electronic data interchange (EDI) standard.
This standard defines an element 355 Unit or Basis for Measurement Code which is widely used within different messages. Starting form 325 UoMs according to the release 2010 published in 1987, the current 8050 release (2024) enlists 927 UoMs. All the UoMs codes related to this element are 2-characters long.
SAP UoMs
As it was described above, there are two UoM coding entities in the SAP ERP. So called ISO code is a list of external codes which might be assigned to internal ones. Internal code is a list of UoMs which might be assigned to countable items, and this code is represented as an unconverted technical code, invisible for users and as language-dependent name.
Frankly speaking I haven't find what was a source of the SAP UoM code systems, please add your comment if you know this. In general, we need to consider that SAP codes sometimes match EDIFACT or X12, but might be unique.
I've collected some remarkable examples for you:
- EA means Each for X12, EDIFACT Rec 20, and for SAP ISO, SAP unconverted and converted to English
- BX means Box for X12, EDIFACT Rec 20 and Rec 21 and SAP ISO, although named Crate
- CT means Carton for X12, EDIFACT Rec 20 and Rec 21 and SAP ISO
- PC means Piece for X12 and SAP converted to English, however means Parcel for EDIFACT Rec 21 and not listed for Rec 200
- PCE means Piece for SAP ISO only, not listed in other standards
- KG means Kilogram for X12 and SAP unconverted and converted to English, while for EDIFACT Rec 20 and Rec 21 and SAP ISO it means Keg
- ST means Set for X12, Sheet for EDIFACT Rec 20 and Rec 21 and SAP ISO and Piece (Stuk) for SAP unconverted
- SAP Managed Tags:
2 Comments
