Issue

This document evaluates the options for dealing with Syensqo has close to 700 non-standard/custom units of measure (ie non SAP / ISO Standard ones) and any customised conversions (eg from ISO to SAP) that have been created over time by Syensqo for use with Supplier and Customer integration, Ordering and Invoicing.

Using non standard UoMs / Conversions across the system will impact any internal integrations we have (eg between Ariba, TM and S/4 etc) 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 S/4 HANA.

Recommendation

It is recommended to use only the standard UoMs within the S/4 HANA system and other linked systems 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 - adhering to the ISO standard.

For legacy data using non standard UoMs these will have to be mapped and switched to standard UoMs at the point of data migration to ensure legacy data is compatible with the S/4 system.

created in the system. 

• These non-standard units of measure might cause data consistency issues as the definitions and the conversions are not standardised
• These custom units of measure cause issues with integrations with other SAP modules or 3rd party systems that do not recognise these units

Recommendation

Based on the evaluation of the solution options, it is recommended to Use SAP / ISO Standard UoMs and conversions. This follows the Simplification/Standardisation approach of the project and ensures consistency and ease of integration across the landscape.

Any legacy data using non-standard UoMs will be mapped to standard UoMs during data migration.

Background & Context

Syensqo has close to 700 non-standard/custom units of measure created in the system. These units are historically created to cater to UoM's published by suppliers in various catalogs and also as a workaround to support certain business processes. Below are some of the issues faced currently 

• Incorrect Conversion Factors - Missing or incorrect conversion factors between non-standard UoM's sometimes cause calculation errors e.g., in pricing, inventory etc.
• Reporting and Analysis Errors - Non-standard UoM's create issues in reporting and analytics, leading to miscalculations or inaccurate data representation and aggregations
• Incompatibility with SAP Standard Functions - Some SAP standard functions (e.g., MRP, ATP checks) do not fully support non-standard UoM's, or require additional customisation
• User Confusion and Data Entry Mistakes - Non-standard UoM's sometimes lead to user confusion and result in data entry mistakes, especially when the same unit of measure is shared across multiple business units

Scale of Issue

Below table provides the statistics of non-standard UoM's in the system along with the usage of the same. 

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 but most large suppliers now adhere to the ISO standard.

Benchmark comparison

In other clients we have soon systems with 700+ custom UoMs fully converted to SAP/ISO standards.

Investigating Syenqso's internal usage of these custom UoMs implies this should be the case here as historical uses fall into 3 categories,

1. Using non-standard UoM because it was possible and standard UoMs were not enforced
2. Used for order of magnitude conversions (e.g. ppb vs ppm) - there are now SAP recommendation to handle this with standard UoMs
3. Older legacy use cases which needed custom UoMs, but which now have standard functions available. 

Assumptions

The majority of suppliers and customers will be able to adhere to the SAP standard or ISO Units of Measure. This will require investigation to confirm.

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
• We do not have total control over what UoMs suppliers send in via Punchout Catalogs and what customers send in via their Purchase Orders

Impacts

However, it is important to consider potential drawbacks or challenges associated with 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 them 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.

As a part of the above analysis, though there are ~700 non-standard UoM's that are existing in the system, there are only ~200 of them are currently active and being used in material master and Purchase Orders. 

Assumptions

• Business processes are simplified and standardised and will not have any requirements for non-standard units of measure
• Punch-out catalogs used by Syensqo will have standard ISO units of measure - In case of any exceptions, the unit of measure in the catalog will be mapped to a standard unit of measure in SAP

Constraints

N/A

Impacts

Data Migration

• All dependent master data ex: Material master, BOM's etc.. will be updated with the standard unit of measure (All the quantities in these data objects ex: BOM Header quantity, MOQ in material master will be updated based on the conversion factors)
• Stock quantities ex: Inventory, Stock in transit etc.. will adjusted based on the standard UoM before migrating to the new system
• Prices ex: Info records, pricing conditions etc.. will be adjusted based on the standard UOM before migrating to the new system

Downstream systems

• Any downstream system using the master data with non-standard UoM will be updated with new UoM and conversions. Mapping table will be used in case the UoM updates are not possible

Communication

• Communication along with the mapping for non-standard to Standard UoM's will be sent to the relevant customers / Vendors / 3rd party systems 

Business Rules

All the master data and Business processes use only Standard SAP / ISO Units of Measure

Options considered

Following are the options considered.

Option 1: Use SAP / ISO Standard UoMs and conversions 

As a part of this option, all the master data and business processes use only the standard SAP/ISO unit of measures available in the system. Non-standard UoM's are not permitted to be created / used. Mapping activity will be carried out when the master data / transactional data is migrated from the legacy systems to the new S/4 HANA system.

Advantages:

• UoM's and conversions are standardised across all the master data objects and business processes
• No additional effort / customisations required to enable the standard SAP functionality
• Uniform and Simplified reporting as the UoM's and conversion factors are standardised
• Standard integrations without any additional data mappings with other modules of SAP, SAAS systems and any other 3rd party applications

Disadvantages:

• One time data conversion effort to map the master and transactional data with standard UoM
• One time data conversion / mapping of the non-standard UoM's in the downstream systems
• Business processes that require creation of the non-standard UoM needs to be remediated

Option 2: Allow the use of non-standard UoM's

As a part of this option, the existing As-Is active non-standard UoM's are migrated to the new S/4 Hana system.

Advantages:

• The existing processes can continue without any changes
• No data migration/mapping effort except when there is de-duplication of master data

Disadvantages:

• No standardisation of the UoM's across master and transactional data
• Complex governance process to govern the non-standard UoM's and the conversion factors
• User errors due to confusion and unfamiliarity of the non-standard UoM's
• Customisations and data mappings required for integrations to any SAAS or 3rd party applications
• Not all standard functionalities will be able to support the non-standard UoM's 
• Potential incorrect reporting and aggregations 

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 / ISO Standard UoMs and conversions, do not copy over any custom entries 

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

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 & customers
• May invalidate legacy data that uses custom UoMs – e.g. Supplier Invoices, POs and Customer Invocies/Sales Orders etc that would need to be altered
• If plan is only to use SAP standards, then another way of correcting the suppliers/customers who send in non-standard UoMs need to be used

Option 2: Carry over any active custom UoMs/conversions 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/customers 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

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.Option 1: Use SAP / ISO Standard UoM's and conversions is recommended. This follows the Simplification/Standardisation approach of the project and minimises any maintenance burden going forward.We can react to any UoM exceptions that cannot be switched to Standard

Standard UoM's and conversions	Option 2: Allow the use of non-standard UoM's
Alignment with project charter - Standardization and Simplification	Aligned with the Simplification and Standardisation principle	Not Aligned
Integration	Standard integration without any data mapping or customisations required for UoM's	Data mappings or customisations required for integrating with other SAP modules are 3rd party applications which doesn't support the non-standard UoM
Data Migration	One time effort to map the non-standard UoM's on the master and transactional data and migrate	No mapping required. However where there is de-duplication of materials with a standard and non-standard UoM, additional mapping effort is required
Reporting	Accurate and consistent reporting as the UoM and the conversion factors are standardised	Potential errors / requirement of mappings due to incorrect conversion factors or inconsistent use of non-standard UoM

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

Adhere to SAP Std UoMs on reports, data etc

Pro - Only Std Used 

Con - standard and custom UoMs used

Impact on suppliers/Customers

Con - Suppliers/Customers need to correct to SAP Std or cant use them

Pro - Suppliers/customers dont have to changeImpact on data migration

Con - Need to map non Std UoMs to Std on legacy data

Pro - no mapping requiredRequires enhancement

Pro - no enhancement required

Pro - no enhancement requiredNo recreating errors already solved in ECC

Con - any supplier already fixed by custom UoM will break

Pro - no impactMaintain UoMs across landscape

Pro - Std only - no impact

Con - Custom UoMs need to be maintained

See also

Change log

Workflow history