Wednesday, May 6, 2026
12 changes · saas-18.3
New functionality added to Odoo
This update prepares Odoo for a change in Belgian tax regulations. Starting May 1st, businesses will need to use a new 'Tax Provision Account' (411800) for VAT periodic returns, replacing the previous account. This ensures compliance with updated Belgian accounting standards.
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 fixes an issue where the HTML editor's undo function sometimes restored the selection to the wrong position. The fix ensures the selection is properly 'staged' before deletion, guaranteeing accurate restoration during undo operations. This improves the user experience and prevents data inconsistencies.
Original PR description
Problem: In some cases, undo restores the selection to an incorrect position. Cause: The selection state was not staged before the deletion started, leading to an inconsistent selection being restored during undo. Solution: Stage the selection before performing the deletion to ensure it can be restored to the correct position. Steps to reproduce: - Go to To-Do → Create New. - Type something on the first line and press Enter. - Type something on the second line and apply styling to it. - Use the Up arrow key to move to the first line. - Remove a character. - Press Undo (Ctrl + Z). - Observe that the selection and toolbar appear on the second line. task-6142055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260630
This update resolves a technical error that prevented users from selecting cash payments on POS terminals when using Razorpay. The fix ensures the system correctly handles payment selections, improving the reliability of the POS payment process. This change enhances the overall user experience for cash transactions.
Original PR description
Steps: - Open a POS configuration with the Razorpay payment method set to all payment modes. - Process an order and initiate a Razorpay transaction. - Select a cash payment option on the terminal. Issue: - A traceback occurs with the error: `Cannot read properties of null (reading 'replace')`. Cause: - The code attempts to call the replace method on a null value. Fix: - Ensure the replace method is called only when the value is a valid string. Task-6190355 Forward-Port-Of: odoo/odoo#261922
This update fixes a minor error in the French version of the Profit and Loss report. The term "exceptionnel" was incorrectly using masculine form when it should be feminine to accurately reflect charges. This ensures correct reporting and compliance with French accounting standards.
Original PR description
There was a small typo in section 8 of the pnl report. "exceptionnel" must go feminine when referring to charges. Forward-Port-Of: odoo/enterprise#116198
This update resolves an issue where internal transfers using multi-step routes in the RO edi stock batch module were incorrectly flagging a missing delivery carrier. The fix ensures that carrier validation is skipped for internal movements, streamlining the process and preventing unnecessary errors. This improves the efficiency of internal stock transfers.
Original PR description
### Issue: With `l10n_ro_edi_stock_batch`, internal transfers using multi-step routes were requiring a delivery carrier This makes no sense for internal moves ### Cause: The method…
### Issue: With `l10n_ro_edi_stock_batch`, internal transfers using multi-step routes were requiring a delivery carrier This makes no sense for internal moves ### Cause: The method `_compute_l10n_ro_edi_stock_enable` was overridden to check for `not picking.batch_id` However, for multi-step delivery routes, internal pickings still triggered the carrier validation, as no check on the `picking_type` was performed ### Steps to reproduce: - Install `l10n_ro_edi_stock_batch` with demo data and switch to RO Company - In Settings, enable `Multi-Step Routes` - Set the RO Warehouse's Outgoing Shipments to `Pick then Deliver (2 steps)` - Create a Product (e.g. RO product) - Create a Delivery Method (e.g. RO Delivery, Partner: Any, Delivery Product: RO Product) - Create and Confirm a Sale Order for the RO Product - From the Sale Order, click Delivery and validate the picking ### Before the fix, internal transfers raised: `The picking RO Co/PICK/00001 is missing a delivery carrier.` enterprise-PR: https://github.com/odoo/enterprise/pull/114166 opw-5925087 Forward-Port-Of: odoo/odoo#257293
This update resolves an issue that prevented users from modifying warehouse routes in the Romanian (RO) accounting module. The problem stemmed from incorrect data handling when updating routes, causing a system error. This fix ensures that warehouse route changes can now be made without interruption.
Original PR description
### Issue: When changing the routes of a Romanian warehouse, an error is raised, blocking any modification of multi-step routes ### Cause: The code attempts to access `in_type_id` from `warehouse_data` However, when updating routes, `warehouse_data` is empty in the method `_create_or_update_sequences_and_picking_types` This leads to a crash because the code assumes that `warehouse_data` always contains `in_type_id` and `out_type_id` Additionally, even if the data were present, it would result in creating duplicate `stock.picking.type` records ### Steps to reproduce: - Install `l10n_ro_saft_stock` with demo data and switch to `RO Company` - Enable `Multi-steps Routes` in Settings - Try to modify Incoming or Outgoing Shipments on a warehouse - When saving, the following error is raised: "Oh snap! in_type_id" odoo-pr: https://github.com/odoo/odoo/pull/257293 opw-5925087 Forward-Port-Of: odoo/enterprise#114166
This update prevents subscriptions from being automatically reopened after manual closure by a salesperson. Previously, approvals or payments could trigger reopening, leading to inconsistencies. This change ensures subscriptions remain closed as intended, streamlining the subscription management process.
Original PR description
Before this commit, when a subscription was closed manually by the salesperson, it could be reopened when a transaction was approved or an invoice paid. It could cause issue. In this case, we should not reopen automatically. task-5900481 Forward-Port-Of: odoo/enterprise#106487
This update fixes a display issue in push notifications for inbox users. Previously, notifications contained escaped characters, resulting in a broken message. Now, users receive the full, correctly formatted notification content, ensuring accurate and clear alerts.
Original PR description
**Steps to reproduce:** Log in as admin and ensure notifications are handled in Odoo. Enable push notifications and the 'Task Created' subtype for a project. As a second user, create a new task in…
**Steps to reproduce:** Log in as admin and ensure notifications are handled in Odoo. Enable push notifications and the 'Task Created' subtype for a project. As a second user, create a new task in that project. **Current behavior before PR:** admin received escaped content in the push notification (e.g., `A new task has been created in the "Project Name" project`) **Cause:** For inbox users, we send a client-side push notification using `previewText` as the body. This field returns a markup object containing escaped characters, which are converted to a string when passed to the notification body. Since the notification body only accepts plain text, these characters are displayed literally to the user. **Desired behavior after PR is merged:** admin receives the unescaped content in the push notification. (e.g., `A new task has been created in the "Project Name" project`) task-5112810 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a test failure in the 'pos_self_order' module that occurred due to a discrepancy in how time slots were generated. The fix freezes the time to '00:00' to ensure all available slots are considered for each day, improving the reliability of the order scheduling process. This ensures accurate order processing and prevents potential disruptions.
Original PR description
Before this commit: = - The test test_slot_limit_orders created slots only for the first day of the week (Monday). - The test scenario includes a slot at "18:00". - On Mondays, the test fails between 18:01 and 23:59 because the "18:00" slot no longer exists for the current day. - On other days, the test passes since slots are generated for the upcoming Monday. After this commit: = - Freezed the time to current day at "00:00" so that slot list can have every slot for that day. task-6043739 runbot-241836
This update fixes a discrepancy in how the invoiced quantity is calculated for sales orders, particularly when dealing with packaged products. Previously, rounding differences led to an inaccurate displayed quantity. The change ensures consistent rounding across delivered and invoiced quantities, improving data accuracy and order reporting.
Original PR description
Steps to reproduce: --- - Install the `Sales and Inventory` modules. - Enable `Units of Measure & Packagings` from Settings. - Go to `Sales > Configuration > Products > Units & Packagings.` - Create…
Steps to reproduce: --- - Install the `Sales and Inventory` modules. - Enable `Units of Measure & Packagings` from Settings. - Go to `Sales > Configuration > Products > Units & Packagings.` - Create a new unit > Pack of 12 with quantity 12 and unit Units. - Create a new product > enable Track Inventory, set Quantity On Hand to 100, and in the `sales` tab, under `Upsell & Cross-Sell`, set `packaging` as` Pack of 12`. - Create a Sales Order > add the product and set the quantity to 3, with a unit Pack of 12. - Confirm the order and validate the delivery. - Create and confirm the invoice. - Return `1 unit` from the delivery and validate it. - From the invoice, create a `credit note` with quantity 1 unit and confirm it. - Go back to the Sales Order. Issue: --- - On the Sales Order: `Delivered Quantity` shows` 2.92` while `Invoiced Quantity` shows `2.91`. Root cause: --- - At [1] & [2], in `_compute_qty_invoiced`, the `_compute_quantity` method is called without specifying a `rounding_method`, so it defaults to `UP` (1/12 rounded to 0.09), while `_compute_qty_delivered` explicitly uses `HALF-UP` (1/12 rounded to 0.08), leading to inconsistent rounding. Solution: --- - In this PR, the same rounding method (HALF-UP) is applied when computing the invoiced quantity to ensure consistency with the delivered quantity. [1]https://github.com/odoo/odoo/blob/64c1f1a7d3b24ca613d0b29a2412f1094fea08d9/addons/sale/models/sale_order_line.py#L896-L912 [2]https://github.com/odoo/odoo/blob/64c1f1a7d3b24ca613d0b29a2412f1094fea08d9/addons/sale_stock/models/sale_order_line.py#L193-L209 opw-6073690 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258024
This update corrects a bug preventing free FSM services with prepaid invoicing from appearing on invoices. Previously, the system incorrectly set the invoice quantity to zero. Now, these services will correctly appear on invoices, ensuring accurate billing for prepaid FSM tasks.
Original PR description
Changed _compute_qty_to_invoice in industry_fsm_sale, SaleOrderLine to no longer set qty_to_invoice to 0 for free services with prepaid invoicing. Previous changes seem intended for goods. Steps to reproduce: - Create service product with 0 price, prepaid invoice policy, creates FSM task - Create/Confirm sales order with created product - Attempt to create invoice, get 0 quantity to invoice error Current Behavior: Free services linked to FSM tasks do not appear on invoices due to compute 0 qty_to_invoice Expected Behavior: Prepaid Invoice Services linked to FSM tasks appear on invoices. Other invoice policies can be invoiced through the generated sales order lines (timesheets, delivered quantity, etc.) opw-6047992 Forward-Port-Of: odoo/enterprise#113718
This update automatically refreshes the payment screen when the PIS payment status changes. Previously, users needed to manually refresh the page to see the updated status, leading to delays. This improvement ensures payment information is always current and accurate.
Original PR description
There were some buttons like sign payment that were visible even when the PIS status was signed which needed a manual page refresh for the update to reflect, now it's reflected automatically on the PIS status change. task-5417365 Forward-Port-Of: odoo/enterprise#114299