Test Odoo inventory by following an item through named locations and documented stock movements. Establish the warehouse route first, then compare a receipt and delivery with the intended physical process. A correct-looking total is insufficient if goods appear in the wrong location or the team misunderstands which action completes the movement.
Use a separate test database and a representative non-sensitive item. Record the Odoo version, enabled features and relevant warehouse configuration before the demonstration. This guide uses Odoo 18 documentation; it does not claim identical behaviour in another release or that a particular implementation has already been configured.
The original location-and-movement worksheet below is a proposed acceptance exercise. It focuses on what happens between a supplier receipt, a storage location and a customer delivery. General stock-control selection and accounting assurance require their own review rather than being inferred from this narrow workflow.
How should the location structure describe your warehouse?
Sketch the real places the demonstration needs to represent. A shelf inside a room is a different concept from the warehouse as a whole. Decide how much detail the business actually needs for retrieval, counting and movement. Do not create an elaborate hierarchy that the people handling goods cannot maintain.
Odoo’s locations documentation describes the relevant configuration. Specific storage locations require enabling Storage Locations. A location can have a parent location. Use those features to represent an agreed structure, and have the stock owner confirm the proposed labels and relationships.
Odoo location types determine stock-movement and valuation behaviour. Treat the type as more than a descriptive name. Ask the implementer to explain why each selected type fits its intended role, particularly when representing damaged goods, external holdings or other exceptions. Keep any accounting consequence outside acceptance until the appropriate reviewer has checked it.
A location barcode requires the Barcode app. If scanning is part of the proposed process, confirm the installed application and the actual scanning journey rather than assuming that entering a barcode field establishes a working warehouse workflow. This article does not claim hardware compatibility or a completed scanning test.
The Current Stock view includes on-hand quantities at the location. Use that location-level view during the demonstration. A product-wide total can hide a movement into an unintended place. Record which location was inspected and the relevant item identity alongside the displayed quantity.
Which route should the receipt and delivery follow?
Odoo’s one-step flow documentation supplies a defined baseline. Odoo’s documented default is one-step incoming and outgoing shipments. Ask whether the proposed installation retains that default or deliberately uses another route. The answer belongs in the test record before any transaction is entered.
Incoming and outgoing flows can use different numbers of steps. Do not infer the delivery process from a demonstration of receiving. A business may need distinct handling for each direction, and the configured route must be inspected independently. Describe the business requirement without assuming that a particular routing choice is already available.
Enabling Multi-Step Routes also activates Storage Locations. Record enabled features together so reviewers can understand why location controls appear. A demonstration performed after changing settings should not be described as proof of the original configuration. Retain the baseline and any agreed test change separately.
A confirmed purchase order provides a Receipt smart button. Validating a warehouse receipt moves it to Done. Keep the commercial order and warehouse receipt distinct in the handover. Ask the operator to identify the actual receipt being processed and explain the stock movement before treating the purchase workflow as demonstrated.
| Acceptance question | Proposed observation | Why the distinction matters |
|---|---|---|
| Where should the item be received? | Named destination and route are shown | An overall total can hide a wrong location |
| Which record represents the receipt? | Operator follows the purchase-to-receipt relationship | Order confirmation and goods handling need separate understanding |
| Has the receipt been completed? | Relevant receipt state and stock view agree | A visible document alone does not show completion |
| How will delivery differ? | Outgoing route is inspected separately | Incoming configuration does not establish outgoing handling |
| Is scanning required? | Installed feature and intended interaction are recorded | A barcode field is not a hardware acceptance result |
The table defines evidence requests. It does not prescribe a count frequency, accounting treatment or legal control. Those decisions need the business’s actual operating requirements and the relevant review, rather than a numerical rule invented for a software demonstration.
How should exceptions be included without damaging live stock?
Choose an exception that reveals a meaningful ambiguity. For example, a delivery may need clarification because the intended item is physically elsewhere. Write the expected business response before testing it. Do not change production quantities just to observe what the system allows, and do not treat an administrative adjustment as a substitute for understanding the movement.
Keep damaged, returned and unavailable stock requirements separate from the normal receipt. Ask which configured process would own each case, and request the corresponding publisher documentation before making a feature claim. A normal-flow demonstration cannot establish every exception merely because the application has an inventory menu.
Distinguish a requirement from a demonstrated behaviour in the acceptance notes. “The team needs location-specific visibility” describes a requirement. “The recorded test item appeared in the named location after the approved test receipt” would be an observation only after the exercise is actually performed. Keeping those statements separate prevents invented implementation experience.
Original shelf-to-customer acceptance worksheet
Prepare a fictional item called Sample Folder and proposed locations called Receiving and Shelf A in a separate test copy. These labels are illustrative, not a recommended warehouse standard. Record the intended route and location types, and have the business owner confirm what physical process the exercise represents.
Begin with the agreed starting stock state. Retain the item and location views before entering the sample purchase. Follow the documented order-to-receipt route, then ask the operator to explain the record awaiting action. Record the relevant reference so another reviewer can trace the same sample transaction.
Process the approved sample receipt and inspect the resulting state and location-level stock. Compare the result with the expectation written before the test. If a quantity or location differs, retain the mismatch and investigate its configuration. Do not silently change the expected route until the displayed result appears acceptable.
Next, inspect the outgoing configuration and follow the agreed sample delivery journey. Record its own evidence instead of copying the receiving result. Ask the stock owner to explain the item’s location before and after the proposed movement, including any point that remains unresolved.
Finally, review the record with the operator and implementer. Separate demonstrated requirements, configuration changes and open exceptions. Agree a later migration and recovery plan before touching live stock. Completion of this worksheet does not authorise importing balances, posting adjustments or changing production warehouse settings.
For broader requirements, see business systems and software development. Get started with your location sketch and the movements the demonstration must explain.
By Spout Team. AI-assisted drafting by Codex from linked Odoo primary documentation. No live stock change, configured deployment or accounting assurance is claimed.