Requirement, Period, Min/Max or Decoupling point

Requirement, Period, Min/Max or Decoupling point — which coverage code for which item?

The question has a longer answer than it implies, because Microsoft's coverage settings page lists six coverage codes, not four. And three Microsoft pages give three different lists.

One correction before anything else, because it is the thing people search for and cannot find. DDMRP is the methodology, not a value in the field. The coverage code is Decoupling point. If you have been searching the setup form for "DDMRP", that is why you could not find it.

Start with the list Microsoft actually publishes

The coverage code is the per-item replenishment policy, and Microsoft's coverage settings page names six of them [GA]: Manual, Per requirement, Per period, Min/Max, Priority and Decoupling point. Microsoft calls them "replenishment methods, or lot-sizing methods" and says the system uses them "to determine the batch size for purchased or produced items."

Before the comparison, the naming, because it decides what you go looking for in the interface.

[Coverage settings](https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/coverage-settings) — Manual · Per requirement · Per period · Min/Max · Priority · Decoupling point
[Replenishment methods and quantity modification](https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/planning-optimization/replenishment-methods-quantity-modification) — Period · Requirement · Min./Max. · Manual
[Coverage time fences](https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/planning-optimization/coverage-time-fence) — Period · Requirement · Min/Max · Priority · Decoupling point

The forms Per requirement and Per period appear on the coverage settings page. The procedure page for coverage rules uses the shorter form — Microsoft's task guide for coverage rules says "In the Coverage code field, select an option. Select Requirement for this procedure."

We are not going to adjudicate which of the three is the interface. What the pages support is narrower and more useful: the long forms Per requirement and Per period appear on one page, the short forms appear on the other two, and the procedure page tells you to select Requirement. If you searched the docs for "Per period" and found one page, that is why.

What Microsoft documents each one doing

Behaviour first, because everything else follows from it. Quoted from the two pages above.

**Requirement** — What Microsoft documents it does: "the system creates a planned purchase, transfer, or production order for each requirement of the item" — one supply per demand · Prerequisite Microsoft states: None
**Period** — What Microsoft documents it does: "combines all the demand for a period into one order… planned for the first day of the period", the next period starting "with the next requirements of the item" · Prerequisite Microsoft states: None
**Min/Max** — What Microsoft documents it does: "replenishes inventory up to a certain level when the predicted on-hand quantity is below a threshold. The replenishment quantity is the difference between the maximum level and the predicted on-hand level" · Prerequisite Microsoft states: None
**Manual** — What Microsoft documents it does: "the system doesn't suggest purchase, transfer, or production orders for the item. The planner for the item is responsible for creating the required orders" · Prerequisite Microsoft states: None
**Priority — What Microsoft documents it does: "replenishes buffers for a product according to its minimum, reorder point, and maximum stock quantities… For replenishing, priority (not date) is considered" · Prerequisite Microsoft states: "available for the Coverage code** field only when Planning Optimization is enabled"
**Decoupling point** — What Microsoft documents it does: "identifies a product as a decoupling point (buffer) according to the Demand Driven Material Requirements Planning (DDMRP) methodology" · Prerequisite Microsoft states: DDMRP "requires that you use the Planning Optimization Add-in"

Two of the six are not lot-sizing rules at all. Priority works by urgency rather than requirement date, and Decoupling point triggers when the net flow position falls below the reorder point — which Microsoft calculates as on-hand plus on-order minus qualified demand.

Choosing either of those two is a change of planning method, not a change of batch size.

Which item each one fits — and who is saying so

Microsoft publishes fit guidance for four of the six. For the other two it publishes selection criteria or nothing at all. The middle column below is Microsoft's, quoted. The right-hand column is ours — our reading of what the documented behaviour implies, and it carries no Microsoft authority.

**Requirement** — The item Microsoft says it fits: "expensive products that have intermittent demand"; "often used for configurable products or make-to-order scenarios" · The signal we watch for (ours, T2): Move off it when one demand line reliably produces one supply order that a buyer then merges by hand
**Period** — The item Microsoft says it fits: "non-predictable inventory draw, season-influenced products, or high-cost products" · The signal we watch for (ours, T2): Move off it when the period length was copied from another item rather than derived from the order cycle you actually run
**Min/Max** — The item Microsoft says it fits: "predictable inventory draw, high runners, or less expensive products" · The signal we watch for (ours, T2): Move off it when demand stops being predictable — the threshold is static and will not tell you it has gone stale
**Manual** — The item Microsoft says it fits: "products for which you don't want the system to generate planned orders" · The signal we watch for (ours, T2): Review it every quarter. Manual is where phase-outs go to be forgotten
**Priority — The item Microsoft says it fits: The priority-based planning page documents no item profile.** It describes the mechanism — urgent demand prioritised over less important demand, larger orders split by priority range · The signal we watch for (ours, T2): We use it where the useful question is "what do I replenish first", not "when is it due" — distribution centres and consumables with many concurrent shortages
**Decoupling point — The item Microsoft says it fits: Microsoft publishes six selection criteria, not an item type:** External variability · Inventory leverage and flexibility · Critical operation protection · Customer tolerance time · Sales order visibility horizon · Market potential lead time · The signal we watch for (ours, T2): We only reach for it once customer tolerance time is shorter than cumulative lead time. Below that threshold, buffering solves a problem you do not have

That is the honest state of the evidence. Microsoft owns "what this code does" completely, and owns "which item" for four codes. For Priority and Decoupling point, the fit call in the right-hand column is ours and should be argued with rather than deferred to.

Microsoft's own decoupling example is worth reading before you argue: a pillow with a cumulative lead time of twenty-one days, reduced to a decoupled lead time of five days once the foam billets, the fabric kit and the finished good are buffered, because decoupled items "are always in stock. Therefore, they have a lead time of 0 (zero)" (inventory positioning).

What rides along with the choice

The coverage code is not a single setting. Three consequences travel with it and they surprise people at go-live.

Exception load. Under Priority, Microsoft states plainly: "The system doesn't generate action messages for coverage codes with priority-based planning." Moving a population onto it removes those items from the exception list your planners work from.
Engine scope. Under Decoupling point, "Master planning calculates only decoupled items by using DDMRP. All other items are calculated by using standard material requirements planning (MRP)." The two methods run side by side, per item, in one plan.
What the code cannot escape. The coverage time fence is set on the coverage group, the item coverage record or the master plan — never on the code. Microsoft states that its derived-requirement filtering "applies to all coverage codes: Period, Requirement, Min/Max, Priority, and Decoupling point", through the Filter derived requirements by coverage time fence with Planning Optimization feature. Microsoft places that feature in the Feature management workspace "in Supply Chain Management version 10.0.49 and later", and states that in "version 10.0.48 and earlier, this feature isn't available". The page assigns it no GA or preview label.

One more that is not a coverage-code setting but behaves like one: Min/Max changes shape when a Multiple is defined on default order settings. Microsoft: "the Min./Max. replenishment method changes its behavior and considers the Multiple value", replenishing to "the first possible value that, together with predicted on-hand level, is below the maximum level" — and, where that sum would fall under the minimum, to "the first value that, together with predicted on-hand, is above the maximum level". Microsoft's own third example lands above the maximum, so the rule has two branches and only one of them is the one people remember.

The three questions we ask, in this order

Ours, not Microsoft's. It fits on one page and it is faster than a matrix.

Does a human have to decide this one? If yes, Manual, and put a review date on it. If no, continue.
Is demand predictable enough to hold a threshold? If yes, Min/Max, and set the Multiple deliberately because it changes the arithmetic. If no, continue.
Is demand intermittent as well as expensive? If yes, Requirement — that is Microsoft's own fit for it. If demand is expensive but arrives in waves you can batch, Period, with a period length taken from your real order cycle rather than copied from another item.

Then the two overrides, which are policy decisions rather than item decisions. If the useful question is "what first" rather than "when", Priority. If customer tolerance time is shorter than cumulative lead time and you can name which of Microsoft's six criteria the position satisfies, Decoupling point.

And one grouping rule from Microsoft that quietly constrains all of it: "items in the same coverage group should have similar lead times." A group holding a two-day fastener and a sixteen-week casting cannot carry one correct negative-days value, whatever coverage code it has.

Where this goes wrong

The common failure is not a wrong code. It is one code for everything, inherited by default: Microsoft's fallback is that if no coverage group is linked to a product, master planning "uses the general coverage group that you specify on the Master planning parameters page." Nobody chose that policy for those items; it was the shape of the setup.

The second failure is treating Decoupling point as an upgrade. It is a different method with a different unit of work, and applying it broadly removes the decoupling that gives it its value.

The third is the one that costs money quietly: a code chosen correctly in 2019 and never revisited. Demand variability moves, lead times move, and neither Min/Max nor Period will tell you the assumption underneath it has expired. The engine will keep executing your old policy perfectly.

Where we would draw the line

We would not set Decoupling point on any item where nobody can name which of Microsoft's six criteria it satisfies. We would not put a population onto Priority without telling the planners their action messages will stop arriving for those items. And we would not run a coverage-code review as a one-off spreadsheet, because that is precisely how the current values got there.

Dynamics 365 manages the replenishment once the code is set. Choosing the code per item, and re-choosing it as demand and lead times move, is the optimization it leaves to you — and it is what Demand & Inventory Optimizer does: it scores every item on live demand variability, value and lead-time behaviour, and writes the coverage policy 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/

Export your item coverage records and count how many distinct coverage codes are actually in use. If the answer is one, book a fifteen-minute call and we will walk the segmentation with you on your own catalogue, live — no deck. https://cognilium.ai

Requirement, Period, Min/Max or Decoupling point — which coverage code for which item?