Thursday, May 22, 2025
2 changes · 18.0
New functionality added to Odoo
This adds Oman-specific accounting setup so businesses operating in Oman can configure Odoo with local accounts, taxes, fiscal positions, states, and tax reports. It helps companies meet local reporting and tax requirements more quickly during implementation.
Original PR description
Add localization for Oman: - Accounts - Taxes - Fiscal positions - States - Tax reports task ID: 3927925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Analytic accounting reports now avoid creating very large temporary data copies when users open or refine reports. This prevents timeouts on high-volume databases and makes affected reporting screens usable again, reducing upgrade blockers for customers moving to 18.0.
Original PR description
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the…
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the reporting feature would be unusable for them. DBs already in 18.0 for which the issue is not happening at the moment will stop working as soon as enough data is added to the DB.
In this patch we propose to switch to a view-based approach. This doesn't create any new data, and it is able to use exiting indexes. The timing goes from minutes to seconds. The frontend is usable again.
Example of the data stored in the temp table:
```
=> select count(*) from analytic_temp_account_move_line
+----------+
| count |
|----------|
| 60669759 |
+----------+
```
The example DB has 31 "plan columns". In other words we are duplicating 31 times 1957089 rows. That's too much data. It's also a waste of space and time. Especially if we later issue more filtering commands as the report is refined in the frontend. This leads to current approach being unusable for some clients. In the example DB the timing is bigger than the standard timeout for frontend requests.
Planning and execution of for the insert in the temporary table:
```
Insert on analytic_temp_account_move_line (cost=0.86..6659742.75 rows=0 width=0) (actual time=209651.484..209651.487 rows=0 loops=1)
-> Subquery Scan on "*SELECT*" (cost=0.86..6659742.75 rows=157594266 width=548) (actual time=644.693..92507.579 rows=60669759 loops=1)
-> Result (cost=0.86..5083800.09 rows=157594266 width=548) (actual time=644.689..85762.552 rows=60669759 loops=1)
-> ProjectSet (cost=0.86..1143943.44 rows=157594266 width=366) (actual time=644.657..72959.699 rows=60669759 loops=1)
-> Merge Left Join (cost=0.86..317844.46 rows=5083686 width=486) (actual time=644.562..22711.962 rows=1957089 loops=1)
Merge Cond: (account_analytic_line.move_line_id = account_move_line.id)
-> Index Scan using account_analytic_line__move_line_id_index on account_analytic_line (cost=0.43..97499.67 rows=1957619 width=150) (actual time=641.529..7738.521 rows=1957089 loops=1)
Filter: (general_account_id IS NOT NULL)
Rows Removed by Filter: 136994
-> Materialize (cost=0.43..144877.29 rows=2272735 width=344) (actual time=3.014..13564.293 rows=3022715 loops=1)
-> Index Scan using account_move_line_pkey on account_move_line (cost=0.43..139195.45 rows=2272735 width=344) (actual time=3.005..11312.577 rows=2274827 loops=1)
Planning Time: 132.775 ms
JIT:
Functions: 78
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 4.236 ms (Deform 2.533 ms), Inlining 64.617 ms, Optimization 351.121 ms, Emission 222.715 ms, Total 642.690 ms
Execution Time: 209672.536 ms
```
Planning and execution of a query based on the new view (note the usage of indexes from the actual tables):
```
Hash Join (cost=72813.40..294958.00 rows=7724 width=4) (actual time=1760.970..3493.933 rows=61 loops=1)
Hash Cond: (account_move_line.account_id = account_move_line__account_id.id)
-> Subquery Scan on account_move_line (cost=72794.39..294349.71 rows=223360 width=8) (actual time=1725.998..3477.187 rows=246 loops=1)
Filter: (account_move_line.analytic_distribution = ANY ('{1703,898,896,890,648,670,673,685,818,899,828,837,846,849,848,891,901,904,905,906,907,942,952,1039,980,985,1049,1050,1051,1093,1107,1114,1233,1126,1129,1133,1151,1152,1153,1222,1272,1218,1230,1243,1282,1249,1369,1271,1286,1328,1371,1396,1432,1403,1404,1406,1409,1430,1431,1437,1449,1473,1498,1515,1516,1517,1524,1525,1527,1528,1543,1549,1588,1592,1604,1605,1784,1641,1650,1652,1676,1677,1678,1679,1680,1702,1751,1759,1760,1767,1964,1796,1826,1832,1838,1926,1866,1883,1916,1922,1923,1954,1963,2144,1977,1974,2005,2011,2013,2015,2016,2032,2035,2037,2038,2064,2142,2097,2106,2110,2111,2112,2115,2121,2122,2130,2131,2141,2157,2311,2251,2252,2263,2269,2270,2271,2272,2274,2275,2279,2280,2287,2300,2307,2312,2316,2330,2339,2720,2370,2372,2423,2439,2462,2494,2477,2478,2480,2483,2491,2492,2493,2537,2533,2534,2535,2536,2546,2550,2551,2573,2574,2575,2576,2587,2598,2658,2691,2710,2721,2763}'::jsonb[]))
Rows Removed by Filter: 2617642
-> Gather (cost=72793.94..290647.16 rows=246807 width=910) (actual time=1720.216..3369.512 rows=2617888 loops=1)
Workers Planned: 1
Workers Launched: 1
-> Result (cost=71793.94..264966.46 rows=4500611 width=910) (actual time=1706.592..2884.302 rows=1308944 loops=2)
-> ProjectSet (cost=71793.94..197457.29 rows=4500611 width=12) (actual time=1706.573..2654.189 rows=1308944 loops=2)
-> Parallel Hash Join (cost=71793.94..173865.38 rows=145181 width=132) (actual time=1706.560..2554.799 rows=42224 loops=2)
Hash Cond: (account_move_line_1.id = account_analytic_line.move_line_id)
-> Parallel Index Scan using account_move_line__journal_id_index on account_move_line account_move_line_1 (cost=0.43..100906.82 rows=149368 width=4) (actual time=2.633..788.321 rows=126675 loops=2)
Index Cond: (journal_id = ANY ('{23,21,17}'::integer[]))
-> Parallel Hash (cost=67363.05..67363.05 rows=354437 width=136) (actual time=1699.502..1699.503 rows=421304 loops=2)
Buckets: 1048576 Batches: 1 Memory Usage: 54880kB
-> Parallel Index Scan using account_analytic_line__date_index on account_analytic_line (cost=0.43..67363.05 rows=354437 width=136) (actual time=9.963..1507.693 rows=421304 loops=2)
Index Cond: ((date <= '2024-12-31'::date) AND (date >= '2024-01-01'::date))
Filter: ((general_account_id IS NOT NULL) AND (company_id = 3))
Rows Removed by Filter: 57954
-> Hash (cost=18.65..18.65 rows=29 width=4) (actual time=16.619..16.620 rows=29 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 10kB
-> Index Scan using account_account__account_type_index on account_account account_move_line__account_id (cost=0.15..18.65 rows=29 width=4) (actual time=16.513..16.592 rows=29 loops=1)
Index Cond: ((account_type)::text = 'income'::text)
Planning Time: 75.050 ms
JIT:
Functions: 51
Options: Inlining false, Optimization false, Expressions true, Deforming true
Timing: Generation 4.433 ms (Deform 2.707 ms), Inlining 0.000 ms, Optimization 2.501 ms, Emission 30.127 ms, Total 37.061 ms
Execution Time: 3496.425 ms
```
OPW-4782916