Daily updates from Odoo
Saturday, August 1, 2026
6 changes · 19.0
Enhancements to existing features
Payment XML files now include the building number field required by upcoming ISO 20022 address standards. This helps keep SEPA credit transfer and direct debit exports compliant ahead of the November 2026 mandate, reducing future payment processing risks.
Original PR description
This commit adds the <BldgNb> node in the iso20022 XML files, as it will be mandatory starting November 2026. Linked: https://github.com/odoo/odoo/pull/271855 task-6317758 Forward-Port-Of: odoo/enterprise#126298 Forward-Port-Of: odoo/enterprise#121674
Resolved issues and error corrections
This fixes an error that blocked users from confirming several Brazilian customer invoices at once when Avalara Brazil tax mapping was enabled. Businesses can now process invoice batches without interruption, improving billing reliability and reducing manual workarounds.
Original PR description
**_Steps to reproduce:_** * Install `l10n_br_avatax` and configure Avalara Brazil. * Create at least two customer invoices. * Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara…
**_Steps to reproduce:_** * Install `l10n_br_avatax` and configure Avalara Brazil. * Create at least two customer invoices. * Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara Brazil)**. * Select the invoices and click **Action → Confirm Entries**. **_Observed behavior:_** * A traceback is raised with `ValueError: Expected singleton: account.move(...)` and the invoices cannot be validated. **_Cause:_** * During tax extraction, `_extract_tax_values_from_l10n_br_avatax_detail` accesses `self.invoice_filter_type_domain` while `self` may contain multiple `account.move` records. * Accessing `invoice_filter_type_domain` on a multi-recordset raises an `Expected singleton` error, preventing the validation of multiple invoices. **_Fix:_** * Build the returned tax values by iterating over each invoice in the recordset and using the corresponding `invoice_filter_type_domain`. * This ensures `_extract_tax_values_from_l10n_br_avatax_detail` correctly handles multiple invoices during validation without raising a singleton error. opw-6334761
Basic users can now open the spreadsheet creation dialog in Documents even when they do not have access to spreadsheet templates. This removes an inconsistent limitation and lets them create empty spreadsheets from the kanban view like other document types.
Original PR description
A basic user can access the document app and create all types of documents from the kanban view except for the spreadsheets because it requires an access to the templates. While the user cannot interact with the templates, they should have the possibility to create an empty spreadsheet. Note that it can already be done coming from the view of a spreadsheet! This revision ensures that the user can indeed access the spreadsheet creation modal even if they don't have access to the spreadsheet templates. Task-6364964 Forward-Port-Of: odoo/enterprise#126231 Forward-Port-Of: odoo/enterprise#123003
The POS preparation display order-count badge now uses the same rules as the preparation screen. This prevents orders from disappearing from the badge after midnight or remaining counted after a reset, giving staff a consistent view of pending work.
Original PR description
Steps to reproduce: - Configure a preparation display on a POS config with a product category - Place an order and leave it in a non-final stage - Keep the session open past midnight Issue: The…
Steps to reproduce: - Configure a preparation display on a POS config with a product category - Place an order and leave it in a non-final stage - Keep the session open past midnight Issue: The kanban order-count badge drops the order once its create_date falls behind "today", while the preparation screen still lists it. The same divergence makes the badge keep counting an order that a "Reset" already removed from the screen. _compute_order_count() scoped its search on pos_config_id and create_date >= today, whereas the screen is built by get_preparation_display_order() from _get_open_orders_in_display() and _get_stageless_orders_in_display(), which have no date filter and instead bound the set by the order stage `done` flag and the session state. An order open across midnight is therefore in the screen set but not in the badge set. Conversely reset() marks the current stage done, which drops the order from the screen set, but the badge only skipped orders whose latest stage is the final stage, so an order reset while still in the first stage stayed counted. opw-6414302 Forward-Port-Of: odoo/enterprise#126139 Forward-Port-Of: odoo/enterprise#125984
This fix ensures Indian localization reports classify POS and other non-purchase entries correctly when determining transaction type. It prevents general journal POS moves from being treated as purchases and updates existing databases with the corrected values.
Original PR description
Description: In #118297 non-sales journal moves were considered purchase moves during l10n_in_transaction_type computation, which is not correct for POS moves as their journal is of type 'general'. Fix: Compare only the purchase journal moves state against the partner state. Other moves treated as sales and their state compared against the company state. Add a migration script to update existing databases. opw-638646
This fix prevents deleted products in kiosk self-order flows from being incorrectly tracked when the Belgian blackbox module is installed. It helps avoid checkout or compliance-related errors when customers change their order before confirming.
Original PR description
Fix issue when deleting a product in the Kiosk with the blackbox module installed task-id: 6438820 community pr: https://github.com/odoo/odoo/pull/279778