Choosing a Reordering Policy in Business Central

Reading Time: 11 minutes

This is the one that ties the other three together. Over the last few weeks I wrote about Safety Stock (how much buffer to hold), EOQ (how much to order), and the Reorder Point (when to order). Three numbers, three free extensions, each one writing a defensible value into a standard Business Central field. This post answers the question those three quietly leave open: once you have the numbers, which reordering policy actually reads them?

Because that is the part that trips people up. A perfect reorder point does nothing on an item set to Lot-for-Lot, because Lot-for-Lot never looks at it. A carefully calculated EOQ does nothing on an item set to Maximum Qty., because that policy orders up to a ceiling instead of a fixed lot. The numbers are only as good as the policy that consumes them, and the policy is a separate decision that most setups never make on purpose. They inherit whatever was on the item template at go-live and leave it there.

So here is the whole picture in one place: what each policy does, which of the three numbers it uses, how to choose between them from the item’s own demand, and three worked examples on the same data. A purchased product, a make-to-stock finished good, and a make-to-order machine with stocked components underneath it.

Get the Code

github.com/GmsoftLtd/bc-replenishment-policy

Free. MIT licensed. Object range 50400 to 50499, so it sits alongside bc-safety-stock (50100 to 50199), bc-eoq-calculator (50200 to 50299), and bc-reorder-point (50300 to 50399) with no conflict. Runtime 14.0, BC v27+. It reads the three numbers off the item and recommends the policy. It does not need the other three apps installed.

The Four Policies, and the Numbers Each One Reads

Business Central’s Reordering Policy field has four settings that matter. The trick to choosing between them is to know exactly which of your three numbers each one actually uses on a planning run. Here it is on one grid.

Reordering Policy	What the engine does	Safety Stock	Reorder Point	EOQ (Reorder Qty.)	Maximum Inventory
Fixed Reorder Qty.	At the reorder point, order a fixed quantity	yes	yes	yes	no
Maximum Qty.	At the reorder point, order up to a maximum	yes	yes	no	yes
Lot-for-Lot	Order exactly what each demand needs, no standing stock	optional	no	no	no
Order	One supply per demand, pegged together (make-to-order)	no	no	no	no

Read down the columns and the design tells you how to choose.

The reorder point is read by exactly two policies, Fixed Reorder Qty. and Maximum Qty. Those are the keep-stock-on-the-shelf-and-defend-a-trigger policies. If you stock the item and replenish it to a level, you want one of these two.

The EOQ is the order size for Fixed Reorder Qty. only. For Maximum Qty. the order size is whatever it takes to reach the ceiling, so the engine reads Maximum Inventory instead and ignores the EOQ field. That is the single most common mismatch I see: an EOQ lovingly calculated, sitting on a Maximum Qty. item that never reads it.

Lot-for-Lot holds no standing stock. There is no shelf to draw down, so there is no reorder point to defend and no fixed lot to order. It plans against actual demand in each bucket. Safety stock can still apply as a small buffer if you want one, but the point of the policy is to order to demand and carry nothing between.

Order pegs supply to demand one to one. None of the three stock numbers apply, by design. This is make-to-order, and I wrote about why a reorder point is meaningless here in the last post.

So the policy choice is really one question asked in three steps.

1. Do you stock this item, or make and buy it to order? That separates Order from the other three.
2. If you stock it, is demand frequent enough to defend a reorder point, or so infrequent that holding a buffer between sales is dead cash? That separates Fixed Reorder Qty. and Maximum Qty. from Lot-for-Lot.
3. If you defend a reorder point, do you need to cap inventory? That separates Maximum Qty. (capped) from Fixed Reorder Qty. (not capped).

Read the Demand, Do Not Guess It

Frequent and infrequent should not be a gut call. The item’s own posted sales tell you, through two numbers you can compute from Item Ledger Entries.

The first is the Average Demand Interval, the ADI. It is the mean number of calendar days between days that actually had a sale. An ADI of 1 means it sells every day. An ADI of 30 means roughly once a month. The second is the squared coefficient of variation of the demand size, the CV squared, which measures how erratic the quantity is when a sale does happen.

Put those two against the standard thresholds (ADI of 1.32, CV squared of 0.49) and you get the classic Syntetos-Boylan-Croston pattern grid.

                  CV2 < 0.49 (steady size)   CV2 >= 0.49 (erratic size)
ADI <  1.32       Smooth                     Erratic        -> frequent, defend a reorder point
ADI >= 1.32       Intermittent               Lumpy          -> infrequent, order to demand

Frequent demand, the Smooth and Erratic boxes, gets a reorder-point policy. Infrequent demand, the Intermittent and Lumpy boxes, gets Lot-for-Lot, because a reorder point would have you holding stock for weeks at a time between sales. That gives a clean decision tree, and it is exactly the tree the extension walks for you.

Is the item made or bought to order (Order policy, or Make-to-Order)?
 Yes -> ORDER. Supply pegs to demand. The three numbers do not apply.
 No  -> Classify demand from posted sales:
        Infrequent (ADI >= 1.32)  -> LOT-FOR-LOT
        Frequent  (ADI < 1.32)   -> Any reason to cap inventory (shelf life, or a max set)?
                                     Yes -> MAXIMUM QTY.
                                     No  -> FIXED REORDER QTY.

Everything below is that tree, applied to three items.

Worked Example 1: A Purchased Product

Item 1100, a Brake Pad Set. You buy it from a vendor and sell it off the shelf, steadily, most working days. The three calculators have already run. Cost inputs are a unit cost of 20, an ordering cost of 50, and a holding rate of 25 percent a year.

Input	Value	Where it comes from
Average daily demand	8 a day	sales, last 365 days
Lead time	14 days	purchase receipt history
Safety stock	60	bc-safety-stock, 95 percent service
Annual demand	2,920	8 times 365
Holding cost per unit per year	5	20 times 25 percent

Reorder Point is (8 times 14) plus 60, which is 112 plus 60, which is 172. EOQ is the square root of (2 times 2,920 times 50) divided by 5, which is the square root of 58,400, about 242.

It sells most days in steady quantities, so the ADI is about 1.05 and the CV squared is low, around 0.2. That is Smooth. Frequent demand, no shelf life, no reason to cap. This is the textbook home of Fixed Reorder Qty.

Item field	Value
Reordering Policy	Fixed Reorder Qty.
Reorder Point	172
Reorder Quantity	242
Safety Stock Quantity	60

On a planning run, when projected inventory falls to 172, BC suggests a purchase of 242. The reorder point covers the fourteen days of selling you will do while the order is in transit, plus the buffer. The EOQ is the cheapest quantity to bring in. All three numbers working together, each sitting in the field its policy reads. This is the bread and butter, and most of your purchased catalogue lands here.

Worked Example 2: A Make-to-Stock Finished Good

Item 2200, Fresh Pasta 500g. You manufacture it to stock and ship it from inventory, but it carries a 30-day shelf life. Demand is high and steady.

Input	Value	Where it comes from
Average daily demand	50 a day	sales, last 365 days
Manufacturing lead time	5 days	Lead Time Calculation, set to 5D
Safety stock	120	bc-safety-stock
Shelf life	30 days	Item Expiration Calculation, set to 30D

Reorder Point is (50 times 5) plus 120, which is 250 plus 120, which is 370.

It sells every day in steady quantities, so this is Smooth, same as the brake pads so far. Frequent demand. By the brake-pad logic you would reach for Fixed Reorder Qty. But there is a shelf life, and that changes the order-size decision. If you ordered a big fixed EOQ every time, you would build a tall standing stock that risks expiring before it sells. You want to refill up to a sensible ceiling and no further. That is Maximum Qty.

Set a maximum that holds at most a few days of cover above the reorder point, comfortably inside the 30-day shelf life. Say a Maximum Inventory of 700, roughly six to seven days of demand at the top. When stock crosses 370, BC orders up to 700, a variable quantity, never a fixed lot, never overstocking a perishable.

Item field	Value
Reordering Policy	Maximum Qty.
Reorder Point	370
Maximum Inventory	700
Safety Stock Quantity	120

Notice what changed and what did not. The demand-during-lead-time maths feeding the reorder point is the same. The safety stock is the same. But the shelf life flipped the order-size decision from a fixed economic lot to a capped refill, and with it the policy and the field the engine reads. The EOQ field is no longer in play. The Maximum Inventory is. A shelf life, scarce warehouse space, or a plain do-not-tie-up-cash-in-this rule is usually what turns a Fixed Reorder Qty. item into a Maximum Qty. one. Same trigger, capped fill.

Worked Example 3: A Make-to-Order Machine With Stocked Components

Item 3000, an MX-200 Packaging Machine. You build it only when a customer orders one. You never put a finished machine on the shelf. This is the case most reordering-policy advice gets wrong, because the right answer is different policies at different levels of the same bill of materials.

The machine itself is make-to-order. Manufacturing Policy is Make-to-Order, Reordering Policy is Order. Each sales order for an MX-200 creates one production order pegged to it. There is no stock level to defend.

Item field	Value
Reordering Policy	Order
Reorder Point	not used
Safety Stock Quantity	not used
Reorder Quantity	not used

Safety stock, reorder point, and EOQ do not apply to the machine. Setting a reorder point on a make-to-order finished good is the classic mistake. You would be defending a shelf level for something you never put on a shelf.

But the components underneath are where the three numbers come back, and they do not all answer the same way. Take two of them.

Component 3100, an M8 Bolt. Cheap, used across many products, consumed constantly. High frequent demand, trivial unit cost, no shelf life. The pattern is Smooth, and there is no reason to cap, so it is Fixed Reorder Qty. The reorder point defends the purchase lead time, and the EOQ is a big cheap lot because ordering bolts in small batches is wasteful.

Item field	Value
Reordering Policy	Fixed Reorder Qty.
Reorder Point	800
Reorder Quantity	5,000
Safety Stock Quantity	300

Component 3200, an MX Control Board. Expensive, used only when an MX-200 is actually built, which happens a handful of times a year. If a machine is built about eight times a year, demand for the board occurs on roughly eight days out of 365, so its ADI is about 46, far above the 1.32 threshold. That is Lumpy. Holding a reorder-point buffer of a 900 board between builds is dead cash on the shelf. The answer is Lot-for-Lot. Order exactly what each machine build needs, when the production order for the machine creates the demand.

Item field	Value
Reordering Policy	Lot-for-Lot
Reorder Point	not used
Safety Stock Quantity	0 (or a small buffer only if a stockout would idle the line)
Order Multiple / Min. Order Qty.	as needed

So one make-to-order machine fans out into three different policies. Order for the machine, Fixed Reorder Qty. for the commodity bolt, Lot-for-Lot for the expensive lumpy board. Each one is the demand pattern at that level of the BOM talking. The question is never whether the company is make-to-order or make-to-stock. It is whether this item is, asked one item at a time, all the way down the structure, and the policy that follows from it.

One honest caveat on the components. The free extension classifies demand from posted Sales entries. A component like the control board is consumed in production, not sold, so its real pattern lives in Consumption entries, which the current build does not read yet. It is on the roadmap. For now, reason about a component the same way by hand: how often is it consumed, and how erratic is the quantity when it is. The decision tree is identical. Only the source of the history differs.

Putting It on One Screen

Walking ADI, CV squared, three numbers, and a decision tree per item is exactly the kind of thing a small extension should do for you. The free bc-replenishment-policy advisor adds an Item Card action that does four things.

It reads the three numbers already on the item, the Safety Stock Quantity, the Reorder Point, and the Reorder Quantity, and shows them together so you see the whole replenishment picture at once. It classifies the item’s demand from posted sales and reports the ADI, the CV squared, and the pattern. It recommends Fixed Reorder Qty., Maximum Qty., Lot-for-Lot, or Order, with the reason in plain English. And, only if you switch on Auto-Update, it writes the recommended Reordering Policy back to the item. That switch is off by default, because changing a reordering policy is consequential and the tool should recommend, not impose, until you decide to trust it.

Object	Type	ID
Repl. Policy Advisor Setup	Table + Page	50400
Repl. Policy Advice Log	Table + Page	50401
Repl. Policy Recommendation	Enum	50400
Replenishment Policy Advisor	Codeunit	50400
Repl. Policy Advisor Job	Codeunit	50401
Item Card Page Extension	PageExt	50400
Item List Page Extension	PageExt	50401
Repl. Policy Advisor Permission Set	Permission Set	50400

There is a bulk action on the Item List for a whole category at once, and a Job Queue codeunit (object 50401) that takes a Parameter String like FILTER=Item Category Code:FERT so you can re-advise on a schedule. Every run is logged with the three numbers, the demand statistics, the pattern, the current policy, the recommended policy, and the reason, so the recommendation is auditable rather than a black box.

How This Completes the Set

Four numbers, four jobs, one coherent planning setup.

• Safety Stock answers how much buffer to hold against variability. It goes into Item Safety Stock Quantity. That is bc-safety-stock.
• EOQ answers how much to order. It goes into Item Reorder Quantity. That is bc-eoq-calculator.
• Reorder Point answers when to order. It goes into Item Reorder Point. That is bc-reorder-point.
• Reordering Policy answers which engine reads all of the above. That is this extension, bc-replenishment-policy.

The maths told you what the numbers are. This tells you which policy reads them. Populate the three numbers on a make-to-stock item, let the advisor pick the policy from the demand pattern, and the Planning Worksheet has everything it needs and nothing it will ignore. Every field on the card can be explained to an auditor or a sceptical operations manager, because every one of them came from the item’s own history and a stated rule, not from a guess made at go-live.

Practical Tips

Fix the inputs before the policy. The advisor reads the three numbers as they stand. If the safety stock or the reorder point is stale, the policy may be right but the levels will be wrong. Run the three calculators first, then advise the policy.

Re-advise on a cadence, not once. Demand patterns drift. An item that sold every day last year can go intermittent this year, and its right policy changes with it. Schedule the bulk advice quarterly for fast movers and once a year for the long tail.

Treat the thresholds as yours. The 1.32 and 0.49 defaults are the textbook values, and they are sensible, but they live on the setup card. If your business treats anything selling less than weekly as order-to-demand, raise the ADI threshold and the classification follows.

Leave Auto-Update off until you trust it. Run it in advisory mode first, read the log across a real category, and see whether you agree with the calls. Turn on the write-back only once the recommendations match your judgement. Make-to-order items are never auto-flipped regardless.

When This Is the Wrong Tool

New items below the minimum observations have no pattern yet. The advisor returns Insufficient Data rather than guess. Use a category default until the sales accumulate.

Strategic or regulatory stocking is not a demand decision. If a policy is driven by a supply contract, a compliance floor, or a single-source risk, set it by hand. The pattern grid does not know about any of that.

Items mid-transition mislead. Something being phased in or phased out has a recent history that does not describe its steady state. Advise it after it settles, or set it manually until it does.

Install It

Developer or sandbox:

git clone https://github.com/GmsoftLtd/bc-replenishment-policy

Open in VS Code with the AL extension, confirm the object range 50400 to 50499 is free, and press F5. Open Search, go to Replenishment Policy Advisor Setup, and check the history window and the two thresholds. Then open a stocked Item Card and click Advise Replenishment Policy to see the three numbers and the recommendation side by side.

Production tenant:

1. Download a release .app from the Releases page, or build from source.
2. Upload via Extension Management.
3. Leave Auto-Update off, run the bulk advice against a real category, and read the log.
4. Turn on Auto-Update only when you are happy to let it write the policy.

With Auto-Update off it changes nothing on your items. It only reads and logs. Safe to trial on a live tenant.

Resources

• Code: github.com/GmsoftLtd/bc-replenishment-policy
• License: MIT
• The set: bc-safety-stock · bc-eoq-calculator · bc-reorder-point
• Microsoft Learn: Design details: Reordering policies and Planning parameters
• My consultancy: GMSOFT Limited
• PRs welcome for demand classification from consumption, per-location SKU policies, and seasonal demand profiles

If your tenant has EOQ values on Maximum Qty. items, reorder points on make-to-order finished goods, or expensive parts sitting on a fixed-lot policy they sell twice a year, install this in a sandbox and run the bulk advice against a real category. The log will tell you, item by item, which policy each one should be on and why. That list is usually the most honest audit of a planning setup you will get in ten minutes.

---

Questions, an edge case, or a planning behaviour you cannot explain? Get in touch.