Friday, April 17, 2026
5 changes · 17.0
Resolved issues and error corrections
This update fixes an error in how stock valuations are calculated when receiving foreign currency purchases with auto-standard products. Previously, incorrect currency exchange entries were created, leading to inaccurate inventory values. This change ensures that stock valuations accurately reflect the cost of goods, regardless of currency.
Original PR description
This is a backport of https://github.com/odoo/odoo/pull/243029 The same bug is reproducible in 17.0 Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will…
This is a backport of https://github.com/odoo/odoo/pull/243029 The same bug is reproducible in 17.0 Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation To reproduce the issue: (Company in USD) 1. Enable EUR and define the rates as followed: - Yesterday: 2 - Today: 2.5 2. Create a product category: - Method: Standard - Valuation: Automated 3. Create a product P in that category - Cost: 10 USD 4. [Yesterday] Confirm a PO in EUR with 1 x P 5. [Yesterday] Receive it 6. Bill Error: the stock valuation has two entries: one with 10 USD debit, the receipt. Another one with 2 USD credit, the currency exchange rate difference. The second one is a mistake, in a standard configuration, the stock valuation should be impacted by nothing but the cost defined on the product form. Since https://github.com/odoo-dev/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7, in some conditions the method `_get_exchange_account` returns the stock valuation account. This is what happens here, but it's a mistake since in the above case, we should stick with the classic account (i.e. the `super` call). The conditions must be more strict. opw-5905197
This update fixes an issue where the Italian tax module was incorrectly removing parts of VAT numbers when generating XML invoices for Spanish partners. The fix ensures that VAT numbers, like 'A95758389', are accurately exported to the tax agency, preventing data discrepancies and potential compliance problems. This improves the reliability of invoice data transmission.
Original PR description
**Steps to reproduce:** * Install `l10n_it_edi` module. * Create a partner with country **Spain** and VAT `A95758389`. * Create an invoice and send it to the Tax Agency, and download XML. **Observed behavior:** * The exported XML contains `5758389` in <IdCodice> instead of `A95758389` — the first two characters of the VAT are silently dropped. **Cause:** * In `_l10n_it_edi_get_values`, the EU branch that strips the country-code prefix used a bare `else` after the `isdecimal()` check, unconditionally removing the first two characters of any VAT that does not start with two digits. Spanish NIFs like `A95758389` start with `A9` (letter + digit), which is not a country-code prefix but was treated as one, corrupting the value. **Fix:** * Remove country prefix from normalized VAT by `removeprefix(normalized_country)` Instead of removing the first two characters. It will ensure that only the country prefix will be removed. opw-6089198
This update corrects a problem where invoice exports to FAIA were failing due to inconsistencies in how account IDs were referenced. The change ensures that all account IDs in the export match those defined within Odoo's accounting system, improving the reliability of financial reports. This resolves an issue impacting accurate reporting.
Original PR description
This is one of several commits fixing the FAIA xml export. The Invoice/Line/AccountID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match an account defined in MasterFiles/GeneralLedgerAccounts/Account/AccountID. As the latter uses account_code since PR #65221, the former should too. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296)
This update resolves an issue where entering an invalid Taiwan VAT number (e.g., containing letters) would cause the invoicing system to crash. The fix adds validation to ensure the VAT number consists only of digits, providing a clear warning message to the user instead of an error.
Original PR description
**Steps to reproduce:** - Install the `base_vat` module. - Navigate to Invoicing > Customers. - Create a new contact and set the country to `Taiwan`. - Enter `1234567A` as the `Tax ID` and try to `save`. **Error:** `ValueError: invalid literal for int() with base 10: 'A'` **Root cause:** At [1], `check_vat_tw` is missing validation to ensure that the VAT number (without the country code) contains only digits, which causes an error when calling the `int()` method on the VAT number. **Fix:** This commit prevents errors and ensures users receive a `clear warning message`. [1]: https://github.com/odoo/odoo/blob/23398d24e108875b2838715d4b366df265d53234/addons/base_vat/models/res_partner.py#L929-L958 **No task Id**
This update fixes an issue where the web interface could crash when retrieving data due to outdated cached information. The change ensures a safer and more reliable way of filtering x2many records, aligning the system with recent improvements and preventing potential errors. This enhances overall web performance and stability.
Original PR description
Description of the issue/feature this PR addresses: This is a follow-up to #250904. The original 17.0 fix filtered inaccessible x2many records reused from cache during web_read. However, while…
Description of the issue/feature this PR addresses:
This is a follow-up to #250904.
The original 17.0 fix filtered inaccessible x2many records reused from cache during web_read. However, while forward-porting the fix to 18.0, additional issues were revealed.
The original issue is still cache pollution: web_read may reuse cached x2many ids that are not accessible anymore with the current record rules/context, and should neither expose them nor crash when formatting the result.
The 18.0 investigation showed that the first approach was not enough in all cases:
* using search([('id', 'in', ...)]) to filter x2many records is not always safe, as some models can override search() and raise errors
* using _filtered_access('read') unconditionally can also be too aggressive when the current user has no general read access on the comodel, as it may remove valid x2many values and break existing flows.
This PR backports the adjusted logic from the 18.0 forward-port to 17.0, so that 17.0 stays aligned with the later versions.
Current behavior before PR:
Even after the previous fix, web_read can still mishandle polluted cached x2many values in some cases, either by crashing while trying to filter/order the records, or by over-filtering them when the user has no general read access on the comodel.
Desired behavior after PR is merged:
web_read should keep filtering polluted x2many values when the user has read access on the comodel, while avoiding regressions for fields whose comodel is not generally readable by the current user.
The x2many values are therefore filtered in a safer way, aligned with the logic introduced in the 18.0 forward-port.
Backport-Of: #257517
X-original-commit: 05ded3eda89fb8ff9aafa62f314a9d5d4677d292 (cherry picked from commit 7eec72aadc294b1c2780e601e81636cffcc4965d)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr