IDEMPIERE-5671: Fixing Line net amount has error due to rounding.

[dpansheriya]

Pull Request Checklist

• My code follows the code guidelines of this project
• My code follows the best practices of this project
• I have performed a self-review of my own code
• My code is easy to understand and review.
• I have checked my code and corrected any misspellings
• In hard-to-understand areas, I have commented my code.
• My changes generate no new warnings

Tests

• I have tested the direct scenario that my code is solving
• I checked all collaterals that can be affected by my changes, and tested other potential affected scenarios
• New and existing unit tests pass locally with my changes
• I have added unit tests that prove my fix is effective or that my feature works

Documentation

• I have made corresponding changes to the documentation as follows:
• • New feature (non-breaking change which adds functionality): I have created the New Feature page in the project wiki explaining the functionality and how to use it. If relevant, I have committed sample data to the core seed to have usable examples in GardenWorld.
• • Breaking change (fix or feature that would cause existing functionality to not work as expected): I have documented the change in a clear way that everyone in the community can understand the impact of the change.
• • Improvement (improves and existing functionality): This documentation is needed if the improvement changes the way the user interacts with the system or the outcome of a process/task changes. If it is just, for instance, a performance improvement, documentation might not be needed.
• The changed/added documentation is in the project wiki (not privately-hosted pdf files or links pointing to a company website) and is complete and self-explanatory.

[CarlosRuiz-globalqss]

Hi @dpansheriya - I tested this successfully.

However, I think it is wrong to round the price based on the UOM precision. The UOM precision is for quantities and is being used for rounding prices in several places.

Also, the prices can accept 12 decimal points when entered manually in the same product UOM, but the unit price is being rounded when there is a UOM conversion, I think both cases must accept the 12 decimals for consistency.

Can you please integrate the following patch:
pr1782PR.patch.txt

[dpansheriya]

Hi @dpansheriya - I tested this successfully.

However, I think it is wrong to round the price based on the UOM precision. The UOM precision is for quantities and is being used for rounding prices in several places.

Also, the prices can accept 12 decimal points when entered manually in the same product UOM, but the unit price is being rounded when there is a UOM conversion, I think both cases must accept the 12 decimals for consistency.

Can you please integrate the following patch: pr1782PR.patch.txt

Carlos, I think 12 decimal hard coding is not good. I think we should round priceActual to costing precision as that is what used for costing too. If 12 digits precision printed on reports, it may not be good. also some how it must be controlled based on countries

[CarlosRuiz-globalqss]

Carlos, I think 12 decimal hard coding is not good. I think we should round priceActual to costing precision as that is what used for costing too. If 12 digits precision printed on reports, it may not be good. also some how it must be controlled based on countries

@dpansheriya - the 12 decimal hard coding is already there when you enter a price manually, so, I'm not introducing something new, but making the price rounding consistent when manual vs UOM-converted.

If I remember correctly that was implemented to solve a big issue when doing multiple invoices for a single order.
When a sales order generates multiple invoices it creates rounding issues on every invoice generated when the price is rounded to very few decimals - with 12 decimals there can be still issues with very large quantities, but the error is minimized.

About your concern when printing, in invoices the printed price is the PriceEntered, and if for any reason you need to print the UOM-converted price, then I think is more accurate to print 12.8033 than 12.8

[dpansheriya]

Carlos, I think 12 decimal hard coding is not good. I think we should round priceActual to costing precision as that is what used for costing too. If 12 digits precision printed on reports, it may not be good. also some how it must be controlled based on countries

@dpansheriya - the 12 decimal hard coding is already there when you enter a price manually, so, I'm not introducing something new, but making the price rounding consistent when manual vs UOM-converted.

If I remember correctly that was implemented to solve a big issue when doing multiple invoices for a single order. When a sales order generates multiple invoices it creates rounding issues on every invoice generated when the price is rounded to very few decimals - with 12 decimals there can be still issues with very large quantities, but the error is minimized.

About your concern when printing, in invoices the printed price is the PriceEntered, and if for any reason you need to print the UOM-converted price, then I think is more accurate to print 12.8033 than 12.8
@CarlosRuiz-globalqss
Applied your patch.