The item master, and why it is not a parts list

What an item is

An item is a persistent identifier for a real thing. A capacitor, a bracket, a firmware image, a finished product. It exists from the moment somebody decides the thing needs a name and it never goes away, because things that stopped being made were still bought and still shipped.

A revision is a version of that item, and it is where nearly all the data lives — the structure, the documents, the approved manufacturers, the state. The item itself holds very little: an identifier, a type, a classification, and a description that is allowed to be dull.

That distribution is deliberate. Anything that can change without changing what the thing is belongs on the item; anything that changes because the thing changed belongs on the revision. The test resolves most field-placement arguments in one pass, and it is worth having the argument once at configuration time rather than every quarter afterwards.

When two items are one item

The most expensive data condition in any PLM is duplicate identity: the same physical component entered twice, under two numbers, by two engineers who searched for it differently.

It is expensive because the duplicates are individually correct. Both records describe a real part accurately. Nothing is malformed, no validation fires, and the only symptom is that where-used returns half the truth and the buyer negotiates two smaller volumes instead of one larger one.

Manufacturing PLM attacks it at creation rather than by cleanup. Semantic search runs before a new item is created, against classification attributes rather than description text, and a near match is presented with its differences named — not as a similarity score, but as a statement that this candidate matches on eleven of thirteen attributes and differs on tolerance and package.

The inverse condition also exists and gets less attention: one item covering two things, usually because a part was quietly changed in a way that should have been a new item and was recorded as a revision instead. The revision-versus-new-item test — whether the change is backward compatible in every application — is what keeps that from happening.

The failure it prevents

A company runs an obsolescence check on a connector that has gone end-of-life. Where-used returns two products. The redesign is scoped, executed and released over five weeks.

Nine months later a third product fails certification with the same obsolete connector in it. That product's BOM referenced a duplicate item — same connector, different number, created eighteen months earlier by an engineer in a different office who searched for *header* rather than *connector*.

The obsolescence check was correct and the answer was incomplete, which is the worst combination available. A wrong answer gets challenged; a confidently incomplete one gets acted on. Duplicate identity is what turns every structural query in the system into a partial one.

How it meets the rest of the product

Numbering schemes attach at item creation and are per-tenant: significant, non-significant, or a hybrid where the classification contributes a prefix. Manufacturing PLM holds a position — non-significant numbers age better — and implements whichever scheme you choose without complaint.

Classification is what makes search work, which is the real reason it is enforced. An item classified as a chip resistor has typed attributes for resistance, tolerance, package and power rating, and those attributes are what a duplicate check compares. Free-text descriptions cannot support the query.

Where-used, effectivity, variant resolution and impact analysis all resolve against item identity. Every one of them degrades in exactly the same way when identity is loose, which is why this is the first thing configured and the hardest to fix later.

How it meets your ERP

The item number is the join key between the two systems, and it needs to be stable in a way that revisions are not. Manufacturing PLM publishes items to your ERP; the ERP does not need to know what a revision is unless you have decided it should.

Most deployments publish the item with the currently released revision's attributes flattened onto it, which is what an ERP item master expects. The revision history stays here, where it has a change process attached to it, rather than being replicated into a system with no concept of approval.

Where your ERP already holds the item master and Manufacturing PLM adopts it, the numbering scheme is theirs and the reconciliation runs the other way. The system-of-record matrix records that decision per field, so the direction is explicit rather than inferred from whichever integration was built first.

Where the boundary is

Manufacturing PLM does not merge duplicate items automatically. Where a duplicate is confirmed, the merge is an explicit operation with a preview showing every structure affected, and it is recorded as a change. An automatic merge on a false positive is a silent structural edit across products nobody was looking at.

It also does not hold inventory, cost or lead time as authored data. Those are read from your ERP with a source and an as-of stamp where the integration exists, and left empty where it does not — an empty field is honest and a stale one is not.