Matching manufacturer part numbers to real parts
An MPN looks like a key and behaves like a sentence. The same physical component reaches you as a dozen strings, and the difference between two of them is sometimes packaging and sometimes a different part.
Why this is hard
Manufacturer part numbers carry meaning in their suffixes, and the meaning is not standardised between manufacturers or even between families at the same manufacturer.
Six kinds of noise account for most of it: packaging suffixes that change the string but not the component; tape-and-reel versus cut-tape codes; tolerance and grade letters that do change the part; RoHS and lead-finish markers; distributor-added prefixes that never appeared on a datasheet; and plain transcription damage from spreadsheets, where a leading zero vanished or a hyphen became an en dash.
The consequence is that string equality is nearly useless and string similarity is dangerous. GRM188R71C104KA01D and GRM188R71C104KA01J differ by one character and are different packaging of the same capacitor. CRCW060310K0FKEA and CRCW060310K0JNEA also differ by one character, and are one percent and five percent tolerance respectively.
How matching works here
Matching runs in stages, cheapest first, and each stage can settle the question without invoking the next.
- Exact normalised match — case, whitespace and dash-family characters folded. This settles the clear majority and costs nothing.
- Known-suffix decomposition — the string is split into base and suffix using manufacturer-family rules, and a base match with a packaging-only difference is reported as a match with the difference named.
- Catalogue lookup — the normalised base is resolved against distributor catalogue data, which frequently identifies the manufacturer and family the string belongs to even when your record does not.
- Model-proposed match — only for what survives, and only ever as a proposal carrying a confidence value and a written reason for the specific pair.
The failure it prevents
A quoted BOM comes back from a contract manufacturer with their internal part numbers alongside yours. Somebody runs a fuzzy match in a spreadsheet, accepts everything above a similarity threshold, and imports the result.
Two hundred lines match correctly. Three do not, and one of those three is a resistor that arrives at five percent tolerance in a divider that assumed one. The boards work at room temperature, fail intermittently at the top of the operating range, and the investigation takes eleven weeks because the BOM says the right part.
A similarity score is not evidence. The failure mode of fuzzy matching is that it is confidently wrong on exactly the pairs where one character carries the meaning — which is why every proposal here names the difference it found rather than reporting a number.
How it meets the rest of the product
Matching is a Recommend-tier operation. It proposes; a person accepts. There is no configuration in which a match is applied silently to your data, because the whole class of error this prevents is the one where a plausible substitution enters the record unattended.
Accepted matches attach to the AML as approved manufacturer entries with their own provenance, so an entry added by accepting a proposal is distinguishable later from one an engineer entered directly. A rejected proposal is also recorded, which stops the same pair being proposed every import.
Grid paste and import both route through it, so a pasted column of manufacturer part numbers arrives as a review screen rather than as data. Where a line cannot be matched with confidence it stays unmatched and visible rather than being approximated.
Where-used runs against the matched entries rather than the raw strings, which is what makes the question useful. Asking where a manufacturer part is consumed only returns a complete answer if every spelling of it has been resolved to the same component first.
How it meets your ERP
Your ERP holds purchasing's view of the same components, and it is frequently the richest matching source available — because it contains the part numbers people have actually bought against, which no catalogue knows.
Where an ERP item read is configured, its manufacturer references are used as a matching source alongside catalogue data, and a proposal grounded in your own purchasing history is presented as such. That reason carries more weight with a reviewer than a catalogue hit, and correctly so.
Manufacturing PLM does not write matches back to the ERP. The AML is engineering's approved list and the ERP's vendor records are procurement's; they inform each other and neither is derived from the other, which is the arrangement that survives both teams changing their minds.
Where the boundary is
Manufacturing PLM does not decide that two part numbers are the same. It proposes, with a reason, and a person decides. That is a deliberate limit rather than a stage of maturity, because the cost of a wrong match is discovered in the field and the cost of a review is thirty seconds.
It also does not maintain a component database of its own. Catalogue data is read from the sources you configure, cached with an as-of stamp, and never presented as Manufacturing PLM's own knowledge of a component's specifications.
Facts
| Noise sources | Packaging · reel codes · tolerance · RoHS · prefixes · transcription |
| One character | Can mean packaging, or 1% versus 5% tolerance |
| Stages | Normalised → suffix decomposition → catalogue → model |
| Model stage | Runs only on what survives the cheaper stages |
| Agent tier | Recommend — never applied silently |
| Every proposal | Carries a confidence and a written reason for that pair |
| Rejections | Recorded, so the same pair is not re-proposed each import |
| Not offered | Automatic matching · a component database of our own |
Frequently asked
Why not just use fuzzy string matching?
Because it is confidently wrong on exactly the pairs where one character carries the meaning. CRCW060310K0FKEA and CRCW060310K0JNEA differ by one character and are one percent and five percent tolerance. A similarity score cannot tell you which difference you are looking at.
Can matching run automatically on import?
It runs automatically; it does not apply automatically. Every proposal reaches a review screen with its confidence and reason, and there is no configuration that skips that step — the error class this prevents is precisely the plausible substitution entering data unattended.
What does a proposal actually tell me?
The pair, a confidence value, and a written reason specific to those two strings — that the difference is a packaging suffix, or that a catalogue lookup resolved both to the same manufacturer family. A reason a reviewer can check beats a number they cannot.
Does it use our ERP data?
Where an ERP item read is configured, yes, and it is frequently the richest source available because it holds the part numbers people have actually purchased against. A proposal grounded in your own buying history is presented as such and carries more weight.
Do accepted matches go back to the ERP?
No. The AML is engineering's approved list and the ERP's vendor records are procurement's. They inform each other and neither is derived from the other, which is the one arrangement that survives both teams changing their minds independently, repeatedly, over several years.
What happens to lines that do not match?
They stay unmatched and visible rather than being approximated. An unmatched line is a question somebody can answer in about a minute; an approximated one is a wrong answer that looks settled, survives every review, and gets discovered in the field instead.
Do you maintain your own component database?
No. Catalogue data is read from the sources you configure, cached with an as-of stamp, and never presented as Manufacturing PLM's own knowledge of a component's specifications. Specifications belong to the manufacturer, and a stale copy of them is worse than a link.