Tuesday, June 2, 2026
6 changes · saas-18.4
Resolved issues and error corrections
This update resolves an issue where product variant prices weren't automatically updating when the cost price changed. Previously, users had to manually switch price lists to trigger the update. The fix adds a direct update mechanism to ensure on-sale prices accurately reflect cost changes, improving pricing accuracy and reducing manual intervention.
Original PR description
When we create a product variant and have a pricelist which is based on the cost price, and change the cost price, the on_sale_price doesn't update. You have the change the price list to other and back to the one you want for it to trigger change because the _onchange_compute_pricing only gets triggered if there's change on pricelist (pricer_sale_pricelist_id), and sales price (lst_price). Steps to Reproduce: 1.Create a pricelist and add a line with "formula" price type, and based on "cost", 2.Create a product variant, and add the pricelist just created. 3.Change the "Cost". The "On Sale Price" doesn't update. 4.You have to change the price list to some other and back to the one you want for the "On Sale Price" to update. To fix the issue, we add the field Cost (standard_price) on api.onchange, so when we change the cost it'll update the "On Sale Price" right away. opw-5947995 Forward-Port-Of: odoo/enterprise#111892
This update addresses a requirement from the Peruvian tax authority (SUNAT) regarding delivery guides. Customers using the l10n_pe_edi_stock module now need to include a 'carrier handover date' field in their delivery guides to avoid errors. The update automatically handles this by reusing existing data, and provides a helpful message to users on older versions to update their module.
Original PR description
SUNAT R. S. N° 000108-2026/SUNAT and the GRE validation rules published on 2026-06-01 add field 34 "Fecha de entrega de bienes al transportista" (cac:LoadingTransportEvent/cbc:OccurrenceDate). It is required, and rejected with error 3617 when absent, only when the transport modality is '01' (public transport). Enforcement started 2026-06-01, so affected customers can no longer submit their delivery guides.
In our implementation the departure start date is equivalent to this date, so we reuse it instead of adding a new field. The node is gated to public transport to match the validation rule and avoid emitting it on private transport ('02') guides.
Because the new node only ships with this module version, customers on an older version keep hitting error 3617 from SUNAT. Detect that code in the SUNAT response and store an actionable message asking the user to update the module, instead of surfacing the raw rejection.
task-6266662
Forward-Port-Of: odoo/enterprise#119038This update resolves a crash in the General Ledger report when using prefix groups. The fix addresses an issue caused by incorrect domain generation, ensuring lines can be properly expanded. This improves report functionality for users utilizing prefix group filtering.
Original PR description
If expanding a line in the General Ledger report using a prefix group (defined on `prefix_groups_threshold`) users experience a crash due to a bad domain. This bad domain is caused by a custom…
If expanding a line in the General Ledger report using a prefix group (defined on `prefix_groups_threshold`) users experience a crash due to a bad domain. This bad domain is caused by a custom groupby key that is not a real field name, which causes the invalid domain name to be generated here https://github.com/odoo/enterprise/blob/e9a920d62a5894d8198fdbf2e35032de555d0bd7/account_reports/models/account_report.py#L5895-L5898 The solution adds mapping of the groupby names to the actual field names and adjusts `_report_expand_unfoldable_line_groupby_prefix_group()` to read the custom groupby keys from this mapping, thus creating valid domains. This also changes the `forced_domain` to use `display_name` instead of `name` , allowing the lines to expand properly. https://github.com/odoo/enterprise/blob/da6ab7eedfa1b326cc6e01876dfff30e50a1c578/account_reports/models/account_report.py#L5896 Reproduction steps: Runbot 18.4 Debug/Developer mode Accounting -> General Ledger Report Gear icon in top bar Options -> Lower the prefix_groups_threshold to 1 Go back to the general ledger, try expanding some lines and see crash **Only affects 18.4** opw-6231127
A technical issue preventing users from accessing billing targets in the Timesheets module has been fixed. This change ensures the billing process functions correctly for employees, particularly when 'Billing Rate Indicators' are enabled and specific user access settings are in place. The fix involved adding a necessary field to resolve a dependency conflict.
Original PR description
… of employees Prerequisites to reproduce: - Enable `Billing Rate Indicators` in timesheets. - Change timesheet access of user to `User: all timesheets` - Remove Employee access Steps to Reproduce: - In Timesheets app, from configuration go to `Billing Time Targets` - Click on view button on any row Issue: - A traceback breaking the flow. Reason: - We use `hr_presence_status` widget which requires `work_location_type` field, change made from https://github.com/odoo/odoo/commit/0496ed10636c7b2dfde7038a43494d4edbd9f95b. - Thus unavailability of field causing the traceback. Fix: - Add a related field for work_location_type from which we get the value.
This update corrects a bug where paying with the 'customer account' payment method on a zero-priced order resulted in an incorrect 'change' calculation. The fix hides the 'pay_later' payment option in this scenario, aligning with business process requirements and preventing incorrect accounting.
Original PR description
Step to reproduce: - install "pos_settle_due" - create a pos order, set order price = 0, select a customer - go to payment page, select "customer account" as payment method - here you can set any…
Step to reproduce: - install "pos_settle_due" - create a pos order, set order price = 0, select a customer - go to payment page, select "customer account" as payment method - here you can set any amount to pay, ex 100$ - fulfill the order. Observation: - the order amount is 0, if we pay 100$ using customer account, it is considered as change (which means we returned it to customer) - As per PO, this flow doesn't make sense Issue: - customer has 100$ due for this order, but he won't be able to settle this as fetch order to settle with amount != 0, after commit [1] - [1] https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f https://github.com/odoo/enterprise/blob/951e5f42884c898bc14d9c32ae6a8f08c31ff06d/pos_settle_due/static/src/app/screens/partner_list/partner_line/partner_line.js#L35 Fix: - we hide payment method of type "pay_later" in case of 0 price order opw-6123699 Forward-Port-Of: odoo/enterprise#118093 Forward-Port-Of: odoo/enterprise#116556
A test was failing in our Point of Sale (POS) tax feature due to a limitation in how the system loads partner data. This update corrects the test to ensure proper functionality when searching for partners, particularly in the US, and prevents disruptions to the POS experience. This resolves a previous issue impacting the AvaTax integration.
Original PR description
**Issue:** "test_pos_fiscal_position_without_pos_avatax" test is failing with demo data because a US partner is created and searched for in the tour, but only the first 100 partners (alphabetically ordered) are loaded in the POS. Therefore, he's not found. runbot-938983 Backport of https://github.com/odoo/enterprise/commit/968799612ff3a9cbba0ffbf4e644d6699abcfa81 Forward-Port-Of: odoo/enterprise#119069