A warehouse management system organises where goods are stored and how they move through receiving, storage, picking and dispatch. Evaluate it by whether staff can find the right stock, record the movement and investigate a difference. A product balance alone is not enough when the business needs location-level control.
Odoo’s location documentation explains warehouse spaces, parent hierarchies, location types and counting settings. Its receipt and delivery guide shows a basic movement workflow. These sources support a concrete introduction without claiming that a particular installation has achieved stock accuracy or meets every warehouse requirement. Odoo locations, receipts and deliveries.
How is warehouse control different from a stock list?
A stock list can say how many units a business records for a product. Warehouse control needs to answer where those units are, which can be picked and which movement explains their position. Goods awaiting inspection may require different treatment from goods available for sale.
Begin with a physical map of the actual warehouse. Identify receiving, storage, dispatch and any restricted areas the business genuinely uses. Do not create elaborate digital locations that staff cannot identify on the floor, nor claim facilities that do not exist.
Odoo defines a location as a specific space within a warehouse and categorises it by type. The type affects stock movement and valuation behaviour. Therefore location configuration is more than a naming exercise: a visually convenient label can have consequences for how the system treats stock.
Which location and route choices should you compare?
| Choice | Useful purpose | Demonstration required |
|---|---|---|
| Simple warehouse stock location | Straightforward receiving and dispatch | Locate a product and trace the source movement |
| Hierarchical locations | Separate zones, shelves or rooms | Move stock between identifiable locations |
| Multi-step route | Separate receiving, picking or other stages | Show who confirms each physical event |
| Restricted disposition area | Keep unresolved goods distinct | Demonstrate the intended availability controls |
| Location counting | Check recorded stock against observation | Record count, difference and approved correction |
The table is an editorial selection aid. It does not assert that every configuration supports an automatic restriction merely because a location has a descriptive name. Require the actual behaviour to be shown.
What do hierarchy and barcodes establish?
Odoo supports parent-child location structures and location barcodes. The barcode actions described require the Barcode app. A printed label without the configured application and workflow is not a complete scanning system.
Agree a recognisable naming convention that staff can use in speech, reports and labels. Keep the hierarchy understandable without requiring every location code to reproduce the full building description. This is a practical design recommendation, not a universal warehouse-code standard.
During a demonstration, scan or select the source and destination and inspect the resulting movement. Confirm the quantity and item identity as well as the location. A successful scan sound does not prove the correct stock movement was recorded. Location configuration and dependencies.
How should receiving and dispatch be tested?
Use a controlled product and a representative receipt. Record the accepted quantity and destination, then open the resulting stock position. Where inspection or rejection applies, show how those goods remain distinguishable from accepted stock.
Odoo’s one-step guide describes receipts and deliveries as separate operations and allows incoming and outgoing workflows to have different numbers of steps. Do not assume the warehouse must use the same route complexity in both directions.
For dispatch, select a product from the intended location and inspect the delivery record after validation. Compare the order’s delivered quantity with the physical movement evidence. A confirmed sales order is not, by itself, proof that staff handed goods to a customer or carrier. Test the configured event that represents that handover.
An original receive-pick-dispatch exercise
Run this exercise in an isolated test environment:
Starting position: record the product, unit, locations and observed opening quantity.
Receive: create the intended receipt and identify accepted versus unresolved goods.
Put away: move accepted stock into the selected storage location and inspect the trail.
Pick: prepare a partial outgoing quantity and record which location supplied it.
Dispatch: complete the intended handover record and inspect the remaining stock.
Return: record returned goods and their disposition without assuming they are immediately saleable.
Count: compare physical test stock with the system position at each relevant location.
Investigate: open the source documents behind any difference and retain the correction reason.
This is an original acceptance artefact. It does not establish a universal route, count frequency or operating procedure. Adapt it to the real warehouse while preserving evidence of each physical event.
What should cycle counting contribute?
Odoo’s location settings include an inventory frequency, last count and next expected count. The documented default zero frequency means no scheduled counts. A warehouse should therefore not assume counting reminders exist simply because the inventory module is installed.
Choose a counting process based on the business’s needs and available evidence. This article does not invent a universally sufficient interval or accuracy threshold. Record what was counted, who counted it and which movements occurred around the count boundary.
Investigate a discrepancy before changing the total. A correction may be necessary, but it should not conceal an unrecorded receipt, wrong location or duplicate dispatch. Keep the original evidence so the class of error can be addressed rather than repeatedly balancing the same product.
What should determine the WMS choice?
Choose the system and configuration that can demonstrate the required movement trail with ordinary staff roles. Separate current features from proposed integrations and custom development. Keep performance or accuracy claims tied to measured tests rather than a product label.
Discuss the requirements through Spout’s web development service or start an enquiry with the location map and exercise results.
Add a deliberate wrong-location selection to the exercise and inspect the resulting warning or allowed action. A system can maintain an accurate quantity while staff place goods in the wrong recorded space. Record how that error is detected and corrected, including the movement reference, rather than assuming a barcode scan always establishes the right destination. Repeat the count after the correction to confirm the two locations explain the physical position.
Define the hosting and recovery responsibilities for the warehouse application alongside the movement model.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.