Wednesday, December 31, 2025
6 changes · saas-18.4
New functionality added to Odoo
This update incorporates new master data for Brazil, aligning with recent changes to the country's fiscal regulations. These adjustments ensure Odoo accurately reflects Brazilian tax requirements, improving compliance and financial reporting for businesses operating in Brazil. The changes primarily affect tax reporting and account configurations.
Original PR description
task-4939796 Forward-Port-Of: odoo/odoo#240988
Enhancements to existing features
This update prepares Odoo for Brazil's upcoming shift to a new consumption tax system starting in 2026. Users can enable this new system based on their business location and transaction types, and the changes impact both tax calculations and electronic data interchange (EDI) processes. This ensures Odoo remains compliant with evolving Brazilian tax regulations.
Original PR description
2026 marks the start of Brazil's 8-year plan to migrate to a completely new consumption tax system [1]. The new system is meant to be simpler than the old one, but we defer to Avalara for tax…
Resolved issues and error corrections
This update automatically marks UrbanPiper orders as paid in Odoo when they are marked as 'dispatched'. This prevents order cancellations due to cashier oversight and ensures accurate order status tracking, improving the POS process.
Original PR description
*= urban_piper, black_box_be In this commit: =============== - When UrbanPiper updates an order to `dispatched`, we now automatically mark the order as paid in Odoo. - This prevents the order from being cancelled during the POS session closing if the cashier forgot to mark it as ready. - Also, we are adding this urban piper order to the blackbox, if it was not recorded in it. Task: 5261892 X-original-commit: 808cf7b3f8c185053dac5cbf75307efa67fd6e90 Forward-Port Of:odoo/enterprise#99513
2026 marks the start of Brazil's 8-year plan to migrate to a completely new consumption tax system [1]. The new system is meant to be simpler than the old one, but we defer to Avalara for tax calculation so we don't really notice it technically. The old and new system have to coexist for the foreseeable future because the rollout happens gradually over many years. Whether the new system has to be enabled depends on the federal state the business is in, the type of transactions they do, and other factors. The user has the option to enable it through the l10n_br_is_icbs Boolean flag on the company, which gates all the new functionality. These changes impact both tax calculation and EDI. This set of modules adapts our existing l10n_br* modules to the new requirements set out by Avalara. We are required to send extra values to their API, and in some cases adapt existing ones. task-4939796 [1] https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp214.htm Forward-Port-Of: odoo/enterprise#102706
This update fixes an issue where users could inadvertently change product taxes while items were already in their shopping cart. Now, users can still modify product details but tax updates are restricted when a product is in the cart, ensuring order accuracy and consistency.
Original PR description
- When a product is already in the cart, prevent updating its taxes from the frontend product edit popup. This avoids inconsistencies between the product taxes and the taxes applied to the order line. - Now we can still edit other fields of the product. task-id: 4943650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures invoices exported with distance selling correctly use the foreign VAT number defined for the customer's fiscal position. Previously, the company's VAT was incorrectly used, leading to inaccurate VAT reporting. This fix improves invoice accuracy and compliance with EU regulations.
Original PR description
When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it. Steps to reproduce: 1.…
When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it. Steps to reproduce: 1. Install a European localization (ex: l10n_at) 2. Enable EU Intra-community Distance Selling. You should now have new OSS fiscal positions. Update the one you want to use with a foreign VAT. 3. Create a valid foreign customer. (within the EU) 4. Create and send an invoice for this customer. 5. In the PDF, there is an embedded factur-x file. Notice how the VAT number under the SellerTradeParty corresponds to the company's VAT, not the foreign VAT number defined on the fiscal position. This is more apparent because we use the correct VAT number in the PDF file but not in the corresponding XML. This commit fixes this issue by first checking if we have a foreign VAT number defined on the fiscal position of the invoice. If so, we use it. opw-5182837 Forward-Port-Of: odoo/odoo#237666 Forward-Port-Of: odoo/odoo#236692
This update resolves an issue where Odoo invoices with discounts generated for Nemhandel failed validation. The fix ensures that discounts are correctly accounted for in the invoice data, allowing these invoices to be successfully transmitted to customers. This improves the reliability of our Nemhandel integration.
Original PR description
Before this fix, all the OIOUBL invoices with a discount generated by Odoo would fail the schematron validation, meaning they can't be sent to the customer through Nemhandel. The schematron enforces that the discount is taken into account at the PriceAmount, to keep the rules on lineExtensionAmount working. Also changes the import to understand that it's a discount. opw-5379474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241614