Wednesday, December 31, 2025
5 changes · 18.0
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 continues to accurately handle Brazilian tax reporting and compliance, supporting our business operations in the Brazilian market. The changes affect tax reporting data.
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. The changes adapt our existing modules to comply with the new requirements, primarily impacting tax calculations and EDI processes.
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 prevents a payment error that occurred when invoices with missing due dates were processed. The fix ensures correct invoice calculations and payment processing by prioritizing invoice lines with due dates, resolving a potential disruption to financial operations.
Original PR description
Currently, an error occurs when a user attempts to pay an invoice. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):** - Install the `Accounting`…
Currently, an error occurs when a user attempts to pay an invoice. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):** - Install the `Accounting` module. - Go to `Payment Terms` and create `a new Payment Term` with at `least two Due Term lines`. - Go to `Invoices` and `create a new Invoice`. - Add one invoice line and set the `Payment Term` to the `newly created payment term`. - In the `Journal Items` tab > `Enable the Due Date` column (optional hidden). - From the two `Receivable journal items`, remove the `Due Date` from one of the `receivable lines`. - Now `Confirm the invoice` and `Click on Pay`. **Error:** `TypeError: '<' not supported between instances of 'datetime.date' and 'bool'` **Cause:** This error occurs when the user clicks Pay, than it going to calculate the total amount to pay from here [1]. If the payment term has more than one term line, it creates more than one receivable invoice line, and the receivable invoice lines are sorted from here [2]. When two or more invoice lines have the same move_id, they are sorted based on the due date. However, if one of the receivable lines does not have a due date, the error is raised. Similarly, as shown in [3], when the system retrieves the installment data, it sorts the lines based on the due date and raises the same error. **Fix:** This commit ensures that when there is no due date on any receivable invoice line and two lines belong to the same invoice, the comparison uses the maximum date as like here [4] and places that line at the end for that invoice, thereby maintaining the correct flow. The same fix is applied while retrieving the installment data, as described above. [1]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L703 [2]- https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L635 [3]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L3305 [4]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L522 sentry-713241246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 optimizes how Odoo handles web socket connections, particularly under heavy load. By delaying cursor acquisition attempts, the system reduces connection failures and improves overall responsiveness, especially when dealing with a large number of simultaneous users.
Original PR description
Benchmarking with 4k connected clients, 1 message per second. | | Message dispatching | Cursor analysis | |-- |-- | -- | | Before|<img width="600" alt="image" src="https://github.com/user-attachments/assets/f02e7efc-4611-4356-8bef-386ff2b0a7da" />|<img width="600" alt="2_current_implementation__cursor_analysis" src="https://github.com/user-attachments/assets/04dce96e-74a6-4f1b-9918-a6c61913e7c4" />| |After|<img width="600" alt="image" src="https://github.com/user-attachments/assets/a9463484-7f69-4fcb-a248-5692893a8893" />|<img width="600" height="997" alt="8_tweak_delay_both_sleep__cursor_analysis" src="https://github.com/user-attachments/assets/34a2c233-5c36-4597-a55b-cfb89a41efcf" />| Forward-Port-Of: odoo/odoo#241330
This update optimizes how product category information is loaded in the product screen, resolving a performance bottleneck. Previously, the loading process was slow and inefficient, particularly when dealing with many product categories. This change significantly improves the speed and responsiveness of the product screen, enhancing the user experience.
Original PR description
Before this commit, the product category info loading was done in O(n^2) time complexity due to nested loops. It caused performance issues when loading a large number of product categories. opw-5442894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr