Skip to main content

Stock Transfer Approvals

Purpose​

Stock Transfer Approvals applies quantity and estimated-value policies to internal inventory transfers. It can require approval before reservation, before validation, or at both stages. Each request preserves the transfer facts, policy revision, reason and decision so that an old approval cannot silently authorise changed goods or locations.

The app extends native Inventory transfers. It does not apply its approval gate to receipts or deliveries. Approval authorises the selected stage; the operator still performs the normal stock action.

Before you start​

Install the matching package with native Inventory and Discuss/Mail (stock and mail). XLSX audit export requires the declared xlsxwriter Python library. No Enterprise-only dependency is declared.

Prepare internal operation types, source and destination locations, product units and company-specific standard costs. Estimated value uses demand converted to each product’s reference unit multiplied by its standard cost, in company currency. It is a policy estimate, not an accounting valuation or landed-cost calculation. Aggregate quantity adds those reference quantities across products and is a policy signal, not a shared physical unit.

This guide follows the 19.0 source workflow. Other listed releases received selected comparisons. No runtime transfer or approval was executed for this guide.

Access and roles​

Inventory users can submit requests for transfers they may write and read company-permitted approval history. Inventory managers configure policies and access audit reports and exports.

Internal Transfer Approver is a separate role. A decision maker must also be named as an approver user or belong to a configured approver group on the policy, with the request company active. Internal Transfer Cost Viewer controls access to estimated monetary values, including their export. Internal Transfer Emergency Override requires its dedicated role and a policy that explicitly allows override. The policy’s self-approval prohibition also applies to emergency overrides.

Setup and menu​

Open Internal Transfer Approval Policies under Inventory configuration. Choose company, effective dates, operation type and any warehouse, location, requester, product or product-category scope. Source and destination location matches are exact. Product/category scopes match products present on the transfer; they do not limit the metrics to only those products.

Set Minimum Aggregate Quantity and, with cost-viewer access, Minimum Estimated Value. Each nonzero minimum must be met for the policy to match; equality qualifies. Choose No Approval, Warning Only, or Approval Required, then the timing, permitted approvers, self-approval rule and optional emergency override.

Lower priority numbers win first, followed by greater specificity, newer effective start and lower record ID. Inventory settings can nominate a default policy, but it is considered only after the other policies and must still match its scope and thresholds. Warning Only informs the operator without blocking reservation or validation.

Workflow​

  1. Open an internal transfer and review products, demand, locations, schedule, lots, packages and owners. Inspect its approval status and threshold message.
  2. Enter the approval reason. Select Submit Reservation Approval or Submit Validation Approval, according to the stage shown. Submission can confirm a draft transfer. For validation submission, zero move quantities can be filled from demand before the snapshot is recorded; review the prepared quantities.
  3. The request becomes waiting and configured approvers receive review activities. Open it from Internal Transfer Approvals under Inventory operations or the transfer’s Approvals smart button.
  4. An eligible approver reviews the captured facts and selects Approve or Reject, entering a decision reason. If policy or transfer facts changed, the request becomes stale and must be refreshed from the transfer.
  5. Return to the transfer and perform the native reservation or validation action. The gate checks the current evidence and consumes the approval for that stage when the operation proceeds.
  6. With Before Both, obtain a reservation decision first, reserve the goods, then submit a separate validation request for the resulting transfer facts. A consumed reservation decision does not authorise validation.
  7. Use Print Authorization on an approved request and the Transfer Approval Audit or Transfer Approval Product Audit reports for review. Managers can use Export Transfer Approval Audit for CSV or XLSX, with estimated values available only to cost viewers.

Practice scenario​

In an authorised test database, fictional Northbank Stores moves 20 units between internal locations. Configure a policy for that operation type with a minimum aggregate quantity of 10, Approval Required, Before Both, and a separate approver. Submit a reason, obtain reservation approval and reserve. Then submit and approve validation before completing the transfer. The source-derived expectation is two stage-specific decisions. This scenario was not executed.

Repeat after changing a quantity or destination following submission. The expected result is stale evidence requiring a refreshed request, not reuse of the earlier decision.

Troubleshooting and limitations​

If approval is not required, inspect direction, company, effective dates, every scope and both configured minima. A default policy is not an unconditional catch-all. A visible approval button does not remove server-side role, company or self-approval checks.

For waiting, rejected or stale requests, resolve the decision or refresh the request before proceeding. Changes to product, demand, units, location, schedule, lot/package/owner information or governing policy may invalidate evidence. Emergency override is a reasoned, retained decision, not an unrestricted bypass.

Native cancellation cancels active requests while retaining history. Backorders and materially changed transfers need their own current evidence. The app does not guarantee stock availability or replace native tracking and validation requirements.

Qualified catalogue versions are 15.0, 16.0, 17.0, 18.0, 19.0 and 20.0. Versions 15–16 use older done-quantity fields and view modifiers; 17–18 use their native quantity and rounding APIs. Version 20 adapts unit fields and access definitions. Install the matching major-version build; these comparisons are not runtime certification.

Live Test — Odoo 19.0 · Choose your exact Odoo version in the Corvus catalogue.

Related guides: Stock Reservation Expiry and Inventory Replenishment.