[FIX] purchase_stock_ux: cancel remaining must not leave a pending vendor receipt nor a counter-delivery - #365
Open
fw-bot-adhoc wants to merge 1 commit into
Conversation
…ndor receipt nor a counter-delivery When cancelling the remaining qty, lowering product_qty does not always cancel the pending receipt: with a refund return (ticket 124773) a live pending IN remains and inflates the forecast of units to receive, and when the negative move does not net against the pending one (different price/final location) a counter-delivery to the vendor is generated (ticket 124957). We now explicitly cancel the line's open remaining move. In 1, 2 or 3 step receptions the pending qty to receive always lives in the first-step move (vendor->input), which hangs off move_ids and has no downstream; core (_action_cancel) propagates to later moves if needed, so there is no need to walk the chain. The cancel is scoped to genuine forward vendor receipts: exchange-return replacements (a legitimate expected receipt) and open, not-yet-validated vendor returns (origin_returned_move_id, which also hang off move_ids and are not part of the remainder) are excluded. product_qty is not touched, so invoicing (qty_to_invoice) stays intact. Also replace the expensive fields_get() probe in _is_exchange_move_helper with a plain 'is_exchange_move' in self._fields check (O(1), no full field-descriptor build). Tests (test_cancel_remaining.py, over 1/2/3 steps): partial receipt, refund return (124773), preservation of goods in transit, and an open vendor return that must survive cancel remaining (RED without the origin_returned_move_id guard). X-original-commit: 44a1146
Contributor
Author
|
@jcadhoc @les-adhoc cherrypicking of pull request #358 failed. stdout: Either perform the forward-port manually (and push to this branch, proceeding as usual) or close this PR (maybe?).
More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port |
Author
|
@jcadhoc @les-adhoc this forward port of #358 is awaiting action (not merged or closed). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Problem
When cancelling the remaining qty on a purchase order line (
button_cancel_remaining), loweringproduct_qtydoes not always cancel the pending receipt:Fix
After setting
product_qty, explicitly cancel the line's open remaining move, scoped to genuine forward vendor receipts:In 1/2/3-step receptions the pending qty always lives in the first-step move (vendor→input), which hangs off
move_idsand has no downstream; core_action_cancelpropagates to later moves if needed (and never todoneones), so there's no need to walk the chain.product_qtyis not touched, so invoicing (qty_to_invoice) stays intact.The two exclusions matter because returns and exchange replacements also carry
purchase_line_idand thus land inmove_ids; without the guards, an open (not-yet-validated) vendor return would be cancelled along with the remainder.Also replaced the expensive
fields_get()probe in_is_exchange_move_helperwith a plain'is_exchange_move' in self._fieldscheck (O(1), no full field-descriptor build).Tests
test_cancel_remaining.py, parametrized over one/two/three steps:origin_returned_move_idguard; reproduces the over-cancel reported on the client base)All green on a v18 test DB (
0 failed, 0 error of 4 tests).Forward-Port-Of: #358