Click and collect widget is not supported for rental products

Steps to reproduce:
-------------------
* Enable "Click and collect" in setting and set up warehouses
* Create a rental product
* Add a unit of the product in one of the warehouses
* Rent that product for a period
* Go on the website>shop>the product
* The available quantity for the warehouse does not account for the in start/end dates in the eCommerce product page

Observation:
-------------
The implementation of click and collect does not include a sale_renting module, this entails that [click and collect](https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/views/templates.xml#L28-L36) and [openLocationSelector](https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/static/src/js/click_and_collect_availability/click_and_collect_availability.js#L54) don't have any information about the rental periode

The rental date range is shown when the product is possible to rent and the rental period is only set in the  xml file:
https://github.com/odoo/enterprise/blob/1bf7dbcfef2186ee5a08382367fe195efca033dc/website_sale_renting/views/templates.xml#L90

Since openLocationSelector don't have access to the rental period, it can't update the necessary information to work with rental products.
For example, the free_qty should change depending on the rental period.

opw-5365564

**Steps to reproduce:**
* install `account_iso20022` and `l10n_ch`.
* Set Swiss ISO20022 in outbound payments in the Bank journal.
* Create two vendor payments: one with a Swiss QR_iban bank account (CH...) and one with a foreign bank account (DE...).
* Group them into a batch payment and download the XML.

**Observed behavior:**
* Swiss IBAN creditor accounts are rendered as `<CdtrAcct><Id><Othr><Id>` instead of `<CdtrAcct><Id><IBAN>`.
* Foreign IBAN creditor accounts (e.g. DE) correctly use `<IBAN>`.
* UBS and other Swiss banks reject the XML file due to the inconsistency.

**Cause:**
* `_get_CdtrAcct()` delegates to `_is_bank_account_qr_iban()` to decide between `<IBAN>` and `<Othr><Id>`.
* Swiss IBANs with an IID in the range 30000–31999 are classified as QR-IBANs, causing them to fall into the `<Othr><Id>` path even when they are standard IBAN accounts eligible for the `<IBAN>` tag.

**Fix:**
* Override `_get_CdtrAcct()` in the Swiss ISO20022 journal model to always emit `<CdtrAcct><Id><IBAN>` for any IBAN-type account when `payment_method_code == 'iso20022_ch'`, regardless of QR-IBAN classification.
* Non-IBAN accounts (e.g. postal accounts) still fall through to the base implementation using `<Othr><Id>`.

Ref: https://www.bib.eu/uploads/2020/04/Payment_import.pdf

opw-6061266

Steps to reproduce:
1. Create a currency with a non-1 exchange rate with the company's
currency (e.g. VEF with a rate of 0.000005 against USD).
2. Create a pricelist in that currency.
3. Create an event.
4. Create a sale order with the new pricelist.
5. Add a sale order line with a ticket of the event and confirm
the order.
6. Go to the event's page and check the total sales smart button.
7. Check the total sales of the event: it should be equal to the sale
order's total price converted to the company's currency, but it is not,
because of the wrong conversion (it used the inverse of the correct
exchange rate, which is 200000 instead of 0.000005 in our example).

Problem:
The total sales smart button in an event's page shows wrong totals when
sales are in a currency other than the company's currency.

Cause:
The code converts the sale price from the event's currency (which is the
same as the company's currency) to each sale order's currency, while it
should be the other way around (from each sale order's currency to the
event's currency).
https://github.com/odoo/odoo/blob/3cd709172e997f5a726cf3ae85ffcb9965619fcb/addons/event_sale/models/event_event.py#L38

opw-5494790

Steps to reproduce the bug:
- Create a service product "P1":
  - In the Purchase tab:
    - Vendor: Azure Interior
    - Subcontract Service: True
  - UoM: dozen
  - Purchase UoM: unit

- Create a sales order with 1 dozen of P1
  - Confirm -> a purchase order with 12 units of P1 is generated
- Confirm the purchase order
- Go back to the sales order:
  - Update the quantity from 1 to 2 dozen

Problem:
A new purchase order is generated, but with 144 units instead of 12
units. The quantity difference between the old SO quantity and the new
one is computed twice in the purchase order line UoM, in both
`_purchase_increase_ordered_qty` and `_purchase_service_prepare_line_values`:
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L186

Solution:
The `quantity` parameter must be expressed in the SO line UoM, as
described in the documentation of the function `_purchase_service_prepare_line_values`.

https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L178

opw-6049106

Forward-Port-Of: odoo/odoo#255478

__Problem__
Employees could not see their remaining leave days and the view always showed 0 left days. This happened when multiple allocations existed across different years.

The view relied on `min(id)`/earliest allocation logic and a default current-year domain. When the earliest allocation belonged to a previous year:

* The record holding the remaining balance was filtered out by the year domain.
* Expired allocations were still included in totals.

As a result, remaining days were either incorrect or always displayed as zero.

__Fix__
* compute remaining balance on the latest non-expired allocation `max(id)`
* Only sum non-expired allocations when computing the available balance.
* changes in leave subtraction logic:
  * If a leave falls entirely in a non-expired allocation → subtract fully.
  * If it falls entirely in expired allocations → do not subtract.
  * If it spans expired and non-expired allocations → subtract only the portion after the last expiry date.

* When subtracting partial leaves, count only actual working days:
  * Use the employee’s resource calendar (`resource_calendar_attendance`) to get the weekend days
  * Exclude public holidays
* Apply the same proportional logic to hours.

__Result__
* Remaining leave days are now always visible.
* Expired allocations no longer affect current availability.

_Backwards compatibility note:_
* Splitting leaves across expired and non-expired allocations happens on sum(allocations) level, not on the actual leave lines level.

so leaves are not split into two records when they span expired and non-expired allocations. The leave record remains whole, but only the portion that falls into non-expired allocations is counted against the available balance.

__Example__
allocation 2025: 20 days (expires 31 Dec 2025)
allocation 2026: 20 days (expires 31 Dec 2026)
Public holidays: 2 Jan, 31 Dec
weekends: Saturdays and Sundays

Leave: 15 Dec 2025 to 6 Jan 2026 (15 days total)
* 2025 is expired so counting starts from 1 Jan 2026
* Interval days: 1 Jan to 6 Jan = 6 days
* Public holiday on 2 Jan → exclude
* Weekend on 4 Jan and 5 Jan → exclude
* Working days counted: 6 - 3 = 3 days subtracted from 2026 allocation.

report will show:
2025: 20 days allocated, 15 days taken, 0 days left (all expired) 2026: 20 days allocated, 0 days taken (leave not split), 17 days left

-opw-5169606

Click and collect widget is not supported for rental products

Steps to reproduce:
-------------------
* Enable "Click and collect" in setting and set up warehouses
* Create a rental product
* Add a unit of the product in one of the warehouses
* Rent that product for a period
* Go on the website>shop>the product
-> The available quantity for the warehouse does not account for the in start/end dates in the eCommerce product page

Observation:
---------------
The implementation of click and collect does not include a sale_renting module, this entails that click and collect and openLocationSelector has no information about the rental period.
https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/views/templates.xml#L28-L36 

https://github.com/odoo/odoo/blob/20e54e37670ffa569f47663a7e4b8d7de3a4c33c/addons/website_sale_collect/static/src/js/click_and_collect_availability/click_and_collect_availability.js#L54-L61
The rental date range is shown when the product is possible to rent and the rental period is only set in the [xml](https://github.com/odoo/enterprise/blob/1bf7dbcfef2186ee5a08382367fe195efca033dc/website_sale_renting/views/templates.xml#L90) 

Since openLocationSelector don't have access to the rental period, it can't update the necessary information to work with rental products.
For example, the free_qty should change depending on the rental period.


opw-5365564

When we erase a sn/lot on a MO for a product that is tracked by lot, we will be deadlocked.

### Steps to reproduce:
* Create a product tracked by lot and lot_valuated
* Create a BoM for this product
* Create a MO for this product
* Confirm and Produce all
* erase the lot and save -> the MO is deadlock, it's not possible to modify the lot number, nor it's possible to unbuild.

### Current behavior:
A user is able to erase a lot/SN from a MO of a lot_valuated product.

### Expected behavior:
It should not be possible to erase a lot/SN form a MO of a lot_valuated product.

### Observation:
When the MO is done, its valuation will be calculated which in our case, it means, we have to have a lot number. When trying to add a lot/SN of a MO where it has been erased, we will remove the quantities from the previous lot, but in our case, since we don't have one, it will trigger the user error. https://github.com/odoo/odoo/commit/33e192de30526ea7fe320bcaa7a16dac8108feff
This error is not triggered when removing the SN/lot because when we remove the value, it will be update to False which means it will skip _update_svl_quantity():
https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock_account/models/stock_move_line.py#L35-L36
https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock_account/models/stock_move_line.py#L62-L65
This use case is also protected when creating a product tracked by lot but not lot_valuated: https://github.com/odoo/odoo/commit/4963103e5587d36364b8df84d0b3407a1977efdf

opw-6039885

### Issue before this commit:
When a sales order with a product invoiced on delivered quantities is fully delivered and then completely returned the delivered quantity is reset to zero. In this situation, where nothing has been invoiced and nothing remains to be invoiced, the invoice status of the sales order line is incorrectly set to "Fully Invoiced" instead of "Nothing to Invoice".

### Steps to reproduce the issue:
1. Create a new quotation for a storable product.
2. Confirm the order.
3. Validate the delivery of the product.
4. Perform a return for the product
5. Validate that return to simulate a customer return.
6. The sales order details correctly reflect that the delivered quantity and invoiced quantity are both zero. Despite these values—which indicate there is nothing to invoice—the invoice status on the quotation erroneously displays as "fully invoiced".

### Cause of the issue:
The invoice status computation includes a fallback logic that marks a sales order line as "invoiced" when all related stock moves are either done or cancelled. However, this logic does not verify whether any quantity remains effectively delivered. As a result, after a full return, even when qty_delivered = 0, the condition is still met and the line is incorrectly marked as fully invoiced.

### Reason to introduce the fix:
A fully returned sales order line with no delivered and no invoiced quantity should not be considered fully invoiced. The fix ensures that the fallback to "invoiced" only applies when there is a strictly positive delivered quantity, preventing incorrect invoice status after full customer returns.

opw-6014772

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#254871