Daily updates from Odoo
Wednesday, May 6, 2026
11 changes · saas-18.2
Resolved issues and error corrections
This update resolves a bug that prevented users from modifying warehouse routes in the Romanian (RO) accounting version of Odoo. The issue stemmed from incorrect data handling during route updates, causing a system error. This fix ensures that warehouse routes can now be safely adjusted without disruption.
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 resolves a duplication issue in the French Profit and Loss report by removing a redundant account (6492) from the calculation. The fix ensures accurate financial reporting for French businesses using Odoo Enterprise, aligning with proper accounting practices. This was built upon previous work to avoid duplicate accounts.
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 automatically refreshes the payment screen when the PIS (Payment Initiation System) status changes. Previously, users had to manually refresh the page to see the updated status, which was inconvenient. This change ensures a smoother and more reliable payment process for users.
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
This update corrects a minor error in the automated testing of Odoo's Point of Sale (POS) system. A typo was identified in an assertion within a test case, which prevented the test from running correctly. This fix ensures the accuracy of the testing process and improves the reliability of the POS module.
Original PR description
Correct a typo in `test_01_order_flow` assertions. `pdis_order1` was reassigned multiple times; the second assertion should use `pdis_order2`. Task-6065459
This update prevents subscriptions from being automatically reopened after a manual closure by a salesperson. Previously, approvals or payments could trigger reopening, leading to inconsistencies. This change ensures subscription status remains accurate and reliable, streamlining sales processes.
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 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 corrects an issue where free FSM services with prepaid invoicing were not appearing on invoices. The change adjusts a calculation to ensure these services are correctly reflected when creating invoices, allowing for accurate billing of prepaid FSM tasks. This resolves a previous bug impacting service invoicing.
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 fixes an issue where users were redirected to a standard form view when opening documents linked through a Many2One field. Now, users can directly access the Kanban or List view for documents, allowing them to preview and navigate documents more effectively, especially when dealing with folders.
Original PR description
Problem: When opening a linked `documents.document` record from a Many2One field added via Studio, the user is redirected to the standard form view. This is problematic because the form view does not allow the user to preview the actual document or navigate into it if the record is a folder. Solution: override `get_formview_action` to open the Kanban/List/Activity views. task-6068437 Forward-Port-Of: odoo/enterprise#113149
This update corrects a bug in the Mod 349 report for Spanish tax filings. Previously, transactions under 1 Euro were incorrectly excluded, preventing the report from displaying all relevant journal entries. The fix adjusts the calculation to accurately include these small amounts, ensuring complete and accurate tax reporting.
Original PR description
Steps to reproduce: - Install l10n_es_reports. - Create a company from France. - Create and post a vendor bill for that company with an amount of 0.12 EUR. - Open the Tax Return report and switch to the Mod 349 report for the current year. - Click the 0.12 EUR amount line. Observed: - The journal items view opens with no records. Cause: - `_get_modelo349_audit_aml_domain()` calls `_custom_modelo349_common()`, which filters lines using: `float_compare(result_dict['value'], 0, precision_rounding=2)` - Using `precision_rounding=2` treats values below 1 as equal to 0, so those lines are excluded from the audit domain. Fix: - Replace `precision_rounding` with `precision_digits=2` so values are only treated as zero when they are effectively below 0.01. opw-6134339 Forward-Port-Of: odoo/enterprise#114776
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 report 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