¿Listo para implementarlo en tu Odoo?
Agenda una demo o habla con un consultor y resuelve tus dudas antes de comprar. Instalación, configuración y soporte incluidos.
Demand Intelligence: Forecasting & Replenishment
Odoo tells you what you have. This app tells you what you will need, when to order it and why — and then turns it into a native purchase order. Statistical forecasting with automatic model selection, safety stock sized on the real forecast error, lead times measured from your own receipts, and a plain-language explanation behind every number.
What you get
Odoo's native replenishment asks you to type a minimum and a maximum per product, and then trusts you got them right. This app computes them: it reads your own stock moves, learns the demand pattern of every product-warehouse pair, chooses a forecasting model by competition, sizes the buffer from the error that model actually made, and tells you what to order, how much, and on which day.
And it tells you why. Every suggestion carries the steps of its own calculation written out in sentences — the coverage you asked for, the service level it turns into, the vendor minimum that pushed the quantity up, the packaging multiple that rounded it. There is no black box to take on faith.
When it cannot forecast something, it says so instead of inventing a number, and it tells you what is missing: no history, no vendor, no lead time, no cost. That census is the first screen you should look at.
Key features
14 models, chosen by competition
Naive, seasonal naive, drift, moving average, simple exponential smoothing, damped Holt, additive and multiplicative Holt-Winters, trend with seasonality, Croston, Croston-SBA, TSB, autoregressive AR(p) and zero. Every candidate is backtested with rolling origins and the one that errs least wins — together with the evidence of why it won.
Rolling-origin backtesting Parsimony rule Auditable fit
Intermittent demand, handled properly
Spare parts and slow movers do not behave like fast movers, and a moving average over a series of zeros is useless. Demand is classified with the Syntetos-Boylan ADI/CV² quadrant and routed to the right family: Croston, SBA or TSB for the intermittent ones.
Smooth · Erratic · Intermittent · Lumpy
Safety stock from the error, not from the demand
The buffer protects you against what you failed to foresee, not against the seasonality the model already captures. It is sized on the standard deviation of the backtesting residuals, combined with the lead time variability through King's formula. You set a target fill rate — the indicator the business measures — and the app shows you the cycle service level and the z factor it turns into.
σ of the forecast error King's formula Fill rate → z
Lead time measured, not promised
The vendor's declared delay is what they promise. The app also measures what they deliver, from your own closed receipts, per product and vendor — and uses that. A buffer sized on a promise is a buffer sized wrong, and the dashboard puts both figures side by side so you can see the gap.
Promised vs delivered Lead time σ
Replenishment you can act on
Every suggestion carries the order date, the expected arrival, the quantity in the vendor's purchase unit with the minimum, the packaging multiple and the maximum already applied, the vendor, and a 1-10 priority decile. One click turns the selected ones into native RFQs — grouped by vendor, company and warehouse, because a purchase order cannot receive in two warehouses at once.
MOQ · multiple · maximum Native purchase.order Priority deciles
Move it before you buy it
When the same item is in excess in one warehouse and short in another of the same company, the app proposes the transfer instead of a purchase, and tells you what that saves: the spend avoided and the sales at risk it rescues. Accepting one creates a real internal transfer. The surplus of a source is a budget that empties out — it is never promised twice.
Real stock.picking Never across companies
Every decision explained, in sentences
Not a log, not a formula dump: prose. «To have it by 6 Sept, and with a 14 days lead time, the best order date is 9 Aug.» «The vendor does not sell less than 5,000, so the quantity goes up to 5,000 — the order covers 9.49× what is forecast. Decide whether you over-buy from this vendor or look for another one.» The steps come from the engine with a stable key and their figures; the wording is a catalogue of 93 sentences you can translate.
And the pairs that get no suggestion are explained too — that is the part everyone else leaves out. Print it to PDF or post it to the chatter of the purchase order.
Data quality comes first
Before promising you any result, the app takes a census of what stops it from planning: pairs with no demand history, history too short, no vendor, a vendor with no lead time, no cost, no sales price, negative net demand, negative stock, archived products that still hold stock. Each issue is graded — blocks planning, degrades the result, or merely informational — and points at the exact product and warehouse.
Telling a customer how many of their products cannot be planned, and why, is worth more than any forecast shown on top of broken data.
Where it lives
There is good demand planning software on the market. Almost all of it is a platform of its own: it pulls your sales and stock out of Odoo every day, plans on its own servers, and pushes suggestions back. That works, and it costs a subscription, a connector and an account — and the screen where the buyer decides is no longer the screen where the buyer works.
The competitor column describes each vendor's own published Odoo integration. The Odoo column is verified against the 19.0 source: no Holt-Winters, Croston or ARIMA anywhere in the addons, no ABC/XYZ, no safety stock, and the minimum quantity of a reordering rule is a required field with no computation behind it. No third-party prices are quoted, because none of them publish one.
How it works
1 · Generate the pairs
One click creates the product × warehouse universe. It is idempotent: run it as often as you like.
2 · Rebuild the history
It reads your existing stock moves, aggregates them into weekly buckets, corrects demand lost to stockouts and flags outliers.
3 · Run the forecast
Every model competes on every pair. The winner is kept with its parameters and its backtesting metrics.
4 · Recompute the inventory
Safety stock, reorder point, order-up-to level, daily stock projection, ABC · XYZ classes and the health status of every pair.
5 · Decide
Review the ranked suggestions and the proposed transfers, read the reasoning, and turn what you accept into real documents.
Or let it run alone
Two scheduled actions do steps 2 to 5 nightly. They ship disabled: you turn them on once you have seen your own data.
Screenshots
Real screens of the module running on Odoo 19, over a catalogue of 879 product-warehouse pairs with three years of history.
The app at a glance
What was sold against what will be needed, and where every pair stands.
Six headline figures and the demand curve: 26 weeks sold against 26 forecast, with the engine's own confidence band. It goes in money because a catalogue mixes units of measure and quantities cannot be added up.
Inventory value, excess over what is needed, dead stock, tied-up capital, expected loss from stockouts, and how many pairs actually have a forecast you can trust.
Tied-up capital by product category — excess and dead stock kept apart, because you fix them in different ways — and the health of the whole catalogue in one ring.
Every pair with its ABC and XYZ class, its computed safety stock and reorder point, its stockout date and the money at risk. Filter by state from the side panel.
One pair, two curves: what was sold against what is forecast with the model's own band, and how the stock will evolve — with the reorder point, the buffer, the incoming receipts and the day it runs out.
Ranked by decile: 10 is the most urgent of today's batch. Each line carries the order date, the expected arrival, the quantity in the vendor's own purchase unit and the resulting coverage.
The reasoning behind the number, step by step and in plain language — including the steps that changed the figure the statistics had produced.
Move it before you buy it: what to move, from where to where, the spend avoided and the sales at risk rescued. Accepting one creates a real internal transfer.
What stops the app from planning, graded by severity and pointing at the exact product and warehouse.
Requirements and good to know
Dependencies
Odoo 19.0 with Inventory
(stock) and Purchase (purchase_stock).
Nothing else. It runs on Community and on Enterprise.
Zero external dependencies
No numpy, no scipy, no pandas, no external service. The whole engine is written in the Python standard library, so installing the app never means intervening on the server.
GRUPO MI ERP SAS — José Luis Vizcaya López