BOM compare, with both sides resolved
Comparing a resolved structure against a stored one reports every effectivity and variant decision as a difference. Manufacturing PLM resolves both sides through the same engine first, so a diff shows what actually changed and nothing else.
What it is, and what it is not
A structural difference between two configurations of a product: two revisions, two variants, two plants, two dates, or a baseline against what is current. Five kinds of difference come out — added, removed, changed, moved, unchanged — each carrying the line identity that connects the two sides.
It is not a text diff of two exports. A text diff has no idea that a line moved to a different parent rather than being deleted from one place and added to another, and it will report a re-ordered grid as hundreds of changes.
It is also not a report generated on a schedule. Compare is a question asked at the moment somebody needs it, against conditions they state, which is why it belongs to the resolver rather than to a reporting layer.
The mechanism: both sides go through the engine
This is the rule the whole feature turns on. Both sources are resolved before they are compared, under their own stated conditions, and only then diffed.
The alternative is very tempting and quietly wrong. If one side is a resolution and the other is the stored structure, every effectivity window and every variant rule shows up as a difference — because it *is* a difference between a conditional statement and one of its answers. A user sees forty changes where two occurred, stops trusting the screen, and goes back to exporting to Excel.
Line identity is what makes a move distinguishable from a delete-plus-add. Every BOM line carries a stable identity independent of its position, so a bracket that migrates from one parent to another is reported once, as moved, with both parents named — rather than twice, as unrelated events.
The failure it prevents
A contract manufacturer is qualified on a build. Six months later they ask which parts changed since qualification. Somebody exports the current BOM, exports the qualification baseline, and diffs the two spreadsheets.
The diff returns sixty rows. Most are noise: quantity formatting, re-sorted lines, a phantom assembly that expanded differently, and eleven lines that are only in one export because the qualification was for the 240-volt variant and the current export was not scoped to any variant at all.
Somebody spends a day separating the four real changes from the fifty-six artefacts, and there is no way to prove they got it right. Resolving both sides under stated conditions produces four rows, each with a reason, and the conditions are printed at the top of the screen so the answer can be reproduced.
How it meets the rest of the product
Compare, where-used, cost rollup, compliance rollup and impact analysis all read the same resolver, which is why they agree by construction rather than by coincidence. A line that a cost rollup counted is a line compare will show.
Baselines are first-class and distinct from snapshots. Comparing against a baseline — a qualification, a first article, a released configuration — is the same operation with the baseline as one side, so nothing special has to be built for the case that matters most in a regulated conversation.
The BOM Agent uses compare rather than reimplementing it. Asked what changed between two revisions, it calls the same service, receives the same five difference kinds, and answers in prose with the rows cited — so a reader can open the diff and check the claim.
Colour is never the only channel. Each difference kind carries a glyph and a left rule as well as a colour, so the diff survives greyscale printing and colour-vision deficiency — which matters because these get printed and taped to a bench.
How it meets your ERP
The most useful comparison in an integrated setup is between what Manufacturing PLM resolved and what the ERP actually holds. Both sides go through their respective reads, and the differences that come back are exactly the reconciliation queue: lines edited downstream, lines that failed to publish, lines added by a planner.
That comparison is what a reconciliation task is built from. Rather than an alert saying the two systems disagree, you get the five difference kinds against the specific object, naming the field, both values and which system owns it under the system-of-record matrix.
Comparing a released structure against what was published also answers the audit question directly: show that what the ERP built from is what engineering approved. Because both sides are resolved deterministically, that demonstration is repeatable rather than a one-time export somebody has to be trusted about.
Where the boundary is
Compare reports structural and attribute differences. It does not judge which side is correct, and it does not merge — there is no button that accepts the left column. Reconciling a difference is a change, and changes go through change control rather than through a diff screen.
It also does not compare geometry. Two revisions of a CAD model differing by a fillet is a question for the CAD system; Manufacturing PLM compares the structures, the attributes and the documents attached, and links out for the rest.
Facts
| Difference kinds | Added · removed · changed · moved · unchanged |
| Core rule | Both sides resolved before diffing |
| Moves | Detected via stable line identity, not position |
| Compare across | Revisions · variants · plants · dates · baselines |
| Accessibility | Glyph and rule as well as colour |
| Agents | The BOM Agent calls it and cites the rows |
| ERP | Resolved vs published is the reconciliation queue |
| Not offered | Merge, arbitration, geometry comparison |
Frequently asked
Why resolve before comparing?
Because comparing a resolution against a stored structure reports every effectivity window and variant rule as a difference. Users see forty changes where two happened, stop trusting the screen, and go back to Excel. Resolving both sides under stated conditions is what makes the diff mean something.
Can it tell a move from a delete and an add?
Yes. Every BOM line carries a stable identity independent of its position, so a bracket that migrates to a different parent is reported once as moved, with both parents named, rather than twice as unrelated events. A text diff of two exports cannot do this.
What can we compare against?
Two revisions, two variants, two plants, two dates, or a baseline against what is current. A baseline is first-class rather than a saved export, so comparing against a qualification or a first article is the same operation with the baseline supplied as one side.
Does it work in greyscale?
Yes. Each difference kind carries a glyph and a left rule as well as a colour, so the diff survives printing in black and white and colour-vision deficiency. These get printed and taped to a bench often enough that colour alone would be a real defect.
Can we compare Manufacturing PLM against the ERP?
Yes, and it is the most useful comparison in an integrated setup. The differences returned are the reconciliation queue: lines edited downstream, lines that failed to publish, lines a planner added. Each names the field, both values and the owning system under the matrix.
Is there a merge button?
No, deliberately. Reconciling a difference means changing a released structure, and released structures move through change control rather than through a diff screen. A one-click merge would be a way to bypass approval, which is the thing the change process exists to prevent.
Does it compare CAD geometry?
No. Two revisions differing by a fillet is a question for the CAD system, and Manufacturing PLM links out rather than pretending to answer it. What it compares is structure, attributes and the documents attached — which is the layer where change control actually operates.