Re: [Proposal] Support for more decimals in price fields

[Jacques Le Roux <ja...@les7arts.com>]

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 <
> chinmay.patidar@hotwaxsystems.com> 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*
>>
>
>