Daily updates from Odoo
Thursday, May 7, 2026
9 changes · saas-18.2
Resolved issues and error corrections
This update fixes a limitation in how Odoo Enterprise manages its UNSPSC product codes. Previously, new codes required a full module reinstall. Now, an automated upgrade script triggered during module updates adds missing codes to the database, ensuring the system always reflects the latest industry standards. Existing product codes remain unchanged.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#112652
This update resolves an issue where commission plans with negative target values caused errors. The fix ensures the commission calculation logic handles negative targets correctly by applying absolute values within the calculation process. This expands the flexibility of commission plan setup.
Original PR description
Steps to reproduce: ------------------- 1. Install sale_commission 2. Create a commission plan based on targets 3. Try to add a new commission level with negative targets Issue: ------ Adding a commission level with a negative target results in a ```python RangeError: Maximum call stack size exceeded. ``` Cause: ------ https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/sale_commission/static/src/js/commission_plan_graph/commission_plan_graph.js#L50-L56 Negative target values caused infinite recursion in the GCD function, leading to this `RangeError`. Solution: ----------- Since the Euclidean algorithm only works correctly with non-negative integers, apply Math.abs() on both inputs before the recursion starts. This ensures negative targets are handled gracefully without causing infinite recursion. **NOTE:** Backport: c0d748f opw-6182644 Forward-Port-Of: odoo/enterprise#116050
This update fixes an issue where CodaBox statements were sometimes incorrectly routed to the wrong bank journal due to currency differences. The system now prioritizes journals with explicit currency IDs, ensuring statements are accurately assigned to the correct currency-specific account. This prevents financial discrepancies and improves the reliability of CodaBox data import.
Original PR description
When several journals share the same IBAN but use different currencies, a CODA could land on the wrong journal instead of the currency-specific one. Split the lookup in two passes: first a journal with an explicit currency_id matching the CODA, then fall back to the no-currency journal (qualified by the company currency). Steps to reproduce: - Create 2 bank journals sharing the same IBAN; one without currency and one with USD. - Setup CodaBox connection and retrieve USD statements. - Before this fix: may land on the EUR journal. opw-6048931 Forward-Port-Of: odoo/enterprise#116228 Forward-Port-Of: odoo/enterprise#114590
This update fixes an issue where Colorado state income tax calculations resulted in a positive value on payslips, which is incorrect. The fix aligns with established payroll tax principles, ensuring that taxes are always withheld from employee paychecks, not returned as refunds. This ensures accurate payroll reporting and compliance.
Original PR description
## Issue When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive. ## Steps to reproduce 1. Install *United States - Payroll*…
## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.
## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
- Wage: $0
- (Set the contract's status to *Running*)
- (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
- Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**
## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:
> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*
## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).
opw-5999856
Forward-Port-Of: odoo/enterprise#112724This update fixes a minor error in the calculation of Swiss source tax (QST) reversals within the payroll system. Specifically, it corrects a miscalculation of the minimum IS (Insolvenzsumme) during the reversal process. This ensures accurate tax reporting for Swiss businesses using the Enterprise edition of Odoo.
Original PR description
opw 6133391 Fix for the source tax correction following PR #114463 Forward-Port-Of: odoo/enterprise#115585
This update corrects a technical issue within the Odoo Enterprise's Kenyan payroll module (l10n_ke_he_payroll) that caused duplicate XML IDs for a key configuration setting. This duplication was identified and resolved to ensure accurate payroll calculations and prevent potential errors. The fix improves the stability and reliability of the module.
Original PR description
This commit avoids duplicated xml_id for `hr.salary.rule` model. In commit https://github.com/odoo/enterprise/commit/a7d51fa2ee8b1af0e807b3e9cb6e313d8885ff67, key `l10n_ke_employees_salary_pension_contribution` (sequence 72) was deleted and added key `l10n_ke_employees_salary_pension_contribution` (sequence 35). In commit https://github.com/odoo/enterprise/commit/c23243be9ca833acea7089defadbe0eaf869051d, key `l10n_ke_employees_salary_pension_contribution` (sequence 72) was added again. Forward-Port-Of: odoo/enterprise#115696 Forward-Port-Of: odoo/enterprise#85723
This update resolves an error that occurred when the account_followup module was installed without the related payment module. The fix ensures the system doesn't attempt to access a missing payment method, preventing template rendering failures for payment reminder emails. This ensures consistent email functionality.
Original PR description
Repro steps: 1. Initialize a new DB 2. Install account_followup module without payment module 3. Go to Email templates > Payment reminder 4. Click on Preview You will get an error Failed to render QWeb template for Mail Template: 'Payment Reminder' (ID: 9) Target Model: res.partner Language context: en_US Error: Error while render the template KeyError: 'payment.method' Root cause: The method `_show_pay_now_button` that was being called in the template email_template_followup_1 was using self.env['payment.method'] even tho payment module is not a dependency of account_followup Fix: The introduced fix ensures that 'payment.method' model exists before attempting to use it build_error-243030 Forward-Port-Of: odoo/enterprise#116079
This update fixes a visual issue in the Point of Sale (POS) system where the displayed change amount was not showing the correct negative value. The change ensures that the POS interface accurately reflects the amount of change given to customers, improving the user experience and reducing potential errors.
Original PR description
In this commit: --------------- - The tours are updated to adapt the change as now frontend display the change amount with the correct (negative) sign. Community PR: https://github.com/odoo/odoo/pull/256776 task: 6074620 Forward-Port-Of: odoo/enterprise#112560
This update fixes an issue where public holidays without a working schedule were not appearing in payroll reports. The fix ensures that all public holidays, regardless of their working schedule definition, are now correctly included in the SD worx report generation. This improves the accuracy of payroll calculations for Belgian businesses.
Original PR description
### Steps to reproduce: - Create a public holiday without working schedule - Generate a SD worx for the month of the public holiday - Notice the public holiday is not shown in the report ### Cause: When searching for the public holiday we don't take into condsideration the holidays without working schedule. ### Fix: Modify the domain to fetch those holidays as well opw-5500070 Forward-Port-Of: odoo/enterprise#114900