We upgraded our production environment to TC 12.3 last week and immediately ran into issues with cost rollup calculations. The process completes without errors in the logs, but the rolled-up costs are significantly off - sometimes by 30-40%.
The problem appears most severe in multi-level BOMs (5+ levels deep) where we have multiple cost elements mapped. When I validate the cost element mapping against our pre-upgrade configuration, everything looks correct in the preferences. However, the BOM structure integrity seems questionable - some child components show null cost values even though they have valid cost sheets attached.
Here’s what I’m seeing in the cost calculation service:
CostElement element = cost.getCostElement();
if (element == null || element.getValue() == null) {
logger.warn("Null cost element at level: " + depth);
}
Has anyone dealt with cost rollup failures post-upgrade? I’m particularly concerned about whether our data migration scripts properly handled the cost element relationships. Any insights on validating BOM structure integrity after major version upgrades would be appreciated.
I worked on a similar post-upgrade remediation project last quarter. The 30-40% variance pattern is classic orphaned cost element syndrome. Here’s what you need to do systematically.
First, validate your cost element mapping at the type level. In TC 12.3, the cost element mapping framework changed to support more granular inheritance rules. Your pre-upgrade mappings might be technically present but not active under the new validation rules.
For BOM structure integrity, run this diagnostic query to identify all cost sheets with broken linkages:
QuerySpec qs = new QuerySpec(CostSheet.class);
qs.appendWhere(new SearchCondition(CostSheet.class, "bomLineReference", SearchCondition.IS_NULL));
QueryResult qr = PersistenceHelper.manager.find(qs);
Once you have the list, you’ll need to rebuild the linkages. The upgrade data migration scripts in 12.3 have a gap when handling custom cost element attributes - they migrate the cost sheet objects but don’t always preserve the BOM line associations when the cost elements use custom inheritance rules.
Here’s the remediation approach:
Cost Element Mapping Validation: Export your cost element definitions from the business modeler and compare them against the 12.3 reference schema. Look for any custom attributes that might have lost their mapping rules. The migration script creates a backup file (usually in <TC_DATA>/upgrade/cost_mappings_backup.xml) - compare that against your current state.
BOM Structure Integrity Check: For each orphaned cost sheet, trace back to the original BOM line using the cost sheet’s creation timestamp and owner context. You can usually reconstruct the relationship by matching the part number and revision. Use the Cost Management validation utility with the “deep scan” option enabled - it will identify not just null references but also misaligned cost element hierarchies.
Upgrade Data Migration Scripts: The critical script is migrate_cost_structures_12_3.sql in your upgrade package. Review the transformation logic for your specific cost element types. If you used custom cost elements (not OOTB), you may need to write a補充 script to handle the mappings the standard migration missed. The script should iterate through all cost sheets, validate their BOM line references, and rebuild the linkages where null.
For your 47 orphaned instances, I recommend a phased approach: fix 10-15 manually first to establish the pattern, then script the rest. Create a rollback plan before bulk operations. Most importantly, after fixing the linkages, run a full cost rollup on a test BOM structure to verify the calculations match your expected values before applying to production data.
The validation query I provided above will give you the starting point. Once you’ve rebuilt the linkages, the cost rollup process should work correctly. The key is ensuring that every cost sheet has a valid BOM line reference and that the cost element mappings follow the 12.3 inheritance rules.
This draft is based on general Teamcenter knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen similar issues after TC upgrades. The null cost element problem usually points to orphaned references in the cost structure. Run a validation query to check if your cost sheets are properly linked to their parent BOM lines. Also verify that the cost element types in your upgraded instance match the expected enumeration values from 12.3.
“Tested this on TC 12.3 after our Q3 upgrade and the QuerySpec diagnostic immediately surfaced 47 orphaned cost element mappings causing our BOM rollup discrepancies.”
This happened to us during our 12.2 to 12.3 migration. The cost rollup engine changed how it handles inherited cost elements in 12.3. Check your upgrade logs specifically for warnings about cost element mapping transformations. We had to manually remap about 15% of our cost structures because the migration script didn’t preserve custom cost element attributes. The BOM integrity check should be your first step - use the OOTB validation utility in Cost Management to identify disconnected relationships.
The null value check you’re doing is good, but you also need to verify the cost element mapping at the BOM structure level. In 12.3, there’s a new validation step that checks parent-child cost element compatibility. If a parent has cost element A but the child only supports element B, the rollup will skip that branch and you’ll see those discrepancies. Your 30-40% variance suggests multiple branches are being skipped. Check the cost element definitions in your business modeler - they might have lost their inheritance rules during migration.
Thanks for the responses. I ran the BOM validation utility and found 47 instances where cost sheets exist but aren’t properly linked to BOM lines. The cost element definitions look intact in the modeler, but I’m seeing warnings about missing cost element mappings in components that were created pre-upgrade. Should I focus on fixing the linkage issues first, or is there a bulk remapping approach that would be more efficient?
Focus on the linkage issues first - they’re your root cause. The upgrade migration scripts in 12.3 have a known limitation with complex cost structures. They don’t always preserve the bidirectional references between cost sheets and BOM lines when custom cost elements are involved. Before you start bulk operations, export your current cost structure configuration as a baseline. Then use the Cost Management API to rebuild the linkages programmatically. I’d recommend processing in batches of 50-100 components to avoid transaction timeouts.