Jacopo, (and others interested in tax calc and stuff too),
I don't know why it was set that way, it REALLY should be restricted
to 2 decimal places, so I have changed that now (rev 5929). Of course
for existing databases the type on that column will have to be
changed manually.
I also added a new entity field type called "currency-precise" that
has 3 decimal places instead of 2. I was considering 4 places instead
of 3, but hopefully 3 will be sufficient and for control purposes the
less the better. This is now used for the ProductPrice.price and
OrderAdjustment.amount fields. Those are the two main ones we need
now that I can think of, though we may add more later on.
To use this with OrderAdjustment is going to be fun for the UK style
VAT calculation because they will all need to be added with 3 decimal
digits, and then the total rounded to 2, and then an invoice line
created for the whole order instead of each line in order for
everything to add up properly... Maybe I should rethink that and just
always have the OrderAdjustment be 2 decimal digits and just do the
calculation in memory... Would avoid possibly messing up the invoice
and such... What a PITA, I don't know....
-David
On Oct 7, 2005, at 12:18 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