Issue

This document evaluates the options for dealing with custom units of measure (ie non SAP Standard ones) that have been created over time by Syensqo for use with Supplier and Customer integration, Ordering and Invoicing.

Using non standard UoMs across the system will impact any internal integrations we have (eg between Ariba and S/4) as the UoMs have to be consistent across the entire landscape,. However retaining only standard Units of Measure could create difficulty engaging with suppliers and customers who do not use the same UoM standards as Syensqo.

Recommendation

It is recommended to use only the standard UoMs within the S/4 HANA system and other linked system to ensure consistency ease of maintenance across the landscape.

Suppliers, customers and any internal processes that require the use of non standard should be reviewed and the custom UoMs replaced with standard UoMs.

Scenarios/processes that cannot work without using non Standard UoMs should be considered only by exception. IF completely necessary these will be accommodated by using enhancements to map the non-standard UoM to an Std SAP UoM at the point of integration.  This ensures that the data in the S/4 system use only standard units.

Background & Context

In the past suppliers who did not send in a standard ISO or SAP Unit of Measure via a catalog, on an acknowledgement, or an invoice would get an error at the point of the data being entered (manually or by interface) on SAP.

This means that the transaction has to be checked and the Unit of Measure corrected by the supplier, causing delays. A fix for this issue is for the UoM to be added to the SAP UoM list as a custom unit to avoid recurrences. This has meant a gradually expanding list of custom UoMs.

The ERP Rebuild will mean a switch to SAP standard as a default. So a decision has to be made about how to handle these non standard UoMs that exist in WP1 and PF1.

• Stick only to the standard
• Copy over the non standard UoMs that are active
• Create a mapping tool to be map to suppliers custom UoMs, but do not permit any non standard UoM to be entered into SAP

Scale of issue

The volume of POs and materials that use non standard UoMs is a small % of the total activity but not insigificant.

Volume of non Standard (ie not in Standard S/4 HANA) UoMs in each system 

Note - There are more Non Std UoMs used in POs than are used in Material Masters. This is means these UoMs are used in Text Based orders in the system

Most of these come from Punchout Catalogs. These catalogs are maintained by the supplier and if they use a non Std UoM we cannot change that data ourselves.

Assumptions

Not all suppliers adhere to the SAP standard or ISO Units of Measure and will send non standard ones on Acknowledgements or Invoices

Constraints

• We wish to have SAP Standard only Units of measure within S/4 HANA to ensure that reporting and valuation is consistent and to simplify the maintenance of UoMs across the system
• We do not have total control what UoMs external suppliers use - some will use non standard UoMs

Impacts

However, it is important to consider potential drawbacks or challenges associated with adding in custom UoMs

• UoMs and mapping would have to be carried over from the legacy system either manually or by some custom extraction process.
• There is unlikely to be a standard SAP tool to do this copy over as the assumption with SAP is that the SAP and ISO UoMs are enough
• If custom UoMs are present in the system then they could be used by Syensqo staff when creating transactions and master data, rather than using htem to map suppliers own UoMs to SAP standards. This could cause confusion downstream and so a review of how these are currently handled by the system should be carried out.
• If all suppliers are no longer using non-SAP or non ISO UoMs then this may not be a live issue. To decide which ones to carry over a review of UoMs currently received on invoices would need to be be carried out.
• Accepting nonstandard UoMs without proper and complete mapping can cause confusion in standard reports, blocking global analysis.
• There may be legacy data to be transferred that uses these custom UoMs
• UoM mismatches can occur in other streams – eg O2C where customers send in non standard UoMs causing similar issues to procurement.
• If we create custom UoMs they will need to be maintained and validated across the entire system landscape to prevent any interfacing issues.
• The volume of activity not using std UoMs is significant - sticking to Std only could cause disruption

Business Rules

For the purposes of standardisation only the Standard SAP / ISO Units of Measure should be permitted within the SAP. But this does not preclude mapping non Standard UoMs to Standard ones at the point of integration.

Options considered

It would be painful to go through the same UoM errors that Syensqo has already solved by adding in custom UoMs.

However allowing non standard UoMs creates additional complexity and would need to be analysed across the system in order to see how big an issue it is and any downstream or reporting impacts.

Option 1: Use only SAP Standard UoMs, do not copy over any custom UoMs

The organisation uses only the standard SAP offering for SAP and ISO UoMs

Advantages:

• No need to ensure that UoMs are correctly replicated across the landscape
• Reduces the long-term maintenance burden as there are fewer custom elements to manage.
• No effort required to develop a process to transfer the UoMs
• No issue with non-standard UoMs impacting reports
• No potential confusion due to unexpected downstream use of non-standard UoMs
• Ensures that only standardized data is used in the new system, which can simplify future upgrades and integrations.

Disadvantages:

• May hit the same issues that have already been solved when receiving transactions from suppliers
• May invalidate legacy data that uses custom UoMs – e.g. Supplier Invoices, POs etc that would need to be altered
• If plan is only to use SAP standards, then another way of correcting the suppliers who send in non-standard UoMs need to be used

Option 2: Carry over any active custom UoMs from As Is

Take over the current custom UoMs as they are, including any mapping

Advantages:

• UoM Problems that are already solved / mapped do not re-occur
• No issue with legacy data that use custom UoMs (if any)
• No impact on suppliers that submit non standard UoMs

Disadvantages:

• Need to replicate custom UoMs across landscape
• Maintenance burden as custom UoMs will need to be supported and .
• Any pre-existing issues (e.g. in reports due to unexpected UoMs) will also re-occur (if we dont correct the data)
• May have an impact on other standard tools or integrations
• Need to develop a process to transfer UoMs 
• Risk of conflicts with standard UoMs and future upgrades or integrations with other systems.
• Potential confusion due to unexpected downstream use of non-standard UoMs
• Need to review data to see which UoMs are actually in use to avoid taking over defunct ones

Option 3: Build mapping to change non standard UoM to SAP UoMs at the point of integration with suppliers

Create mappings for non Std UoMs to the SAP UoMs at the point of integration - eg the catalog transfer, PO output, Invoice receipt, Sales Order transmission etc

This will likely require enhancements to create the actual mapping logic and will require a mapping to an SAP UoM to be agreed.

Advantages:

• UoM Problems that are already solved / mapped do not re-occur
• No impact on suppliers that submit non standard UoMs
• No impact on landscape as internally its only standard UoMs
• Reports will not be affected as only standard UoMs used
• No potential confusion due to unexpected downstream use of non-standard UoMs
• Ensures that only standardized data is used in the new system, which can simplify future upgrades and integrations.

Disadvantages:

• Maintenance burden as mapping to custom UoMs will need to be supported
• May invalidate legacy data that uses custom UoMs – e.g. Supplier Invoices, POs etc that would need to be altered
• Need enhancements to handle the mapping to the SAP Std UoMs at the integration points

Evaluation

Based on the evaluation of the solution options, it is recommended that the "Use only SAP Standard" approach is used as a starting position.

This follows the Simplification/Standardisation approach of the project and minimises any maintenance burden going forward.

We can react to any UoM exceptions that occur in testing and data load and review any custom UoM that may be required (but only by exception)

Impact on 3rd Parties

Suppliers and Customers should not be using non standard ISO Codes going forward and should be pushed to do so

Impact on Legacy Data

Need to see how many custom UoMs are used in the legacy data and take action (remap etc) where needed. 

Criteria	Option 1: Use only SAP Standard UoMs, do not copy over any custom UoMs	Option 2: Carry over any active custom UoMs from As Is	Option 3: Build mapping to change non standard UoM to SAP UoMs at the point of integration with suppliers
Adhere to SAP Std UoMs on reports, data etc	Pro - Only Std Used	Con - standard and custom UoMs used	Pro - Only Std Used INTERNALLY
Impact on suppliers	Con - Suppliers need to correct to SAP Std or cant use them	Pro - Suppliers dont have to change	Pro - Suppliers dont have to change
Impact on data migration	Con - Need to map non Std UoMs to Std on legacy data	Pro - no mapping required	Con - Need to map non Std UoMs to Std on legacy data
Requires enhancement	Pro - no enhancement required	Pro - no enhancement required	Con - enhancement required
No recreating errors already solved in ECC	Con - any supplier already fixed by custom UoM will break	Pro - no impact	Pro - no impact
Maintain UoMs across landscape	Pro - Std only - no impact	Con - Custom UoMs need to be maintained	Pro - Std only INTERNALLY - no impact

See also

Change log

Workflow history