We’re experiencing critical BOM synchronization failures in our recipe management system after importing master data from our ERP system. The import completes successfully, but when we try to approve recipes, the system throws unit of measure inconsistency errors.
The error specifically mentions that the base unit in the BOM doesn’t match the recipe unit configuration. We’ve verified the master data import validation logs and everything appears correct there. The synchronization logic seems to fail only when processing recipes with alternative units of measure.
This is blocking our recipe approval workflow entirely - we have 47 recipes stuck in draft status that need to go live next week for our new product line. Has anyone encountered similar BOM sync issues with CUNI transaction after master data imports?
Before you correct the conversions, you need to identify all affected recipes and BOMs. Run SE16 on tables MAST (material to BOM link) and STPO (BOM items) to find which BOMs use those materials. Then check RCPV (recipe versions) for dependencies. Make the corrections in a test system first and validate that existing approved recipes still calculate correctly. The BOM sync will need to be retriggered for all draft recipes after the fix.
Here’s the complete solution addressing all three aspects:
BOM Synchronization Logic Fix:
The synchronization failure occurs because SAP PLM recipe management validates UoM consistency across multiple dimensions during BOM sync. You need to understand the validation sequence: Material Master → BOM Header → BOM Components → Recipe Header → Recipe Operations. Each level must have compatible UoM definitions.
Unit of Measure Configuration Correction:
First, identify all problematic conversions:
SELECT matnr, meinh, umrez, umren
FROM t006a
WHERE mandt = '100'
AND (umrez = 0 OR umren = 0)
For your reversed conversion factors, you’ll need to correct them in CUNI transaction. Document current values first, then update with correct numerator/denominator ratios. For example, if you have KG→G showing 1000:1 but it should be 1:1000, fix it carefully as this affects all calculations.
Master Data Import Validation Enhancement:
Implement enhanced validation in your import profile:
- Add custom validation step to check UoM conversion logic before BOM sync
- Validate that base UoM in material master matches recipe type allowed UoMs
- Verify conversion factors are mathematically consistent (A→B and B→A should be reciprocals)
- Check that all alternative UoMs in BOMs have valid conversions to recipe base UoM
Recovery Steps:
- Export current T006A data for affected materials as backup
- Correct conversion factors in test system using CUNI
- Run transaction C223 to check recipe-BOM consistency
- Re-sync BOMs for all 47 draft recipes using transaction C201
- Test one recipe approval end-to-end before batch processing
- Apply fixes to production and monitor sync logs
The key is that master data import validation must go beyond existence checks - it needs semantic validation of UoM relationships. Consider implementing a custom BAdI at the import validation point to catch these issues before they reach the BOM sync stage.
This is exactly why we implemented pre-import validation scripts. Your master data import validation needs enhancement to check UoM conversion logic, not just existence. We wrote a custom ABAP program that validates conversion factors against business rules before import - catches reversed ratios, missing decimals, and incompatible unit types.
I’ve seen this before! The BOM synchronization logic in recipe management validates UoM at multiple levels. You need to verify: 1) Material master base UoM matches recipe header UoM, 2) All BOM component UoMs have valid conversions defined, 3) The import didn’t create orphaned UoM entries. Check table T006A for your material-specific conversions. Also review the master data import validation settings - sometimes the validation passes but creates inconsistent data that only surfaces during BOM sync. What does your import profile look like for UoM handling?
Thanks Sara - checked T006A and found the issue! Several materials have conversion factors but the denominator/numerator are reversed. The import validation didn’t catch this because it only checks for existence of conversions, not correctness. How do I fix this without breaking existing recipes?
Check your unit of measure conversion tables in transaction CUNI. Often the issue is that the master data import creates entries without proper conversion factors between base and alternative units. Run a consistency check on your material masters first.