**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

Forward-Port-Of: odoo/odoo#263342

**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

Forward-Port-Of: odoo/enterprise#116626

**Problem:**
change of standard price on a product valued by lot 
and with standard price category does not work

**Steps to reproduce:**
- create a storable product tracked and valued by lot
- set category as standard price
- set a cost of 10 and save
- click on the quantity smart button and then "update quantity"
- add a quantity of 1 in a new lot
- on the product form, change the cost to 12 and save
- reload the page

**Current behavior:**
the cost is back to 10

**Expected behavior:**
it should stay 12

**Cause of the issue:**
when we change the standard_price of the product, 
_change_standard_price() is called from the write method
https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock_account/models/product.py#L293

Inside _change_standard_price(): 
step 1: a new product.value is created
step 2 : we set the standard_price of the lots to be the same 
as the one of the product
https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock_account/models/product.py#L319-L323

In the create method for product.value (step 1), we call _set_value() 
on the moves with a remaining quantity
https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock_account/models/product_value.py#L95
At the end of set_value we call _update_standard_price() on 
our product
https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock_account/models/stock_move.py#L337

Because the product is lot_valuated we update the standard_price 
based on the avg_cost of the product (this is needed because 
for instance if the prod is avco we can not simply use 
_run_average_batch as it is the case for non lot valuated avco 
product, because then the result won't be a weighted average of 
each lot, whereas avg_cost does take this into account) 
https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock_account/models/product.py#L633-L634

To compute the avg_cost, inside _compute_value(), we use 
the total value of each lot
https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock_account/models/product.py#L226

The lots total value is computed inside the _compute_value() 
method of stock.lot. 
In this method, because the product is valued by standard_price
we use the standard price of the lot
https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock_account/models/stock_lot.py#L40
But this value hasn't been updated yet (it will be at the time 
of step 2) so it's still the old value (10 in our case). 

So the avg_cost of the product will also be the old value and 
the standard price will be udpated back the old value

Then, at the end of _change_standard_price() (at the time of step 2)
the standard price of the lots are set based on the standard price 
of the product (so it stays the old value)

**fix:**
Inside _update_standard_price(), if the product is valued by standard 
price we do nothing 
https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock_account/models/product.py#L639-L640
We apply the same logic for the lot_valued product, if it's standard_price
there is nothing to update

opw-5949146

Forward-Port-Of: odoo/odoo#265623
Forward-Port-Of: odoo/odoo#264991

When generating a VAT return with an unclaimed tax amount carried to the
next month, the carryover reimbursement move amounts are computed with
an incorrect ratio.

Steps to reproduce:
- Create and post a bill in May containing a VAT amount.
- Create and post a bill in June containing a VAT amount.
- Create a VAT return for May to carry over the VAT amount to the next
  month.
- Create a VAT return for June, requesting the full VAT amount to be
  reimbursed.
- Validate and send the June VAT return.
- Check the generated reimbursement move

Issue: Line values does not correspond to anything real/tangible.  It
occurs because when computing the ratio for the move we check the last
tax report entry, where we find the amount of tax from the past months
and a line balancing the last month that should not be taken into
account.  The "Balance tax current account (receivable)" line from the
tax closing entry is mistakenly picked up as a tax carried forward line,
throwing off the amounts.

opw-5961836

Forward-Port-Of: odoo/enterprise#117927
Forward-Port-Of: odoo/enterprise#115451

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#265201
Forward-Port-Of: odoo/odoo#256615

Description of the issue/feature this PR addresses:

Searching for records without a binary attachment (e.g., `('binary_field', '=', False)`) previously generated a query using `NOT IN (SELECT res_id FROM ir_attachment...)`. On databases with a large `ir_attachment` table, materializing this entire list of IDs causes a significant performance bottleneck.

Replacing NOT IN with a NOT EXISTS allows PostgreSQL to short-circuit the evaluation as soon as it find a matching document, drastically reducing query execution time.

Current behavior before PR:

Searching for a "false-ish" binary with attachment generates a query with a `NOT IN`, slow when `ir_attachment` is large.

```python
>>> env["ir.ui.menu"].search([("web_icon_data", "!=", False)])
2026-03-06 15:59:51,326 516177 DEBUG odoo19 odoo.sql_db: [1.076 ms] query: SELECT "ir_ui_menu"."id" FROM "ir_ui_menu" WHERE ("ir_ui_menu"."active" IS TRUE AND "ir_ui_menu"."id" IN (SELECT res_id FROM ir_attachment WHERE res_model = 'ir.ui.menu' AND res_field = 'web_icon_data')) ORDER BY "ir_ui_menu"."sequence"  , "ir_ui_menu"."id"   
ir.ui.menu(15, 1, 16)
>>> env["ir.ui.menu"].search([("web_icon_data", "=", False)])
2026-03-06 15:59:54,439 516177 DEBUG odoo19 odoo.sql_db: [0.665 ms] query: SELECT "ir_ui_menu"."id" FROM "ir_ui_menu" WHERE ("ir_ui_menu"."active" IS TRUE AND "ir_ui_menu"."id" NOT IN (SELECT res_id FROM ir_attachment WHERE res_model = 'ir.ui.menu' AND res_field = 'web_icon_data')) ORDER BY "ir_ui_menu"."sequence"  , "ir_ui_menu"."id"   
ir.ui.menu(62, 68, 3, 10, 43, 59, 4, 28, 44, 65, 6, 7, 29, 41, 45, 61, 66, 5, 18, 30, 31, 48, 49, 60, 69, 70, 9, 11, 12, 17, 19, 20, 21, 22, 23, 24, 25, 26, 27, 32, 33, 34, 36, 37, 38, 39, 40, 42, 46, 47, 52, 54, 56, 57, 58, 63, 71, 73, 74, 76, 78, 79, 80, 81, 50, 64, 51, 72, 75, 77, 35, 14, 13, 53, 2, 55, 67, 8)
```


Desired behavior after PR is merged:

Searching for a "false-ish" binary with attachment generates a query with a `NOT EXISTS`

```python
>>> env["ir.ui.menu"].search([("web_icon_data", "!=", False)])
2026-03-06 15:59:04,847 513555 DEBUG odoo19 odoo.sql_db: [0.945 ms] query: SELECT "ir_ui_menu"."id" FROM "ir_ui_menu" WHERE ("ir_ui_menu"."active" IS TRUE AND "ir_ui_menu"."id" IN (SELECT res_id FROM ir_attachment WHERE res_model = 'ir.ui.menu' AND res_field = 'web_icon_data')) ORDER BY "ir_ui_menu"."sequence"  , "ir_ui_menu"."id"   
ir.ui.menu(15, 1, 16)
>>> env["ir.ui.menu"].search([("web_icon_data", "=", False)])
2026-03-06 15:59:08,323 513555 DEBUG odoo19 odoo.sql_db: [0.628 ms] query: SELECT "ir_ui_menu"."id" FROM "ir_ui_menu" WHERE ("ir_ui_menu"."active" IS TRUE AND NOT EXISTS (SELECT 1 FROM ir_attachment WHERE res_model = 'ir.ui.menu' AND res_field = 'web_icon_data' AND res_id = "ir_ui_menu"."id")) ORDER BY "ir_ui_menu"."sequence"  , "ir_ui_menu"."id"   
ir.ui.menu(62, 68, 3, 10, 43, 59, 4, 28, 44, 65, 6, 7, 29, 41, 45, 61, 66, 5, 18, 30, 31, 48, 49, 60, 69, 70, 9, 11, 12, 17, 19, 20, 21, 22, 23, 24, 25, 26, 27, 32, 33, 34, 36, 37, 38, 39, 40, 42, 46, 47, 52, 54, 56, 57, 58, 63, 71, 73, 74, 76, 78, 79, 80, 81, 50, 64, 51, 72, 75, 77, 35, 14, 13, 53, 2, 55, 67, 8)
```



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

Forward-Port-Of: odoo/odoo#265702
Forward-Port-Of: odoo/odoo#252525

### Issue before this commit:
When importing an XML file containing multiple business documents (multiple bodies with a single header), the system correctly split the file into separate attachments but failed to process any document beyond the first one.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Go to Vendor -> Bills
3. Try to upload a xml with multiple bodies and one header
4. See only the first bill is correctly imported

### Cause of the issue:
The splitting logic renamed subsequent attachments with numeric suffixes but then this function incorrectly checked the name of the document.
https://github.com/odoo/odoo/blob/29805eec2b70144edf9441cffe7e69e39fd4ba0e/addons/l10n_it_edi/models/account_move.py#L297-L305
We can not rely only on the name of the document but we need to check also its content.
Refer to the rules for the name of the attachments: https://www.fatturapa.gov.it/export/documenti/Specifiche-tecniche-relative-al-Sistema-di-Interscambio-versione-1.8.4.pdf

In summary what we need in the document (page 9): 

> The unique progressive of the file is represented by an alphanumeric string up to 5 characters long and with allowed values. [az], [AZ], [0-9]. The unique progressive of the file has the sole purpose of differentiating the name of the files transmitted to the Interchange System by the same entity; it does not necessarily have to follow a strict progressive nature and may also present different numbering styles.

### Reason to introduce the fix:
This fix ensures that the function not only checks the name but also the content to be sure that the xml or p7m file contains a valid structure to be registered.

Ticket [link](https://www.odoo.com/odoo/project.task/6072258)
opw-6072258

Forward-Port-Of: odoo/odoo#265079
Forward-Port-Of: odoo/odoo#259887

**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#265200
Forward-Port-Of: odoo/odoo#255848

Steps to reproduce:
1- Install Accounting
2- Go to [Accounting -> Assets] and create a new asset with start date 1/1/2025
3- Specify the fixed asset account and confirm the asset
4- Open [Accounting -> Lock Dates]
5- Set a Lock date on everything with the date 31/12/2025 and save
6- Cancel the asset, set to draft and confirm again

Issue:
`Invalid Operation: The remaining value on the last depreciation line must be 0`

Expected behavior:
Should not be able to set to draft once the asset is cancelled

Why this happens:
Commit 66db1d5 introduced a new condition on the `Set to Draft` button which results in the button being visible when it should not be. If a Lock Date is set after an asset is confirmed, the acquisition and any depreciation entries are effectively finalized in the accounting history. Allowing a user to "Set to Draft" at that point would involve deleting or modifying entries in a closed period, which violates accounting integrity.

opw-6152777

Forward-Port-Of: odoo/enterprise#116900

Currently, an error occurs when a user selects a shift template on a planning slot.

**Steps to Reproduce:**

 - Install the `Planning` module with demo data.
 - Create a `Resource Time Off` record with `start` and `end date` separated by more than 
  `1400 days (around 3.9 years)`, and Set the Working Hours field to Standard 40 hours/week.
 - Go to `Planning` > `Configuration` > `Shift Templates`, open an `existing record` or create 
   a `new one`, and set the `Working Days` to more than 1 day.
 - Create a new `planning slot`, Assign the resource `Abigail Peterson`, and select the above 
   `shift template`.

`AttributeError: 'bool' object has no attribute 'replace'`

This error occurs because when the user sets the shift template, the compute method runs to 
calculate the start and end datetimes [1]. It computes the end datetime by adding the template 
duration in working days from the given start datetime using the resource working calendar within 
a searchable range of around 1400 days [2]. During this computation, leaves and non-working days 
are skipped [3]. If no valid working interval is found within the searchable range, then it returns 
False [4], which raises the error [5].

This commit ensures that if plan_days returns False, the computation falls back to the previously 
calculated end date.

[1]: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L662-L671

[2]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L826-L835

[3]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L533-L537

[4]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L835

[5]- https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L653-L654

sentry-7472958590

Forward-Port-Of: odoo/enterprise#117926
Forward-Port-Of: odoo/enterprise#117073

Steps to produce:
---
- Install `website_sale`, `l10n_ca` & `accountant` modules with demo data.
- Switch to a `Canadian (CA) company.`
- Go to Settings and enable` Discounts, Loyalty & Gift Cards`.
- Go to` Website > eCommerce > Loyalty > Discount & Loyalty.`
- Create a new program > Set Program Type to Discount Code > Under Conditional Rules, set Minimum Purchase to 0 > Under Rewards, choose Discount on Order.
- Go to `website > configuration > websites` > Create a new website for the CA company > Set it as default (first in sequence).
- Create new product > Set Sales Taxes to` 14.975% GST + QST` > Publish the product.
- Open the website in an incognito window > Add the product to the cart > Apply the discount code.
- In the main tab > Go to Website > eCommerce > Orders > Open the corresponding order > In the Other Info tab, change the fiscal position to Quebec (QC) > Click to update taxes.

Issue:
---
- The tax on the discount line is split into: 14.975% GST + QST & 9.975% QST.

Root cause:
---
- When a discount is applied in the cart, the discount line initially carries split taxes: 5% GST and 9.975% QST.
- After changing the fiscal position to Quebec (QC), the system replaces 5% GST with 14.975% GST + QST because 5% GST is present in replace of 14.975% GST. so at [1] it replaces 5% GST with 14.975% GST and do nothing for 9.975% QST.
- In 17.0, the discount line directly uses 14.975% GST + QST (no tax splitting), so this issue does not occur.
- In 18.0, at [2], taxes are explicitly split and added to the base line, and the same split taxes are reused during grouping. This leads to multiple taxes being displayed on the sale order line.

Fix:
---
- Avoid splitting taxes on the discount line in the sale order.
- Keep the original tax structure intact to prevent duplication after fiscal position changes.

[1]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/account/models/partner.py#L151-L156
[2]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/sale_loyalty/models/sale_order.py#L296

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

Forward-Port-Of: odoo/odoo#265233
Forward-Port-Of: odoo/odoo#262147

Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well.

For example, setting the scan of lot/serial as mandatory didn't prevent the user to set automatically a SN on consummed component by generating a lot/serial on the produced product or by clicking on "Produce All" button.

This commit adds some conditions to avoid to update barcode lines in case they should depending of the config.

This commit also fixes a related issue where the MRP operation type's config wasn't used at all when a MO is created directly from the Barcode app.
As the config is get from the MO's picking type and no MO exists when a new one is created from the Barcode app, there is no MO's config returned in the data send by the server.
To fix that, the config is now updated clientside when the data are fetched after a save.

[Task-5420762](https://www.odoo.com/odoo/project/966/tasks/4655907/project.task/5420762)
[opw-5223507](https://www.odoo.com/odoo/project/49/tasks/5223507)

Forward-Port-Of: odoo/enterprise#117816
Forward-Port-Of: odoo/enterprise#113318

### Steps to reproduce:
- Download 'Point of Sale' and 'Contacts' app
- Create a customer with a pricelist that includes a percentage discount
- Create a shop with the following properties:
    - Default preset = 'Takeout' with a standard 40hr/week schedule
    - Payments = 'Card' and 'Customer Account'
    - Pricelists = a 'Default' and the discounted pricelist
- Create a POS order (without choosing a customer)
- Add products to the order, and select 'Customer Account' payment method
- Select the created customer
    * Pricelist applies → Order total decreases.
    * Payment now exceeds total → Negative change shown.
- Disable 'Invoice' checkbox.
- Click 'Validate' → Show popup 'No cash statement found for this session.'
- Again click 'Customer Account' → Add another payment line (negative).
- Process the order payment
- Close Session
- Try to create an invoice for the order
> Error: Entry not balanced

### Cause of Issue:
When 'Validate' is clicked for the first time and `syncAllOrders()` is called, `serializeForORM()`
clears the `_dirty` state tracking after the serialization. https://github.com/odoo/odoo/blob/418b103dab782d81a33d2a7afd8ec3767d7a82df/addons/point_of_sale/static/src/app/services/pos_store.js#L1501-L1534

When the 'No cash statement found' error occurs, the backend rolls back the changes made to the
order lines.

Then, since the `order.lines` weren't marked as dirty (no changes occured to them) and `payment.ids`
were marked as dirty, when 'Validate' is clicked for the second time, the js side doesn't send the
`order.lines` again, so the backend uses the existing, undiscounted lines.

The mismatch happens because while the product lines are undiscounted, the `payment.ids` are
correct (because a new 'Customer Account' line was added, so `payment.ids` were sent again).
Hence, `amount_total` and `amount_paid` were calculated with discounts applied, while individual
`line.price_unit` values remained at list price, resulting in invoice line amounts not matching
the amount paid and causing "entry not balanced" errors during invoice generation.

### Fix:
Preserved the `_ dirty` state commands, ensuring that when the order is reserialized on retry,
the line data are included in the second `sync_from_ui` payload.

opw-6080597

Forward-Port-Of: odoo/odoo#259636

**Steps to reproduce:**
* Install a Norwegian localization (e.g. **l10n_no**).
* Set up a company with a valid Norwegian VAT number (e.g. **NO179728982MVA** or just **179728982**).
* Create a customer invoice and send it via **Peppol** (format: **UBL BIS Billing 3.0.12**).

**Observed behavior:**
* The EDI document creation fails with: "The VAT number of the supplier does not seem to be valid. It should be of the form: NO179728982MVA."
* The error occurs even when the VAT number is correctly formatted.

**Cause:**
* Commit 186ad1db refactored the party node building by removing `_get_party_node()` and replacing it with granular `_ubl_add_party_*_nodes()` methods. The Norwegian VAT normalization block (introduced in task-5448941) that set `supplierCompanyID` on the party node lived inside `_get_party_node()` and was not ported to the new architecture, leaving `supplierCompanyID` never set.
* The NO-R-001 constraint in `_invoice_constraints_peppol_en16931_ubl()` reads the VAT from `party_node.get('supplierCompanyID')`, which now always returns `None`, causing `mva.is_valid(None)` to return `False` and the constraint to always fail.

**Fix:**
* Port the missing normalization logic into `_ubl_add_accounting_supplier_party_tax_scheme_nodes()`: prepend `NO` and append `MVA` to the VAT if not already present, then assign the normalized value to `party_node['supplierCompanyID']` and update `PartyTaxScheme[0]/CompanyID` when a VAT node exists.
* Handle the `NO` case in `_ubl_add_party_legal_entity_nodes()` to write the normalized VAT into `PartyLegalEntity/CompanyID`.

opw-6215400

Forward-Port-Of: odoo/odoo#264679

Steps to produce:
---
- Install `website_sale`, `l10n_ca` & `accountant` modules with demo data.
- Switch to a `Canadian (CA) company.`
- Go to Settings and enable` Discounts, Loyalty & Gift Cards`.
- Go to` Website > eCommerce > Loyalty > Discount & Loyalty.`
- Create a new program > Set Program Type to Discount Code > Under Conditional Rules, set Minimum Purchase to 0 > Under Rewards, choose Discount on Order.
- Go to `website > configuration > websites` > Create a new website for the CA company > Set it as default (first in sequence).
- Create new product > Set Sales Taxes to` 14.975% GST + QST` > Publish the product.
- Open the website in an incognito window > Add the product to the cart > Apply the discount code.
- In the main tab > Go to Website > eCommerce > Orders > Open the corresponding order > In the Other Info tab, change the fiscal position to Quebec (QC) > Click to update taxes.

Issue:
---
- The tax on the discount line is split into: 14.975% GST + QST & 9.975% QST.

Root cause:
---
- When a discount is applied in the cart, the discount line initially carries split taxes: 5% GST and 9.975% QST.
- After changing the fiscal position to Quebec (QC), the system replaces 5% GST with 14.975% GST + QST because 5% GST is present in replace of 14.975% GST. so at [1] it replaces 5% GST with 14.975% GST and do nothing for 9.975% QST.
- In 17.0, the discount line directly uses 14.975% GST + QST (no tax splitting), so this issue does not occur.
- In 18.0, at [2], taxes are explicitly split and added to the base line, and the same split taxes are reused during grouping. This leads to multiple taxes being displayed on the sale order line.

Fix:
---
- Avoid splitting taxes on the discount line in the sale order.
- Keep the original tax structure intact to prevent duplication after fiscal position changes.

[1]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/account/models/partner.py#L151-L156
[2]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/sale_loyalty/models/sale_order.py#L296

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

Forward-Port-Of: odoo/odoo#265233
Forward-Port-Of: odoo/odoo#262147

**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

Forward-Port-Of: odoo/odoo#263342

**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

Forward-Port-Of: odoo/enterprise#116626

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#265201
Forward-Port-Of: odoo/odoo#256615

Description of the issue/feature this PR addresses:

Searching for records without a binary attachment (e.g., `('binary_field', '=', False)`) previously generated a query using `NOT IN (SELECT res_id FROM ir_attachment...)`. On databases with a large `ir_attachment` table, materializing this entire list of IDs causes a significant performance bottleneck.

Replacing NOT IN with a NOT EXISTS allows PostgreSQL to short-circuit the evaluation as soon as it find a matching document, drastically reducing query execution time.

Current behavior before PR:

Searching for a "false-ish" binary with attachment generates a query with a `NOT IN`, slow when `ir_attachment` is large.

```python
>>> env["ir.ui.menu"].search([("web_icon_data", "!=", False)])
2026-03-06 15:59:51,326 516177 DEBUG odoo19 odoo.sql_db: [1.076 ms] query: SELECT "ir_ui_menu"."id" FROM "ir_ui_menu" WHERE ("ir_ui_menu"."active" IS TRUE AND "ir_ui_menu"."id" IN (SELECT res_id FROM ir_attachment WHERE res_model = 'ir.ui.menu' AND res_field = 'web_icon_data')) ORDER BY "ir_ui_menu"."sequence"  , "ir_ui_menu"."id"   
ir.ui.menu(15, 1, 16)
>>> env["ir.ui.menu"].search([("web_icon_data", "=", False)])
2026-03-06 15:59:54,439 516177 DEBUG odoo19 odoo.sql_db: [0.665 ms] query: SELECT "ir_ui_menu"."id" FROM "ir_ui_menu" WHERE ("ir_ui_menu"."active" IS TRUE AND "ir_ui_menu"."id" NOT IN (SELECT res_id FROM ir_attachment WHERE res_model = 'ir.ui.menu' AND res_field = 'web_icon_data')) ORDER BY "ir_ui_menu"."sequence"  , "ir_ui_menu"."id"   
ir.ui.menu(62, 68, 3, 10, 43, 59, 4, 28, 44, 65, 6, 7, 29, 41, 45, 61, 66, 5, 18, 30, 31, 48, 49, 60, 69, 70, 9, 11, 12, 17, 19, 20, 21, 22, 23, 24, 25, 26, 27, 32, 33, 34, 36, 37, 38, 39, 40, 42, 46, 47, 52, 54, 56, 57, 58, 63, 71, 73, 74, 76, 78, 79, 80, 81, 50, 64, 51, 72, 75, 77, 35, 14, 13, 53, 2, 55, 67, 8)
```


Desired behavior after PR is merged:

Searching for a "false-ish" binary with attachment generates a query with a `NOT EXISTS`

```python
>>> env["ir.ui.menu"].search([("web_icon_data", "!=", False)])
2026-03-06 15:59:04,847 513555 DEBUG odoo19 odoo.sql_db: [0.945 ms] query: SELECT "ir_ui_menu"."id" FROM "ir_ui_menu" WHERE ("ir_ui_menu"."active" IS TRUE AND "ir_ui_menu"."id" IN (SELECT res_id FROM ir_attachment WHERE res_model = 'ir.ui.menu' AND res_field = 'web_icon_data')) ORDER BY "ir_ui_menu"."sequence"  , "ir_ui_menu"."id"   
ir.ui.menu(15, 1, 16)
>>> env["ir.ui.menu"].search([("web_icon_data", "=", False)])
2026-03-06 15:59:08,323 513555 DEBUG odoo19 odoo.sql_db: [0.628 ms] query: SELECT "ir_ui_menu"."id" FROM "ir_ui_menu" WHERE ("ir_ui_menu"."active" IS TRUE AND NOT EXISTS (SELECT 1 FROM ir_attachment WHERE res_model = 'ir.ui.menu' AND res_field = 'web_icon_data' AND res_id = "ir_ui_menu"."id")) ORDER BY "ir_ui_menu"."sequence"  , "ir_ui_menu"."id"   
ir.ui.menu(62, 68, 3, 10, 43, 59, 4, 28, 44, 65, 6, 7, 29, 41, 45, 61, 66, 5, 18, 30, 31, 48, 49, 60, 69, 70, 9, 11, 12, 17, 19, 20, 21, 22, 23, 24, 25, 26, 27, 32, 33, 34, 36, 37, 38, 39, 40, 42, 46, 47, 52, 54, 56, 57, 58, 63, 71, 73, 74, 76, 78, 79, 80, 81, 50, 64, 51, 72, 75, 77, 35, 14, 13, 53, 2, 55, 67, 8)
```



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

Forward-Port-Of: odoo/odoo#265702
Forward-Port-Of: odoo/odoo#252525

**Steps to reproduce:**
* Install a Norwegian localization (e.g. **l10n_no**).
* Set up a company with a valid Norwegian VAT number (e.g. **NO179728982MVA** or just **179728982**).
* Create a customer invoice and send it via **Peppol** (format: **UBL BIS Billing 3.0.12**).

**Observed behavior:**
* The EDI document creation fails with: "The VAT number of the supplier does not seem to be valid. It should be of the form: NO179728982MVA."
* The error occurs even when the VAT number is correctly formatted.

**Cause:**
* Commit 186ad1db refactored the party node building by removing `_get_party_node()` and replacing it with granular `_ubl_add_party_*_nodes()` methods. The Norwegian VAT normalization block (introduced in task-5448941) that set `supplierCompanyID` on the party node lived inside `_get_party_node()` and was not ported to the new architecture, leaving `supplierCompanyID` never set.
* The NO-R-001 constraint in `_invoice_constraints_peppol_en16931_ubl()` reads the VAT from `party_node.get('supplierCompanyID')`, which now always returns `None`, causing `mva.is_valid(None)` to return `False` and the constraint to always fail.

**Fix:**
* Port the missing normalization logic into `_ubl_add_accounting_supplier_party_tax_scheme_nodes()`: prepend `NO` and append `MVA` to the VAT if not already present, then assign the normalized value to `party_node['supplierCompanyID']` and update `PartyTaxScheme[0]/CompanyID` when a VAT node exists.
* Handle the `NO` case in `_ubl_add_party_legal_entity_nodes()` to write the normalized VAT into `PartyLegalEntity/CompanyID`.

opw-6215400

__
## Short functional explanation of the error
When setting attendances on several consecutive days for a flexible employee, with an overtime ruleset containing a single rule. This rule being based on week and quantity.
When regenerating overtimes for this ruleset, the overtime hours generated isn't correct.

## Reproduction Steps
1. Create an employee. In the Payroll tab, set a start date for their contract. Set Work Entry Source as Attendances. Set their Working Hours as a flexible schedule. Set their weekly hours at 40.
2. Create an Overtime Ruleset. Add a single rule, based on Quantity, if the worked hours on a `Week` differs `from the amount defined on the contract`. Check Pay Extra Hours and leave the Work Entry Type to use as Overtime Hours.
3. Go back to the employee. In Settings, set the Overtime Ruleset field as the new Overtime Ruleset you just created.
4. Create 5 attendances, each from 8 am to 6 pm, from Monday to Friday.
5. Go to the Overtime Ruleset you just created and click on Regenerate Overtimes.
6. Go back to Attendances. Search for your employee, and click on the list view.

### Expected behavior
The employee's schedule is 40 hours per week. They worked 50 hours. 10 hours should be considered as Worked Extra Hours.

### Unexpected behavior
18 hours are considered as extra hours.

## Origin of the issue
To compute the expected duration of the day, we run: https://github.com/odoo/odoo/blob/7fc5edc29f854d619dbcb5fcc3503fb18ca05335/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L303-L304 where `schedule['work']` will contain intervals on 5 consecutive days, from 8 am to 4 pm.
However, the last day of the employee's attendances isn't contained in these intervals. As a result, `period_schedule` will contain 4 days (the common days between the employee's Attendance days and `schedule['work']` ) and thus, `expected_duration` will be set at 36 hours instead of 40.
In the case where overtimes are computed based on hours from the 
contract, for flexible employees, the expected hours are the ones
indicated on their schedule.

__
opw-6131543

Forward-Port-Of: odoo/odoo#263335

Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well.

For example, setting the scan of lot/serial as mandatory didn't prevent the user to set automatically a SN on consummed component by generating a lot/serial on the produced product or by clicking on "Produce All" button.

This commit adds some conditions to avoid to update barcode lines in case they should depending of the config.

This commit also fixes a related issue where the MRP operation type's config wasn't used at all when a MO is created directly from the Barcode app.
As the config is get from the MO's picking type and no MO exists when a new one is created from the Barcode app, there is no MO's config returned in the data send by the server.
To fix that, the config is now updated clientside when the data are fetched after a save.

[Task-5420762](https://www.odoo.com/odoo/project/966/tasks/4655907/project.task/5420762)
[opw-5223507](https://www.odoo.com/odoo/project/49/tasks/5223507)

Forward-Port-Of: odoo/enterprise#117816
Forward-Port-Of: odoo/enterprise#113318

### Steps to reproduce:
- Download 'Point of Sale' and 'Contacts' app
- Create a customer with a pricelist that includes a percentage discount
- Create a shop with the following properties:
    - Default preset = 'Takeout' with a standard 40hr/week schedule
    - Payments = 'Card' and 'Customer Account'
    - Pricelists = a 'Default' and the discounted pricelist
- Create a POS order (without choosing a customer)
- Add products to the order, and select 'Customer Account' payment method
- Select the created customer
    * Pricelist applies → Order total decreases.
    * Payment now exceeds total → Negative change shown.
- Disable 'Invoice' checkbox.
- Click 'Validate' → Show popup 'No cash statement found for this session.'
- Again click 'Customer Account' → Add another payment line (negative).
- Process the order payment
- Close Session
- Try to create an invoice for the order
> Error: Entry not balanced

### Cause of Issue:
When 'Validate' is clicked for the first time and `syncAllOrders()` is called, `serializeForORM()`
clears the `_dirty` state tracking after the serialization. https://github.com/odoo/odoo/blob/418b103dab782d81a33d2a7afd8ec3767d7a82df/addons/point_of_sale/static/src/app/services/pos_store.js#L1501-L1534

When the 'No cash statement found' error occurs, the backend rolls back the changes made to the
order lines.

Then, since the `order.lines` weren't marked as dirty (no changes occured to them) and `payment.ids`
were marked as dirty, when 'Validate' is clicked for the second time, the js side doesn't send the
`order.lines` again, so the backend uses the existing, undiscounted lines.

The mismatch happens because while the product lines are undiscounted, the `payment.ids` are
correct (because a new 'Customer Account' line was added, so `payment.ids` were sent again).
Hence, `amount_total` and `amount_paid` were calculated with discounts applied, while individual
`line.price_unit` values remained at list price, resulting in invoice line amounts not matching
the amount paid and causing "entry not balanced" errors during invoice generation.

### Fix:
Preserved the `_ dirty` state commands, ensuring that when the order is reserialized on retry,
the line data are included in the second `sync_from_ui` payload.

opw-6080597

Forward-Port-Of: odoo/odoo#259636

Steps to produce:
---
- Install `website_sale`, `l10n_ca` & `accountant` modules with demo data.
- Switch to a `Canadian (CA) company.`
- Go to Settings and enable` Discounts, Loyalty & Gift Cards`.
- Go to` Website > eCommerce > Loyalty > Discount & Loyalty.`
- Create a new program > Set Program Type to Discount Code > Under Conditional Rules, set Minimum Purchase to 0 > Under Rewards, choose Discount on Order.
- Go to `website > configuration > websites` > Create a new website for the CA company > Set it as default (first in sequence).
- Create new product > Set Sales Taxes to` 14.975% GST + QST` > Publish the product.
- Open the website in an incognito window > Add the product to the cart > Apply the discount code.
- In the main tab > Go to Website > eCommerce > Orders > Open the corresponding order > In the Other Info tab, change the fiscal position to Quebec (QC) > Click to update taxes.

Issue:
---
- The tax on the discount line is split into: 14.975% GST + QST & 9.975% QST.

Root cause:
---
- When a discount is applied in the cart, the discount line initially carries split taxes: 5% GST and 9.975% QST.
- After changing the fiscal position to Quebec (QC), the system replaces 5% GST with 14.975% GST + QST because 5% GST is present in replace of 14.975% GST. so at [1] it replaces 5% GST with 14.975% GST and do nothing for 9.975% QST.
- In 17.0, the discount line directly uses 14.975% GST + QST (no tax splitting), so this issue does not occur.
- In 18.0, at [2], taxes are explicitly split and added to the base line, and the same split taxes are reused during grouping. This leads to multiple taxes being displayed on the sale order line.

Fix:
---
- Avoid splitting taxes on the discount line in the sale order.
- Keep the original tax structure intact to prevent duplication after fiscal position changes.

[1]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/account/models/partner.py#L151-L156
[2]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/sale_loyalty/models/sale_order.py#L296

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

Forward-Port-Of: odoo/odoo#265233
Forward-Port-Of: odoo/odoo#262147

**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

Forward-Port-Of: odoo/odoo#263342

**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

Forward-Port-Of: odoo/enterprise#116626

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#265201
Forward-Port-Of: odoo/odoo#256615

### Steps to reproduce:
- Download 'Point of Sale' and 'Contacts' app
- Create a customer with a pricelist that includes a percentage discount
- Create a shop with the following properties:
    - Default preset = 'Takeout' with a standard 40hr/week schedule
    - Payments = 'Card' and 'Customer Account'
    - Pricelists = a 'Default' and the discounted pricelist
- Create a POS order (without choosing a customer)
- Add products to the order, and select 'Customer Account' payment method
- Select the created customer
    * Pricelist applies → Order total decreases.
    * Payment now exceeds total → Negative change shown.
- Disable 'Invoice' checkbox.
- Click 'Validate' → Show popup 'No cash statement found for this session.'
- Again click 'Customer Account' → Add another payment line (negative).
- Process the order payment
- Close Session
- Try to create an invoice for the order
> Error: Entry not balanced

### Cause of Issue:
When 'Validate' is clicked for the first time and `syncAllOrders()` is called, `serializeForORM()`
clears the `_dirty` state tracking after the serialization. https://github.com/odoo/odoo/blob/418b103dab782d81a33d2a7afd8ec3767d7a82df/addons/point_of_sale/static/src/app/services/pos_store.js#L1501-L1534

When the 'No cash statement found' error occurs, the backend rolls back the changes made to the
order lines.

Then, since the `order.lines` weren't marked as dirty (no changes occured to them) and `payment.ids`
were marked as dirty, when 'Validate' is clicked for the second time, the js side doesn't send the
`order.lines` again, so the backend uses the existing, undiscounted lines.

The mismatch happens because while the product lines are undiscounted, the `payment.ids` are
correct (because a new 'Customer Account' line was added, so `payment.ids` were sent again).
Hence, `amount_total` and `amount_paid` were calculated with discounts applied, while individual
`line.price_unit` values remained at list price, resulting in invoice line amounts not matching
the amount paid and causing "entry not balanced" errors during invoice generation.

### Fix:
Preserved the `_ dirty` state commands, ensuring that when the order is reserialized on retry,
the line data are included in the second `sync_from_ui` payload.

opw-6080597

Forward-Port-Of: odoo/odoo#259636

### Steps to reproduce:

- In the settings enable dropshipping
- Create a storable product P, enable the dropshipping and set a vendor
- Create and confirm a sale order for a field service
- Open the related task > Products > Add 1 unit of P
- Go back to the sale order > an RFQ has been created
#### > The delivered quantity of P is set to 1

### Cause of the issue:

Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83
provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237
The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198
Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute).

Fix:

The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167

opw-6104326

Forward-Port-Of: odoo/enterprise#117727
Forward-Port-Of: odoo/enterprise#115760

**Steps to reproduce:**
- Create a flexible 32h/week calendar (8h/day, 4 days)
- Assign it to an employee with the Default Ruleset
- Create attendances: 8h on Monday, Tuesday, Friday, and Saturday (32h total, matching the weekly budget)
- Select the list view and go to the month of the attendances
- Employee shows 16:00 Worked Extra Hours (8h on Fri + 8h on Sat)

**Cause:**
`resource.calendar._attendance_intervals_batch` generates work intervals for flexible calendars by front loading the weekly hour budget onto the first days of the week (Mon 8h, Tue 8h, Wed 8h, Thu 8h for a 32h calendar), But days beyond the budget (Fri, Sat, Sun) get zero hours.

The two overtime rule paths relies on these synthetic intervals:

1) The quantity rule: `_get_daterange_overtime_undertime_intervals_for_quantity_rule()` computed `expected_duration` by intersecting the synthetic schedule with each day. For Fri/Sat the intersection was empty (expected = 0) -> all worked hours counted as overtime.

https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L302-L304

**update** solved by: https://github.com/odoo/odoo/pull/265120/changes/94d4bfffa053cd78ce07ff07ab14b53e8d931053

2) The timing rule: `_get_rules_intervals_by_timing_type()` derived "work_days" from the synthetic schedule and inverted them to get "non_work_days". (Fri, Sat, Sun) were classified as non-working days, therefore, any attendance on those days triggered full overtime.

https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L421-L433

**Solution:**
For flexible calendars in the overtime rule consumer:
- Quantity rules: read expected hours directly from the calendar's `hours_per_day` / `hours_per_week` instead of the synthetic schedule intervals, subtracting any leaves in the period
- Timing rules: treat the entire attendance date range (minus leaves) as potential work days, so that `non_work_days` is empty for flexible employees (they can work any day of the week)

opw-6067063

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

Forward-Port-Of: odoo/odoo#263840

this pr fixes 3 bug, as all are closely related.

  Step to reproduce (hide is_custom attr in kiosk mode):
  - have two attributes A and B
  - A has only 1 attribute value with is_custom = True
  - B can have any two value ( ex. gender: male/female)
  - use it on a product  and make it available in POS for kiosk
  - start kiosk and open that product

  Observation:
  - we do not get option to select option from A but the heading is visible
  - when we select from B, Add to cart is disabled.

  Cause:
  - we do not allow attribute values with is_custom = True in kiosk
  - but we display the attribute regardless
  - the Add to cart btn depends on `selectedValues`, which requires
  value from each attribute, in this case, we are not seletion anything from A
  - so it is disabled

  Fix:
  - we introduced  `attributesToDisplay` which will hide heading in case of single
  custom value for any attribute
  - for Add to cart, wenow do not expect value from `is_custom`  attribute values.

   Allow product with 1 attr which is `is_custom` to be
   configurable in configs other than kiosk) correct fix for commit

   Step to reproduce
  - have attributes A
  - A has only 1 attribute value with is_custom = True
  - use it on a product and make it available in POS
  - start pos and open that product

  Observation:
  - we do not get option to select add text for A

  Cause:
  - in pos, we consider product to be configurable only it has more than 1
  attributes, which misses is_custom attr

  Fix:
  - we backport commit[1] and also considers its side effect by introducing
  `isProductConfigurable` for pos_self_order, which will still avoid
  `is_custom` attrs for kiosk

  [1] https://github.com/odoo/odoo/commit/5155c77a03ed2ff6c914eac41cc81ccb34b1f3c7

  Empty page is displayed if product has only `is_custom` attribute value
  and other attribute with type other then 'no_variant' for combo item

   Step to reproduce
  - have attributes A and B
  - A has only 1 attribute value with is_custom = True
  - B has two values with type "always"
  - use it on a product and add that product in combo item and make it available
    in Kisok
  - start kiosk and open that combo and select that product

  Observation:
  - we do not get option to select

  Cause:
  - `availableAttributeValue` only show `no_variant` and non `is_custom` attribute
     values in attributeSelection component.

  Fix:
  - before mounting Attributeselection component, we check if product has required
    attribute or not.

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

Forward-Port-Of: odoo/odoo#265238
Forward-Port-Of: odoo/odoo#257880

**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

Forward-Port-Of: odoo/enterprise#116626

[FIX] website: improve carousel accessibility
    
    To improve keyboard accessibility on carousels, the indicators container
    is not focusable anymore, and the indicators themselves now only have
    one focusable button at a time.
    The tab order is thus: previous button > active indicator > next button.
    (The previous and next button may both appear before.)
    You can still navigate among indicators with the left and right arrows,
    which also moves the focus to the newly targetted indicator.
    
    Note that other accessibility improvements remain to be done on the
    carousels (add a pause/play button on auto-sliding carousels, place the
    buttons before the carousel slide in the tab order, add some aria
    attributes (roledescription, live), adaptative labels...).

[FIX] website: make focus visible on carousel arrows
    
    When focusing manually (with tab / shift+tab) the previous/next arrows
    in carousels, it is hard to follow where the focus is, because there is
    no outline and the contrast is too small.
    
    This commit adds a specific outline if the button is `:focus-visible`
    (with both black and white to work on any background).

[IMP] website: pause carousel on focus within
    
    Carousels are paused on hover (or touchstart), but if the focus is
    inside one, it won't pause. That can make it hard to navigate within
    interactive carousels during the sliding interval (e.g. the dynamic
    products, which by default has 4 different products with 3 different
    focusable links/buttons).
    This commit applies the same behavior on focusin as Bootstrap's default
    on mouseover, and on focusout as on mouseout.

[IMP] website: support home/end keys on carousels

    When the focus is in a carousel, pressing the "home" key displays the
    first slide and pressing the "end" key displays the last slide.

task-5470023

Forward-Port-Of: odoo/odoo#244939

Currently, after validating a transaction with a manual operation, the
aml resulting from the manual operation can still be selected and
matched with other transactions.

Steps to reproduce:
- Create a transaction for 500 dollars
- Create a manual counterpart line for the bank statement line with
  label "test123" and validate
- Create another transaction of -1000 dollars and label "test123"

Issue: The manual counterpart line matched before is being suggested
against the new transaction. The perfect match reconciliation model will
reconcile the manual counterpart line with the new bank statement line.

Analysis:
During the retrieval of possible aml to match we only look at the aml
reconciliation state. Manual counterpart lines created during the
validation of a previous statement line are still selectable candidates,
causing false positive matches in automated reconciliation models.
Test in Enterprise: https://github.com/odoo/enterprise/pull/115847

opw-6045050

Forward-Port-Of: odoo/odoo#264522
Forward-Port-Of: odoo/odoo#262295

Steps to produce:
---
- Install `website_sale`, `l10n_ca` & `accountant` modules with demo data.
- Switch to a `Canadian (CA) company.`
- Go to Settings and enable` Discounts, Loyalty & Gift Cards`.
- Go to` Website > eCommerce > Loyalty > Discount & Loyalty.`
- Create a new program > Set Program Type to Discount Code > Under Conditional Rules, set Minimum Purchase to 0 > Under Rewards, choose Discount on Order.
- Go to `website > configuration > websites` > Create a new website for the CA company > Set it as default (first in sequence).
- Create new product > Set Sales Taxes to` 14.975% GST + QST` > Publish the product.
- Open the website in an incognito window > Add the product to the cart > Apply the discount code.
- In the main tab > Go to Website > eCommerce > Orders > Open the corresponding order > In the Other Info tab, change the fiscal position to Quebec (QC) > Click to update taxes.

Issue:
---
- The tax on the discount line is split into: 14.975% GST + QST & 9.975% QST.

Root cause:
---
- When a discount is applied in the cart, the discount line initially carries split taxes: 5% GST and 9.975% QST.
- After changing the fiscal position to Quebec (QC), the system replaces 5% GST with 14.975% GST + QST because 5% GST is present in replace of 14.975% GST. so at [1] it replaces 5% GST with 14.975% GST and do nothing for 9.975% QST.
- In 17.0, the discount line directly uses 14.975% GST + QST (no tax splitting), so this issue does not occur.
- In 18.0, at [2], taxes are explicitly split and added to the base line, and the same split taxes are reused during grouping. This leads to multiple taxes being displayed on the sale order line.

Fix:
---
- Avoid splitting taxes on the discount line in the sale order.
- Keep the original tax structure intact to prevent duplication after fiscal position changes.

[1]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/account/models/partner.py#L151-L156
[2]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/sale_loyalty/models/sale_order.py#L296

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

Forward-Port-Of: odoo/odoo#265233
Forward-Port-Of: odoo/odoo#262147

### Issue before this commit:
When importing an Italian electronic vendor bill using the AssoSoftware standard, pension fund taxes (Cassa Previdenziale) are not applied to the invoice lines.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_witholding
2. Change VAT number of IT company with the one in the xml
3. Go to Taxes > 4%F.Pens. > Advanced Options and change Pension Fund Type with TC02
4. Import xml of the ticket in vendor bills
5. P.Fund tax is not assigned

### Cause of the issue:
The issue is caused by the following line:
https://github.com/odoo/odoo/blob/669b9b84f4d5c8765dc4b451d5da6a95dbb9ded8/addons/l10n_it_edi_withholding/models/account_move.py#L247 Currently, the parser strictly expects the optional <RiferimentoTesto> tag alongside <TipoDato>AswCassPre</TipoDato>. However, several third-party software providers generate valid XML files containing only the  AswCassPre block without any optional child tags.

### Reason to introduce the fix:
Ensure that the pension fund tax mapped to the line's VAT rate is correctly applied whenever the AswCassPre data type is present, even if the optional reference tags are omitted.

opw-6189225

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

Forward-Port-Of: odoo/odoo#264083

Before this commit, finding a bom for a recordset of `products` involved looping over all the boms and it will loop over all the `product_variant_ids` of `bom.product_tmpl_id` if the bom's `product_id` is NULL. This approach might loop over variants which we are not trying to find a bom for. In additon to that, due to the fact that multiple boms might have the same `product_tmpl_id`, this approach might consider the same variants in the inner loop redundantly even though we matched the variant with a bom in a previous itration.

Worst case, this might result in a time complexity of $O(N * M)$ where N is the number of boms and M is the number of variants.

To improve the performance, I only considered the variants given in the paramater `products` and in addition to that, I created a new dictionary mapping a `product_tmpl_id` to its bom if the bom doesn't have a variant set. By doing this, I can loop over the `products` given and if it doesn't have a bom set then it will be set to the one its template had taken from the previos loop.

In a method call with the following constraints
    - **2** products the method was finding a bom for
    - The 2 products had the same template and the template contained **550** active variants
    - The boms were only related to the template rather than the variants themselves.

| Input Size | Before | After |
| :--- | :--- | :--- |
| 100 | 0.78s | 0.03s |
| 1000 | 8.53s | 0.11s |
| 10000 | 80.99s | 0.73s |

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

Forward-Port-Of: odoo/odoo#247465

Issue is really similar to commit 21877c09863222a237fe99334787ac46935dcca4 except here the compensations 
amls are created in _stock_account_prepare_anglo_saxon_in_lines_vals
because of a difference between bill price and product cost

**Steps to reproduce:**
- create storable product with category standard auto
- on the category, set an account in the field 'price difference account'
- set a cost of 10
- set a purchase tax
- confirm a PO for 1 @ 15 and validate receipt
- create bill, set a date, save
- on the Bill set the total tax at 100 (it's bellow 'untaxed amount'
on the bottom right of the bill and should be 2.25 before you
change it, if the tax is 15%)
- confirm the bill 

**Current behavior:**
tax was reset to 2.25

**Expected behavior:**
It should stay 100 as it was manually set

**Cause of the issue:**
The total tax amount is computed based on the tax lines 
in Journal Items
https://github.com/odoo/odoo/blob/2744396733bb3ad60813e9e093d67192c0d38b36/addons/account/models/account_move.py#L1171
So the problem is actually that a recomputation of the balance
of the tax account.move.line (the one with the account "tax paid" in 
journal items) is triggered when we confirm the Bill.

That's because:
 When we confirm the bill, 
_stock_account_prepare_anglo_saxon_in_lines_vals() creates 
two amls : 
- one debiting 5 on the account set in the field 'price difference 
account'
- one crediting 5 in the stock interim received account
(This makes sense and is there to realign with the fact that, on the 
account move linked to the svl, the amount credited from stock 
interim received is rightfully 10 because that's cost of the product 
and it's a standard price product)

When we create those amls from,  the create method 
from account.move.lines calls super() inside a context manager 
calling _sync_dynamic_lines().
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move_line.py#L1628-L1635
the yield of sync_dynamic_lines() is inside a context manager
calling _sync_tax_lines.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3250
Therefore, the first half of sync_tax_lines() (untill the yield) is ran 
before the call to super and the rest (from the yield) is ran 
after the call to super. 
Because we added two lines in the account.move, get_changed_lines
will return those 2 new line and because there is a tax_ids on the new lines
round_from_tax will be False.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3034-L3041
Therefore we won't reach continue.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3055-L3059
And the tax line will be recomputed using 
_prepare_tax_line()
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3065

Here is why there is a tax_ids on the new lines : 
The field is precompute so if we don't set a value for 
it, _compute_tax_ids will be ran to compute it.
As the account move on which the lines are added 
is a bill, the tax_ids will the supplier_tax_id of the product.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move_line.py#L898-L901

**fix**
There is no need for a tax_ids on these lines as they 
are not meant to (and should'nt) impact the taxes.

opw-6014710

Forward-Port-Of: odoo/odoo#263306

The delivery transfer for a product tracked by serial number is not linked to the POS order when there is no available stock. When validating a POS delivery in real time, stock can split the transfer into a completed picking and a backorder (e.g. one line fully delivered with lots, another serial-tracked line with no stock and no serial number).

Steps to reproduce:
-------------------
* Setup two products: one tracked by qunatity with some quantity on-hand an other tracked by SN but no quantity on-hand
* Open Pos
* Sell in one order, both products without providing SN
* Validate payment
* Open Inventory: two deliveries sould exist under Inventory Overview of PoS Orders

> Observation:
The first picking shows the POS order as Source Document but the backorder has no source document and is not linked to the POS order.

Why the fix:
------------
Pos Origin (Source Document, POS order, session) was only written on the pickings returned by `_create_picking_from_pos_order_lines`, which did not include pickings created during `_action_done()`. Extend the write to the initial pickings and their backorders so every transfer stays tied to the originating `pos.order`.

opw-6090606

Forward-Port-Of: odoo/odoo#264803
Forward-Port-Of: odoo/odoo#259370

Currently, an error occurs when users click on View GROSS/PPH21/JHT/JP History to see historical payslip line values.

Steps to Reproduce:
 - Install the `l10n_id_hr_payroll` module with demo data.
 - Switch to the `Indonesian` company.
 - Go to `Employees` and open an `existing record or create a new one`.
 - Click on `GROSS/PPH21/JHT/JP History` button.

`ValueError: External ID not found in the system: hr_payroll.act_contribution_reg_payslip_lines`

The issue occurs because, in [this commit], the act_contribution_reg_payslip_lines window action 
was removed. However, when viewing historical lines, and it still tries to retrieve this action using 
its XML ID [1] and then updates its domain, context, and views. As a result, it raises an error due 
to the missing XML ID.

This commit ensures that the method returns a standalone window action dictionary instead of 
relying on the removed window action record.

[this commit]: http://github.com/odoo/enterprise/pull/112571/changes/7094cdc033591258cae7c7df46888c29eaae6248

[1]- https://github.com/odoo/enterprise/blob/103500a805d1ffc1185ed639d613c2d1ede492cb/l10n_id_hr_payroll/models/hr_employee.py#L17-L24

sentry-7489148694

Forward-Port-Of: odoo/enterprise#117683

__
## Short functional explanation of the error
While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and
hr_work_entry_attendance are both installed.
When setting an attendance for an employee that has a check-in date but no check-out date, and running the scheduled action `Automatically check-out employees`, an `expected singleton` error occurs.

## Reproduction Steps
1. Install hr_work_entry_attendance.
2. Create an Employee. In the Payroll tab, set a start date for the contract. In the Settings tab, make sure their timezone is set to Brussels, and set the Overtime Ruleset field to Default Ruleset.
3. In Settings, check the Automatic Check-out box.
4. Go to Attendances. Create an attendance for the employee you just created. Set a Check-in date to 8 am on April 17th, for example, and leave the check-out field empty.
5. Open Scheduled Actions. Search the action Automatically check-out employees and click Run Manually.

### Expected behavior
The attendance check-out should be set at the end of April 17th.

### Unexpected behavior
An error occurs:
`Expected singleton: hr.attendance.overtime.line(39, 40)`

## Origin of the issue
When the attendance goes over several days, we set the check-out date to:
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L618 This is a Naive date. However, it will later be considered as a UTC date. Because the employee's timezone is Brussels, this time will be transformed to 2 am next day when we retrieve attendance intervals. This will result in the creation of overtime entries for both days, causing the Expected Singleton error.
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L687 https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L667-L672 In our case, `self.check_in` = April 17th at 06:02:00 and `self.check_out` = April 17th at 23:59:59. Converted, we will obtain April 17th at 08:02:00 and April 18th at 1:59:59.
Because of that, at the return:
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L706 We will return a dict containing 2 intervals: one for 17th April and one for 18th April.
We will then create overtime entries with such attendances: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L333 leading to the creation of 2 different overtimes for the same attendance.
So, when we retrieve the overtime for that attendance: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L185, We get the 2. Thus when trying to access their status with: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L191 An Expected Singleton Occurs.
__
opw-6036064

Forward-Port-Of: odoo/enterprise#115828

This PR updates owl to version 3 and adapts the codebase accordingly. A compatibility layer
has been introduced to ease the transition. However, for some breaking changes, such a compatibility
layer wasn't possible.

Migration guide: https://odoo.github.io/owl/documentation/v3/owl/migration_owl2_to_owl3.html

OWL3 documentation: https://odoo.github.io/owl/documentation/v3/owl/

Community PR: https://github.com/odoo/odoo/pull/247747

Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Achraf <abz@odoo.com>
Co-authored-by: Alex Kühn <aku@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Bastien Pierre <ipb@odoo.com>
Co-authored-by: Jean Schoenlaub <jesc@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
Co-authored-by: Stephane Vanmeerhaeghe <stva@odoo.com>

__
## Short functional explanation of the error
While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and
hr_work_entry_attendance are both installed.
When setting an attendance for an employee that has a check-in date but no check-out date, and running the scheduled action `Automatically check-out employees`, an `expected singleton` error occurs.

## Reproduction Steps
1. Install hr_work_entry_attendance.
2. Create an Employee. In the Payroll tab, set a start date for the contract. In the Settings tab, make sure their timezone is set to Brussels, and set the Overtime Ruleset field to Default Ruleset.
3. In Settings, check the Automatic Check-out box.
4. Go to Attendances. Create an attendance for the employee you just created. Set a Check-in date to 8 am on April 17th, for example, and leave the check-out field empty.
5. Open Scheduled Actions. Search the action Automatically check-out employees and click Run Manually.

### Expected behavior
The attendance check-out should be set at the end of April 17th.

### Unexpected behavior
An error occurs:
`Expected singleton: hr.attendance.overtime.line(39, 40)`

## Origin of the issue
When the attendance goes over several days, we set the check-out date to:
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L618 This is a Naive date. However, it will later be considered as a UTC date. Because the employee's timezone is Brussels, this time will be transformed to 2 am next day when we retrieve attendance intervals. This will result in the creation of overtime entries for both days, causing the Expected Singleton error.
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L687 https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L667-L672 In our case, `self.check_in` = April 17th at 06:02:00 and `self.check_out` = April 17th at 23:59:59. Converted, we will obtain April 17th at 08:02:00 and April 18th at 1:59:59.
Because of that, at the return:
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L706 We will return a dict containing 2 intervals: one for 17th April and one for 18th April.
We will then create overtime entries with such attendances: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L333 leading to the creation of 2 different overtimes for the same attendance.
So, when we retrieve the overtime for that attendance: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L185, We get the 2. Thus when trying to access their status with: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L191 An Expected Singleton Occurs.
__
opw-6036064

### **Steps to Reproduce:**
1) Install sale_renting_planning, hr_holidays with demo data.
2) Create a public holiday for Standard 40 hours/week
3) Create a service product with below configuration:
- check Plan Service as Projector click on internal link and check
   `Sync Shifts and Rental Orders`.
4) Planning>Configuration>Materials for projector 1 and 2 remove working time.
5) create a rental order for this product during public holiday and click on
   confirm.


### **Error:**
```
ValidationError:
This Sales Order can't be confirmed. No resources are available for the shifts in: Test.
```
### **Root Cause:**
while evaluating resource availability during a rental confirmation from [_planning_slot_vals_list_per_sol](https://github.com/odoo/enterprise/blob/a65723cae215495f0d18cb64b3da36ae6f06affd/sale_renting_planning/models/sale_order_line.py#L30-L117), it retrieved all leaves overlapping the rental period.

If any of those leaves were global leaves(`resource_id=False`), then `all_resource_leave` is set to `True` at [1].

This forcefully marked all available resources as unavailable. It failed to check if the global leave actually belonged to the specific `calendar_id` of the available resources. which leads to blocking fully flexible resources or resource with different working calendar.

[1]- https://github.com/odoo/enterprise/blob/a65723cae215495f0d18cb64b3da36ae6f06affd/sale_renting_planning/models/sale_order_line.py#L57-L60

### **Fix:**
- Update the `resource.calendar.leaves` search domain to explicitly filter for global leaves that have no `calendar_id` or that share a `calendar_id` with the available resources.
- Modify the leave processing loop so that calendar-specific global leaves are only applied to resources operating on that exact calendar, rather than indiscriminately blocking all resources.

**opw-6166749**

Steps to reproduce:

**Setup**
1. Install Work Entries (which will install the other necessary modules)
2. Create a new employee with a fully fixed working schedule
3. Make sure their contract date is set (preferably in the past)
4. Ensure that the employee and working schedule are in a timezone that has a positive UTC offset
5. Ensure that "Automatic Check-Out" is enabled in Attendances

**Reproduction**
1. Create an attendance for your employee that falls right before a non-working day 
a. Make sure you do this so it spills over into the next day and will be picked up by the cron. I did this by going to the previous Friday and having the attendance start that morning. 
b. The date has to be after the employee's contract has begun
3. Remove the check-out time so the attendance is still running
4. Go into "Scheduled Actions" and manually run the cron
5. Observe the traceback

In the "Automatic Check-Out" scheduled action for Attendances, we attempt to calculate the correct check-out time for attendances that are over the set hour tolerance. To do this, we temporarily set the check-out time of the attendance to 11:59PM of the date of check-in. When we set this, in timezones with a positive UTC offset, the time will spill over into the next day. This causes two overtime records to be temporarily generated when normally, only one is generated. Ths causes issues when a function in teh Work Entries module is ran, as it checks the status of the overtime lines. Since there are two, we get a singleton error here, as it only expects one overtime line. This fix corrects this by ensuring that the write method is not called on the attendance record, utilizing a temporary variable instead, and preventing the multiple overtimes from ever being generated.

[opw-6198323](https://www.odoo.com/odoo/project/49/tasks/6198323?debug=assets)

**Issue:**
The account_online_payment module overrides `action_draft` to raise a UserError for sepa_ct payments belonging to a batch with a `payment_online_status` = 'pending' or 'accepted'.
This blocks the bank statement unreconciliation process. When `delete_reconciled_line` is called, it tries to set payments to draft and re-post them, despite it being an internal process not a manual user modification.

**Steps to reproduce:**
- Setup a 'sepa_ct' payment method on a bank journal.
- Create a bill with a vendor with a trusted bank account.
- Create a payment for that bill with a 'sepa_ct' payment method.
- Add the payment to a batch.
- Manually set the `payment_online_status` = 'pending'.
- Create a bank transaction and reconcile it with the batch.
- Try to unreconcile the lines on the transaction
- Result: UserError 'You cannot modify a payment that has already been sent to the bank.'

**Fix:**
Pass a context flag to `action_draft` during the unreconciliation flow so that the validation is skipped when the call originates from the internal unreconcile flow.

OPW-6080464

**Steps to produce:**
- Install `sale_mrp_renting`.
- Enable `Rental Transfers` from settings.
- Create a rental product.
- Create two variants of the product.
- Create a BoM for one variant and set its type to `Kit`.
- Create a rental order using the other variant.
- Try to confirm the order.

**Issue:**
In versions 17 and 18, a UserError is raised-
```
The unit of measure Units defined on the order line doesn't belong to the same
category as the unit of measure False defined on the product. Please correct
the unit of measure defined on the order line or on the product, they should
belong to the same category.
```

From version 18.2 onward, a different error occurs
```
ZeroDivisionError: float division by zero
```

**Root cause:**
In versions 17 and 18:  At [1], since the BoM is created for a different variant , no BoM is found for the selected variant. As a result, when `_compute_quantity` is called at [2], the `bom.product_uom_id` is empty, which leads to the `UserError` from  `_compute_quantity` method. In version 18.2+:  At [1], as the BoM is empty. Then at [3], `_compute_kit_quantities` is called with an empty BoM, and at [4], this results in a division by zero error.

**Solution:**
Skip the computation when no BoM is found and directly return the quantity to avoid both the `UserError` and the `ZeroDivisionError`.

[1]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L13
[2]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L20
[3]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L21
[4]
https://github.com/odoo/odoo/blob/91b09dbea5c8a306b5e9d2120466777f0248b360/addons/mrp/models/stock_move.py#L676

**opw-6082434**

**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

Forward-Port-Of: odoo/enterprise#116626

### Issue before this commit:
When importing an Italian electronic vendor bill using the AssoSoftware standard, pension fund taxes (Cassa Previdenziale) are not applied to the invoice lines.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_witholding
2. Change VAT number of IT company with the one in the xml
3. Go to Taxes > 4%F.Pens. > Advanced Options and change Pension Fund Type with TC02
4. Import xml of the ticket in vendor bills
5. P.Fund tax is not assigned

### Cause of the issue:
The issue is caused by the following line:
https://github.com/odoo/odoo/blob/669b9b84f4d5c8765dc4b451d5da6a95dbb9ded8/addons/l10n_it_edi_withholding/models/account_move.py#L247 Currently, the parser strictly expects the optional <RiferimentoTesto> tag alongside <TipoDato>AswCassPre</TipoDato>. However, several third-party software providers generate valid XML files containing only the  AswCassPre block without any optional child tags.

### Reason to introduce the fix:
Ensure that the pension fund tax mapped to the line's VAT rate is correctly applied whenever the AswCassPre data type is present, even if the optional reference tags are omitted.

opw-6189225

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

Forward-Port-Of: odoo/odoo#264083

## Issue
When creating a job application with a new email address, a `res.partner` is created with both its name and email set to the email address, even if a `partner_name` is provided.

## Steps to reproduce
1. Install *Recruitment* (`hr_recruitment`) and *Contacts* (`contacts`)
2. In Recruitment, create a job application:
    - Any Subject
    - Name N
    - Email E
3. Save the job application
4. Go to Contacts
5. **The partner created from the job application has both its name and email set to the Email E used to create the job application.**

## Cause
The `_inverse_partner_email` passes the email address to `find_or_create` to create the new res.partner:

https://github.com/odoo/odoo/blob/fc58ff23f491a2063b10ffcd6393a08b90dc7975/addons/hr_recruitment/models/hr_applicant.py#L317-L324

This method is implemented to parse both a name and an email address in the same string.

https://github.com/odoo/odoo/blob/fc58ff23f491a2063b10ffcd6393a08b90dc7975/odoo/addons/base/models/res_partner.py#L937-L945

We can thus provide both the `partner_name` and the `email_from` to the method to create a user with a name and an email address properly set.

## POS tests modifications
Before this first commit, some partners in `hr_recruitment` demo data were created with their email address as their name. This is the case, for example, for "Johan Duck", whose name was set to `coincoin@gmail.example.com`.

<img width="627" height="86" alt="260296" src="https://github.com/user-attachments/assets/e4bab843-8ba3-4930-af20-ca8603983929" />

In the POS tours, the list of loaded partners is limited to 100 partners and ordered by their order count (which is often null), __and their name__. 

https://github.com/odoo/odoo/blob/e7345340efbd66473da70ccf6680181b158047ce/addons/point_of_sale/models/pos_config.py#L845-L865

By "renaming" the partners from `hr_recruitment`, they started appearing higher up in the list because their name now starts with capital letters whereas their email began with lower letters, which are sorted after capital letters by the `ORDER BY` SQL clause. As a result, partners from multiple tours were pushed out of the 100 first partners, meaning they were no longer loaded during the tours, causing the tests to fail.

One solution, which is already used in other tests, is to give the test partners names that make them appear higher in the partner list, ensuring they remain within the first 100 loaded partners.



opw-6111598

Forward-Port-Of: odoo/odoo#260296

Steps to reproduce
1. Create a quotation
2. From the list view, select it and click Actions > Send an email
3. Pick the quotation template and send
4. The order stays in 'draft'

Issue
The Actions menu calls `action_quotation_send` with
`hide_default_template=True`:
https://github.com/odoo/odoo/blob/38734e4bc7d841a30524a2bc17fc94c9a83b5aa0/addons/sale/views/sale_order_views.xml#L1128-L1131
which skips the branch that sets `mark_so_as_sent` in context:
https://github.com/odoo/odoo/blob/38734e4bc7d841a30524a2bc17fc94c9a83b5aa0/addons/sale/models/sale_order.py#L1068-L1071

Without that flag, neither `message_post` (single order) nor the
mass-mail path (multi order) transitions the order to 'sent'. The
flag cannot be set unconditionally in `action_quotation_send` because
the same method also opens the composer for non-quotation emails
(e.g. `website_sale` cart recovery), which must stay in 'draft'.

Detect the quotation template at send time in `_action_send_mail`
and add `_message_mail_after_hook` for the mass-mail path.

opw-5248931

Steps to reproduce:
- Activate Anglo-Saxon accounting
- Create a product with track inventory and an automated inventory valuation product category
- Define MTO on the product
- Add this product to an Analytic Distribution Model (i.e. Legal)

- Create a SO for this product
- Create and confirm the PO related to it, the Analytic account is set on the PO.
- Confirm the reception of the product
- This creates a Stock valuation layer with the Analytic account
- Confirm the SO
- Confirm the delivery of the product
- This creates a Stock valuation layer with the Analytic account too
- Create the Invoice

Issue:
Missing analytic account on the 110300 Stock Interim (Delivered) creating unabalanced analytic accounting

Other:
test_report_invoice_items_anglo_saxon_automatic_valuation
introduced in this PR https://github.com/odoo/odoo/pull/205777
checks that in a project's analytic report, the values based
on cogs lines are displayed in the cost section.
With this fix, both cogs lines will have an analytic account
so their impact on the project analytic report will even out.
This made the test fail.
To keep the benefit of this test, we simulate that the user manually
removes the analytic account on some of the cogs lines
(those targetting stock interim received).


opw-6060567

1. Apply the below diff.
2. Login using the same account in two independent tabs (e.g. one regular tab, and a private one).
3. In the first tab, change the account password.
4. In the second tab, go to `/web/binary/upload_attachment` (any `type='http', auth='user'` controller would do) => 500 error.

> AttributeError: 'HttpDispatcher' object has no attribute 'env'

```
diff --git a/odoo/http.py b/odoo/http.py
index b0fd6197aea8..1ea817ec85cd 100644
--- a/odoo/http.py
+++ b/odoo/http.py
@@ -2309,7 +2309,7 @@ class HttpDispatcher(Dispatcher):
         """
         if isinstance(exc, SessionExpiredException):
             session = self.request.session
-            was_connected = session.uid is not None
+            was_connected = True
             session.logout(keep_db=True)
             response = self.request.redirect_query('/web/login', {'redirect': self.request.httprequest.full_path})
             if was_connected:
```

It is necessary to apply the diff because most places that raise `SessionExpiredException` also pro-actively `logout()`, i.e. they reset `session.uid` and when the exception reaches handle-error `was_connected` is always `False`. For the bug to occur, we need a way to be in the `was_connected == True` case but we found no way in standard Odoo (this also explains how this bug is still present, 2 years later). The diff is the easiest way we found to reproduce it.

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

Currently, an error is produced when sending invoices to MyInvois if the invoice number uses a year-range sequence.

**Steps to Reproduce:(v-19.0)**
1. Install the `accountant` and `l10n_my_edi` modules (with demo data).
2. Switch to "MY Company"(Malaysian company).
3. Enable "_Quick Encoding_" for Customer Invoices in Settings.
4. Create a customer invoice with customer "_MY Company_", set a Malaysian classification code and taxes on the invoice line, and confirm the invoice.
5. Set the invoice back to Draft and modify the invoice number with a year-range sequence (e.g., INV/2025-2026/00001), then confirm it again.
6. Open the invoice list view and click **"Send to MyInvois"**.

**Error:**
`ValueError: not enough values to unpack (expected 4, got 2)`

The `_get_sequence_date_range()` method on `myinvois.document` overrides the method from `sequence.mixin` and returns only two values from `date_utils.get_fiscal_year()`. However, it expects the method to return four values at [1].

[1] - https://github.com/odoo/odoo/blob/57b6b8d63b038ede32dfcc833c30e93d0cf4166c/addons/account/models/sequence_mixin.py#L146
Ref: https://github.com/odoo/odoo/blob/1ce06257f877711bd5de5487364909d72b476318/addons/account/models/account_move.py#L4263

sentry-7320998540