## Current behavior:
In Malaysia's Statement of Account, the total and total overdue amounts
dont consider the selected Statement Date, and will calculate all the
balances up until today in the generated PDF report

## Expected behavior:
The total and total overdue amounts should only sum the balances included
in the report up until the selected Statement Date

## Steps to reproduce:
1. Install l10n_my_reports module, switch to Malaysian company
2. Go inside Invoicing > Report > Aged receivable
3. Select a specific date in the past
4. Observe that the total amounts dont match with the balance column, and wont change regardless of the date selected

## Cause of the issue:
The template used o.total_overdue which ignores the report domain
and statement date

## Fix:
Accumulate overdue_total in the template loop with the same domain
and date_to cutoff as the balance lines, so it always matches
the displayed Balance lines for the selected Statement Date

opw-6332970

Forward-Port-Of: odoo/enterprise#125410
Forward-Port-Of: odoo/enterprise#123694

Previously, the `_preprocess_work_hours_data` method would abort early if no payslip was found for the given period. This prevented the correct generation or evaluation of expected Mexican work hours in contexts where a draft payslip does not yet exist (i.e., when an off-cycle payslip is initially generated for a given time period).

To resolve this, the strict dependency on the payslip record has been removed. It now falls back to the contract version's base data when a payslip is absent:
- The calendar defaults to the contract version's `resource_calendar_id`.
- The duration is assumed to be standard (`is_wrong_duration = False`).
- The Mexican schedule table (`l10n_mx_schedule_table`) is fetched globally from the environment (`hr.rule.parameter`) rather than relying on the payslip-specific helper method.

This ensures expected work hours and attendance fields are calculated consistently across all payroll workflows, regardless of whether the payslip has been instantiated.

opw-6351402

Forward-Port-Of: odoo/enterprise#125219

Currently, when users group accrual reports by dates, aggregated computed fields are not calculated correctly. As a result, values such as the total amount may be displayed as zero even when the grouped records contain non-zero amounts.

## Steps to produce:
- Install Purchase and Accounting
- Create a product `Energy drink Sample` with cost 10$
- Create and Confirm a PO with the energy drink sample with vendor as `Administrator`
- Set `Received` as 1.
- Go to Accounting > Review > Bill to Receive
- Search Filter> Remove vendor grouping > Use Custom Group `Order Date`
- Expand the group

## Observed Behavior
Although the grouped lines contain an amount of 10 dollars, the aggregated total displayed in the sum remains zero.

The total should reflect the combined value of the grouped lines.

## Root Cause:
This issue occurs because opening the view triggers `_read_group_for_accrual`, which overrides the `_read_group` method on purchase order lines. The purpose of this override is to support grouping on computed fields that are not stored in the database such as `amount_to_invoice_at_date (Amount)`, `qty_received_at_date (Received)`.

When `_read_group_for_accrual` is executed, it delegates grouping for non-computed fields to the parent `_read_group` implementation, as shown at [1].

The parent method returns results in `res` similar to: 
```
[(datetime.datetime(2026, 6, 1, 0, 0), 1.0, 10.0, 1)]
```
During iteration over res at [2], the code uses `group[0]` as the grouping key. In this example, group[0] is `datetime.datetime(2026, 6, 1, 0, 0)`, which represents the granularity date
(e.g., the first day of the month when grouping by month).

However, `records_by_group` is keyed by the actual purchase order line order dates rather than the granularity dates returned by `_read_group`. For example:
```
{datetime.datetime(2026, 6, 12, 0, 0): purchase.order.line(1,)}
```

As a result, the lookup performed using the granularity date (`datetime.datetime(2026, 6, 1, 0, 0))` does not find a matching entry in `records_by_group`. Consequently, records falls back to an empty `purchase.order.line()` recordset.

Later, at [3], the aggregation logic computes totals using this empty recordset. Since the required fields are evaluated on an empty set of records, the aggregated values are computed as zero.

This ultimately causes the method to return a total value of zero
[1]-
https://github.com/odoo/enterprise/blob/eeea1377a7d36d11e140c44dee30a45228e7b4a6/account_accountant/models/analytic_mixin.py#L9-L24 
[2]-
https://github.com/odoo/enterprise/blob/eeea1377a7d36d11e140c44dee30a45228e7b4a6/account_accountant/models/analytic_mixin.py#L40-L42 
[3]-
https://github.com/odoo/enterprise/blob/eeea1377a7d36d11e140c44dee30a45228e7b4a6/account_accountant/models/analytic_mixin.py#L44-L47

## Solution:
The issue can be resolved by grouping records using the same date granularity specified in the groupby, rather than using the field values.

By aligning the grouping logic with the granularity returned by `_read_group` (for example, grouping by the first day of the month when using monthly grouping ), the keys in `records_by_group` match the values returned in `res`. As a result, the corresponding records are correctly retrieved during aggregation.

This ensures that the aggregation is performed on the appropriate purchase order lines instead of an empty recordset, allowing the computed totals to be calculated correctly.

[opw-6261225](https://www.odoo.com/odoo/project/49/tasks/6261225)

Forward-Port-Of: odoo/enterprise#120369

## Issue
When creating a Contract Template for a Swiss company, the template does not match the version shown in the Employee's view. Also, some fields are not correctly applied when loading a contract template on an employee (e.g. `hourly_wage`, `wage`, ...).

## Steps to reproduce
1. Install *Switzerland - Swissdec Certified ELM 5.0 - Payroll* (`l10n_ch_hr_payroll`)
2. (Create and) Use a Swiss company
3. In Employees > Configuration > Contract Templates, create a Contract Template
    - Wage Type: Hourly Wage
    - Hourly Wage: Any value > 0
    - **(Notice how the aforementionned fields are missing from the template)**
4. In Employees > Employees, create an Employee
5. On the new employee's view, on the Payroll tab, click "Load Template"
and load the template created in step 3
6. **The data from the template is not applied to the employee's contract**

## Cause
The fields loaded from a contract template are listed in the `whitelist` variable of the `hr.version.wizard`:

https://github.com/odoo/odoo/blob/5c3deb11627f4d6762c4994207bd582afb96f064/addons/hr/wizard/hr_contract_template_wizard.py#L15-L30

Multiple fields were missing from the whitelist (e.g. `hourly_wage`, `l10n_ch_has_{hourly|monthly|lesson}`, ...). These fields would not be loaded from the template when applying a template on an employee.

**This commit replicates the employee's version view on the contract template and adds the related fields to the whitelist for them to be correctly applied when loading a contract template.**

opw-5966664
opw-6128467

Forward-Port-Of: odoo/enterprise#125435
Forward-Port-Of: odoo/enterprise#110683

### Issue before this commit:
When reverting a Guatemalan invoice (creating a credit note), the XML node FechaEmisionDocumentoOrigen incorrectly reports the EDI document's technical certification date instead of the original invoice's emission date. This causes the SAT to reject the document.

### Steps to reproduce the issue:
1. Download Accounting and l10n_gt
2. Revert an invoice (credit note) inserting a different date than the one of the invoice
3. See that FechaEmisionDocumentoOrigen report the date of the credit note instead of the one of the invoice

### Cause of the issue:
The _l10n_gt_edi_add_reference_values method extracted the date from original_document.datetime (the technical timestamp of when the XML was generated) rather than using the actual accounting date of the original invoice.

### Reason to introduce the fix:
SAT validation rules strictly require the reference date to match the exact commercial emission date of the original invoice. Fetching invoice_date directly ensures compliance, avoids timezone conversion errors, and prevents the XML from being rejected.
Source: https://www.lawinsider.com/es/contracts/dJXl4Vo79L2

<img width="730" height="205" alt="2026-07-17_10-19" src="https://github.com/user-attachments/assets/802e7bb3-fcf9-48db-b86f-227b494001b6" />

opw-6394409

Forward-Port-Of: odoo/enterprise#125788
Forward-Port-Of: odoo/enterprise#124794

### Steps to reproduce:
- In a database with Switzerland localization, install 'Accounting' and 'Payroll'
- Manually change the debit and credit accounts on the Swiss ELM salary rules (rule code 1000)
- Install 'POS'
- Check the accounts you configured on the salary rules
>The accounts are reset to their default values

### Cause of Issue:
POS depends on the module `stock_account`. When `stock_account` is installed, the `_configure_journals` method in its `__init__.py` creates a new `account.journal` for inventory valuation. To apply default values to this journal, the method retrieves data from the chart template.
https://github.com/odoo/odoo/blob/7d16ef88784e18e885b97dbded3231775f1349d2/addons/stock_account/__init__.py#L41

The `hr_payroll_account` module overrides `_post_load_data` and unconditionally calls `_load_payroll_accounts(template_code, company)`. https://github.com/odoo/enterprise/blob/fcf06997a0eb999af86e4b6917311a86f04a390e/hr_payroll_account/models/account_chart_template.py#L16-L18

This triggers the reinstallation of the default payroll accounts, which overwrites and discards any manual configuration changes the user has made to their salary rules.

### Fix:
Ensure that default payroll accounts are only reset during a genuine chart of accounts loading process, and not during localized post-load operations triggered by other modules.

opw-6251112

Forward-Port-Of: odoo/enterprise#121687

In MPS, if a product’s Bill of Materials (BOM) is not specified at the time of addition, the system will not correctly account for batch size.

Steps to reproduce:
-------------------
* Create a product with a bom that has a batch size of 2
* Open MPS
* Add the product
  - without specifying the bom
  - Route Manufacture
* Add 1 in the Forcast Demand -> the batch size from the bom it's not taken into account.

Observation:
-------------
When updating mps, it will call get_production_schedule_view_state: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L424 this function when calculating the quantity to resplenish will call _get_resplenish_qty: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L534 to know the quantity to resplenish it will need the batch size, in mps they will only consider the batch size from the bom registered: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L863-L865 
Since there is no default value for bom_id, If there is no bom selected, there is no batch size.

opw-6259956

Forward-Port-Of: odoo/enterprise#124922
Forward-Port-Of: odoo/enterprise#119560

Resizing a work order from the right edge in the Gantt view updated only the stop date (`date_finished`). Since the work order Gantt view defines dependencies, this triggered dependency propagation through `web_gantt_reschedule`. During that flow, `_web_gantt_move_candidates` needed both the old start and stop dates to update dependent work orders,
but the old-value snapshot only contained fields present in `vals`. As a result, `date_start` was missing and the resize crashed with a `KeyError: 'date_start'`.

Handle the missing old start date in the generic Gantt dependency propagation flow. When only the stop date is changed, the old start date is added to the old-value snapshot without adding it to the actual write values. This keeps the right-edge resize payload unchanged while giving dependency propagation the values it needs.

Steps to reproduce:
1. Create a manufacturing order with work orders.
2. Plan the manufacturing order.
3. Open the Work Order Gantt view.
4. Resize a work order from the right edge to change its planned end date.

Before this commit:
Right-edge resizing a work order with dependencies crashed during dependency propagation with `KeyError: 'date_start'`.

After this commit:
Right-edge resizing keeps the changed `date_finished`, dependency propagation has access to the old `date_start`, and dependent work orders are rescheduled without crashing.

task-6345347

In a [previous PR], a test was introduced to reject any `l10n_xx_hr_*` module that has a `countries` key in its manifest and depends on a module that also has that country key.

This test was too broad and rejected some valid cases:
1. A non-auto-install module can have a country key defined to add  flags in the apps kanban view. ([src])
2. A module that has a country-specific regular dependency, but not as an  auto-install condition.

The second case is illustrated by [l10n_us_hr_payroll], which should auto-install when `hr_payroll` is installed and a US company exists.
With the old test, achieving this required adding `l10n_us` to its auto-install dependencies. 
But, since `l10n_us` is not auto-installable, `l10n_us_hr_payroll` would not be installed if you create a DB with a US company and only install `hr_payroll`.

In practice, that module was still being installed via a [post-init hook] in `hr_payroll`. This hook was installing all `l10n_XX_hr_payroll` modules for each country where a company is located, which is the behavior of the `countries` parameter in the manifest.

This caused issues during upgrades as this runs late in the process: after the auto-discovery phase.
Modules installed by this hook would be considered as `uninstalled` until `hr_payroll` is loaded.


This commit narrows the check to only fail if:
- A module has a `country` key in its manifest, and
- It has a country-specific module in its **auto-install** dependencies.

Moreover, it modifies `l10n_us_hr_payroll` to correctly rely on the auto_install mechanism instead of the post-init hook.

[previous PR]: https://github.com/odoo/enterprise/pull/101843
[src]: https://github.com/odoo/odoo/blob/6df9f92a537aa4bb4ee5dc946fe31c4e56e6dfea/odoo/addons/base/models/ir_module.py#L271-L273
[l10n_us_hr_payroll]: https://github.com/odoo/enterprise/blob/24a33ffb769557be498d61328522bb77f68d3a5a/l10n_us_hr_payroll/__manifest__.py
[post-init hook]: https://github.com/odoo/enterprise/blob/85185595cfd1ee5310ceb9dc80c0589accad2f19/hr_payroll/__init__.py#L21

Forward-Port-Of: odoo/enterprise#125853
Forward-Port-Of: odoo/enterprise#120279

While trying to fix the SAT cron, we did not think it through
it could cause infinite cron triggering.
Indeed, the write_date is updated on every record that is handled.

Fix is manyfold:
- Avoid re-processing what we already check within the last 4 hours/12 hours
depending on the type of the document.
- The domain takes the *static* create date instead of the write_date
to make sure we don't endless re-process the same record and that
the window of 7/60 days applies.
- Limit the Vendor Bill to be checked only during 7 days after their creation.
- Use the create_date in the order of the search to ensure we process older
records first, before their time-window closes.
- Process the Vendor Bills last, this ensure Customer Invoices will be processed
in priority in case we are not able to process everything within the last 4/12 hours.

This is still imperfect and a little fragile, we will find a better solution
in master, most likely by adding a dedicated field to keep track of the
last SAT check.

See https://github.com/odoo/enterprise/pull/123213
See https://github.com/odoo/enterprise/pull/103272

task-none

Forward-Port-Of: odoo/enterprise#125598
Forward-Port-Of: odoo/enterprise#125317