Odoo Changelog — 2026-04-22

Wednesday, April 22, 2026

6 changes · 17.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] l10n_mx_edi: hide update payment button

Enterprise17.0l10n_mx_ediMedium

This fix corrects when the “Update Payment” button is shown on Mexican electronic invoices. In batch payment cases, the system now evaluates the payment information properly so the button disappears when it should, avoiding confusion for users.

Original PR description

backport of f41900a4353ea867b08f71ed64f8702a13411bac

- Create one invoice with the PUE payment policy.
- Create another invoice with the PDD payment policy.
- Send both invoices to the CFDI.
- Create a batch payment for both and reconcile.
- Click on Update Payment on one of the invoices.

The Update Payment button does not disappear.
In the method _l10n_mx_edi_cfdi_invoice_get_payments_diff, we compare the current UUIDs and the previous UUIDs to determine if the button should be shown. However, when there is a batch payment, the current UUID list includes the UUIDs of all invoices in the batch, including the PUE payment (which should normally be filtered out by the continue). The previous UUID list includes only the UUID of the PDD payment.

opw-6055781

#mexico#edi#invoicing#payments#batch payment

[FIX] hr_attendance: check out on employee archive

PR #260106

Core17.0hr_attendanceMedium

When an employee is archived while they are still checked in, the system now ensures their attendance is properly closed. This prevents mismatches where an employee looks inactive but still has an open attendance record, which could cause reporting and process issues for HR.

Original PR description

- Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance.
- Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving.
- Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance. Inheriting from employee departure wizard and adding a warning if ongoing attendance so the hr user can choose to checkout or delete the attendance.

Task: 6131692

#hr#attendance#archive#checkout

[FIX] account_reports: Order of string external values

PR #113837

Enterprise17.0account_reportsMedium

This fix ensures string-based report values are sorted by date when the "most recent" option is used. It prevents values from appearing in the wrong order, especially in reports covering the full history of data.

Original PR description

Ensure string-type external values are correctly sorted by date when using the "most_recent" formula.
This resolves an issue where values appeared unordered, especially for expressions using the "From the very start" period.

task-5951888

#reports#sorting#date#accounting

[FIX] web: ensure settings load when swiping on mobile

PR #260563

Core17.0webMedium

This update fixes an issue on mobile devices where swiping between app settings could show a blank page. It now waits for the next settings page to finish loading before completing the swipe, making navigation smoother and more reliable.

Original PR description

Before this commit, swiping between settings for different apps on mobile
devices would often result in a blank page.

This occurred because the swipe method did not wait for the target page to
render completely before completing the transition. This commit ensures the
swipe action waits for the rendering process, preventing the blank state
during app navigation.

#mobile#settings#navigation#usability

[FIX] l10n_sa_edi: skip reversed down-payments

PR #259384

Core17.0l10n_sa_ediMedium

This change prevents final invoices from failing when a sale order has more than one down-payment record. The system now correctly ignores reversed down payments when a valid replacement exists, which helps ensure invoices can be sent to ZATCA without errors.

Original PR description

Sending the final invoice of a sale order to ZATCA crashed with `ValueError: Expected singleton: account.move(a, b)` when the sale order had multiple down-payment references.

Steps to reproduce:
1. Configure a SA company and setup ZATCA
2. Create a sale order and confirm it
3. Deliver the product line.
3. From the sale order, create a down-payment invoice (fixed amount, e.g. 115) and post it (DP1).
4. On DP1, click "Credit Note" and choose "Full refund and new draft invoice"; validate. DP1 becomes `reversed` and a new draft down-payment DP2 is created. Post DP2.
5. From the sale order, create the final regular invoice and post it.
6. Send the final invoice to ZATCA (or generate its XML) -> `ValueError: Expected singleton: account.move(a, b)`.

Root cause: _l10n_sa_get_line_prepayment_vals looks up the related down-payment move through the down-payment sale order line shared with the product line. The filter matched any out_invoice with _is_downpayment() == True, so the reversed DP1 and the active DP2 both ended up in the recordset, and reading .name raised the singleton error.

Prefer non-reversed down-payment moves when available, but fall back to reversed ones if no alternative exists (e.g.
when generating a credit note of the final invoice after the original down-payment was itself reversed).

opw-6116265

[FIX] l10n_cz_reports_2025: remove country code from vat number in vies summary report xml

PR #113083

Enterprise17.0l10n_cz_reports_2025Medium

The VIES Summary Report XML export now removes the country prefix from customer VAT numbers. This ensures the file matches the official Czech format and helps prevent validation issues when submitting the report.

Original PR description

**Steps to reproduce:**
- Install the `l10n_cz_reports` module and switch to a `CZ Company`
- Create an invoice for a customer with a VAT number, add a product, and 
  set the Transaction Code (enable it from the optional columns if needed).
- Navigate to Reporting > VIES Summary Report.
- Observe the value in the `VAT Number` column (includes country code).
- From the dropdown, export the report as XML.

**Observation:**
In the generated XML file, the `c_vat` field contains the VAT number 
including the country code (e.g., `CZ12345679`) instead of only the 
numeric part (`12345679`).

**Root cause:**
At [1], the VAT number is directly taken from the report lines without 
removing the country code.

**Fix:**
This commit ensures that the `c_vat` field contains only the VAT number without 
the country code, complying with the official VIES XML format requirements.

Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part)

[1]:
https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62

opw-6093259

backport of f41900a4353ea867b08f71ed64f8702a13411bac - Create one invoice with the PUE payment policy. - Create another invoice with the PDD payment policy. - Send both invoices to the CFDI. - Create a batch payment for both and reconcile. - Click on Update Payment on one of the invoices. The Update Payment button does not disappear. In the method _l10n_mx_edi_cfdi_invoice_get_payments_diff, we compare the current UUIDs and the previous UUIDs to determine if the button should be shown. However, when there is a batch payment, the current UUID list includes the UUIDs of all invoices in the batch, including the PUE payment (which should normally be filtered out by the continue). The previous UUID list includes only the UUID of the PDD payment. opw-6055781

- Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance. - Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving. - Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance. Inheriting from employee departure wizard and adding a warning if ongoing attendance so the hr user can choose to checkout or delete the attendance. Task: 6131692

Ensure string-type external values are correctly sorted by date when using the "most_recent" formula. This resolves an issue where values appeared unordered, especially for expressions using the "From the very start" period. task-5951888

Before this commit, swiping between settings for different apps on mobile devices would often result in a blank page. This occurred because the swipe method did not wait for the target page to render completely before completing the transition. This commit ensures the swipe action waits for the rendering process, preventing the blank state during app navigation.

Sending the final invoice of a sale order to ZATCA crashed with `ValueError: Expected singleton: account.move(a, b)` when the sale order had multiple down-payment references. Steps to reproduce: 1. Configure a SA company and setup ZATCA 2. Create a sale order and confirm it 3. Deliver the product line. 3. From the sale order, create a down-payment invoice (fixed amount, e.g. 115) and post it (DP1). 4. On DP1, click "Credit Note" and choose "Full refund and new draft invoice"; validate. DP1 becomes `reversed` and a new draft down-payment DP2 is created. Post DP2. 5. From the sale order, create the final regular invoice and post it. 6. Send the final invoice to ZATCA (or generate its XML) -> `ValueError: Expected singleton: account.move(a, b)`. Root cause: _l10n_sa_get_line_prepayment_vals looks up the related down-payment move through the down-payment sale order line shared with the product line. The filter matched any out_invoice with _is_downpayment() == True, so the reversed DP1 and the active DP2 both ended up in the recordset, and reading .name raised the singleton error. Prefer non-reversed down-payment moves when available, but fall back to reversed ones if no alternative exists (e.g. when generating a credit note of the final invoice after the original down-payment was itself reversed). opw-6116265

**Steps to reproduce:** - Install the `l10n_cz_reports` module and switch to a `CZ Company` - Create an invoice for a customer with a VAT number, add a product, and set the Transaction Code (enable it from the optional columns if needed). - Navigate to Reporting > VIES Summary Report. - Observe the value in the `VAT Number` column (includes country code). - From the dropdown, export the report as XML. **Observation:** In the generated XML file, the `c_vat` field contains the VAT number including the country code (e.g., `CZ12345679`) instead of only the numeric part (`12345679`). **Root cause:** At [1], the VAT number is directly taken from the report lines without removing the country code. **Fix:** This commit ensures that the `c_vat` field contains only the VAT number without the country code, complying with the official VIES XML format requirements. Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part) [1]: https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62 opw-6093259