Back to Blog
Published:
Last Updated:
Fresh Content
Demand & ReplenishmentChapter 7

Is DDMRP in Dynamics 365 actually free?

8 min read
1,726 words
high priority
Muhammad Mudassir

Muhammad Mudassir

Founder & CEO, Cognilium AI

TL;DR

A qualified yes. Microsoft states Supply Chain Management "includes DDMRP with no additional license fees" — but DDMRP requires the Planning Optimization Add-in, which requires a Supply Chain Management licence, a tier-2 or higher Lifecycle Services environment, and a cloud deployment. The licence is the cheap part; the decoupling-point analysis is not.

Is DDMRP in Dynamics 365 actually free?

Yes, with a qualifier that matters more than the answer. Microsoft charges nothing extra for the functionality. It charges for everything DDMRP sits on, and the expensive part was never the licence anyway.

The sentence, and the sentence that qualifies it

Microsoft's statement is exact and worth quoting rather than summarising: "Microsoft Dynamics 365 Supply Chain Management includes DDMRP with no additional license fees."

DDMRP [GA] — Demand Driven Material Requirements Planning, a buffer-based method that breaks the link between demand signal and supply order at chosen points in the network — is a capability of the Master planning module, not a separate purchase.

The qualifier is two sentences later on the same page: "However, it requires that you use the Planning Optimization Add-in."

That is not a second bill. Microsoft is equally explicit on the Planning Optimization page: "You can run master planning using your current Supply Chain Management licenses… There are no extra costs associated with using Planning Optimization." It is a set of preconditions, and each one is a place a project stops.

  • **A Supply Chain Management licence** — What Microsoft states: "Your Microsoft Entra account must have a Supply Chain Management licensed assigned to it" — Microsoft's wording, typo included · What it costs you: Per-user licensing, unchanged
  • **A tier-2 or higher environment** — What Microsoft states: "a Lifecycle Services enabled high-availability environment, tier 2 or higher (not a OneBox environment)" · What it costs you: Environment cost. The add-in "can't be installed on a development (OneBox) environment"
  • **Version 10.0.23 or later** — What Microsoft states: Stated as a floor for installing the add-in · What it costs you: An upgrade, if you are behind
  • **Power Platform integration** — What Microsoft states: "Your system must be set up for Power Platform integration" · What it costs you: A platform project, not a planning one
  • **A cloud deployment** — What Microsoft states: "Planning Optimization doesn't support on-premises deployments of Dynamics 365 Supply Chain Management" · What it costs you: If you run on-premises, DDMRP is unavailable at any price
  • **A supported Azure geography** — What Microsoft states: Microsoft lists the geographies where the service is available · What it costs you: Nothing, unless you are outside the list
  • **A Power Platform admin account* — What Microsoft states: "You must sign in to your Power Platform environment using an account with administrator privileges and an access mode of Read-Write*" · What it costs you: A permissions request, usually to a team outside supply chain

Two more steps that are neither licence nor money but do consume a change window: the Planning Optimization configuration key is enabled under System administration > Setup > License configuration with the system in maintenance mode, and the add-in "must be installed separately on each environment where you use Planning Optimization, regardless of any code moved between the environments." Sandbox parity is a manual act.

Not a module, and not a substitute for the MRP you already run

This is the sentence to put in front of anyone proposing a DDMRP programme: "DDMRP isn't a new module, and it doesn't replace existing planning functionality." Microsoft adds that it "integrates with the existing planning setups" and is controlled by "a new coverage code… completely different from period, min/max, requirement, and so on."

Which code, exactly? Decoupling point — the value that Microsoft documents as "the coverage code that identifies a product as a decoupling point (buffer) according to the Demand Driven Material Requirements Planning (DDMRP) methodology."

And the operating boundary is stated plainly on the planning page: "Master planning calculates only decoupled items by using DDMRP. All other items are calculated by using standard material requirements planning (MRP)."

That single line is the whole failure mode. Applying Decoupling point to every item is not an aggressive rollout — it is a category error. The method's value comes from the items you don't buffer.

The five components, and which three you will actually be doing

Microsoft names five sequential components, and tells you how they split: "The first three components essentially define the initial and evolving configuration… The last two components define the day-to-day operation."

  • **Strategic inventory positioning** — "Identify decoupling points in the supply chain network"
  • **Buffer profiles and levels** — "identify the buffer sizes (minimum quantity, maximum quantity, and reorder point) and the reorder quantity"
  • **Dynamic buffer adjustments** — "Adjust buffer levels, based on varying operating parameters or planned future events"
  • **Demand-driven planning** — "Generate supply orders as they're required" — manufacturing, purchase and stock transfer orders
  • **Highly collaborative and visible execution** — "Run the supply orders with the help of visualization"

Components four and five are the software doing its job. One, two and three are a supply-chain design exercise, and they are what the licence does not include.

Where the money is: choosing the decoupling points

Microsoft does publish selection criteria, and they are specific. On inventory positioning, you are told to "consider all the following aspects of each item in the BOM as criteria": External variability, Inventory leverage and flexibility, Critical operation protection, Customer tolerance time, Sales order visibility horizon, and Market potential lead time.

Microsoft's worked pillow example shows the payoff: cumulative lead time of twenty-one days, and after decoupling, a decoupled lead time of five days, because "the decoupled items are always in stock. Therefore, they have a lead time of 0 (zero)."

Our method for sequencing those six criteria is ours, not Microsoft's. We run them in this order, because it fails fast and cheaply:

  1. Customer tolerance time against cumulative lead time. If customers wait longer than you take, you have a scheduling problem, not a buffering one. Stop here.
  2. Critical operation protection. Find the single machine or single supplier every route passes through. That constraint chooses its own buffer.
  3. Inventory leverage and flexibility. Buffer the part that serves the most finished goods, not the finished good — one buffer, many outcomes.
  4. External variability. Buffer where the variability enters from outside, which is usually the purchased end, not the customer end.
  5. Sales order visibility horizon and market potential lead time. These decide whether the last buffer belongs at the finished good, and they are a commercial argument, not a planning one.

The cost that recurs: component three

Buffers set once are buffers wrong within a quarter. Microsoft's third component exists for this, and the mechanism is the Demand adjustment factor, which "multiplies the ADU in all calculations for the selected period" — ADU being average daily usage, the demand rate every buffer is sized from.

Microsoft's own description of a full implementation is unambiguous: "In a full DDMRP implementation, you calculate new buffer values every day through a batch job and automatically accept them. You then run planning as a batch job and review the planned orders every day to refill the buffers" (buffer profile and levels).

That daily review is the real running cost, and it is a role, not a licence line.

One detail worth knowing before you set the two buffer factors: neither published range is Microsoft's own recommendation, and the two pages do not agree. The inventory positioning page says "DDMRP methodology recommends a value between 0.00 and 0.40 for items that have low variability"; the buffer page gives the low-variability band as "0.20–0.40" and attributes it to the Demand Driven Institute. The engine applies whatever decimal you enter, so the number is a policy choice either way. Set the factor deliberately and record why.

"There is no licence fee, so the risk is low — switch it on for the A items"

The premise is right and the conclusion does not follow. A licence-free feature can still be an expensive commitment, because the cost sits in analysis and in a daily operating rhythm you either staff or abandon.

There is also an interaction people miss. Priority-based planning [GA], which Microsoft says "adds support for demand-driven planning, which is one step of" DDMRP, carries this: "The system doesn't generate action messages for coverage codes with priority-based planning."

DDMRP uses that same machinery — to set order priority it "uses priority-based planning functionality instead of requirement dates". Microsoft's sentence names "coverage codes with priority-based planning" without listing them, so confirm the exception behaviour for decoupled items in your own environment rather than assuming it. Either way, how your planners find problems is part of this decision, not a discovery after it.

Where we would draw the line

We would not set Decoupling point on an item until someone can name which of Microsoft's six criteria it satisfies. We would not start a DDMRP programme where nobody owns the daily buffer recalculation, because component three decays silently and takes the results with it.

And we would not run it at all on a network whose lead times are unmeasured. Every buffer here is a function of decoupled lead time and average daily usage, so a bad lead time produces a confident, precisely wrong buffer.

Dynamics 365 manages the buffer once you have set it. Choosing where the buffers go, and what they should be this week rather than at go-live, is the optimization it leaves to you — and it is exactly what Demand & Inventory Optimizer does: it scores decoupling candidates on live lead-time and demand behaviour and writes the buffer levels back into Dynamics behind an approval step.

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/

If you are deciding where the buffers go, book a fifteen-minute call and we will walk the decoupling analysis with you against your own BOMs, live — no deck. https://cognilium.ai

Sources

Sources

Share this article

Muhammad Mudassir

Muhammad Mudassir

Founder & CEO, Cognilium AI

Mudassir Marwat's argument is that ERP systems record decisions they never optimise.

Founder & CEO of Cognilium AI; 37 AI agents in production across four products; 4 production AI products built and operated; three clouds in production (AWSGCPAzure)
Agentic AIRAG → GraphRAG retrievalVoice AIMulti-Agent Orchestration
Next in this series
Should master planning use finite or infinite capacity?
Chapter 8 · 8 min
In short

Key takeaways

  • Microsoft states that Supply Chain Management includes DDMRP with no additional licence fees. The qualifier is that DDMRP requires the Planning Optimization Add-in, which requires a Supply Chain Management licence, a high-availability Lifecycle Services environment and a cloud deployment.
  • If you run Supply Chain Management on-premises, DDMRP is not available at any price, because Planning Optimization does not support on-premises deployments.
  • DDMRP is not a module and does not stand in for existing planning. Microsoft calculates only decoupled items with DDMRP; everything else is planned by standard material requirements planning.
  • Applying the decoupling-point coverage code to every item removes the whole benefit, because the method works by breaking the demand signal at a few chosen positions.
  • The recurring cost is the third component, dynamic buffer adjustment. Microsoft's own description of a full implementation is a daily recalculation batch job and a daily review of planned orders.
What goes wrong

Common mistakes to avoid

  • Reading "no additional license fees" as "no cost", and skipping the environment, version and Power Platform prerequisites that decide whether the add-in installs at all.
  • Setting the decoupling-point coverage code broadly to see what happens, instead of choosing positions against Microsoft's published criteria.
  • Calculating buffers once at go-live and never scheduling the recalculation job, which leaves every buffer sized for a demand pattern that has since moved.
  • Installing the add-in in production and assuming the sandbox matches. Microsoft requires it to be installed separately on each environment.
  • Assuming decoupled items still produce the same exception messages. Microsoft states that no action messages are generated for coverage codes with priority-based planning, and does not list which codes that covers — so confirm it before planners rely on it.