Odoo Changelog — 2026-05-14

Thursday, May 14, 2026

7 changes · master

Bug Fixes(7)

Resolved issues and error corrections

[FIX] account_reports: handle report when fiscal year ends on Feb 29

Enterprisemasteraccount

This update resolves an error that occurred when users set their fiscal year's end date to February 29th. The fix ensures reports accurately calculate dates, regardless of whether the fiscal year is a leap year or not. This prevents reporting issues related to incorrect date calculations.

Original PR description

**Steps to Reproduce:**
1. Install the Accounting module.
2. Go to Settings and set the fiscal year's last day to 29 February.
3. Accounting > Reporting > open any report.

**Error:**
`ValueError - day is out of range for month`

**Cause:**
At [1], a fixed year (2025) is used to compute the fiscal year end. However, 2025 is not a leap year, so creating a date with February 29 raises an error.

**Fix:**
Ensure that when the fiscal year’s last day is Feb 29, a leap year (2024) is used for the computation. For all other dates, the year remains unchanged (2025).

As a result;
- If the last day is February **28** (non-leap year) -> `fy_start` becomes **March 1** 
- If the last day is February **29** (leap year) ->  `fy_start` also becomes **March 1**

[1] - https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/account_reports/models/account_report.py#L820

sentry-7438598965

Forward-Port-Of: odoo/enterprise#115400

#reporting#fiscal year#date calculation

[FIX] quality_control: prevent error when creating quality check

PR #117341

Enterprisemasterquality_control

This update prevents a critical error that occurred when creating quality checks from quality points. The issue arose when a product wasn't specified, causing a system error. This fix ensures quality checks can be created successfully under all circumstances, improving data integrity and usability.

Original PR description

When creating a quality check from a quality point, a traceback occurs if no product is set.

Steps to reproduce the error:
- Install ``quality_control`` module with demo data
- Go to Quality > Quality Control > Control Points > Create a new Control point >
  Set Control per: Quantity, Partial Test: 99 > Save
- Click on Quality Checks smart button > Click on New

Traceback:
```py
ValueError: Expected singleton: uom.uom()
```

https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/quality_control/models/quality.py#L369 During creation of a quality check, ``product_id`` is not set.
The compute method ``_compute_qty_to_test`` accesses ``product_id.uom_id``,
which leads to the above traceback.

sentry-7440188763

Forward-Port-Of: odoo/enterprise#115292

#quality#checks#error

[FIX] sale_subscription: fix TypeError

PR #116933

Enterprisemastersale_subscriptionMEDIUM

This update resolves a technical issue preventing v19.1 upgrades of subscription orders. The problem stemmed from a comparison between a boolean value and a date field during invoice calculation, causing an error. This fix ensures correct invoice generation for subscription orders.

Original PR description

**Steps-to-Reproduce** - In v19, install subscriptions. - create new subscription + service product with allow one time sale enabled. - make a SO with that product,any reccuring plan and any end…

**Steps-to-Reproduce**
- In v19, install subscriptions.
- create new subscription + service product with allow one time sale enabled.
- make a SO with that product,any reccuring plan and any end date. 
```
id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 1_draft            |                   | 2026-05-02
```

- confirm the SO
```
 id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 3_progress         | 2026-05-01        | 2026-05-02
```
- remove its recurring plan (some product sold for months for testing then converted to one time sale )
```
 id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 3_progress         |                   | 2026-05-02
```

- upgrade to v19.1 will fail or opening sales > To Invoice > Orders To Invoice gives this error or add amount_to_invoice in list view using studio to produce in v19 :
```
File "/home/odoo/odoo18/enterprise/sale_subscription/models/sale_order_line.py",
 line 175, in _compute_amount_to_invoice
    and (not order.end_date or order.next_invoice_date < order.end_date)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'bool' and 'datetime.date'
```

- upgrade failing for v19.1 because amount_to_invoice added to list view [here](https://github.com/odoo/odoo/commit/427232efd121410380b62acf4fd2e9ee369e6542#diff-48cb4309a6006f91b2b40e4c1049860218d419fce1782c7dcc278329803129caR193-R213).

upg - [4220658](https://upgrade.odoo.com/odoo/upgrade.request/4220658)
opw - [6128033](https://www.odoo.com/odoo/project/70/tasks/6128033)

Forward-Port-Of: odoo/enterprise#116477
Forward-Port-Of: odoo/enterprise#115976

#subscriptions#invoice#error

[FIX] l10n_cz_reports_2025: correct values of discount lines in vies report

PR #117361

Enterprisemasterl10n_cz_reportsMEDIUM

This update fixes an issue where discount lines in Czech VAT reports were incorrectly calculating values. The previous method used absolute values, leading to inflated report totals. The fix now correctly handles negative discount amounts, ensuring accurate reporting of VAT liabilities. This ensures compliance with Czech regulations.

Original PR description

Step to reproduce:
- install l10n_cz_reports_2025 and switch to cz company
- create a invoice, with cz company ( as partner), of 100.
- when adding products, add "Transaction code" (optional fields) to "Goods"
- Add discount line, set to -10, add "Transaction code" in this line too.
- confirm it

Observation:
- invoice is 90$
- open vies summary report for this year
- value turn out to 110

Cause:
- commit [1](https://github.com/odoo/enterprise/commit/892268c44b1bbc838a9f03ef36a079bfff625ca6) converts every balance to +ve and only negate it, in case of refund
- in case of discount lines, price is -ve, ABS() turn it to +ve and value comes out to be wrong

Fix:
- instead of applying ABS() directly, we flip the signs only for out_* moves,
in short when a account is credited, its balance is < 0 then we flip its sign

opw- 5979262

Forward-Port-Of: odoo/enterprise#117038
Forward-Port-Of: odoo/enterprise#113087

#reporting#vat#czech

[FIX] l10n_no_reports: fix VAT declaration XML validation errors

PR #117329

Enterprisemasterl10n_noMEDIUM

This update corrects errors in the Norwegian VAT XML export that were preventing successful validation by the Skatteetaten tax authority. The changes ensure the XML adheres to strict government rules regarding decimal formatting, rounding, and required legal notes, allowing VAT returns to be submitted correctly.

Original PR description

Before commit:
The Norwegian VAT XML export fails Skatteetaten validation due to incorrect
decimal formatting, mathematical rounding mismatches between base and tax
amounts, missing mandatory legal notes, and invalid KID number formats.

Fix:
To strictly follow Skatteetaten validation rules for the Norway VAT XML, the
following changes were implemented:
- Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted 
  fractional rates like `11.11` to `11,11` in XML.
- Rounded down the `tax_amount` to align precisely with government mathematical
  expectations.
- `base_amount` converted into absolute value to ensuring the calculation
  (`base * rate = tax`) resolves perfectly.
- Add the mandatory `<merknad>` explaining the reverse charge method for codes
  81, 83, 86, 88, and 91.
- Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix.

Expect:
The generated XML payload now adheres perfectly to Skatteetaten's strict
structural and mathematical rules, allowing the VAT return to pass government
validations successfully.

Related Community PR: https://github.com/odoo/odoo/pull/258390

Task-6033027

Forward-Port-Of: odoo/enterprise#117168
Forward-Port-Of: odoo/enterprise#110792

#vat#norway#tax#xml#compliance

[FIX] l10n_mx_edi_pos, l10n_pe_edi_pos: clean tests after `pos_stock` refactor

PR #117294

Enterprisemasterl10n_mx_edi_posl10n_pe_edi_pos

This update cleans up tests related to the recent restructuring of the POS stock functionality. Previously, tests were referencing outdated stock-related data, which has now been removed to align with the new `pos_stock` module. This ensures the tests accurately reflect the current system.

Original PR description

Issue:
======
- Some tests were still using stock-related fields and groups that were
previously part of `pos`, but were moved to a new module `pos_stock` after
the refactor.

Fix:
=====
- Remove references to these fields from the tests, as stock-related logic is
now handled in `pos_stock` module.

Task-6183114
Error-242928,243017,243059
Related Community PR: https://github.com/odoo/odoo/pull/262719

Forward-Port-Of: odoo/enterprise#116185

#pos#edi#stock#test

[FIX] sign: restore 'waiting for me' filter behavior

PR #117379

Enterprisemastersign

The 'Waiting for Me' filter in the Sign app was incorrectly fetching all documents instead of filtering those requiring the current user's signature. This update corrects a technical issue related to how the system processes filter criteria, ensuring the filter functions as intended and only displays relevant documents.

Original PR description

When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.

Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me

Observed Behavior:
All the documents are fetched.

Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.

Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown

From:
`('need_my_signature', '=', True)]`

To:
`[('need_my_signature', 'in', [True])]`

This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.

As a result, instead of filtering documents, all documents are returned.

[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108

[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177

Fix:
Corrected the return domain logic to fetch the correct documents.

opw-6026935

Forward-Port-Of: odoo/enterprise#117049
Forward-Port-Of: odoo/enterprise#113760

#sign#filter#workflow

**Steps to Reproduce:** 1. Install the Accounting module. 2. Go to Settings and set the fiscal year's last day to 29 February. 3. Accounting > Reporting > open any report. **Error:** `ValueError - day is out of range for month` **Cause:** At [1], a fixed year (2025) is used to compute the fiscal year end. However, 2025 is not a leap year, so creating a date with February 29 raises an error. **Fix:** Ensure that when the fiscal year’s last day is Feb 29, a leap year (2024) is used for the computation. For all other dates, the year remains unchanged (2025). As a result; - If the last day is February **28** (non-leap year) -> `fy_start` becomes **March 1** - If the last day is February **29** (leap year) -> `fy_start` also becomes **March 1** [1] - https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/account_reports/models/account_report.py#L820 sentry-7438598965 Forward-Port-Of: odoo/enterprise#115400

When creating a quality check from a quality point, a traceback occurs if no product is set. Steps to reproduce the error: - Install ``quality_control`` module with demo data - Go to Quality > Quality Control > Control Points > Create a new Control point > Set Control per: Quantity, Partial Test: 99 > Save - Click on Quality Checks smart button > Click on New Traceback: ```py ValueError: Expected singleton: uom.uom() ``` https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/quality_control/models/quality.py#L369 During creation of a quality check, ``product_id`` is not set. The compute method ``_compute_qty_to_test`` accesses ``product_id.uom_id``, which leads to the above traceback. sentry-7440188763 Forward-Port-Of: odoo/enterprise#115292

**Steps-to-Reproduce** - In v19, install subscriptions. - create new subscription + service product with allow one time sale enabled. - make a SO with that product,any reccuring plan and any end date. ``` id | name | subscription_state | next_invoice_date | end_date ----+--------+--------------------+-------------------+------------ 1 | S00001 | 1_draft | | 2026-05-02 ``` - confirm the SO ``` id | name | subscription_state | next_invoice_date | end_date ----+--------+--------------------+-------------------+------------ 1 | S00001 | 3_progress | 2026-05-01 | 2026-05-02 ``` - remove its recurring plan (some product sold for months for testing then converted to one time sale ) ``` id | name | subscription_state | next_invoice_date | end_date ----+--------+--------------------+-------------------+------------ 1 | S00001 | 3_progress | | 2026-05-02 ``` - upgrade to v19.1 will fail or opening sales > To Invoice > Orders To Invoice gives this error or add amount_to_invoice in list view using studio to produce in v19 : ``` File "/home/odoo/odoo18/enterprise/sale_subscription/models/sale_order_line.py", line 175, in _compute_amount_to_invoice and (not order.end_date or order.next_invoice_date < order.end_date) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: '<' not supported between instances of 'bool' and 'datetime.date' ``` - upgrade failing for v19.1 because amount_to_invoice added to list view [here](https://github.com/odoo/odoo/commit/427232efd121410380b62acf4fd2e9ee369e6542#diff-48cb4309a6006f91b2b40e4c1049860218d419fce1782c7dcc278329803129caR193-R213). upg - [4220658](https://upgrade.odoo.com/odoo/upgrade.request/4220658) opw - [6128033](https://www.odoo.com/odoo/project/70/tasks/6128033) Forward-Port-Of: odoo/enterprise#116477 Forward-Port-Of: odoo/enterprise#115976

Step to reproduce: - install l10n_cz_reports_2025 and switch to cz company - create a invoice, with cz company ( as partner), of 100. - when adding products, add "Transaction code" (optional fields) to "Goods" - Add discount line, set to -10, add "Transaction code" in this line too. - confirm it Observation: - invoice is 90$ - open vies summary report for this year - value turn out to 110 Cause: - commit [1](https://github.com/odoo/enterprise/commit/892268c44b1bbc838a9f03ef36a079bfff625ca6) converts every balance to +ve and only negate it, in case of refund - in case of discount lines, price is -ve, ABS() turn it to +ve and value comes out to be wrong Fix: - instead of applying ABS() directly, we flip the signs only for out_* moves, in short when a account is credited, its balance is < 0 then we flip its sign opw- 5979262 Forward-Port-Of: odoo/enterprise#117038 Forward-Port-Of: odoo/enterprise#113087

Before commit: The Norwegian VAT XML export fails Skatteetaten validation due to incorrect decimal formatting, mathematical rounding mismatches between base and tax amounts, missing mandatory legal notes, and invalid KID number formats. Fix: To strictly follow Skatteetaten validation rules for the Norway VAT XML, the following changes were implemented: - Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted fractional rates like `11.11` to `11,11` in XML. - Rounded down the `tax_amount` to align precisely with government mathematical expectations. - `base_amount` converted into absolute value to ensuring the calculation (`base * rate = tax`) resolves perfectly. - Add the mandatory `<merknad>` explaining the reverse charge method for codes 81, 83, 86, 88, and 91. - Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix. Expect: The generated XML payload now adheres perfectly to Skatteetaten's strict structural and mathematical rules, allowing the VAT return to pass government validations successfully. Related Community PR: https://github.com/odoo/odoo/pull/258390 Task-6033027 Forward-Port-Of: odoo/enterprise#117168 Forward-Port-Of: odoo/enterprise#110792

Issue: ====== - Some tests were still using stock-related fields and groups that were previously part of `pos`, but were moved to a new module `pos_stock` after the refactor. Fix: ===== - Remove references to these fields from the tests, as stock-related logic is now handled in `pos_stock` module. Task-6183114 Error-242928,243017,243059 Related Community PR: https://github.com/odoo/odoo/pull/262719 Forward-Port-Of: odoo/enterprise#116185

When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature. Steps to reproduce: 1) Install sign with demo data 2) Open sign app and remove default filter 3) Add a filter Waiting for me Observed Behavior: All the documents are fetched. Expected Behavior: Documents should be filtered out to only show those where the current user is a signer. Root Cause: Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown From: `('need_my_signature', '=', True)]` To: `[('need_my_signature', 'in', [True])]` This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature. As a result, instead of filtering documents, all documents are returned. [1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108 [2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177 Fix: Corrected the return domain logic to fetch the correct documents. opw-6026935 Forward-Port-Of: odoo/enterprise#117049 Forward-Port-Of: odoo/enterprise#113760