Friday, May 29, 2026
7 changes · saas-18.4
Enhancements to existing features
Analytic reporting can now group entries by product category, making it easier to understand where costs or revenues are coming from. This gives finance and operations teams a clearer way to compare performance across product groups without extra manual filtering.
Original PR description
Add the related (non-stored) 'product_category' field on the account.analytic.line model to make it available in the Analytic Reporting "Group By" task-6219418 Forward-Port-Of: odoo/odoo#266378
Resolved issues and error corrections
Philippine withholding taxes are now excluded from periodic VAT closing entries. This prevents withholding tax amounts from being counted in VAT closing calculations, helping businesses keep tax reports and accounting entries accurate.
Original PR description
Set `use_in_tax_closing` to False on withholding tax (WHT) repartition lines, as they should not contribute to the periodic VAT closing entry. task-6146238 Forward-Port-Of: odoo/odoo#266705 Forward-Port-Of: odoo/odoo#266623
Removing a background image from a website section now also removes any color or gradient filter that was applied to it. This prevents leftover visual effects from staying on the page after the image is deleted, keeping page editing results predictable.
Original PR description
Steps to reproduce: - Edit a website page. - Select a section with a background image. - Set a gradient color filter on the background image. - Remove the background image. => The gradient color filter stays in the section DOM. After this commit, `removeBackgroundImage` directly removes the related `.o_we_bg_filter`.
Polish FA(3) e-invoices now include the delivery date when it differs from the invoice issue date, as required by the regulation. This prevents the delivery date from being incorrectly omitted when the accounting date matches the delivery date.
Original PR description
**Steps to reproduce** 1. Create a customer invoice with Invoice Date `2025-05-27` and accounting Date `2026-05-04`. 2. On the *Other Info* tab, set the Delivery Date to `2026-05-04` and post the…
**Steps to reproduce** 1. Create a customer invoice with Invoice Date `2025-05-27` and accounting Date `2026-05-04`. 2. On the *Other Info* tab, set the Delivery Date to `2026-05-04` and post the invoice. 3. Generate the FA(3) XML. **Issue** `P_6` is omitted from the payload even though the delivery date differs from the invoice issue date. The FA(3) information sheet (Warsaw, September 2025, binding from 1 February 2026) defines `P_6` as *"the date of delivery [...] if such date is specified and differs from the date of issue of the invoice"*, where the date of issue is `P_1` (Art. 106e sec. 1 item 1 of the VAT Act). In Odoo `P_1` maps to `invoice_date`, but the template at https://github.com/odoo/odoo/blob/4890b8021af2a5c025944220043d295bb7bbbb9b/addons/l10n_pl_edi/data/fa3_template.xml#L132 compares `delivery_date` against `invoice.date`, the accounting/entry date. When the invoice is posted on the delivery day the accounting date equals the delivery date, the guard evaluates to false, and `P_6` is wrongly dropped. Comparing against `invoice.invoice_date` aligns the guard with `P_1` as the spec requires. Ticket [link](https://www.odoo.com/odoo/project.task/6211119) opw-6211119 Forward-Port-Of: odoo/odoo#266667
This change restores the previous behavior that keeps empty add-on path entries instead of silently removing them. It ensures users and support teams still receive the intended warning, helping identify configuration issues without changing business workflows.
Original PR description
This reverts commit e1c71a90b3e7163733cba3da401eaf473f190fef. The warning is fine. https://github.com/odoo/odoo/pull/259007#issuecomment-4299650605 > il fallait justement stop le forward-port en 18.2, on veut le warning, mais on n'avait pas la possibilité d'en avoir un avant 18.1 Forward-Port-Of: odoo/odoo#262841
This update fixes an issue where commission plans were incorrectly listed in the 'Other Plans' section for salespeople, even when their assignment periods didn't overlap. The system now accurately checks if salesperson assignment dates intersect with plan effective dates, ensuring only relevant plans are displayed. This improves the accuracy of sales reporting and commission calculations.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a commission plan A with effective period 2025–2026 2. Assign salesperson to plan A from 01/01/2025 to 31/12/2025 3. Create another commission plan B with effective period 2026 4. Assign the same salesperson to plan B from 01/01/2026 to 31/12/2026 5. Open plan B and check the 'Other Plans' section in the salespeople tab Issue: Plans are shown in 'Other Plans' even when salesperson assignment periods do not overlap. System incorrectly relies on plan effective dates instead of salesperson-specific assignment dates Fix: A plan is now considered overlapping only if the salesperson assignment periods intersect. Non-overlapping plans are properly excluded from 'Other Plans'. Taskid-6055253 Forward-Port-Of: odoo/enterprise#118559 Forward-Port-Of: odoo/enterprise#112694
This update fixes a technical issue that caused a traceback when attempting to mark workorders as done in certain scenarios, specifically when no workorders were open. The fix ensures the system handles empty recordsets gracefully, preventing errors and maintaining stability.
Original PR description
When calling on a empty recordset action_mark_as_done, it creates a traceback. **Observation** When calling action_mark_as_done, the method first loops over each workorder to perform various safety…
When calling on a empty recordset action_mark_as_done, it creates a traceback. **Observation** When calling action_mark_as_done, the method first loops over each workorder to perform various safety checks, and then calls button_finish to close all workorders: https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L881-L888 Inside button_finish, it retrieves all open workorders and marks them as done: - Retrieve open workorders: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L659 - mark them as done: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L675-L678 Returning to action_mark_as_done, it attempts to set the state to 'done' on the last workorder outside of the loop, referencing the loop variable: https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L894 -> If self is empty, the loop never executes. This leaves the loop variable empty, which ultimately triggers a traceback. opw-6239910 Forward-Port-Of: odoo/enterprise#118403