Component sourcing data, attached to your parts
Catalogue data is the most useful information in electronics design and the most dangerous to copy. Manufacturing PLM reads it, stamps it, and never pretends the copy is current.
What it brings in
Component aggregators — Octopart, Nexar, and the distributor APIs behind them — publish four things worth attaching to a part: lifecycle status, availability, price at quantity, and compliance markers such as RoHS and REACH declarations.
Manufacturing PLM reads them against the manufacturer part numbers on your AML and attaches the result to the entry rather than to the item. That distinction matters: an item does not have a lifecycle status, a specific manufacturer's part does, and an item with three approved manufacturers has three answers.
Every attached value carries the source it came from and the moment it was read. A price with no as-of stamp is a rumour, and a lifecycle status with no as-of stamp is worse, because obsolescence is exactly the fact that changes while nobody is looking.
Why the stamp is the whole design
The tempting implementation is to write catalogue values into item fields and refresh them nightly. It demos well and fails in a specific way: the values become indistinguishable from data your engineers entered, and nobody can tell which is which six months later.
Cached reads are held separately from authored data and rendered as reads. A screen showing a part's lifecycle status shows where the status came from and when, and a stale read is labelled stale rather than shown plainly.
The consequence people notice first is that two engineers looking at the same part on the same afternoon see the same numbers, because they are looking at the same cached read rather than at two independent live lookups that disagree. Disagreeing prices in a design review is a conversation nobody should have to have.
The failure it prevents
A design passes review with every component in production status. Fourteen months later the product enters volume ramp and two components are end-of-life, one with no drop-in replacement and a twelve-week redesign attached to it.
The status was accurate when it was checked. Nobody checked it again, because nothing was watching — the lifecycle field said *Active* on a screen and the field had been correct on the day somebody typed it.
Obsolescence is a change in somebody else's data, which is why it needs a watcher rather than a field. Lifecycle changes on parts you consume raise a task against the products that consume them, resolved through where-used, and the task exists whether or not anyone was thinking about that component.
How it meets the rest of the product
Where-used turns a component-level fact into a product-level one. An end-of-life notice on a connector is uninteresting until you know it appears in four shipping products and one in design, and that resolution runs through the same engine the rest of the product uses.
Part reuse search consumes the same data, which is where it pays for itself quietly: a search for an equivalent component that ranks by what is actually available and in production is a different tool from one that ranks by specification alone.
The sourcing agent watches these reads on a schedule and raises tasks at Recommend tier — an obsolescence notice becomes a task with the affected products named and a proposed alternate where one is identifiable, never an automatic AML change.
Compliance markers feed the rollup rather than sitting on the part in isolation. A REACH declaration on one component is a fact; the same declaration resolved up through every assembly that consumes it is the answer a customer questionnaire is actually asking for, and the rollup produces it from the same cached reads.
Cost estimation reads price at quantity through the resolved structure, so a variant's estimated component cost reflects the lines that variant actually contains. It is an estimate and labelled as one, but it is an estimate built on the same resolution the BOM screen shows rather than on a spreadsheet somebody maintained separately.
How it meets your ERP
Catalogue price and your ERP's negotiated price are different facts, and Manufacturing PLM shows both without averaging them. Catalogue price at quantity is what the market charges; your ERP holds what you agreed to pay, and an engineer estimating a design needs the second where it exists.
Availability is the same story. A distributor's stock figure is not your stock figure, and where an ERP inventory read is configured, both appear labelled by source rather than combined into a single number that means neither thing.
Manufacturing PLM does not write catalogue data into your ERP. Procurement's item records are procurement's, and pushing a distributor's lifecycle status into them creates a value nobody in that system authored and nobody can trace.
Where the boundary is
Manufacturing PLM is not a sourcing tool. It does not quote, place orders, manage supplier relationships or track shipments. It reads the small set of catalogue facts that change engineering decisions and stops there.
It also does not resell catalogue access. You configure your own credentials against your own agreement with the data provider, the reads are yours, and the terms are between you and them — which also means your entitlement determines what depth of data appears here.
Facts
| Sources | Octopart · Nexar · distributor APIs, on your credentials |
| Reads | Lifecycle · availability · price at quantity · compliance |
| Attached to | The AML entry, not the item — three manufacturers, three answers |
| Every value | Carries its source and the moment it was read |
| Held | Separately from authored data; rendered as a read |
| Obsolescence | A watcher, not a field — tasks raised via where-used |
| Agent tier | Recommend — never an automatic AML change |
| Not offered | Quoting · orders · shipment tracking · resold catalogue access |
Frequently asked
Why attach data to the AML entry rather than the item?
Because an item does not have a lifecycle status — a specific manufacturer's part does. An item with three approved manufacturers has three answers, and collapsing them onto the item means showing one of them and silently discarding the other two entirely.
Why not just write the values into fields?
Because they then become indistinguishable from data your engineers entered, and nobody can tell which is which six months later. Cached reads are held separately and rendered as reads, with the source and the moment they were fetched shown alongside.
How does obsolescence actually get caught?
By a watcher rather than a field. Lifecycle changes on parts you consume raise a task against the products consuming them, resolved through where-used, and that task exists whether or not anybody happened to be thinking about that component that week.
Whose price do I see — the catalogue's or ours?
Both, labelled by source and never averaged. Catalogue price at quantity is what the market charges; your ERP holds what you actually agreed to pay. An engineer estimating a design needs the second wherever it exists and the first where it does not.
Do you push this data into our ERP?
No. Procurement's item records are procurement's, and pushing a distributor's lifecycle status into them creates a value nobody in that system authored, nobody maintains, and nobody can trace back to a source on the day it turns out to be wrong.
Do we need our own Octopart account?
Yes. You configure your own credentials against your own agreement with the data provider, the reads are yours, and the terms are between you and them. Your entitlement also determines what depth of data appears here rather than anything set on our side.
Is this a sourcing tool?
No. It does not quote, place orders, manage supplier relationships or track shipments. It reads the small set of catalogue facts that actually change an engineering decision — lifecycle, availability, price at quantity, compliance markers — and then deliberately stops at that line.