Manufacturing PLM and Dynamics 365

What this connector is, and what it is not

It publishes released engineering structures into Dynamics 365 as versioned production bills of material with starting dates, and reads cost, inventory and vendor context back the other way.

Two products share the name and they are not the same system. Business Central models a Production BOM with a header, lines and versions carrying starting dates. Finance & Operations models released products, BOMs and BOM versions with their own site and validity semantics. The connector targets each on its own terms rather than reducing both to a lowest common denominator that fits neither.

What it is not is a replacement for the engineering change module in F&O. If you run change management there, Manufacturing PLM feeds it the released outcome; the review, redlines and approvals happen upstream where the affected-object analysis lives.

The mechanism: versions carry the date

In both products, the durable place for effectivity is the BOM version, not the BOM header. Manufacturing PLM releases into a new version with a starting date drawn from the change's effectivity, leaving prior versions intact so the record of what was buildable when survives.

Certification and approval state is respected rather than bypassed. A version published by Manufacturing PLM enters in the state your configuration specifies, so a site that requires manual certification before a version becomes usable keeps that control — the integration does not quietly promote structures past a gate somebody put there on purpose.

Transport is the OData interface each product exposes, with credentials held per tenant. Reads are targeted queries rather than full extracts, and writes are idempotent, so a retried run does not produce a duplicate version.

The failure it prevents

The Business Central version of this failure is subtle. Somebody edits the current BOM version in place rather than creating a new one, because editing is faster and the version is not yet certified. The change is real, it affects planning, and it exists nowhere in engineering.

Three months later an engineer runs a where-used in the PLM to scope an ECO, gets four assemblies, and misses the fifth — because the fifth relationship was created in Dynamics and the PLM has never seen it. The ECO ships incomplete.

Publishing to versions rather than in place, and raising a reconciliation task when a published version is edited downstream, closes that loop. The edit is still allowed; what changes is that engineering finds out about it in a work queue rather than nine months later in a warranty claim.

How it meets the rest of the product

The structure that publishes is resolved — effectivity, variants, revision policy and plant scope evaluated together into one configuration — because a BOM version holds a concrete structure and cannot evaluate conditions on its own.

Unit-of-measure handling matters more here than in most connectors, because a mismatch between engineering units and inventory units produces quantities that are wrong by a factor rather than wrong by an item, and factor errors survive review. Manufacturing PLM masters the unit and its conversions on mapped items and publishes both.

Cost, inventory and vendor fields read back and render read-only, labelled with the owning system. Rollups through the resolved structure use those values so an engineer can see the cost consequence of a design change without either system having to guess.

Where-used and impact analysis both run over resolved structures, which is why the answer to “which shipping products contain this part” is a different and more useful answer than “which structures mention it anywhere”. Dynamics receives the first one.

How it meets your ERP

Item identity matching runs on manufacturer part number first, internal number second, then a configurable tie-break. Dynamics will hold items Manufacturing PLM never created — packaging, freight, service items, non-stock — and those keep their own identity rather than being pulled into engineering's namespace. Unmatched items are surfaced for a person, never merged on a similarity score.

Every sync is an attributed audit row naming the connector, the run and the direction. Sync history is queryable, retries are bounded, and publication is all-or-nothing per release: a partially written structure looks complete to the planning run that reads it next, which makes it worse than a failed one.

Where your deployment differs — a heavily extended F&O environment, a BC tenant with custom item categories — the connector maps to what exists and reports what it cannot find. It does not create schema on your behalf.

Where the boundary is

No purchase orders, production orders, item journals, ledger entries or financial postings, in either direction. Manufacturing PLM reads inventory and cost as context and writes engineering definition; everything transactional stays in Dynamics.

Routings and work centres are not published by default. They belong to the MBOM row of the matrix, which is decided per tenant — if manufacturing engineering owns routings in Dynamics, Manufacturing PLM stops at the bill of material and does not pretend to have opinions past that line.