What crosses the seam, and when
Publication is where a change stops being an engineering record and starts driving purchase orders. Two things decide whether that goes well: what triggers it, and whether the effectivity date travels with it.
Field map — object by object
| Manufacturing PLM object | Lands as | Master | Direction | On conflict |
|---|---|---|---|---|
| Released structure | Dated BOM revision / production BOM | Manufacturing PLM | Manufacturing PLM → ERP on release | Reconciliation task, never an overwrite |
| Effectivity | Valid-from / effective-start date | Manufacturing PLM | Manufacturing PLM → ERP | Dates are engineering's |
| Part | Item / released product | Manufacturing PLM | Manufacturing PLM → ERP on first release | Matched, never renumbered |
| Change record | Change master / revision record | Manufacturing PLM | Manufacturing PLM → ERP | Manufacturing PLM creates; ERP edits are flagged |
| Draft or in-work structure | — | Manufacturing PLM | **Never published** | There is no path for it to cross |
What it is, and what it is not
The outbound half of the connector: taking a change that has just released and landing its result in your ERP as something the planning run can act on.
It is not a synchronisation. Synchronisation implies two systems converging on a shared state, which is the wrong model — one system owns each fact, and publication moves an owned fact outward at a defined moment.
It is also not continuous. “Continuously” is not a trigger; it is a way of avoiding the question of when, and it is how integrations end up firing during a month-end close. The trigger for a released structure is the release itself.
The mechanism: resolved, dated, atomic
Resolved. What crosses is a concrete structure, not the stored one. A stored BOM is a conditional statement — effective from these dates, for these options, at these plants — and an ERP bill of materials has no way to evaluate conditions. So Manufacturing PLM resolves at the change's effectivity and sends the single configuration that results.
Dated. The effectivity travels with the payload and lands in the field the planning run already reads: a dated BOM Revision in NetSuite, a Change Master with a valid-from in SAP, a versioned Production BOM in Dynamics, a dated revision in Acumatica. An effectivity written into a custom field or a description is invisible to planning, which makes it worse than useless — it looks like the problem was handled.
Atomic. A release publishes completely or not at all. Retries are bounded and idempotent, so a retried run does not create a duplicate revision, and a failed run leaves nothing behind. A half-published structure looks complete to whatever reads it next, which makes it more dangerous than an outright failure.
The failure it prevents
A change is approved in August to take effect on 1 October, because production has six weeks of the old component on the shelf. The integration fires on approval and stamps today's date.
For six weeks the planning run believes the new structure is current. It nets requirements against the new component, releases purchase orders for it, and stops consuming the stock whose depletion set the October date in the first place.
Nothing errored — both systems did exactly what they were configured to do. The stock is discovered later as excess and written off, and the integration gets blamed for something that was a modelling decision. Publishing on release while carrying the effectivity date keeps approval and effect as two events in both systems, which is what engineering intended when they chose October.
How it meets the rest of the product
Publication sits downstream of the workflow engine rather than being a step inside it. A workflow completes, the change releases atomically, and publication happens as part of that release. That keeps retry semantics in one place: the connector owns its bounded retries, and a workflow never has to model your ERP being unavailable.
Because the release transaction is atomic across every affected object, there is no window in which some revisions have moved and others have not — so what publishes is internally consistent by construction rather than by ordering luck.
Impact analysis reads the other direction and marks objects already published, with the ERP context read back against them. A reviewer approving a change sees which affected parts carry open demand before deciding, not after.
Nothing in-work has a path outward. Drafts, iterations and unreleased revisions are not filtered from the payload — they are not the kind of thing publication operates on.
How it meets your ERP
What differs per connector is shape, not ownership. The same resolved structure becomes a dated BOM Revision, a Change Master with a valid-from, a versioned Production BOM, a Part Revision, or a dated revision — and each connector page publishes its own field map alongside the shared matrix.
Where the target cannot model something Manufacturing PLM holds, the flattening rule is written in the connector configuration rather than inferred at run time. Unit-number effectivity is the usual case: an ERP that models dates but not serial ranges gets a stated rule, so two people reading the same sync agree about what happened.
If a published structure is edited in the ERP afterwards, the next run raises a reconciliation task naming the object, the field, both values and the owning system. It does not overwrite. Somebody edited it for a reason, often a good one, and a PLM that silently wins that argument overnight gets switched off within a quarter.
Where the boundary is
Nothing transactional crosses in either direction. No purchase orders, production orders, goods movements, invoices or ledger entries. Manufacturing PLM writes engineering definition and reads operational context, and the line is the same on every connector page.
Publication also does not schedule the change in the world. It carries the date engineering chose; whether a plant can absorb the change on that date is a conversation, and no integration setting substitutes for having it.
Facts
| Trigger | Change release — never a clock, never “continuously” |
| Payload | The resolved structure, not the stored conditional one |
| Effectivity | Travels with it, into the field planning already reads |
| Atomicity | All or nothing per release |
| Retries | Bounded and idempotent — no duplicate revisions |
| Per connector | Shape differs; ownership does not |
| Flattening | Stated in config where the target cannot model something |
| In-work data | Has no path outward at all |
Frequently asked
When does publication happen?
On change release, carrying the effectivity date rather than today's. Approval and effect stay two separate events in both systems, which is what engineering intended when they chose a future date. Continuously is not a trigger; it is a way of avoiding the question.
Why send a resolved structure rather than the rules?
Because a stored BOM is a conditional statement and an ERP bill has no way to evaluate conditions. Manufacturing PLM resolves at the change's effectivity and sends the single configuration that results, which is both simpler and impossible to disagree with silently.
What happens if a publish fails halfway?
Nothing lands. Publication is all-or-nothing per release, retries are bounded and idempotent, and the run appears in sync history with its error. A half-published structure looks complete to whatever planning run reads it next, which is worse than failing outright.
Can a draft accidentally reach our ERP?
No, and not because it is filtered out. Drafts, iterations and unreleased revisions are not the kind of object publication operates on — there is no code path that could carry one outward, so it is not a setting somebody can get wrong.
What if our ERP cannot model unit effectivity?
The flattening rule is written in the connector configuration rather than inferred at run time. An ERP that models dates but not serial ranges gets a stated rule, so two people reading the same sync afterwards agree about what actually happened and why.
What if somebody edits the published BOM?
The next run raises a reconciliation task naming the object, the field, both values and the owning system. It does not overwrite. Somebody edited it for a reason, often a good one, and a PLM that wins that argument silently at 2am gets switched off.
Does anything transactional cross?
Nothing at all, in either direction. No purchase orders, no production orders, no goods movements, no invoices and no ledger entries. Manufacturing PLM writes engineering definition and reads operational context as impact-analysis input, and that boundary is identical on every one of the connector pages.