When the two systems disagree

What it is, and what it is not

A comparison between what Manufacturing PLM resolved and what your ERP actually holds, turned into work items that name the object, the field, both values, and which system owns it under the system-of-record matrix.

It is not conflict resolution in the version-control sense. There is no merge, no three-way diff and no automatic winner, because the two systems are not two branches of the same document — one of them owns each fact, and a disagreement means either the owner's value did not arrive or somebody changed a value they do not own.

It is also not an alert. An alert says the systems disagree; a reconciliation task says which object, which field, what each system holds, who owns it, and what the options are. The first is noise within a week.

The mechanism: it is a diff, computed properly

Both sides are resolved before they are compared, exactly as in BOM compare. Manufacturing PLM resolves the structure under the conditions the publication used; the ERP's structure is read as it stands. Only then are they diffed.

That produces the same five difference kinds as any other comparison — added, removed, changed, moved, unchanged — and the first four become the reconciliation queue. A line added in the ERP is a line somebody added deliberately. A line removed is one that failed to publish or was deleted. A quantity changed is the most common and the most quietly consequential.

Comparing a resolution against a stored structure would report every effectivity and variant decision as a difference, which would fill the queue with noise and train everybody to dismiss it. That is the failure mode of most integration monitoring, and it is why the comparison goes through the engine rather than beside it.

The failure it prevents

A planner adds a packaging line to the assembly in the ERP, because packaging has always been maintained there and nobody wrote down that it moved to engineering. Two weeks later Manufacturing PLM republishes after a minor change and the packaging line is gone.

Nothing errored. Both systems did what they were configured to do. The line gets re-added, disappears again, and by the third cycle the site has stopped trusting the integration and is maintaining the ERP BOM by hand — which is the outcome the whole project existed to prevent.

A reconciliation task changes that sequence at the first occurrence. The planner's line is not deleted; it is reported, with both values, in the same work queue as everything else. Somebody decides whether packaging belongs in the engineering BOM or whether the MBOM row of the matrix should move — and either answer is fine, because the point is that the question got asked in week one rather than month four.

How it meets the rest of the product

Tasks land in the ordinary work queue rather than a separate integration console, because a console nobody opens is where reconciliation work goes to be ignored. They carry an owner, an age and an escalation like any other task.

Resolving a difference in favour of Manufacturing PLM means raising a change, not editing a published structure — so the correction runs through change control with an impact set, an approver and an effectivity date. Resolving in favour of the ERP means either accepting the value or moving the matrix row, and moving a row is a configuration decision with a preflight.

Every sync is an attributed audit row naming the connector, the run and the direction, so “who changed this value” has an answer that names a system rather than trailing off. Sync history is queryable, and a reconciliation task links to the run that produced it.

Agents inherit the matrix, so no agent can resolve a difference by writing a field its owner masters. The Supplier and Cost agents surface reconciliation context in their answers rather than acting on it.

How it meets your ERP

The behaviour is identical across all six connectors because the disagreement is the same shape regardless of vendor. What differs is which fields are in scope, and that comes from each connector's published field map.

Nothing is overwritten on the strength of a matrix row alone. Ownership decides who is right in principle; it does not authorise a silent write over somebody's deliberate edit. The matrix tells the task which side to recommend, and a person accepts it.

Where a connector supports it, Manufacturing PLM reads back enough context to make the decision informed — whether the edited item has open purchase orders, whether the quantity change has already driven procurement. A difference with a purchase order behind it is a different conversation from one on a part nobody has bought yet.

Where the boundary is

Manufacturing PLM will not decide for you. There is no auto-resolve setting, and there deliberately will not be one: a rule that silently applies the matrix is indistinguishable from the overwrite behaviour this exists to replace, and the first time it discards a legitimate edit the integration loses its credibility permanently.

It also cannot reconcile what it cannot see. Fields outside the connector's field map are not compared, so a difference in an ERP field Manufacturing PLM does not read is invisible here. That is an argument for mapping the fields that matter rather than a claim that the queue is complete.