Thanks Chinmay, Aishwary,
There are 2 aspects:
1. the underneath calculations where IMO we should use as mush as possible
decimals.
To be pragmatic I think in DB 6 is enough. This number was used in Europe
when converting from all other currencies to Euro, with a not so bad
result. We could use more for cryptocurrencies if needed
2. And then showing result in UI, where most of the time 2 decimals are enough,
but you can set the number of decimals you want using properties
(from the top of my head)
Now about currency-precise vs currency-amount, you can start with http://markmail.org/message/sv7kcso4su7qguxe and go ahead with new improvements,
after discussing it here please.
HTH
Jacques
Le 27/09/2017 à 15:48, Aishwary Shrivastava a écrit :
+1 Chinmay Patidar,
As it will be good for users who want to use Bitcoins as a mode of Payments.
On Wed, Sep 27, 2017 at 6:12 PM, Chinmay Patidar <
[email protected]> wrote:
Hello Devs,
Ofbiz places a restriction on saving more than 3 decimal places in price
related entity-fields. But there can be a number of use cases where a user
needs to store more than 2 or 3 decimal places in the currency related
entity-fields.
I even saw some discussions related to this but didn't found any
conclusions from them. Even one issue
<https://issues.apache.org/jira/browse/OFBIZ-494> has been created but for
limited fields. So, I would like to propose support for multiple or more
than 2/3 decimals in price related fields.
Following are some findings related to the currency fields which would be
helpful to examine the requirement:
Ofbiz uses two field types to store the currency related entity-fields.
These two types are 'currency-amount' and 'currency-precise' with their
respective types being NUMBER(18,2) and NUMBER(18,3).
Upon initial research, one can conclude that changing the field definitions
of 'currency-amount' and 'currency-precise' would achieve the requirement.
But doing so will raise following questions which need to be answered. Feel
free to add in them.
- What would be the precise value of precision(number of decimals)?
- Will these changes can make the system inconsistent?
In addition, I would like to know the significance of having two separate
field types, i.e. 'currency-amount' and 'currency-precise'.
Also, I have marked one improvement which will be needed to realize the
solution. There are multiple occurrences where hardcoded scaling of 2 has
been set to either display or store a currency field. This needs to be
changed and must be set dynamically.
I'd like to hear your thoughts.
Thanks,
*Chinmay Patidar*
