Odoo 19 Inventory: Putaway, Removal, and Replenishment Deep-Dive

The Odoo 19 inventory module looks similar to 17 on the surface but the rules engine underneath was rewritten. If you migrate without re-mapping your putaway and removal strategies, your warehouse operators will see incoming receipts route to wrong locations and outgoing pickings consume the wrong lot. This article walks through the rules that changed, the configuration flow that replaces what you had, and the gotchas we have hit in real warehouse migrations.

ECOSIRE has migrated 25+ multi-warehouse Odoo deployments to 19.0, including pharma (FEFO-strict), automotive (FIFO with serial tracking), and 3PL (multi-tenant with custom putaway). The patterns below come from those projects.

Key Takeaways

• Putaway rules are now ordered with explicit priority and category fallbacks instead of first-match
• Removal strategies expanded from 4 to 7, including a "least-rotation-cost" option for cold storage
• Dynamic replenishment can now combine min/max + lead-time + seasonality into one rule
• Multi-step routes ship pre-configured for cross-docking and consolidation
• The barcode application got a real offline mode (queued operations sync when WiFi returns)
• Lot/serial inheritance through manufacturing routes is automatic instead of manual
• Storage capacity constraints now exist on stock.location (max weight, max volume, max units)

Putaway strategies — what changed

In Odoo 17, putaway was a single ordered list of rules per warehouse. The first matching rule won. This worked until you had 50+ rules and needed conditional logic ("box of product X goes to A unless A is full, then B").

Odoo 19 introduces:

• Explicit priority (1-100, lower runs first)
• Conditional location chaining (if-full fallback)
• Category-level rules with product overrides
• Storage capacity check built in: a putaway rule won't route to a location that would exceed its max_weight_kg, max_volume_m3, or max_units constraint

Configuration shifts from Inventory > Configuration > Putaway Rules (one big list) to a layered view:

Warehouse: Main DC
  Category: Bulk
    Rule 1: Pallet → Bulk-Aisle-A (priority 10)
    Rule 2: Pallet → Bulk-Aisle-B (priority 20, fallback if A full)
  Category: Pickface
    Rule 3: Each → Pick-Zone-1 (priority 10, capacity-checked)
  Product: Hazmat-001
    Rule 4: Override → Hazmat-Bay (priority 1)

The migration script will move your 17.0 rules into category 'Default' and capacity fields default to unlimited. You almost certainly want to refactor toward category rules post-migration.

Removal strategies — 4 became 7

Odoo 17 supported FIFO, LIFO, FEFO, and "Closest Location". Odoo 19 adds:

The "Custom Python" option exposes a small expression sandbox on stock.removal.strategy that returns a sorted list of stock.quant records. Useful for warehouses with rotation rules that don't fit any stock pattern (e.g., "consume highest-temperature-history lot first").

# Custom removal strategy — example: prefer lots whose age > 60 days
# but only if quantity exceeds 100 units
def custom_removal(quants, demand):
    aged = quants.filtered(
        lambda q: (fields.Date.today() - q.in_date).days > 60
                  and q.available_quantity >= 100
    )
    return (aged | quants).sorted('in_date')

Dynamic replenishment

Odoo 17 had separate fields for min/max stock, lead time, and seasonality forecasts; combining them required a custom cron. Odoo 19 ships a single replenishment rule type that includes all three:

Replenishment Rule: SKU-12345 at Main-DC
  Trigger: When forecast inventory < 50 units within 14 days
  Quantity: max(min_qty, forecast_demand * lead_time_days * safety_factor)
  Source: Vendor-A (lead time 7 days)
  Seasonality: Multiply demand by [Jan: 1.2, Jul: 0.8, Dec: 1.5]
  Schedule: Generate POs every Monday

The forecast input can be the system's built-in time-series forecast, a CSV upload, or an external API call (configurable via ir.actions.server).

For SMBs without dedicated demand planners, this is the single biggest reason to migrate to 19 — manual reorder-point spreadsheets disappear.

Multi-step routes — pre-configured

Odoo 17 supported 1-step, 2-step, and 3-step receipts/deliveries. Configuring cross-docking or consolidation flows required custom routes. Odoo 19 ships:

• Cross-docking: Receipt → directly to outgoing dock without put-away (auto-skip storage step)
• Consolidation: Multiple inbound transfers merge into single put-away
• Wave picking: Multiple outbound pickings batch into one wave by zone
• Cluster picking: Operator picks for multiple orders simultaneously into a cart

Each ships as a switchable route on the warehouse form. No custom XML required.

Barcode application — offline mode

The mobile barcode app in 17 needed live network for every scan. Operators in dead-zone aisles had to back-track. Odoo 19's app:

• Caches the picking on device when opened
• Queues all scans locally
• Syncs operations on a single submit when network returns
• Conflict resolution: warns if a queued scan conflicts with another operator's confirmed scan

The wire-protocol changed; if you customized the barcode app's workflow in 17, the JS/OWL components moved.

Lot/serial through manufacturing

In 17, lot numbers from raw materials didn't automatically inherit to finished-goods lots; you had to wire it via stock.move.lot_ids overrides. In 19, the relationship is first-class:

• Each manufacturing order has a "consumed lots" panel showing every input lot
• Finished goods lot inherits a parent_lot_ids many2many
• Recall workflows query the parent chain: "if lot X of raw material is recalled, here are all finished-goods lots that consumed it"

For regulated industries (FDA, pharma, food) this replaces a custom module that was a permanent fixture in our previous deployments.

Storage capacity constraints

stock.location gained three fields:

• max_weight_kg (Float)
• max_volume_m3 (Float)
• max_units (Integer, optional per-product override)

Putaway rules respect these. Inbound transfers warn (or block, configurable) before exceeding capacity. The reservation engine treats over-capacity locations as ineligible.

Migration playbook (inventory module)

1. Audit putaway rules: Export current rules to CSV. Map each to the new layered structure (warehouse → category → product). Aim to consolidate similar rules into category-level entries.
2. Re-map removal strategies: Per product category, decide FIFO/LIFO/FEFO/etc. Document custom Python strategies if any.
3. Pre-flight capacity data: Measure max weight/volume per critical location. Populate before go-live.
4. Test cross-docking: If you used custom cross-dock routes, validate the stock cross-dock route post-migration.
5. Re-train barcode operators: Offline mode workflow differs; show them the queue indicator.
6. Validate lot inheritance: Run a test MO with multi-component BOM and verify lot lineage display.

Real-world inventory metrics

For three multi-warehouse clients post-migration we tracked:

The error reductions come from capacity constraints catching mistakes earlier and FEFO enforcement ending the "we shipped the wrong-date lot" incidents. Inventory accuracy at year-end physical counts improved by an average of 1.1 percentage points across our pharma and food-handling clients.

Integration with manufacturing routes

Odoo 19's tighter integration between inventory and manufacturing means changes here propagate forward:

• An MO consuming raw materials respects the removal strategy of the source location automatically
• Finished-goods receipts route through the matching putaway rules
• Backorder logic for MOs respects capacity constraints (won't suggest receiving partial goods to an over-capacity location)
• Returns route through dedicated reverse-flow rules (new in 19) that don't reuse the forward putaway

If you have custom MO-to-stock-move logic from 17, audit it post-migration. Most cases reduce: the new integration eliminates 4-6 typical custom modules per manufacturing client.

Multi-warehouse and inter-warehouse transfers

Odoo 19 cleaned up how transfers between warehouses work. Key changes:

• The "Resupply" route is now first-class for inter-warehouse demand (no more configuring procurement-rule chains by hand)
• Transfer status visibility improved: in-transit count is queryable per warehouse
• ETAs are computed from lead times automatically and update if a transfer is delayed
• A single MO at the receiving warehouse can pull from multiple source warehouses via priority-ordered resupply rules

For 3PLs and multi-DC retailers, this is the second-largest reason to migrate after the replenishment improvements. Operations teams stop running custom inter-warehouse transfer planning sheets and let the system surface delays automatically.

Frequently Asked Questions

Will my Odoo 17 putaway rules survive migration?

Yes, openupgrade migrates them into the new structure as flat rules under category 'Default' with priority based on original sequence. They will work, but you should refactor toward category-level rules within a sprint of going live to take advantage of the new logic.

Does the offline barcode mode work on iOS and Android?

Yes, the offline cache works on both platforms via the IndexedDB layer. Note that very old devices with limited storage may not cache more than 200-300 picking lines; tune the barcode.cache.max_lines system parameter if you hit that ceiling.

Can I mix removal strategies — FEFO for some products, FIFO for others?

Yes. Removal strategy is configured per product category or per individual product (override). A pharma SKU can use FEFO while a non-perishable accessory uses FIFO in the same warehouse.

How does Odoo 19 handle expired lots that should never ship?

The expiration_date field combined with FEFO ensures expired lots are consumed first by default, but Odoo 19 added an "expired lots are blocked from picking" warehouse-level toggle. With it enabled, expired lots stay in inventory but are invisible to the reservation engine, forcing physical disposition before they can be moved.

What is the cost of enabling storage capacity constraints retroactively?

Setting capacity on existing locations is metadata-only and instant. The constraint engine evaluates on inbound moves only, so existing over-capacity locations stay over-capacity until manually rebalanced. Run a rebalancing cron or campaign before flipping the "block over-capacity" hard mode.

---

Inventory is where Odoo 19 most rewards migrations from older versions. ECOSIRE's Odoo implementation team configures multi-warehouse setups with putaway, removal, and replenishment tuned to your real flow. We have a 5-day "WMS readiness" sprint that audits your current rules and produces a 19.0 configuration plan — see our Odoo customization service for details.