Thursday, May 14, 2026
4 changes · saas-18.4
Resolved issues and error corrections
Companies using the Indian localization must now keep the audit trail active once it has been enabled. This supports compliance with Indian Ministry of Corporate Affairs requirements and prevents accidental or unauthorized deactivation.
Original PR description
After the refactor introduced in https://github.com/odoo/odoo/commit/f280f762b6417fa1a0b09649ffbdecafcc7e7579, The audit trail feature was split into two modes: a lightweight general-purpose mode and a force-restricted mode for specific localizations (e.g., Germany), where deactivation is not allowed once enabled. In India, as per the requirements of the Ministry of Corporate Affairs, the audit trail must be maintained and cannot be disabled once activated. This commit extends the force-restricted audit trail mode to the Indian localization (l10n_in) to ensure compliance with statutory requirements. task-6182002 Forward-Port-Of: odoo/odoo#262508
Invoices using a separate invoice address could fail to confirm when cash rounding was applied with the biggest-tax method. The fix ensures rounding lines use the correct commercial customer, preventing errors and allowing affected invoices to post reliably.
Original PR description
When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install…
When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install membership module - Create a cash rounding with the 'biggest tax' strategy and 0.05 rounding - Enable customer addresses and create a partner P with an invoice address I - Create an invoice, select I as customer (P will be assigned as delivery address but this is not relevant) - Add an invoice line for 100.03 and any tax and apply the cash rounding - Confirm -> MissingError: record has been deleted Cause: - When creating the cash rounding lines, we set the `partner_id` from the invoice's partner (in our case partner I, which has P as `commercial_partner_id`). - When posting the invoice we look for lines that have partner id different than the invoice's commercial partner id and we call the write method to set the commercial partner id instead https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L5234-L5239 - In some cases, for example in the `membership` module, the override of the write method calls the super() before using `self`. https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/membership/models/account_move.py#L45-L49 But the super triggers the `_sync_tax_lines` mechanism, during which the rounding line in deleted https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_tax.py#L3102-L3110 https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L3113-L3114 Therefore `self` doesn't exist anymore when comming back in the override Fix: Setting the commercial partner on the rounding line to avoid calling the write method opw-6128868 Forward-Port-Of: odoo/odoo#262759
This update fixes an issue where discount lines in Czech VAT summary reports were incorrectly calculating values. The root cause was a conversion process that was incorrectly applying absolute values, leading to inflated report totals. The fix ensures accurate VAT reporting by only flipping the signs of negative balances, specifically for 'out_' accounts.
Original PR description
Step to reproduce: - install l10n_cz_reports_2025 and switch to cz company - create a invoice, with cz company ( as partner), of 100. - when adding products, add "Transaction code" (optional fields) to "Goods" - Add discount line, set to -10, add "Transaction code" in this line too. - confirm it Observation: - invoice is 90$ - open vies summary report for this year - value turn out to 110 Cause: - commit [1](https://github.com/odoo/enterprise/commit/892268c44b1bbc838a9f03ef36a079bfff625ca6) converts every balance to +ve and only negate it, in case of refund - in case of discount lines, price is -ve, ABS() turn it to +ve and value comes out to be wrong Fix: - instead of applying ABS() directly, we flip the signs only for out_* moves, in short when a account is credited, its balance is < 0 then we flip its sign opw- 5979262 Forward-Port-Of: odoo/enterprise#117038 Forward-Port-Of: odoo/enterprise#113087
This update corrects a CSV export issue for Danish EC Sales reports. The previous export incorrectly used 'LIST' instead of the required 'LISTE' format, leading to file rejection by tax authorities. This change ensures compliance with Danish regulations and prevents export failures.
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 Forward-Port-Of: odoo/enterprise#116554