Wednesday, April 1, 2026
3 changes · 19.0
Enhancements to existing features
This update replaces the hardcoded WKHTML reporting engine with a flexible, modular system that supports multiple reporting engines including a new Paper Muncher option. Companies can now choose their preferred reporting engine for different types of reports, improving flexibility and reducing dependency on a single solution.
Original PR description
Description of the issue/feature this PR addresses: We currently force the use of WKHTML, since it's hardcoded we can't add new reporting engines easily. The main goal of this PR is to be able to : - modularize the reporting engines - make accounting use the same generation pipeline - add a new reporting engine for paper-muncher - allow user to choose their reporting engine by company/action report/accounting report --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The inventory valuation report previously crashed when handling databases with 300,000+ products due to excessive memory usage. This fix optimizes how the system loads product data, reducing memory consumption by up to 67% and making the report usable for large-scale operations. The report now successfully handles massive product catalogs without errors or system slowdowns.
Original PR description
Behavior before: Opening the inventory valuation report on databases with 300k+ products (storable) caused an out-of-memory (OOM) error, making the report completely unusable at this scale. Behavior…
Behavior before: Opening the inventory valuation report on databases with 300k+ products (storable) caused an out-of-memory (OOM) error, making the report completely unusable at this scale. Behavior after: The inventory valuation report loads successfully and efficiently for 300k+ products without any memory errors or RAM spikes. Root Cause: In `_get_accounts_by_product()`, querying all storable products creates a massive recordset. When iterating through this recordset, the call to `_get_product_accounts()` accesses various relational and property fields (like categories and accounts). Because standard ORM prefetching was active, accessing these relational fields on the first loop iteration triggered a massive batch-fetch for all 300k+ products in the recordset simultaneously. This cascading prefetch overloaded the environment cache and caused an immediate OOM crash. Fix: Wrapped the `_get_accounts_by_product()` call in `with_context(prefetch_fields=False)`. This disables the greedy batch-loading behavior across the entire recordset. The ORM now fetches the required relational accounting fields surgically, record-by-record inside the loop, maintaining a minimal memory footprint and preventing the crash. Benchmark: | Products Count | Memory Before | Memory After | Time Before | Time After | |------------------------|-------------------------|----------------------|------------------- |----------------| | 300k+ | Memory Error | 1.1. GB | 46.63 s | 1.9 m | | 200k | Memory Error | 566.4 MB | 1.2 m | 1 m | | 100k | 873.1 MB | 286.8 MB | 36.74 s | 32.15 s | | 50k | 442.1 MB | 145.6 MB | 18.96 s | 17.65 s | opw-5462037 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
Resolved issues and error corrections
This fix corrects an error in Pakistan payroll tax calculations that was causing employees with yearly salaries above 2,200,000 PKR to be charged excessive taxes. The tax calculation was incorrectly accumulating amounts across tax brackets instead of resetting properly at each bracket level, resulting in overstated tax amounts. This fix ensures employees are taxed according to Pakistan's official tax bracket rules.
Original PR description
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install…
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install `l10n_pk_hr_payroll_account`,`hr_contract_salary` with demo data. 2) Switch to PK company. 3) Create an employee and a running contract with yearly cost 2,200,001 4) Create a payslip and compute it from the Salary Computation tab. ### **Observed Behavior:** 'Tax Bracket Yearly' is computed as `122000.24` ### **Expected Behavior:** 'Tax Bracket Yearly' should be `116000.24` ### **Root Cause:** since [commit](https://github.com/odoo/enterprise/pull/98345/commits/62f5e216518d83317618d7dbc0be4db92d1881a3), the tax computation relies on [_l10n_pk_get_tax](https://github.com/odoo/enterprise/blob/a9656336583a4d5c5b12d4d6120ec62ba1cf9151/l10n_pk_hr_payroll/models/hr_payslip.py#L9-L20) , In this method, the `result` is incorrectly accumulated with `fix` when iterating through brackets, leading to an inflated tax value. [official pakistan document](https://download1.fbr.gov.pk/Docs/20258181281745641WHT-RateCard.pdf) ### **Fix:** Use `result = fix` instead of `result += fix` so that the cumulative tax is correctly reset at each bracket. **opw-5979265** Forward-Port-Of: odoo/enterprise#112642 Forward-Port-Of: odoo/enterprise#110939