## Problem

When generating an export CFE (e-Factura Exportación) in the Uruguayan EDI module, invoices that include a discount line equal to the subtotal — resulting in a **total of 0.00** — were not handled correctly by the XML/CFE generation
logic.

This use case is valid and required by exporters who need to reflect the declared value of goods/services while invoicing at zero (e.g. to comply with customs or incoterm requirements such as FCA). In Uruware's validation portal, the "Descuentos y Recargos" (discounts & surcharges) section of the subtotal block must be correctly populated for the CFE to be accepted.

**Example:** An invoice with a line of 648.00 UYU and a global discount of −648.00 UYU → Total: 0.00. The export value is still declared, taxes are zero, but the CFE must reflect the discount amount explicitly.

<img width="592" height="679" alt="example_expo_invoice_discount" src="https://github.com/user-attachments/assets/aa83c158-e342-4da5-a251-fc209bbed5c4" />

## Root Cause

The CFE template (`cfe_template.xml`) and the move computation logic (`account_move.py`) did not account for the case where export invoices carry line-level or global discounts that zero out the total. The discount amount was
either omitted from the XML nodes or computed incorrectly, causing Uruware validation to fail or the discount block to not render.

## Fix

- **`l10n_uy_edi/models/account_move.py`** — Updated the export invoice computation to correctly include discount amounts in the CFE data dict, ensuring the `ValorDR` is filled with the value of the discount per line.
- **`l10n_uy_edi/views/cfe_template.xml`** — Adjusted the template condition so `MntExpoyAsim` node accepts 0 as value.

## Steps to Reproduce (before fix)

1. Create an export invoice (e-Factura Exportación) for a foreign partner.
2. Add a product line with a unit price, e.g. 216.00 × 3 = 648.00 UYU.
3. Add a global discount of 648.00 (same amount) so the total is 0.00.
4. Confirm and send to Uruware — the CFE is rejected / discount block is missing.

## Verification

After the fix, the same invoice generates a valid CFE accepted by Uruware with the discount correctly reflected in the `DscRcgGlobal` node and the discount line visible on the printed document.

Forward-Port-Of: odoo/enterprise#124910
Forward-Port-Of: odoo/enterprise#120130

## 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#125212
Forward-Port-Of: odoo/enterprise#110683

If one of the Payroll Structure Types has the Scheduled Pay field unset,
opening the Payroll dashboard raises a traceback.

Steps to reproduce the error:
- Install ``hr_payroll`` module
- Go to Payroll > Configuration > Settings > Set Payroll Closing Date > Save
- Go to Payroll > Configuration > Structure Types > Create a new Structure Type > Unset Scheduled Pay
- Open Dashboard

Traceback:
```py
AttributeError: 'bool' object has no attribute 'title'
```

https://github.com/odoo/enterprise/blob/9a3ea83a432f42f62076a50fca6bc771a2de96bf/hr_payroll/models/hr_payroll_warning.py#L413-L419
The dashboard collects the scheduled pay values from all structure types and
later calls ``schedule.title()`` to build the labels. When a Structure Type has
no Scheduled Pay configured, so ``schedule`` becomes ``False``, leading to the traceback.

``_get_schedule_pay`` method can return False at [1],
So, It will generate the traceback from below line also. https://github.com/odoo/enterprise/blob/8a3d87d51a9a3c4df656a328a9179ee43541022d/hr_payroll/models/hr_payroll_warning.py#L401

Solution:
Added a fallback value when default scheduled pay is False.

[1]: https://github.com/odoo/enterprise/blob/8a3d87d51a9a3c4df656a328a9179ee43541022d/hr_payroll/models/hr_payroll_warning.py#L149-L154

sentry-7583037488

### 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#124794

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#119560

A user without Planning rights cannot add a product from the catalog on a sale order

Steps to reproduce:
1. Install planning_field_service_sale_timesheet module
2. Go to Settings > Users & Companies > Users and open user Marc Demo
3. Set Planning rights to No
4. Go to Settings > Planning > Field Service and enable Quotations
5. Go to Planning, create a new planning slot with customer Acme Corporation, open it in fullscreen, click on the quotation smart button and create a new quotation
6. Log in as Marc Demo
7. Go to Sales and open the new quotation
8. Click on Catalog in the order lines
9. An access error is raised

Issue:
planning_field_service_sale_timesheet overrides `action_add_from_catalog` and tries to read sale.order.planning_slot_id but users can't always access this field as it either requires Administrator rights on Planning or that the planning.slot is not in draft
https://github.com/odoo/enterprise/blob/e92a86257cb99ee1010531ec10d8fc968623a31d/planning/security/planning_security.xml#L60-L69

Solution:
Check that the user has write rights before opening `action_view_material`

opw-6315647

Forward-Port-Of: odoo/enterprise#123228

Currently, an error occurs when grouping planning slots by role.

**Steps to Reproduce:**
 - Install the `Planning` module.
 - Go to `Planning` > `Configuration` > `Roles`.
 - Create a `role` without assigning any resource to it (or assign a resource without a working time).
 - Go to `Planning`, create a new `planning slot`, assign the `role` created above, set the start date to `20/07/2026 12:00 PM` and the end date to `21/07/2026 2:00 AM`.
 - Switch to the `Gantt view` of the `planning slots`.
 - Group by `Role` and set the custom date range to `07/19/2026 -> 07/20/2026`, then click `Apply`.

`KeyError: 1`

The error occurs when the user groups the planning slots by role in the Gantt view. During 
the computation of the Gantt progress bar, if the existing slot's role has no resource, or has 
a flexible resource without a calendar, the regular resources become empty [1]. Then it 
attempts to compute the valid work intervals for these empty resources [2], resulting in an 
empty calendar work interval dictionary ({}) [3]. Later, when computing the duration over the 
period with the valid range slots, it tries to access the resource directly from the empty 
calendar_intervals dictionary [4], which raises the error.

This commit ensures that, when no work intervals are available for a resource, an empty 
work interval is used instead.

[1]- https://github.com/odoo/enterprise/blob/3871b75fb74a7b35bfea9610ca08b853eb723320/planning/models/planning_slot.py#L307

[2]: https://github.com/odoo/odoo/blob/5663509fe5caa1191fafcea3b3879dcef9ceca8f/addons/resource/models/resource_resource.py#L220

[3]: https://github.com/odoo/enterprise/blob/3871b75fb74a7b35bfea9610ca08b853eb723320/planning/models/planning_slot.py#L3415-L3417

[4]- https://github.com/odoo/enterprise/blob/3871b75fb74a7b35bfea9610ca08b853eb723320/planning/models/planning_slot.py#L3300

sentry-7620222164

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