If you’ve ever configured Odoo’s Inventory module to sell products from multiple stock locations simultaneously, you probably encountered the virtual warehouse pattern. It was a workaround more than a feature — a way to aggregate stock across physical warehouses into a single sellable pool so that sales orders could pull from wherever inventory happened to be available. The documentation for it lived inside the daily operations section of Inventory, and it described a workflow that, while functional, created edge cases around reservation conflicts, delivery routing, and stock valuation.
That documentation is now gone. Odoo has removed the entire “sell from multiple/virtual warehouses” article from its Inventory module — all 233 lines of it — along with its reference in the daily operations table of contents.
What the Virtual Warehouse Pattern Did
The original approach worked by creating a virtual warehouse that didn’t hold physical stock but instead aggregated availability across real warehouses. When a sales order was confirmed, Odoo would check the virtual location, find available stock across linked warehouses, and generate delivery orders from whichever location could fulfill the demand. It was clever but brittle — the reservation logic could produce unexpected results when multiple orders competed for the same stock, and the inventory valuation reports sometimes double-counted units in transit between locations.
For small businesses with two or three warehouses, it worked well enough. For anything larger, it became a source of fulfillment errors that were difficult to trace.
What Replaces It
Odoo isn’t removing the ability to sell from multiple locations. It’s removing one specific approach and steering users toward mechanisms that have matured significantly in recent versions.
The primary replacement is the routing and rules system. Warehouse routes let you define fulfillment logic per product, per warehouse, or per sales channel. A route can specify that online orders always ship from the distribution center, while in-store pickups pull from the nearest retail location. The rules engine handles reservation priority, inter-warehouse transfers, and dropship scenarios without the abstraction of a virtual stock pool.
For multi-entity organizations, the inter-company transaction system handles what virtual warehouses used to approximate. When Company A sells a product that Company B holds in stock, Odoo automatically generates a purchase order from A to B, a corresponding sales order on B’s side, and the inventory movements to support the transfer. The stock never needs to exist in a virtual location — it stays where it physically is, and the documents handle the rest.
A Grammar Fix Buried Alongside a Feature Removal
The same change that removed the virtual warehouse article also corrected a grammar issue in the daily operations index: “aren’t necessary” became “are not necessary.” It’s the kind of detail that tells you this wasn’t a rushed cleanup. Someone read through the page, fixed the English, and deliberately removed the reference to a workflow they no longer want users to follow.
What This Means for Existing Implementations
Removing documentation doesn’t immediately break existing configurations. If you have virtual warehouses set up and running in production, they’ll continue to work until the underlying code changes. But the documentation removal is a strong signal about direction. Odoo is telling implementers and consultants: stop recommending this pattern for new deployments.
For teams planning an upgrade or a new implementation, the message is clear. Invest time in understanding routes and fulfillment rules. Learn the inter-company transaction flow if you operate across entities. These are the mechanisms Odoo is actively developing and documenting, and they handle multi-location selling with fewer surprises than the virtual warehouse shortcut ever did.
The broader trend here is Odoo simplifying its Inventory architecture by removing patterns that created ambiguity. Virtual warehouses were always a workaround for a problem that routes solve more cleanly. Removing the documentation is the first step; the code will likely follow in a future version. If your warehouse configuration relies on this pattern, now is the time to start migrating to routes — not when the upgrade forces your hand.