Plan inventory by recording the demand, lead-time and buffer assumptions behind each reorder decision. Specify what the software compares, who can change the inputs and how exceptions are reviewed. A configured minimum or expected arrival date should be explainable from evidence, rather than treated as an automatically optimal stock policy.
Which quantity does the reorder rule actually inspect?
Odoo’s reordering rules compare forecast stock with a configured minimum quantity. Odoo’s Max field specifies the quantity to which stock is replenished. Use the Odoo reordering-rule documentation to distinguish the documented calculation from the business decision about suitable inputs.
For one representative item, record the on-hand quantity, the forecast considered by the configured process and the proposed minimum and maximum. Ask which demand and incoming movements contribute to the forecast you are examining. Keep a reference to the actual supporting records.
Odoo’s reordering setup requires a Goods product with inventory tracking enabled. Include the item setup in the assessment. A planner should be able to identify the product, location and intended replenishment method rather than assume a rule applies because the item appears somewhere in the catalogue.
Use a hypothetical item called Test Filter for a controlled exercise. Choose synthetic movements that make the expected result easy to explain. The quantities are exercise inputs to agree, not published recommendations for another business or claims about local demand.
Which lead time belongs to which event?
Odoo defines vendor lead time as the time from purchase-order confirmation to product receipt. Odoo’s customer lead time runs from sales-order confirmation to shipment from the warehouse. The Odoo lead-time guide gives those terms specific start and end events. Record the equivalent events in your own planning vocabulary.
A purchase confirmation, a warehouse receipt, a warehouse shipment and a customer delivery are different milestones. Ask which one a report’s date represents before using it to explain availability or communicate an expectation to another team.
Keep the source of each lead-time input in an assumption register. Identify whether it came from an agreed term, a review of observed transactions or an estimate still awaiting confirmation. A field containing a number does not reveal which kind of evidence supports it.
Odoo’s manufacturing lead-time guidance uses calendar days rather than work-centre capacity planning. If manufacturing is involved, assess work-centre availability separately where the task requires it. Do not turn a calendar-based input into an assertion that a production schedule has accounted for every operational constraint.
Odoo has a separate field for time needed to obtain components or manufacture subassemblies. Ask the planner to explain the component dependency before interpreting the finished-product date. A production step cannot be understood fully from its own duration if the components needed to begin it remain unresolved.
How should buffers be justified?
Separate a quantity buffer from a timing buffer. Ask which risk each proposed setting addresses, what evidence supports it and who can review it. Avoid importing a standard percentage or number of days without explaining its relevance to the item and process.
The sales security lead time is a preparation buffer ahead of the scheduled delivery date. Keep that documented purpose visible in the configuration record. A date advanced to allow preparation is a different decision from holding additional units in stock.
For Test Filter, propose an assessment in which one expected receipt is delayed. Ask how the planning view changes and which decision the responsible person must make. Record the actual observed result when the exercise is performed; do not assume the application chooses a commercially suitable response on the planner’s behalf.
Include a question about the consequence of the buffer. Who reviews surplus stock, an unavailable component or a request that cannot wait? The purpose of the assessment is to make the trade-off intelligible, not to describe the largest buffer as automatically safest.
Who decides whether replenishment proceeds?
Odoo supports both automatic and manual reordering-rule triggers. Choose the intended review boundary deliberately. In a manual flow, ask who reviews the proposed order. In an automatic flow, ask which configuration and operating checks justify that choice and how an unexpected proposal becomes visible.
Odoo can round replenishment up to an order multiple that meets or slightly exceeds Max. Include a pack-size or order-multiple case in the controlled evaluation. Compare the proposed quantity with the target and ask the planner to explain any excess created by the configured multiple.
Use this original assumption-and-exception register for the representative item. It combines the basis of each input with the action required when reality differs from the plan.
| Planning input | Evidence to retain | Exception to assess |
|---|---|---|
| Demand considered | Named movements and forecast basis | Changed or missing demand record |
| Reorder minimum | Owner’s rationale and review decision | Rule triggers at an unexpected point |
| Replenishment target | Agreed target and relevant constraints | Order multiple changes the quantity |
| Purchase lead time | Defined confirmation and receipt events | Receipt occurs outside the assumption |
| Component preparation | Required components and their availability basis | A dependency remains unavailable |
| Timing buffer | Risk addressed and decision owner | Earlier preparation does not resolve the delay |
| Review boundary | Manual or automatic configuration and responsibility | Proposed replenishment needs intervention |
Keep proposed actions specific. “Review stock” is less useful than “the planner must confirm whether the delayed Test Filter receipt changes the quantity available for the named job”. A clear exception owner turns the report into a decision tool.
What should be checked before the rule is accepted?
Walk the synthetic item through an ordinary demand change, a delayed receipt and the selected order multiple. Record the configuration, contributing transactions and result for each case. Ask a colleague to explain why the proposed replenishment changed.
Do not change several assumptions at once merely to obtain an attractive result. Preserve the original scenario, record the input changed and compare the subsequent outcome. This gives the reviewer a basis for distinguishing a corrected setup from an arbitrary adjustment.
When reviewing an observed delay, keep the original expected milestone and the actual event date together. Ask whether the difference concerns the input assumption, an unrecorded movement or a separate operational decision before revising the rule.
Agree how the assumptions will be revisited after adoption. A new pack definition, changed demand pattern or different replenishment route should have an owner who knows which record to review. The register should preserve the earlier decision rather than present today’s inputs as if they had always applied.
For the general stock process, use the inventory-control guide. Explore web development, or discuss your requirements with Spout using the assumption-and-exception register.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.