Wednesday, May 6, 2026
11 changes · saas-18.3
New functionality added to Odoo
This update prepares Odoo for a change in Belgian VAT regulations. Starting May 1st, businesses will need to use a new 'Tax Provision Account' (411800) instead of the previous account for periodic VAT returns. This ensures compliance with updated reporting requirements.
Original PR description
[IMP] l10n_be_reports: Add new VAT provision account Starting May 1st, in Belgium the VAT provision account will replace the current account for periodic returns - Adding the new bank account - Adding a new 'Tax Provision Account' 411800 task-6044017
Resolved issues and error corrections
This update resolves a bug that prevented the balance from being displayed correctly when reconciling foreign currency invoices. Specifically, a problem with how the system handled multiple currency selections was corrected, ensuring accurate balance calculations and visibility across different reconciliation scenarios. This improves the user experience when working with multi-currency transactions.
Original PR description
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction…
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected ### Cause: In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it There is no reason to block the sum of lines with the same currency When there is no selectedLines, the function returns early and doesn't unhide the balance ### Steps to reproduce: - Install `account_accountant` with demo data - Enable a foreign currency like EUR - Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€) - Go to the Dashboard, and select Bank - Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$) - Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency` - Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$) - Switch to the Kanban View and Reconcile the line Multi-currencies - Select your 2 invoices one by one Before the fix, after selecting the second invoice, the balance is displayed as `/` For the additional case: - Unselect all lines - Select a line in another currency (e.g., USD), then unselect it The balance remains hidden opw-6063366
This update resolves a duplication issue in the French Profit and Loss report by removing a mistakenly included account. The fix ensures accurate financial reporting for French businesses using Odoo Enterprise. This improves the reliability of financial data and aligns with accounting standards.
Original PR description
This commit is an addon to this commit[[1]] where we tried to avoid duplicate accounts in the Profit And Loss report. The problem is that we don't exclude the separated account 6492 from the original one (649). This commit adds the removal of this account in the report formula. task-6053784 Here is the coverage: [Profit and loss account (FR) - Accounts Coverage Report (2).xlsx](https://github.com/user-attachments/files/27011824/Profit.and.loss.account.FR.-.Accounts.Coverage.Report.2.xlsx) The correct separation: <img width="837" height="485" alt="image" src="https://github.com/user-attachments/assets/ebe98976-f689-4389-866a-c9a0c8b50534" /> [1]: https://github.com/odoo/enterprise/commit/4587c49c4b220305652150d2f21a95fb7cfa188d Forward-Port-Of: odoo/enterprise#115060 Forward-Port-Of: odoo/enterprise#114858
This update ensures that forced full packaging reservations are correctly applied, even when large quantities of a product are available. Previously, the system was incorrectly calculating reservations based on packaging multiples, leading to inaccurate stock levels. This fix now accurately reflects the intended behavior of reserving only full packaging units.
Original PR description
Issue ----- Forced full packaging reservation setting is ignored when there is a big quant in stock. Steps to reproduce ----- - Enable packagings - Create a product category "Super Category" -…
Issue
-----
Forced full packaging reservation setting is ignored when there is a big quant in stock.
Steps to reproduce
-----
- Enable packagings
- Create a product category "Super Category"
- Reserve Packagings: Reserve Only Full Packagings
- Create a stored product "AAA"
- Product Category: Super Category
- 50 units on hand
- Packaging: 6-Pack (6 units)
- Create a delivery for 15 units of AAA
> Reservation is made for 15 units
Cause
-----
The rounding to a multiple of the packaging quantity takes the stock quant into account. For our example case, we have 8 full 6-Packs on hand, so the `available_quantity` gets set to 48 when doing
https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L923-L925
This leads to the reservation quantity being min(15, 48) = 15
https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L927
-----
Ticket:
opw-5974333
Forward-Port-Of: odoo/odoo#262312
Forward-Port-Of: odoo/odoo#257342This update fixes an issue where manually adjusting lot quantities during manufacturing order production didn't always reflect the intended changes. The fix ensures that the specified lot quantities are correctly used when producing, preventing discrepancies in stock levels. This improves the accuracy of manufacturing processes.
Original PR description
**Issue** Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order. **Steps to reproduce** - Create a storable product P tracked by lot - Create two lots for…
**Issue** Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order. **Steps to reproduce** - Create a storable product P tracked by lot - Create two lots for product P with 2 units each - Create a MO for a product consuming two units P and confirm it - On the raw move, manually set 1 unit for each lot - Click on "Produce All" - Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each **Cause** While producing: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line: - Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297 - Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity **Solution** Assume that raw move lines being created in mrp without changing the producing quantity are manually created opw-5946439 Forward-Port-Of: odoo/odoo#259678 Forward-Port-Of: odoo/odoo#257258
This update resolves a technical error preventing the correct submission of Dutch VAT returns (SBR) for businesses with multiple branches under a single VAT unit. The fix ensures that only the relevant closing entry is used, avoiding a system error that previously blocked the SBR process. This improves the reliability of the VAT return submission.
Original PR description
In a multi-company/multi-branch setup where multiple entities form a single VAT unit, Odoo generates a closing entry for each branch/company during the tax closing process. When attempting to submit the Dutch VAT return via Digipoort (SBR), the wizard gathers these entries via `closing_move_ids`. However, the code subsequently tries to set the resulting recordset as `closing_entry_id` on `l10n_nl_reports.sbr.status.service`, which results in a traceback: `ValueError: Expected singleton: account.move(id1, id2, ...)` This occurs because `closing_entry_id` is a `Many2one` which requires a single record (singleton), but the system provides all closing moves from the tax group. This commit fixes the issue by filtering the closing moves to only target the one associated with the return company, ensuring a singleton is passed to the message posting logic. Issue introduced by: 647699eeb4b8a1cc37ca074fa57844871c5086c1 opw-6106081
This update fixes an issue where payment reminders weren't being sent to newly duplicated subscriptions. The root cause was a shared 'last_reminder_date' field, preventing new reminders from being triggered. The fix sets this field to 'false' for copied subscriptions, ensuring reminders are sent as expected.
Original PR description
Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription Steps to reproduce: 1. Install Subscriptions 2. Create a new…
Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription Steps to reproduce: 1. Install Subscriptions 2. Create a new subscription for customer Acme Corporation with product Office Cleaning Service (SUB), a Monthly recurring plan and in the Other Info tab, set the subscription Start Date to one week ago 3. Confirm the subscription 4. Go to Scheduled Actions and run the action "Sale Subscription: send reminder for subscriptions with no token" 5. Go back to the previously created subscription (see that a reminder email has been added in the chatter) 6. Duplicate the subscription and confirm the duplicate 7. Run the action "Sale Subscription: send reminder for subscriptions with no token" again 8. There are no reminder for the duplicate subscription Issue: The copy of a subscription uses the same `last_reminder_date`, preventing payment reminders to be sent here https://github.com/odoo/enterprise/blob/5a2ab62254cd5f684a3b1a0d7c0001b888c70d08/sale_subscription/models/sale_order.py#L2114-L2120 Solution: Set `copy=False` on the field `last_reminder_date` opw-6167356 Forward-Port-Of: odoo/enterprise#115509
This update fixes an issue where subscription delivery dates were incorrectly displayed as the previous day due to timezone differences. The change ensures delivery dates are accurately calculated based on the company's timezone, resolving a potential scheduling problem for subscription orders. This improves the reliability of delivery planning.
Original PR description
Steps to reproduce 1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3). 2. Create a sale order for a storable subscription product and confirm…
Steps to reproduce 1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3). 2. Create a sale order for a storable subscription product and confirm it. 3. Open the generated delivery order and check its Scheduled Date. Issue The scheduled date on the first delivery renders as the previous day. `_prepare_procurement_values` writes `date_planned` as `current_period_start`, which is a plain `fields.Date` value (https://github.com/odoo/enterprise/blob/ba41d7de3c0474286e3e9319710fdacfb95d3e2c/sale_subscription_stock/models/sale_order_line.py#L156). When a `date` is stored in the `Datetime` column `stock.move.date`, Odoo anchors it at midnight UTC; in any negative-offset timezone this renders as the previous day (e.g. `2022-03-02 00:00 UTC` shows as `2022-03-01 21:00` in UTC-3). The non-subscription path does not hit this because it resolves `date_planned` through `_expected_date()`, which returns `order_id.date_order` — a full `Datetime` set to `fields.Datetime.now()` at confirmation (https://github.com/odoo/odoo/blob/996702b0d5c518db2ac6f0b144e7835b27c29736/addons/sale/models/sale_order_line.py#L1398). The same midnight-UTC drift also affects later recurrences, where `current_period_start` falls back to `last_invoice_date` — another `Date`. Solution Split the two cases explicitly: - First delivery (`last_invoice_date` unset): set `date_planned` to `order_id.date_order`, matching the non-subscription flow. - Subsequent deliveries: localize `last_invoice_date` at `00:00` in the company timezone before converting back to UTC, reusing the pattern already applied to reordering rules (https://github.com/odoo/odoo/blob/20a0eee2d03293564320c268252a0353781d99ea/addons/stock/models/stock_orderpoint.py#L722). opw-6133831 Forward-Port-Of: odoo/enterprise#115100
This update resolves a crash that occurred when preparing future online food delivery orders. The issue stemmed from an incorrect delivery time format, which has now been corrected to ensure the preparation display functions smoothly and reliably.
Original PR description
### In this commit: Fixes a crash in the preparation display when handling future online food delivery orders. The issue was caused by an invalid delivery time format. This is resolved by properly passing the delivery time as a Number in the utils. Task-[5960176](https://www.odoo.com/odoo/project/1737/tasks/5960176)
This update corrects a bug where the Point of Sale dashboard incorrectly displayed all POS locations under only the primary warehouse, even when a different warehouse and operation type were configured. The fix ensures that POS locations automatically reflect the correct warehouse based on their operation type, improving accuracy and usability.
Original PR description
When filtering pos by warehouse_id, all pos are under the same warehouse even if we had configure an Operation Type from a different warehouse for a specific pos. Steps to reproduce: ------------------- * Setup a second warehouse in the company * Add the new POS operation type picking for the second warehouse on the POS settings * Group by warehouse in the POS dashboard > Observation: It always shows the first warehouse Why the fix: ------------ The warehouse_id field on pos.config was a plain Many2one with a static default that always set it to the first warehouse of the company. Convert warehouse_id into a computed stored editable field that derives from picking_type_id.warehouse_id. This ensures the warehouse stays in sync when the operation type changes, while still allowing manual override for the Ship Later feature. opw-6104652 Forward-Port-Of: odoo/odoo#262246 Forward-Port-Of: odoo/odoo#258830
This update ensures Odoo's Dutch reporting modules (SBR) correctly submit data to the new Digipoort infrastructure, which is migrating to digipoort.logius.nl by May 1, 2026. This change is critical to avoid submission failures and maintain compliance with Dutch regulations.
Original PR description
*: l10n_nl_reports_sbr{,_icp,_status_info}
---
Description of the issue this commit addresses:
The Dutch Digipoort endpoint infrastructure is being migrated from procesinfrastructuur.nl to digipoort.logius.nl effective May 1, 2026. Odoo's SBR modules need to use the new endpoints or submissions will fail.
---
Desired behavior after this commit is merged:
This commit updates all Digipoort endpoint URLs (delivery and status services) from the old domain to the new logius.nl domain, and clarifies that valid PKIoverheid certificates are required for both environments. Reports now submit to the new Digipoort infrastructure correctly.
---
task-6171403
Forward-Port-Of: odoo/enterprise#115668