Stock Available to Promise Release
Currently the reservation is performed by adding reserved quantities on quants, which is fine as long as the reservation is made right after the order confirmation. This way, the first arrived, first served principle is always applied. But if you release warehouse operations in a chosen order (through deliver round for example), then you need to be sure the reservations are made in respect to the first arrived first served principle and not driven by the order you choose to release your operations.
Allow each delivery move to mark a quantity as virtually reserved. Simple rule would be first ordered, first served. More complex rules could be implemented.
When the reservation of a picking move occurs, the quantity that is reserved is then based on the quantity that was promised to the customer (available to promise):
- The moves can be reserved in any order, the right quantity is always reserved
- The removal strategy is computed only when the reservation occurs. If you reserve order 2 before order 1 (because you have/want to deliver order 2) you can apply correctly fifo/fefo.
- For instance order 1 must be delivered in 1 month, order 2 must be delivered now.
- Virtually lock quantities to be able to serve order 1
- Reserve remaining quantity for order 2 and apply fefo
- Allow to limit the promised quantity in time. If a customer orders now for a planned delivery in 2 months, then allow to not lock this quantity as virtually reserved
- Allow to perform reservations jointly with your delivery rounds planning. Reserve only the quants you planned to deliver.
When move qty is not completely satisfied on release, the remaining qty is split and attached to a new picking that can be released later.
Important: if the "Stock reservation horizon" is set, the qty is calculated on moves which have an expected date not beyond \$today + \$horizon (in days).
Important: Moves without a warehouse set are not supported. If the warehouse is not set on the move, the "Ordered Available to Promise" Quantity will always be 0. It will also not be considered as consuming existing stock. The warehouse gets set by the Stock rule, if the Rule is not assigned to a warehouse, also the move will not end up with a warehouse.
auto_awesome What this module does
AI-generated from the code · Odoo 18.0Lets warehouse staff release delivery transfers in a chosen order while still reserving stock fairly, based on the quantity promised to each customer. Adds release and unrelease buttons, priority dates, and available-to-promise quantities on transfers and moves.
This module changes how outgoing deliveries are reserved. Instead of reserving stock the moment an order is confirmed, moves can wait in a 'to release' state. When you release a transfer, the quantity reserved is based on the quantity promised to the customer (available to promise), so releasing transfers in any order still respects first-ordered, first-served.
- On transfers and moves you see new fields: Priority Date, Ordered Available to Promise, Quantity Promised before this move, and flags showing whether a transfer needs release or is ready to release.
- Buttons let you Release or Unrelease transfers and moves. Unreleasing cancels the chained moves and can return already-done quantities to stock.
- A transfer's release policy can be 'As soon as possible' or 'When all products are ready'.
- Picking types can be set to 'Unrelease on backorder' and 'Prevent new move after release'.
- Routes and rules can be set to 'Release based on Available to Promise', 'No backorder at release', and 'Reverse done transfer on cancellation'.
- Company settings control the reservation horizon (days) and the maximum preparation time used to reschedule released transfers.
- Menus appear under Inventory reports ('Moves Allocations') and transfers ('Transfers Allocations'), and products show a count of moves needing release.
The module touches stock.move, stock.picking, stock.picking.type, stock.route, stock.rule, product.product, res.company, and adds the stock.release and stock.unrelease wizards.
Depends on
Required by other modules
Menus it adds
Models and fields (14)
- stock.move · extends an existing modelneed_release, date_priority (Priority Date), release_ready, unrelease_allowed, previous_promised_qty (Quantity Promised before this move), ordered_available_to_promise_qty (Ordered Available to Promise (Real Qty)), ordered_available_to_promise_uom_qty (Ordered Available to Promise)
- stock.rule · extends an existing modelno_backorder_at_release, available_to_promise_defer_pull, allow_unrelease_return_done_move
- res.company · extends an existing modelstock_reservation_horizon, stock_release_max_prep_time (Transfer Releases Max Prep. Time)
- stock.route · extends an existing modelno_backorder_at_release (No backorder at release), available_to_promise_defer_pull (Release based on Available to Promise), allow_unrelease_return_done_move (Reverse done transfer on cancellation)
- stock.picking · extends an existing modelneed_release, date_priority (Priority Date), release_ready, release_policy, last_release_date, need_release_count (# of need release moves), release_ready_count (# of moves ready)
- stock.release · new model
- stock.location · extends an existing model
- product.product · extends an existing modelmove_need_release_count (Moves Need Release)
- stock.unrelease · new model
- procurement.group · extends an existing model
- stock.picking.type · extends an existing modelunrelease_on_backorder (Unrelease on backorder), count_picking_need_release, prevent_new_move_after_release (Prevent new move after release)
- res.config.settings · extends an existing modelstock_reservation_horizon, stock_release_max_prep_time
- stock.return.picking · extends an existing model
- stock.return.picking.line · extends an existing model
Text generated by AI (DeepSeek) from reading the Odoo 18.0 code on GitHub; it may contain mistakes, so check the code before deciding. The module is very large and only part of the code was read. View the code on GitHub
Availability by version
Reviewed: 2026-11-03Confirmation status: 4 confirmed, 5 with no information of 9 versions.
Sources · Odoo 13.0
Confirmed on 2026-11-03 in branch 13.0 of OCA/wms.
terminal Installation and usage
OCA documentation · Odoo 18.0Configuration
Source · Odoo 18.0In Inventory \> Configuration \> Routes, activate the option "Release based on Available to Promise" on the routes where you want to use the feature.
To modify the horizon go to "Inventory \> Settings" and change "Stock reservation horizon".
Usage
Source · Odoo 18.0When an outgoing transfer would generate chained moves, it will not. The chained moves need to be released manually. To do so, open "Inventory \> Operations \> Stock Allocation", select the moves to release and use "action \> Release Stock Move". A move can be released only if the available to promise quantity is greater than zero. This quantity is computed as the product's virtual quantity minus the previous moves in the list (previous being defined by the field "Priority Date").
This behaviour is activated by stock route by setting the option "Release based on Available to Promise".
By default, when an outgoing transfer is released, a backorder is created for the remaining quantities for products not available at release time. This behaviour can also be changed by stock route by setting the option "No backorder at release". In such a case, moves created for unavailable products will remain in the original outgoing picking and no backorder will be created.
One a picking is released, you can also ensure that new move will no more be assigned to a released picking by setting the option "Prevent new move after release". on the stock picking type.
At the end of the picking process (when the picking is validated) of an outgoing transfer, if a backorder is created, the chained moves can be automatically unreleased. This behaviour is activated by setting the option "Unrelease on backorder" on the stock picking type.
No verified information in OCA: Installation.
Installation instructions, the distribution package, dependencies and configuration steps are not shown because they have not yet been verified in the module documentation for any version.
Data imported from GitHub: this sheet reflects the latest catalog review, not a live lookup. Always check the module documentation and staging before installing in production.