Issue
Syensqo has close to 700 non-standard/custom units of measure 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
It is recommended to use only the standard UoMs available within the S/4HANA 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 UoMs 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.
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.
| System | Non-Standard UoM's | POs in past 5 years | PO's with non-Standard UoM | % | UoM's used in affected POs | Materials changed in 10 Years | Materials with Non-Standard UoM | % | UoM's used in Material Masters |
| QF2 | 404 | 4,642,346 | 184,587 | 4% | 66 | 613,651 | 27,648* | 5% | 32 |
| WQ2 | 357 | 2,877,450 | 82,007 | 3% | 73 | 567,413 | 5,995 | 1% | 51 |
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 can 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
Communication
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.
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 conversions.
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 Invoices/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.
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 SAP/ISO UoMs and possibly support them by mapping to a S/4 Standard at the point of integration. This would let the system accommodate non standard UoMs from suppliers or customers but only have Standard UoMs within the S/4 System. This would be achieved using enhancements and on an exception basis.
Impact on 3rd Parties
Suppliers and Customers should not be using non standard ISO Codes going forward and should be pushed to stop doing 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 |
|
|
| Impact on suppliers/Customers |
|  Suppliers/customers don't have to change |
| Impact on data migration |
| no mapping required |
| Requires enhancement |
| no enhancement required |
| No recreating errors already solved in ECC |
| no impact |
| Maintain UoMs across landscape |
|  Custom UoMs need to be maintained |
Benchmark comparison
The project team have worked on other implementation projects where 700+ custom UoMs were successfully converted to ISO standards without any exceptions, so an approach to align to standard seems feasible.
Data from other standardisation projects shows that typically non-standard UoM usage occurs for one of 3 reasons:
- Using non-standard UoM because it was possible for users to conveniently create these, and use of standard UoMs was not enforced.
- Used for order of magnitude conversions (e.g. ppb vs ppm) - there is now better SAP functionality to handle this with standard UoMs
- Older legacy use cases which needed custom UoMs, but which now have standard functions available.
See also
Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.
