Daily updates from Odoo
Monday, December 22, 2025
2 changes · 17.0
Resolved issues and error corrections
This update fixes a memory error that occurred when processing recurring invoices for subscriptions with large databases. By optimizing how the system retrieves data, the change significantly reduces memory consumption and prevents crashes, ensuring smoother operation for users with many subscriptions.
Original PR description
A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the…
A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the compute method overwrite `_get_invoiced` in the sale_subscription module can consume a lot of memory. The issue is mostly coming from the search on account.move.line. In case a lot of account.move.lines have a subscription_id, the search to get `all_subscription_ids` is going to return a lot of records. Then, accessing any field on this recordset will prefetch all the prefetchable fields, leading to a MemoryError. This commit fixes that by manually fetching the fields we need on account_move_line. Since `subscription_move_lines` is not used anywhere else and `move_by_origin` only contains ids, the number of queries stays the same while the memory consumption plummets. #### Benchmark In a database with 236 000 account.move.line with a non-null subscription_id, running the schedule action with 5 subscriptions to invoice consumes at least 1.7GB (MemoryError raised). After this commit it consumes 191MB. <img width="1918" height="943" alt="sale_subscription_before" src="https://github.com/user-attachments/assets/e868921f-e691-47c3-8474-edb9a1d22d0b" /> <img width="1920" height="949" alt="sale_subscription_after" src="https://github.com/user-attachments/assets/78e9fc31-4c5f-4369-8bd0-494ca2c693fd" />
This update fixes a bug in the TPAR report that caused errors when calculating gross paid for vendors using asset_cash accounts. The change ensures accurate report generation by including all relevant payment lines, preventing report failures and improving financial reporting reliability.
Original PR description
Behavior before: Exporting the TPAR report could fail with an error indicating that the GST amount exceeded the gross paid for certain vendors. Some payment lines were excluded from the SQL query,…
Behavior before: Exporting the TPAR report could fail with an error indicating that the GST amount exceeded the gross paid for certain vendors. Some payment lines were excluded from the SQL query, leading to discrepancies in the report. Behavior after: The SQL query has been updated to include all relevant payment lines, including those in asset_cash accounts. This ensures that the gross paid is calculated correctly, allowing the TPAR report to be exported without errors. Root Cause: The previous query only considered asset_current and liability_current accounts, ignoring asset_cash accounts. This omission caused the gross paid amount to be understated relative to the total GST paid. Steps to Reproduce: 1. Create a vendor bill. 2. Navigate to the Bank Reconciliation page (Accounting → Dashboard → Bank Journal). 3. Create a bank statement line for the bill amount. 4. Validate the statement line with the corresponding invoice line. 5. Generate the TPAR report — the payment amount should now be correctly included. OPW: 5148697