Daily updates from Odoo
Wednesday, December 31, 2025
4 changes · 19.0
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 Avalara's requirements for tax calculation and EDI.
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…
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
Resolved issues and error corrections
This update enhances the preparation display filters in the Point of Sale module, offering more flexible options for managing order preparation. Specifically, it adds multi-select time and preset filters, and ensures the category filter is always visible, streamlining the process for staff.
Original PR description
- Time filter: * Remove "All" option (now default) * Add "Now" option for unscheduled and next-slot orders * Allow multi-selection - Preset filter: * Add multi-select preset filter * Only shown if related POS configs use presets - Category/Product filter: * Always show pos.category filter (even if no preparation card contains this category) * Move category/product filters below Time and Preset filters task: https://www.odoo.com/odoo/project/1737/tasks/5060221 community PR: https://github.com/odoo/odoo/pull/233920 Forward-Port-Of: odoo/enterprise#95136
This update fixes an issue where certain POS presets weren't correctly displayed in self-service ordering modes (kiosk and mobile). Now, presets are only shown if they're available in self-service and, in specific cases, require a slight configuration change to ensure they appear correctly.
Original PR description
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset…
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset was not available in self, this preset was used as the default one. But now, it's not the case anymore. We only use it if, and only if, it is available in self. The second thing was to fix the "Dine In" preset availability in the eating location choices. A dine-in preset is a preset which have service_at == table as attribute. If this preset (is `available_in_self`) and has `service_at === table`, we only show it when there is a table_identifier in the URL or when we are in the kiosk. In all other cases, it'll never be shown. If user wants to see this preset in the kiosk or in the mobile menu without table_identifier, user needs to change the `service_at` field at `counter` (or `delivery`) and put the product as `available in self` as well. task-id: 5190541 community pr:https://github.com/odoo/odoo/pull/234522
This update corrects a technical problem that could occur when duplicating Odoo databases. The fix ensures that a calculation within the HR Job Post module handles recordsets of multiple records correctly, preventing an error that would have disrupted database operations. This improves database stability and reliability.
Original PR description
These two computes assume a recordset of size 1. When duplicating databases, the recordset for this method might be more than 1, causing a "Expected singleton" traceback. See opw-5226545 (and linked TOTD thread) Forward-Port-Of: odoo/enterprise#99424