mark_urbanpiper_prep_order_as_printed() raised ValueError when the
'urbanpiper_printed' flag was already set, to stop the same order from
printing its preparation ticket twice (https://github.com/odoo/enterprise/pull/103894,
Task-5353283).

Accepting an UrbanPiper order fires this RPC from two places for the
same order: synchronously from TicketScreen, and again via the
DELIVERY_ORDER_COUNT bus notification the accept flow itself
broadcasts. Under load, both requests race for the row lock; Odoo's
retrying() replays the loser on lock contention, and by the time it
replays the winner has already committed, so the loser hits the
already-printed branch and raises. The raise is an unhandled
ValueError, so it surfaces as a 500 and fails any tour that accepts
an order (test_frontend.py, test_order_receipt.py),
intermittently and CI-timing-dependent only.

The only caller (pos_store.js: _sendDeliveryOrderForPreparation)
already wraps the RPC in try/catch and treats a caught exception
exactly like a falsy return value: either way it just skips sending
the ticket to preparation. No other code reads or writes
urbanpiper_printed, and no webhook path calls this method, so
returning False is behaviorally identical for every real caller and
safe to make the default.

This also removes the mark_urbanpiper_prep_order_as_printed_patch
monkeypatch added alongside the original raise in test_01_order_flow:
it existed solely to swallow this exact ValueError for that one tour,
which is no longer needed now that the method itself is idempotent.

runbot error: 941514

Forward-Port-Of: odoo/enterprise#125840

Steps to Reproduce:
1. Configure Payment Term (Accounting > Configuration > Payment Terms) containing multiple installments.
2. Create a Customer Invoice with this Payment Term.
3. Post the invoice.
4. Register a payment and fully reconcile one of the installments.
5. Navigate to the customer's Follow-Up Report (Accounting > Reporting > Partner Ledger > Report: Follow-Up Report).
6. Navigate to remaining open installment/account move line for that invoice.
7. Turn On or Off the No Follow-Up toggle for the invoice.

An error occurs when enabling or disabling the No Follow-Up toggle.

Issue:
Enabling or disabling the No Follow-Up toggle on a remaining open installment in the Follow-Up Report raises a server error when the invoice contains multiple installments and one or more installments are already fully reconciled.

Root Cause:
The Follow-Up Report only loads and sends non-fully reconciled account move lines from the JavaScript side through all_line_ids. In action_toggle_no_followup(), when the selected line belongs to an invoice, the code retrieves all receivable/payable lines of the invoice, including fully reconciled installments:

```
move.line_ids.filtered(
    lambda line: line.account_type in ('asset_receivable', 'liability_payable'),
)
```

The method then attempts to map every receivable/payable line to a report line ID using aml_id_to_line_id. Since fully reconciled installments are not present in all_line_ids, they are missing from the mapping dictionary, causing a KeyError when accessing:

`aml_id_to_line_id[line.id]
`

Fix:
Restricted the impacted lines to those present in the report by adding a check that the account move line exists in aml_id_to_line_id before performing the mapping:

```
lambda line: line.account_type in ('asset_receivable', 'liability_payable')
             and line.id in aml_id_to_line_id
```


opw-6245448

Forward-Port-Of: odoo/enterprise#126785
Forward-Port-Of: odoo/enterprise#126156

**Issue**
When rental transfers are enabled and rental pickups/returns are processed through stock pickings, it may become impossible to perform a subsequent rental return through the rental return wizard.

**Steps to reproduce**
- Activate "Rental Transfers" in the settings
- Create a rental product P, tracked by serial number
- Create two serial numbers for P
- Create and confirm a rental order for 2 units of P
- Validate the pickup transfer
- Partially validate the return transfer without creating a backorder
- Open the rental order and click on "Return" 
-> The return wizard opens without any available serial number and validation fails with a serial number-related error.

**Cause**
When clicking on "Return", if there is no pending pickup/return transfer: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/models/sale_order.py#L62-L68 the rental return wizard is opened directly:
https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_renting/models/sale_order.py#L316 No serial number is prefilled in the wizard because `returned_lot_ids` is empty: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L122-L124 This is because `returnable_lot_ids` is empty as well. `returnable_lot_ids` is computed while generating the wizard lines: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_renting/wizard/rental_processing.py#L38 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_renting/wizard/rental_processing.py#L47-L48 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L99-L106 and `returnable_lots` is empty because both `pickedup_lots` and `returned_lots` are. Those fields are currently only populated through the rental wizard flow: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L42-L43 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L160-L161 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L166-L167

Since this flow uses stock pickings instead of the rental wizard, those fields are never updated, preventing the wizard from determining any returnable serial number.

opw-6150305

Forward-Port-Of: odoo/enterprise#119257