**Steps to reproduce:**
* In **Accounting**, create a new accounting report.
* Set **Root Report** to **Profit and Loss**.
* Add a report line with **Figure Type = Percentage**.
* set **Computation Engine = External Value** and **Formula = 0** on report line.
* Add a report column with **Figure Type = Monetary**.
* Create a menu item for the report.
* Open the report and click **Budget**.
* Create a new budget filter and click **Create**.

**Observed behavior:**
* The system crashes with `TypeError: 'NoneType' object is not subscriptable`.
* The error occurs while accessing budget column values.

**Cause:**
* Budget comparison logic assumes required budget columns always exist.
* When the report configuration lacks compatible budget columns, internal variables remain unset and are accessed anyway.

**Fix:**
* Add a safety check to skip budget comparison when required columns are missing.
* Prevents the crash and allows budget filters to be created safely.

opw-5357339

Forward-Port-Of: odoo/enterprise#104162

Currently, saving the General Settings in a branch of a Guatemalan company raises a "Missing required field" error for the 'Service Provider' field (`l10n_gt_edi_service_provider`), even if no changes were made.

### **Steps to reproduce:**
1) Install `l10n_gt_edi` and switch to a GT company. 
2) Create a branch of the GT company.
3) In the parent company, go to Accounting Settings, set the Guatemala
   Localization to 'Demo', and save.
4) Switch to the branch company.
5) Open Accounting Settings and click Save.

### **Observed Behavior:**
An error occurs because `l10n_gt_edi_service_provider` is empty but required.

### **Root Cause:**
The `l10n_gt_edi_service_provider` field is marked as `required` whenever `country_code == 'GT'` (see[1]). However, the field is hidden in branch companies via the `invisible="not l10n_gt_edi_is_root_company"` domain on the settings block. Because the field is required but empty (and invisible to the user), the form validation fails.

[1]- https://github.com/odoo/enterprise/blob/6f3265aad51a264bee754ca239e8a5019487b38c/l10n_gt_edi/views/res_config_settings_views.xml#L19-L22

### **FIX:**
Update the `required` domain to include `l10n_gt_edi_is_root_company`.
This ensures the field is only mandatory in the root company where it
is actually visible and configurable and also set the `l10n_gt_edi_service_provider`
for branch company same as parent company.

**opw-5385819**

Forward-Port-Of: odoo/enterprise#106323

Steps to Reproduce:
1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result, the allocated period is shorter than the required hours.

Source:
When selecting 25/11/2025 as the start date, the system tries to schedule the task within the remaining days of November (25–28).
However, these four days are not enough to cover 40 hours.

The system then searches for available intervals in the next month. But the intervals from November are still kept in the list, so when the algorithm iterates again, it reuses the previously consumed intervals (25 and 26). This causes the scheduler to allocate the remaining hours to those same days, leading to an incorrect result where the task spans only 25–26 November, instead of continuing from 1 December.

Solution:
Remove already-used intervals before recomputing the schedule.

opw-5364327

Forward-Port-Of: odoo/enterprise#106160
Forward-Port-Of: odoo/enterprise#101262

Occasionally the test_kardex_report test fails:

```
Traceback (most recent call last):
  File "/data/build/enterprise/l10n_pe_reports_stock/tests/test_ple_kardex_report.py", line 126, in test_kardex_report
    self.assertSequenceEqual(
AssertionError: Sequences differ: ['M1|[18 chars]|1||02/01/2024|01|FBILL202401|0002|02|product_[313 chars], ''] != ['M1|[18 chars]|1||01/01/2024|01|FBILL202401|0001|02|product_[313 chars], '']

First differing element 0:
'M1|0[17 chars]|1||02/01/2024|01|FBILL202401|0002|02|product_[21 chars]0|1|'
'M1|0[17 chars]|1||01/01/2024|01|FBILL202401|0001|02|product_[21 chars]0|1|'

- ['M1|0000|1|99|FURN9999|1||02/01/2024|01|FBILL202401|0002|02|product_order_no|NIU|3.00|0.00|1|',
?                             ^                           ^

+ ['M1|0000|1|99|FURN9999|1||01/01/2024|01|FBILL202401|0001|02|product_order_no|NIU|3.00|0.00|1|',
?                             ^                           ^
```

The issue was reproducible locally by disabling nested loop joins: `self.env.cr.execute("SET LOCAL enable_nestloop = off")` to nudge Postgres to use a different join strategy.

The test creates a PO that is picked and invoiced in two steps (first quantity 3, then the remaining 2). As a result, the `stock.valuation.layer` ends up being linked to two `account.move.line`s because the join goes through the same `purchase_order_line`. So it will appear twice in the `_get_ple_reports_data()` query. A `DISTINCT
ON (stock_valuation_layer.id)` was already there with the goal of picking one of them. Which one depends on the order, but it's not deterministic: the valuation layer's `id`, `product_id`, and `create_date` will all be the same.

This commit makes the behavior deterministic by sorting on PO line and SO line ids.

runbot-error-238888

Forward-Port-Of: odoo/enterprise#107047