Currently, an error occurs when the "Payroll: Update Data" scheduled action is executed.

**Steps to Reproduce:**
 - Install `l10n_sa_hr_payroll` with demo data.
 - Switch to `Saudi Arabian` company.
 - Go to `Payroll` > `Configuration` > `Salary` > `Rule Categories`.
 - Delete all records related to the Saudi Arabian company.
 - Go to `Scheduled Actions` and run `"Payroll: Update Data"`.

`ValueError: External ID not found in the system: l10n_sa_hr_payroll.l10n_sa_category_provision`

After [this commit], the category_id field becomes non-required, allowing users to delete 
a rule category record even if it is linked to a salary rule. When updating the data file [1], 
this causes an error due to the missing rule category [2].

This commit ensures that, when updating the salary rule data, the rule category data is updated 
beforehand, as shown here [3].

[this commit]: https://github.com/odoo/enterprise/commit/c663fd2a81b7f6b34f8199fdbdc4a75c4f21379e

[1]- https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/models/hr_payslip.py#L157-L165

[2]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/data/hr_salary_rule_saudi_data.xml#L249

[3]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_ke_hr_payroll/models/hr_payslip.py#L9-L18

sentry-7349905716

**Steps to reproduce:**
1. Install module `l10n_pe_edi`.
2. Switch company to PE.
3. Create a tax:
   - Name: ICBPER
   - Amount type: Fixed
   - Code: ICBPER
   - Amount: 0.5(e.g.)
   - Set the tax group to ICBPER (In Advance Option)
4. Create a invoice and add a product with ICBPER tax.
5. Post the invoice and click "Process Now" (at header).

**Issue:**
Processing the invoice raises:
    AttributeError: 'dict' object has no attribute '_get_downpayment_lines'

**Cause:**
When `fixed_taxes_as_allowance_charges` is True, `_setup_base_lines()` calls `_turn_emptying_taxes_as_new_base_lines()`, which splits fixed taxes (e.g., ICBPER) into separate base lines.

During this process, `base_line['record']` is no longer the original `account.move.line` record. Instead, it becomes a dictionary containing record under `base_line['record']['record']`.
  - With the flag enabled: `base_line['record']` -> dict `line._get_downpayment_lines()` -> AttributeError
  - With the flag disabled: `base_line['record']` -> `account.move.line``line._get_downpayment_lines()` -> works correctly
 
The Peru EDI implementation directly accesses `base_line['record']` expecting an `account.move.line`. The the nested dict structure causes the crash during file generation.

**Solution:**
Override `_add_invoice_config_vals()` to explicitly set `fixed_taxes_as_allowance_charges = False`
- Add test to ensure invoices with ICBPER fixed taxes generate XML without error

**opw-5809939**

Forward-Port-Of: odoo/enterprise#108638

Steps to reproduce (singleton crash):

Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)".

Steps to reproduce (stale overtime lines):

With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed.

The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`.

The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` (hr_attendance) built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed.

Solution:
- In `_get_overtime_intervals`, localize `end_of_day` to the employee's timezone before converting to UTC, so overtime intervals are correctly bounded by the local end of day.
- In `_set_real_overtime_intervals` and the overtime loop in `_get_attendance_intervals`, iterate over individual records from potentially multi-record `Intervals` payloads to avoid singleton errors.
- In `_get_overtimes_to_update_domain` (hr_attendance), localize check_in/check_out to the employee's timezone before computing the date range so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle.

opw-5931665

Forward-Port-Of: odoo/enterprise#109419

Currently, when a user creates a Sale Order for MTO products that share the same component (which itself has a BOM), the system does not create a separate child MO for each manufacturing order.

## Steps to produce:
- Install Sales and Manufacturing
- Go to Settings and turn on Replenish on Order (MTO).
- Create products 'Wooden Arrow' and 'Wooden Rod' with a BOM that includes:
   - 'Stick', which itself has a BOM with 'Raw stick'.
- On each product page, go to Inventory and enable the MTO route, except for 'Raw Stick' .
- Create a Sale Order for Wooden Arrow and Wooden Rod for Customer 'Administrator'.
- Confirm the Sale Order.
- Go to Manufacturing > Open and check both Manufacturing Orders.

## Observed Behavior:
Currently, the manufacturing order for 'Wooden Arrow' has a child MO, but the order for 'Wooden Rod' does not.

The child MO under 'Wooden Arrow' produces two sticks at once. However, each manufacturing order should have its own separate child MO so that every item is produced and tracked individually.

## Root cause:
The issue happens because when a Sale Order is confirmed, [_run_manufacture](https://github.com/odoo/odoo/blob/7c7c6663e28974834d1569b27605f6ce400c7b16/addons/mrp/models/stock_rule.py#L81-L120) is called. This method creates a new MO or updates an existing one based on the domain returned by `_make_mo_get_domain` [1].

For 'Wooden Arrow' and 'Wooden Rod; new MOs are created because no existing MO matches their BOM ID, product ID, or reference.
They are added to `new_productions_values_by_company` [2], which is then used to create the MOs [3].

When `_run_manufacture` runs for 'Stick', it is triggered twice since both MOs require it as a component. The first time, no MO matches the domain, so a new one is created. The second time, the domain matches the existing MO (same BOM ID and product ID), so that MO is updated instead [4]. Because of this, `new_productions_values_by_company` is not filled again, and no second child MO is created.

[1]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L146-L165 
[2]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L98-L103 
[3]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L113-L115 
[4]-
https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L105-L110

## Solution:
To resolve this issue, the domain has been tightened to include the parent production group ID. Since the parent MO’s group ID is passed through the procurement variable when `_run_manufacture` is executed for its component products, this group ID can be used to ensure the correct MO is matched.

**Why modify the existing test case?:**
With this change, in the `test_sale_mrp_pickings` test case, a new child MO for 'Stick' is created under the MO for 'Arrow' instead of modifying another parent MO for 'Stick'. The test case has been updated accordingly. (Confirmed the new behavior with CRL and TAGO)



opw-5480133

Forward-Port-Of: odoo/odoo#248229

This commit resolves a performance bottleneck that occurred when handling very
large sale orders (e.g., ~200 order lines). Previously, the util function
`getParentSectionRecord` determined the parent (sub)section of an order line by
iterating over all preceding order lines. Since this logic was executed for each
order line, the overall complexity became O(n²).

Moreover, this function was invoked inside the `shouldCollapse` method, which is
used in multiple UI flows during rendering. As a result, large sale orders could
cause noticeable UI slowdowns and block the main JavaScript thread.

To address this, we now build a parent–child section mapping once per render
in O(n) time. Subsequent lookups simply read from this mapping instead of
recomputing the parent by scanning previous lines.

This significantly reduces the computational cost and prevents UI blocking when
working with large orders, leading to a much smoother rendering experience.

opw-5865167

Benchmark:

| No. records | Before      | After        |
|----------------|---------------|--------------|
|       150      |   1300ms  |   ~850ms |


| Before      | After        |
|---------------|--------------|
|   <img width="287" height="284" alt="image" src="https://github.com/user-attachments/assets/dd73ab18-3c53-4958-99b7-083dd5cd9e64" />  |   <img width="311" height="277" alt="image" src="https://github.com/user-attachments/assets/b6e90fa3-85eb-4d72-b616-28aff9a938e8" />|
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#252991

**PROBLEM**
Here is the client use case:
The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the 'consigne/vidange'. When returning the 'consigne', you would create an invoice line, with a product with a price of 0, negative quantity,a 0% tax and the fixed tax for the 'consigne'. When an invoice contains such lines, it fails peppol validations.

**STEP TO REPRODUCE**
1. Create a fixed tax used for 'vidange/consigne'.
2. Create an invoice, with a line with unit price of 0, negative quantity, a 0% tax and the fixed tax for the 'consigne'.
3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08].

**CAUSE**
Fixed tax (like the one used for vidange) are aggregated in new invoice lines by the function `_ubl_turn_emptying_taxes_as_new_base_lines()`. Let say we have the following invoice:
line 1: qty=2, unit_price=3, taxes: 21% & vidange(fixed tax of 1). line 2: qty=-1, unit_price=0, taxes: 0% & vidange.

After calling `_ubl_turn_emptying_taxes_as_new_base_lines()`, we got: line 1: qty=2, unit_price=3, taxes: 21%.
line 2: qty=-1, unit_price=0, taxes: 0%.
line 3: qty=1, unit_price=1(amount of the fixed tax), taxes:None.

When generating the VAT breakdown, we have 2 line will end up being tax exempted (line 2 and 3). Because the `tax_exemption_reason` differs, they will not be merged in the same entry in the breakdown, which break the constraint of peppol saying we can only have one VAT breakdown with code 'Exempt from tax'.
Line 2 reason comes from:
https://github.com/odoo-dev/odoo/blob/de22093ee225df499b2de80e1f07dd281ac686bc/addons/account_edi_ubl_cii/models/account_edi_common.py#L271-L274

opw-5912986

Forward-Port-Of: odoo/odoo#254875
Forward-Port-Of: odoo/odoo#250413

Steps to reproduce:
-------------------
* Let's say you're on company A, create a pos payment method
* Don't assign a pos yet
* Create a branch company sub_A
* Switch to that branch company
* Create a pos
* Now switch to company A but also select sub_A
* In the config of the pos from sub_A, try to add the new payment method and save
> Validation error -> Normal
* Now instead go to the payment method form
* In the point of sales select the pos sub_A
* Save
> No error
* Try opening the pos sub_A
> Validation error, same as the first one -> Normal

Why the fix:
------------
We already have a contraint on the pos config model checking that the companies match.
https://github.com/odoo/odoo/blob/88df50bc96448dfaff28bd37e970ffd18bf8d554/addons/point_of_sale/models/pos_config.py#L469-L473

However when writing on the model pos payment there is no constraint and the ORM currently does not trigger constraints on comodel of the field we're modifying so we need to add this constraint on the pos payment method model as well

opw-6000206

Forward-Port-Of: odoo/odoo#253858

Steps to reproduce (singleton crash):

Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)".

Steps to reproduce (stale overtime lines):

With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed.

The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`.

The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed. Additionally, `_get_localized_times` called `.astimezone()` on naive UTC datetimes without first localizing them, producing incorrect local times for the same reason.

Solution:
- In `_get_overtimes_to_update_domain`, localize check_in/check_out to the employee's timezone before computing the overtime search date range (with a ±1 day buffer) so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle.
- Fix `_get_localized_times` to call `utc.localize()` on naive UTC datetimes before converting to the employee's timezone.

opw-5931665

Forward-Port-Of: odoo/odoo#251812

**Steps to reproduce:**
- Install Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings:
  * activate Peppol
  * set "Rounding Method" to "Round Globally"

- Create an invoice:
  * Customer: [a Belgian customer with a VAT]
  * Invoice Lines:

    | Label | Quantity | Price | Taxes | 
    | ------- | ---------- | ------- | ------- |
    |  Line 1   |   1.0    | 90.30 |   0%  |
    |  Line 2   |   0.45   |  2.54 |   6%  |
    |  Line 3   |   0.28   |  6.87 |   6%  |

- Confirm the invoice
- Send the invoice to Peppol

**Issue:**
The generated XML has a line with `<cbc:LineExtensionAmount>` set to 90.31, `<cbc:InvoicedQuantity>` set to 1.0 and `<cbc:PriceAmount>` set to 90.30, which fails the validation with the following error:

`[BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT".`

**Cause:**
The use of decimal number in quantity generates a 0.01 rounding difference in the base amounts.
The extra cent is dispatched in one of the `<cbc:LineExtensionAmount>` node.

**Solution:**
There is no easy solution to handle these rounding cases. The solution used in this fix is to handle the extra cents as if they are cash rounding amount and declare them in `<cbc:PayableRoundingAmount>` node.

opw-5933545




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

Forward-Port-Of: odoo/odoo#255095
Forward-Port-Of: odoo/odoo#253625

### Description of the issue/feature this PR addresses:

Some stock queries determine whether a location belongs to the subtree of a set of locations by checking the parent_path prefix against candidate parent locations. This is done using a correlated EXISTS subquery with a LIKE parent.parent_path || '%' condition.

When the list of candidate locations becomes large (for example tens or hundreds of thousands of ids), this approach causes extremely poor performance because the database must repeatedly compare hierarchical path strings for every candidate row.

This PR improves the performance of this ancestry check by replacing the string prefix comparison with a direct check on the ancestor ids contained in parent_path.

### Current behavior before PR:

The query determines whether a location belongs to the subtree of one of the provided locations using:

location.parent_path LIKE parent.parent_path || '%'

For each row, PostgreSQL must evaluate a correlated subquery against all candidate parent locations. Because this relies on string prefix comparisons on parent_path, when the location list is large, this results in extremely slow queries.

### Desired behavior after PR is merged:

Instead of performing string prefix comparisons, the query extracts the ancestor ids directly from parent_path.

The path is:

1. Trimmed to remove leading and trailing /
2. Split into an array of ancestor ids
3. Expanded using unnest
4. Checked for intersection with the provided location ids

This converts the ancestry check from repeated string comparisons into a simple integer membership check.

### Benchmarks

Comparing performance of old subquery:

```
SELECT stock_location_inner.id 
FROM stock_location AS stock_location_inner 
WHERE EXISTS (
    SELECT 1
    FROM stock_location parent
	WHERE parent.id IN (long list)
		AND stock_location_inner.parent_path LIKE parent.parent_path || '%%'
);
```

to new one:

```
SELECT stock_location_inner.id 
FROM stock_location AS stock_location_inner 
WHERE EXISTS (
    SELECT 1
    FROM unnest(
        string_to_array(trim(both '/' FROM stock_location_inner.parent_path), '/')::int[]
    ) AS path_id(id)
	WHERE path_id.id IN (long list)
);
```

Depending on the number of elements in 'long list'

| # of elements | Before | After |
| --- |---|---|
| 130,000 | 21min | 0.8sec |  
| 10,000 | 95sec | 0.5sec |  
| 1,000 | 10.5sec | 0.5sec |  

In practice, on the reference ticket this causes the "Validate" button on a stock picking to go from timing out to taking 8 seconds. 

### Reference

opw-5932436

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

Forward-Port-Of: odoo/odoo#254245