Monday, December 9, 2024
2 changes · 17.0
Enhancements to existing features
This update significantly improves the speed of generating the Profit & Loss report, especially when using multiple analytic filters. The change streamlines the report generation process by avoiding unnecessary table creation, resulting in faster loading times for larger datasets. This enhances user experience and efficiency.
Original PR description
When loading the Profit and Loss report with multiple analytic filters, loading times can be very slow on larger databases. Analytic filtering necessitates the creation of a temporary table which is…
When loading the Profit and Loss report with multiple analytic filters, loading times can be very slow on larger databases. Analytic filtering necessitates the creation of a temporary table which is used to merge the account_move_line and account_analytic_line tables. This process takes an enormous amount of time on large databases and is unnecessary. Since this table is created whenever the analytic filters are changed (it is dropped on commit), it is much faster to only copy the relevant lines into the new table. This PR adds logic to identify the relevant analytic accounts for the given query, and changes the table-making query to only copy lines with the relevant analytic accounts attached to them. Performance Benchmarks Pre: | 100,000 lines | 250,000 lines| 500,000 lines| |--------|--------|--------| | 5.2s | 10.77s | 110s | | 4.86s | 11.43s | 110s | | 5.16s | 12.2s | 115s | Performance Benchmarks Post: | 100,000 lines | 250,000 lines | 500,000 lines | |--------|--------|--------| | 1.56s | 3.19s | 6.22s | | 2.65s | 6.03s | 11.58s | | 3.74s | 8.36s | 16.36s | OPW-4300365
Resolved issues and error corrections
This update fixes an issue where the precision of product prices on Ecuadorian customer invoices was incorrectly rounded, particularly when discounts were applied. The change ensures that all price calculations and the resulting XML invoices accurately reflect the specified decimal accuracy (4 digits) as set in the Odoo configuration, improving reporting accuracy for Ecuadorian clients.
Original PR description
### Steps to reproduce: - Activate developer mode - Install the 'l10n_ec' module and switch to an Ecuadorian company - In Settings > Technical > Database Structure > Decimal Accuracy change the…
### Steps to reproduce: - Activate developer mode - Install the 'l10n_ec' module and switch to an Ecuadorian company - In Settings > Technical > Database Structure > Decimal Accuracy change the number of decimals for "Product Price" to 4 for example - In Accounting, create a new Customer Invoice - Select 'Instituto Ecuatoriano' as Customer - Add a line with a price with 4 decimals - Select 'Sin utilization del sistema financiero' as Payment Method - Confirm - On the blue popup at the top of the page, click 'process now' to get the XML in the chatter - In the XML the "precioUnitario" field only has 2 precision digits, it has been rounded - When adding a discount of 100% this field has all precision digits needed ### Cause: The price_unit is calculated differently if the discount is 100%. The "precioUnitario" field should always have the number of precision digits specified in the settings. ### Solution: We need to find the unit price without the discount, but without the included. This value is not computed. As the values computed in the account.move.line are already rounded based on the currency (2 digits) we need to recompute the values using `compute_all` and multiplying by the `price_digits` to not round in `compute_all`. The way the rounding is made here is by taking the decimal precision from the settings and making it a power of 10 in `price_digits` (4 decimals results in price_digits = 10000). Then we compute the taxes with `price_unit * price_digits`. As, per definition, `price_unit` has the number of digits used in the calculation of `price_digits`, we end up with an integer. But after the results of `compute_all` may no longer be an integer. We need an integer to keep the decimal precision. This is why, in the result, there is a call to `round()`. The call to `float_round()` is to make sure there are not more decimals than 6. This is needed as the number displayed in the XML will always be of 6 decimals, so if the client set a number of decimals greater than 6, it will be rounded in the XML but not on the invoice. To ensure that both values are the same, we round the value here. Some tests had "precioUnitario" with strange values that did not match the actual price_unit. It was because the precedent way to calculate this field was not perfect, I guess. opw-4120341 Forward-Port-Of: odoo/enterprise#68555