Odoo Changelog — 2026-05-26

Tuesday, May 26, 2026

7 changes · 19.0

Bug Fixes(7)

Resolved issues and error corrections

[FIX] l10n_be_hr_payroll: Work address DMFA Integer constraint

Enterprise19.0l10n_be_hr_payroll

This update corrects a technical issue that could cause errors in the generation of payroll reports (DMFA). By adding a validation check to ensure only numerical characters are used, the system now reliably produces these reports without interruption. This ensures accurate and consistent payroll reporting.

Original PR description

Added a validation error in the _get_code function in case the code contains non-numerical characters.
This prevents non-numerical characters input from breaking the DMFA report PDF generation.

Task: 6231125

#payroll#reporting#be

[FIX] delivery_ups_rest: sanitise long province codes

PR #117203

Enterprise19.0delivery_ups_rest

A bug was preventing users from confirming shipments when the destination province was outside of the supported areas (USA, Canada, and Vietnam). This update ensures that UPS province codes are limited to a maximum of 5 characters, aligning with the UPS API requirements and preventing errors during shipment validation.

Original PR description

Issue
-----
Users cannot confirm shipments depending on the destination's province.

Steps to reproduce
-----
- Set up UPS
- Create a contact in Philipines
	- Province: Cebu
- Create a delivery
- Validate the delivery

> Error message

Cause
-----
Codes can only be 5 characters long, as per the API

https://developer.ups.com/tag/Shipping?loc=en_US#operation/Shipment

According to the doc, the field is only useful for USA, Canada and Vietnam.

-----
Ticket:
opw-6149404

#UPS#shipping#delivery

[FIX] sale_subscription: adapt query counter to current module usage

PR #118191

Enterprise19.0sale_subscription

This update optimizes how Odoo tracks subscription usage, leading to faster reporting and a smoother experience for users managing subscriptions. The change addresses a performance issue related to query counts, ensuring the system remains responsive even with a large number of subscriptions. This improvement focuses on internal system efficiency.

Original PR description

runbot-163667

Forward-Port-Of: odoo/enterprise#117266

#performance#reporting#subscriptions

[IMP] knowledge: scope and fix css rules for printers

PR #109379

Enterprise19.0knowledge

This update ensures Knowledge articles always load correctly when printing, regardless of how the print action is initiated. The changes also address potential rendering issues caused by the print stylesheet applying to other modules. CSS rules have been refined to target only the Knowledge view, improving print accuracy and stability.

Original PR description

Previously, the file containing the Knowledge print assets was lazy-loaded when the user triggered a print action through the UI. However, printing can also be initiated through other mechanisms…

Previously, the file containing the Knowledge print assets was lazy-loaded when the user triggered a print action through the UI. However, printing can also be initiated through other mechanisms (keyboard shortcuts, contextual menu, etc.), which prevented us from consistently detecting when to load the assets. In those cases, the assets were not loaded and the article appeared blank (see: odoo/enterprise#70243).

To ensure the assets are always loaded regardless of how printing is triggered, we moved them to the common print bundle and adopted the standard asset-loading approach. This change also simplifies the codebase by removing JavaScript workarounds previously used to load the assets dynamically.

However, some CSS rules in the Knowledge print stylesheet target global elements such as the web client container. Since the stylesheet is now included in a global asset bundle and always loaded, these rules apply to all modules and may cause rendering issues when printing views outside of Knowledge.

To prevent such side effects, the CSS rules in `knowledge_print.scss` will be updated to use more specific selectors. The rules will be scoped so they only apply when the container includes the Knowledge view (using the `:has`).

This PR also refactors the stylesheet by removing outdated rules that no longer match any elements. Several of these rules predate the major UI refactoring introduced in Odoo 16.

Task-5999878

[FIX] account_saft: SupplierID reference without matching Supplier

PR #118245

Enterprise19.0account_saft

This update corrects a technical issue where the FAIA report incorrectly referenced suppliers without matching supplier data. This prevented accurate reporting for certain companies, specifically those with no open balances. The fix ensures the report correctly identifies suppliers based on established criteria.

Original PR description

## Steps to reproduce:

1. Install `l10n_lu_reports`, swap to the LU company
2. Look at the partner Azure Interior.
    1. They have no open balances on `asset_receivable` or `liability_payable` accounts.
    2. Their `supplier_count` is higher than their `customer_count`.
3. Navigate to Accounting > Reporting > General Ledger.
4. Select the 2026 fiscal year.
5. Select gear > FAIA report.
6. Open the downloaded file. Notice:
    1. Azure Interior is listed under /MasterFiles/Customers/Customer.
    2. There are no /MasterFiles/Suppliers.
    3. Azure Interior's ID (14 in this case) is referenced in a /SupplierID section.
7. Take a gander at the official XSD for LU [1]. The SupplierID must match an element in /MasterFiles/Suppliers.

Video: [2]

## Explanation

This is one of several errors found with the FAIA export. See PR #113316 for more.

It's possible to have a /SupplierID listed on a /Transaction/Line element but not have a /Suppliers/Supplier element that it refers to. This is not valid according to the FAIA report's schema [1].

This happens because /Transaction/Line and /MasterFiles use different criteria to determine if a partner is a Customer or a Supplier.

The element /Transaction/Line [3] determines this from the `partner_vals['type']` value [4].  This value is 'customer' or 'supplier' and is determined by comparing the ResPartner fields `customer_rank` and `supplier_rank`. In case of a tie, the partner is assigned as a 'supplier'.

The element /MasterFiles allows a partner to be both a Customer and a Supplier via `partner_vals['types']` [5]. Partners with an open `asset_receivable` balance at the start or end of the reporting period are listed as Customers [6]. Likewise, partners with an open `liability_payable` balance are listed as Suppliers [7]. If there are no open balances, partners are put in the Customer list by default.

The XSD validation error will not show up in a standard Runbot database because the namespace for the XSD is incorrect. If you manually fix the XSD namespace (`xmlns:doc` instead of `xmlns`) and use xmllint to check a generated XML against the XSD, it will raise the following error.

> No match found for key-sequence ['14'] of keyref 'RefGLTransactionLineSupplier'. Downloads/general_ledger (5).xml fails to validate

[1] https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip. I will note that there are three XSDs. Version A has a different namespace and appears to be more restrictive. The "full" XSD document does not raise these errors.
[2] https://drive.google.com/file/d/1xeULpCcGgZk-kYcCjBTKxcfv4ICYRzaB/view?usp=sharing
[3] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L244-L248
[4] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L299
[5] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L303-L309
[6] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L153
[7] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L173

opw-6107107

Forward-Port-Of: odoo/enterprise#117799

[FIX] l10n_be_coda: reactivate commented test

PR #118226

Enterprise19.0l10n_be_coda

A technical issue where a test was incorrectly marked as commented instead of updated has been resolved. This fix ensures that the test accurately reflects the functionality of the l10n_be_coda module for Belgian accounting, preventing potential errors in reporting.

Original PR description

Test was commented instead of updated in this commit https://github.com/odoo/enterprise/commit/f1fafe0060c221e4a268c897af30455cc3d029ef

task-none

Forward-Port-Of: odoo/enterprise#118068
Forward-Port-Of: odoo/enterprise#117924

#accounting#Belgium#test

[FIX] hr_work_entry: tz issues with lunch & Work Entry reset

PR #114148

Enterprise19.0hr_work_entry_attendance

This update corrects a bug where resetting previous/next day Work Entries in payroll was unexpectedly deleting them. The issue stemmed from incorrect timezone handling, which caused the system to incorrectly nullify the Work Entry domain. The fix ensures accurate Work Entry management by using the correct calendar timezone.

Original PR description

Setup: Set the work entry source to attendance for an employee with active contract and change his timezone so that it differs from the working schedule one.

Reset previous/next day delete Work Entry (payroll)
- Step to reproduce: after an attendance was created, go to "Work Entries" in payroll, select the previous/next day and hit "Reset Selected Work Entries". The Work Entry will disappear.
- Cause: domain to nullify using wrong tz
- Solution: adjust domain to use calendar tz
- Test: testing positive ans negative tz in hr_work_entry_attendance (enterprise)

Task: 6072325

#payroll#work_entry#timezone#hr

Added a validation error in the _get_code function in case the code contains non-numerical characters. This prevents non-numerical characters input from breaking the DMFA report PDF generation. Task: 6231125

Issue ----- Users cannot confirm shipments depending on the destination's province. Steps to reproduce ----- - Set up UPS - Create a contact in Philipines - Province: Cebu - Create a delivery - Validate the delivery > Error message Cause ----- Codes can only be 5 characters long, as per the API https://developer.ups.com/tag/Shipping?loc=en_US#operation/Shipment According to the doc, the field is only useful for USA, Canada and Vietnam. ----- Ticket: opw-6149404

Previously, the file containing the Knowledge print assets was lazy-loaded when the user triggered a print action through the UI. However, printing can also be initiated through other mechanisms (keyboard shortcuts, contextual menu, etc.), which prevented us from consistently detecting when to load the assets. In those cases, the assets were not loaded and the article appeared blank (see: odoo/enterprise#70243). To ensure the assets are always loaded regardless of how printing is triggered, we moved them to the common print bundle and adopted the standard asset-loading approach. This change also simplifies the codebase by removing JavaScript workarounds previously used to load the assets dynamically. However, some CSS rules in the Knowledge print stylesheet target global elements such as the web client container. Since the stylesheet is now included in a global asset bundle and always loaded, these rules apply to all modules and may cause rendering issues when printing views outside of Knowledge. To prevent such side effects, the CSS rules in `knowledge_print.scss` will be updated to use more specific selectors. The rules will be scoped so they only apply when the container includes the Knowledge view (using the `:has`). This PR also refactors the stylesheet by removing outdated rules that no longer match any elements. Several of these rules predate the major UI refactoring introduced in Odoo 16. Task-5999878

## Steps to reproduce: 1. Install `l10n_lu_reports`, swap to the LU company 2. Look at the partner Azure Interior. 1. They have no open balances on `asset_receivable` or `liability_payable` accounts. 2. Their `supplier_count` is higher than their `customer_count`. 3. Navigate to Accounting > Reporting > General Ledger. 4. Select the 2026 fiscal year. 5. Select gear > FAIA report. 6. Open the downloaded file. Notice: 1. Azure Interior is listed under /MasterFiles/Customers/Customer. 2. There are no /MasterFiles/Suppliers. 3. Azure Interior's ID (14 in this case) is referenced in a /SupplierID section. 7. Take a gander at the official XSD for LU [1]. The SupplierID must match an element in /MasterFiles/Suppliers. Video: [2] ## Explanation This is one of several errors found with the FAIA export. See PR #113316 for more. It's possible to have a /SupplierID listed on a /Transaction/Line element but not have a /Suppliers/Supplier element that it refers to. This is not valid according to the FAIA report's schema [1]. This happens because /Transaction/Line and /MasterFiles use different criteria to determine if a partner is a Customer or a Supplier. The element /Transaction/Line [3] determines this from the `partner_vals['type']` value [4]. This value is 'customer' or 'supplier' and is determined by comparing the ResPartner fields `customer_rank` and `supplier_rank`. In case of a tie, the partner is assigned as a 'supplier'. The element /MasterFiles allows a partner to be both a Customer and a Supplier via `partner_vals['types']` [5]. Partners with an open `asset_receivable` balance at the start or end of the reporting period are listed as Customers [6]. Likewise, partners with an open `liability_payable` balance are listed as Suppliers [7]. If there are no open balances, partners are put in the Customer list by default. The XSD validation error will not show up in a standard Runbot database because the namespace for the XSD is incorrect. If you manually fix the XSD namespace (`xmlns:doc` instead of `xmlns`) and use xmllint to check a generated XML against the XSD, it will raise the following error. > No match found for key-sequence ['14'] of keyref 'RefGLTransactionLineSupplier'. Downloads/general_ledger (5).xml fails to validate [1] https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip. I will note that there are three XSDs. Version A has a different namespace and appears to be more restrictive. The "full" XSD document does not raise these errors. [2] https://drive.google.com/file/d/1xeULpCcGgZk-kYcCjBTKxcfv4ICYRzaB/view?usp=sharing [3] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L244-L248 [4] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L299 [5] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L303-L309 [6] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L153 [7] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L173 opw-6107107 Forward-Port-Of: odoo/enterprise#117799

Test was commented instead of updated in this commit https://github.com/odoo/enterprise/commit/f1fafe0060c221e4a268c897af30455cc3d029ef task-none Forward-Port-Of: odoo/enterprise#118068 Forward-Port-Of: odoo/enterprise#117924

Setup: Set the work entry source to attendance for an employee with active contract and change his timezone so that it differs from the working schedule one. Reset previous/next day delete Work Entry (payroll) - Step to reproduce: after an attendance was created, go to "Work Entries" in payroll, select the previous/next day and hit "Reset Selected Work Entries". The Work Entry will disappear. - Cause: domain to nullify using wrong tz - Solution: adjust domain to use calendar tz - Test: testing positive ans negative tz in hr_work_entry_attendance (enterprise) Task: 6072325