Use sequential, non-significant part numbers and hold the meaning in fields, not in the identifier. Intelligent part numbers that encode material, family, size or supplier look organised for about three years, then the encoded attributes change and the number becomes a lie that nobody is allowed to correct. Keep the number short, fixed length, uppercase, unique and never reused, put every attribute in a validated field, and carry legacy numbers in a cross-reference so history and suppliers still resolve.
A part number is a licence plate, not a description. This guide covers why intelligent schemes fail, what specifically breaks in ERP, how to handle revisions and variants, and how to renumber an existing catalogue without destroying history.
Home / Guides / Part Numbering
A buyer raises a purchase order for FB-SS16-JON-0250-B and takes delivery of a mild steel weldment. SS16 means 316 stainless in the 2016 numbering convention. The part was redesigned four years ago, the material changed, and nobody renumbered it, because renumbering would have orphaned the stock history, two customer drawings and a supplier's tooling. So the number lies, and everyone who reads it instead of opening the item record is wrong.
That is the standard failure mode of an intelligent part numbering system. The people who hit it are engineering and operations leads standardising a catalogue, usually because something forced the issue: an ERP replacement, a stock count that will not reconcile because one bracket exists under three numbers, or a supplier quoting against a part that no longer exists.
This guide covers the argument between intelligent (significant) and sequential (non-significant) numbering, what breaks in ERP, how to handle revisions and variants, and how to renumber a catalogue without losing history.
A part number has four jobs and only four: be unique, be stable, be transcribable by a human reading a label or speaking on the phone, and be machine friendly in barcodes, EDI messages and CSV files. Notice what is not on that list: telling you what the part is. That is the description's job, and the search function's. When people ask for an intelligent scheme, what they are really asking for is "I want to find things without opening the record", which is a search problem wearing an identifier costume.
Here is the whole argument in one sentence. An identifier must be stable and a description must be accurate, and those two requirements conflict the moment the part changes. An intelligent number tries to be both, so the first time reality moves you choose between a wrong number and a broken history, and organisations always choose the wrong number. Five symptoms follow.
A material substitution during a shortage, a machined part becoming a fabrication, a size corrected on a drawing revision. Each invalidates a segment, and each is cheaper to ignore than to renumber. After five years the encoding is right for older parts and wrong for newer ones, which is worse than none at all, because people trust it.
You encoded material and family because those were what people filtered on in 2016. Now the questions are about country of origin, RoHS status and single-source risk, none of which are in the number and none of which there is room to add. Had the attributes been fields, adding another would have been an afternoon.
Every significant scheme has judgement in it. Is a 250mm bracket with a chamfer the same size class as the plain one? Two engineers working honestly from the same rules derive different numbers for the same part. It gets created twice and MRP orders material you already hold.
The three-digit sequence within a family hits 999. The two-character supplier code cannot represent the 340th supplier. The size segment cannot express 1.5mm and 1500mm in four characters, so somebody rounds and parts collide.
Because deriving a number means interpreting rules, someone owns the decode table and approves every number, so part creation queues behind one inbox. When that person is on holiday, engineers invent temporary numbers, and temporary numbers are permanent.
Sequential numbering means the next part gets the next number and the number means nothing. 1004821 is a bracket only because the item record says so. What you give up is real: you cannot glance at a works order and know the family. What you gain is a number that never changes, no decode table and no derivation-driven duplicates.
The objection deserves an answer. Engineers and stores staff say they need to read the number. They do not. They need to find the part and confirm they have the right one, which indexed attribute fields, a decent search and a printed label solve better than any encoding.
If the business will not accept a bare sequence, the only defensible compromise is one short prefix encoding something structurally immutable, such as record type. Never encode make versus buy, supplier, material, size, colour, finish, cost band, ABC class, location or project. All of those change.
Numbering arguments are conducted in the abstract and then land badly in a real system. The item number is a foreign key across ledgers, journals, document lines, BOMs, routings and interfaces, and its length is fixed in all of them.
| System | Item identifier | What that means in practice |
|---|---|---|
| Dynamics 365 Business Central | "Item No." is Code[20] on the item and on downstream tables such as Item Ledger Entry, Item Journal Line and Value Entry |
Twenty characters. Lengthening it is an AL development project across hundreds of objects |
| SAP S/4HANA | MATNR, historically 18 characters, extendable to a maximum of 40 via the extended material number | A configuration decision affecting custom code, interfaces and print output. Confirm which mode you are in before assuming 40 |
| Infor LN | Item codes can be segmented into a project-code segment and an item-base segment (see the Items session documentation) | Segmentation exists for project and configured items, not as a licence to encode attributes. Verify behaviour on your version |
The Infor LN documentation makes the general point neatly. Search keys default to the first sixteen characters of the item's name field, with anything up to and including a full stop excluded. Front-load a long common prefix and those sixteen characters are near-identical across thousands of items, so the search key stops discriminating. Nobody models that in a workshop; everybody discovers it in testing.
Intelligent schemes need separators, and separators are where the trouble is. Infor LN documents characters that are not allowed in generic item codes, including %, &, /, \, *, | and ?. Beyond the ERP, slashes break URLs, ampersands break XML, commas break CSV, and some barcode symbologies support only a restricted character set. Three more that cost real days:
0012345 to 12345 the moment anyone opens the extract, so half the mapping workbook is quietly wrong.brk100a and BRK100A as the same value; a case-sensitive Oracle or PostgreSQL setup does not. Mandate uppercase and normalise on load.Somebody deletes an obsolete item and reissues the number to keep a tidy sequence. Every historical transaction, cost record and quality record pointing at it now points at the wrong thing, silently. GS1 made non-reuse absolute for GTINs from January 2019 for exactly this reason (GS1 on GTIN reuse). Apply the same rule internally: obsolete an item, never delete and reissue.
The related failure is quieter. When the number is useless for finding things, people push searchable content into the description, and everyone invents their own convention, so BRACKET SS 250MM, SS BRACKET, 250 mm and Bkt-250-Stainless all describe one item. Then somebody writes a report that parses descriptions with string functions, and it works for eight months. Variants make this worse: the rules for a different length or finish are the fuzziest part of any convention, which is how one bracket ends up with three numbers and split stock.
Here is a scheme of the kind common at UK fabricators and machine shops, AA-BBBB-CCC-DDDD-E, eighteen characters with hyphens.
FB - SS16 - JON - 0250 - B
| | | | +-- revision letter
| | | +--------- nominal size in mm, zero padded
| | +---------------- supplier code, 3 letters
| +----------------------- material grade
+---------------------------- family (FB fabricated, MC machined, AS assembly)It is not a stupid scheme. Somebody thought about it. Here is how each segment fails once the catalogue has a few years on it.
| Segment | Intent | How it breaks |
|---|---|---|
AA family | Manufacturing route | A machined part becomes a weldment when volumes rise. The number still says MC, so reports that group by prefix are wrong |
BBBB material | The grade | Dual sourcing and shortage substitutions leave one number covering two grades, correctable only by renumbering |
CCC supplier | Where it comes from | Supply source is a property of a relationship, not of a part. Resourcing forces a choice between a new number for an identical part and a number that lies, and both answers are wrong |
DDDD size | Nominal dimension | Cannot express 1.5mm and 1500mm in four digits. Round to fit and two different parts collide on one number, which is how the wrong shim gets picked and nobody notices |
E revision | Drawing revision | Every drawing change creates a new ERP item, splitting stock and cost history across A, B and C for a fully interchangeable change |
The revision segment is the most expensive mistake there. Whether a change warrants a new item number is a per-change decision, on interchangeability grounds. Encoding revision forces a split every time, including for a tolerance note.
| Element | Design | Reasoning |
|---|---|---|
| Item number | Seven digits, sequential, allocated by the ERP number series, starting at 1000000 | Nine million numbers, always seven characters, no leading zeros to lose, no confusable letters, comfortable inside a twenty character field |
| Revision | Separate field, incremented for interchangeable changes only | Drawing changes stop splitting inventory; non-interchangeable changes get a new number by exception |
| Family, material, size, finish, origin, compliance | Validated fields with controlled value lists | Reportable, correctable and extensible without touching the identifier |
| Legacy number | Indexed alias field on every migrated item, never blanked | Twenty years of drawings and supplier records still resolve |
| Supplier and customer part numbers | Cross-reference table, many external numbers to one item | Their numbering is their business. It belongs beside your identifier, never inside it |
| GTIN, NSN and other external codes | Dedicated validated fields | Externally governed, under rules you do not control |
The cross-reference is the piece people skip and the piece that makes this survivable. Model it as a table, not a spreadsheet on somebody's desktop:
CREATE TABLE item_number_xref (
xref_id BIGINT IDENTITY(1,1) PRIMARY KEY,
item_no CHAR(7) NOT NULL,
external_no VARCHAR(40) NOT NULL,
xref_type VARCHAR(12) NOT NULL, -- LEGACY | SUPPLIER | CUSTOMER | MERGED
partner_code VARCHAR(20) NOT NULL DEFAULT '',
source_system VARCHAR(20) NOT NULL,
valid_from DATE NOT NULL,
valid_to DATE NULL,
CONSTRAINT fk_xref_item FOREIGN KEY (item_no) REFERENCES item_master (item_no)
);
-- One external number resolves to exactly one item. This is the constraint
-- that stops a merge quietly turning into a fork.
CREATE UNIQUE INDEX ux_item_xref
ON item_number_xref (external_no, xref_type, partner_code, source_system);
CREATE INDEX ix_item_xref_item ON item_number_xref (item_no);That unique index does the real work. Many legacy numbers may map to one new item, which is what you want when merging duplicates. One legacy number mapping to two new items is a defect the database should refuse.
A revision is a change to the same item. The test is two-way interchangeability: can the new one replace the old in service, and can the old still be used in place of the new? If both are true, same number, higher revision, commingle the stock. If either is false, new item number and a planned cut-in date. Infor LN carries a revision-controlled flag on the item and links effectivity to change orders; where ERP support is thinner, the discipline lives in the change process instead.
A variant is a configuration of a configurable product. Do not enumerate variants inside the identifier. Configurable ERPs have machinery for this, which is why Infor LN separates a project-code segment from the item-base segment and generates product variants from the configuration process. If you are hand-deriving variant numbers in a spreadsheet, you are rebuilding a configurator badly.
Other people's numbers are external identifiers. Supplier, customer and manufacturer part numbers, and standards references such as DIN or BS numbers, belong in cross-reference records. Copy one into your item number and you have coupled your identifier to a company you do not control.
Renumbering a live catalogue is a data migration, and it fails the way migrations fail: cleansing happens after the mapping, and nobody owns the decisions. Ordering matters more than tooling.
| Object | Translate? | Why |
|---|---|---|
| Open purchase, works and sales orders | Yes | They are received, issued or shipped after cutover against the new master |
| On-hand stock and bin locations | Yes | The count has to reconcile to the new item records on day one |
| BOMs and routings | Yes | Structures must resolve against live items or MRP produces nonsense |
| Open quality records and NCRs | Yes | They attach to items still being made and shipped |
| Posted stock and financial history | Usually no | Rewriting posted history rewrites the audit trail. Archive it read-only and join through the cross-reference |
| Drawings, specs and manuals | Reference both | The number is in the title block. Reissuing every drawing is rarely proportionate; a cross-reference is |
Three steps remain, and the first is always underestimated. Relabel the physical world: bins, racks, travellers, kanban cards, tooling and work instructions, none of which a script can do at the weekend. Then tell suppliers and subcontractors in advance, with a mapping file and a date. Finally, run aftercare for a quarter, checking items created since go-live against the request process.
Profiling in step two is mostly SQL. This is the query I reach for first, because near-duplicate descriptions are the fastest route to the parts of the catalogue that will hurt:
-- Candidate duplicates: same normalised description, different item numbers.
-- Strip punctuation, spaces and case so "SS BRACKET, 250 mm" collides with
-- "ss-bracket 250MM" before anyone renumbers either of them.
WITH norm AS (
SELECT item_no,
UPPER(REGEXP_REPLACE(description, '[^A-Za-z0-9]', '', 'g')) AS desc_key,
material_code
FROM item_master
WHERE status <> 'OBSOLETE'
)
SELECT desc_key,
COUNT(*) AS item_count,
COUNT(DISTINCT material_code) AS distinct_materials,
STRING_AGG(item_no, ', ') AS item_numbers
FROM norm
GROUP BY desc_key
HAVING COUNT(*) > 1
ORDER BY item_count DESC, desc_key;Rows where distinct_materials is 1 are almost always duplicates to merge. Rows above 1 are usually variants needing a description standard instead.
Externally allocated identifiers. Defence supply brings NATO Stock Numbers, a thirteen digit code combining a supply classification, a codification bureau code and an item identification number. Traded goods bring GTINs under GS1 rules. You design neither; you receive them, validate them and store them beside your own number.
PLM upstream of ERP. If the design authority sits in PLM, the PLM allocates the number and ERP consumes it, which settles the debate by ownership rather than argument. Your job becomes checking the ERP item field accepts whatever PLM issues, before you sign either contract.
Multi-site and group consolidation. One part, one number, group wide, with site-specific data in site-level records. Easy to say, and the hardest master data decision in any consolidation. On a GBP 4.5m consolidation of four legacy ERP systems onto one Infor LN cloud instance for 220 users over three years, the difficult question was never which fields to map. It was which of the four item catalogues won, and what happened to the three that did not.
Non-physical items, lots and serials. Phantom, non-stock, service and cost items use the same series with a different item type; a separate scheme causes pain the first time a cost item appears on a BOM. Lots, batches and serials are not part numbers. If people are appending batch codes to item numbers, that is a traceability configuration problem.
Part numbering is master data governance wearing overalls. If the catalogue is already damaged, the order that works is: agree ownership, profile, cleanse, renumber. Start with the free master data ownership matrix, because a numbering scheme without an owner reverts to old habits inside a year. Where the problem is duplicate, incomplete or contradictory records rather than the format of the identifier, that is data quality consultancy work: profiling, agreeing rules, cleansing against them and putting controls in place so it stays clean.
Where the renumbering is happening because you are moving systems, it belongs inside the ERP data migration workstream, mapped and reconciled alongside everything else rather than run as a side project by engineering. If a go-live date is fixed, the data migration readiness review gives an honest read on whether the item master is ready. For Infor LN and Baan, where item code segmentation, revision control and change management interact in ways the manual does not make obvious, see Infor LN consultancy and the guide on what an Infor LN consultant does. Ongoing ownership of rules and definitions sits under data management.
Sequential, in almost every case. An identifier has to be stable and a description has to be accurate, and those requirements conflict the moment a part changes. Encode nothing in the number, hold every attribute in a validated field, and let search do the job. The exception is where a PLM or an external standard already allocates the number.
Short enough to fit every downstream field and be read aloud without error, long enough never to run out. Seven digits starting at 1000000 gives roughly nine million numbers, is always seven characters, has no leading zeros for Excel to strip, and sits inside a twenty character ERP item field. Check the real field length in your target system first.
No. Keep revision in its own field and test each change for two-way interchangeability: if the new version can replace the old and the old can still be used, it is the same item at a higher revision and the stock can be commingled. If not, issue a new item number. Baking revision into the identifier splits stock and history on every drawing change.
There is no universal standard for internal part numbers, which is why the question generates so much argument. ISO 8000-115 addresses the quality of identifiers exchanged as master data, GS1 governs GTINs, and NATO Stock Numbers apply in defence supply. All three sit alongside your number rather than replacing it.
No. Reuse silently corrupts every historical transaction, cost record and quality record already pointing at that number, and there is no clean recovery. GS1 made non-reuse absolute for GTINs from January 2019 for this reason. Internally, obsolete the item and retire the number permanently.
Freeze the old scheme immediately, deduplicate before renumbering, build a cross-reference where every legacy number resolves to exactly one new item, carry the legacy number into a searchable alias field, translate open transactions and on-hand stock, and archive posted history read-only rather than rewriting the audit trail.
Part numbering is one of the few master data decisions that is genuinely hard to reverse, because the number ends up printed on labels, stamped into tooling, quoted by suppliers and referenced in customer manuals. Cheaper to argue about now than to live with for a decade.
If you are standardising a catalogue, planning a migration, or looking at an item master you no longer trust, book a 30-minute data risk call. Bring an extract and we will look at what the numbers are telling you.
Matty Hatton is the founder of Digital Adaption, an ERP and data consultancy on the Wirral working across the North West and the UK. Delivery is ISO 9001 certified. LinkedIn | Get in touch