Master Planning in D365: Coverage Groups and the Core Planning Parameters
For two weeks I have been deep in the warehouse: wave templates, cycle counting, replenishment, inbound flows, and last time the mobile device menu in the operator's hand. I promised at the end of that article to step back from the floor and into planning, because everything the warehouse moves has to be made or bought first, and the thing that decides what to make and buy, and when, is master planning. This is the first of a few articles on it, and I want to start where the behaviour actually lives: the mobile device menu was the doorway to warehouse work; coverage groups are the doorway to planning. Get them right and the plan is sensible. Get them wrong and you spend your days explaining strange planned orders.
WHAT MASTER PLANNING IS ACTUALLY DOING
Strip master planning down to its core and it is a comparison. On one side it gathers demand: sales order lines, the demand forecast, transfer and production requirements, and any safety stock you have asked it to hold. On the other side it gathers supply that already exists: on-hand inventory plus open purchase, production, and transfer orders. It nets the two together, item by item and warehouse by warehouse, across the timeline, and wherever demand outruns available supply it raises a planned order to cover the gap. Those planned orders are suggestions, not commitments, until somebody firms them into real purchase, production, or transfer orders. That loop is the whole engine. What makes two companies running the same engine get completely different plans is the configuration that decides how the gap gets covered, and that configuration is mostly the coverage group.
COVERAGE GROUPS: WHERE THE BEHAVIOUR LIVES
A coverage group is a reusable bundle of planning settings that you attach to items so the engine knows how to treat them. You do not configure planning item by item from scratch; you build a handful of coverage groups that describe the patterns you have, then point each item at the group that fits. A fast-moving stocked component, an expensive made-to-order assembly, and a cheap consumable each want different treatment, and a coverage group is how you express that difference once and reuse it. The single most important field on the group is the coverage code, because it decides how individual requirements get grouped into planned orders and therefore how many orders you get and how much buffer they carry.
THE FOUR COVERAGE CODES
There are four coverage codes, and choosing among them is the first real decision you make for any item.
• Requirement. The engine raises one planned order for each demand line, sized exactly to that line. This is lot-for-lot planning: the tightest possible inventory and the most orders. It suits high-value or made-to-order items where you never want stock sitting idle.
• Period. The engine groups all demand that falls inside a defined period (for example a week) into a single planned order. You get fewer, larger orders and a little more buffer, which suits items where placing an order has real cost or where the supplier prefers consolidated quantities.
• Min/Max. The engine tops inventory back up to a maximum whenever projected stock drops to a minimum. This is classic reorder-point behaviour and is ideal for cheap, steadily consumed items where you simply want to keep a band of stock on the shelf.
• Manual. The engine raises no planned orders at all for the item. You plan and order it by hand. Useful for items you deliberately keep out of automatic planning.
THE TIME FENCES THAT MATTER
After the coverage code, the next thing a coverage group controls is how far into the future planning is allowed to look and act. These are the time fences, and they are where I see the most confusion, so it is worth being precise about what each one does.
• Coverage time fence. How far ahead the engine plans coverage for the item at all. Demand beyond this horizon is ignored for now. Too short and you fail to react to known future demand; too long and you create planned orders for demand that is still soft.
• Negative days. How long the engine will let existing supply arrive late before it gives up and raises a new planned order instead of pegging to that late receipt. Set this to roughly your acceptable wait. Too low and you get duplicate orders; too high and the plan quietly tolerates lateness it should flag.
• Positive days. How far forward the engine will use existing on-hand and receipts to cover future demand before it suggests something new. This is what stops planning from ordering more when you already have stock that will comfortably cover the next stretch.
• Freeze time fence. A near-term window inside which the engine will not create, change, or reschedule planned orders. This protects the immediate horizon that the floor and buyers are already executing, so planning does not keep shuffling next-shift work.
• Action and futures message time fences. These switch on the advisory messages: action messages suggest moving or cancelling existing orders, and futures messages warn that a receipt will arrive later than the demand needs it. They do not change orders by themselves; they tell a planner where to look.
ITEM COVERAGE: THE OVERRIDE WHEN THE GROUP IS NOT ENOUGH
A coverage group is a sensible default for a family of items, but real catalogues always have exceptions, and that is what item coverage is for. Item coverage records sit at the item and warehouse level (and can go finer, down to a specific dimension such as a configuration or a site) and let you override individual settings without inventing a brand new coverage group for one part. The most common use is to set a minimum quantity, which is how safety stock is expressed for a single item-warehouse, and to override the coverage code or lead time where one location behaves differently from the rest. My rule of thumb: use coverage groups for the patterns that repeat, and item coverage only for the genuine one-offs. If you find yourself creating dozens of item coverage overrides that all say the same thing, that is a signal you are missing a coverage group, not that you need more overrides.
A FEW SETTINGS THAT QUIETLY SHAPE THE PLAN
Two more things on the coverage group are worth naming because they change results in ways people do not expect. First, whether the group includes the forecast in the demand it plans against, and how forecast consumption reduces that forecast as real sales orders arrive; if this is set wrong you either double-count demand or ignore it. Second, the quantity modifiers that live with the item (minimum order quantity, multiples, and maximum) which the engine respects when it sizes a planned order. A coverage code of Requirement still rounds up to your order multiple, so a tiny demand line can produce a larger planned order than the line alone would suggest. None of this is exotic, but it explains most of the planned orders that look wrong at first glance.
WHAT GOES WRONG
• One coverage group for everything. A single global group forces fast consumables and expensive made-to-order parts into the same behaviour. Build a small set of groups that match your real item patterns.
• Coverage time fence too short. If the horizon is shorter than your lead time, the engine cannot react in time and buyers are always firefighting. Make sure the fence comfortably exceeds the longest lead time you need to cover.
• Negative days left at zero. With no tolerance, the engine raises a fresh planned order the moment a receipt looks even slightly late, and you drown in duplicates. Set negative days to a realistic acceptable delay.
• Safety stock buried in the wrong place. Putting a blanket minimum on the coverage group when only a few items need it ties up cash everywhere. Express safety stock through item coverage minimums where it actually belongs.
• Treating action and futures messages as noise. These messages are the plan telling you where reality and the schedule have drifted apart. Ignoring them is how late receipts and stranded orders pile up unseen.
TAKEAWAYS
Master planning is a simple engine wrapped around one comparison of demand and supply, and almost all of its personality comes from the coverage group attached to each item. Start with the coverage code, because it decides how requirements turn into orders: Requirement for tight, made-to-order items, Period to consolidate, Min/Max for steady consumables, Manual to opt out. Then set the time fences deliberately so the engine looks far enough ahead, tolerates a sensible amount of lateness, reuses the stock you already have, and leaves the frozen near term alone. Use item coverage for the genuine exceptions, especially safety stock minimums, and reserve coverage groups for the patterns that repeat. Do that and the plan stops surprising you, which means you spend your time acting on planned orders instead of explaining them.
Next time I will follow the planned orders forward: firming them into real purchase and production orders, and reading the action and futures messages that tell you what to reschedule before the warehouse ever feels it.
In this series: previous article The Warehouse Mobile Device Menu in D365 Advanced WMS: Menu Items and Work Classes
For two weeks I have been deep in the warehouse: wave templates, cycle counting, replenishment, inbound flows, and last time the mobile device menu in the operator's hand. I promised at the end of that article to step back from the floor and into planning, because everything the warehouse moves has to be made or bought first, and the thing that decides what to make and buy, and when, is master planning. This is the first of a few articles on it, and I want to start where the behaviour actually lives: the mobile device menu was the doorway to warehouse work; coverage groups are the doorway to planning. Get them right and the plan is sensible. Get them wrong and you spend your days explaining strange planned orders.
WHAT MASTER PLANNING IS ACTUALLY DOING
Strip master planning down to its core and it is a comparison. On one side it gathers demand: sales order lines, the demand forecast, transfer and production requirements, and any safety stock you have asked it to hold. On the other side it gathers supply that already exists: on-hand inventory plus open purchase, production, and transfer orders. It nets the two together, item by item and warehouse by warehouse, across the timeline, and wherever demand outruns available supply it raises a planned order to cover the gap. Those planned orders are suggestions, not commitments, until somebody firms them into real purchase, production, or transfer orders. That loop is the whole engine. What makes two companies running the same engine get completely different plans is the configuration that decides how the gap gets covered, and that configuration is mostly the coverage group.
COVERAGE GROUPS: WHERE THE BEHAVIOUR LIVES
A coverage group is a reusable bundle of planning settings that you attach to items so the engine knows how to treat them. You do not configure planning item by item from scratch; you build a handful of coverage groups that describe the patterns you have, then point each item at the group that fits. A fast-moving stocked component, an expensive made-to-order assembly, and a cheap consumable each want different treatment, and a coverage group is how you express that difference once and reuse it. The single most important field on the group is the coverage code, because it decides how individual requirements get grouped into planned orders and therefore how many orders you get and how much buffer they carry.
THE FOUR COVERAGE CODES
There are four coverage codes, and choosing among them is the first real decision you make for any item.
• Requirement. The engine raises one planned order for each demand line, sized exactly to that line. This is lot-for-lot planning: the tightest possible inventory and the most orders. It suits high-value or made-to-order items where you never want stock sitting idle.
• Period. The engine groups all demand that falls inside a defined period (for example a week) into a single planned order. You get fewer, larger orders and a little more buffer, which suits items where placing an order has real cost or where the supplier prefers consolidated quantities.
• Min/Max. The engine tops inventory back up to a maximum whenever projected stock drops to a minimum. This is classic reorder-point behaviour and is ideal for cheap, steadily consumed items where you simply want to keep a band of stock on the shelf.
• Manual. The engine raises no planned orders at all for the item. You plan and order it by hand. Useful for items you deliberately keep out of automatic planning.
THE TIME FENCES THAT MATTER
After the coverage code, the next thing a coverage group controls is how far into the future planning is allowed to look and act. These are the time fences, and they are where I see the most confusion, so it is worth being precise about what each one does.
• Coverage time fence. How far ahead the engine plans coverage for the item at all. Demand beyond this horizon is ignored for now. Too short and you fail to react to known future demand; too long and you create planned orders for demand that is still soft.
• Negative days. How long the engine will let existing supply arrive late before it gives up and raises a new planned order instead of pegging to that late receipt. Set this to roughly your acceptable wait. Too low and you get duplicate orders; too high and the plan quietly tolerates lateness it should flag.
• Positive days. How far forward the engine will use existing on-hand and receipts to cover future demand before it suggests something new. This is what stops planning from ordering more when you already have stock that will comfortably cover the next stretch.
• Freeze time fence. A near-term window inside which the engine will not create, change, or reschedule planned orders. This protects the immediate horizon that the floor and buyers are already executing, so planning does not keep shuffling next-shift work.
• Action and futures message time fences. These switch on the advisory messages: action messages suggest moving or cancelling existing orders, and futures messages warn that a receipt will arrive later than the demand needs it. They do not change orders by themselves; they tell a planner where to look.
ITEM COVERAGE: THE OVERRIDE WHEN THE GROUP IS NOT ENOUGH
A coverage group is a sensible default for a family of items, but real catalogues always have exceptions, and that is what item coverage is for. Item coverage records sit at the item and warehouse level (and can go finer, down to a specific dimension such as a configuration or a site) and let you override individual settings without inventing a brand new coverage group for one part. The most common use is to set a minimum quantity, which is how safety stock is expressed for a single item-warehouse, and to override the coverage code or lead time where one location behaves differently from the rest. My rule of thumb: use coverage groups for the patterns that repeat, and item coverage only for the genuine one-offs. If you find yourself creating dozens of item coverage overrides that all say the same thing, that is a signal you are missing a coverage group, not that you need more overrides.
A FEW SETTINGS THAT QUIETLY SHAPE THE PLAN
Two more things on the coverage group are worth naming because they change results in ways people do not expect. First, whether the group includes the forecast in the demand it plans against, and how forecast consumption reduces that forecast as real sales orders arrive; if this is set wrong you either double-count demand or ignore it. Second, the quantity modifiers that live with the item (minimum order quantity, multiples, and maximum) which the engine respects when it sizes a planned order. A coverage code of Requirement still rounds up to your order multiple, so a tiny demand line can produce a larger planned order than the line alone would suggest. None of this is exotic, but it explains most of the planned orders that look wrong at first glance.
WHAT GOES WRONG
• One coverage group for everything. A single global group forces fast consumables and expensive made-to-order parts into the same behaviour. Build a small set of groups that match your real item patterns.
• Coverage time fence too short. If the horizon is shorter than your lead time, the engine cannot react in time and buyers are always firefighting. Make sure the fence comfortably exceeds the longest lead time you need to cover.
• Negative days left at zero. With no tolerance, the engine raises a fresh planned order the moment a receipt looks even slightly late, and you drown in duplicates. Set negative days to a realistic acceptable delay.
• Safety stock buried in the wrong place. Putting a blanket minimum on the coverage group when only a few items need it ties up cash everywhere. Express safety stock through item coverage minimums where it actually belongs.
• Treating action and futures messages as noise. These messages are the plan telling you where reality and the schedule have drifted apart. Ignoring them is how late receipts and stranded orders pile up unseen.
TAKEAWAYS
Master planning is a simple engine wrapped around one comparison of demand and supply, and almost all of its personality comes from the coverage group attached to each item. Start with the coverage code, because it decides how requirements turn into orders: Requirement for tight, made-to-order items, Period to consolidate, Min/Max for steady consumables, Manual to opt out. Then set the time fences deliberately so the engine looks far enough ahead, tolerates a sensible amount of lateness, reuses the stock you already have, and leaves the frozen near term alone. Use item coverage for the genuine exceptions, especially safety stock minimums, and reserve coverage groups for the patterns that repeat. Do that and the plan stops surprising you, which means you spend your time acting on planned orders instead of explaining them.
Next time I will follow the planned orders forward: firming them into real purchase and production orders, and reading the action and futures messages that tell you what to reschedule before the warehouse ever feels it.
In this series: previous article The Warehouse Mobile Device Menu in D365 Advanced WMS: Menu Items and Work Classes
No replies yet. Be the first to respond!
