## Issue:
When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later
A UserError was raised asking to remove the leave even if it should be linked to the first allocation created

## Cause:
The `action_refuse()` method for `hr.leave.allocation` uses the `virtual_leaves_taken` value inside the `_get_consumed_leaves()` function's result
That parameter is calculated for the allocation as far as it state is `validate`, for all the leaves in that time interval, including previously created leaves
The leaves will be allocated to the last allocation created, so the last one can't be removed later
As a result, the allocation is considered as already used by these pre-existing leaves, even if the leave can still be modified to return to the state prior to the allocation's validation

## Steps to reproduce:
- Create an initial Allocation (that should end after the next created Allocation)
- Create a Leave from 22/12/2025 to 31/12/2025
- Create an Allocation including the leave period (01/12/2025 to 31/12/2025)
- Validate, then Refuse

opw-4900686

Fixes Task 5213234

Issue:
In AccountMove method _find_matching_po_and_inv_lines (called when looking for
a subset match of EDI invoice lines with PO lines), the price_unit of a
purchase.order.line is compared to the price_unit of an invoice line.
However, currently the comparisons do not take into account the precision to be
applied to product prices.
In some cases, the invoice line price_unit differs from the price_unit in a PO
line, but by less than the "Product Price" precision. With the current
comparisons this leads to not matching the lines.
This has prevented matching some invoices received via Peppol for at least one
big customer (see Task-5213234)

Steps to reproduce:
- Create an XML document for an EDI UBL invoice with 2 lines; the first line
  has a price_unit 113.57 euros (for example) 
- Create a PO with a reference matching the invoice, and one PO line with a
  price_unit matching the price_unit of the first invoice line (113.57 euros)
- Upload the XML invoice and create a bill from it; during the creation of the
  account.move.line, the price_unit gets a value which is slightly different
  from 113.57 (113.57000000000001) (due to python rounding ?)
- Result: no link is established between the PO and the invoice.

This fix makes sure that the "Product Price" precision is used when comparing
the invoice line price_unit with a PO line price_unit.

opw-5213234

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/789de5eea [REL] 17.0.77 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/d9d0f3181 [FIX] range: invalid sheet name with special character [Task: 5125762](https://www.odoo.com/odoo/2328/tasks/5125762)
https://github.com/odoo/o-spreadsheet/commit/63817f3f1 [FIX] Package: update owl to 2.8.1 [](https://www.odoo.com/odoo/2328/tasks/)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

When you create a product with atleast one variant that has 2 value,
and create a BoM for this product that has 2 lines with each line
having one of the two values, then create a POS order with one unit
of each variant, the cost of the first line not correctly computed.

Steps to reproduce:
-------------------
* Create a prodcut P with one attribute A that has two values A1 and A2
* Create a product C with no attribute and a cost of 10$
* Create a BoM for P with two lines:
  - Line 1: product C, quantity 1, only for attribute value A1
  - Line 2: product C, quantity 2, only for attribute value A2
* Open a PoS session
* Add Product P with attribute value A1 to the order
* Add Product P with attribute value A2 to the order
* Validate the order and close the session
* Go to the order and check the cost of each line
> Observation: The cost are not correct, they should be 10$ and 20$

Why the fix:
------------
Before this fix we were not taking the
`bom_product_template_attribute_value_ids` into account when filtering
the stock moves to consider for the cost computation. This value
represent the attribute values that the product must have for
this BoM line to be considered.

opw-4765234

When creating a new allocation,
selecting "Accrual" with an accrual plan, and then re-selecting "Regular," the accrual plan is registered in the backend,
Flush accrual_plan_id when changing the allocation type.

### **Steps to reproduce:**

1. Create a test database (version 17 or later).
2. Install the `hr_holidays` module.
3. In the Time Off module, navigate to Allocations.
4. Create a new allocation.
5. Select "Accrual Allocation" and assign an accrual plan.
6. Change the allocation type back to "Regular Allocation" and save.
7. Verify the accrual plan is registered in the backend.

**Note:** The accrual_plan_id field is displayed for visibility.

**Before Fix:**
<img width="1897" height="610" alt="before_allocation" src="https://github.com/user-attachments/assets/357c6c1d-3d57-4d2e-bf23-1cf260897aa1" />
<img width="1894" height="477" alt="before" src="https://github.com/user-attachments/assets/af193cd9-2e61-4fa9-8488-927e899ca574" />

```python3
test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 18;
 id |   private_name    | allocation_type | accrual_plan_id 
----+-------------------+-----------------+-----------------
 18 | Before allocation | regular         |               1
(1 row)
```

**After Fix:**
<img width="1898" height="555" alt="after_allocation" src="https://github.com/user-attachments/assets/60702c72-2e16-4a5f-9b48-213f3c845437" />
<img width="1900" height="535" alt="after" src="https://github.com/user-attachments/assets/15cb27fa-f54b-4e98-94c6-77ae92934c9f" />


```python3
test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 19;
 id |   private_name   | allocation_type | accrual_plan_id 
----+------------------+-----------------+-----------------
 19 | after allocation | regular         |                
(1 row)
```

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

**Issue:**
As a user without "Administration / Settings" access, it is not possible to revoke SEPA Mandates that have been used to pay invoices through the customer portal.

**Steps to Reproduce:**
- Enable SEPA Direct Debit payment provider in Test Mode
- Create a mandate for a customer w/ valid IBAN
- Create an invoice for that customer and post it
- Action > Generate a Payment Link, open this in an incognito window
- Pay using SEPA Direct Debit
- Call `_set_done()` on the payment.transaction
- Try to revoke the mandate as a non-admin with "Accounting / Billing"

-> Access Error, can't modify payment.token

**Cause:**
- When SEPA Mandate is revoked, we check for all associated payment tokens (saved payment methods from SEPA Direct Debit payment provider) and deactivate them.
- The check in code isn't called with sudo, so it uses the current user access rights, but only admins can modify the payment tokens in any way.

**Solution:**
- Write to the `linked_tokens` with sudo so we can archive the tokens regardless of user access

opw-5136221