**Steps to reproduce the issue:**

- Install the l10n_mx_edi module.
- Open the Accounting app and go to Customers → Invoices.
- From the invoice line, make the Tax Object field visible.
- Create a new invoice and add a product that has no Unit Price.
- Save the invoice.
- Edit the same invoice, set a Unit Price for the product, and save it again.
- Issue: The Tax Object field is not automatically set after the Unit Price is added.

**Description:**

- In our standard code, there is a condition that skips computing the Tax Object when the Unit Price is [0](https://github.com/odoo/enterprise/blob/615a5f756d708db95e22cdbdd6e7aca72ac769ec/l10n_mx_edi/models/account_move.py#L988). This is the expected behavior.
- However, after setting a Unit Price on the product, the Tax Object is not recomputed, so it remains unset.
- To resolve this issue, I added price_unit to the @api.depends decorator so that the Tax Object is recomputed whenever the Unit Price changes.

**Reference videos:**

Before the fix:
[screen-capture (2).webm](https://github.com/user-attachments/assets/c1162fd9-52b8-4a8c-9ac2-39cf2ca3ad69)


After the fix:
[screen-capture (1).webm](https://github.com/user-attachments/assets/1c05dc34-6778-487a-9bfc-635cf652e670)


OPW -6305080 
UPG - 4268848

Forward-Port-Of: odoo/enterprise#125530
Forward-Port-Of: odoo/enterprise#123009

**Steps to reproduce the issue:**

- Install the l10n_mx_edi module.
- Open the Accounting app and go to Customers → Invoices.
- From the invoice line, make the Tax Object field visible.
- Create a new invoice and add a product that has no Unit Price.
- Save the invoice.
- Edit the same invoice, set a Unit Price for the product, and save it again.
- Issue: The Tax Object field is not automatically set after the Unit Price is added.

**Description:**

- In our standard code, there is a condition that skips computing the Tax Object when the Unit Price is [0](https://github.com/odoo/enterprise/blob/615a5f756d708db95e22cdbdd6e7aca72ac769ec/l10n_mx_edi/models/account_move.py#L988). This is the expected behavior.
- However, after setting a Unit Price on the product, the Tax Object is not recomputed, so it remains unset.
- To resolve this issue, I added price_unit to the @api.depends decorator so that the Tax Object is recomputed whenever the Unit Price changes.

**Reference videos:**

Before the fix:
[screen-capture (2).webm](https://github.com/user-attachments/assets/c1162fd9-52b8-4a8c-9ac2-39cf2ca3ad69)


After the fix:
[screen-capture (1).webm](https://github.com/user-attachments/assets/1c05dc34-6778-487a-9bfc-635cf652e670)


OPW -6305080 
UPG - 4268848

Forward-Port-Of: odoo/enterprise#125098
Forward-Port-Of: odoo/enterprise#123009

## Steps to reproduce:

1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`.
2. Ensure that Demo mode is activated if not on Runbot.
3. Navigate to Contacts, then click into "BR Company Customer Estimated Profit".
4. Duplicate this contact, then set the following fields:
   1. Tax Regime set to individual
   2. ICMS Taxpayer Type set to Non-Taxpayer
5. Swtich to the BR Company and go to Accounting / Configuration / Settings.
6. Set up a Sandbox Avalara account and enable logging payload responses.
7. Navigate to Accounting > Customers > Invoices.
8. Create an invoice with:
   1. Customer set to the copy created earlier.
   2. Operation Type set to Sale of Goods
   3. Document Type set to 55
   4. Payment Method Brazil set to Money
   5. Presence set to Present
   6. One sales order line with:
      1. Regular Consumable Product
      2. quantity set to 1
      3. price set to 100.0
9. Confirm the invoice.
10. Navigate back to Accounting > Configuration > Settings to view the response from Avalara. The customer will have the CFOP 6102 instead of CFOP 6108.

Explanation:

PR #97845 introduced `_l10n_br_deep_clean_dict()` to remove falsy values and empty dictionaries from the payload we send to Avalara. This fix was applied as broadly as possible to prevent excessive if statements.

However, if the falsy values in taxSettings of the customer are not communicated, Avalara will assign the customer to an incorrect CFOP.

opw-6085964

Forward-Port-Of: odoo/enterprise#124730
Forward-Port-Of: odoo/enterprise#120783

**Problem:**
On a website with rental planning enabled, a customer can book a planning-backed rental product through eCommerce even when no planning resource is free for the requested window. The cart lets them increase the quantity past the available capacity and proceed all the way through checkout without any availability gate.

**Steps to reproduce:**
1. Install `website_sale_renting_planning`.
2. Create a planning role with `sync_shift_rental` and one resource.
3. Create a service product with `rent_ok=True`, `planning_enabled=True` and the role above.
4. Pre-book the resource for some window via a `planning.slot`.
5. From eCommerce, add the product to the cart for the same window.
6. Proceed to checkout/payment.

**Current behavior:**
The cart is considered ready, no warning is shown, and payment can proceed even though no planning resource is free for the chosen period.

**Expected behavior:**
The cart should be flagged as not ready and pre-payment validation should refuse to confirm until the customer picks a different date or quantity.

**Cause of the issue:**
`sale.order._available_dates_for_renting` in `website_sale_renting` is the documented hook for "stock availability" gating of the cart and pre-payment flow (called from `_is_cart_ready` and from `_check_cart_is_ready_to_be_paid`). `website_sale_stock_renting` overrides it to apply a per-line stock check, but
`website_sale_renting_planning` has no such override, so planning-backed rental services reach payment with no availability gate at all.

**Fix:**
Apply the same gating pattern that `website_sale_stock_renting` already uses: override `_available_dates_for_renting` in `website_sale_renting_planning` so that, for each rental line whose product is a planning-synced rentable service, the cart is only considered valid when at least the requested quantity of planning resources is free during the rental window (mirroring the resource and leave filtering already done by `_planning_slot_vals_list_per_sol` at SO confirmation time). This puts the gate at the same point the stock-renting flow enforces it, keeping the public cart/checkout flow consistent across rentable product types.

opw-6247034

Forward-Port-Of: odoo/enterprise#125534
Forward-Port-Of: odoo/enterprise#118943

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

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

### Problem

`Mail: Fetchmail Service` cron aborts with `AttributeError: 'NoneType' object has no attribute 'upper'` in `l10n_cl_edi/models/fetchmail_server.py::_process_incoming_customer_claim` when an incoming customer claim DTE has no `<RUTRecep>`:

```python
dte.findtext('.//ns0:RUTRecep', ...).upper() or
dte.findtext('.//ns0:RutReceptor', ...).upper()
```

`findtext()` returns `None` when the tag is missing, so `.upper()` blows up before the `or` fallback can run. Once the cron hits such a message it re-crashes on every subsequent run and blocks the whole mailbox until the offending mail is deleted.

### Fix

Guard each `findtext(...)` with `or ''` so the `or` chain actually falls through. Empty `partner_vat` is already handled by the existing "Partner … has not been found" branch a few lines below.

### Traceback (Odoo 19)

```
File "/mnt/extra-addons/enterprise/l10n_cl_edi/models/fetchmail_server.py", line 285, in _process_incoming_customer_claim
    dte.findtext('.//ns0:RUTRecep', namespaces=XML_NAMESPACES).upper() or
AttributeError: 'NoneType' object has no attribute 'upper'
```

### Ticket

No ticket open for this but opw-5257481 is related.

Forward-Port-Of: odoo/enterprise#123387

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

### Steps to reproduce:

- In the settings enable: Packages
- On the operation type `Delivery Order` set "Set Package Type"
- Create and confirm a delivery for 1 unit of a product P + reserve it
- Got to the barcode app to process the delivery
- Scan your product and click "put in pack"
#### > The put in pack wizard allowing you to set a package type on the new package does not pop up.

### Cause of the issue:

As a general rule of thumb the wizard is suppose to be displayed when the option is enabled and when a package/package type is not already provided to the call:
https://github.com/odoo/odoo/blob/5dbc448d336c7ff22803ae91d5014eb6d0a07234/addons/stock/models/stock_package.py#L332-L341 https://github.com/odoo/odoo/blob/5dbc448d336c7ff22803ae91d5014eb6d0a07234/addons/stock/models/stock_move_line.py#L1236-L1238 However an override was added to the barcode module so that the wizard is never displayed when the action is launched from the barcode app: https://github.com/odoo/enterprise/blob/673d449f38cd3eff27c44270c8f7edf91d0ecd02/stock_barcode/models/stock_move_line.py#L193-L196

The idea behind this override was that you could provide the package type id via scans and hence that is was not necessary. However, if you click directly on the put in pack button, the wizard still make sense and should therefore be displayed under the same conditions.

opw-6325092

Forward-Port-Of: odoo/enterprise#122308

[FIX] mrp_workorder_plm: avoid singleton traceback when matching BOM operations
**Issue**
Adding a step in a manufacturing order with two operations that are too similar
could lead to a traceback when proposing an improvement from the Shop Floor.

**Steps to reproduce**
- Install the Product Lifecycle Management app.
- Create a BOM for any product with two operations that:
	- Have the same name and work center
	- Have no variant
- Create and confirm a Manufacturing Order for that product.
- Open the Shop Floor view.
- Click the gear icon -> Update Instructions -> Improvement Suggestion -> Add a Step -> Propose a Change.
-> A traceback occurs

**Cause**
When adding a step:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L10
It tries to find the corresponding operation in the ECO's new BoM.
This relies on `_get_sync_values()`:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_plm/models/mrp_routing.py#L9-L13
Because two operations share the same name, work center, and no variant, both match the filter:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L39
This results in a singleton error when accessing `operation.id`:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L42

opw-6241880

Forward-Port-Of: odoo/enterprise#119404

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

Steps to reproduce the bug:
- Create a BOM for product P1 with one work order WO1
- Create 3 quality points linked to WO1 via the `operation_id` field
- Confirm a manufacturing order for P1:
    - 3 quality checks A → B → C are generated
- Open the shop floor for the work order:
    - Observe that all 3 quality checks are displayed
- Delete quality check B (the middle one)
- come back to the shop floor for the work order:
- Observe that quality check C is no longer displayed in the shop floor

Problem:
After deleting check B, check C disappeared from the shop floor. Quality checks are stored as a doubly-linked list via the `next_check_id` and `previous_check_id` fields on `quality.check`. The shop floor JS (`mrp_display_record.js`) traverses this list starting from the check with no `previous_check_id`, then follows `next_check_id` until the chain ends. When check B was deleted, it nullified the FK references pointing to it, leaving check A with `next_check_id = False` and check C with `previous_check_id = False`. The traversal from A therefore stopped immediately, and C was never reached.

No `unlink` override existed on `quality.check` to repair the chain before deletion.

Solution:
Added an `unlink` override that, before deleting each check, reconnects its predecessor and successor: if the deleted check has both a previous and a next, `prev.next_check_id` is set to `next` and `next.previous_check_id` is set to `prev`, preserving a valid chain for the remaining checks.

opw-6369298

Forward-Port-Of: odoo/enterprise#124118

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

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

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

**Steps to Reproduce:**

 - Install `l10n_au_hr_payroll` with demo data.
 - Switch to `Australian Company`.
 - Go to `Payroll` > `Configuration` > `Salary` > `Rule Categories`. 
 - Delete all records related to the `Australian Company`. 
 - Go to `Scheduled Actions` and run `Payroll: Update Data`.

`ValueError: External ID not found in the system: l10n_au_hr_payroll.rule_category_ote`

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], an error is 
raised due to the missing rule category.

This commit ensures that when updating the salary rule data, it updates the category data 
beforehand as like [here]

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

[1] https://github.com/odoo/enterprise/blob/b6612dd58276646b81a3a12cd48e8427ea5359c2/l10n_au_hr_payroll/models/hr_payslip.py#L76-L83

[here]: https://github.com/odoo/enterprise/blob/b6612dd58276646b81a3a12cd48e8427ea5359c2/l10n_ch_hr_payroll/models/hr_payslip.py#L1074-L1087

sentry-7349905716

Steps to reproduce:
-------------------
1. Install `documents_hr` and `web_studio` with demo data.
2. Add `document_count` to the Employees list view via Studio.
3. Create a second company with an employee, enable multi-company.
4. Open Employees list, click **All** in the search panel.

Issues:
------
Issue 1:
```python
File "/home/odoo/odoo/enterprise/documents_hr/models/hr_employee.py", line 25, in _compute_document_count
    if not self.company_id.documents_hr_settings:
File "/home/odoo/odoo/community/odoo/orm/fields.py", line 1429, in __get__
    record.ensure_one()
File "/home/odoo/odoo/community/odoo/orm/models.py", line 5640, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: res.company(1, 2)
```

Issue 2:
```python
  File "/home/odoo/odoo/enterprise/documents_hr/models/hr_employee.py", line 31, in _compute_document_count
    ('partner_id', '=', self.work_contact_id.id)
  File "/home/odoo/odoo/community/odoo/orm/fields_misc.py", line 117, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.partner(9, 8, 7)
```
Cause:
---------
https://github.com/odoo/enterprise/blob/38674448e387159d28f98c1678856fcaf5f7f52e/documents_hr/models/hr_employee.py#L23-L48
1. The document count computation assumes all employees belong to the same company by directly accessing `self.company_id.documents_hr_settings`. In a multi-company environment, `self` may contain employees from different companies, making self.company_id a multi-recordset and triggering a singleton error.

2. Similarly, when `documents_hr_settings` is disabled, the fallback computation accesses `self.work_contact_id` on a multi-recordset, causing another singleton error.

Solution:
-----------
Split the employees based on whether `documents_hr_settings` is enabled and compute each group separately.
Additionally, use the current employee's `work_contact_id` in the fallback computation to avoid singleton error.

**NOTE:**
This has been resolved from saas-19.4 onward with this improvement [commit](https://github.com/odoo/enterprise/commit/d018d8205300b434728129e199ae048cefbaa296).

opw-6351141

**_Steps to reproduce :_**

-  Install l10n_it_riba.
-  Configure a company with a San Marino (SM) IBAN as the bank account for the
   journal used for Ri.Ba.
-  Create a customer payment and add it to a Batch Payment using the Ri.Ba.
   payment method.
-  Validate the Batch Payment.

**_Observed behavior :_**

 The validation fails with the error:
   `Only bank accounts with an Italian IBAN are allowed to use Ri.Ba. payments`

**_Cause :_** 

 The Ri.Ba. validation logic only accepts IBANs with the IT country code and incorrectly rejects valid San Marino (SM) IBANs.

**_Fix :_**

-  Update the Ri.Ba. IBAN validation to accept both Italian (IT) and San Marino (SM) IBANs when generating Ri.Ba. payment files.

-  While validating Batch Payments for SM IBANs, we observed that the extracted value could overlap with the branch code portion, causing the generated RIBA record to exceed the expected 120-character length. This change updates the extraction logic to prevent overlap and ensure compliance with the required record format.

**_opw_** - 6303820

Forward-Port-Of: odoo/enterprise#121439

### Issue before this commit:
When a company generates an EC Sales List for a foreign country (e.g., a Luxembourgish company running a Belgian report), the exported XML and PDF files incorrectly display the company's primary domestic VAT number instead of the foreign VAT number defined in the fiscal position in the tag DeclarantReference.

### Steps to reproduce the issue:
1. Download Accounting and l10n_lu
2. Switch to LU company
3. Go to Fiscal Positions in settings and create the Belgian position (insert country as Belgium and Foreign Tax ID as BE0477472701)
4. A pop up will appear saying: Click  to create the taxes for this country. so click there to create the taxes
5. Go to Invoices and create a new invoice and be sure that:
	1. be sure the customer has a VAT number in their profile
	2. in tab Other Info the Fiscal Position is set to Belgium
	3. the tax applied is 0% EU S (BE)
	4. date of invoice is in June
6. Open the tax return in 1 July
7. Open EC Sales List June 2026 (BE) and mark as reviewed all the lines
8. Click on Validate
9. Open the XML and PDF file created and see that the tag DeclarantReference is wrong because it reports the data of LU company instead of BE company

### Cause of the issue:
The `export_to_xml_sales_report` method relied on legacy code (company.partner_id.vat) to fetch the VAT number. It failed to use the centralized `get_vat_for_export(options)` method, thereby completely bypassing the foreign VAT logic correctly implemented in other tax reports.

### Reason to introduce the fix:
To ensure tax compliance by appling the correct VAT number from the foreign fiscal position.

opw-6170447

Forward-Port-Of: odoo/enterprise#125210
Forward-Port-Of: odoo/enterprise#124698

### Steps to reproduce:

- Ensure `sale_stock_renting` is installed
- Enable Multi-Steps Routes > Unarchive MTO
- Create a product P with a BoM and the routes MTO + manufacture
- Create anc confirm a sale order for A unit of P
- Log in with an other user with with mrp User rights and sales User: Own Documents Only (he should not have access to the SO)
- Open the MO, add a component line and save
#### > Access Error: Blame the following rule: - Personal Order

### Cause of the issue:

Writing on the `move_raw_ids` will trigger a call of the `_autoconfirm_production` in order to confirm the newly created move: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L990-L991 https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L1422-L1423
During this confirmation process, one calls the `_merge_moves` method in order to  merge this new move (if relevant) to any already existing one. https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/stock/models/stock_move.py#L1575-L1576
Now, the issue is that, `sale_stock_renting` module overrides the method `_prepare_merge_moves_distinct_fields` determining the fields relevant to the merge by requiring a read access to the `is_rental_order` compute field of the `sale_order` linked to the MO:
https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/sale_stock_renting/models/stock_move.py#L34-L40
However, due to the 'Personal Orders' ir.rule, the user does not have a read access to this record:
https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/sale/security/ir_rules.xml#L44-L49

Community: https://github.com/odoo/odoo/pull/271017

opw-6275658

Forward-Port-Of: odoo/enterprise#121845
Forward-Port-Of: odoo/enterprise#121135

When a knowledge article linked to an Annual report is moved to the trash and
the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate.

Steps to reproduce the error:
- Install ``accountant_knowledge`` module
- Go to Accounting > Review > Annual Report > Create a new annual report
- Go to Knowledge > Open the knowledge article linked to the annual report > Send to Trash
- Run the ``Base: Auto-vacuum internal data`` cron

Traceback:
```py
ForeignKeyViolation: update or delete on table "knowledge_article" violates foreign key constraint 
"audit_report_knowledge_article_id_fkey" on table "audit_report" DETAIL:  Key (id)=(67) is still referenced from table "audit_report".
```

https://github.com/odoo/enterprise/blob/04cce2e400ce2e412f28aa1849078a7c40ff0e2c/knowledge/models/knowledge_article.py#L1069-L1070
The garbage collector deletes trashed knowledge articles that match its domain.
Since this domain also includes articles linked to Annual Reports,
the cron attempts to delete records that are still referenced by annual report,
resulting in a foreign key violation error.

Solution:
Ensure linked audit reports are also deleted during knowledge article garbage collection.

sentry-7488793071

Forward-Port-Of: odoo/enterprise#125525
Forward-Port-Of: odoo/enterprise#121189

## Steps to reproduce:

1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`.
2. Ensure that Demo mode is activated if not on Runbot.
3. Navigate to Contacts, then click into "BR Company Customer Estimated Profit".
4. Duplicate this contact, then set the following fields:
   1. Tax Regime set to individual
   2. ICMS Taxpayer Type set to Non-Taxpayer
5. Swtich to the BR Company and go to Accounting / Configuration / Settings.
6. Set up a Sandbox Avalara account and enable logging payload responses.
7. Navigate to Accounting > Customers > Invoices.
8. Create an invoice with:
   1. Customer set to the copy created earlier.
   2. Operation Type set to Sale of Goods
   3. Document Type set to 55
   4. Payment Method Brazil set to Money
   5. Presence set to Present
   6. One sales order line with:
      1. Regular Consumable Product
      2. quantity set to 1
      3. price set to 100.0
9. Confirm the invoice.
10. Navigate back to Accounting > Configuration > Settings to view the response from Avalara. The customer will have the CFOP 6102 instead of CFOP 6108.

Explanation:

PR #97845 introduced `_l10n_br_deep_clean_dict()` to remove falsy values and empty dictionaries from the payload we send to Avalara. This fix was applied as broadly as possible to prevent excessive if statements.

However, if the falsy values in taxSettings of the customer are not communicated, Avalara will assign the customer to an incorrect CFOP.

opw-6085964

Forward-Port-Of: odoo/enterprise#124730
Forward-Port-Of: odoo/enterprise#120783

To reproduce the issue:

1) Create a company in Belgium
2) Instantiate its returns and review, submit and pay one of the VAT returns 3) Change the states_worklfow of the VAT return so that it only accepts "review" and "submit" stages, not "paid" anymore 4) Go to the list of returns, remove the TODO filter => traceback

The problem is here that the existing returns don't recompute their state when the workflow of the type is modified. In some cases, this is fine, but it others, it's annoying. In our example, the terminal state changed, so all the returns in that terminal stage should change their state to the new terminal one. "paid" is not an accepted value anymore, it should become "submitted".

Moreover, when the workflow is changed, the selection field actually containing the state must also change. As it is, it seems to work because "state" of account.return is stored, but the value it's based on (the workflow field) won't be consistent with it. It's not annoying now, but those inconsistencies could become a big source of trouble in the future (we know that from experience ... I'm looking at you, version 8 ! è-é).

This issue typically happens at upgrade. We had cases in FR and AE already. We solve that by a generic override of the write to sort things out when such change needs to happen. An upgrade PR will also be done to adapt the script so that we eventually solve the inconsistencies on dbs that have already migrated to 19.0.

Forward-Port-Of: odoo/enterprise#124934
Forward-Port-Of: odoo/enterprise#124144

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)

### Problem

`Mail: Fetchmail Service` cron aborts with `AttributeError: 'NoneType' object has no attribute 'upper'` in `l10n_cl_edi/models/fetchmail_server.py::_process_incoming_customer_claim` when an incoming customer claim DTE has no `<RUTRecep>`:

```python
dte.findtext('.//ns0:RUTRecep', ...).upper() or
dte.findtext('.//ns0:RutReceptor', ...).upper()
```

`findtext()` returns `None` when the tag is missing, so `.upper()` blows up before the `or` fallback can run. Once the cron hits such a message it re-crashes on every subsequent run and blocks the whole mailbox until the offending mail is deleted.

### Fix

Guard each `findtext(...)` with `or ''` so the `or` chain actually falls through. Empty `partner_vat` is already handled by the existing "Partner … has not been found" branch a few lines below.

### Traceback (Odoo 19)

```
File "/mnt/extra-addons/enterprise/l10n_cl_edi/models/fetchmail_server.py", line 285, in _process_incoming_customer_claim
    dte.findtext('.//ns0:RUTRecep', namespaces=XML_NAMESPACES).upper() or
AttributeError: 'NoneType' object has no attribute 'upper'
```

### Ticket

No ticket open for this but opw-5257481 is related.

From the cart, it is possible to increase the amount ordered of a rental product that synchronizes shifts depending on a specific service

Steps to reproduce:
1. Install website_sale_renting_planning module
2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period
3. In the General Information tab, click on the internal link to "Developer"
4. Enable Sync Shifts and Rental Orders
5. Go to the eCommerce website and search for product "test"
6. Add as much product "test" to the cart as possible (the quantity is limited)
7. Open the cart
8. You can increase the amount of the product regardless of its availability

Issue:
We don't check the renting availabilities to limit the maximum quantity of the product

Solution:
Check that the new quantity of the product is available in `_verify_updated_quantity` for the specified dates. We also need to check the availability of the product when we modify the rental dates

opw-6274035

Issue
-----
International deliveries for fractions of items (eg 500g of a product sold by kg) are rejected by Sendcloud.

Steps to reproduce
-----
- Setup Sendcloud
	- Fedex international
- Create a product
	- weight: 1kg
	- valid hs code
- Create a contact (outside EU if the company is in EU)
- Deliver 0.5 of the product to the contact

> Error "... parcel not returned from Sendcloud"

Cause
-----
Sendcloud returns he folloing error:

> "The total weight for declared items exceeds the total weight set for the shipment."

This is because the `weight` set on the shipment

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L449-L464

corresponds to the weight of the package, whereas the weight set on the description of the product in `parcel_items` corresponds to the weight of one "full" unit of the product.

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L327-L335

We cannot change the quantity in `parcel_items` to match the actual delivered one because the field should be an integer.

https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-parcel-items-items-quantity

The price is also off, because it gets taken from the `move_line`, so it reflects the price of the actual quantity and not a "full" item.

https://github.com/odoo/odoo/blob/208a8a6a5adb8ec1f2710453c2ee3b54c55a9f1e/addons/stock_delivery/models/delivery_carrier.py#L235

Note that this issue is common to **all UoM types**.

Solution
-----
Since we cannot change the quantity, we can instead adapt the description and weight sent in `parcel_items`. For example, sending 300g of sugar, we would send
- description: "Sugar (0.3 kg)"
- weight: "0.300"

-----
Ticket:
opw-6346330

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

# How to reproduce
For an employee with full attendances for april and may:
- Create payslip for the month of April, Compute Sheet & Confirm
- Create a Time off request for that employee ffrom the 1st of April to the 10th of April, Approve & Validate
> Since the April payroll is closed, you need to defer the Time Off
- Report to Next Month
- Create payslip for the month of May
> The deffered time off should be there
- Compute Sheet & Confirm
- Create a Time off request for that employee for the 3rd of May, Approve & Validate
> Again, the May payroll is closed, so you need to defer the Time Off

# The issue
You cannot defer the time off because "There is no work entries linked to this time off to report"

# The cause
When deferring a time off, we call `action_report_to_next_month` that will look for work entries generated during the leave period to defer :
https://github.com/odoo/enterprise/blob/f93882555864a1f0a2a3e3863780096c78923bfa/hr_payroll_holidays/models/hr_leave.py#L94-L101

The issue is that, since [this commit], we search for work entries that are not leaves and the first deferring we did transformed the work entries at the start of may into leaves.

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

opw-6318809

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

For an MO with component tracked by lot is possible to close it without assigning the lot number even when they are marked for manual consumption.
From the shopfloor this will close the MO that will disappear when it's gone it will throw a user error, without the MO reappearing.

Steps to reproduce
---------------------------
**Issue 1**
1) Create a product "final"
2) Create a product "component" tracked by lot
3) Update the on hand quantity and don't assign a lot number
4) Create a BoM for "final" with "component" as component and manual consumption
5) Create a MO and confirm it
6) Go to shopfloor
7) Set "final" quantity
8) Set "component" quantity
10) Close the MO
-> The MO disappear (leaving a user error)
-> Since the "component" does not have a lot number it should not disappear

**Issue 2**
Same steps as Issue 1 until step 6:
6*) Add "comp" as barcode to the product component
7*) Go to barcode
8*) Open the manufacturing order
9*) Add the quantity to final
10*) Scan "comp"
11*) Scan a non-existent lot number, ex: "12345"
-> It raise the error

Observation
----------------------

**Issue 1**
When clicking on "Closing production" it will call [onClickValidateButton](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L481-L482)() that will lead us to validate,
and validate will [call](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L511) the function [pre_button_mark_done](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L507) in python.

in pre_button_mark_done, we will skip any check on the lot number, since we already have set qty_producing (when setting "final" quantity), 
 it will avoid _set_quantities where a check for lot number is made:
https://github.com/odoo/odoo/blob/9218d302b0fd56c1854d95d3756c0f5e9c9c8700/addons/mrp/models/mrp_production.py#L2235-L2239
https://github.com/odoo/odoo/blob/9218d302b0fd56c1854d95d3756c0f5e9c9c8700/addons/mrp/models/mrp_production.py#L2839-L2844
And it will also skip the consumption wizard since it doesn't check for lot number nor allow to set lot numbers:
https://github.com/odoo/odoo/blob/35f804995118e6ffe150c9c7a7bad4844bd0e0ed/addons/mrp/models/mrp_production.py#L1658-L1660
After avoiding both checks we go back to validate.

In validate and we update the variable underValidation which will [trigger the fadeout animation](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L154)
When the [animation ends](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L662-L665),
the call to realValidation will be triggered and will call productionValidation that will send a call to [button_mark_done](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L551)

In button_mark_done, when calling _action_done on the move_lines, we will finally check that there is a lot number, which will trigger an error :
https://github.com/odoo/odoo/blob/35f804995118e6ffe150c9c7a7bad4844bd0e0ed/addons/stock/models/stock_move_line.py#L664-L669
but because the fadeout animation is already over, the mo will have disappeared, which means we can't correct the userError that has been raised.

**Issue 2**
In barcode when scanning a lot after a product, it will not create a lot but only apply a lot_name :
https://github.com/odoo/enterprise/blob/7b57a2927aeb8abf84d0f6acc64a7e9bbc8f608d/stock_barcode/static/src/models/barcode_model.js#L1306-L1311
this cause an issue with the existing condition since it only pass the check if there is a lot, but in this case there only is a lot_name.

When we click on "Produce" in a Mo in barcode, it will call validate, that in this case, will call button_mark_done:
https://github.com/odoo/enterprise/blob/80aaa507fd2196b90cea724ecab0fa0ed5f13db6/stock_barcode/static/src/components/main.xml#L163
https://github.com/odoo/enterprise/blob/80aaa507fd2196b90cea724ecab0fa0ed5f13db6/stock_barcode/static/src/models/barcode_model.js#L602-L605
https://github.com/odoo/enterprise/blob/80aaa507fd2196b90cea724ecab0fa0ed5f13db6/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L14

opw-6060310

Steps to reproduce:
-------------------
1. Install Timesheets.
2. Create a new employee with a fully fixed working schedule (40h/week).
3. Open Timesheets > All Timesheets and create a new timesheet in the past week for this employee (e.g. 8 hours).
4. Observe the overtime indicator for the employee (it shows 32 hrs)
   (Click the left arrow to display it).
5. Change the timesheet encoding unit to "Days / Half-Days".
6. Return to Timesheets and observe the overtime indicator (it now correctly shows 4 days).
7. Install a language other than English (e.g. French).
8. Return to Timesheets and observe the overtime indicator again.

Issue:
--------
The remaining time value changes unexpectedly and displays 32 hours instead of 4 days.

Cause:
---------
In `get_timesheet_and_working_hours_for_employees`, the code determines whether the timesheet UoM is expressed in days by comparing the UoM name with the string `"days"`.

Since UoM names are translatable, this comparison becomes invalid when the user language changes (e.g. `"jours"` in French), causing the logic to skip the day conversion and return values in hours instead.
https://github.com/odoo/enterprise/blob/c48290e90fdeadf4f9ca8c44b035e601e7ed380a/timesheet_grid/models/hr_employee.py#L165-L169

Solution:
-----------
Compare the timesheet UoM record with the day UoM record directly instead of relying on translated string values.


see commit: https://github.com/odoo/enterprise/commit/5fbf194c5056566453a124812fd2614edfe19a82

opw-6279133