Friday, June 5, 2026
15 changes · saas-19.2
Resolved issues and error corrections
This update resolves a critical issue where the Swedish SIE 4 report export would crash due to excessive memory usage. The fix dramatically improves performance by optimizing the database query and reducing the amount of data processed in Python, allowing for handling of large datasets efficiently.
Original PR description
### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive…
### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets. ### Current behavior before PR: When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash. ### Desired behavior after PR is merged: The method now utilizes a hybrid data extraction approach: - The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids. - A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query. - itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries. The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure. ### Benchmark: For Memory: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 407MB| | ~200,000 moves | 1.8GB | 174.8 MB| For Speed: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 5.10s | | ~200,000 moves | 1m29s| 5.3s| ### Reference: opw-6067999 Forward-Port-Of: odoo/enterprise#118849 Forward-Port-Of: odoo/enterprise#113227
This update fixes an issue where generated invoices for Colombia (l10n_co_dian) were incorrectly exporting a generic line number instead of the required document ID. This prevented the invoices from passing validation checks with DIAN and external systems. The fix ensures the correct document ID is used, resolving compatibility problems.
Original PR description
### Issue When generating the attached document (AttachedDocument) for Colombia, the parent document reference tag <cbc:ID> incorrectly exported a generic line counter instead of the actual document…
### Issue
When generating the attached document (AttachedDocument) for Colombia, the parent document reference tag <cbc:ID> incorrectly exported a generic line counter instead of the actual document identification number
While the DIAN platform itself accepted the file, this caused rejections in external validation tools and third-party software because they could not resolve the link back to the original invoice
DIAN Documentation: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo_tecnico_factura_electronica_vr_1_7_2020.pdf
On page 213 there is an example for ParentDocumentLineReference
On page 216 there is the specification that does not show any check
Example of the incorrect XML structure:
```xml
<cac:ParentDocumentLineReference>
<cbc:LineID>1</cbc:LineID>
<cac:DocumentReference>
<cbc:ID>1</cbc:ID>
</cac:DocumentReference>
</cac:ParentDocumentLineReference>
```
Expected XML structure:
```xml
<cac:ParentDocumentLineReference>
<cbc:LineID>1</cbc:LineID>
<cac:DocumentReference>
<cbc:ID>SETP990001021</cbc:ID>
</cac:DocumentReference>
</cac:ParentDocumentLineReference>
```
### Cause
In the template, the value for <cbc:ID> was retrieved using `parent_document.get('id')` which fetched the sequential loop index https://github.com/odoo/enterprise/blob/cd25713fd2c35737d98db29df72b2d07ae9146e8/l10n_co_dian/views/templates.xml#L272-L275
The dictionary parsing logic did not extract the true document identifier from the XML tree response or the original XML data https://github.com/odoo/enterprise/blob/13dc30679e382df5845993c880a97df600c39ed4/l10n_co_dian/models/l10n_co_dian_document.py#L429-L432
### Steps to reproduce
- Install `l10n_co_dian`
- Setup DIAN configuration
- Generate an attached document for a commercial event or invoice
- Open the generated XML file
Before the fix, the `<cac:ParentDocumentLineReference>/<cac:DocumentReference>/<cbc:ID>` tag contains a technical integer like "1" instead of the official document sequence number
opw-6164321
Forward-Port-Of: odoo/enterprise#118319A recent change incorrectly configured the Gantt view for appointments, causing new bookings to default to midnight instead of the intended start time. This fix corrects the override to the correct method, ensuring bookings now use the expected time logic. This resolves a scheduling issue impacting appointment creation.
Original PR description
The [commit] replaced the `onAddClicked` method with `_onNewClicked`, and updated all related calls and overrides accordingly. However, the appointment Gantt view override was mistakenly changed to override a non-existent `_onAddClicked` method, leaving the custom logic unused. As a result, bookings created through the `New` button in the Gantt view used midnight (12:00 AM) instead of the time derived from the custom logic as the default start datetime. This commit fixes the issue by correctly overriding `_onNewClicked`. [commit]: https://github.com/odoo/enterprise/commit/bc779c9ec5295f8d1fe06e8432c518c78c606ea2 Forward-Port-Of: odoo/enterprise#118799
This update enables users to modify vendor bills imported from the Italian tax agency (SDI). Previously, these bills were treated as final and unchangeable. This change ensures compliance with Italian regulations by allowing adjustments to imported invoices before they are submitted to the tax authority, resolving a limitation in the system.
Original PR description
- Install l10n_it_edi - Create and confirm vendor bill - Use studio to make the field l10n_it_edi_transaction editable - Input any value - The reset to draft button disappears In _compute_show_reset_to_draft_button we hide the reset to draft button if l10n_it_edi_transaction is populated in order to filter out moves already sent to the tax agency. Normally invoices and bills sent to the SDI cannot be modified. However it is possible to import vendor bills from the SDI, and their transaction field is also imported. It should be possible to modified those imported invoices. opw-6222891 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#265748
This update resolves an issue where POS users couldn't successfully initiate Mollie payments. By using a special, elevated provider for Mollie API calls, the system now correctly handles payment requests without requiring specific system-level access. This ensures a smoother payment experience for all POS users.
Original PR description
Description of the issue/feature this PR addresses: POS users can trigger Mollie terminal payments without having access to the mollie_api_key field, which is only available to base.group_system. Use a sudoed Mollie provider when checking the API key and when calling the Mollie API, matching the access pattern used by other POS terminal integrations to avoid this issue. Current behavior before PR: POS user tries to initiate a payment via mollie, receives and AccessError. Desired behavior after PR is merged: POS user can successfully initiate a payment without the need for the base.group_system. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264646
This update resolves an issue where refunded orders were still visible in the 'Orders to Settle' list when linked to a customer account. The fix ensures that orders and their associated refunds are removed from this list when the customer account balance is zero, streamlining the settlement process for users.
Original PR description
Currently, if you refund an order made on the customer account with the customer account as well, you can still see the order in the list of orders to settle. Steps to reproduce: -------------------…
Currently, if you refund an order made on the customer account with the customer account as well, you can still see the order in the list of orders to settle. Steps to reproduce: ------------------- * Open shop * Make an order using the customer account for a customer, don't invoice it * Refund one of the order using the customer account, don't invoice it * Make a new order using the customer account * In the customer list, find the customer used and select "Settle Orders" > The 2 orders are present in the list Why the fix: ------------ Originally the list would only show the orders for chich the customers have due (>0). https://github.com/odoo/enterprise/commit/bf4b6043b999b4a081b1afa73fc4113bf4db28f8 But recently the code we also see the refunds in the list as well. https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f However this new behavior is not visible if, with the refund, the customer account temporarily falls to 0. So currently we have some refunds that impact the amount to settle and some that don't. Originally we were thinking that either we should show all refunds in that list (given they use the customer account) or we shouldn't show any as it was previously. Both solutions are not ideal. * Showing them all would get the list bigger than it is and would require the customer to select the order and its refund(s) and settle them together. Since refunds are not usually done right after the order they would not be close it that list. However this solution would enable the option to remove the orders from the list requiring a few step from the customer. * Showing none isn't idea either with this use case as it means that we still see orders that were cancelled out by their refunds. To remove to order the customer has two options. Either going backend and searching the order and its refund(s) and invoice them, either settling the order but that means that now there's money deposited on the customer account. Any of the two option isn't perfect a it still requires manual intervention from the customer and wouldn't work on previous data. Creating a server action to correct those data wouldn't have been feasible either. Instead, the approach we're taking is the following: When loading the list of order to settle we want to remove the orders and the potential refunds were the customer account is evened out. We only need to look at the orders of the partners that contains refunds for which the customer account was used. If the sum of the transactions made on the customer account is 0 we can say that the order and its refunds have cancelled out each other (in terms of customer account) and we don't show them if the list of orders remaining to settle. opw-6170830 Forward-Port-Of: odoo/enterprise#117725
This update dynamically adjusts the number of pages processed when uploading PDFs to the AI chat feature. Previously, uploads were limited to 5 pages. Now, the system can handle entire documents, improving the efficiency of AI-powered conversations. This change ensures agents can fully utilize the AI's capabilities with PDF attachments.
Original PR description
Prior to this commit, when uploading a document (i.e. during a chat with an agent). Only a part of its pages would get parsed and sent to the API (5 pages). With this commit, the number of pages is made dynamic by the use of a new context key `ai_max_pdf_pages`. This variable is still set for the document autosorting features since it is not required to read the full document. Default value is None (no limit). Forward-Port-Of: odoo/enterprise#119338
This update fixes an issue where check amounts were not being properly rounded when generated in the Philippines. The change ensures that check amounts are displayed accurately, removing the "ONLY" suffix and improving the overall payment process for PH customers. This ensures compliance with local regulations and provides a more professional customer experience.
Original PR description
Current behaviour: --- When paying with checks, the amount is not rounded in the check amount in words string. Steps to reproduce: --- 1. Switch to PH company 2. Set setting Check Layout as "Print Check - PH" 3. Create a new vendor bill 4. Add a product with a specific price like 91490.15 5. Confirm the bill, click on Register Payment 6. Select Payment Method "Checks", Create Payment 7. Go to the payment, Amount in Words is wrong 8. Ninety-One Thousand Four Hundred Ninety And 15000000001/100 ONLY Expected behaviour: --- The decimal amount should be rounded, and "ONLY" shouldn't appear. Fix: --- Rounded the pay amount And backported: https://github.com/odoo/enterprise/commit/bb6c9848665709c14c5113b2c98976f869cd473b opw-6058344 Forward-Port-Of: odoo/enterprise#117679 Forward-Port-Of: odoo/enterprise#116717
This update resolves a critical issue preventing Odoo's financial reports from passing validation with the National Bank of Belgium (NBB). The fix adds missing data points to the XBRL report, ensuring compliance and accurate submissions. This change specifically addresses datapoints related to balance sheet figures.
Original PR description
This commit adds missing explanatory disclosure datapoints to the generated XBRL report. The missing disclosures resulted in failing validation when report is submitted to NBB. The datapoints are only added if the original value was non-zero. For example, the tangible assets disclosures are only added if the tangible assets in balance sheet is non-zero. Additionally, only disclosures that were reported as causing a failing validation were added. task-5977199 Forward-Port-Of: odoo/enterprise#117853
This update fixes an error in the import of Italian vendor invoices (l10n_it_edi) where pension fund tax was incorrectly applied to all invoice lines with the same VAT rate. The fix now accurately extracts the tax exemption reason from the invoice data, ensuring the correct tax is applied to each line, leading to accurate financial reporting.
Original PR description
In `l10n_it_edi` vendor bill import, the pension fund tax was incorrectly applied to all invoice lines sharing the same VAT rate, even though they have different `l10n_it_tax_exemption_reason`s, resulting in wrong entries and document total. We now extract the Tax Exemption reason from the `DatiCassaPrevidenziale` node, and use it to search the correct tax. Steps to reproduce: 1. Install `account` and `l10n_edi_it` 2. In the `4% INPS` tax, set `TC22` in pension fund type and `N2.2` in exoneration 3. Import bill from the ticket 4. See the pension fund tax is applied to all the lines. It should only be applied only to the first one. Ticket [link](https://www.odoo.com/odoo/project.task/6212975) opw-6212975 Forward-Port-Of: odoo/odoo#267066 Forward-Port-Of: odoo/odoo#265821
This update resolves an issue where Romanian E-Factura invoices were being rejected due to exceeding character limits for product names, descriptions, and notes. The system has been updated to enforce a maximum of 100 characters for names, 200 for descriptions, and 300 for notes, ensuring compliance with Romanian regulations. This prevents invoice errors and successful E-Factura transmission.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_ro_edi - Switch to a Romanian localization (e.g. RO Company) - Configure Romanian E-Factura - Create an invoice with a product having a name…
**Steps to reproduce:** - Install Accounting and l10n_ro_edi - Switch to a Romanian localization (e.g. RO Company) - Configure Romanian E-Factura - Create an invoice with a product having a name longer than 100 chars - Confirm the invoice - Send E-Factura to SPV - Fetch E-Factura status **Issue:** The invoice is rejected with the following error: "[BR-RO-L100]-The allowed maximum number of characters for the Item name (BT-153) is 100." **Similar issue with the product description:** "[BR-RO-L200]-The allowed maximum number of characters for the Item description (BT-154) is 200." **Similar issue with the note (i.e. Terms and Conditions):** "[BR-RO-L300]-The allowed maximum number of characters for the Invoice note (BT-22) is 300." **Solution:** Truncate the name of the product to 100 chars in the electronic invoice, the description of the product to 200 and the note to 300. opw-5964904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268192 Forward-Port-Of: odoo/odoo#265811
This update resolves a problem where validating delivery costs on confirmed sales orders (with real-cost carrier pricing) would trigger an error. The fix prevents the system from incorrectly updating delivery line prices and names on locked orders, ensuring smooth order processing. This improves the user experience for sales teams managing confirmed orders.
Original PR description
Sale module has setting `Lock Confirmed Sales`, which particularly doesn't allow order line modification on a confirmed order. However, when a delivery carrier is set up with Invoicing Policy = Real cost, validating the picking pushes the actual carrier price onto the delivery line, writing `price_unit` and `name`. On a locked SO this raises a UserError. Fix it by excluding the delivery line's `price_unit` and `name` from the protected fields, only when the write originates from `_add_delivery_cost_to_so`. The code path is identified by the context `allow_delivery_cost_update`, so a regular UI edit of those fields on a locked SO is still blocked. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266511 Forward-Port-Of: odoo/odoo#265721
This update fixes a performance issue in the Point of Sale interface where a large number of customers in the browser cache could cause slow loading and browser crashes. The change limits the number of partners rendered during searches, improving speed and stability for users.
Original PR description
Currently, it's possible to experience very slow loading speed of the partner list and/or browser crashes in the POS when there are thousands of customers stored in the browser cache. This appears to…
Currently, it's possible to experience very slow loading speed of the partner list and/or browser crashes in the POS when there are thousands of customers stored in the browser cache.
This appears to be caused by a few reasons compounding together:
1. While we limit the number of customers in the initial render of the list, there is no limit during the search. Therefore, if there are thousands of customers matching the search pattern loaded in the browser cache, the browser will attempt to render equally as many `PartnerLine` components.
2. A 100 ms debounce time is fast enough to trigger the render after each key stroke. 200~300ms is the industry standard for Software UI debounce.
3. For each customer rendered in the list, we may perform a search for its parent partner amongst all loaded customers with the function `PosStore.getPartnerCredit()`.
This PR aims at reducing the number of partner lines rendered in a short period of time and thus, at improving speed and avoiding crashes.
Steps to reproduce:
1. Create a fresh db + install the point_of_sale with demo data
2. Populate the res.partner model by a factor of 100 to reach 4000+ partners
3. Update the following system parameter to make sure that we load all partners in the browser cache when we open the POS session:
- `point_of_sale.limited_customer_count` -> 5000
4. Open a POS session and and click on the `Customer` button to render the partner list
5. Type `adm` in the search bar at normal typing speed
6. Crash
Ticket: opw-5435973
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#258667This update resolves an issue where inserting certain website snippets (like alerts) within restricted editable areas created invalid HTML. The fix prevents the snippet from being broken down into smaller elements, ensuring the website builder generates valid and functional code. This improves the reliability and usability of the website design tool.
Original PR description
### [FIX] website: prevent inserting block snippet with powerbox in inlines Inserting block snippet with powerbox when the selection is inside an editable part limited to an element that can only…
### [FIX] website: prevent inserting block snippet with powerbox in inlines Inserting block snippet with powerbox when the selection is inside an editable part limited to an element that can only contain inline nodes leads to invalid html (like `<div>` inside `<span>`). This commit disables insertion of block snippets when the selection is such a part of the document. Steps to reproduce: - Open website builder - Put cursor in "copyright" at the bottom of the footer - Type `/alert` and press enter - Bug: `<div>` element is inserted inside `<span>`, that is invalid html task-6259092 ### [FIX] website: prevent unwrapping `s_blockquote` on insert with powerbox When the snippet `s_blockquote` was inserted with the powerbox or pasted from clipboard in an unbreakable element which does not allow blocks as children, the `<blockquote>` element itself was abandonned and its children were inserted instead. This lead to insertion of a broken snippet. This commit marks the `s_blockquote` snippet as "unsplittable" so that always stays in one piece when inserted. Steps to reproduce: - Open website builder - Put cursor in a link - Type `/blockquote` and press enter - Bug: the snippet's children are inserted, instead of snippet itself task-6259092 Forward-Port-Of: odoo/odoo#267111
This update corrects a bug in the Point of Sale system's cash rounding method (DOWN). Previously, overpayments were incorrectly absorbed as rounding offsets, resulting in incorrect change calculations. This fix ensures accurate change calculations and a more reliable transaction experience.
Original PR description
With the DOWN cash rounding method, `asymmetricRound` used `this.isNegative(a)` to decide whether to invert the rounding direction. `isNegative` internally applies the configured method before comparing. This caused `asymmetricRound` to return 0 for genuinely negative remainders, making `appliedRounding` absorb the full overpayment as a rounding offset and zeroing out the change. opw-6268670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268272