default to always round up for order and invoice amounts?

[Leon Torres-2]

Hi folks,

Currently we use BigDecimal.ROUND_HALF_EVEN in
accounting/config/arithmetic.properties to round up or down with as much
precision as possible when dealing with invoice and order amounts.

But for production, we decided that we prefer to use ROUND_CEILING instead,

0.825 -> 0.83
0.821 -> 0.83
0.820 -> 0.82

The rationale is we don't want to underpay taxes due to tax figures being
rounded down.

Since we haven't yet made the InvoiceServices.java createInvoiceFromOrder
service sophisticated enough to use a different rounding mode and scale for each
adjustment type, we have to make all the rounding modes ROUND_CEILING for now.

So perhaps using ROUND_CEILING is a better default for all rounding modes in
arithmetic.properties for ofbiz?

- Leon

Open Source Strategies, Inc.

[Hans Bakker]

> 0.821 -> 0.83

you think is accepatable?


On Friday 30 June 2006 06:52, Leon Torres wrote:

> Hi folks,
>
> Currently we use BigDecimal.ROUND_HALF_EVEN in
> accounting/config/arithmetic.properties to round up or down with as much
> precision as possible when dealing with invoice and order amounts.
>
> But for production, we decided that we prefer to use ROUND_CEILING instead,
>
> 0.825 -> 0.83
> 0.821 -> 0.83
> 0.820 -> 0.82
>
> The rationale is we don't want to underpay taxes due to tax figures being
> rounded down.
>
> Since we haven't yet made the InvoiceServices.java createInvoiceFromOrder
> service sophisticated enough to use a different rounding mode and scale for
> each adjustment type, we have to make all the rounding modes ROUND_CEILING
> for now.
>
> So perhaps using ROUND_CEILING is a better default for all rounding modes
> in arithmetic.properties for ofbiz?
>
> - Leon
>
> Open Source Strategies, Inc.

--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

[BJ Freeman]

try and get that past an accountant.
if the invoice they get from a supplier does not match the invoiced
created by ofbiz. They are very unhappy.
you also have the problem of the math package that supports this to be
different for diffent OS's and CPU's.


Leon Torres sent the following on 6/29/2006 4:52 PM:

> Hi folks,
>
> Currently we use BigDecimal.ROUND_HALF_EVEN in
> accounting/config/arithmetic.properties to round up or down with as much
> precision as possible when dealing with invoice and order amounts.
>
> But for production, we decided that we prefer to use ROUND_CEILING instead,
>
> 0.825 -> 0.83
> 0.821 -> 0.83
> 0.820 -> 0.82
>
> The rationale is we don't want to underpay taxes due to tax figures
> being rounded down.
>
> Since we haven't yet made the InvoiceServices.java
> createInvoiceFromOrder service sophisticated enough to use a different
> rounding mode and scale for each adjustment type, we have to make all
> the rounding modes ROUND_CEILING for now.
>
> So perhaps using ROUND_CEILING is a better default for all rounding
> modes in arithmetic.properties for ofbiz?
>
> - Leon
>
> Open Source Strategies, Inc.
>

[Leon Torres-2]

Hans Bakker wrote:
 >> 0.821 -> 0.83
 >
 > you think is accepatable?
 >

For taxes yes. See rationale in my first post.

- Leon

[Jacques Le Roux]

In France for taxes we round to the floor. But only with totals..

Jacques

From: "Leon Torres" <[hidden email]>


> Hans Bakker wrote:
>  >> 0.821 -> 0.83
>  >
>  > you think is accepatable?
>  >
>
> For taxes yes. See rationale in my first post.
>
> - Leon

[Andrew Sykes]

Leon,

UK would round this down.

On Thu, 2006-06-29 at 17:29 -0700, Leon Torres wrote:
> Hans Bakker wrote:
>  >> 0.821 -> 0.83
>  >
>  > you think is accepatable?
>  >
>
> For taxes yes. See rationale in my first post.
>
> - Leon
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Si Chen-2]

Wow,

So it looks like everybody does this differently.  Well, in that case  
we'll leave this as is, but make sure you study arithmetic.properties  
file, understand what the different rounding modes mean, and use the  
right one.

Si


On Jun 30, 2006, at 1:42 AM, Andrew Sykes wrote:

> Leon,
>
> UK would round this down.
>
> On Thu, 2006-06-29 at 17:29 -0700, Leon Torres wrote:
>> Hans Bakker wrote:
>>>> 0.821 -> 0.83
>>>
>>> you think is accepatable?
>>>
>>
>> For taxes yes. See rationale in my first post.
>>
>> - Leon
> --
> Kind Regards
> Andrew Sykes <[hidden email]>
> Sykes Development Ltd
> http://www.sykesdevelopment.com

[Andrew Sykes]

Si,

Could we somehow allocate a rounding mode to a Geo?

- Andrew

On Fri, 2006-06-30 at 10:40 -0700, Si Chen wrote:

> Wow,
>
> So it looks like everybody does this differently.  Well, in that case  
> we'll leave this as is, but make sure you study arithmetic.properties  
> file, understand what the different rounding modes mean, and use the  
> right one.
>
> Si
>
>
> On Jun 30, 2006, at 1:42 AM, Andrew Sykes wrote:
>
> > Leon,
> >
> > UK would round this down.
> >
> > On Thu, 2006-06-29 at 17:29 -0700, Leon Torres wrote:
> >> Hans Bakker wrote:
> >>>> 0.821 -> 0.83
> >>>
> >>> you think is accepatable?
> >>>
> >>
> >> For taxes yes. See rationale in my first post.
> >>
> >> - Leon
> > --
> > Kind Regards
> > Andrew Sykes <[hidden email]>
> > Sykes Development Ltd
> > http://www.sykesdevelopment.com
>

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Leon Torres-2]

As a follow up, we advise using any of the floor or ceiling rounding modes
because GenericValue.getBigDecimal() doesn't return exact numbers.  If the
database value is 9.9, it will return 9.9000000000000003552713678.  Using
ROUND_CEILING on this produces 9.91. That's bad!

The whole cause of this thread was behavior of ROUND_HALF_EVEN that goes against
what most of us are trained to think when it comes to rounding.  For instance,
I'm trained to think that 0.825 must be rounded to 0.83.  But when using
ROUND_HALF_EVEN, I was seeing 0.82 instead.  So this made me think that
ROUND_HALF_EVEN was doing the wrong thing.

But this turns out that my ingrained thinking is incorrect.  If the last digit
is 5, which is equidistant from the next higher and lower rounded numbers, then
it should be rounded up half the time and down half the time.  Hence, the most
precise way to round is to use a technique like ROUND_HALF_CEILING.

However since I highly doubt this is common knowledge, especially among
customers and users, I think we should move to ROUND_HALF_UP instead, which
rounds 0.825 to 0.83 as is commonly accepted.  Even if it's imprecise, it's what
society expects.

What do you think?

If you want a primer on how BigDecimal works and all these rounding modes and
issues, here's an article I wrote,

http://www.opensourcestrategies.com/ofbiz/ofbiz_bigdecimal_cookbook.txt

- Leon



Si Chen wrote:
> Wow,
>
> So it looks like everybody does this differently.  Well, in that case
> we'll leave this as is, but make sure you study arithmetic.properties
> file, understand what the different rounding modes mean, and use the
> right one.
>
> Si

[David E. Jones]

For tax purposes it would make sense to associate it with the TaxAuthority...

-David


Andrew Sykes wrote:

> Si,
>
> Could we somehow allocate a rounding mode to a Geo?
>
> - Andrew
>
> On Fri, 2006-06-30 at 10:40 -0700, Si Chen wrote:
>> Wow,
>>
>> So it looks like everybody does this differently.  Well, in that case  
>> we'll leave this as is, but make sure you study arithmetic.properties  
>> file, understand what the different rounding modes mean, and use the  
>> right one.
>>
>> Si
>>
>>
>> On Jun 30, 2006, at 1:42 AM, Andrew Sykes wrote:
>>
>>> Leon,
>>>
>>> UK would round this down.
>>>
>>> On Thu, 2006-06-29 at 17:29 -0700, Leon Torres wrote:
>>>> Hans Bakker wrote:
>>>>>> 0.821 -> 0.83
>>>>> you think is accepatable?
>>>>>
>>>> For taxes yes. See rationale in my first post.
>>>>
>>>> - Leon
>>> --
>>> Kind Regards
>>> Andrew Sykes <[hidden email]>
>>> Sykes Development Ltd
>>> http://www.sykesdevelopment.com

[Andrew Sykes]

David,

Er, yes, that's what I meant - Geo indeed!

Sorry about that.

- Andrew

On Fri, 2006-06-30 at 13:14 -0600, David E. Jones wrote:

> For tax purposes it would make sense to associate it with the TaxAuthority...
>
> -David
>
>
> Andrew Sykes wrote:
> > Si,
> >
> > Could we somehow allocate a rounding mode to a Geo?
> >
> > - Andrew
> >
> > On Fri, 2006-06-30 at 10:40 -0700, Si Chen wrote:
> >> Wow,
> >>
> >> So it looks like everybody does this differently.  Well, in that case  
> >> we'll leave this as is, but make sure you study arithmetic.properties  
> >> file, understand what the different rounding modes mean, and use the  
> >> right one.
> >>
> >> Si
> >>
> >>
> >> On Jun 30, 2006, at 1:42 AM, Andrew Sykes wrote:
> >>
> >>> Leon,
> >>>
> >>> UK would round this down.
> >>>
> >>> On Thu, 2006-06-29 at 17:29 -0700, Leon Torres wrote:
> >>>> Hans Bakker wrote:
> >>>>>> 0.821 -> 0.83
> >>>>> you think is accepatable?
> >>>>>
> >>>> For taxes yes. See rationale in my first post.
> >>>>
> >>>> - Leon
> >>> --
> >>> Kind Regards
> >>> Andrew Sykes <[hidden email]>
> >>> Sykes Development Ltd
> >>> http://www.sykesdevelopment.com

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Adrian Crum]

Why not round it in code?

Leon Torres wrote:

> As a follow up, we advise using any of the floor or ceiling rounding
> modes because GenericValue.getBigDecimal() doesn't return exact
> numbers.  If the database value is 9.9, it will return
> 9.9000000000000003552713678.  Using ROUND_CEILING on this produces 9.91.
> That's bad!
>
> The whole cause of this thread was behavior of ROUND_HALF_EVEN that goes
> against what most of us are trained to think when it comes to rounding.  
> For instance, I'm trained to think that 0.825 must be rounded to 0.83.  
> But when using ROUND_HALF_EVEN, I was seeing 0.82 instead.  So this made
> me think that ROUND_HALF_EVEN was doing the wrong thing.
>
> But this turns out that my ingrained thinking is incorrect.  If the last
> digit is 5, which is equidistant from the next higher and lower rounded
> numbers, then it should be rounded up half the time and down half the
> time.  Hence, the most precise way to round is to use a technique like
> ROUND_HALF_CEILING.
>
> However since I highly doubt this is common knowledge, especially among
> customers and users, I think we should move to ROUND_HALF_UP instead,
> which rounds 0.825 to 0.83 as is commonly accepted.  Even if it's
> imprecise, it's what society expects.
>
> What do you think?
>
> If you want a primer on how BigDecimal works and all these rounding
> modes and issues, here's an article I wrote,
>
> http://www.opensourcestrategies.com/ofbiz/ofbiz_bigdecimal_cookbook.txt
>
> - Leon
>
>
>
> Si Chen wrote:
>
>> Wow,
>>
>> So it looks like everybody does this differently.  Well, in that case
>> we'll leave this as is, but make sure you study arithmetic.properties
>> file, understand what the different rounding modes mean, and use the
>> right one.
>>
>> Si
>
>