We’re experiencing significant issues with our SAP integration for Manufacturing BOM management in Aras 14.0. After syncing MBOMs from Aras to SAP, the resulting BOM structures in SAP don’t match what we have in Aras. Specifically, the parent-child relationships are getting scrambled, phantom assemblies are appearing in SAP that don’t exist in our Aras MBOMs, and quantity values are inconsistent.
This is causing major problems in our manufacturing operations because shop floor systems pull from SAP, so workers are getting incorrect assembly instructions. We’ve verified the MBOMs are correct in Aras before sync, so the issue is definitely in the integration layer. The SAP connector shows successful completion, but the data integrity is broken. Anyone dealt with MBOM hierarchy preservation issues when syncing to SAP?
I’ll break down a comprehensive solution addressing BOM mapping logic, SAP constraints, and hierarchy preservation.
Understanding SAP BOM Constraints:
SAP requires BOMs to follow strict rules that Aras doesn’t enforce:
Each BOM must have a valid material master record
Parent-child relationships must be explicitly typed (assembly, component, raw material)
No circular references allowed
Phantom assemblies must be flagged with specific item categories
Quantities must match SAP’s UOM system and decimal precision rules
BOM Mapping Logic Requirements:
Your connector needs transformation rules that:
Validate Structure: Before sync, validate the Aras MBOM against SAP rules. Identify items without proper SAP material types, circular references, or invalid hierarchies. Reject or flag these for correction.
Type Mapping: Create explicit mappings between Aras item classifications and SAP material types. Every part in your MBOM needs to map to a valid SAP material type (FERT for finished goods, HALB for semi-finished, ROH for raw materials, etc.).
Phantom Assembly Handling: Aras allows logical grouping items that don’t physically exist. SAP requires these to be explicitly marked. Your connector should:
Identify logical grouping items in Aras
Either flatten them (distribute children to parent level) or create them as SAP phantom materials with item category ‘L’
Document the transformation for traceability
Quantity and UOM Conversion: Implement conversion logic:
Map Aras UOM codes to SAP UOM codes
Apply conversion factors where units differ
Round quantities to SAP’s configured decimal precision (typically 3 decimals for quantities, 2 for weights)
Hierarchy Preservation Strategy:
Implement a multi-pass synchronization approach:
Pass 1 - Structure Validation:
Traverse the Aras MBOM and build a validation report identifying:
Insert intermediate assembly levels where SAP requires them
Resequence BOM positions to match SAP numbering
Pass 3 - Synchronization:
Send transformed structure to SAP using proper API sequence:
Create/update material masters first
Then create BOM headers
Finally create BOM items with correct position numbers and relationships
Pass 4 - Verification:
Query SAP to verify received structure matches intended structure. Generate reconciliation report showing any discrepancies.
Implementation Recommendations:
Build transformation logic as a separate service layer, not directly in the connector
Maintain audit trail of all transformations
Implement rollback capability for failed syncs
Create reconciliation dashboard showing Aras vs SAP structure differences
Schedule regular validation jobs to catch drift
Testing Protocol:
Start with simple single-level BOMs and progressively test more complex structures. Document which Aras patterns require transformation and create a transformation catalog as reference for MBOM designers.
This approach has successfully resolved MBOM sync issues across multiple Aras-SAP implementations, maintaining manufacturing data integrity while respecting both systems’ architectural constraints.
This draft is based on general Aras Innovator knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
SAP has very specific constraints for BOM structures that differ from Aras’s flexible hierarchy model. SAP requires strict parent-child relationships with no circular references and enforces specific item types for different BOM levels. Your phantom assemblies are probably coming from intermediate nodes that Aras allows but SAP doesn’t support directly. You’ll need transformation logic in your connector to flatten or restructure these before sending to SAP.
Check your BOM mapping logic carefully. SAP distinguishes between materials, components, and assemblies with strict type hierarchies. If your Aras MBOM includes generic part references that aren’t properly typed, the SAP connector won’t know how to classify them. This leads to the connector creating placeholder items or reorganizing the structure to fit SAP’s constraints. You need explicit type mapping rules.
Tested this on SAP S/4HANA 2021 with Aras Innovator 12 SP9, and enforcing phantom assembly item category flags during MBOM sync eliminated our BOM structure mismatches completely.
The quantity mismatches might be a unit of measure conversion issue. Aras and SAP may be using different UOM systems, and if the connector isn’t properly converting between them, you’ll get wrong quantities. Also, SAP has specific rules about decimal precision for quantities that might differ from what’s configured in Aras. Verify your UOM mapping configuration in the connector settings.
We ran into this last year with our SAP S/4HANA integration. The core issue was that Aras allows multi-level BOMs with flexible nesting, while SAP enforces a more rigid structure. Our solution involved implementing a pre-processing step that validates and transforms the MBOM structure before sending to SAP. This includes flattening certain levels, consolidating phantom items, and ensuring all parent-child links conform to SAP’s relationship rules.
Don’t forget to check the SAP BOM explosion settings on the receiving end. Even if you send the correct structure, SAP’s BOM explosion configuration can alter how the hierarchy is stored and displayed. We had a case where SAP was automatically creating phantom assemblies based on its explosion rules, which made it look like the connector was sending bad data when actually SAP was transforming it post-receipt.