[FIX] purchase_ux: complete the pending criterion in purchase matching - #369
[FIX] purchase_ux: complete the pending criterion in purchase matching#369fw-bot-adhoc wants to merge 1 commit into
Conversation
Two cases were still wrong in the lines offered by the 'Match purchase lines' button: * Over receipt: when the vendor delivers more than ordered, the line ends up fully ordered but not fully billed (ordered 40, received 41, billed 40). The bill criterion product_qty > qty_invoiced gives False and the quantity left to bill was hidden. Add qty_to_invoice > 0 as a second term, the same criterion the native view uses. The first term is still needed for a confirmed purchase order with no receipt yet, where qty_to_invoice is 0 on products controlled on received quantities. * Forced invoice status: a purchase order set as 'No Bill to Receive' / 'Nothing to Bill' kept offering its lines, because neither the filter nor the native view look at force_invoiced_status. Exclude them, on bills and on credit notes: the user already declared that order as nothing left to bill. Add tests for the bill criterion (no receipt, partial receipt, over receipt, fully billed, forced status) and for the credit note one (pending refund from a return, return already credited). * Orders closed with the 'Set Invoiced' button: the button stamped invoice_status on the order and zeroed qty_to_invoice on the lines, both stored computed fields, so the next recompute undid it and neither the matcher nor the lines ever saw the order as closed for billing. Write force_invoiced_status instead, which is what everything else reads. X-original-commit: e67119e
|
|
|
@mav-adhoc @les-adhoc cherrypicking of pull request #359 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 |
you can use 
|
Superseded by #360, the port of #359 to 19.0 that was written by hand before this automatic forward-port existed. It is not a cherry-pick: on 19.0 the exclusion of orders with a forced invoice status belongs in Closing so the fix does not land twice. #360 carries it with the 8 tests adapted to this branch. |
3 participants
Completes the criterion of the lines offered by the Match purchase lines button, on top of #351 and #353.
1. Over receipt was hidden on bills
The bill criterion is
product_qty > qty_invoiced. When the vendor delivers more than ordered, the line ends up ordered = billed but received > billed, so there is a legitimate quantity left to bill and the line disappeared from the matcher (ordered 40, received 41, billed 40 → 1 pending).Fixed by adding
qty_to_invoice > 0as a second term, the same criterion the native view uses (purchase/models/purchase_bill_line_match.py,_select_po_line()). The first term is still needed: on products controlled on received quantitiesqty_to_invoiceisqty_received - qty_invoiced, so a confirmed purchase order with no receipt yet gives 0 — that is the regression #353 fixed. Thein_refundcriterion is untouched.2. The filter ignored
force_invoiced_statusNeither this filter nor the native view read
force_invoiced_status/invoice_status, so an order manually set as No Bill to Receive / Nothing to Bill kept offering its lines: with ordered 10 and billed 0 the first term is still True, andbutton_set_invoiced()only zeroesqty_to_invoice. Setting the status is the documented way to close an order for billing, so those lines are now excluded, on bills and on credit notes alike.Test plan
purchase_ux/tests/test_purchase_matching.py, 7 cases. Bill criterion: confirmed order with no receipt (offered), partial receipt not billed (offered), over receipt 40/41/40 (offered — point 1), fully received and billed (not offered), forced invoice status (not offered — point 2). Credit note criterion: pending refund from a return 600/500/600 (offered), return already credited 600/500/500 (not offered).Verified locally on 18.0: 0 failed, 0 errors of 10 tests. Reverting only
account_move.pyfailstest_bill_over_receiptandtest_bill_forced_invoiced_status, and leaves the other five green.Known limitation, out of scope
A line returned and already credited (ordered 150, net billed 0) still shows as 150 pending on bills. It happens with the previous criterion and with the native one too; whether it is tolerated is a product decision.
https://www.adhoc.inc/odoo/project.task/72358
3. Orders closed with the Set Invoiced button
button_set_invoiced()stampedinvoice_statuson the order and zeroedqty_to_invoiceon its lines. Both are stored computed fields, so the next recompute undid it: right after pressing the button the order reads Nothing to Bill instead of No Bill to Receive, and any later recompute — writing on a line is enough — brings it back to Waiting Bills with the full quantity pending. Neither the matcher nor the line status ever treated those orders as closed, since both readforce_invoiced_status, which the button never set. It now writes that field, which is durable and is what the rest of the module reads. This is the path a mass cleanup goes through, so without it the exclusion of point 2 never applies to it.test_bill_set_invoiced_buttoncovers it: after the button the order keepsforce_invoiced_statusand No Bill to Receive, the matcher does not offer its lines, and a later change of the received quantity does not bring it back. The behaviour was verified on 19.0 (same code); on 18.0 it rides on CI. The line level status of those orders only becomes correct together with #361.Forward-Port-Of: #359