Skip to main content

Stock Reservation Expiry

Purpose​

Stock Reservation Expiry helps Inventory teams free stock tied to stale reservations. Policies calculate warning and release deadlines, support manager holds and extensions, and optionally use Odoo's native unreserve operation when a reservation expires. Release frees a reservation; it does not cancel the sales order, complete the delivery, or move physical stock.

The addon extends transfers and sales orders, with an operational queue and retained reservation-event history.

Before you start​

Install the package for your Odoo major version with native Sales/Inventory integration (sale_stock) and the Python library xlsxwriter. The manifest declares no Enterprise-only dependency. Use a narrowly scoped policy first, with the operation type explicitly selected if the intended scope is outgoing deliveries.

Company evaluation is disabled by default, and new policies are inactive. A policy must be saved and previewed before activation. Configure a responsible execution user with Inventory Manager access to that company; this user’s permissions matter to scheduled evaluation.

This guide follows the 19.0 source workflow. Other source versions received selected comparisons. No scheduled job, release, notification, or runtime test was executed for this guide.

Access and roles​

Inventory users can read policies, the queue, and reservation events. Inventory Managers configure policies and company settings, preview impact, place or clear holds, extend reservations, release stock, and export value information. Transfer write access and an active permitted company are also required for decisions. Reserved monetary values and exports are manager-only; the event log is retained by the controlled workflow.

Setup and menu​

Use Reservation Expiry Policies in Inventory configuration, Reservation Expiry Queue in operations, and Reservation Release History or Export Reservation Audit in reporting. Transfers show a Reservation Expiry section and Reservation Events smart button. Sales orders summarize their related delivery reservation status.

A policy can narrow the operation type, warehouse, routes, customer or tags, product or exact category, source-document text, sale payment terms, and delivery priority. Choose an anchor: First Assignment, Transfer Confirmation, Sale Confirmation, or Scheduled Date. The release deadline is anchor plus lifetime; the warning deadline is that result minus warning lead. The default lifetime is 24 hours, warning lead four hours, and cooling period two hours.

Choose Monitor Only, Manager Decision, or Auto Release. Only the last mode authorizes scheduled unreserve. Configure activities and internal email recipients deliberately: warnings can create follow-up activities and, when enabled, internal notifications.

In Inventory settings, Reservation Expiry & Auto-Release contains Enable policy evaluation, Batch safety, Default cooling period, and Execution user. The supplied scheduler wakes every 15 minutes; each company also has its own evaluation cadence, default 60 minutes, and batch size, default 100. A configured deadline is therefore not a guarantee of release at that exact second.

Workflow​

  1. Create an inactive policy with a narrow scope, suitable anchor, lifetime, warning lead, mode, and exemptions. The warning lead must be shorter than the positive lifetime; cooling cannot be negative.
  2. Save and select Test Policy. Inspect Policy Preview for matched transfers, products, reserved quantities, current status, and exemption reasons. The preview refuses more than 500 matching reserved moves; narrow the scope when needed.
  3. Activate the policy only after reviewing that current revision. Existing reservations are brought under evaluation. When no first-assignment timestamp exists, activation is the first conservative observation used for that anchor. To change evaluation settings later, deactivate, edit, save, preview again, and reactivate.
  4. Enable company evaluation with the authorised execution user when ready. Use the queue to review Active, Warning, Held, Expired, Released, Exempt, and Error states. A warning can create configured follow-up; it does not itself release stock.
  5. On a transfer, an Inventory Manager can select Hold Reservation, Extend Reservation, or Release Now. Enter a business reason. Holds and extensions require a future end time. The decision wizard also supports Clear Hold. Holds prevent release until cleared or expired; extensions move the effective release deadline later.
  6. In Auto Release, the scheduled process rechecks an expired reservation before native unreserve. Release Now allows a manager decision before the automatic deadline, but still requires an active matching policy and refuses holds, exemptions, picked moves, completed/cancelled moves, and reservation-bypass flows.
  7. Review Reservation Events and the transfer's last outcome. After release, cooling temporarily prevents automatic reassignment. An explicit native transfer availability check can bypass that cooling filter. Managers can use Audit PDF or export a date range as CSV/XLSX; export dates and timestamps follow the exporter's timezone.

Practice scenario​

In an authorised test database, reserve fictional “Cedar Dispatch Unit” on one normal-priority, unlocked delivery. Create a product-specific Monitor Only policy and run Test Policy. Inspect its match and deadline, then place a manager hold with a reason and a future end time. The source-derived expectation is Held status without stock being released. This scenario was not executed.

Troubleshooting and limitations​

Default exemptions include urgent deliveries, locked transfers, reservation-bypass flows, and chained/cross-dock flows. Configured routes and approved customer tags can also exempt a reservation. The optional paid-order exemption requires fully invoiced, fully paid coverage; a paid deposit alone is insufficient. If payment status cannot be read, the policy treats it conservatively as exempt when that option is enabled.

Missing anchor dates prevent a deadline. A changed reservation can invalidate a preview and require a fresh review. Company evaluation without a valid execution user is skipped, so inspect settings and error history rather than assuming expiry occurred. Setting policy cooling to zero uses the company's fallback cooling value. No background release is promised for Monitor Only or Manager Decision mode.

Qualified catalogue versions are 15.0, 16.0, 18.0, 19.0, and 20.0; 17.0 exists in source but is not a qualified live-demo pair here. Versions 15–16 use earlier reserved/done quantity fields; later releases use the newer stock quantity/picked flow. Scheduler progress APIs differ. Version 20 explicitly checks accounting read rights and follows native invoice-line links for the paid-order exemption, and adapts unit and access APIs. Secondary workflows remain unreviewed beyond the selected comparisons.

Live Test — Odoo 19 is catalogue-qualified; no demo was launched. Choose your exact version in the Corvus catalogue.

Related guides: Stock Transfer Approvals and Delivery Shelf Life Rules.