Two namespaces that overlap

What the problem actually is

Both systems have items and both have numbers, so the instinct is that one of them must be right. That framing produces the wrong project.

The truth is that the two namespaces overlap rather than compete. Engineering creates parts that the ERP needs in order to plan and buy. Purchasing and sales create items engineering has no opinion about: cartons, pallets, freight lines, service labour, non-stock consumables. A third group exists in both because both created them at different times, under different numbers, for the same physical thing.

The job is not to unify the namespaces. It is to know which items are in the overlap, link those, and leave the rest alone.

The mechanism: three passes, and a person at the end

Manufacturer part number first. It is the identifier the outside world uses, and two records naming the same MPN are almost certainly the same physical component. This pass does most of the work on purchased parts.

Internal part number second. Where an organisation has already been disciplined — the ERP item and the engineering part share a number — this catches them. Common for parts engineering originated and pushed outward previously.

A configured tie-break third. Manufacturer plus a normalised description, a legacy cross-reference table, a customer-specific rule. This is where your organisation's history goes, and it is configuration rather than something inferred.

Anything unmatched is surfaced for a person. Never merged on description similarity, and never guessed. A wrong match is close to unpickable: two genuinely different parts become one, the structures referencing each now reference the survivor, and the record of which was which is gone. A missing match is a task; a wrong match is an incident.

The failure it prevents

A team migrates onto a PLM and imports every part. The ERP already held most of them under its own numbers, so the import creates a second item master alongside the first.

Nothing errors. Purchasing keeps transacting against the ERP items; engineering designs against the PLM parts; and for a while nobody notices because the numbers look similar enough. Then a change releases, publishes a structure referencing engineering's numbers, and the planning run cannot net requirements because half the components are items with no purchase history.

Untangling that takes a quarter of somebody's attention and produces a cross-reference spreadsheet that becomes load-bearing. Matching on the way in turns the same work into a finite list of unmatched items worked through before go-live — the same effort, spent at the point where it is still cheap.

How it meets the rest of the product

Match links are objects with an owner and an audit row, not a hidden column. Breaking a link is a deliberate act by a person and is recorded, because a silently broken link produces two systems that quietly stop agreeing about a part they both hold.

The AML is where MPN matching earns its keep twice. An internal part carries the manufacturer parts engineering has approved, and those are what component lifecycle feeds match against — so the same identifier that links a part to an ERP item also links it to an end-of-life notice.

Migration runs identity matching during the import rather than after it, against your live ERP rather than against an export. That ordering is the whole difference between a pre-cutover checklist and a post-cutover reconciliation project.

The Parts Agent reads the unmatched list as one of its inputs, because an item that matches nothing is frequently a duplicate of something that does.

How it meets your ERP

Engineering parts master in Manufacturing PLM; items originating in purchasing or sales master in your ERP. That split is the default row in the system-of-record matrix, and it is set per connector rather than assumed globally.

In SAP landscapes the default frequently flips: the material number has been SAP's for fifteen years and there is no good argument for taking it away. Manufacturing PLM then holds engineering identity alongside the material number and matches between them, which is a configuration decision recorded in the matrix rather than a behaviour that varies quietly by deployment.

What never happens is a silent renumber. Manufacturing PLM will not rewrite an ERP item's number to match engineering's, and it will not accept a rewrite in the other direction. A number that changes underneath a purchase order is a number nobody can reconcile against a receipt.

Where the boundary is

Manufacturing PLM does not clean up your ERP item master. Duplicate items that exist entirely on the ERP side — the same carton set up twice by two buyers — are visible in the unmatched list and are the ERP owner's to resolve, because merging them has purchasing and financial consequences Manufacturing PLM cannot see.

It also does not infer identity from history. Two items frequently purchased together, or consumed on the same work orders, are not thereby the same item, and a system that treated that pattern as evidence would produce merges nobody could defend.