**Steps to reproduce:**
- Create a company in Belgium and set the fiscal localisation accordingly.
- In the same company, create a fiscal position in Switzerland, set the foreign tax ID and then generate the taxes for it.
- Install the module account_edi_ubl_cii.
- Create and invoice for a belgian customer, with one product line having a 0% tax.
- Export the invoice as XML.
- Go to taxes, filter by purchase, and make sure that the 0% switzerland tax has a higher sequence than the belgian 0% tax.
- Import the previous invoice XML as a vendor bill.

**Issue:**
After importing the bill, the switzerland tax is used even though the fiscal localisation is belgian, which is wrong as it violates the constraint _validate_taxes_country

**Solution:**
Added a more selective domain to _import_fill_invoice_line_taxes

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

Forward-Port-Of: odoo/odoo#263560
Forward-Port-Of: odoo/odoo#255848

When selling event tickets in POS while offline, the order could be synced later but without creating event registrations (tickets) after a page reload.

Steps to reproduce:
-------------------
* Open a POS session with `pos_event`
* Sell an event ticket
* Switch to offline mode
* Validate payment while offline (order becomes paid but unsynced)
* Reload/close and reopen POS, then reconnect
* Let the order sync

> Observation:
The `pos.order` is created on the backend, but `event.registration` and `event.registration.answer` are missing so tickets are not generated.

Why the fix:
------------
`pos_event` used `order.finalized` as IndexedDB cleanup condition for `event.registration` and `event.registration.answer`. For paid-but-unsynced orders, `finalized` is already true, so those records can be removed from IndexedDB too early. After reload, the order is restored/synced but without its event registration payload.

Implementation:
---------------
Use `order.canBeRemovedFromIndexedDB` instead of `order.finalized` for `event.registration` and `event.registration.answer` retention rules, so records are kept locally until the order is truly synced (server id assigned) or canceled.

Test Note:
---------------
Use case is hard to simulate exactly.
Add a basic unit test to assert both registration models are kept for paid unsynced orders and only removable once synced.

opw-6056079

Forward-Port-Of: odoo/odoo#263912
Forward-Port-Of: odoo/odoo#256615

**Steps to reproduce:**
- Install Accounting and Point of Sale

- In Accounting settings, activate "AvaTax"
- Configure the AvaTax fiscal position and activate "Detect Automatically" option
- Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one

- Go to the settings of a point of Sale
- Activate "Flexible Taxes" and configure "Default" and "Allowed"
- Make sure that AvaTax fiscal position is not allowed
- Do not activate "AvaTax PoS Integration"

- Open a POS session
- Select a customer with an address in the US and without fiscal position
- Check the fiscal position

**Issue:**
The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS.

**Cause:**
We force the use of a fiscal position if it is configured on a customer.
In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected.

**Solution:**
When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax.

opw-6154089




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

**Steps to reproduce:**
- Install Accounting and Point of Sale

- In Accounting settings, activate "AvaTax"
- Configure the AvaTax fiscal position and activate "Detect Automatically" option
- Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one

- Go to the settings of a point of Sale
- Activate "Flexible Taxes" and configure "Default" and "Allowed"
- Make sure that AvaTax fiscal position is not allowed
- Do not activate "AvaTax PoS Integration"

- Open a POS session
- Select a customer with an address in the US and without fiscal position
- Check the fiscal position

**Issue:**
The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS.

**Cause:**
We force the use of a fiscal position if it is configured on a customer.
In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected.

**Solution:**
When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax.

opw-6154089

### Issue:
When importing EDI documents such as Peppol files, Swiss VAT numbers are often provided in a flat format (e.g., CHE530781296TVA), while existing Odoo partners usually store them in the official formatted version (e.g., CHE-530.781.296 TVA)

This mismatch prevents proper partner matching and may create duplicate partners during import

### Cause:
`_retrieve_partner` lacks Swiss-specific VAT normalization logic in `_import_retrieve_customer_from_vat()`
As a result, the matching process fails to:
- match formatted and unformatted Swiss VAT numbers
- properly handle language suffixes such as `TVA`, `MWST`, or `IVA`

If `base_vat` is installed, and the imported XML VAT is `CHE530781296TVA`, a new partner will be created with the structure format  `CHE-530.781.296 TVA`
As the match won't be made new partner will be created at each import

### Steps to reproduce:
- Install `account`
- Create a Vendor (Name: Test CH Vendor, Country: Switzerland, Tax ID: CHE-530.781.296 TVA)
- Import the bill [CH_bill_to_import.xml](https://github.com/user-attachments/files/27202997/CH_bill_to_import.xml) from the ticket 

Before the fix, the existing partner is not matched and a duplicate partner is created

opw-6072239

### Issue:

The `Print Label`, `Register Production`, `Register By-products`and `Register Consumed Materials` are all available in the test types at control point creation.

### Expected behavior:

These test types are only meant for manufacturing operations and are supposed to be hidden by the field domain:
https://github.com/odoo/enterprise/blob/f56aa85b4ad32c5d9ad5593df1366d72e88da0e4/mrp_workorder/models/quality.py#L102-L104 https://github.com/odoo/enterprise/blob/00d6cccd75c402378698a6fd11ee2692f2361c7f/mrp_workorder/models/quality.py#L20-L24

### Cause of the issue:

Since saas-18.1: 5ef007a2116e528b796ebe80fb291ba5f1a94c8f domains are optimised into equivalents SQL clause with better sql performances. This optimization results in the following match for boolean fields: 
`('field', '=', True)` -> `('field', 'in', OrderedSet([True]))` 
`('field', '=', False)` -> `('field', ' not in', OrderedSet([True]))`
Because of these:
https://github.com/odoo/odoo/blob/82b16e8feb3d60a9a3855e3adb3164ae5a6c041d/odoo/orm/domains.py#L1058-L1079 https://github.com/odoo/odoo/blob/82b16e8feb3d60a9a3855e3adb3164ae5a6c041d/odoo/orm/domains.py#L1215-L1236
Now the issue is that the specific `search_method` of the `allow_registration` field is then called with this optimized domain: https://github.com/odoo/odoo/blob/82b16e8feb3d60a9a3855e3adb3164ae5a6c041d/odoo/orm/domains.py#L860-L866 https://github.com/odoo/enterprise/blob/00d6cccd75c402378698a6fd11ee2692f2361c7f/mrp_workorder/models/quality.py#L20-L24
And since `value` is defined as a non empty ordered set in both cases it the search method returns a True leaf as search domain.

opw-5915197

**Issue**
Reducing the PO quantity after performing a partial receipt, in multi-step receipts warehouse
can incorrectly update the remaining receipt quantity.

**Steps to reproduce**
- Setup 2-route receipt warehouse (Inventory > Configuration > Warehouse Management > Warehouses)
- Create a PO for 35 units and confirm it
- Click on receive products, set received quantity to 10 and create a backorder
- Validate the next transfer
- Go back to the PO and change the quantity to 20
- Check the receipt demand
-> The backorder picking demand become 35 instead of 10

**Cause**
Updating the quantity of a purchase order line, also updates the related picking:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L120
It updates the picking associated to the backorder since the other one is done:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L185-L187
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L197
This ultimately calls:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L228
To compute the new demand for the picking, it retrieves the `move_dest`:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L240
To compute `qty_to_push`:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L247-L249
However, since we are in a 2-route receipt setup, `move_dest` is the move from Input to stock for the done picking.
Thus, `qty_to_push` is `20 - 10 = 10` instead of `20 - 35 = -15`

**Solution**
The previous logic assumes a pull flow, where downstream (move_dest_ids) quantities are always up-to-date and can be used as the source of truth to recompute demand.
In push flows (e.g., multi-step receipts), this assumption does not hold. 
To fix this, we instead base the computation on the quantity of the current moves (qty) if nothing has to be attached. 

**Additional information**
Known limitation: this does not address inconsistencies in return flows. When there're returns, units 
define in the pol and the one define in the sum of the picking can diverge, thus this pr won't fix that.

opw-5512172

Forward-Port-Of: odoo/odoo#263294
Forward-Port-Of: odoo/odoo#248626

### Description of the issue/feature this PR addresses: 
**Issue**: During KSeF authentication, some foreign qualified certificates causes a crash with error _"Failed to authenticate with XAdES: 400 Client Error: Bad Request for url: https://api.ksef.mf.gov.pl/v2/auth/xades-signature"_ This is due to Odoo not handling different `SubjectIdentifierType`

**Solution**: Implement a try/except block to safely check for the NIP in the certificate's subject string, defaulting the identifier type to `certificateFingerprint` when the NIP is missing or a ValueError is caught.

### Current behavior before PR:
The `SubjectIdentifierType` is hardcoded as `certificateSubject`, and does not handle `certificateFingerprint` at all. This causes there to be an error when trying to authenticate with the KSeF server using XAdES signature.

### Desired behavior after PR is merged:

The sign_authentication_challenge method will now safely evaluate the subject string. It assigns `certificateSubject` only if the NIP is verified to be in the subject string. If the NIP is absent or a ValueError occurs during parsing, the system safely falls back to using `certificateFingerprint`. This prevents tracebacks and ensures the correct XML payload is sent to the KSeF server.

opw-6125243

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

Forward-Port-Of: odoo/odoo#265390