Daily updates from Odoo
Wednesday, October 29, 2025
10 changes · saas-18.2
Resolved issues and error corrections
Users can now update the email template for customer statements even after removing all recipients. This prevents an error during statement sending and keeps the workflow from being interrupted.
Original PR description
Currently, an error occurs if the recipients of the statement report are removed and the user tries to update the email template. **Steps to Reproduce:** 1. Install Accounting. 2. Customers (list view) > select any record > Actions > Customer Statement > Send. 3. Remove recipients and try to update the email template. **Error:** `KeyError - False` **Cause:** The system tries to fetch mail field values from an empty recipient list, leading to a KeyError. **Fix:** This commit recomputes the recipient partners before updating the email subject and body from the template. sentry-6918345730 Forward-Port-Of: odoo/enterprise#96273
Corrects Swedish payment processing so IBAN payments are no longer mistakenly treated as local BBAN-style payments when account type details are missing. This helps prevent payment batches from being classified incorrectly and avoids related processing failures.
Original PR description
The method `_is_se_bban` is supposed to flag if payments are bban or iban. But since 8d77c0442d7912880c5da5976c92b24d3f9885ca,
the method returns True for batch of iban payments when you don't provide the `partner_acc_type` params, because
`len({'bban_se', 'plusgiro', 'bankgiro', *(partner_acc_type or {})}) == 3`
is always True if `partner_acc_type` is None.
This commit fix that behaviour, by replacing the empty set by `{'iban'}`, meaning the second condition will always be
False when `partner_acc_type` is None.
This bug has been found by failing runbot tests (error: 233465)
no-task
Forward-Port-Of: odoo/enterprise#97876Opening the duplicate transaction wizard without a linked journal no longer causes an error. This improves reliability for accounting users accessing the view directly or before a journal has been selected.
Original PR description
When user opens the ``account.duplicate.transaction.wizard.form`` view, a traceback appears.
Steps to reproduce the error:
- Install ``Accounting`` module
- Using Open View, Open ``account.duplicate.transaction.wizard.form`` view
Traceback:
```py
UndefinedFunction: operator does not exist: integer = boolean
LINE 5: WHERE st_line.journal_id = false
^
```
https://github.com/odoo/enterprise/blob/8146cfc7b47ba8536f0fa5208cc69685371b55b8/account_online_synchronization/models/account_journal.py#L278
When the view is opened, the ``_compute_provider_duplicate_ids`` method is triggered,
which calls ``_get_provider_duplicate_transactions`` method.
Since no journal is linked to the wizard, it will raise the traceback from the above line.
ref: 218e8a365b153a202d062152ff69234482bcccf2
sentry-6943450225This fixes an issue in Studio's report editor where adding a column to reports with conditional table headers could update only some rows. Users editing documents such as Delivery Slips should now see columns added consistently across the whole table.
Original PR description
The TableSizeComputer.compute() method can return cells with incorrect cell indexes. This can result in the _addColumn function only adding a column to some rows in the report editor.…
The TableSizeComputer.compute() method can return cells with incorrect cell indexes. This can result in the _addColumn function only adding a column to some rows in the report editor. TableSizeComputer.compute() does not handle cases where a conditional is used inside of a th element but the corresponding td element does not have a conditional. Steps to reproduce ----- 1. Open the Delivery Slip in the report editor. 2. Click the header to show the dropdown and select elif: o.move_line_ids and o.state=='done'. 3. Hover over the last th element to select the column button. 4. Click Insert right and see that only the header row has an additional column. Cause ----- TableSizeComputer.compute() calculates how many possible cells can be in a row which can be more than the total number of columns you have if you have th or td elements with a conditional inside of them. In the Delivery Slip report, a th element is present when using serial numbers and a different th element is present when not using serial numbers. The corresponding t-body has two different tr elements for these conditions. The compute method will have one less cell in these rows because the corresponding conditional is handled outside of the row. Solution ----- Only count mutually exclusive th or td elements once. This prevents the cellIndex from being larger than the total possible columns. opw-ticket 5173345 Forward-Port-Of: odoo/enterprise#98207
This fixes an issue in SAF-T accounting reports where entries without a linked customer or supplier could be handled incorrectly. The report filtering now accounts for this case, helping prevent reporting errors and improving reliability for accounting exports.
Original PR description
### Issue: After #95804 , some of the code was improved but the consideration for partner_id being None was not expected. To fix this issue, we add partner_id on the domain. OPW-5177365 Forward-Port-Of: odoo/enterprise#98240
Restaurant kitchen displays now stay in sync when staff merge, transfer, link, or unlink tables. Merged orders correctly combine item quantities, and linked table names show all related tables so kitchen staff have clearer order information.
Original PR description
- **Task:** [#5005179](https://www.odoo.com/odoo/my-tasks/5005179) - **Community:** [#225700](https://github.com/odoo/odoo/pull/225700) - **Enterprise:** [#93997](https://github.com/odoo/enterprise/pull/93997) - **Runbot:** [saas-18.2-fix_merging_tables_kitchen_display-ltra-397311](https://runbot.odoo.com/runbot/bundle/saas-18.2-fix_merging_tables_kitchen_display-ltra-397311) --- **Before** - The kitchen display was not updated when transferring, merging, or linking orders between tables. - When merging orders with the same product, quantities were not summed correctly, requiring the product to be ordered again. - When linking 3 or more tables, the linked table name only showed the first two tables. **After** - The kitchen display is now notified when transferring, merging, unmerging, or linking orders between tables. - Product quantities are correctly aggregated when merging orders. - The names of linked tables now include all related tables, sorted by table number.
Corrects how discounts are rounded when creating Mexican global invoices, preventing valid invoices from being rejected due to small rounding differences. This helps businesses issue compliant CFDI documents without manual workarounds for discounted invoice lines.
Original PR description
Steps to reproduce: ------------------- * Create an invoice with the following line: * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50% * Confirm, create a global invoice > Observation: Error ```…
Steps to reproduce: ------------------- * Create an invoice with the following line: * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50% * Confirm, create a global invoice > Observation: Error ``` Code : CFDI40108 Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual al redondeo de la suma de los importes de los conceptos registrados. ``` Why the fix: ------------ The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63. https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336 Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62. opw-5023597 Forward-Port-Of: odoo/enterprise#94438
Deleting a signer role from a Sign template no longer causes an error when that role includes radio buttons. This prevents interruptions while editing templates and keeps the signing setup workflow reliable.
Original PR description
Before this commit, when deleting a Signer role that already had a radio button dropped in the Template, it would trigger a traceback since the were trying to delete radio buttons individually. This was problematic because radio buttons are deleted in chain, so when deleting the first, we already delete all the remaining radio buttons and its chain link. After this commit, no issue is raised anymore when deleting a signer role, as radio buttons already deleted are now skipped in the code. task-5130925
This fix restores Swedish POS blackbox validation so orders are properly processed under the current POS synchronization flow. It also fixes receipt reprint tracking and corrects the organization number format, helping Swedish businesses stay compliant and avoid checkout disruptions.
Original PR description
Before this commit, the Swedish blackbox was completely broken in 18.0 because the `push_single_order` function is no longer used. To fix this, the same approach as `pos_blackbox_be` was used, where the `preSyncAllOrders` function was overridden instead. In addition, the old receipt reprinting logic was no longer working, and so it now uses the `nb_print` field to keep track of the number of reprints. Finally, we also forward port a fix from 17.0 (ddbc1fc) to correct the format of the organisation number, which for some reason was not forward ported originally. task-5077448 Forward-Port-Of: odoo/enterprise#98139
Batch payments now show a clear, non-blocking warning when SEPA Credit Transfer partners are missing required country or city information for structured addresses. This helps users fix partner records before generating payment files that would become invalid under the November 2026 SEPA rules.
Original PR description
Starting from November 15th, 2026, SEPA Credit Transfer (SCT) payments require both the partner's country and city to be defined when using structured addresses. If missing, the generated XML file will be invalid. This change adds a non-blocking red banner on the batch payment form to warn users and provide a link to review the affected partners. task-5156613 Forward-Port-Of: odoo/enterprise#97598