Monday, April 20, 2026
4 changes · 19.0
Enhancements to existing features
Backdated inventory valuation for average-cost products now avoids unnecessary historical quantity checks across unrelated products. This can greatly reduce processing time on large databases while keeping the same valuation results.
Original PR description
When computing Inventory Valuation with a past `As of` date for AVCO products, `_run_average_batch()` reads `qty_available` for each manual `product.value` entry with `product.with_context(to_date=manual_value.date).qty_available`. On large databases, products can carry a broad prefetch set through the `product.value` browsing path. As a result, each distinct `to_date` may compute `qty_available` for more products than necessary. This change narrows the prefetch ids to the products sharing the same manual value date before reading `qty_available`. This keeps the same `to_date`, the same quantity computation, and the same per-product result, while reducing the amount of historical quantity computation done for each date. | Stock moves | Before PR | After PR | | --- | ---: | ---: | | 785k | fails after ~900s | 183s | opw-5944584
Argentina tax amount calculations now use Odoo’s standard tax calculation engine instead of custom invoice line queries. This improves consistency and prepares the localization for future Argentina-specific tax updates with lower risk of incorrect totals.
Original PR description
This commit refactors the tax amount calculations on the `_get_vat` and `_l10n_ar_get_amounts` method so that it uses the tax computation engine helpers properly, to prepare for any future fixes done on how Argentina tax calculations differs from all other localizations. This replaces all move line queries with the proper `base_line` calculation, with the proper aggregating methods. related-enterprise-PR: https://github.com/odoo/enterprise/pull/92639 task-4891206 Forward-Port-Of: odoo/odoo#223393
This update corrects how tax amounts are calculated in Argentine electronic invoicing and related reports. It helps ensure invoice totals and tax breakdowns are more precise and consistently formatted, reducing mismatches in printed or reported amounts.
Original PR description
- Rewrite all tax amounts calculations on `_get_tributes` and `_get_line_details` to properly use the tax computation engine helpers (`base_line`, and aggregating methods) - Ensure that all final amounts from the calculation are formatted with `float_repr` with appropriate precision. related-community-PR: https://github.com/odoo/odoo/pull/223393 task-4891206 Forward-Port-Of: odoo/enterprise#92639
After databases are synchronized with Odoo.com, the system now tries to create a local API key for each database that does not already have one. This reduces the need to rely on a shared global key and speeds up database access, especially when the key is not already cached.
Original PR description
Before this commit, databases fetched from Odoo's SaaS were contacted using the global API key, which is more costly than using a key local to each database. Avoiding the call from the server to Odoo to check the foreign API key can spare about 500ms on each database where this key is not in the LRU. With this commit, after the synchronization with Odoo.com, we try to generate an API key on each database that doesn't have one yet. To do so, it relies on the API introduced by odoo/odoo#246118.