Engineering Changes and Revisions in D365: Reflecting Them in BOMs and Production Orders

When I talk to production managers about their biggest recurring headaches, engineering changes come up more often than anything else. A revision lands, and suddenly nobody is sure which BOM version the shop floor is building against, whether the orders already released should finish on the old revision or be pulled back, and why the warehouse just picked a component that engineering obsoleted two weeks ago. The change itself is rarely the problem. The propagation is.

D365 Supply Chain Management gives you two mechanisms for handling this: the classic BOM versioning model that has been in the product since the AX days, and the Engineering Change Management (ECM) module. In this article I will cover both, and, more importantly, the part most implementations leave undefined: what happens to production orders that are already in flight when the revision changes underneath them.

THE FOUNDATION: BOM VERSIONS AND EFFECTIVITY

Everything starts with the fact that an item does not have "a BOM" in D365; it has BOM versions, each with an approval status, an activation flag, and effectivity criteria: from/to dates, from/to quantities, and site. When planning or a production order needs a BOM, the system selects the active, approved version whose effectivity matches the date, quantity, and site of the demand.

That selection logic is your simplest change mechanism. A clean revision cutover without any extra modules looks like this:

1. Create a new BOM version for the item (copy the old one as a starting point).

2. Make the component changes on the new version.

3. Set the new version's from-date to the cutover date, and the old version's to-date to the day before.

4. Approve and activate the new version.

From that point, every planned order and every new production order with a delivery date past the cutover picks up the new structure automatically. Master planning is date-sensitive here, which surprises people: planned orders scheduled before the cutover still explode the old version, and orders after it explode the new one. That is exactly what you want for a phase-in driven by component run-out.

The weakness of doing this manually is governance. Nothing forces a where-used analysis, nothing tracks why the change happened, and nothing stops a planner from activating a version while purchasing still has three months of the old component on order. That is the gap ECM closes.

ENGINEERING CHANGE MANAGEMENT: THE GOVERNED PATH

The ECM module adds a controlled lifecycle around exactly the steps above. The pieces that matter:

• Engineering products: items created under an engineering category, owned by an engineering legal entity, carrying a version that is either a separate field or an actual product dimension (more on that choice below).

• Engineering change requests (ECR): the formal "we have a problem or an idea" record. Anyone can raise one; it carries no product data changes itself.

• Engineering change orders (ECO): the executable change. An ECO bundles the affected products, the new version definitions, BOM and route changes, and an impact analysis, and pushes everything through an approval workflow before anything touches the active data.

• Readiness checks and release policies: gates that verify the new version is actually buildable (BOM approved, route approved, item data complete) before it is released to the operating legal entities.

The single most valuable screen in the module, in my experience, is the impact analysis on the ECO. It runs where-used across BOMs, open purchase orders, open sales orders, and open production orders, and forces the change board to answer the question they otherwise skip: what do we do with everything currently in motion? Use up old stock? Rework? Scrap? Finish open orders on the old revision? The decision gets recorded on the change order instead of living in a hallway conversation.

One design decision deserves real thought before you turn ECM on: whether the version is a product dimension. If you make version a dimension, you can carry inventory of revision A and revision B separately, sell them separately, and trace them separately; this is the right answer in regulated industries and anywhere form-fit-function changes matter. If revisions are always interchangeable, keep the version as a plain attribute and spare yourself a dimension on every transaction. Switching this choice later is painful, so make it deliberately.

THE PART EVERYONE GETS WRONG: IN-FLIGHT PRODUCTION ORDERS

Now the operational core. A production order does not reference the BOM version dynamically; it takes a snapshot. At estimation, the BOM and route are exploded into the production BOM and production route, which are copies owned by the order. After that point, changing the master BOM does nothing to that order.

This gives you a clear rulebook by order status:

• Created, not yet estimated: nothing to do. The order will explode whichever version is effective when you estimate it.

• Estimated or scheduled, not started: the order holds a snapshot of the old version. If the change must apply, reset the order status back and re-estimate it so the explosion runs again against the new active version. This is the cleanest fix and it is criminally underused; most users do not know status can go backwards.

• Started, materials picked: re-estimating is now disruptive because picking work and consumption already exist. Here you decide per order: finish on the old revision (the usual answer for minor changes), or manually edit the production BOM lines on the order to swap components (acceptable for one or two orders, miserable at scale), or end the order short and create a new one on the new revision (the honest answer when the change is safety-critical).

• Reported as finished: the revision question moves to inventory. If version is a product dimension you already have clean separation; if not, batch numbers are your traceability fallback, so make sure the cutover date is recorded against batches.

If the change is urgent and safety-related, the impact analysis from the ECO is what tells you how many orders sit in each of these buckets before you commit to a strategy. Without ECM, build yourself the same picture with a where-used inquiry plus a filtered production order list before touching anything, not after.

PHASE-IN STRATEGIES THAT ACTUALLY WORK

Three patterns cover nearly every real change:

• Date-driven cutover: both versions exist, effectivity dates do the work, planning consumes old stock naturally. Best for cost reductions and non-critical substitutions. The discipline needed: someone owns watching the run-out so the to-date matches reality.

• Immediate mandatory cutover: new version activated now, old version expired, every unstarted order re-estimated, started orders dispositioned one by one, remaining old stock blocked or scrapped through quality orders. Expensive and noisy; reserve it for safety and regulatory changes.

• Use-up with engineering visibility: the new version is approved but its from-date floats; purchasing stops replenishing the old component and the planner activates the new version when stock hits zero. This needs a weekly review, but it wastes the least money.

TAKEAWAYS

BOM versions with effectivity dates are the engine of every engineering change in D365; ECM adds the governance, impact analysis, and version traceability that manual versioning lacks. Decide early whether revision needs to be a product dimension, because that choice is nearly irreversible. And write down the in-flight order rulebook by status (re-estimate unstarted orders, disposition started ones deliberately) so the shop floor is not inventing policy at 6 a.m. on cutover day. Changes are constant; chaos is optional.

Next time I will look at the costing side: what BOM changes do to standard cost, and how to time cost recalculations around revision cutovers.

In this series: previous article BOM Line Types in D365 · next article BOM Changes and Standard Cost in D365