You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by "skip@thedevers" <sk...@thedevers.org> on 2008/04/22 02:23:38 UTC
Rounding Errors
I am importing orders (and writing them from scratch) with item costs at
three decimal digits. I have changed order.decimals to 3.
However, I end up with amounts like .466 truncated to .46
I looked at OrderItem and OrderItemBilling definitions and amount is a
currency-amount which is defined as NUMERIC(18,2)
I am wondering what is the best way to solve this problem. I am thinking of
changing the schema for OrderItem and OrderItemBilling to be floating-point.
I could also change the fieldtypepostgres.xml to be NUMERIC(18,3). However,
I only want the sold item prices to be three decimal digits, and not the
totals and so forth.
Anyone have any advice?
Skip
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date: 4/16/2008
9:34 AM
RE: Rounding Errors
Posted by "skip@thedevers" <sk...@thedevers.org>.
Scott
Yes, it would. What I was wondering however was whether it was best to
change the definition of both currency-precise (to NUMERIC(18,4) and
currency-amount (to NUMERIC(18,3)), or instead, modify each of the data
definitions for OrderItem, OrderItemBilling, and InventoryItem individually
and change the affected fields (amount and such) to be currency-precise.
I tried the former (changing the currency-amount definition) and it seems to
work ok. I will then however have to redo a complete alpha test to be sure
nothing unexpected happens. On the bright side, BigDecimal rounding does
not seem to be an issue.
On the other hand, I am worried that I might miss a data definition that
won't show up until a beta test with the customer next week.
Skip
-----Original Message-----
From: Scott Gray [mailto:lektran@gmail.com]
Sent: Monday, April 21, 2008 5:51 PM
To: user@ofbiz.apache.org
Subject: Re: Rounding Errors
currency-precise should solve the problem
Regards
Scott
On 22/04/2008, BJ Freeman <bj...@free-man.net> wrote:
>
> there has been discussion about this.
> the consensus as I remember it was leave rounding to the last.
> this mean mapping flow to find the final end point where this is going
> to be rounded.
> This I would think would be in the Accounting module. so the GL will
> balance.
>
>
> skip@thedevers sent the following on 4/21/2008 5:23 PM:
>
> > I am importing orders (and writing them from scratch) with item costs at
> > three decimal digits. I have changed order.decimals to 3.
> >
> > However, I end up with amounts like .466 truncated to .46
> >
> > I looked at OrderItem and OrderItemBilling definitions and amount is a
> > currency-amount which is defined as NUMERIC(18,2)
> >
> > I am wondering what is the best way to solve this problem. I am
> thinking of
> > changing the schema for OrderItem and OrderItemBilling to be
> floating-point.
> > I could also change the fieldtypepostgres.xml to be
> NUMERIC(18,3). However,
> > I only want the sold item prices to be three decimal digits, and not the
> > totals and so forth.
> >
> > Anyone have any advice?
> >
> > Skip
> > No virus found in this outgoing message.
> > Checked by AVG.
> > Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date:
> 4/16/2008
> > 9:34 AM
> >
> >
> >
> >
>
>
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date: 4/16/2008
9:34 AM
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date: 4/16/2008
9:34 AM
Re: Rounding Errors
Posted by Scott Gray <le...@gmail.com>.
currency-precise should solve the problem
Regards
Scott
On 22/04/2008, BJ Freeman <bj...@free-man.net> wrote:
>
> there has been discussion about this.
> the consensus as I remember it was leave rounding to the last.
> this mean mapping flow to find the final end point where this is going
> to be rounded.
> This I would think would be in the Accounting module. so the GL will
> balance.
>
>
> skip@thedevers sent the following on 4/21/2008 5:23 PM:
>
> > I am importing orders (and writing them from scratch) with item costs at
> > three decimal digits. I have changed order.decimals to 3.
> >
> > However, I end up with amounts like .466 truncated to .46
> >
> > I looked at OrderItem and OrderItemBilling definitions and amount is a
> > currency-amount which is defined as NUMERIC(18,2)
> >
> > I am wondering what is the best way to solve this problem. I am
> thinking of
> > changing the schema for OrderItem and OrderItemBilling to be
> floating-point.
> > I could also change the fieldtypepostgres.xml to be
> NUMERIC(18,3). However,
> > I only want the sold item prices to be three decimal digits, and not the
> > totals and so forth.
> >
> > Anyone have any advice?
> >
> > Skip
> > No virus found in this outgoing message.
> > Checked by AVG.
> > Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date:
> 4/16/2008
> > 9:34 AM
> >
> >
> >
> >
>
>
Re: Rounding Errors
Posted by BJ Freeman <bj...@free-man.net>.
there has been discussion about this.
the consensus as I remember it was leave rounding to the last.
this mean mapping flow to find the final end point where this is going
to be rounded.
This I would think would be in the Accounting module. so the GL will
balance.
skip@thedevers sent the following on 4/21/2008 5:23 PM:
> I am importing orders (and writing them from scratch) with item costs at
> three decimal digits. I have changed order.decimals to 3.
>
> However, I end up with amounts like .466 truncated to .46
>
> I looked at OrderItem and OrderItemBilling definitions and amount is a
> currency-amount which is defined as NUMERIC(18,2)
>
> I am wondering what is the best way to solve this problem. I am thinking of
> changing the schema for OrderItem and OrderItemBilling to be floating-point.
> I could also change the fieldtypepostgres.xml to be NUMERIC(18,3). However,
> I only want the sold item prices to be three decimal digits, and not the
> totals and so forth.
>
> Anyone have any advice?
>
> Skip
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date: 4/16/2008
> 9:34 AM
>
>
>
>