Saturday, March 28, 2026
7 changes · saas-19.1
Resolved issues and error corrections
This update fixes an issue where quarterly VAT returns in the Italian module didn't automatically generate the required XML export files. The fix correctly uses the 'date_to' field for quarter detection, ensuring accurate XML generation. This allows users to properly file their quarterly tax returns.
Original PR description
## Issue: When the tax return periodicity is set to quarterly and the return is validated, the XML file is not generated and downloaded ## Cause: The quarter detection logic was based on the `date_from` field of the return However, for quarterly returns, the correct reference should be `date_to` Using `date_to` also works correctly for monthly returns ## Steps to reproduce: - Install `l10n_it_xml_export` - Switch to the IT Company - Go in the Tax Report (Monthly VAT Report (IT)) to do a Tax Return (Opening Date: 01/01/2025, Periodicity: Quarterly) - If needed change the Tax Return Periodicity in Settings to Quaterly - Select the first report and ignore the error in Review Before the fix, it is only possible to close the return without generating the XML export opw-5707544 Forward-Port-Of: odoo/enterprise#111370 Forward-Port-Of: odoo/enterprise#108548
This update resolves an issue where the system incorrectly identified direct deposit accounts due to changes in Wise's API. The fix ensures the system consistently handles both 'swift_code' and 'SwiftCode' formats, preventing errors and ensuring accurate processing of direct deposit payments. This improves reliability and avoids potential payment failures.
Original PR description
Internally, Wise has changed their return value of their API to sometimes return `swift_code` and other times return `SwiftCode` depending on the create time of the recipient account. If the account is older than a few months it will use `SwiftCode` as the return value of GET /v2/accounts when they are created with type `swift_code` in the POST. As such, to be defensive this code handles both cases to not make any assumptions in case users have old or new accounts. This stops a traceback where the system doesn't think it's a swift account and tries to access abartn even though it doesn't exists. task-6070033 Forward-Port-Of: odoo/enterprise#112075
This update fixes a test failure related to optional discount line editing within the sale_management module. The test was incorrectly placed in the sale module, causing a runbot issue. Moving the test to the correct location ensures proper functionality and stability of the discount editing process.
Original PR description
Issue: --- `is_optional` does not exist in `sale` module, leading to runbot issue. The test needs to be moved to `sale_management`. runbot-242127 Forward-Port-Of: odoo/odoo#256099
This update resolves a technical issue that was causing instability in Odoo's VoIP testing. The fix ensures that event listeners are properly removed after tests, preventing memory leaks and improving the reliability of the test suite. This ultimately contributes to a more stable and dependable Odoo platform.
Original PR description
Forward-Port-Of: odoo/odoo#256376
This update fixes a performance issue related to Odoo's translation caching. Previously, when a translated field was updated, it could trigger unnecessary recalculations of other dependent fields, even if those fields used a different language value. Now, Odoo will retain existing translation caches, improving speed and efficiency when updating related fields.
Original PR description
when related translated field (field_x) is changed when onchange, if another computed fields which depends on the field_x is recomputed but using another language value of the field_x. The orm should keep the existing translations in the cache but not drop them. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256324 Forward-Port-Of: odoo/odoo#256111
A technical issue with how Odoo processed spreadsheet data was causing errors. This update corrects a problem where a trailing character in the spreadsheet's JSON format was preventing it from being correctly read and used. This ensures the spreadsheet data is processed reliably.
Original PR description
Steps to reproduce: - Share the Sales Commission spreadsheet - Open the shared link ⮕ traceback This was caused by the trailing line break in the json, so the last character was not a `}`. Task: 6064328 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256475 Forward-Port-Of: odoo/odoo#255523
This update corrects a problem where the date format in EDI export files was inconsistent due to timezone differences between the database and test environments. The fix ensures that all dates are generated using the correct UTC timestamp, improving the accuracy and reliability of the EDI data. This impacts sales order generation and reporting.
Original PR description
The Issue: Before this commit, the generated EDI XML used `sale_order.create_date.date()` to populate the IssueDate node, while the test used `datetime.today().date()` to build the expected value. Since `create_date` is a UTC timestamp set by the database and `datetime.today()` returns the local system time, these diverge when the server timezone is ahead of UTC and the test runs shortly after local midnight (e.g., runbot at 01:00 CET produces UTC date Jan 11 vs local date Jan 12). The Fix: Align the test to derive its expected date from `so.create_date.date()` instead of `datetime.today().date()`, ensuring both sides use the same timezone-consistent source of truth. runbot-237841 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256065