Effectivity: which parts are in the product, and when

What effectivity is, and what it is not

Effectivity is the condition under which a BOM line is part of the product. It is not a revision, and it is not a lifecycle state. A part can be released, current and fully approved and still not be in the product you are building today — because the line carrying it stopped being effective in June.

Most teams meet effectivity the first time a change has to take hold on a date that is not today. Engineering approves a new control board in August; production has six weeks of the old one on the shelf; the change takes effect on 1 October. Until that morning, both boards are correct answers to “what is in this assembly” — for different questions.

Effectivity is how the bill of materials holds both answers at once without a person arbitrating between them. Without it, teams solve the same problem with a spreadsheet column, a note buried in the ECO, and somebody's memory. All three work until the person who maintains them is on holiday.

Three dimensions, because manufacturing has three

Manufacturing PLM carries effectivity on three independent dimensions, and a line may use any combination of them.

Date effectivity answers “what is in the product as of this day”. It is what most changes use, and it is what your ERP's MRP run needs in order to plan.

Unit effectivity answers “what is in serial number 1420”. Serialised products — machines, instruments, vehicles — change mid-run, and a unit built in March is not the unit built in November. Unit effectivity is the only honest way to answer a field service question two years after shipment.

Plant effectivity answers “what is in the product built in Frankfurt”. The same product built at two sites often differs: a different connector, a local label, a regionally sourced fastener. A single global BOM that pretends otherwise gets corrected by hand on the shop floor, and those corrections never make it back.

Because the three are independent, they compose. A line can be effective from 1 October, on units 1400 and above, at FRA-2 only.

Ranges, not single dates — and the two failures they expose

A single “effective from” date on each line looks sufficient right up until two lines disagree. Manufacturing PLM stores effectivity as ranges, with an explicit start and an explicit end — either of which may be open — and the resolution engine checks every set of sibling ranges for two conditions.

An overlap is two lines effective at the same moment in the same position: two control boards in one slot. The structure no longer resolves to a single answer, so something downstream picks one arbitrarily and nobody is told which.

A gap is a window where no line is effective at all. The old part ended on 30 June, the new one starts on 16 September, and for eleven weeks the assembly has a hole in it. A gap is almost always a typo, and it is almost always found by a buyer running a shortage report rather than by the engineer who made it.

Both conditions are detected when the change is drafted. The figure above is what that check looks like on screen: the overlap named in days, the gap named in days, and both anchored to the lines that caused them.

How it meets the rest of the product

Effectivity is not a field on a screen; it is one of four conditions the resolution engine takes, alongside revision policy, variant selection and plant scope. That has a consequence worth stating plainly: every read path in Manufacturing PLM is effectivity-aware, because every read path goes through the same resolver.

BOM compare resolves both sides before diffing, so a comparison never reports an effectivity decision as a difference. Where-used answers “which products contain this part today” and “which contained it in March” from one query. Cost, mass and compliance rollups sum only the lines actually effective under the conditions you asked for. The Change Agent's impact analysis walks the effective structure and cites the date it read it at.

The alternative — effectivity handled feature by feature — is how a PLM ends up with a compare screen and a cost report that quietly disagree, and no way to tell which one is lying.

How it meets your ERP

The released, resolved BOM masters in Manufacturing PLM and publishes outward; cost, on-hand and lead time master in the ERP and are read back. Effectivity sits exactly on that seam.

When a change releases, Manufacturing PLM publishes the resolved structure with its effectivity dates attached, in the shape the target system expects — a dated BOM revision in NetSuite, an engineering change with a valid-from in SAP S/4HANA, a revision record in Dynamics 365 Business Central. Where the target ERP does not model unit or plant effectivity, the flattening rule is written in the connector configuration rather than assumed, so two people reading the same sync agree on what happened.

If someone edits the published BOM inside the ERP, Manufacturing PLM does not silently overwrite it on the next run. The sync raises a reconciliation task naming the field, both values, and which system owns it under the system-of-record matrix.

Where the boundary is

Effectivity in Manufacturing PLM governs product definition, not execution. It does not schedule production, allocate inventory, or decide which of the six control boards sitting in the stockroom gets consumed first — those are ERP and MES decisions and Manufacturing PLM does not attempt them.

It also does not govern document content: a drawing's revision is controlled by revision and lifecycle, not by an effectivity range. And if you need use-up-the-old-stock-first logic, that rule lives in your ERP and reads the effectivity Manufacturing PLM published to it.