Odoo Changelog — 2026-07-13

Monday, July 13, 2026

6 changes · 19.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] document_account: prevent context leakage in document creation

Enterprise19.0documents_accountMEDIUM

This fix prevents accounting screen filters from accidentally carrying over into document creation and causing errors. Users can update invoice payments from accounting workflows more reliably, including Mexican CFDI payment updates.

Original PR description

**Issue:**
The `default_type` context can leak into documents during creation with
invalid values (e.g., 'sale' for documents.document.type), causing a ValueError.

**Steps to reproduce - using MX EDI update payment:**
- Use a Mexican company with CFDI credentials configured.
- Create an invoice "payment policy = PPD", and send it to CFDI.
- Create a bank transaction and reconcile it with the invoice.
- Go to the Accounting Dashboard, remove current filters, and group by "Type"
  (this injects default_type into the context).
- From there, enter the "Sales" journal and open the invoice.
- Click on the "Update Payments" button.
- Result: `ValueError: Wrong value for documents.document.type: 'sale'`

**Fix:**
Clean context from the `default_*` keys when transitioning from Accounting to
Documents models.

opw-6141172
opw-5742850
opw-6182877

#accounting#documents#invoicing#mexico#cfdi

[FIX] l10n_ca_payment_cpa005: populate Item Trace Number with payment id

PR #123920

Enterprise19.0l10n_ca_payment_cpa005MEDIUM

Canadian EFT export files now include a nonzero item trace number for each payment, using the payment's own identifier. This helps ensure CPA-005 payment files meet Canadian banking requirements and reduces the risk of rejected transactions.

Original PR description

According to CPA-005 standards on the Item Trace Number:
"The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36).
https://www.payments.ca/sites/default/files/standard005eng.pdf

Steps to reproduce:
1. Install the module l10n_ca_payment_cpa005
2. Go into "CA Company"
3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC"
4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal
5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence
6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error)
7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT"
8. Create a batch payment for both payments created
9. Validate the batch payment and the export file should show up in the chatter
10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence

Solution:
Set the Item Trace Number to be the payment's id

opw-6323432

Forward-Port-Of: odoo/enterprise#123707
Forward-Port-Of: odoo/enterprise#123633

#Canadian EFT#CPA-005#payments#banking

[FIX] website_sale_renting: serialize rental dates for accessory cart

PR #123887

Enterprise19.0website_sale_rentingMEDIUM

Customers can now add suggested accessory products from the cart when buying rental items with day-based pricing. This prevents an error caused by rental date formatting, improving checkout reliability for rental sales.

Original PR description

Steps to reproduce:
===================
1. Create a rental product with a day-based rental period (e.g. 1 day) and a non-rental accessory product.
2. Add the rental product to the cart.
3. From the cart page, click "Add to cart" on the suggested accessory.

=> RPC error: ValueError: unconverted data remains: .999999

Root cause:
===========
For rental products priced on a non-hourly recurrence, the cart's rental_return_date is stored as the end of day in the website timezone, i.e. with .999999 microseconds. The suggested-products button renders the rental dates as raw str(datetime) into its data attributes, and the accessory add-to-cart sent them verbatim to /shop/cart/add, where fields.Datetime.to_datetime() cannot parse microseconds.

Fix:
====
Round-trip the data-attribute values through deserializeDateTime / serializeDateTime so the controller receives the standard server datetime format without microseconds, like every other renting flow.

opw-6372176

#rentals#cart#accessories#checkout

[FIX] account_reports: export real dates instead of text in report XLSX

PR #121668

Enterprise19.0account_reportsMEDIUM

Accounting report exports now send dates to Excel as actual date values instead of plain text. This makes exported reports easier to sort, filter, format, and reuse without manual cleanup, and also prevents an export crash when date-time values are processed.

Original PR description

Before this commit, columns with figure_type 'date'/'datetime', General Ledger's Date column, but also Partner Ledger, Aged Partner Balance, Bank Reconciliation and Customer Statement. were exported to XLSX as plain text strings instead of real Excel date values.

_get_cell_type_value, which decides whether a cell must be written as a date or as text, only recognized a cell as a date when its 'class' contained 'date'. _build_column_dict, used by every report to build its column cells, never set that key, so
the check always failed and cells fell back to text, even though figure_type was correctly set to 'date' on them.

_build_column_dict now also sets 'class': 'date' on date datetime columns, the same convention already used by hand-built cells
 in account_followup

This in turn revealed a second, so-far dormant issue: once real datetime values started reaching the XLSX writer, _set_xlsx_cell_sizes crashed while estimating the column width, as it unconditionally tried float(value) to shorten long numbers and only guarded against value errors and overflow errors, not the TypeError raised by float() on a datetime object. It now skips that numeric-shortening step for date/datetime values, like it already did for None.

opw-6276398

#xlsx#excel#accounting reports#dates

[FIX] l10n_hk_hr_payroll: fix IRD reports details

PR #121877

Enterprise19.0l10n_hk_hr_payrolltest_l10n_hk_hr_payroll_accountMEDIUM

This fixes details in Hong Kong IRD payroll reports so assessment years are calculated from the correct employee start or leaving dates. It also enforces that an “other” leaving reason includes an explanation, helping submissions meet IRD certification requirements.

Original PR description

As we now have complete support for IRD reports (in master), we started to try to get our system certified by the IRD.

A first submission highlighted a few issues that we are now fixing.

From 19.0:
    - In IR56F, the RTN_ASS_YR should be the tax year in which the employee left the company. E.g. after april, the next year.
    - In the same report, if the code for the cessation reason is 5 (other), the reason MUST be provided.
From 19.2:
    - Same change has to be done when setting RTN_ASS_YR for IR56G
    - A same change has to also be done for IR56E, based on the date the employee joined the company.

task-6332150

#Hong Kong payroll#IRD reports#tax compliance

[FIX] documents: fix the Actions menu with several documents selected

PR #123986

Enterprise19.0documentsMEDIUM

The Documents app now keeps the Actions menu usable when several documents are selected. This prevents users from getting stuck when trying to apply bulk actions, while preserving the correct selected-document count after uploads.

Original PR description

***Issue:*** Since https://github.com/odoo/enterprise/commit/8baaad621a1555680cd77ab514f626137b5b584d the div holding the selection box and the Actions menu carries t-key="targetRecords.length" in…

That t-key was added because the selection box shows a stale count after a file upload. The real problem is that SelectionBox caches this.root once in setup. The upload flow reloads the model, which replaces the root record list, and the box keeps counting the selection of the old one.

***Fix:***
Remove the t-key from documents_list_controller.xml and documents_kanban_controller.xml and make DocumentsSelectionBox read the current props.root instead of the value cached by the parent setup. The count follows the new record list after an upload without remounting anything, and the Actions menu is not recreated so its dropdown keeps working. The upload scenario stays covered by the existing multi_view.test.js test, a new test checks that the Actions menu opens with two selected documents.

***Steps to reproduce:***
1. Open the Documents app
2. Switch to the list view
3. Tick the checkboxes of two documents
4. Click the Actions button next to the "2 selected" box

=> the Actions dropdown does not open

Ticket [link](https://www.odoo.com/odoo/project.task/6365618)

opw-6365618

Forward-Port-Of: odoo/enterprise#123575

#documents#actions menu#bulk selection

**Issue:** The `default_type` context can leak into documents during creation with invalid values (e.g., 'sale' for documents.document.type), causing a ValueError. **Steps to reproduce - using MX EDI update payment:** - Use a Mexican company with CFDI credentials configured. - Create an invoice "payment policy = PPD", and send it to CFDI. - Create a bank transaction and reconcile it with the invoice. - Go to the Accounting Dashboard, remove current filters, and group by "Type" (this injects default_type into the context). - From there, enter the "Sales" journal and open the invoice. - Click on the "Update Payments" button. - Result: `ValueError: Wrong value for documents.document.type: 'sale'` **Fix:** Clean context from the `default_*` keys when transitioning from Accounting to Documents models. opw-6141172 opw-5742850 opw-6182877

Issue: The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as a zero-filled sequence According to CPA-005 standards on the Item Trace Number: "The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36). https://www.payments.ca/sites/default/files/standard005eng.pdf Steps to reproduce: 1. Install the module l10n_ca_payment_cpa005 2. Go into "CA Company" 3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC" 4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal 5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence 6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error) 7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT" 8. Create a batch payment for both payments created 9. Validate the batch payment and the export file should show up in the chatter 10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence Solution: Set the Item Trace Number to be the payment's id opw-6323432 Forward-Port-Of: odoo/enterprise#123707 Forward-Port-Of: odoo/enterprise#123633

Steps to reproduce: =================== 1. Create a rental product with a day-based rental period (e.g. 1 day) and a non-rental accessory product. 2. Add the rental product to the cart. 3. From the cart page, click "Add to cart" on the suggested accessory. => RPC error: ValueError: unconverted data remains: .999999 Root cause: =========== For rental products priced on a non-hourly recurrence, the cart's rental_return_date is stored as the end of day in the website timezone, i.e. with .999999 microseconds. The suggested-products button renders the rental dates as raw str(datetime) into its data attributes, and the accessory add-to-cart sent them verbatim to /shop/cart/add, where fields.Datetime.to_datetime() cannot parse microseconds. Fix: ==== Round-trip the data-attribute values through deserializeDateTime / serializeDateTime so the controller receives the standard server datetime format without microseconds, like every other renting flow. opw-6372176

Before this commit, columns with figure_type 'date'/'datetime', General Ledger's Date column, but also Partner Ledger, Aged Partner Balance, Bank Reconciliation and Customer Statement. were exported to XLSX as plain text strings instead of real Excel date values. _get_cell_type_value, which decides whether a cell must be written as a date or as text, only recognized a cell as a date when its 'class' contained 'date'. _build_column_dict, used by every report to build its column cells, never set that key, so the check always failed and cells fell back to text, even though figure_type was correctly set to 'date' on them. _build_column_dict now also sets 'class': 'date' on date datetime columns, the same convention already used by hand-built cells in account_followup This in turn revealed a second, so-far dormant issue: once real datetime values started reaching the XLSX writer, _set_xlsx_cell_sizes crashed while estimating the column width, as it unconditionally tried float(value) to shorten long numbers and only guarded against value errors and overflow errors, not the TypeError raised by float() on a datetime object. It now skips that numeric-shortening step for date/datetime values, like it already did for None. opw-6276398

As we now have complete support for IRD reports (in master), we started to try to get our system certified by the IRD. A first submission highlighted a few issues that we are now fixing. From 19.0: - In IR56F, the RTN_ASS_YR should be the tax year in which the employee left the company. E.g. after april, the next year. - In the same report, if the code for the cessation reason is 5 (other), the reason MUST be provided. From 19.2: - Same change has to be done when setting RTN_ASS_YR for IR56G - A same change has to also be done for IR56E, based on the date the employee joined the company. task-6332150

***Issue:*** Since https://github.com/odoo/enterprise/commit/8baaad621a1555680cd77ab514f626137b5b584d the div holding the selection box and the Actions menu carries t-key="targetRecords.length" in the documents list and kanban views, so every change of the selection count destroys and recreates everything inside it. Ticking a document checkbox updates both the selection and the focused record, and with these two updates the recreation goes wrong: the new ActionMenus component ends up destroyed while its button is still in the page. The dropdown click listeners are removed with the component, so clicking Actions does nothing until the selection changes again. That t-key was added because the selection box shows a stale count after a file upload. The real problem is that SelectionBox caches this.root once in setup. The upload flow reloads the model, which replaces the root record list, and the box keeps counting the selection of the old one. ***Fix:*** Remove the t-key from documents_list_controller.xml and documents_kanban_controller.xml and make DocumentsSelectionBox read the current props.root instead of the value cached by the parent setup. The count follows the new record list after an upload without remounting anything, and the Actions menu is not recreated so its dropdown keeps working. The upload scenario stays covered by the existing multi_view.test.js test, a new test checks that the Actions menu opens with two selected documents. ***Steps to reproduce:*** 1. Open the Documents app 2. Switch to the list view 3. Tick the checkboxes of two documents 4. Click the Actions button next to the "2 selected" box => the Actions dropdown does not open Ticket [link](https://www.odoo.com/odoo/project.task/6365618) opw-6365618 Forward-Port-Of: odoo/enterprise#123575