An expiry control is incomplete until the valid unit proceeds, the removal-date-passed serial stays excluded, and the backorder reconciles.
Category: Odoo, ERP & Manufacturing Operations
What changed
On August 11, 2026, Odoo landed a fix on its upstream 19.0 branch for a specific subcontracting receipt failure. A subcontracting receipt is the point where a business receives tracked finished goods produced by an outside supplier. The documented path combined Manufacturing, Subcontracting, serial tracking, expiration dates, a mixed receipt, and a backorder.
In Odoo's reproduction, a subcontractor receipt contained two tracked finished units. One serial had a removal date earlier than the current date. That is the configured point when the unit should leave usable stock, and it can come before the final expiration date. When the user validated the receipt, chose Proceed Except Expired, and created a backorder, the process could fail with an Expected singleton error.
The plain result was a crash instead of a clean split between the accepted unit and the outstanding quantity. According to Odoo's commit explanation, lot IDs placed in the expiry wizard's temporary context leaked into the backorder workflow. They were then assigned across component and finished-product moves where the next method expected a single move.
The fix cleans that temporary context before the next validation step. Its new regression test asserts that the acceptable serial continues through the original subcontracting manufacturing order and that the removal-date-passed serial is not assigned to the backorder manufacturing order.
That is the exact sourced change. It does not show that every Odoo 19 deployment already contains the patch, that expired goods were generally consumed, or that every expiry and backorder path is now covered.
Why operational leaders should care
This is a narrow bug with a precise implementation lesson: an operator's removal-date decision must survive the split into the next receipt, backorder, and manufacturing records.
The expiry warning made the user choose what to exclude. The backorder process then had to preserve that decision while splitting quantities, creating stock moves, and maintaining the relationship to a subcontracting manufacturing order. A temporary value from the first step crossed into the second step and changed how the next records were built.
For an operations team, the useful question is not simply, “Did the warning appear?” It is, “Did the accepted unit, excluded serial, remaining quantity, backorder, manufacturing record, and stock history all end in the expected state?”
This matters when subcontracted products feed customer orders, replenishment, warehouse promises, or an e-commerce catalog. A receipt failure can leave usable stock waiting, an outstanding quantity unclear, and downstream teams unsure whether an order can be released. Those are workflow risks to test; they are not claims that this Odoo fix changed Shopify, accounting, or every connected system.
The exception-to-backorder control map
| Control point | What should remain true | Evidence to retain |
|---|---|---|
| Purchase and Bill of Materials | The vendor, subcontracting Bill of Materials, expected quantity, and component route agree | Purchase order, Bill of Materials, and route configuration |
| Tracked receipt | Each finished unit has the intended serial or lot and date fields | Receipt details before validation |
| Expiry decision | The operator's choice clearly separates the acceptable and removal-date-passed units | Warning, selected action, user, and time |
| Accepted quantity | The valid unit completes without inheriting the excluded serial's state | Completed receipt line and linked stock move |
| Backorder | Only the outstanding quantity remains, without the excluded serial being assigned to it | Backorder quantity and empty or replacement serial assignment |
| Subcontracting lineage | Finished-product and component moves remain linked to the right manufacturing records | Manufacturing order and moves history |
| Downstream availability | Warehouse, order, catalog, reporting, and support views agree on usable and outstanding quantity | Integration logs and reconciled reports |
The table deliberately separates native Odoo evidence from connected-system evidence. The upstream regression test covers the specific Odoo failure. Your Shopify catalog, custom portal, finance workflow, reporting model, or warehouse alert still needs its own acceptance test.
A ten-step implementation checklist
- Record the deployed build. Capture the Odoo version, hosting route, update date, relevant commit or build reference, and installed custom modules. A commit on the upstream
19.0branch is not proof that the running database has it. - Recreate the sourced path in staging. Use a synthetic subcontracted product with tracking and expiration dates enabled, two finished units, and one serial whose removal date has passed.
- Capture the decision boundary. Validate the receipt, record the expiry warning, and use the documented Proceed Except Expired path. Keep the operator and timestamp in the test evidence.
- Verify the acceptable unit. Confirm that the valid serial completes on the intended receipt and appears on the correct subcontracting manufacturing record and stock move.
- Inspect the excluded serial. Confirm that the removal-date-passed serial does not appear on the new backorder manufacturing order or an accepted inventory move.
- Reconcile quantities. The accepted or completed quantity plus the outstanding backorder quantity should equal the original demand without a duplicate or missing unit. Reconcile component consumption separately.
- Trace components and finished goods. For resupply subcontracting, follow the component and finished-product moves through the subcontracting and production locations. Do not sign off from the receipt status alone.
- Exercise custom code. Retest any custom receipt wizard, automated action, server action, barcode flow, connector, or approval that reads lot IDs, date fields, manufacturing orders, or backorders.
- Test connected operations. If Odoo publishes quantities to Shopify or another e-commerce channel, compare catalog availability, checkout readiness, order allocation, warehouse work, reporting, and support views after the exception. If finance or valuation rules depend on the receipt, have finance verify the configured result.
- Assign exception ownership. Name who reviews removal-date exceptions, who releases replacement stock, who resolves a failed backorder, and what evidence allows operations to close the incident.
Risks, limits, and where the hype is not useful
- This fix addresses the documented mixed-serial subcontracting receipt and backorder path on Odoo's
19.0branch. It is not evidence of a general expiration-control failure. - A removal date can occur before the final expiration date. Use your configured fields and quality policy; do not collapse every date into the word “expired.”
- The upstream test proves that the crash is avoided and the removal-date-passed serial is not inherited by the backorder manufacturing order. It does not certify a custom module, integration, accounting setup, or e-commerce sync.
- Updating code without replaying the business exception is weak evidence. Customized databases can change context, record creation, permissions, or integrations around the fixed path.
- This article is operational guidance, not food-safety, regulatory, accounting, or legal advice.
The AorBorC view
The useful boundary is the operator's exception choice: it has to survive the split into the next records. The right response is neither panic nor a blind update. It is a focused regression pack that proves the exception can be handled without losing the valid quantity or the record trail.
AorBorC's Odoo implementation work starts with the operating flow: purchasing, subcontracting, receipts, lots or serials, approvals, stock moves, reporting, and the people responsible when the normal route breaks. Where the standard workflow needs extension, our ERP module development keeps custom behavior testable and close to the records it changes.
For businesses that sell manufactured or subcontracted stock online, our e-commerce systems work also tests the catalog-to-inventory and order-to-warehouse handoffs. A native Odoo fix is one layer; the connected operating system still needs evidence.
Business takeaway
Do not sign off an expiry warning because it appeared. Sign it off when the valid unit moves, the excluded serial stays excluded, the backorder reconciles, and affected dependent records reconcile.
Your next move
Pick one subcontracted product with tracking enabled and replay the mixed-serial exception in staging. If the receipt, backorder, manufacturing order, or downstream quantity cannot be reconciled, plan an Odoo workflow review before the next production update.