Odoo Changelog — 2026-08-07

Friday, August 7, 2026

3 changes · 18.0

Bug Fixes(3)

Resolved issues and error corrections

[FIX] l10n_mx_edi: fix Cuota tax amounts in payment complements

Enterprise18.0l10n_mx_ediMEDIUM

Payment complements in Mexican electronic invoicing now calculate fixed-rate tax amounts more accurately when invoices are partially paid. This helps prevent payment CFDIs from being rejected by tax authorities due to rounding mismatches.

Original PR description

When generating a payment complement, tax base and importe coming from the related invoice are prorated by the percentage actually paid, each rounded independently to the currency precision. The post-fix step that restores the SAT invariant uses a Tasa-only formula (`base = total / (1 + rate)`), so Cuota (fixed amount per unit) taxes keep mismatched values, ending up with
`ImporteDR != round(BaseDR * TasaOCuotaDR)`. This leads to CFDIs rejected by the PAC/SAT.

Steps to reproduce:
  - Create a customer invoice with a Cuota IEPS tax (e.g. 26.2569).
  - Register a partial payment whose amount is not an exact divisor of the invoice total (e.g. one third).
  - Send the payment CFDI: the resulting Cuota TrasladoDR has an ImporteDR that does not match BaseDR * TasaOCuotaDR, leading to a rejected CFDI.

This commit recomputes `importe` from the prorated `base` for Cuota taxes (bypassing the Tasa post-fix)

opw-6087564

#Mexico#electronic invoicing#payments#tax compliance

[FIX] mrp_workorder: preserve Shop Floor order

PR #126267

Enterprise18.0mrp_workorderMEDIUM

This fix keeps manufacturing work orders in the expected order when the Shop Floor view is refreshed or filters are changed. It prevents items from appearing inconsistently by preserving the display order based on work order status and scheduled start date.

Original PR description

Records already in cache are intended to be sorted by their position in `recordCacheIds` to preserve the previously computed display order.

However, `recordCacheIds` stores database record ids (`resId`), and currently the cache lookup incorrectly uses `id` instead.

As a result, every lookup returns `-1`, and could lead to inconsistent ordering.

Steps to reproduce:
1. Create several manufacturing orders with work orders assigned to the same work center.
2. Give the work orders different states and scheduled start dates.
3. Open Shop Floor and display that work center.
4. Refresh the view or change a filter so the records are recomputed.

It should use `resId` so the previously computed display order remains, which is based on state and scheduled start date.

Related: odoo/enterprise#74421

opw-6402233

Forward-Port-Of: odoo/enterprise#125928

#shop-floor#manufacturing#work-orders#ordering

[FIX] helpdesk: fix sla_reached computation

PR #127219

Enterprise18.0helpdeskMEDIUM

Helpdesk tickets now show an SLA as reached only after the ticket actually reaches the SLA target stage. This prevents new tickets from appearing compliant too early and ensures late completions are still recognized as reached while lateness is tracked separately.

Original PR description

### Steps to Reproduce: 1. Go to Helpdesk and create an SLA 2. Create a new Ticket 3. Use Studio to add the field `sla_reached` 4. Apply the SLA 5. Notice that the field is True ### Description of…

### Steps to Reproduce:
1. Go to Helpdesk and create an SLA
2. Create a new Ticket
3. Use Studio to add the field `sla_reached`
4. Apply the SLA
5. Notice that the field is True

### Description of the issue/feature this PR addresses:
**Issue:** The `_compute_sla_reached` method in on `helpdesk_ticket.py` determines whether an SLA has been reached by checking if `exceeded_hours` is less than 0 on its `helpdesk.sla.status` records. Since every newly assigned SLA has a future deadline, `exceeded_hours` starts as negative (AKA <0), so the ticket is immediately flagged as `sla_reached = True` before any progress has been made. Conversely, a ticket that reaches its target stage after the deadline has `exceeded_hours >= 0`, so it's incorrectly flagged as `sla_reached = False` even though the SLA target was genuinely reached (it was just late).

**Solution:** Change the domain in `_compute_sla_reached` to check `reached_datetime != False` instead of `exceeded_hours < 0`, matching the field already listed in the method's `@api.depends` and the same field `_sla_reach()` sets when a ticket enters its target stage. This makes `sla_reached` reflect actual stage progression rather than a time-remaining calculation.

### Current behavior before PR:
A newly created ticket with a pending SLA shows `sla_reached = True` and `sla_success = True` immediately upon creation, before the ticket has moved to any target stage. SImilarly, a ticket that reaches its target stage after the SLA deadline is incorrectly marked `sla_reached = False`.

### Desired behavior after PR:
`sla_reached` is False on ticket creation and only becomes True once the ticket actually enters the SLA's target stage. Lateness continues to be tracked separately and correctly via `sla_reached_late`

opw-6361851

Forward-Port-Of: odoo/enterprise#126432

#sla#helpdesk#tickets

When generating a payment complement, tax base and importe coming from the related invoice are prorated by the percentage actually paid, each rounded independently to the currency precision. The post-fix step that restores the SAT invariant uses a Tasa-only formula (`base = total / (1 + rate)`), so Cuota (fixed amount per unit) taxes keep mismatched values, ending up with `ImporteDR != round(BaseDR * TasaOCuotaDR)`. This leads to CFDIs rejected by the PAC/SAT. Steps to reproduce: - Create a customer invoice with a Cuota IEPS tax (e.g. 26.2569). - Register a partial payment whose amount is not an exact divisor of the invoice total (e.g. one third). - Send the payment CFDI: the resulting Cuota TrasladoDR has an ImporteDR that does not match BaseDR * TasaOCuotaDR, leading to a rejected CFDI. This commit recomputes `importe` from the prorated `base` for Cuota taxes (bypassing the Tasa post-fix) opw-6087564

Records already in cache are intended to be sorted by their position in `recordCacheIds` to preserve the previously computed display order. However, `recordCacheIds` stores database record ids (`resId`), and currently the cache lookup incorrectly uses `id` instead. As a result, every lookup returns `-1`, and could lead to inconsistent ordering. Steps to reproduce: 1. Create several manufacturing orders with work orders assigned to the same work center. 2. Give the work orders different states and scheduled start dates. 3. Open Shop Floor and display that work center. 4. Refresh the view or change a filter so the records are recomputed. It should use `resId` so the previously computed display order remains, which is based on state and scheduled start date. Related: odoo/enterprise#74421 opw-6402233 Forward-Port-Of: odoo/enterprise#125928

### Steps to Reproduce: 1. Go to Helpdesk and create an SLA 2. Create a new Ticket 3. Use Studio to add the field `sla_reached` 4. Apply the SLA 5. Notice that the field is True ### Description of the issue/feature this PR addresses: **Issue:** The `_compute_sla_reached` method in on `helpdesk_ticket.py` determines whether an SLA has been reached by checking if `exceeded_hours` is less than 0 on its `helpdesk.sla.status` records. Since every newly assigned SLA has a future deadline, `exceeded_hours` starts as negative (AKA <0), so the ticket is immediately flagged as `sla_reached = True` before any progress has been made. Conversely, a ticket that reaches its target stage after the deadline has `exceeded_hours >= 0`, so it's incorrectly flagged as `sla_reached = False` even though the SLA target was genuinely reached (it was just late). **Solution:** Change the domain in `_compute_sla_reached` to check `reached_datetime != False` instead of `exceeded_hours < 0`, matching the field already listed in the method's `@api.depends` and the same field `_sla_reach()` sets when a ticket enters its target stage. This makes `sla_reached` reflect actual stage progression rather than a time-remaining calculation. ### Current behavior before PR: A newly created ticket with a pending SLA shows `sla_reached = True` and `sla_success = True` immediately upon creation, before the ticket has moved to any target stage. SImilarly, a ticket that reaches its target stage after the SLA deadline is incorrectly marked `sla_reached = False`. ### Desired behavior after PR: `sla_reached` is False on ticket creation and only becomes True once the ticket actually enters the SLA's target stage. Lateness continues to be tracked separately and correctly via `sla_reached_late` opw-6361851 Forward-Port-Of: odoo/enterprise#126432