Tuesday, June 3, 2025
15 changes · 17.0
Resolved issues and error corrections
This fixes incorrect tax exemption reason codes when exporting electronic invoice XML. The change helps ensure invoices use the official PEPPOL code format, reducing validation errors and compliance issues.
Original PR description
Some of the reasons were added with a wrong code. https://github.com/odoo/odoo/blob/fba7abd168b99157ee9abd1c084720a90196de39/addons/account_edi_ubl_cii_tax_extension/models/account_tax.py#L76-L85 Example: VATEX_EU_AE should have been VATEX-EU-AE... This fix adds a mapping to correct the codes when exporting XML, since we cannot update the keys of the selection field directly in stable versions. Source: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-22/ task-4817958 (part of)
The Peppol setup error now gives a clearer explanation when a Peppol address is already registered. This avoids confusing users with migration key references that often do not apply, helping them understand they may need to unregister from the existing provider first.
Original PR description
Context: Migration keys in the context of Peppol are keys that are used to transfer a Peppol participant from one SMP (a service provider by simplification, like Odoo) to another. Problem: The error fixed in this commit is raised when we detect the Peppol Identification/Peppol Address is already on the Peppol Network. It mentions the migration key while it can also be raised when the identification is already used on our own SMP, which makes the migration mention irrelevant and confusing. Moreover, migration keys are actually handled by very few provider. Generally, the way to go is to unregister from the SMP you want to leave, to be able to register on a new one. task-no
This fixes how Time Off leave types determine valid allocations, so eligible allocations are no longer limited only to accrual-based ones. Businesses should see more accurate leave type availability for employees using different allocation methods.
Original PR description
This commit fixes an issue in the `_compute_valid` method of the `hr.leave.type` model. The `('allocation_type', '=', 'accrual')` was removed from the domain, as it limited the valid allocations to type `accrual` only, which is not the intended behavior
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixed the project profitability report so users can click the Cost of Goods Sold item and view the related invoice line details. This helps teams investigate project costs directly from the dashboard instead of reaching a dead end.
Original PR description
**Current behavior:** COGS dashboard items in a project's profitability report do not open any details when clicked on. **Expected behavior:** This should open a detailed view for an invoice linked…
**Current behavior:** COGS dashboard items in a project's profitability report do not open any details when clicked on. **Expected behavior:** This should open a detailed view for an invoice linked via the analytic account on the project. **Steps to reproduce:** 1. Create a service product that generates a project on sale, on the project template set a specific analytic account 2. Create another product with real time valuation and assign the COGS account on the product category's expense account 3. Sell some of the service product and the auto val product in the same order, deliver it -> generate invoice & post it 4. In the project's settings, open the profitability report and click on the `Cost of Goods Sold` dashboard item **Cause of the issue:** There is no action set up to return for this section, as it was just added in: 0fbc592 **Fix:** Add an action to return the account move line records with COGS display type for the invoice record in question (in the request's `res_id`). opw-4813885
Fixed an issue where opening the Data option in debug mode on an Appraisals employee record could trigger an error. This makes the debug data view behave reliably and prevents interruptions for users or support staff investigating appraisal records.
Original PR description
**Steps to reproduce**:
1. Install Appraisals
2. Appraisals > Open any Employee card
3. Turn on the debug mode
4. Click on Debug Icon
5. Click Data
**Issue**:
- A Traceback error occurs when trying to read the record.
- The fields parameter is None in some cases (viewing Raw Record data in Debug mode) in read function, leading to an
attempt to convert it to an empty dictionary, which is not iterable.
**Cause**:
- The read() function was called with fields is None in debug mode and it was incorrectly converting None to {}, causing a
TypeError when performing set operations.
**Solution**:
- Instead of setting None to {}, it should be converted to an empty set to avoid type mismatch.
opw-4788901Corrected a typo and refreshed missing translation text in the Swiss payroll ELM transmission module. This improves clarity for users working with payroll-related options and helps ensure labels are displayed correctly in different languages.
The helpdesk ticket list now totals time spent without adding small rounding errors. This prevents selected tickets with short timesheet entries from showing inflated totals, improving accuracy for support reporting and billing checks.
Original PR description
to reproduce: ============= - enable timesheet for a helpdesk team - create 5 tickets with 10 minutes each - on list view of tickets, select these tickets -> total spent time is 51 minutes instead of 50 minutes Problem: ======== time is represented as float, when computing the total time spent, we round the float value to 2 decimal places, which can lead to loss of precision. for example 10 minutes is represented as 0.16666666666666666 hours, and when we round it to 2 decimal places, we get 0.17 hours, which is 10.2 minutes. when we sum up 5 tickets, we get 0.85 hours, which is 51 minutes. Solution: ========= we don't round the float value to 2 decimal places, and we let the front handle the display of the time in the correct format. opw-4560872
Miscellaneous changes
Forward-Port-Of: odoo/odoo#212188
Original PR description
Forward-Port-Of: odoo/odoo#212188
Description of the issue/feature this PR addresses: The invoice date was printed as l10n_sa_confirmation_date on the report, causing confusion for users issuing backdated invoices. Additionally, the issue date was being converted to the partner's timezone, leading to inconsistencies. Current behavior before PR: The invoice date appears as l10n_sa_confirmation_date on the report. The issue date is affected by the partner's timezone. Desired behavior after PR is merged: The report will d
Original PR description
Description of the issue/feature this PR addresses: The invoice date was printed as l10n_sa_confirmation_date on the report, causing confusion for users issuing backdated invoices. Additionally, the issue date was being converted to the partner's timezone, leading to inconsistencies. Current behavior before PR: The invoice date appears as l10n_sa_confirmation_date on the report. The issue date is affected by the partner's timezone. Desired behavior after PR is merged: The report will display both the standard invoice date and l10n_sa_confirmation_date separately for clarity. The issue date will always be passed in SA timezone to the report to ensure consistency, regardless of the partner's country. task-4508551 Forward-Port-Of: odoo/odoo#200888
This is clearer. It also avoids some noisy messages in runbot. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212037
Original PR description
This is clearer. It also avoids some noisy messages in runbot. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212037
With two events having an calendar.alarm that is set for 1 hour before the event and a first event having attendees Partner1 and Partner2 and a second event has attendees Partner2 to Partner3. _do_sms_reminder will sent SMS once for each event to attendees from Partner1 to Partner3. Original issue introduced here: a1087e301122eea626ed30f34198de4666a81bdf Enabled by recent fix here ce574e5edf7bc848c867727d8c66a8e7802b029f that is batching events by alarm. opw-4812919 Forward-
Original PR description
With two events having an calendar.alarm that is set for 1 hour before the event and a first event having attendees Partner1 and Partner2 and a second event has attendees Partner2 to Partner3. _do_sms_reminder will sent SMS once for each event to attendees from Partner1 to Partner3. Original issue introduced here: a1087e301122eea626ed30f34198de4666a81bdf Enabled by recent fix here ce574e5edf7bc848c867727d8c66a8e7802b029f that is batching events by alarm. opw-4812919 Forward-Port-Of: odoo/odoo#211948
The aim of this commit is to prevent the file generated to be rejected by the administration. Before this commit: As there weren't any mapping for those country code, the field `f2112_buitenlandspostnummer` wouldn't be set in the xml. After this commit: The field is correctly set task-none Forward-Port-Of: odoo/enterprise#86886
Original PR description
The aim of this commit is to prevent the file generated to be rejected by the administration. Before this commit: As there weren't any mapping for those country code, the field `f2112_buitenlandspostnummer` wouldn't be set in the xml. After this commit: The field is correctly set task-none Forward-Port-Of: odoo/enterprise#86886
Before this commit the opening balance in the iras audit export was always at 0. This was caused because it would call _query_values which was not returning the initial balances. The fix was to instead call _get_initial_balance_values. With this we could finally get the opening balances. task-4826744 Forward-Port-Of: odoo/enterprise#86600
Original PR description
Before this commit the opening balance in the iras audit export was always at 0. This was caused because it would call _query_values which was not returning the initial balances. The fix was to instead call _get_initial_balance_values. With this we could finally get the opening balances. task-4826744 Forward-Port-Of: odoo/enterprise#86600
Besides being clearer this avoids some noisy messages in runbot. Example: ``` Cannot evaluate 'documents.document' domain: "['&', ('folder_id.read_group_ids', 'in', [g.id for g in user.groups_id]), '|', ('folder_id.user_specific', '=', False), ('owner_id', '=', user.id)]": RuntimeError('Cannot self-print iterations') while evaluating "['&', ('folder_id.read_group_ids', 'in', [g.id for g in user.groups_id]), '|', ('folder_id.user_specific', '=', False), ('owner_id', '=', user.id)]" ``` Fo
Original PR description
Besides being clearer this avoids some noisy messages in runbot.
Example:
```
Cannot evaluate 'documents.document' domain: "['&', ('folder_id.read_group_ids', 'in', [g.id for g in user.groups_id]), '|', ('folder_id.user_specific', '=', False), ('owner_id', '=', user.id)]": RuntimeError('Cannot self-print iterations') while evaluating
"['&', ('folder_id.read_group_ids', 'in', [g.id for g in user.groups_id]), '|', ('folder_id.user_specific', '=', False), ('owner_id', '=', user.id)]"
```
Forward-Port-Of: odoo/enterprise#86591…tion_reg_payslip_lines This argument causes several issues and do not make sense as there is already a default_partner_id. For example, you click on payslip lines from the contact Abigail Peterson, and it filters everything with a search on partner_id = 1, which doesn't make sense. It also causes issues if the partner with id 1 doesn't exists. opw-4516239 Forward-Port-Of: odoo/enterprise#78287
Original PR description
…tion_reg_payslip_lines This argument causes several issues and do not make sense as there is already a default_partner_id. For example, you click on payslip lines from the contact Abigail Peterson, and it filters everything with a search on partner_id = 1, which doesn't make sense. It also causes issues if the partner with id 1 doesn't exists. opw-4516239 Forward-Port-Of: odoo/enterprise#78287