Wednesday, December 31, 2025
4 changes · 17.0
New functionality added to Odoo
This update incorporates new master data required to comply with recent changes to Brazilian fiscal regulations. The changes affect tax reporting and account configurations within the Odoo system, ensuring continued compliance with local tax laws. This update is crucial for businesses operating in Brazil.
Original PR description
task-4939796
Enhancements to existing features
This update prepares Odoo for Brazil's upcoming tax system changes in 2026, aligning with a phased rollout impacting consumption taxes. Businesses can enable this functionality based on their location and transaction types, and the update adapts our modules to integrate with Avalara for tax calculations. It ensures continued compliance 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 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
Resolved issues and error corrections
This update resolves a crash that occurred when users switched tabs while a receipt was being generated in Point of Sale. The fix ensures the receipt component is reliably loaded and accessible, preventing the printing process from failing. This improves the overall reliability of the PoS system.
Original PR description
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay…
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay button. 3. While loading (normally a few seconds to finish the invoice), switch the tab and stay there for few seconds (the time the invoicing has finsihed). 4. Come back to the initial page, a traceback will appear and the ticket is not printed. Why it happens: --------------- The receipt is printed when the parent of the `OrderReceipt`, i.e. `RenderContainer` is rendered. In this case, we assume that `OrderReceipt` has already had the time to be mounted and thus it's in the DOM, so in this case, `this.ref?.el?.firstElementChild` has the order receipt. However, when switching the tab, and since OWL uses `requestAnimationFrame` as a scheduler, and since the browser will throttle `requestAnimationFrame` when the tab is not active, we will not have access to the order receipt component in its parent's `onRendered`! The fix ------- Instead of seeing the parent renders as a sign that its child has been successfully put in the DOM, we now renders the child component (OrderReceipt) in its own container and thus we can hook into its `onMounted` lifecycle where we know for sure that this component has been successfully mounted and attached to the DOM, and can be accessed through `this.ref?.el?.firstElementChild`. opw-5124585
This update fixes an issue where searching for serial numbers in the stock barcode view could return incorrect results. By adding a context, the system now correctly handles searches from the list view, ensuring more accurate and reliable stock tracking. This improves data integrity and user confidence.
Original PR description
Issue --> On the Lots/Serial Numbers view, with GS1 enabled, searching by a serial number can cause search arguments to get warped, unbeknownst to the end user. This can return unexpected results in the list view. Solution --> Add a context that skips the _preprocess_gs1_search_args method if the search is done from the list/graph view. This solution retains usage for any other purposes of the method. Community PR --> https://github.com/odoo/enterprise/pull/82989 opw-4574666