OdooWiki OCA HUB

Stock Picking Backorder Policy

stock_picking_backorder_policy folder_open OCA/stock-logistics-workflow open_in_new
Inventory/Configuration License: AGPL-3

When a transfer is only partially done, Odoo decides whether to create a backorder for the remaining quantity based on the backorder policy of the operation type (Ask, Always or Never).

That default fits the warehouse, but the right answer is often driven by the document the transfer comes from: some customers always want the rest shipped later, others never do.

This module lets you optionally override that operation type default on the transfer itself:

  • Ask: the user is prompted (standard behaviour).
  • Always: a backorder is created automatically for the remaining quantity.
  • Never: the remaining quantity is cancelled and no backorder is created.

When left empty, the operation type's own policy applies, exactly like standard Odoo.

The policy is carried by the operations, so it survives multi-step routes and make-to-order chains. Modules building on top of this one seed it from their own documents: sale_stock_picking_backorder_policy for deliveries generated from a sale order, purchase_stock_picking_backorder_policy for receipts generated from a purchase order.

auto_awesome What this module does

AI-generated from the code · Odoo 19.0

Lets you choose, on each transfer, whether the remaining quantity should be backordered, cancelled, or asked about, overriding the operation type default.

This module adds a "Backorder policy" field on transfers (stock.picking) and on their move lines (stock.move). You can set it to Ask, Always or Never. If you leave it empty, Odoo behaves exactly as before and uses the policy configured on the operation type.

  • Ask: the user is prompted when the transfer is partially done.
  • Always: a backorder is created automatically for the remaining quantity.
  • Never: the remaining quantity is cancelled and no backorder is created.

The field appears on the transfer form, right after the operation type, and becomes read-only once the transfer is cancelled or done. The policy is carried along the moves, so it survives multi-step routes and make-to-order chains, and moves with different policies are not merged together.

When a transfer is validated with a policy that differs from the operation type's own policy, a note is posted in the transfer's chatter explaining which policy was used instead. The module touches the Inventory transfer screens and the stock rules that generate moves.

Depends on

stock
Models and fields (3)
  • stock.move · extends an existing modelbackorder_policy
  • stock.rule · extends an existing model
  • stock.picking · extends an existing modelbackorder_policy

Text generated by AI (DeepSeek) from reading the Odoo 19.0 code on GitHub; it may contain mistakes, so check the code before deciding. View the code on GitHub

Availability by version

Reviewed: 2026-11-03
Confirmed (verified in repository and branch) Estimated (unverified) No information

Confirmation status: 1 confirmed, 8 with no information of 9 versions.

Sources · Odoo 19.0

Confirmed on 2026-11-03 in branch 19.0 of OCA/stock-logistics-workflow.

terminal Installation and usage

OCA documentation · Odoo 19.0

On a transfer, set the Backorder Policy (Ask, Always or Never). The value set here takes precedence over the value set on the operation type; if left empty, the operation type's value is used.

When the transfer is validated with a missing quantity:

  • Ask: the usual backorder prompt is shown.
  • Always: a backorder is created automatically.
  • Never: the remaining quantity is cancelled.

Returns and exchanges are never subject to the transfer's backorder policy: they always follow the operation type's own Create Backorder setting, since the policy of the original transfer is not relevant to goods coming back in.

No verified information in OCA: Installation, Configuration.

info

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.