Daily updates from Odoo
Monday, May 18, 2026
4 changes · 17.0
Resolved issues and error corrections
This update fixes an error in the Luxembourg Annual VAT Declaration report that resulted in incorrect calculations for Appendix E 1a. The fix ensures that key financial data is accurately included in the report, improving the reliability of VAT reporting for Luxembourg businesses. This resolves a discrepancy in the reported total.
Original PR description
### Issue: The formula `L10N_LU_TAX_163` in the Luxembourg Annual VAT Declaration was incorrect: - `L10N_LU_TAX_791.year_start` was added twice - `L10N_LU_TAX_993.year_start` was missing As a result, the computed total in Appendix E 1a was incorrect ### Steps to reproduce: - Install `l10n_lu_reports` - Open the `Report: Annual VAT Declaration (LU)` - Go to `Appendix E` - Use the `Start of Financial year` pencil icons to manually set values for fields `791` and `993` - Check the computed value of field `163` After the fix, both values are included exactly once in the formula opw-6158950
This update resolves a critical issue causing OOM crashes when generating the Swedish SIE 4 report for large datasets. By optimizing the database query and data processing, the report now runs significantly faster and with reduced memory usage, improving overall system stability and efficiency.
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
This update resolves an issue that previously prevented users from creating taxes within the 'Accounting' module in version 17.0. The fix involves a temporary workaround to handle data loading errors, ensuring tax creation functionality is reliably available. This improves the stability and usability of the accounting process.
Original PR description
Steps to reproduce: - Install `Accounting` module - Create a fiscal position with the configuration shown in the [attachment](https://www.awesomescreenshot.com/image/60382236?key=e3bd2a051bfd2eed3c176e1569ee7c82) - Click `here` for creating tax Solution: This is a backport of the fix implemented in later versions (>17.0). Here, we store the failed fields, temporarily set them to False, and remove them entirely before record creation. commit-1: https://github.com/odoo/odoo/pull/193760/changes/6c4f68116532e036748b77172031c8ecc1775d37 commit-2 : https://github.com/odoo/odoo/pull/132696/changes/38a1e5d19ab9c9fc27bfe55090bff0a22fa20c5c opw-6195611
This update resolves an issue where payments weren't automatically linked to invoices when an invoice was created before the payment cleared. This ensures accurate reconciliation of payments and invoices, preventing potential accounting discrepancies and improving financial reporting accuracy.
Original PR description
Steps to reproduce: - Ensure Automatic Invoice setting is on - Create sales order for product with ordered quantites invoicing policy - Generate a Payment Link - Pay with the ACH Direct Debit method via a provider (e.g. Stripe) - While the payment is processing, confirm the sales order, create an invoice, confirm the invoice Current Behavior: When the payment is finished processing, the payment is not automatically linked to the corresponding invoice Expected Behavior: When the payment is finished processing, the payment should be linked to the invoice despite it being created by a user Explanation: The payment transaction's link to invoice_id is severed in PaymentTransaction._invoice_sale_orders if an invoice is created before the payment is cleared. This will eventually lead to the account.payment created automatically later on not being reconciled with the invoice. opw-6087656