[FIX] purchase_ux: complete the pending criterion in purchase matching

[mav-adhoc]

Port of #359 to 19.0. Rebased on 19.0 after #354 was merged, which brought the per document type criterion this branch was missing, so that part is no longer in the diff — only its tests are kept, see 1. What is left are three defects that 19.0 still has.

1. Credit notes (#351, #353, #354) — already merged, tests only

product_qty does not drop with a return, so a line that is already fully billed but has a pending credit (qty_to_invoice < 0) was hidden from the matcher of a credit note. Fixed on this branch by #354 (bed8052); this PR only adds the two regression tests it never got.

2. Over receipt on bills (#359)

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 > 0 as a second term to the in_invoice criterion, the same one 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 quantities qty_to_invoice is qty_received - qty_invoiced, so a confirmed purchase order with no receipt yet gives 0 and every line would be hidden — that is exactly the regression #354 fixed, so both terms have to stay.

3. Orders set as Nothing to Bill

The view already excludes orders forced as No Bill to Receive, but not the other value of force_invoiced_status, even though both mean the order is closed for billing. The exclusion now covers any forced status. Unlike #359, this branch does not need it in the action: the filter lives in the view, which is the better place, so the action only carries the quantity criterion.

4. Orders closed with the Set Invoiced button

button_set_invoiced() stamped invoice_status on the order and zeroed qty_to_invoice on its lines. Both are stored computed fields, so the next recompute undid it. Verified on 19.0: 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 read force_invoiced_status, which the button never set. It now writes that field, which is durable and is what the rest of the module reads.

Its invisible domain never matched on this branch either: purchase orders no longer have the done state on 19.0 (it is the locked boolean now), so the button was unreachable in the form. It is gated on locked now.

Test plan

purchase_ux/tests/test_purchase_matching.py, 8 cases. Bill criterion: confirmed order with no receipt (offered), partial receipt not billed (offered), over receipt 40/41/40 (offered), fully received and billed (not offered), forced invoice status, both values (not offered). Set Invoiced button: order closed, matcher does not offer its lines, and a later change of the received quantity does not bring it back. Credit note criterion: pending refund from a return 600/500/600 (offered), return already credited 600/500/500 (not offered).

Verified locally on 19.0 over the rebased branch: 0 failed, 0 errors of 12 tests. Reverting purchase_ux/models/ and purchase_ux/views/ to 19.0 fails exactly the three that cover what is left in the diff — test_bill_over_receipt, test_bill_set_invoiced_button and the 'no' subtest of test_bill_forced_invoiced_status — and leaves the rest green, the two credit note ones included, since that criterion is already in the branch.

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.

Note for the merge: this touches a view, so it needs bump, not nobump. The line level status of those orders only becomes correct together with #362.

https://www.adhoc.inc/odoo/project.task/72358

[roboadhoc]

[les-adhoc]

@roboadhoc r+ bump

[mav-adhoc]

@roboadhoc retry

[roboadhoc]

@mav-adhoc retry makes no sense when the PR is not in error.

[jcadhoc]

@roboadhoc check

[roboadhoc]

Updated message. No update to pr head.

[mav-adhoc]

@jcadhoc se hace el loco roboadhoc

[jcadhoc]

@roboadhoc r+ bump