Suggested Min and Max Levels on Odoo 20 Reordering Rules

Every reordering rule in Odoo lives or dies on two numbers: the minimum quantity that triggers replenishment and the maximum quantity stock is replenished up to. Set them too low and you stock out while a purchase order is still in transit. Set them too high and cash sits on shelves. In earlier versions, those numbers came from a planner's spreadsheet, a buyer's gut feel, or a value typed in during implementation and never revisited. Odoo 20 changes the starting point: minimum and maximum stock levels for reordering rules are now suggested based on demand history, desired minimum days of coverage, and order frequency. This article explains how the underlying rules work, what the suggestion is built from, and how to adopt it without handing your warehouse over to an algorithm you have not checked.

First, how a reordering rule works

A reordering rule keeps forecasted stock above a threshold without exceeding an upper limit. Two definitions matter, and both are about forecasted quantity — on hand plus expected receipts, minus expected deliveries — not just what is physically on the shelf today:

Min Quantity is the minimum quantity that can be forecasted without the rule being triggered. When forecasted stock falls below this number, a replenishment order is created.
Max Quantity is the maximum quantity that stock is replenished up to.

The documentation's example is the cleanest illustration: with Min Quantity set to 5 and Max Quantity set to 25, if stock falls to four units, a purchase order is created for 21 units — enough to bring the level back up to the maximum. The route on the product decides what gets created: the Buy route generates a request for quotation (RFQ), while the Manufacture route generates a manufacturing order (MO). A Multiple Quantity can force ordering in fixed batches, which can push resulting stock slightly above the maximum.

Rules also have a trigger. With the Auto trigger (the default), an order is created when the scheduler runs and finds the forecast below the minimum, or when a confirmed sales order pushes the forecast below it; the scheduler runs once a day by default. With the Manual trigger, the product instead appears on the replenishment dashboard as a need, and a person reviews the forecast, lead times, and arrival dates before clicking Order. Either way, outcomes depend entirely on the min and max — the gap Odoo 20's suggestions aim at.

What Odoo 20 actually adds

The release notes state the change in one line, under Inventory: “Minimum and maximum stock levels for reordering rules are now suggested based on demand history, desired minimum days of coverage, and order frequency.”

Read that carefully: it describes a suggestion engine, not an autopilot. Odoo proposes values for the two fields you used to type in yourself; nothing in the release notes says the values apply themselves. The planner still owns the policy, but no longer has to derive every number from raw sales data by hand.

There is a second, related Inventory change worth knowing about if you work from the replenishment dashboard: the Order and Order to max buttons have been consolidated into a single Order button. When you reorder products in advance — selecting products without the To reorder filter — the order quantity is calculated as the maximum quantity minus the forecast quantity. The max you set (or accept as suggested) now directly drives advance orders too, not just threshold-triggered ones.

The three inputs, unpacked

1. Demand history

The suggestion starts from how the product has actually moved — a better foundation than a buyer's memory, which overweights the last stockout and the last overstock in opposite directions. But history is not neutral data: a one-off bulk order, a promotion, or a month where the product was out of stock and therefore could not sell all distort the picture. Demand history tells you what was sold, not what was demanded — a product that sat at zero for three weeks shows zero sales for those weeks, and a suggestion built naively on that window will aim too low.

2. Desired minimum days of coverage

This is the policy lever. Days of coverage translates demand into a floor: how many days of typical demand should the minimum level represent? A fast-moving staple with a short, reliable supply line might justify only a few days of coverage at the minimum; a component with a long or variable lead time, or one whose absence stops production, justifies more. Coverage is where service level lives — raising it buys insurance against stockouts, at the price of more stock on average.

3. Order frequency

How often you are willing to order shapes the maximum. If you order a product weekly, the maximum needs to cover roughly a week of demand beyond the minimum; if you order monthly to consolidate shipments or hit a supplier's freight terms, it must cover a month. Order frequency is the trade-off between ordering costs and holding costs, expressed as a rhythm: frequent small orders mean lower average stock but more RFQs, receipts, and invoices to process.

Put together, the logic is the classic one, now done for you as a starting point: the minimum reflects demand over your risk window (expressed as days of coverage), and the maximum reflects the minimum plus demand over your ordering cycle. The suggestion does the arithmetic; it does not know your supplier closes in August or that a big customer is about to churn.

A worked illustration

Consider a purchased consumable that has been selling about 10 units a day. Suppose you want a minimum of seven days of coverage and you order roughly every two weeks:

Suggested minimum: about 70 units — seven days of demand held as the floor.
Suggested maximum: about 210 units — the minimum plus roughly fourteen more days of demand, so a triggered replenishment covers you until the following order cycle.
If the forecast drops to 65, the rule triggers and replenishes toward 210 — ordering about 145 units, adjusted by any multiple quantity on the rule.

These numbers illustrate the reasoning rather than output from a specific database — your demand history, coverage target, and order rhythm will produce different values. The point is that you can audit a suggestion: if Odoo proposes a minimum of 70 for this product, you can see why, and if your real lead time means seven days of coverage is not enough buffer, you change the coverage input or override the value with your eyes open.

Adopting suggestions without breaking the warehouse

Start with your highest-volume products. They have the richest demand history, so their suggestions are the most credible — and errors there cost the most.
Compare, don't copy. Put the suggested min and max next to your current values. A large gap either way is a finding: either your old numbers were stale, or this product's history is misleading the suggestion. Find out which before changing anything.
Check the suggestion against lead time. Days of coverage at the minimum should comfortably span your supplier's real lead time plus receiving time. If it doesn't, raise the coverage rather than editing the quantity directly, so the logic stays intact.
Respect multiples and packagings. If a vendor sells in cases, orders round up past the maximum. Verify the multiple on the rule still reflects how the product is bought.
Run new values under the Manual trigger first. Let the products surface on the replenishment dashboard as needs for a few cycles. Reviewing proposed orders before they become RFQs is the cheapest possible test of whether the levels behave.
Revisit after the first cycles. Compare what the rules ordered against what you would have ordered, and tune the coverage days and order frequency — the inputs — rather than patching individual numbers.

When to distrust the suggestion

New products. With little or no demand history, there is nothing meaningful to suggest from. Set levels manually until a pattern exists.
Seasonal and promoted products. History that includes a peak season or a one-time promotion pulls suggestions toward that peak. If next quarter looks nothing like the history window, your judgment outranks the average.
Intermittent demand. Slow movers that sell in occasional lumps are poorly served by averages; a suggested maximum can strand cash in stock that turns twice a year.
Products on their way out. A suggestion engine does not know you are discontinuing a line. Lower levels manually, or use a 0/0/1-style approach for items you no longer want to hold.

None of this argues against using the feature — it argues for using it as described: as a suggestion. The old failure mode was numbers nobody had reviewed in two years; the new one would be numbers nobody reviewed at all. Odoo 20 removes the arithmetic excuse, turning demand history, coverage, and order frequency into a concrete proposal you can accept, adjust, or reject product by product. Teams that treat the first suggestion as a draft of their replenishment policy, then re-check the inputs as demand shifts, get the real benefit: fewer stockouts on the products that matter, and less cash sleeping on the shelves.