Monday, July 7, 2025
3 changes · 18.0
Enhancements to existing features
Account merging now avoids loading very large volumes of accounting entries when updating the merged account code. This reduces the risk of memory errors and makes the process much faster for companies with large accounting databases.
Original PR description
### Issue --> The final step of the `_action_merge` method updates the `code` field of the account onto which the other accounts are merged. During the write call on `code`, a dependent field…
### Issue --> The final step of the `_action_merge` method updates the `code` field of the account onto which the other accounts are merged. During the write call on `code`, a dependent field `always_tax_exigible` on `account.move` gets added to the compute chain. This causes a fetch of all `account.move` records related to journal items related to the account that is getting updated. This can lead to a MemoryError on databases with large `account.move` tables. ### Solution --> We delegate the write of the `code` field to SQL. In the account merge wizard, accounts that can be grouped are grouped by the keys --> `'account_type', 'non_trade', 'currency_id', 'reconcile', 'deprecated','name'`. Therefore, the `account_type` does not change after the merge. We can safely assume that any fields dependent on `account_type` do not need recomputation and hence, bypass the ORM for this update. ### Benchmark --> For an account with ~1.17M related `account_move_lines` and ~570k `account_moves`, | Before Fix | After Fix | |--------|--------| | TO/Memory error past TO | ~24s | #### Additional change --> Disable the prefetcher in the write call in `account.account` to optimize memory usage on databases with a large number of journal items/journal entries when writing on `code` or `account_type` in general. opw-4839985
French VAT reporting can now submit an empty declaration when there is no tax to report, reducing manual work and preventing blocked filings. If an electronic submission fails, the system creates a follow-up activity on the closing entry so users can spot and resolve the issue without logging into each company separately.
Original PR description
There were 2 missing points in the tax report export in France: 1. Not possible to send empty tax report 2. The only way to know if a tax report has an error is to connect to the company This commit solves these issues by the following: 1. Adding `zone KF` to the XML export (and showing a user a warning with `check box "déclaration néant" checked`) which allows for sending empty tax report 2. If the EDI export is in error, an activity is added to the closing entry like the following https://app.excalidraw.com/l/65VNwvy7c4X/7ed0dmqcHNM backport of: https://github.com/odoo/enterprise/commit/fecbd62eeef4e6041403bff53a3b53fb8237a0cb task-4370133 task-4458309
Colombian localization now retrieves customer name and email from the official DIAN service using only the identification type and number. This helps businesses comply with Colombian rules limiting what customer information they can request directly.
Original PR description
The Colombian government restricts the information a company can ask from their customers to only their identification type and number. The other data (name and email) is required to be fetched from the DIAN service. task: 4796355