A shop can be out of stock while the central warehouse holds plenty of the same product. In Odoo 20, the first solution to examine is an inter-warehouse resupply route—not another vendor purchase order. Configure the shop as a warehouse that can be supplied by the distribution center, enable that resupply route on the product, then choose how demand should trigger the transfer: Replenish on Order (MTO) or a reordering rule.
Odoo 20 documents both methods and the paired transfers they create: an outgoing delivery from the central warehouse and an incoming receipt at the shop, with goods tracked in an inter-warehouse transit location between those steps. This is a useful built-in workflow, but it does not absolve the implementation team from checking source availability, lead times, reservations and duplicate purchasing. See Odoo 20's inter-warehouse replenishment guide.
Start by separating three different problems
Before configuring anything, establish what the business means by replenishment.
Store-to-store or central-to-store movement transfers stock the business already owns between warehouses. The question is where inventory should move.
Vendor purchasing brings new stock into the business. The question is when to buy more, from whom and in what quantity.
Customer-order fulfillment reserves or procures goods for a specific customer order. The question is whether one order requires a dedicated supply chain.
These flows can be connected, but they are not interchangeable. A local store should not create a fresh supplier order merely because it cannot see the 200 units sitting in another warehouse. Equally, seeing 200 units at headquarters does not prove they are unreserved, pickable or available before the store's deadline.
The aim is to make the source, destination and trigger explicit.
Native Odoo 20: one warehouse can resupply another
Odoo 20 provides a warehouse-level Resupply From configuration and a product route of the form Store: Supply Product from Central. The official setup begins by enabling storage locations, creating or selecting the central and store warehouses, and checking the central warehouse under the store's Resupply From field. The route then becomes available for relevant products. Odoo 20 documentation: Inter-warehouse replenishment.
A simple operating model might look like this:
| Record | Illustrative value | Purpose |
|---|---|---|
| Central warehouse | CENTRAL | Holds imported or manufactured inventory |
| Retail warehouse | SHOP | Holds saleable stock at a branch |
| Source stock location | CENTRAL/Stock | Where the transfer should take stock from |
| Destination stock location | SHOP/Stock | Where the branch needs stock |
| Product route | SHOP: Supply Product from CENTRAL | Connects the two warehouses for this product |
| Reordering rule location | SHOP/Stock | Tests demand at the branch rather than at headquarters |
These names are illustrative, not screenshots or a claimed result from a tested Odoo instance. The location structure and routes in your own database may differ if you use multi-step receipts, quality checks or custom stock rules.
Configure the route in the correct order
First, confirm both warehouses exist and that Storage Locations is enabled in Inventory → Configuration → Settings. In Inventory → Configuration → Warehouses, open the store warehouse and select the central warehouse under Resupply From. Then open a product intended for store replenishment and select its newly available Supply Product from route on the Inventory tab.
Finally, decide whether a sales order should drive a dedicated supply action, or whether the store should maintain a buffer and reorder to a target quantity. The difference determines whether to use MTO or a reordering rule.
Do not start by writing a custom scheduled action that moves stock between generic locations. Odoo already models the shipping and receiving documents as warehouse operations; use those native records unless a real business requirement cannot be met by their configuration.
MTO versus a reordering rule: choose by intent
Odoo 20's inter-warehouse guide supports both MTO and reordering rules for warehouse resupply. The choice is operational, not cosmetic. Source: Odoo 20 inter-warehouse replenishment.
| Business requirement | Prefer to evaluate | Trade-off |
|---|---|---|
| A specific customer order requires dedicated replenishment | MTO | Closer demand-to-supply traceability, but more order-driven movement |
| A branch sells frequently and needs shelf stock | Reordering rule | Maintains local stock levels, but replenishment is not necessarily reserved for one order |
| A manager must review every proposed branch replenishment | Reviewed/manual replenishment process | Human control, with possible delays if nobody owns the queue |
| Low-value, predictable branch demand | Tested automated reordering | Less routine administration, with greater sensitivity to bad thresholds or bad stock data |
Use MTO when the source sales order matters
In the standard Replenish on Order strategy, Odoo 20 documents that confirming a sales order drives procurement linked to that customer demand. The generic MTO documentation explicitly warns that the supply document can be created even if stock exists, and canceling its linked request for quotation or manufacturing order does not automatically regenerate a replacement. Source: Odoo 20 MTO guide.
For a central-to-store transfer, select the resupply route and MTO where that dedicated order-driven behavior fits the business. Then confirm that the sales order's Warehouse is the store—not headquarters. Test the generated documents before trusting the configuration.
MTO is a poor default for every fast-moving retail item when the actual goal is to keep a shelf filled. It may create unnecessary individual supply movements instead of planning branch stock in workable batches.
Use reordering rules when the branch needs a buffer
For replenishment by threshold, Odoo 20 instructs users to create a reordering rule with the retail stock location, the inter-warehouse route, and minimum/maximum quantities. That is the important configuration point: the rule belongs where the stock is needed. Source: Odoo 20 inter-warehouse reordering configuration.
Consider an illustrative policy for one product:
- A store aims to keep roughly 18 units available for sale.
- Its purchasing/operations team wants a replenishment review when the store's relevant forecast falls below 6 units.
- The route is
SHOP: Supply Product from CENTRAL, not Buy.
If the planning quantity falls to 4, the business might expect a proposal near 14 units to restore the target of 18. That number is a planning example, not a claim of an exact Odoo calculation. Forecasted supply, demand timing, reserved stock, quantities already in transit, rounding and package rules can change what a configured database proposes. Review the actual suggested quantity and linked transfer before enabling unattended automation.
The point is to replenish the store from central stock instead of asking the supplier for 14 more units by mistake.
Follow both legs of the transfer
When the route is triggered, Odoo 20 describes two warehouse operations:
- An outgoing delivery from the central warehouse.
- An incoming receipt at the store.
During movement, inventory is represented in Physical Locations/Inter-warehouse transit in the documented workflow. Source: Odoo 20 inter-warehouse transfer sequence.
The operational distinction matters. A transfer document being created is not the same as goods being picked. Goods being dispatched are not yet necessarily available on the branch shelf. Someone must still reconcile shipped and received quantities, shortages, damaged goods and any tracked lots or serial numbers.
Acceptance rule: the final stock position should make physical sense at each step. The source decreases only through the appropriate operation, stock in transit is visible while moving, and the store receipt reflects what was actually received—not automatically whatever the original plan requested.
Why a branch can still run out despite central stock
When a route appears correct but a branch remains empty, investigate in a consistent order.
1. The product has no applicable resupply route
A warehouse-level Resupply From setting does not by itself prove every product is eligible. Odoo 20's documentation separately instructs you to select the generated route on the product. Check the product's Inventory tab and the route selected by any reordering rule. Odoo 20 setup.
2. Demand is attributed to the wrong warehouse
If a quotation is fulfilled from CENTRAL while the operational requirement is a sale from SHOP, the stock demand may be applied in the wrong place. Check the Warehouse on the sales document, then inspect the resulting stock moves and procurement route.
3. The reordering rule is watching the source location
A rule at CENTRAL/Stock answers whether headquarters needs stock. It does not necessarily answer whether SHOP/Stock needs replenishment. Compare the rule's location with the actual destination of the resupply route.
4. On-hand stock is not usable stock
The central warehouse may show units on hand that are already reserved, in a quality location, damaged, awaiting an operation or physically somewhere else. Use stock-by-location information rather than a single top-line product total. Odoo 20's Detailed Stock report is designed to show where quantities sit, including locations and, where applicable, lot/serial information.
5. The timing does not match the promise
A store may need stock tomorrow while the agreed truck schedule is three days. Route configuration cannot defeat transport time. Odoo 20 documents several types of lead times and scheduling offsets, including vendor and purchasing lead times for upstream procurement. Map those separately from the real central-to-store transport and receiving process. Odoo 20 lead times.
6. Two systems are making the same decision
A custom integration, spreadsheet process or old automation may create a transfer or purchase request while native Odoo replenishment does the same. Before turning on automatic rules, list every actor that can create demand or procurement documents. Give one system responsibility for each action.
Do not let store replenishment become double purchasing
An inter-warehouse route should not be confused with an upstream purchase rule. If the central warehouse is low as well, someone may need to buy or manufacture more stock. That is a second planning decision and should have its own clearly defined trigger.
A safe policy is to distinguish:
- Shop demand: do we need to move stock from the central warehouse to the shop?
- Central demand: after all branch allocations and expected receipts, do we need to replenish the distribution center from vendors or production?
If both stock movements and purchasing are automated, review existing open transfers, RFQs, orders and reservations before adding further demand. The first production test should include an overlapping store replenishment and central warehouse shortage to expose unintended duplicate documents.
For groups with several legal companies, stop before copying this same-company design. Multiple warehouses and multiple companies are not equivalent. Odoo's company-specific ownership and intercompany transactions introduce additional accounting and access requirements; see Octivex's Odoo 20 multi-company guide.
A concrete test plan before go-live
Use a staging database that matches your real warehouse structure, with a small set of representative products. Do not assume the output is correct because a transfer document appears.
| Test | What to verify |
|---|---|
| Branch stock below threshold, central has free stock | Correct store location, route, planned quantity and paired transfers |
| Branch stock below threshold, central fully reserved | No silent promise to transfer unavailable goods; visible exception or delayed availability |
| Product has no resupply route | Predictable error or no replenishment, not an unexpected vendor purchase |
| Sales order uses the wrong warehouse | The error is detectable and correctable before shipping |
| Two stores require the same limited central stock | Reservation and prioritization policy is explicit |
| Source delivery completed; destination receipt pending | Quantities remain traceable in transit |
| Destination receives fewer units than shipped | Shortage can be reconciled without fictitious stock |
| MTO-linked order is canceled | Related supply documents and reservations are reviewed, not abandoned |
| Duplicate trigger or integration retry | No duplicate open transfer or RFQ is silently accepted |
| Product uses lot/serial tracking | Traceability remains intact across both warehouse legs |
| Branch needs goods before transport can deliver | Shortfall is surfaced in lead-time planning |
Add one final user-acceptance scenario with the staff who actually operate the warehouse: a branch supervisor requests stock, central staff pick and dispatch it, branch staff receive it, and operations reconcile the documents. That validates the physical hand-off, not just the screen configuration.
When would custom code make sense?
Native routing is the right starting point for a central warehouse replenishing retail outlets. Custom engineering becomes reasonable only if the documented flow cannot represent the actual policy—for example, priority allocation across dozens of shops, temperature-controlled dispatch windows, contractual transfer approvals, carrier integration, location-dependent cutoffs or a specialized exception workflow.
Even then, extend Odoo's existing warehouses, stock moves and procurement logic rather than creating an unrelated parallel stock ledger. Define idempotency for any external command that creates transfer requests. Test cancellations, partial receipts, cross-company boundaries and upgrade compatibility.
For a broader inventory view, Octivex also lists an Inventory Dashboard. Its current product page advertises Odoo 19 support; confirm compatibility before assuming that product is ready for Odoo 20.
Conclusion: make stock movement the first decision
For a central warehouse with multiple branches, the useful question is often not “What should we buy?” but “Where is the existing stock, and which location needs it?” Odoo 20 supplies the warehouse-to-warehouse route, an MTO option for order-driven supply and reordering rules for branch-level replenishment.
Configure the correct source and destination, choose the trigger based on business intent, and test the full delivery–transit–receipt chain. Only then automate larger volumes or introduce custom logic.
If branch stockouts persist while inventory is available elsewhere in your group, Octivex's Odoo implementation and customization team can help map the warehouse routes, reordering policies and integrations before additional code or purchasing is introduced.