Saturday, October 18, 2025
3 changes · 19.0
Resolved issues and error corrections
This fixes a failure scenario in the Chilean electronic invoicing email import process. If an attached tax document cannot be decoded, the system now avoids leaving the import job in a broken database state, helping scheduled email processing continue more reliably.
Original PR description
During l10n_cl_edi's fetchmail cron, if the decoding of a DTE attachment fails, `_create_records_from_attachments` rolls back the transaction, which prevents the savepoint in `_fetch_mail` from being…
During l10n_cl_edi's fetchmail cron, if the decoding of a DTE attachment fails, `_create_records_from_attachments` rolls back the transaction, which prevents the savepoint in `_fetch_mail` from being restored. Doing a commit/rollback within a `cr.savepoint()` is not correct. Since a new transaction is started, the savepoint no longer exists. Failing to restore the savepoint leaves the transaction in a broken state. Thus, we need to remove either the savepoint or the commit + rollback performed by `_create_records_from_attachments`. See https://github.com/odoo/odoo/issues/230014 We can remove the savepoint because `_extend_by_attachments` already catches exceptions which typically represent decoding errors (such as ValidationError, UserError, ValueError, psycopg2.errors.IntegrityError). These errors are recoverable from a transaction point of view; the import fraw recover from them by leaving an empty invoice with the attachment. Other errors are typically not recoverable and it does not makes sense to attempt to recover from them using a `cr.savepoint()`. opw-5147385 Forward-Port-Of: odoo/enterprise#97158
Companies based outside the EU can now save valid European VAT numbers without being blocked by validation rules for their own country. This prevents unnecessary errors for international businesses that legitimately hold EU VAT numbers.
Original PR description
****Behavior:**** **Current:** When a company is assigned a VAT number, the integrity of the VAT is checked according to the rules of the company's country except when a EU country is assigned an other EU country's VAT, then the integrity of the VAT is checked according to the other EU country's rules. **Expected:** We want to allow Foreign companies to have valid European VAT numbers. **Steps to reproduce:** - Create a new contact, select company and add any name - Select a country that is not in the EU and has implemented the VAT system (Ex: China, Australia | Some countries, like the US or some smaller countries, don't have an implementation in Odoo, or just dont use VATs, in that case they are allowed to put whatever in the VAT field) - Input a valid EU VAT number in the Tax ID field (ex: FR17698800935) - when saving, the system should raise a Validation Error. opw-5080231 Forward-Port-Of: odoo/odoo#231999 Forward-Port-Of: odoo/odoo#231177
This fixes rounding errors when taxes are included in item prices, preventing small mismatches between line totals and their tax breakdowns. It also simplifies the tax calculation logic so country-specific accounting rules, such as Portugal and Mexico localizations, are easier to maintain.
Original PR description
== Fix bug price-included == Suppose a line of 24.99 with a 20% tax price-included. base: 24.99 / 1.2 = 20.825 tax: 20.825 * 0.2 = 4.165 If we round both, we get 20.83 + 4.17 = 25.0 != 24.99 == Split and simplify round_base_line_tax_details == Easier implementation of this method to be easier to understand and easier to be customized (see PT override). Also, we now use the aggregate methods to aggregate the amounts instead of doing that by hand. opw-4505888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232025 Forward-Port-Of: odoo/odoo#228437