Monday, September 28, 2026
10 changes · saas-19.3
Enhancements to existing features
This update adds the missing IGIC receivable and payable accounts to the Canary Islands chart of accounts. It helps Odoo post tax adjustments to the right accounts when closing tax periods or preparing tax reports, reducing manual accounting corrections.
Original PR description
… CoA The Canary Islands chart of accounts was missing dedicated receivable/payable accounts for IGIC. Without these, Odoo cannot automatically post tax adjustments to the correct accounts when closing tax periods or generating the tax report. Add accounts 470700 (Hacienda Pública, deudor por IGIC, asset_receivable) and 475700 (Hacienda Pública, acreedora por IGIC, liability_payable) to the common Canary Islands account template, and set them as tax_receivable_account_id and tax_payable_account_id on all IGIC tax groups. Change to the canaries association their correspondent account codes overwriting the names. task-6225928 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270139
Resolved issues and error corrections
Unreconciling one partial match on an invoice now removes only the selected match instead of clearing other related payments or credit notes. This prevents accidental changes to invoice payment status and keeps accounting records consistent.
Original PR description
Repro steps: 1) Create an invoice I 2) Partially reconcile I with a credit note CN 3) Partially reconcile I with a payment P 4) Unreconcile one of the 2 partials Problem: If you unreconcile one partial, both partials are removed (an exception is when account_accountant is installed, not just account, in that case, unreconciling P works fine, but unreconciling CN, also unreconcilies P still) Root cause: account.move.line.remove_move_reconcile used to unreconcile on move level instead of line level because of this PR https://github.com/odoo/odoo/pull/249536 Solution: The logic in remove_move_reconcile is kept simple, and it only unreconciles on account.move.line level. A new method is also introduced account.move._remove_reconciliation_between_moves to unreconcile on the move level, and this one is used with the account payment field to solve the aforementioned issue. task-6574942
Payments in Mexican electronic invoices now keep the same official currency exchange rate as the related invoice when the recalculated rate is within the accepted rounding range. This prevents mismatched invoice and payment XML rates, reducing rejected CFDI documents and reconciliation confusion for USD transactions.
Original PR description
Issue: Currency rate for payment is recomputed up to 6 digit. However, it may differ from the official one stored in db up to 4 digits. Which creates differencies between invoice and payment rate…
Issue: Currency rate for payment is recomputed up to 6 digit. However, it may differ from the official one stored in db up to 4 digits. Which creates differencies between invoice and payment rate made at the same date. Steps to reproduce: - In MX company, - Enable USD, - Set currency rate for today to 1 USD = 17.4455 MXN - Create a PPD invoice (due date > 40 days) in USD - Add a line with - qty: 1, - unit_price: 3.488 - tax: 16% (default tax) - Send it to CFDI - Create payment - On the invoice Form click on "Update Payment" Current behavior: - In the CFDI sheet, Payment and Invoice XML files will have different currency rates Expected behavior: - In the CFDI sheet, Payment and Invoice XML files will have the same currency rate Cause: PACs require having the payment `amount` to be equal to `currency_amount * currency_rate`. For huge amout it may happen that using the 6 digits rounding of currency rate to compute the amount won't fall exactly on the two digit precision for the amount and payment would be refused. Therefore, for all payment, we recompute a 6 digits precision `currency_rate` from `amount` and `currency_amount` then using it to compute the final amount. However, Banxico (Mexican central Bank) publish rates with a 4 digit precision. Recomputing the currency rate up to 6 digits may slightly change it from the 4 digit precision official currency rate. opw-6411530 Forward-Port-Of: odoo/enterprise#132659 Forward-Port-Of: odoo/enterprise#129700
This fix prevents self-ordering kiosks from printing duplicate preparation tickets when customers use a different language from the kiosk default. Orders now produce a single preparation ticket in the kiosk language, reducing staff confusion and avoiding extra confirmation steps for customers.
Original PR description
When having a Kiosk config with a preparation printer and kiosk have multiple language we have the following issue: - Change language (use a different than default Kiosk lang) - Create order, add…
When having a Kiosk config with a preparation printer and kiosk have multiple language we have the following issue: - Change language (use a different than default Kiosk lang) - Create order, add lines - Pay the order - Confirmation page → Print preparation ticket in customer language - Click close → Trigger a page reload (reset to Kiosk default lang) and print a second preparation ticket in default Kiosk lang - Then we have to click again "Close" on the confirmation page a second time → Two preparation tickets printed & we have to close the confirmation page 2 times After the fix: A ticket is rendered in the language loaded with the page, so the confirmation page only prints it when the kiosk is already in its own language Otherwise it stores the order access token, restores the language and loads the default root: the next page prints the ticket, once, in the kiosk language task-id: https://www.odoo.com/odoo/project/1737/tasks/6559206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The expense app now correctly warns users when they submit an expense that appears to duplicate an existing one. This helps prevent accidental duplicate reimbursements and improves expense review accuracy.
Original PR description
Steps to reproduce: - install hr_expense_extract - create an expense and submit it - duplicate that expense, and submit it - no warning dialog showed up when one should.
Fixes an issue where adding users to payroll groups from the Groups screen could fail and prevent the change from being saved. Group membership additions and removals are now consistently audit-logged, improving reliability for Australian payroll administration.
Original PR description
#### Description of the issue/feature this PR addresses:
Adding a user to a group from the Groups form crashes on an Australian Payroll-API database, and removals from that form are never audit-logged.
#### Current behavior before PR:
The audit-logging mixin reads the changed users out of the raw write command with vals.get("user_ids")[0][2], which assumes a 3-element command tuple. The Groups form sends the 2-element (4, id) LINK command, so the write raises an IndexError; UNLINK commands are silently not logged for the same reason.
#### Desired behavior after PR is merged:
Group membership changes made from the Groups form are audit-logged for both additions and removals, regardless of the command used to write user_ids. The mixin reads the members before and after the write instead of interpreting the command. No field, model or method-signature change, so it is safe in stable.
opw-6397011
Forward-Port-Of: odoo/enterprise#132821
Forward-Port-Of: odoo/enterprise#125124This fixes the employee HR responsible selector so it only shows users with the appropriate HR or Time Off Officer permissions. It prevents incorrect or overly broad choices, helping businesses assign time off responsibilities to the right authorized people.
Original PR description
Issue: ---------------------------------------- The domain of the field `hr_responsible_id` isn't computed. Also it should contain `hr_holidays.group_hr_holidays_user`. Cause:…
Issue: ---------------------------------------- The domain of the field `hr_responsible_id` isn't computed. Also it should contain `hr_holidays.group_hr_holidays_user`. Cause: ---------------------------------------- The domain of the field is returned by `_get_hr_responsible_domain()` as a string which is not supported. https://github.com/odoo/odoo/blob/2ea452d03aa0cbfe360c539fb3b29a7b89aa7297/odoo/orm/fields_relational.py#L112-L123 `validated()` returns `None` so the domain is left empty. Solution: ---------------------------------------- Return a list instead of a string. Also, override the field in `hr_holidays` and and the condition on `hr_holidays.group_hr_holidays_user`. Note: ---------------------------------------- This [commit](https://github.com/odoo/odoo/commit/ff50687bad2939db882e75ae20f28e6155fa2191) did the same thing in saas-19.4 but added a useless field in `hr.employee` because it did not catch the error of the string being wrong. opw-6545508 Forward-Port-Of: odoo/odoo#289243
The Swiss balance sheet report formulas were adjusted to produce more accurate financial results. This helps Swiss companies rely on the report for clearer and more compliant financial reporting.
Original PR description
Change some formulas in the Swiss balance sheet task-6379692 Forward-Port-Of: odoo/enterprise#123895
Kenyan eTIMS reporting now excludes taxes that do not have a KRA tax code from the reported tax-inclusive total. This prevents levies paid to other authorities, such as tourism levies, from being incorrectly included in tax authority submissions.
Original PR description
Issue: Non KRA taxes are sent in eTIMS tax total Steps to reproduce: - With l10n_ke_edi_oscu - Create a 2% Tax named CTL with no KRA Tax Code - Create an invoice - Add a line with 16% and CTL taxes - Confirm - Send to eTIMS Current behavior: - eTIMS JSON (unaccessible) is created with 'totAmt' (total_tax_included) including non-KRA Taxes Expected Behavior! - eTIMS JSON 'totAmt' doesn't incldue non-KRA Taxes Note: eTIMS is used to report to Tax Autority, however some "taxes" (e.g. Tourism levy) are paid to other authorities (e.g. Tourism Fund) and shouldn't be included in eTIMS. opw-6456478 Forward-Port-Of: odoo/enterprise#131577
Italian invoices using the Import/Export fiscal position will now apply only the appropriate 0% tax instead of adding an extra N7 tax by default. This prevents incorrect tax combinations on invoice lines and helps businesses produce cleaner, compliant invoices.
Original PR description
Upon Import/Export, the 0% EX N7 tax is added by default on each tax excluded line, as it incorrectly shares the same default Import/Export fiscal position with the standard 0% EX tax. This causes both to be applied simultaneously to a single invoice line. 1. Install Accounting and `l10n_it` 2. Switch to IT company 3. Go to Invoices and create a new one 4. Select the Import/Export fiscal position 5. Add a line with a new product (so it's clean of custom product taxes) 6. Both `0% EX` and `0% EX N7` taxes are applied, instead of just `0% EX` Ticket [link](https://www.odoo.com/odoo/project.task/6518926) opw-6518926 Forward-Port-Of: odoo/odoo#285586