Wednesday, May 13, 2026
5 changes · 17.0
Resolved issues and error corrections
This update resolves an issue where marking a payslip batch as paid would fail if multiple salary lines or input lines used the same code (like 'OTHERFEES'). The fix allows for successful batch payment even with multiple line items sharing the same code, ensuring accurate payroll processing for Swiss employees.
Original PR description
Current behavior: When marking a payslip batch as paid, a ValueError "Expected singleton" is raised if a salary attachment and a manually added input line use the same code (e.g., OTHERFEES).…
Current behavior: When marking a payslip batch as paid, a ValueError "Expected singleton" is raised if a salary attachment and a manually added input line use the same code (e.g., OTHERFEES). Expected behavior: Batch should be marked as paid successfully even when multiple salary lines and multiple input lines share the same code. Required Modules - l10n_ch_hr_payroll_elm - l10n_ch (Switzerland - Accounting) - l10n_ch_hr_payroll (Switzerland - Payroll) - l10n_ch_hr_payroll_account (Switzerland - Payroll with Accounting) - l10n_ch_hr_payroll_elm (Switzerland - Payroll ELM Standard) - l10n_ch_reports (Switzerland - Accounting Reports) Steps to reproduce: 1. Activate the Payroll app 2. Install the required Swiss payroll modules listed above 3. Go to Payroll > Configuration > Salary Rules and create a new rule: Name: Other Fees Code: OTHERFEES Category: Allowance Salary Structure: Switzerland: Regular Pay Active: Yes Appears on Payslip: Yes Condition Based on: Python Expression Python Condition: result = 'OTHERFEES' in inputs Amount Type: Python Code Python Code: result = inputs['OTHERFEES'].amount and result_name = inputs['OTHERFEES'].name 4. Go to Payroll > Configuration > Salary Attachment Types and create a new type: Name: Other Fees Code: OTHERFEES Country: Switzerland 5. Go to Payroll > Contracts > Salary Attachments and create an attachment: Employee: (select an employee) Type: Other Fees (the one you just created) Description: e.g., "Parking" Monthly Amount: e.g., $70.00 Start Date / End Date: set dates that cover your payslip period State: Running 6. Go to Payroll > Payslips > All Payslips and create a new payslip: Select the employee from step 5 Set the period to match your salary attachment dates Add the payslip to a batch Save and verify the salary attachment appears automatically in "Other Inputs" 7. In the "Other Inputs" section, add a second line: Click "Add a line" Create a new Other Input Type with code OTHERFEES (e.g., "Other Fees - Just Created") Set a description (e.g., "Dining") and amount (e.g., -99) You should now have TWO input lines both using code OTHERFEES 8. Click "Compute Sheet" and verify you see TWO salary lines with code OTHERFEES in the Salary Computation tab Click "Create Draft Entry" Go to Payroll > Payslips > Batches, find your batch, and click "Mark as Paid" Expected ResultBatch is marked as paid successfully.Actual ResultValueError: Expected singleton: hr.payslip.line(??, ??) Cause of the issue: In _record_attachment_payment() (line 149), the code filters salary lines by code and expects a single record. When multiple lines share the same code, slip_lines contains multiple records, causing the singleton error on slip_lines.total access. Fix: Handle multiple salary lines with the same code by summing their totals/quantities instead of expecting a singleton. opw-5473648
This update fixes an issue where the Danish EC Sales List CSV export incorrectly used 'LIST' instead of the required 'LISTE' format. This change ensures compliance with Danish tax regulations and prevents file rejection by the tax authorities. The fix was previously implemented in version 19.0.
Original PR description
### Issue: When exporting the Danish EC Sales List to CSV, the column name is `LIST` instead of `LISTE` According to the official documentation: https://info.skat.dk/data.aspx?oid=392&chk=217608 The correct value is `LISTE`, with a fixed length of 5 characters This cause rejection of the file This was already fixed in 19.0 when the two modules were merged: https://www.odoo.com/odoo/unassigned-tasks/4826286 ### Cause: The value `LIST` is hardcoded in the export https://github.com/odoo/enterprise/blob/b9e4fc1ba08db22dafd10f62a7d9159f963dc949/l10n_dk_reports/models/account_sales_report.py#L104-L107 ### Steps to reproduce: - Install `l10n_dk_reports` - Switch to DK Company - Go to EC Sales List - Download the CSV in the dropdown menu The column name should be LISTE opw-6127427
This update corrects an issue in the General Ledger report where it was incorrectly ordering accounts based on the sales order's company instead of the account's company. The fix ensures the report displays GL entries in the correct order according to the account's financial information, improving report accuracy and reliability.
Original PR description
https://github.com/odoo-dev/enterprise/commit/8dfe4c06106029f3f8039afc863bcacf7057106f had to add insert the order of the account lines in `get_query_amls`, to make it work with the streaming. But there's a mistake, it should order in respect of the company of the account instead of the one of the aml. https://github.com/odoo-dev/enterprise/commit/8a636d709c10921724c974d180751f8645ef7cba aimed to fix this issue, but gives a different ordering depending if we come from the csv export or not, but it should not be the case. opw-5999185
This update corrects a potential issue where archived delivery carrier records were being unintentionally passed through the system's context. This prevented users from selecting the correct active carriers when creating deliveries. The fix ensures that only currently active carriers are used, improving delivery accuracy and functionality.
Original PR description
Issue: property_delivery_carrier_id on res.partner can hold an archived delivery.carrier record. Meaning that we pass an archived record to the context and that we can select the archievd delivery.carrier in the choose.delivery.carrier wizard. Solution: Only pass active records through the context. opw-6125792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a typographical error in the CSV file defining account groups used in Odoo's Mexican localization (l10n_mx). The fix ensures accurate reporting and compliance with Mexican tax regulations, as outlined by the latest SAT guidelines. This ensures data integrity for Mexican businesses using Odoo.
Original PR description
Source: https://www.sat.gob.mx/minisitio/NormatividadRMFyRGCE/documentos2026/rgce/anexos/Anexo24delasRGCEpara2026.pdf opw-6174385