CAD to BOM synchronization fails in program management due to duplicate part numbers

PLM Windchill
, , , , , , , ,
1

We’re experiencing critical issues synchronizing CAD structures to BOMs in our program management module. When engineers attempt to create manufacturing BOMs from CAD assemblies, the process fails with ‘Duplicate part number detected in BOM hierarchy’ errors.

The problem occurs specifically when CAD part numbers are assigned using our legacy numbering scheme that allows reuse across different product lines. Our BOM sync rules apparently don’t account for this:

Error: wt.fc.PersistenceException
Duplicate part number: ASM-2401-R3
at BOMSync.createBOMStructure(BOMSync.java:234)

This is blocking our manufacturing planning for Q2 product releases. The CAD models are correct and validated, but the BOM creation step consistently fails. We need the synchronization to either handle duplicate numbers intelligently or provide clear guidance on part number assignment strategies that work with both CAD and BOM requirements.

system 2

For anyone else hitting this, here’s what actually works. The duplicate part number issue during CAD-BOM synchronization stems from inadequate part number assignment governance and sync rule configuration.

CAD Part Number Assignment Strategy: First, you must establish whether your organization uses context-independent (globally unique) or context-dependent (reusable within contexts) numbering. For manufacturing planning, context-independent numbering is strongly recommended. Configure your CAD integration to call Windchill’s NumberGenerator service:

NumberGenerator numGen = NumberGenerator.getNumberGenerator();
String partNumber = numGen.generateNumber(WTPart.class, containerContext);

This ensures CAD parts receive Windchill-managed numbers that respect your uniqueness rules.

BOM Sync Rules Configuration: Modify your BOM synchronization rules to handle existing duplicate scenarios. In the BOMTransformer configuration, enable duplicate resolution:


com.ptc.windchill.bom.duplicateResolution=CONTEXT_AWARE
com.ptc.windchill.bom.numberPrefix.enabled=true
com.ptc.windchill.bom.numberPrefix.source=PROGRAM_CODE

This configuration tells the sync engine to append program context identifiers when duplicates are detected, creating unique BOM part numbers while preserving CAD number traceability.

Manufacturing Planning Impact: For your Q2 releases, implement a two-phase approach:

  1. Short-term: Use the duplicate resolution configuration above to unblock current synchronizations. The system will create BOM parts with context-aware numbering (e.g., PROG-A:ASM-2401-R3).
  2. Long-term: Establish a numbering governance policy requiring all new CAD parts to use Windchill-generated numbers. For existing parts, run a batch renumbering utility during a planned maintenance window.

The manufacturing impact is significant because BOM structures feed MRP and production planning. Inconsistent numbering creates traceability issues and can cause material procurement errors. By implementing proper sync rules, you maintain the engineering-to-manufacturing data flow while preventing duplicate conflicts.

Additionally, configure your program templates to enforce numbering policies at the project creation stage, preventing future occurrences of this issue.

This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen this pattern before. The issue is that Windchill’s BOM sync expects globally unique part numbers within the context hierarchy, but your CAD numbering allows context-specific reuse. You need to check your number generation policy configuration and ensure it’s set to enforce uniqueness at the appropriate organizational level.

marco_code 4

Tested this on Windchill 12.1 with Creo 8.0 and configuring context-independent numbering via the NumberGenerator service eliminated all duplicate part conflicts during CAD-BOM sync.

5

Are you using Creo Parametric with auto-numbering enabled? We had a similar situation where the CAD system was generating numbers independently of Windchill’s numbering service. The synchronization would fail because the parts existed in CAD with numbers that conflicted with existing Windchill objects. Check if your CAD integration is configured to use Windchill’s numbering service rather than local CAD numbering. Also verify that your product context settings aren’t allowing number reuse across programs.

6

We are using Creo Parametric. The CAD team has been using local numbering for years because it’s faster during design iterations. I suspect that’s the root cause, but we have thousands of existing CAD files with these numbers. How do we transition without breaking everything?

7

The transition is definitely manageable but requires planning. First, you need to implement a number mapping strategy during synchronization. Create a custom synchronization rule that prefixes or transforms CAD numbers based on the product context or program. For example, if part ASM-2401-R3 exists in Program A and Program B, the BOM sync could create BOM parts as PRGA-ASM-2401-R3 and PRGB-ASM-2401-R3. This preserves your existing CAD data while ensuring BOM uniqueness. You’ll need to customize the BOM creation logic to handle this transformation. It’s not ideal long-term, but it unblocks manufacturing while you plan a proper numbering governance strategy.

8

Another option is to leverage the alternate identifier framework. Instead of changing the primary part number, you can configure the BOM sync to use a combination of number plus context as the unique identifier. This requires modifying the sync service configuration but maintains your existing numbering scheme. The key is understanding that manufacturing BOMs often need different identification strategies than engineering CAD structures.