Daily updates from Odoo
Wednesday, May 27, 2026
17 changes · 19.0
New functionality added to Odoo
This update introduces a new reporting type specifically for Indonesian tax returns within the Odoo Enterprise system. This addition allows businesses operating in Indonesia to accurately track and report their tax obligations, streamlining compliance processes. It expands Odoo's capabilities to meet the specific requirements of the Indonesian market.
Original PR description
Create new module l10n_id_reports and add return type for Indonesia. task-6239169
Enhancements to existing features
This update enhances the Balance Sheet report to comply with Generally Accepted Accounting Principles (GAAP). It now ensures that all equity accounts are displayed individually, providing clearer and more accurate financial reporting. This change improves the reliability of financial data for users.
Original PR description
*=l10n_us_reports In the Balance Sheet, according to the GAAP rules, all equity accounts should be individually visible. task-6240500
This update improves the speed of auditing large financial reports. Previously, navigating back and forth between reports and their details caused slow reloads and blank screens. Now, the system caches report data, speeding up the auditing process and making it more efficient.
Original PR description
When auditing large reports, users often navigate back and forth between the report and its underlying move lines. Each time the user returns to the report, it triggers a full reload, resulting in a blank screen and long wait time making auditing slow and painful. This commit caches the report information, and line expansion rpc calls in disk. RPC calls are being called asynchronously, and the report is updated if data changed. While data is being refreshed in the background, cached report is displayed along with a warning banner informing the user that report is being loaded. task-5145462
Resolved issues and error corrections
This update corrects a technical issue in the GSTR2B report generation, ensuring accurate reporting of non-GST supplies. The change updates a key used to identify these supplies, resolving a potential discrepancy in tax reporting. This ensures compliance and reliable data for tax filings.
Original PR description
Before this commit, the domain of the non-GST supplies report line in GSTR2B used the GSTR section `purchase_nongst`, while the actual section key is `purchase_non_gst_supplies`. This commit fixes the domain by using the correct GSTR section key. task-6239820
This update resolves an issue where invoices with excessively long item descriptions were being rejected by the Kenyan Revenue Authority (KRA) eTIMS system. The fix truncates descriptions to meet the 200-character limit specified by eTIMS, ensuring successful invoice submission and avoiding delays. This prevents potential disruptions to VAT processing.
Original PR description
The eTIMs specification limit the `itemNm` to 200 characters, so truncate the invoice line description to that limit to ensure that the invoice can be correctly submitted eTIMS server. Otherwise it will be rejected with: ``` Error sending to the KRA: - Request parameter error[<ItemList><itemNm>: length must be between 0 and 200] ``` Task-Id: 5220129 Forward-Port-Of: odoo/enterprise#118152
This update ensures that when a marketing automation email fails and is retried, it only resends to records within the original campaign filter, not the entire mailing template. Previously, clicking 'Retry' sent emails to all records matching the template, causing unintended distribution. This fix maintains accurate targeting and prevents wasted email sends.
Original PR description
Clicking Retry on a mailing tied to a marketing automation campaign resends the email to records outside the campaign filter instead of only the failed recipients. ### Steps to reproduce 1. Create a…
Clicking Retry on a mailing tied to a marketing automation campaign resends the email to records outside the campaign filter instead of only the failed recipients. ### Steps to reproduce 1. Create a marketing automation campaign with a filter. 2. Add an email activity and start the campaign. 3. Force at least one email to fail. 4. Click Retry on the mailing form. The email is sent to every record matching the mailing template, not just the failed ones. ### Cause When an activity runs, it computes the matching record ids from the campaign filter and calls `action_send_mail(res_ids)` with that explicit list. The Retry button calls `action_retry_failed`, which deletes the failed mails and traces, flips the mailing to `in_queue`, and lets the mass mailing cron resend it. That cron calls `_action_send_mail()` with no ids, so it falls back to the mailing template's own domain, which is unrelated to the campaign filter. ### Fix Override `action_retry_failed` for mailings tied to a marketing activity. Instead of requeuing through the mass mailing cron, reset the failed `marketing.trace` rows back to `scheduled`, cancel their already scheduled children so the next run does not double up, reactivate any participant that was marked `completed`, and trigger the marketing automation cron. That cron runs `execute_on_traces`, which re-applies the campaign filter before sending. Non automation mailings keep the original behavior via `super()`. opw-6010465
This update corrects a technical issue where multiple executions of a process could create invalid CFDI invoices with duplicate Addenda nodes. The fix ensures CFDI invoices adhere to strict XML standards, preventing rejection by recipient systems and maintaining compliance with Mexican tax regulations. This improves invoice processing reliability.
Original PR description
Before this commit, if the `_l10n_mx_edi_cfdi_invoice_append_addendas` method was executed more than once on the same invoice, the resulting CFDI would contain multiple `<cfdi:Addenda>` nodes. This…
Before this commit, if the `_l10n_mx_edi_cfdi_invoice_append_addendas` method was executed more than once on the same invoice, the resulting CFDI would contain multiple `<cfdi:Addenda>` nodes.
This occurred because the method manually injects the new Addenda string at the end of the XML without checking if one was already present from a previous execution.
According to the SAT's Anexo 20 and the CFDI 4.0 XSD, the Addenda must be a single node and the last element of the Comprobante. Duplicating root-level nodes like `cfdi:Addenda` is a bad XML formation practice that can cause rejection by the recipient's automated systems.
This fix ensures the CFDI structure remains valid by:
1. Searching for an existing `{*}Addenda` node in the CFDI string.
2. Removing the old node before reconstructing the XML.
3. Preventing the string replacement logic from stacking multiple Addenda blocks.
This ensures that the CFDI remains clean and compliant with the official standard even if the process is triggered multiple times.This update fixes an issue where CFDI (Mexican electronic invoice) documents were being generated with incorrect length limits for key attributes like 'Folio' and 'Serie'. The values were swapped, which caused invalid documents. Importantly, this change does not affect existing valid invoices.
Original PR description
Issue: length limits for attributes `Folio` and `Serie` of the `<cfdi:Comprobante>` elements were swapped, which could result in generation of invalid documents. Solution: swapping the values. This should not affect anything for existing valid documents. task-6046738 Forward-Port-Of: odoo/enterprise#118105 Forward-Port-Of: odoo/enterprise#116955
This update corrects a bug where refund processing triggered the unintended cancellation of original invoices in the Mexican CFDI module. The fix adds a check to ensure the automatic cancellation flow only applies to invoice replacements, preventing credit notes from causing incorrect cancellations. This ensures accurate financial reporting and avoids disruptions to business operations.
Original PR description
Issue: Implementation of automatic CFDI cancel flow of an invoice substituted by a new one accidentally resulted in sending credit notes created from an invoice also triggering cancellation of the original. Solution: adding a check to only apply to invoice replacements and not refunds. ticket-6245456
This update resolves a potential issue that caused Out of Memory errors during the installation of the `sale_subscription` module on databases with a large number of sales orders. The fix ensures that newly added fields are correctly initialized to 'null' during installation, preventing performance bottlenecks and installation failures.
Original PR description
### Description: Installing `sale_subscription` on databases with a large number of `sale.order` and `sale.order.line` can cause Out of Memory (OOM) errors. The issue comes from two stored compute fields, `last_invoiced_date` and `plan_id`. Since these depend on newly added fields, they should default to `null` during installation. ### Reference: opw-6201267 Forward-Port-Of: odoo/enterprise#118203 Forward-Port-Of: odoo/enterprise#118008
This update ensures that work entry data exported to the Acerta payroll system adheres to their specific formatting requirements. Specifically, the external reference number and work entry type code are now padded correctly, resolving potential data discrepancies and ensuring accurate payroll processing. This change improves data integrity with Acerta.
Original PR description
We want to adhere to the correct format for the export of work entries to Acerta. There, the number of external reference is padded to 17, not 20, and is followed by 3 spaces, before the date. Also, the code of the work entry type is padded to 4 and followed by 2 spaces. Task: 6168106 Forward-Port-Of: odoo/enterprise#118239 Forward-Port-Of: odoo/enterprise#118124
This update resolves an issue preventing refunds in the Colombian Point of Sale (PoS) system. The fix corrects outdated code references to older function names, which were left over from a previous system update. This ensures refunds can now be processed correctly for Colombian customers.
Original PR description
**Steps to reproduce:** - Setup a columbian company, DIAN should be in demo mode - Go to the PoS and make a sale with a columbian customer - Refund it - A traceback appears **Why the fix:** Some legacy code was left untouched when we changed the old **get_partner()** to the new **getPartner()** so we got a traceback as this function does not exist anymore. We also change the **set_partner(partner)** to **setPartner(partner)** as it was also forgotten. opw-6231856 Forward-Port-Of: odoo/enterprise#118054
This update fixes a problem where users weren't notified when an expense's payment authorization status changed (e.g., cancelled). The update ensures that users receive timely updates about their expenses, improving accuracy and reducing potential issues. This resolves a previous bug where authorization updates were missed.
Original PR description
## [FIX] hr_expense_stripe: Fix error messages coherence Fix the incoherent punctuation ## [FIX] hr_expense_stripe: Fix reversed and expired authorizations Before this, when receiving an `issuing_authorization.updated` event, the event would be ignored and the user would never know that the expense had been cancelled opw-6210055
This update ensures that sales services from European companies to Northern Ireland are correctly excluded from the EC Sales List report. This change aligns with regulations and accurately reflects sales transactions. The update was specifically developed for the Belgium localization, leveraging tax tag handling for accurate reporting.
Original PR description
…in EC Sales List The services sales done from a european company to a Northern Ireland company should not be included in the EC Sales List Report. It should however be the case for goods and triangular transactions. test is added in Belgium localization because only localizations have handlers using tax tags instead of taxes, and services/goods/triangular sales distinction can be made with these. task-6007931 Forward-Port-Of: odoo/enterprise#117754 Forward-Port-Of: odoo/enterprise#110007
This update optimizes the performance of Odoo's spreadsheet functionality, specifically when working with large tables like the Accounting > Balances Sheets. By using a more targeted approach to style recalculations, the system now responds faster during actions like hovering, resizing windows, or sorting data, leading to a smoother user experience.
Original PR description
Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior. This reduces work during the "Recalculate Style" phase (for example when hovering rows in large tables such as the Accounting > Balances Sheets). It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class.
This update resolves an issue where setting Intrastat information on product templates without associated products would trigger an error. The fix ensures that the system correctly handles product templates without variants, preventing unexpected errors and improving data accuracy for Intrastat reporting.
Original PR description
Problem: The Intrastat fields on product.template are computed without being stored. They are stored in product.product and the same values are used when computing the values on product.template. When trying to set the Intrastat fields on a product template without any product, an RPC error is raised without specifying the reason. Steps to reproduce: 1. Create a new product (product.template) 2. Add an attribute to the product with Variant Creation set to Dynamic, this will set no product variants (product.product) for the product template. 3. Try to set the Intrastat Commodity Code on the product template 4. Save the product template 5. Notice the RPC error raised without any explanation opw-6179705 Forward-Port-Of: odoo/enterprise#117856
This update fixes a display issue on the payslip CFDI documents tab, ensuring that error messages from the Mexican tax authority (PAC/SAT) are now shown as tooltips. Previously, these messages weren't visible, but this change aligns the payslip view with the invoice tab, improving transparency for users regarding CFDI compliance.
Original PR description
The payslip CFDI documents tab uses the account_document_state widget but the 'message' field was not loaded in the list view. This field is required by the widget to render error tooltips showing the Code and Message from the PAC/SAT when cancellation fails. The invoice CFDI tab already includes this field as column_invisible. This commit aligns the payslip view with the invoice behavior.