The reorder point is a number somebody typed once, and nothing since has argued with it
The rule works. It fires when the position drops, it raises the purchase or the build, it does not forget. What it fires on is a minimum and a maximum that a person chose, during implementation, from a season that is now three seasons ago, in a meeting nobody minuted. Since then the product has moved, the lead time has moved, and the number has not. This is not a system failure and it will not appear as one: the rule keeps doing exactly what it was told, which is why the stockout arrives without a warning and the excess arrives without an explanation. The planning is not missing. It happened once, and it has been assumed ever since.
What you get with demand planning
A reordering rule against a product, a location and a warehouse, holding a minimum, a maximum and an order multiple, so the quantity is rounded up to the supplier's pack size rather than to whatever the arithmetic produced. The quantity to order is computed from the current position: when it falls short of the minimum, the rule orders the difference up to the maximum, then rounds to the next whole multiple. A minimum above the maximum is rejected outright, and a negative multiple cannot be stored.
Rules can be set to fire automatically or only when someone asks, snoozed until a date rather than deleted, and each one raises a flag when replenishing it would push the position past its own maximum. A visibility horizon widens the window the rule reads, so demand falling a chosen number of days out is pulled into today's requirement instead of arriving as a surprise next week.
The date the rule works back from is built rather than assumed. Lead time is the sum of the delays on the supply rules along the path, plus the vendor's own delay from the supplier line, plus the visibility horizon, and the system returns the breakdown, so you can read which hop contributed which days instead of arguing about a single opaque number.
What the rule does when it fires is set by the route it runs through. A supply rule takes one of five actions, two of which are the ones that matter here: buy, or manufacture. A rule's supply method can take from stock, always trigger the upstream rule, or, the useful one, take from stock and trigger only for the shortfall. Rules are held per warehouse and per location, and a warehouse can name the warehouses that resupply it, so replenishing one site out of another is a route rather than a habit.
Underneath all of it, the position itself is a set of computed quantities on the product: on hand, free to use, incoming, outgoing, and the projection of the three. All five are searchable, not merely readable, so "everything whose projected position goes negative inside the lead time" is a filter rather than an export.
And the thing this page will not pretend. None of that is a demand forecast. The minimum and the maximum are values a person sets; nothing on the rule reads sales history, a trend or a season. The field the interface labels Forecast is projected on-hand, available, plus what is already coming, less what is already going, which is arithmetic over movements that already exist, not a prediction about movements that do not. It is a genuinely useful number and it is not the number a planner means by that word.
Where demand planning comes from
The rule is in the product. Reordering rules, routes, supply methods and the position fields are all Odoo Community itself, no tier to reach and no per-user fee for any of it, on the deployment you own. NetSuite tiers the same reordering machinery inside its per-seat subscription; in Odoo it is already included, and that difference is the product.
The demand model is a different answer, and it is the one worth being exact about. The ledger holds the signals, the position, the movements, the lead times, the vendor's own delay. The judgement about how much of next quarter to believe is not among them. We looked for it: no field on a reordering rule reads sales history or seasonality, and the only models carrying the word forecast project movements that already exist. So what we install does not forecast demand, and we would rather you know that on the first call than in month three.
What we have not done is establish whether some module elsewhere in the ecosystem supplies one, because nobody has looked, and this is where a lot of ERP pages quietly pick a side. We are not going to tell you it is impossible, and we are not going to imply an install closes it. If planning judgement is the thing you are actually shopping for, say so on the call and we will tell you honestly what we would have to build.
What is a reorder point, and how is the order quantity decided?
A reorder point is the stock position at which a system raises a replenishment a purchase from a supplier, a transfer from another warehouse, or a build. It is usually held as a rule against one product at one location, carrying a minimum, a maximum, and often an order multiple. When the position falls below the minimum, the rule orders enough to bring it back up to the maximum, and then rounds that quantity up to the next whole multiple so the order matches the supplier's pack size rather than the arithmetic. Two things are worth separating when evaluating any system that does this. The mechanism, does the rule fire reliably, can it be paused, does it respect the pack size, can it raise a build as easily as a purchase, is engineering, and mature systems all do it. Where the minimum came from is not engineering. It is a judgement, and the system is only as good as the last time somebody made it.
Is a reorder point the same thing as a demand forecast?
No, and conflating the two is the most common way an inventory system is oversold. A reorder point is a threshold: it reacts to the position the system currently holds and triggers when that position crosses a line. A demand forecast is a prediction: it estimates future consumption from history, seasonality or a statistical model, and produces a number for a period that has not happened. A system can execute reorder points perfectly and contain no forecasting at all, which is the normal case. The practical test is to ask what the minimum quantity is derived from. If the answer is that somebody typed it, the system is reacting, however sophisticated the surrounding machinery; if the answer names a history window and a model, it is forecasting, and then the question becomes how the model is validated and who is accountable when it is wrong.
What does "forecasted quantity" mean in inventory software?
In most inventory systems it means projected on-hand: the quantity currently available, plus quantities on confirmed incoming movements, less quantities on confirmed outgoing movements, evaluated at some horizon. It is arithmetic over transactions that already exist, purchase orders already raised, deliveries already promised, and it is genuinely useful, because it answers "given everything already committed, where will this product be on Thursday". It is not a forecast of demand. It contains nothing about orders that have not been placed, and it does not change if next month is your busiest month of the year. This distinction matters more than it sounds, because the word on the screen is the same word a planner uses for something else entirely, and a shortlist can get quite far on the assumption that the label means what the planner meant.
What should you ask a vendor that markets demand-based replenishment?
Ask which field the demand model reads, and ask to see it change a reorder point. Vendors describe this capability in strong terms, NetSuite's own inventory management page states that "using demand-based replenishment, NetSuite Inventory Management uses historical and seasonal sales data to dynamically manage item reorder points and maintain preferred stock levels", and the claim is checkable rather than a matter of opinion. There should be a history window somewhere, a seasonality setting somewhere, and a reorder point that has a computed value rather than a typed one. The reason to check is not that vendors are dishonest about it; it is that "demand-based" is applied both to systems that fit a model to sales history and to systems that read the current stock position very well, and only the first one changes what happens when your season shifts. A straight answer either way is workable. An unexamined assumption is what puts the plan back in a spreadsheet.