3D Printing Master Data Governance and One-Item-One-Code: Implementation Methods from Coding Rules and Version Indexing to Data Dictionaries

Why Multiple Codes for One Item Cause Continuous Rework in 3D Printing Workshops

In high-mix, low-volume 3D printing workshops, the most common issue is not equipment downtime but a more hidden form of waste: the same part is called A in the quotation system, B on the process card, C in the MES work order, and D in the inspection report. On the surface, all four numbering systems are functioning, but they cannot actually be reconciled. Based on reviews of multiple on-demand manufacturing operations, the author found that whenever a part lacks a unique identity code, subsequent material lots, printing parameters, inspection records, and delivery traceability can only be pieced together through human memory. Once personnel change or orders run concurrently, using the wrong revision, issuing the wrong material, and assembling the wrong part become almost inevitable.

The challenge is compounded by the fact that 3D printing naturally encourages rapid iteration. A bracket may have its wall thickness changed today, its orientation adjusted tomorrow, and its powder lot replaced the day after. If every change creates a new file without being incorporated into unified coding and version-control rules, within weeks there may be more than a dozen similar but incompatible models. This is why digital factory development cannot focus solely on equipment connectivity; it must first address master data and one-item-one-code management.

I. What Master Data Really Is: Turning a “Part” from a File into a Controlled Object

Master data refers to core business entities that are reused across systems and departments and do not change frequently. For 3D printing companies, key master data should include at least four categories: material/part master data (including material grade, process route, and default post-processing); equipment master data (machine model, build chamber size, laser power, and coordinate system); supplier and lot master data (powder lot number, number of sieving cycles, and oxygen content); and process-parameter master data (layer thickness, laser power, scan speed, hatch spacing, and preheat temperature).

The value of this data lies in semantic consistency. For example, the lot number P-2026-10-041 for 316L powder must point to the same code across purchasing receipt, material issue, sieving and reuse, and printing consumption. Otherwise, the question “Which powder lot was used?” will never have a reliable answer. Likewise, the identifier E-LPBF-03 for a specific LPBF machine must be linked to its maintenance records, geometric-accuracy calibration reports, and build-chamber number for its availability and failure statistics to be meaningful.

The distinction between master data and transactional data must also be clear: work orders, delivery notes, and inspection forms are transactional data generated every day; part numbers, equipment IDs, and material grades are master data referenced repeatedly. The former can grow in volume without limit, while the latter must be tightly controlled and have traceable changes.

II. One-Item-One-Code Rules: Readable, Scalable, and Verifiable

The core of one-item-one-code is not simply assigning a number to every part, but ensuring that the code itself carries a parsable structure. In practice, the most reliable approach is a segmented code: category code-feature code-sequential number-version index. For example, BR-Ti64-LPBF-0147-R03 represents a bracket-type part, Ti6Al4V material, LPBF process, sequential number 0147, and revision 3. This coding approach offers three direct benefits: first, it is human-readable, allowing warehouse and quality personnel to identify basic attributes without consulting a database; second, systems can search by segment to quickly filter “all titanium LPBF parts”; third, the version index embeds design iterations in the code and prevents outdated drawing numbers from being misused.

Several common pitfalls should be avoided in code design. Do not include variable information in the code—customer names, order numbers, and quantities can change, and including them makes the code unstable. Do not use sequential serial numbers to convey meaning, as this can lead to duplicate numbers and poor scalability. Do not rely on Chinese characters or full-width characters, which can easily cause inconsistencies in cross-system interfaces. It is recommended to use only uppercase letters, numbers, and hyphens, with a length of 16 to 24 characters to balance readability and barcode capacity.

For serialized parts—where every physical item requires individual traceability, such as aerospace components or medical implant prototypes—add a serial number segment on top of the one-item-one-code structure, creating a two-level “part code + serial number” structure. The part code governs design identity, while the serial number governs physical identity; the two should be linked in a parent-child relationship in the MES.

III. Versions and Drawing Numbers: Making Every Change Traceable

The pace of 3D printing iteration places higher demands on version management. A recommended rule is that any change to geometry, material, or key process parameters requires a new revision. Changes only to notes, packaging instructions, or other content that does not affect physical attributes do not require a revision increase, but a revision note must still be recorded. Version numbers should use R followed by two digits (R01, R02, etc.) and correspond strictly one-to-one with the version index in the code.

Each version must retain four items: the version's 3D model files (one STEP file and one native-format file), the corresponding drawing number and technical requirements, the process card and parameter set for that version, and the first-article inspection or validation record. If any of these is missing, the version should not be released to production. Many teams save only model files and overlook that “the parameter set is also part of the version.” Parts printed from the same model using two different parameter sets can have substantially different properties; without parameter versioning, performance variation cannot be explained.

Obsolete versions must not be deleted; they may only be marked as “obsolete/historical reference only.” Deleting historical versions destroys the traceability chain. Once a customer complaint or failure analysis arises, it becomes impossible to reconstruct the design and process condition at that time.

IV. Implementation Path: From Coding Rules to End-to-End System Integration

Implementation is recommended in four steps, each of which can be independently accepted. The first step is code inventory: review all existing in-process and historical parts, identify cases of multiple codes for one item and one code for multiple items, and create a cross-reference table. This is the most tedious step, but also the only step that cannot be skipped. The second step is rule establishment: issue coding rules, version rules, and a data dictionary, clearly defining the responsible owner and allowable values for each field. The third step is system entry: embed the rules in PLM or ERP, prohibit offline manual numbering, and require the system to generate codes for new parts according to the established rules. The fourth step is integration: ensure that reference fields in quotation, process planning, scheduling, inspection, and shipment all point to the same part code. A missing code at any stage should be treated as noncompliance and must not proceed to the next stage.

Three quantitative metrics are recommended for acceptance: the multiple-codes-for-one-item rate (target: below 1%), the completeness rate of mandatory master-data fields (target: above 98%), and the version traceability rate (the percentage, from a sample of 100 in-process parts, for which the model + parameters + inspection records can be fully reconstructed; target: 100%). Reviewing these three metrics monthly reflects actual progress far better than any slogan-driven “digital transformation” initiative.

V. Common Failure Modes and Recommendations for Avoidance

The most common failure is treating master data as a one-time project. Master data requires ongoing governance; otherwise, new parts will start being manually numbered again within six months, rendering the rules ineffective. It is recommended to appoint a single owner, with all coding-rule changes subject to that owner's review and traceable documentation. A second failure is overdesigning fields—defining hundreds of fields at once, only to find that no one can complete them and they are ultimately left blank. A more practical approach is to begin with 15 to 25 core fields and expand gradually as business needs arise. A third failure is overlooking subcontracting and incoming-material scenarios: outsourced parts and customer-supplied drawings often bypass internal coding and enter production directly. Codes must be assigned at the order-intake stage; otherwise, the traceability chain breaks at its very beginning.

Another often-overlooked point is that coding rules must allow for expansion across factories and systems. A code used in only one workshop today may need to connect with a customer's PLM or an industry platform tomorrow. Reserving a plant segment or prefix segment in the code can avoid a painful full-scale restructuring in the future.

Conclusion

The true foundation of 3D printing workshop digitalization is neither equipment connectivity nor dashboards. It is ensuring that every part has a unique, stable, and parsable identity code, supported by corresponding version management and a data dictionary. Master data governance may appear tedious, but it directly determines whether material lots can be traced, process parameters can be reproduced, and delivery evidence can be accepted by customers. From inventorying existing codes and issuing rules to system embedding and end-to-end integration, this path requires several months of sustained investment. In return, it makes all subsequent digital capabilities—scheduling, quality inspection, costing, and traceability—genuinely achievable.