Jacopo,
I agree this should be changed to restrict it to 2 decimal places.
Based on other conversations recently on the mailing list I would
also like to add a new field type to represent interim and more
accurate currency amounts. For this I'm thinking of 3 or perhaps 4
decimal places, but I'm interested in feedback on that... The main
uses of it I see are:
- the price on the ProductPrice entity to facilitate storage of more
generally applicable prices to get a certain post-tax calculation
result, and this would also be for post-other calculation (like price
rules) results
- the amount on the OrderAdjustment entity: this needs to be at least
3 decimal places for UK VAT line item calculations, and this may be
the case in other places; if there is any place that requires more
than 4 decimals for interim results that need to be persisted then we
need to do something about that... note that this isn't for in-memory
calculations, but for things that actually need to be persisted to
the database (in memory calculations are much easier to be flexible
with)
- any others?
-David
On Oct 7, 2005, at 12:28 AM, Jacopo Cappellato wrote:
> Hi all,
>
> I was fighting against some approximation issues with prices,
> running OFBiz on top of Derby db, and I've discovered that the db
> field type for currency-amount fields for Derby was set to FLOAT
> and not to NUMERIC(18,2). This is causing approx problems in OFBiz
> because the currency amounts are displayed formatted with two
> decimals in many screens and this causes obvious differences when
> calculating totals etc.
>
> Is this a bug or am I missing something?
>
> Thanks,
>
> Jacopo
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev>
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev