Odoo Changelog — 2026-04-16

Thursday, April 16, 2026

7 changes · 17.0

New Features(1)

New functionality added to Odoo

[ADD] pos_alipay

Core17.0point_of_saleMEDIUM

This update introduces Alipay as a new payment method within Odoo PoS, enabling sales in China and Hong Kong. It includes features like payment inquiries, notifications, and cancellations, expanding Odoo's payment options for key markets.

Original PR description

Introduction:

Alipay is a China leading third-party online payment solution.
It is useful to integrate the feature into Odoo PoS system for China Market
and Hong Kong Market.

Features list:

- New PoS payment method, Alipay
- Alipay inquiry payment flow
- Alipay notification/webhook flow
- Alipay cancel payment flow

task-3631513

#payments#china#hong kong#alipay

Bug Fixes(6)

Resolved issues and error corrections

[FIX] l10n_be_hr_payroll: remove tracking on non-stored holiday pay f…

PR #113015

Enterprise17.0l10n_be_hr_payroll

This update resolves a test failure related to the calculation of holiday pay for Belgian employees. The fix removes tracking from a specific field, ensuring it's only computed when needed and preventing incorrect initial values from being set. This ensures accurate holiday pay calculations moving forward.

Original PR description

…ield

The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures.

Previously, the `tracking_disable` context prevented early computation.

The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests.

task: 6095445

#payroll#holiday pay#Belgium

[FIX] account_{asset,reports}: remove wrong/obsolete translations

PR #106998

Enterprise17.0account_assetaccount_reports

This update corrects and streamlines translations for the account asset and reports modules in French (fr_BE, fr_CA, and nl_BE). Outdated or incorrect translation overrides have been removed, ensuring consistent and accurate language across Odoo. This improves the user experience for French-speaking customers.

Original PR description

There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead.

In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct.

task-5921458

#translation#localization#french

[FIX] account: correct rounding precision of total amount price

PR #255035

Core17.0account

This update corrects a rounding issue that caused slight discrepancies in product prices including taxes, particularly when setting prices to exact tax-inclusive amounts. The fix ensures that displayed prices are consistently accurate, improving the reliability of product pricing and financial reporting. This resolves a previous UI display problem.

Original PR description

### Issue before this commit:
When setting a product price intended to result in a clean tax-included amount (e.g., 24€ with a 21% tax), the computed “price including taxes” displayed in the UI was slightly off due to rounding issues. Instead of returning exactly 24.00, the system would display values such as 23.99 or 24.01.

### Steps to reproduce the issue:
1. Download l10n_be and switch to the BE company
2. Create a new product and be sure the tax is setted on 21%
3. Try to insert a price =24/1.21
4. The computed price Incl. taxes inside the brackets is never 24.0 but or 23.99 or 24.01

### Cause of the issue:
When the base_round was not setted to False the calculation was taking t he currency precision to round the number from the start of the calculations even if the number of digits setted was higher. This way the rounding will be computed only at the end of the calculations instead of being already setted from the start.

### Reason to introduce the fix:
Be able to represent all the numbers as the final price for one product.

opw-6024520

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#pricing#taxes#currency

[FIX] base: report actually failing rules in AccessError

PR #259344

Core17.0base

This update fixes a misleading error message that appeared when accessing archived records. Previously, the system incorrectly reported all access rules as failing, even when a specific rule was blocking access. Now, the system accurately identifies the specific rule causing the access error, improving user experience and troubleshooting.

Original PR description

When accessing an archived record directly, if access is prevented by a record rule other than a multi-company global rule, the error message incorrectly reports that all rules are failing, suggesting a company issue even though it is not the actual cause.

The problem is that when access is denied, the diagnostic method `_get_failing` is used to determine which rules are failing. This method performs several count queries with different rule domains. However, `active_test` is True by default, excluding archived records from the count, causing the rule evaluation to miss some records and incorrectly mark rules as failing.

With this commit, `_get_failing` evaluates rules with `active_test=False`, ensuring that only actually failing rules are reported.

#access rights#archived records#error reporting

[FIX] website: avoid persisting legacy cookies bar value

PR #259585

Core17.0website

This update resolves a technical problem where the website cookies bar incorrectly persisted a value, leading to potential issues with website performance and response headers. The fix prevents the cookie bar's state from being incorrectly set when the user doesn't explicitly accept or reject it, improving website stability.

Original PR description

Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup`…

Steps to reproduce:
- Set the cookies bar
- Do not accept nor reject it
- On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set.

`Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`.

This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed.

That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx.

Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`.

opw-6037573

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Backport of: https://github.com/odoo/odoo/pull/258938

#cookies#performance#website

[FIX] account_edi_ubl_cii: Select taxes that match the fiscal position country

PR #255848

Core17.0account_edi_ubl_ciiMEDIUM

This update fixes an issue where vendor bills were incorrectly using Swiss taxes instead of the correct Belgian taxes. The change ensures that the fiscal position country is accurately reflected during invoice import, preventing errors in tax calculations and compliance. This improves data accuracy for financial reporting.

Original PR description

**Steps to reproduce:**
- Create a company in Belgium and set the fiscal localisation accordingly.
- In the same company, create a fiscal position in Switzerland, set the foreign tax ID and then generate the taxes for it.
- Install the module account_edi_ubl_cii.
- Create and invoice for a belgian customer, with one product line having a 0% tax.
- Export the invoice as XML.
- Go to taxes, filter by purchase, and make sure that the 0% switzerland tax has a higher sequence than the belgian 0% tax.
- Import the previous invoice XML as a vendor bill.

**Issue:**
After importing the bill, the switzerland tax is used even though the fiscal localisation is belgian, which is wrong as it violates the constraint _validate_taxes_country

**Solution:**
Added a more selective domain to _import_fill_invoice_line_taxes

opw-5467936
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#tax#invoice#vendor bill#fiscal position

Introduction: Alipay is a China leading third-party online payment solution. It is useful to integrate the feature into Odoo PoS system for China Market and Hong Kong Market. Features list: - New PoS payment method, Alipay - Alipay inquiry payment flow - Alipay notification/webhook flow - Alipay cancel payment flow task-3631513

…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445

There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458

### Issue before this commit: When setting a product price intended to result in a clean tax-included amount (e.g., 24€ with a 21% tax), the computed “price including taxes” displayed in the UI was slightly off due to rounding issues. Instead of returning exactly 24.00, the system would display values such as 23.99 or 24.01. ### Steps to reproduce the issue: 1. Download l10n_be and switch to the BE company 2. Create a new product and be sure the tax is setted on 21% 3. Try to insert a price =24/1.21 4. The computed price Incl. taxes inside the brackets is never 24.0 but or 23.99 or 24.01 ### Cause of the issue: When the base_round was not setted to False the calculation was taking t he currency precision to round the number from the start of the calculations even if the number of digits setted was higher. This way the rounding will be computed only at the end of the calculations instead of being already setted from the start. ### Reason to introduce the fix: Be able to represent all the numbers as the final price for one product. opw-6024520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

When accessing an archived record directly, if access is prevented by a record rule other than a multi-company global rule, the error message incorrectly reports that all rules are failing, suggesting a company issue even though it is not the actual cause. The problem is that when access is denied, the diagnostic method `_get_failing` is used to determine which rules are failing. This method performs several count queries with different rule domains. However, `active_test` is True by default, excluding archived records from the count, causing the rule evaluation to miss some records and incorrectly mark rules as failing. With this commit, `_get_failing` evaluates rules with `active_test=False`, ensuring that only actually failing rules are reported.

Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`. This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed. That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx. Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`. opw-6037573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Backport of: https://github.com/odoo/odoo/pull/258938

**Steps to reproduce:** - Create a company in Belgium and set the fiscal localisation accordingly. - In the same company, create a fiscal position in Switzerland, set the foreign tax ID and then generate the taxes for it. - Install the module account_edi_ubl_cii. - Create and invoice for a belgian customer, with one product line having a 0% tax. - Export the invoice as XML. - Go to taxes, filter by purchase, and make sure that the 0% switzerland tax has a higher sequence than the belgian 0% tax. - Import the previous invoice XML as a vendor bill. **Issue:** After importing the bill, the switzerland tax is used even though the fiscal localisation is belgian, which is wrong as it violates the constraint _validate_taxes_country **Solution:** Added a more selective domain to _import_fill_invoice_line_taxes opw-5467936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr