Automated part number generation for new products reduced manual entry errors

We implemented automated part number generation in TC 12.3 to address persistent data quality issues from manual entry. Our previous process allowed engineers to create their own part numbers, leading to duplicates, inconsistent formats, and traceability problems during audits.

The solution uses custom part number rules based on product family, component type, and material classification. When an engineer creates a new part, the system automatically assigns the next available number in the appropriate sequence. We integrated this with our workflow so part numbers are locked once assigned, preventing changes that would break traceability.

The implementation took about three months including custom rule development and workflow integration. Since deployment six months ago, we’ve seen zero duplicate part numbers and audit preparation time has dropped significantly because part number traceability is now reliable.

Can you share details on the custom rule implementation? We’re planning something similar and wondering whether to use Teamcenter’s built-in naming rules or develop custom Java handlers. What level of complexity did your rules require?

We kept existing parts with their original numbers and applied the new scheme only to parts created after the cutover date. Migrating existing parts would have broken too many references in BOMs, drawings, and ERP. We did create a mapping table that shows which old part numbers would correspond to new scheme numbers, which helps with understanding the transition. The key was making the new system so obviously better that engineers embraced it rather than resisted.

I’ll provide a comprehensive overview of how we implemented this and the benefits we’ve realized across all three focus areas.

Custom Part Number Rules: Our numbering scheme encodes business logic directly into the part number structure: [Product Family 2-char][Component Type 1-char][Material Class 1-char][Sequential 6-digit]

Example: EL-M-S-001234 = Electronics product family, Mechanical component, Steel material, sequence 1234

The custom Java handler implements these rules:

// Pseudocode - Part number generation logic:
1. Extract product family from part's project assignment
2. Determine component type from classification hierarchy
3. Query material attribute to get material class code
4. Build prefix string from these three elements
5. Lock sequence table row for this prefix to prevent concurrent conflicts
6. Read current max sequence number and increment
7. Generate final part number and assign to item_id property
8. Log assignment details to audit table with user/timestamp
// Reference: Custom Part Number Generation Handler v2.1

We created a configuration table that maps product families, component types, and materials to their code letters. This makes the rules data-driven rather than hard-coded, allowing business users to adjust codes without developer involvement.

The validation logic prevents issues like:

  • Sequence number exhaustion (alerts when approaching 999999 limit)
  • Invalid prefix combinations (some component types don’t apply to certain product families)
  • Duplicate assignments (database constraints enforce uniqueness)

Workflow Integration: The part number generation is triggered during the part creation workflow at the “Initialize Part” step. This ensures:

  1. Part number is assigned before the part is visible to other users
  2. Assignment happens in a controlled transaction that can roll back if anything fails
  3. The item_id property becomes read-only after the workflow completes

We added a workflow handler that calls the numbering service during part initialization. If the service fails (database unavailable, sequence exhausted), the workflow stops and alerts the administrator rather than allowing a part to be created without a proper number.

For parts imported from external systems or migrated from legacy data, we created a separate “Manual Assignment” workflow that allows administrators to assign specific numbers with documented justification. This maintains audit control even for exception cases.

The workflow also triggers notification to the data management team when new product families or component types are introduced, so they can verify the numbering rules are configured correctly.

Audit Traceability: Every part number assignment is logged to a custom audit table with these fields:

  • Part number assigned
  • Generation timestamp
  • User who created the part
  • Product family, component type, material codes used
  • Previous sequence number and new sequence number
  • Rule version that generated the number

This provides complete traceability for audits. When auditors ask about a specific part, we can show:

  1. When it was created and by whom
  2. Which business rules determined its number
  3. What the sequential progression was (proving no gaps or duplicates)
  4. That the number hasn’t been changed since assignment

We generate monthly reports showing:

  • Number of parts created by product family
  • Sequence utilization (how close to exhausting ranges)
  • Any manual assignment exceptions and their justifications
  • User compliance (confirming all parts follow the automated process)

The audit trail has proven invaluable during ISO 9001 audits and customer-specific compliance reviews. Auditors can quickly verify that our part numbering is controlled, traceable, and consistent.

Implementation Benefits: Quantifiable improvements since deployment:

  • Zero duplicate part numbers (previously 2-3 per month)
  • 75% reduction in part number-related data corrections
  • Audit preparation time reduced from 2 weeks to 3 days
  • New engineer onboarding simplified (no need to teach numbering conventions)
  • ERP integration errors eliminated (consistent format enables automated validation)

The initial three-month implementation investment has paid back many times over in reduced data quality issues and improved operational efficiency. Engineers initially resisted losing control over numbering, but they quickly appreciated not having to think about it and the elimination of duplicate number conflicts.

Key success factors:

  1. Involve engineering leadership early to get buy-in
  2. Keep rules as simple as possible while meeting business needs
  3. Provide clear visibility into how numbers are assigned (not a black box)
  4. Make the audit trail easily accessible for compliance reviews
  5. Plan for rule evolution - business needs change over time

We’re now expanding this approach to other object types like documents and requirements, applying the same automated generation and audit tracking principles.

For audit purposes, I’d recommend logging every part number assignment with timestamp, user, and the rule parameters that generated it. Store this in a custom audit table separate from general Teamcenter audit logs so it’s easy to query for compliance reports. Also document your numbering rules clearly - auditors want to see the logic documented, not just implemented in code.

We used custom Java handlers because our rules were too complex for built-in naming rules. The logic checks product family, determines the appropriate prefix, queries the database for the last used number in that sequence, and increments it. We also built in validation to prevent sequence gaps and handle concurrent creation requests.

String prefix = getProductFamilyPrefix(part);
int nextNum = getNextSequenceNumber(prefix);
String partNumber = prefix + String.format("%06d", nextNum);
part.setProperty("item_id", partNumber);

The workflow integration ensures the number is assigned during the creation workflow and becomes read-only after initial save.

This is exactly the kind of automation that pays off long-term. How did you handle the transition from manual to automated numbering? Did you migrate existing parts to the new numbering scheme, or just apply it to new parts going forward? We’re considering a similar implementation but worried about the transition disruption.