Dynamics 365 runs your MRP. Why is your inventory still…

Dynamics 365 runs your MRP. Why is your inventory still wrong?

Your master planning run is not wrong. It is doing precisely what you configured it to do. Microsoft ships the calculation engine and leaves four replenishment-policy decisions to you — and those four decide whether the output is worth reading. For the planner who dismisses the same exceptions every morning.

Master planning is a calculation. The decision is the policy you handed it

Master planning — Dynamics 365's name for MRP (material requirements planning) — nets demand against supply, applies the replenishment method assigned to each item, and emits planned orders — faithfully and fast. It has no opinion about whether the method was right.

Microsoft is unambiguous about the division of labour. "In Supply Chain Management, the Planning Optimization Add-in for Microsoft Dynamics 365 Supply Chain Management manages master planning," and the service "holds planning-related data in memory and performs the required calculations" (master planning system architecture). Calculation, not judgement. Four settings carry all of the judgement.

**Coverage segmentation — Where Dynamics 365 stores it: Coverage code, on the coverage group or overridden on Item coverage** · What it determines: The shape of every order: per requirement, batched into a period, held between a minimum and a maximum, buffered, or not planned
**Safety stock method — Where Dynamics 365 stores it: The Minimum field on Item coverage** · What it determines: How much cover each stocking point carries — and it defaults to zero
**Forecast netting — Where Dynamics 365 stores it: Method used to reduce forecast requirements on the master plan, plus Reduce forecast by** on the coverage group · What it determines: Whether a sales order consumes the forecast it was forecast against, or gets planned twice
**Time fences** — Where Dynamics 365 stores it: Coverage, freeze and forecast plan time fences · What it determines: What the engine may see, and what it may overwrite

Each is a data-science question dressed as a configuration field. Dynamics 365 manages them; it does not optimize them. That gap is the last mile, and your working capital sits in it.

What Microsoft ships — and what it has stopped supporting

Planning Optimization `[GA]` is an add-in, and it is cloud only. "To use Planning Optimization, install the Planning Optimization Add-in from your project in Microsoft Dynamics Lifecycle Services and turn on the Planning Optimization functionality in Supply Chain Management" (architecture). The deprecation register's deployment line: "Cloud only. Planning Optimization is not supported with on-premises deployments" (removed or deprecated features).

The built-in engine `[DEPR]` lost support for every deployment type in March 2023: "as of March 2023, Microsoft has now fully discontinued all support for the built-in master planning engine for all types of deployments. Hereafter, Microsoft will only provide support for critical blocking issues (which result in no planned orders being created or the continuous failure of built-in master planning)" (same page).

A second Microsoft page puts it flatter — "There are no bug fixes, no new features, and no investment in the engine going forward" — while setting no removal date: "There's currently no timeline for the full removal of the deprecated master planning engine from Supply Chain Management. Microsoft isn't currently planning to remove it" (deprecated master planning overview). Take both to your risk committee.

Policy decision one: coverage segmentation, and the list nobody agrees on

The coverage code decides the shape of every order the engine proposes, and most segmentation designs need one correction first: there is no coverage code called "DDMRP", and the list is longer than four.

Coverage settings publishes six: Manual, Per requirement, Per period, Min/Max, Priority, and Decoupling point — the last being "the coverage code that identifies a product as a decoupling point (buffer) according to the Demand Driven Material Requirements Planning (DDMRP) methodology." Replenishment methods publishes four under different spellings: Period, Requirement, Min./Max., Manual.

Coverage time fences says a behaviour "applies to all coverage codes: Period, Requirement, Min/Max, Priority, and Decoupling point" — five, Manual absent. A design written from one page is missing options. None of them tells you which of your items belongs in which code. That is a clustering problem over demand variability, unit cost and lead time: recorded by the ERP, optimized by nobody.

A half-configured code changes behaviour rather than failing: Min/Max with no minimum or maximum set means "the system creates one order per day to cover the full amount for that day" (differences from the deprecated engine). And item coverage silently outranks the group: "The coverage settings on the Item coverage page take precedence over the settings on the Coverage group page" (coverage settings).

Policy decision two: safety stock is one field, and it defaults to zero

Dynamics 365 stores safety stock as one number per stocking point, not as a live model. "In the Minimum field, enter the safety stock value. The master planning engine always generates planned orders to prevent the accumulated inventory level from falling below this limit... If you leave the field blank, a default value of 0 (zero) is used" (safety stock fulfillment).

Three ways in: manually on Item coverage, through the Data Management framework's Item coverage entities, or "By the safety stock calculation done by safety stock journals" (safety stock journal).

That journal [GA] is the closest thing in the box to a method: it "calculate[s] a proposed minimum quantity based on an item's historical usage", where "Historical usage represents all issue transactions during a specified period", offering Use average issue during lead time, Use service level and a Lead time margin. Read that input list — single-echelon, over past issues. Nothing models supplier lead-time variability or per-item forecast error, and it moves only when a planner runs it and posts.

Timing is out of your hands too. On Item coverage, "the setting of this field is ignored. (Instead, the system always behaves as though Fulfill minimum is set to Today's date + procurement time.)" (safety stock fulfillment), and Minimum periods sits among the settings Planning Optimization "doesn't support" (parameters not used). The engine defends that number. Nothing in the product owns it.

Policy decision three: forecast netting, and the option that is not a policy

If demand appears twice in your plan, this is where it happened. Method used to reduce forecast requirements on the master plan takes four values: "None", "Percent – reduction key", "Transactions – reduction key", "Transactions – dynamic period" (master planning with demand forecasts).

None is the absence of a policy, and Microsoft says what it costs: "if sales orders are placed, master planning creates additional planned orders to supply the sales orders. The quantity of the forecast requirements isn't reduced." Double-counting, documented, on purpose.

Beneath it sits a second switch on the coverage group, Reduce forecast by: "All transactions – All transactions reduce the forecast" or "Orders – Only sales orders reduce the forecast." Choose Orders and every intercompany issue, transfer and adjustment leaves the forecast standing. Also: forecast dated on or before today is discarded ("Master planning excludes forecast requirements from the past"), and separate forecast plans are gone ("Planning Optimization doesn't support separate forecast planning").

Upstream, the Demand planning app [GA] (generally available from version 1.0.0.1067) runs on its own release train, and its newer statistics are still preview: the "Best fit model - version 3 (preview)" algorithm carries Croston's method, "designed specifically for intermittent demand" [PP] (what's new in Demand planning). A preview algorithm netted by an unchosen policy is two unowned decisions stacked.

Policy decision four: time fences decide what the engine may even see

The coverage time fence is a horizon on what the engine reads. "If any approved supply and demand fall outside the coverage time fence, the system doesn't load them into the engine. Therefore, they don't trigger any replenishment, and the system doesn't calculate delays" (coverage time fences). Microsoft states the constraint — "you must ensure that the coverage time fence is longer than the total lead time" — and the default: "The default system value is 100 days."

Take a distributor buying a cast component overseas: lead time 75 days, ocean transit 21 days, goods-in and inspection 5 days. Total is 101. On the shipped default of 100 that demand is never loaded, nothing is replenished, no delay is calculated — the plan looks clean until the shortage. A supplier who quotes 75 and ships in 90 widens the same silent hole, which is why supplier date reliability is a replenishment input and not a procurement scorecard.

The freeze time fence is the other half, and here the documentation contradicts itself. The fit analysis row for Item coverage records with freeze time fence set reads "This feature is pending. Currently, the freeze time fence setup is ignored when Planning Optimization is enabled" — while the Expected availability column on that same row reads "Supported". The master-plan and coverage-group rows are unambiguous: "This feature is now supported. To use it, enable the Freezing time fence for Planning optimization feature in Feature management. As of Supply Chain Management version 10.0.43, this feature is turned on by default." The item-coverage row is not. Test that level in your own environment before relying on it.

The thirteen questions underneath this one

Every article in this cluster answers one.

**If you run Dynamics 365 SCM on-premises, do you have a supported MRP engine?** — Supply Chain Management on-premises — the cloud-only line
**What can Planning Optimization actually not do in 2026?** — Fit analysis plus not-used-parameters
**Why does your MRP produce twelve thousand action messages?** — Which action types, on which groups
**Time fence or time freeze — which one is deleting your planners' work?** — Two mechanisms, one name
**Which forecast algorithm should you use for intermittent demand?** — Croston's method, and its preview status
**Why does your plan look right in month three and absurd in month one?** — Reduction method, reduction-key periods
**Is DDMRP in Dynamics 365 actually free?** — Licence fees, prerequisite, buffer sizing
**Should master planning use finite or infinite capacity?** — The real constraint, the run-time cost
**Why does auto-firming fire at the wrong time under Planning Optimization?** — Order date, not requirement date
**Why is your supplier OTIF ninety-eight percent when deliveries are late?** — On time in full — and which date is measured
**Requirement, Period, Min/Max or Decoupling point — which coverage code for which item?* — Which code per item — and why Microsoft's DDMRP code is named Decoupling point*
**Demand planning app or master planning — where does the forecast actually live?** — Two release trains, one export path
**There is no S&OP module in Dynamics 365 — so what do you build?** — The missing consensus layer

Three are answered next: action message triage, forecast double-counting and the coverage code comparison.

"That is a configuration problem, not an AI problem"

The strongest objection, and half right. Every setting above is reachable in the client, and a good implementation partner will set sane defaults across the item master in a fortnight. If your coverage codes are unsegmented and your Minimum fields blank, buy that first.

It stops being right at the second derivative. Configuration sets a value once; the value has to stay correct as demand variability, lead times and cost move. Microsoft's own DDMRP page names the end state: "MRP tools often give planners thousands of actions to do. Therefore, it's hard to know what to focus on" (DDMRP overview). Each of those is "a system-generated suggestion to change an existing planned, approved, or firmed order" (action messages). That volume is not a defect. It is the calculation being honest about a drifted policy.

This is what Demand & Inventory Optimizer does. It segments the item master by demand variability, unit cost and lead time, computes the service-optimal Minimum per stocking point from forecast error and lead-time variability rather than an average of past issues, and writes them back to the coverage group and Item coverage through the supported entities, behind an approval step so a planner signs off first. Dynamics 365 stays the system of record and the engine calculates as documented. What changes is the policy it calculates from.

Where we would draw the line. We would not build a second planning engine — reproducing a hyper-scalable service is an expensive way to finish behind. We would not write to Minimum without an approval step; an optimizer that moves stock policy silently is one feature away from a stockout nobody can explain. We would not touch DDMRP buffer profiles before decoupling points have been positioned by people who know the network. And we would not start any of it while the deprecated engine is still running — policy optimization on an unsupported calculation optimizes the wrong layer.

What to do this week

Four checks, all in the client.

Run the fit analysis and read it as a policy document. Master planning > Setup > Planning Optimization fit analysis, then Run analysis, once per legal entity. Its results "just show places where the planning service doesn't honor your current setup."
Count your coverage groups. Master planning > Setup > Coverage > Coverage groups. Three groups over a ten-thousand-item master is three policies for ten thousand demand shapes.
Count the blank Minimums. Product information management > Products > Released products, then Item coverage on the Plan tab. Blank is zero, and zero is a policy.
Compare your coverage time fence with your longest total lead time. Lead time plus transit plus inspection over the fence is demand the engine never loads.

Those four numbers scope the problem. They are the four we ask for on a call.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Worked example. Modelled from public documentation and typical operations.

Bring those four numbers to a call and we will walk your replenishment policy — segmentation, Minimum derivation, write-back path — and show you Demand & Inventory Optimizer live against them. No deck. https://cognilium.ai

— Cognilium. We optimize the decisions your ERP can only manage.

Dynamics 365 runs your MRP. Why is your inventory still wrong?