Thursday, August 13, 2026
8 changes · saas-19.4
Resolved issues and error corrections
This fix prevents small rounding differences from creating unbalanced journal entries when account transfer rules send less than 100% to a destination. Businesses using automated transfers can now rely on the generated accounting entries to balance correctly, avoiding one-cent posting errors.
Original PR description
Before this commit, _get_transfer_move_lines_values computed the amount for the last destination line from the global transferred balance, instead of reusing the amount already removed from the source accounts. The two values are rounded independently and can differ by a cent whenever the removed amount comes from more than one rounded source, producing an unbalanced journal entry. Removing that condition the last destination line always absorbs the remainder fixes it. Steps to reproduce: 1. Transfer model with 2 source accounts and 1 destination line at 15%. 2. Post moves for the period: account A balance 395.88, account B balance 252.16 (total 648.04). 3. Run `action_perform_auto_transfer()`. Before: source lines -59.38 (395.88 * 15%) and -37.82 (252.16 * 15%), destination line +97.21 (648.04*15% rounded) -> entry off by 0.01. After: destination line takes the exact remainder, 97.20 -> balanced. OPW-6443928 Forward-Port-Of: odoo/enterprise#126877
The payroll validation button now correctly opens any needed follow-up prompt, such as a wizard to complete missing employee information. This prevents users from clicking Validate and seeing no response when additional data is required.
Original PR description
action_validate() called action_payslip_done() without returning its result. When action_payslip_done() returns a client action (e.g. a wizard to fix missing employee data instead of raising), that action was lost and the Validate button appeared to do nothing, with no error or warning shown. task-6373549
Customers can now use Order Again for rental products even when their cart already has a rental period. The cart reuses the existing rental dates, preventing a false conflict that previously stopped the item from being added.
Original PR description
Steps to reproduce: --- - Install the `website_sale_renting` module. - Create a rental product, place an order for it with customer as `Administrator`, and confirm the order. - Open the order preview…
Steps to reproduce: --- - Install the `website_sale_renting` module. - Create a rental product, place an order for it with customer as `Administrator`, and confirm the order. - Open the order preview and click `Order Again`. - In the cart, modify the rental period. - Go to My Account > Your Orders, open the sales order, and click `Order Again` again. Issue: --- - Clicking Order Again a second time does nothing and - The following error is logged in the terminal: `You cannot mix different rental periods in the same order.` Root cause: --- - When the user clicks `Order Again`, the `/my/orders/reorder` route calls `add_to_cart`[1], which in turn invokes `_cart_add`[2]. If no rental dates are provided, `_cart_add` computes default rental dates based on the product's rental periodicity [3]. - However, when the current cart already has a rental period set, these computed dates differ from the cart's existing rental period. As a result, the rental consistency check detects the mismatch and prevents the product from being added to the cart. Solution: --- - When the current sale order already has a rental period set, reuse those dates instead of computing default ones. This ensures the product is added using the existing cart rental period and avoids the false conflict. [1]: https://github.com/odoo/odoo/blob/bb9fcbb062887ab6b1c4c17870201d789afa9dbc/addons/website_sale/controllers/reorder.py#L63-L76 [2]: https://github.com/odoo/odoo/blob/bb9fcbb062887ab6b1c4c17870201d789afa9dbc/addons/website_sale/controllers/cart.py#L134-L141 [3]: https://github.com/odoo/enterprise/blob/a39da12a4a85d749235d59a05ebd67b91f9867b0/website_sale_renting/models/sale_order.py#L60-L64 opw-6357001 ---
VoIP contact searches now recognize phone numbers even when the user's input includes an automatic country code and the saved contact number is stored differently. This makes keypad suggestions and contact tab searches more reliable, while showing a readable formatted phone number to users.
Original PR description
Before this fix, the keypad's callee suggestions only matched the search term against the raw `phone` field of contacts. When the user input was automatically prefixed with a country code (e.g. +86), the match could fail if the stored phone number lacked the international prefix. Now `phone_sanitized` is also sent to the frontend via the Store, and the callee suggestion matching falls back to the E164 sanitized number when the raw phone field does not match. Task-6290760 compr https://github.com/odoo/odoo/pull/278018 Forward-Port-Of: odoo/enterprise#127466 Forward-Port-Of: odoo/enterprise#124797
Australian payroll now correctly includes each employee's unused leave when payslips are processed together. This prevents leave payouts or balances from being skipped in multi-employee payroll runs.
Original PR description
`_l10n_au_get_unused_leave_by_type` compared leave allocations to `self.employee_id` while looping payslips. On a multi-recordset that is the whole employee set, so the match never holds and unused leave is skipped. Use `payslip.employee_id` so each payslip keeps its own allocations. task-6458480 Forward-Port-Of: odoo/enterprise#127330
Accounting users can now export Spanish VAT record books that include Point of Sale data without needing separate POS access. This prevents access errors during tax reporting while still using POS information only internally to build the report.
Original PR description
Steps to reproduce:
- With an ES Company
- Open a POS session, add product with tax and pay
- As a user with only accounting access
- Go to Accouting > Reporting > Tax report
- Select Generic Tax report
- Print "VAT record Books"
Issue:
An AccessError will raise
```
Access Error
You are not allowed to access 'Point of Sale Session' (pos.session) records.
This operation is allowed for the following groups:
- Point of Sale/User
Contact your administrator to request access if necessary.
```
Analysis:
Vat Record Books handler for POS needs to read pos.session and pos.order records. Currently, the action is performed with the rights of the user running the report, so accounting-only user face an error.
As POS records are only read internally to build the report, we add sudo call to get the data.
opw-5862529
Forward-Port-Of: odoo/enterprise#126590
Forward-Port-Of: odoo/enterprise#125980Belgian payroll now calculates fictitious remuneration for departure holiday attestations and December double holiday regularization using the salary that applied during each absence period. This prevents employees with mid-year salary changes from having those absences valued at the wrong wage, improving payroll accuracy.
Original PR description
### Problem - The fictitious remuneration used for departure holiday attest and December double holiday regularization was computed using the salary applicable at the end of the previous year for all…
### Problem - The fictitious remuneration used for departure holiday attest and December double holiday regularization was computed using the salary applicable at the end of the previous year for all assimilated absence periods. **For an employee with:** - 20 days of assimilated absence in February with a salary of 2,000. - A salary increase to 3,000 in June. - Another 20 days of assimilated absence in November. ``` The previous computation was: (40 × 3,000) × (3 / 13 / 5) ``` - where all assimilated absence days were valued using the wage applicable on the last day of the previous year. - Instead, the remuneration should be computed using the wage applicable ``` during each assimilated absence period: ((20 × 2,000) + (20 × 3,000)) × (3 / 13 / 5) ``` - Compute the fictitious remuneration using the contract wage applicable to each payslip period so that each assimilated absence is valued with the correct monthly salary before applying the holiday formula. task-5932817
Belgian payroll now reports the correct mobility budget balance when it is paid after an employee's contract no longer includes a mobility budget. This prevents the DMFA declaration from showing zero and helps ensure accurate social security reporting.
Original PR description
When the mobility budget balance is paid on a contract that no longer carries a mobility budget, fall back to the previous quarter's contract to declare the correct amount instead of 0. Task-6384786 Forward-Port-Of: odoo/enterprise#127318