+1 Taher Vaibhav Jain Hotwax Systems, vaibhav.j...@hotwaxsystems.com
On Tue, Oct 3, 2017 at 1:09 PM, Deepak Dixit <deepak.di...@hotwaxsystems.com > wrote: > Looks good Taher. > > > On Sun, Oct 1, 2017 at 2:18 PM, Taher Alkhateeb < > slidingfilame...@gmail.com> > wrote: > > > So this is one area where I faced many problems in the past, with > > units generally and money specifically. You could be surprised how > > many times something like rounding and accuracy can end up being a > > _big_ problem in systems. > > > > I think to really achieve flexibility (which is one of the strong > > points of OFBiz) then we should have a general purpose accuracy > > system. We can perhaps implement it as follows: > > - Amount could be a free field with no restriction on accuracy (it > > goes as far as the environment provides) > > - Accuracy should be a parameter with a default value. However, the > > parameter should be customizable to each unit of measurement > > (currency) separately. So for example, you can set USD to 2, KWD to 3, > > etc ... > > > > > https://www.currency-iso.org/en/home/tables/table-a1.html > > > > Thanks & Regards > -- > Deepak Dixit > www.hotwaxsystems.com > www.hotwax.co > > > > > > > - Rounding method should be a parameter with a default value. Examples > > could be ROUND_UP, ROUND_DOWN, ROUND_NEAREST > > - Rounding time should be a parameter with a default value. Perhaps > > something like DURING_CALCULATION, AFTER_CALCULATION > > - Then we implement all basic calculations in services or utility > > methods that fully utilize the above parameters and settings. > > > > Sorry if I went overboard :) But I usually always lean towards root > > solutions that solve many problems at once. Not sure if any folks are > > interested but if you like the idea I'd be willing to help with it. > > > > On Wed, Sep 27, 2017 at 3:42 PM, Chinmay Patidar > > <chinmay.pati...@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* > > >
