Odoo Changelog — 2026-06-16

Tuesday, June 16, 2026

5 changes · saas-18.3

Bug Fixes(5)

Resolved issues and error corrections

[FIX] l10n_ch_hr_payroll_elm_transmission: prevent accesserror on emp update

PR #120612

Enterprisesaas-18.3l10n_ch_hr_payrollMedium

This update fixes an issue where HR users couldn't update employee information, specifically related to generating payroll slips. The change adds a security layer to ensure HR users can modify employee records without restrictions, improving usability and data accuracy. This resolves a previous error preventing updates.

Original PR description

Issue:
-----------
Updating the employee raises the following error:
```python
You do not have enough rights to access the fields "slip_ids" on Employee (hr.employee). Please contact your system administrator.

Operation: read
User: 2
Fields:
- slip_ids (allowed for groups 'Payroll / Officer: Manage all contracts')
```

Cause:
---------
After this 4416eda, open payslips are recomputed automatically on every employee update:
https://github.com/odoo/enterprise/blob/8f7a43eebdc8f7f46f9d61ab7084e036c20f778e/l10n_ch_hr_payroll_elm_transmission/models/hr_employee.py#L210-L213
`slip_ids` is restricted to payroll users:
https://github.com/odoo/enterprise/blob/8f7a43eebdc8f7f46f9d61ab7084e036c20f778e/hr_payroll/models/hr_employee.py#L14 As a result, when an HR user without payroll rights updates an employee,
accessing slip_ids raises an **AccessError**.

Solution:
-----------
Use sudo() when accessing slip_ids so HR users can update employee records
without issue.

**NOTE:**
The issue has been resolved from version saas~18.4 with the following commits:
279f09a9587674c035c514f966788a4dddfe9794 and 75d66d8

opw-6210358

Forward-Port-Of: odoo/enterprise#120019
Forward-Port-Of: odoo/enterprise#117387

#payroll#employee#swiss

[FIX] pos_hr: display correct employee in tracked order's chatter

PR #265582

Coresaas-18.3pos_hrMedium

This update ensures that the correct employee is displayed in order chatter logs when tracking order edits. Previously, the system incorrectly used the original cashier, regardless of the currently logged-in employee. This fix improves order tracking accuracy and provides a more reliable record of changes made to orders.

Original PR description

**Steps to reproduce:**

- Enable "Track orders edits" in the settings
- Enable "Log in with Employees"
- Go to the Restaurant, log in with employee A
- Go to a table, order 3 Sushis
- Go back to the floor plan and change to employee B
- Go back to the table and change the qty of 3 Sushis to 2 Sushis
- Go to the order in the backend and check the chatter
- It will indicate that employee A did the change, but it was employee B

**Why the fix:**

We always used the cashier set on the order to determine who should be put in the chatter, regardless of who is actually connected at that point.

We now use the session's current employee to write who did the change in the chatter.

We do not change the order's employee, because it will be done once the order has been paid.

In the case where we are not logged in but pos_hr is installed, the employee_id might be the id of a res.user, and
browsing it might return the wrong value. To avoid this, we check if the value exists as a hr.employee before assigning the name.

The way we return the value has been changed because the linter wasn't happy about it.

opw-6213504

[FIX] point_of_sale: multi refund amount

PR #270143

Coresaas-18.3point_of_saleMedium

This update fixes an issue where refund calculations in the Point of Sale (PoS) system were inaccurate when multiple refunds were applied to a partially paid order. Previously, the total and line amounts incorrectly reflected the entire original order total. This change ensures accurate refund processing, preventing financial discrepancies and improving the reliability of PoS transactions.

Original PR description

When refunding an order that has already been partially refunded, the line amount and total amount where incorrect. They would be the total amount of the original order.

Steps to reproduce:
-------------------
* Open PoS and make an order with 3 quantity of a product.
* Close the session
* In the backend, refund 1 quantity of the order and validate the refund
* Refund again the same order with the 2 remaining quantities
> Observation: The total amount and line amount are not correct

opw-6215019

Forward-Port-Of: odoo/odoo#269605
Forward-Port-Of: odoo/odoo#265322

#pos#refund#accounting

[FIX] sale_{stock,mrp}_renting: validate rental transfer for new kit products

PR #120640

Enterprisesaas-18.3sale_mrp_rentingstockMedium

This update resolves an issue where validating rental orders for kit products (specifically when using rented components) would trigger a 'record not found' error. The fix ensures that the system correctly handles the explosion of bills when a rental order involves a kit, preventing this validation error and ensuring proper rental tracking.

Original PR description

### Steps to reproduce:

- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.

### Cause of the issue:

Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65

opw-6191841

Forward-Port-Of: odoo/enterprise#120051

[FIX] l10n_fr_pdp: retrieves the peppol eas and endpoint from commer…

PR #270186

Coresaas-18.3l10n_fr_pdpMedium

This update corrects a problem where invoice processing for French PEPPOL (electronic invoicing) was failing. The issue stemmed from incorrectly retrieving PEPPOL identifier information from sub-contacts instead of the main company. This change ensures invoices using French PEPPOL identifiers are processed correctly.

Original PR description

…cial partner

**STEP TO REPRODUCE**
1. Install l10n_fr_pdp.
2. On the demo FR company contact, create a new contact of type invoice address.
3. Create an invoice with this new contact, and try send the invoice.
4. The pdp invoice constraints checking for pdp identifiers fails.

**CAUSE**
We use the partner to retrieve the peppol_eas and peppol_endpoint field values, but for subcontact, those field are empty. We should use the commercial_partner_id which correspond to the company we try to invoice instead.

opw-6235830

Forward-Port-Of: odoo/odoo#270014

#PEPPOL#FR#Invoice#Compliance

Steps to reproduce: -------------------------- 1. Install l10n_ch_hr_payroll_elm_transmission. 2. Switch to a Swiss company. 3. Create an employee and create a user with HR rights but without Payroll rights. 4. Log in with this new user. 5. Update any value on the employee form (e.g., marital status or add a tag). Issue: ----------- Updating the employee raises the following error: ```python You do not have enough rights to access the fields "slip_ids" on Employee (hr.employee). Please contact your system administrator. Operation: read User: 2 Fields: - slip_ids (allowed for groups 'Payroll / Officer: Manage all contracts') ``` Cause: --------- After this 4416eda, open payslips are recomputed automatically on every employee update: https://github.com/odoo/enterprise/blob/8f7a43eebdc8f7f46f9d61ab7084e036c20f778e/l10n_ch_hr_payroll_elm_transmission/models/hr_employee.py#L210-L213 `slip_ids` is restricted to payroll users: https://github.com/odoo/enterprise/blob/8f7a43eebdc8f7f46f9d61ab7084e036c20f778e/hr_payroll/models/hr_employee.py#L14 As a result, when an HR user without payroll rights updates an employee, accessing slip_ids raises an **AccessError**. Solution: ----------- Use sudo() when accessing slip_ids so HR users can update employee records without issue. **NOTE:** The issue has been resolved from version saas~18.4 with the following commits: 279f09a9587674c035c514f966788a4dddfe9794 and 75d66d8 opw-6210358 Forward-Port-Of: odoo/enterprise#120019 Forward-Port-Of: odoo/enterprise#117387

**Steps to reproduce:** - Enable "Track orders edits" in the settings - Enable "Log in with Employees" - Go to the Restaurant, log in with employee A - Go to a table, order 3 Sushis - Go back to the floor plan and change to employee B - Go back to the table and change the qty of 3 Sushis to 2 Sushis - Go to the order in the backend and check the chatter - It will indicate that employee A did the change, but it was employee B **Why the fix:** We always used the cashier set on the order to determine who should be put in the chatter, regardless of who is actually connected at that point. We now use the session's current employee to write who did the change in the chatter. We do not change the order's employee, because it will be done once the order has been paid. In the case where we are not logged in but pos_hr is installed, the employee_id might be the id of a res.user, and browsing it might return the wrong value. To avoid this, we check if the value exists as a hr.employee before assigning the name. The way we return the value has been changed because the linter wasn't happy about it. opw-6213504

When refunding an order that has already been partially refunded, the line amount and total amount where incorrect. They would be the total amount of the original order. Steps to reproduce: ------------------- * Open PoS and make an order with 3 quantity of a product. * Close the session * In the backend, refund 1 quantity of the order and validate the refund * Refund again the same order with the 2 remaining quantities > Observation: The total amount and line amount are not correct opw-6215019 Forward-Port-Of: odoo/odoo#269605 Forward-Port-Of: odoo/odoo#265322

### Steps to reproduce: - Enable rental transfer - Create a rentable product R - Create and confirm a rental order for 1 unit of R - Create a kit bom for R: 1 x COMP - Validate the delivery of your unit of R #### > Missing Error: Record does not exist or has been deleted. ### Cause of the issue: Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65 opw-6191841 Forward-Port-Of: odoo/enterprise#120051

…cial partner **STEP TO REPRODUCE** 1. Install l10n_fr_pdp. 2. On the demo FR company contact, create a new contact of type invoice address. 3. Create an invoice with this new contact, and try send the invoice. 4. The pdp invoice constraints checking for pdp identifiers fails. **CAUSE** We use the partner to retrieve the peppol_eas and peppol_endpoint field values, but for subcontact, those field are empty. We should use the commercial_partner_id which correspond to the company we try to invoice instead. opw-6235830 Forward-Port-Of: odoo/odoo#270014