You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by pe...@ec4b.com on 2007/04/12 02:55:58 UTC
RE: Inaccurate Calculation of Order (arithmetic.properties > Rounding Parameter Options)
Hi,
Still having trouble setting the 'arithmetic.properties' file to give the
correct figures.
What are the permitted 'rounding parameters'?
ROUND_HALF_UP
or...
#
# Arithmetic properties for configuring BigDecimal calculations
#
# For setting decimal precision and rounding method of operations related to
invoices
invoice.decimals = 2
invoice.rounding = ROUND_HALF_UP
# For setting decimal precision and rounding method of operations related to
orders,
# such as shopping cart amounts and order amounts
order.decimals = 2
order.rounding = ROUND_HALF_UP
# For setting decimal precision and rounding method of operations related to
customer accounts
# such as Financial Accounts
finaccount.decimals = 2
finaccount.rounding = ROUND_HALF_UP
# Most companies would want their sales tax calculations ALWAYS to round up
(ie, 100.081 becomes 100.09)
# This could be ROUND_CEILING or ROUND_UP. (The difference is that
ROUND_CEILING rounds towards positive infinity,
# ROUND_UP away from zero. So, for 1.13, both ROUND_UP and ROUND_CEILING
will round to 1.2, but for -1.13,
# ROUND_UP gives you -1.2 and ROUND_CEILING -1.1.)
salestax.calc.decimals = 2
salestax.final.decimals = 2
salestax.rounding = ROUND_HALF_UP
Thanks & Regards,
Peter
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of David Shere
Sent: 05 April 2007 14:45
To: user@ofbiz.apache.org
Subject: Re: Inaccurate Calculation of Order
This assessment appears to confirm that OFBiz does the rounding this
way: Rounding line items to three digits, then rounding each line item
result to two digits, then add them up.
This is different than what David says is the VAT practice of rounding
line items to three digits, adding them up, and rounding the result to
two digits.
The arithemetic.properties file does not appear to have settings to
control this specific aspect of the rounding behavior.
Chris Howe wrote:
> The only way I can get 13.57 tax is to round to three digits, then
> round to 2 digits for each line then add them up.
> 1. 6.2545 (real) -> 6.255 -> 6.26
> 2. 6.2545 (real) -> 6.255 -> 6.26
> 3. 1.05 (real) -> 1.05 -> 1.05
> 13.559 (real)...13.56....13.57
>
> --- Scott Gray <le...@gmail.com> wrote:
>
>> The only way I can get 13.57 tax is to round the tax for each line
>> item up
>> to 2 decimals before totaling.
>>
>> I think I've send some rounding rules in a config file somewhere but
>> I'm not
>> sure on that.
>>
>> On 05/04/07, Adrian Crum <ad...@hlmksw.com> wrote:
>>> David,
>>>
>>> I just calculated the tax on each line item accurate to 9 decimals,
>> summed
>>> the
>>> taxes, and I still get a total tax of $13.559.
>>>
>>>
>>> David E. Jones wrote:
>>>
>>>> Ummmm.... need more details. There are variations in rounding
>> modes,
>>>> precision rules etc.
>>>>
>>>> For example with VAT in pretty much ALL countries that use VAT
>> you must
>>>> calculate line item tax amounts with 3 digits of precision, add
>> them
>>>> up, then round to 2 digits.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Apr 4, 2007, at 5:50 PM, <pe...@ec4b.com> wrote:
>>>>
>>>>>
>>>>> Hi David,
>>>>>
>>>>>
>>>>> Thanks for responding.
>>>>>
>>>>> An excel spreadsheet that our account had verified.
>>>>>
>>>>>
>>>>> Thanks & Regards,
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: David E. Jones [mailto:jonesde@hotwaxmedia.com]
>>>>> Sent: 04 April 2007 22:39
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: Re: Inaccurate Calculation of Order
>>>>> Importance: High
>>>>>
>>>>>
>>>>> What do you mean by "traditional means" here?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Apr 4, 2007, at 5:15 PM, <pe...@ec4b.com> <pe...@ec4b.com>
>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> Has anyone run into the problem of having Purchases not
>> calculated
>>>>>> accurately?
>>>>>>
>>>>>>
>>>>>> These are the figures calculated by traditional means;
>>>>>> Product 1: 35.74
>>>>>> Product 2: 35.74
>>>>>> Shipping : 6.00
>>>>>> Total : 77.48
>>>>>> Tax : 13.56
>>>>>> -----------------
>>>>>> Total : 91.04
>>>>>>
>>>>>> These are the figures calculated by Ofbiz Order Manager;
>>>>>> Product 1: 35.74
>>>>>> Product 2: 35.74
>>>>>> Shipping : 6.00
>>>>>> Total : 77.48
>>>>>> Tax : 13.57
>>>>>> -----------------
>>>>>> Total : 91.05
>>>>>>
>>>>>>
>>>>>> There is a very slight difference of 1c. But the fact of the
>> matter
>>>>>> is that
>>>>>> the figure calculated by the system is very slightly incorrect.
>>>>>> Struck me
>>>>>> that the Tax maybe being calculated to 3 digits rather than 2
>> digits.
>>>>>> Does anyone know which file(s) control the calculation of the
>> Tax,
>>>>>> so I can
>>>>>> check if it is 2 or 3 digits.
>>>>>>
>>>>>>
>>>>>> Would appreciated any feedback.
>>>>>>
>>>>>>
>>>>>> Thanks & Regards,
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>
>
>
--
David Shere
Information Technology Services
Steele Rubber Products
www.SteeleRubber.com
Re: Inaccurate Calculation of Order (arithmetic.properties > Rounding Parameter Options)
Posted by Scott Gray <le...@gmail.com>.
Hi Peter
You can use any of the rounding modes that BigDecimal uses
http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigDecimal.html
Regards
Scott
On 12/04/07, peter@ec4b.com <pe...@ec4b.com> wrote:
>
> Hi,
>
>
> Still having trouble setting the 'arithmetic.properties' file to give the
> correct figures.
>
> What are the permitted 'rounding parameters'?
> ROUND_HALF_UP
> or...
>
>
> #
> # Arithmetic properties for configuring BigDecimal calculations
> #
>
> # For setting decimal precision and rounding method of operations related
> to
> invoices
> invoice.decimals = 2
> invoice.rounding = ROUND_HALF_UP
>
> # For setting decimal precision and rounding method of operations related
> to
> orders,
> # such as shopping cart amounts and order amounts
> order.decimals = 2
> order.rounding = ROUND_HALF_UP
>
> # For setting decimal precision and rounding method of operations related
> to
> customer accounts
> # such as Financial Accounts
> finaccount.decimals = 2
> finaccount.rounding = ROUND_HALF_UP
>
> # Most companies would want their sales tax calculations ALWAYS to round
> up
> (ie, 100.081 becomes 100.09)
> # This could be ROUND_CEILING or ROUND_UP. (The difference is that
> ROUND_CEILING rounds towards positive infinity,
> # ROUND_UP away from zero. So, for 1.13, both ROUND_UP and ROUND_CEILING
> will round to 1.2, but for -1.13,
> # ROUND_UP gives you -1.2 and ROUND_CEILING -1.1.)
> salestax.calc.decimals = 2
> salestax.final.decimals = 2
> salestax.rounding = ROUND_HALF_UP
>
>
> Thanks & Regards,
>
> Peter
>
>
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of David Shere
> Sent: 05 April 2007 14:45
> To: user@ofbiz.apache.org
> Subject: Re: Inaccurate Calculation of Order
>
> This assessment appears to confirm that OFBiz does the rounding this
> way: Rounding line items to three digits, then rounding each line item
> result to two digits, then add them up.
>
> This is different than what David says is the VAT practice of rounding
> line items to three digits, adding them up, and rounding the result to
> two digits.
>
> The arithemetic.properties file does not appear to have settings to
> control this specific aspect of the rounding behavior.
>
> Chris Howe wrote:
> > The only way I can get 13.57 tax is to round to three digits, then
> > round to 2 digits for each line then add them up.
> > 1. 6.2545 (real) -> 6.255 -> 6.26
> > 2. 6.2545 (real) -> 6.255 -> 6.26
> > 3. 1.05 (real) -> 1.05 -> 1.05
> > 13.559 (real)...13.56....13.57
> >
> > --- Scott Gray <le...@gmail.com> wrote:
> >
> >> The only way I can get 13.57 tax is to round the tax for each line
> >> item up
> >> to 2 decimals before totaling.
> >>
> >> I think I've send some rounding rules in a config file somewhere but
> >> I'm not
> >> sure on that.
> >>
> >> On 05/04/07, Adrian Crum <ad...@hlmksw.com> wrote:
> >>> David,
> >>>
> >>> I just calculated the tax on each line item accurate to 9 decimals,
> >> summed
> >>> the
> >>> taxes, and I still get a total tax of $13.559.
> >>>
> >>>
> >>> David E. Jones wrote:
> >>>
> >>>> Ummmm.... need more details. There are variations in rounding
> >> modes,
> >>>> precision rules etc.
> >>>>
> >>>> For example with VAT in pretty much ALL countries that use VAT
> >> you must
> >>>> calculate line item tax amounts with 3 digits of precision, add
> >> them
> >>>> up, then round to 2 digits.
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>> On Apr 4, 2007, at 5:50 PM, <pe...@ec4b.com> wrote:
> >>>>
> >>>>>
> >>>>> Hi David,
> >>>>>
> >>>>>
> >>>>> Thanks for responding.
> >>>>>
> >>>>> An excel spreadsheet that our account had verified.
> >>>>>
> >>>>>
> >>>>> Thanks & Regards,
> >>>>>
> >>>>> Peter
> >>>>>
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: David E. Jones [mailto:jonesde@hotwaxmedia.com]
> >>>>> Sent: 04 April 2007 22:39
> >>>>> To: user@ofbiz.apache.org
> >>>>> Subject: Re: Inaccurate Calculation of Order
> >>>>> Importance: High
> >>>>>
> >>>>>
> >>>>> What do you mean by "traditional means" here?
> >>>>>
> >>>>> -David
> >>>>>
> >>>>>
> >>>>> On Apr 4, 2007, at 5:15 PM, <pe...@ec4b.com> <pe...@ec4b.com>
> >> wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>>
> >>>>>> Has anyone run into the problem of having Purchases not
> >> calculated
> >>>>>> accurately?
> >>>>>>
> >>>>>>
> >>>>>> These are the figures calculated by traditional means;
> >>>>>> Product 1: 35.74
> >>>>>> Product 2: 35.74
> >>>>>> Shipping : 6.00
> >>>>>> Total : 77.48
> >>>>>> Tax : 13.56
> >>>>>> -----------------
> >>>>>> Total : 91.04
> >>>>>>
> >>>>>> These are the figures calculated by Ofbiz Order Manager;
> >>>>>> Product 1: 35.74
> >>>>>> Product 2: 35.74
> >>>>>> Shipping : 6.00
> >>>>>> Total : 77.48
> >>>>>> Tax : 13.57
> >>>>>> -----------------
> >>>>>> Total : 91.05
> >>>>>>
> >>>>>>
> >>>>>> There is a very slight difference of 1c. But the fact of the
> >> matter
> >>>>>> is that
> >>>>>> the figure calculated by the system is very slightly incorrect.
> >>>>>> Struck me
> >>>>>> that the Tax maybe being calculated to 3 digits rather than 2
> >> digits.
> >>>>>> Does anyone know which file(s) control the calculation of the
> >> Tax,
> >>>>>> so I can
> >>>>>> check if it is 2 or 3 digits.
> >>>>>>
> >>>>>>
> >>>>>> Would appreciated any feedback.
> >>>>>>
> >>>>>>
> >>>>>> Thanks & Regards,
> >>>>>>
> >>>>>> Peter
> >>>>>>
> >>>>>>
> >>>>>
> >
> >
>
> --
> David Shere
> Information Technology Services
> Steele Rubber Products
> www.SteeleRubber.com
>
>