Odoo Changelog — 2026-06-15

Monday, June 15, 2026

4 changes · saas-18.2

Bug Fixes(4)

Resolved issues and error corrections

[FIX] l10n_de_reports: Handle currency on Datev properly

PR #120469

Enterprisesaas-18.2l10n_de_reportsMEDIUM

This update fixes an issue where the Datev export incorrectly displayed currency amounts due to a mismatch between the invoice currency and the company currency. The change ensures that currency calculations in the Datev export align with the invoice's currency, improving the accuracy of financial reporting for German customers.

Original PR description

There is an issue in the Datev export functionality. In the current functionality, the code calculates a delta between the taxes in the `tax_totals` and the ones on the journal items. Issue is, the tax amounts from tax_totals were always in company currency, while the entry itself can use a foreign one. This replaces the use of company currency with the use of the invoice's currency and appropriately adjusts the test featuring foreign currency.

Steps:
Create a foreign currency.
Create an invoice with a taxed product using the currency.
Export the ledger to Datev.
Inspect the resulting csv.
Note that neither the final listed price, nor the rate listed for the currency align with the ones in the db.

opw-6275889

Forward-Port-Of: odoo/enterprise#120293

#reporting#currency#Datev#Germany

[FIX] l10n_in_hr_payroll: fix demo leave allocations during upgrade

PR #120494

Enterprisesaas-18.2l10n_in_hr_payrollMEDIUM

This update resolves an issue where demo leave allocations weren't correctly processed during an upgrade from Odoo 17 to 18. The fix ensures that leave allocations are properly validated and approved, regardless of whether the database was initially set up or upgraded, preventing data inconsistencies.

Original PR description

Steps:
- Install an Odoo 17.0 database with the Indian Payroll module and demo data.
- Upgrade the database to 18.0.

Issue:
- The Indian payroll demo data creates leave allocations and approves them through an XML function call.
- During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'.
- However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function:
- This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'.
- When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition.
- As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading.

Fix:
- Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'.
- As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios.

runbot error-https://runbot.odoo.com/odoo/error/230430 

task-6268381

Forward-Port-Of: odoo/enterprise#119217

#payroll#upgrade#demo data

[FIX] l10n_ch_hr_payroll: prevent payslip refund

PR #118794

Enterprisesaas-18.2l10n_ch_hr_payroll

This update corrects a potential issue in the Swiss payroll module where users could incorrectly request refunds on payslips. Swiss payroll regulations limit payments to one per month, so the system now directs users to cancel and re-create the payslip for any necessary adjustments. This ensures compliance with Swiss tax laws.

Original PR description

Prevent refunds for CH payslips since only one payslip per month is allowed for Swiss payroll. Users should cancel the payslip and create a new one to apply corrections.

task-5951981

Forward-Port-Of: odoo/enterprise#107943

#payroll#Switzerland#tax

[FIX] l10n_ch_hr_payroll_elm_transmission: prevent accesserror on emp update

PR #120019

Enterprisesaas-18.2hr_payrollMEDIUM

This update fixes an issue where HR users couldn't update employee information, specifically related to generating payroll slips. The change allows HR users to modify employee records without errors, ensuring seamless data management. This resolves a restriction on accessing sensitive payroll data.

Original PR description

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#117387

#payroll#employee#hr

There is an issue in the Datev export functionality. In the current functionality, the code calculates a delta between the taxes in the `tax_totals` and the ones on the journal items. Issue is, the tax amounts from tax_totals were always in company currency, while the entry itself can use a foreign one. This replaces the use of company currency with the use of the invoice's currency and appropriately adjusts the test featuring foreign currency. Steps: Create a foreign currency. Create an invoice with a taxed product using the currency. Export the ledger to Datev. Inspect the resulting csv. Note that neither the final listed price, nor the rate listed for the currency align with the ones in the db. opw-6275889 Forward-Port-Of: odoo/enterprise#120293

Steps: - Install an Odoo 17.0 database with the Indian Payroll module and demo data. - Upgrade the database to 18.0. Issue: - The Indian payroll demo data creates leave allocations and approves them through an XML function call. - During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'. - However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function: - This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'. - When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition. - As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading. Fix: - Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'. - As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios. runbot error-https://runbot.odoo.com/odoo/error/230430 task-6268381 Forward-Port-Of: odoo/enterprise#119217

Prevent refunds for CH payslips since only one payslip per month is allowed for Swiss payroll. Users should cancel the payslip and create a new one to apply corrections. task-5951981 Forward-Port-Of: odoo/enterprise#107943

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#117387