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/16 18:56:47 UTC
The Return of...Inaccurate Calculation of Order
Hi,
Sure hope you can help with this, I have been going around in circles.
I am having a problem with the way that Ofbiz calculates tax and order
totals.
>From what I can gather, the file
/applications/accounting/config/arithmetic.properties controls the
rounding and digit length for the calculation of taxes & order totals.
I am starting to think the changes I make to the file are not being applied,
I say this because when I look at the Unit Price in an order it shows
35.742, rather than 35.74. Which would tend to indicate that settings are
not being used because the number of decimal points in each of the settings
in arithmetic.properties are set to 2 digits. I have pasted in the
contents of the arithmetic.properties file below so you can have a look. I
have changed the rounding to a different method to try to achieve the
correct figures.
There is only a disparity of +0.1 but, technically it is wrong. Ofbiz keeps
giving me a total of 91.05, but it should be 91.04. I am been given a hard
time about it...
Essentially;
Using Excel;
US$ tax p+tax
Product1 35.74 6.2545 41.995
Product2 35.74 6.2545 41.995
Shipping 6.00 1.050 7.050
Total 77.48 (3 digit)
Tax 13.56 13.559
------------------------
Grand Total 91.04 91.039
Simply put, I think that the problem is a combination of two issues;
(i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2 digits).
and
(ii). Uses rounding ROUND_HALF_UP, I would tend to use ROUND_HALF_DOWN.
I think the arithmetic.properties file below, should do the trick. But it
doesnt seem to being applied to the calculation.
So I have two Questions;
1). (BIGGEST ISSUE) Do I have to activate the arithmetic.properties
file, and if so how do I do that? (All I have been doing is clearing the
cache and logging out then logging in again, as I had been told this is the
way to do it).
2). Do you see my point about 94.05 and 94.04, and the best way to make this
calculation?
---CONTENTS OF---
.../Ofbiz/trunk/applications/accounting/config/arithmetic.properties
#
# 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_DOWN
# 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_DOWN
# For setting decimal precision and rounding method of operations related to
customer accounts
# such as Financial Accounts
finaccount.decimals = 2
finaccount.rounding = ROUND_HALF_DOWN
# 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_DOWN
Thanks & Regards,
Peter
________________________________________
On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
Hi Scott,
Just strikes me that the file should be 'correct' for everyone. What would
be your guidance as to what the file should be?
Appreciate your fast responses this evening. It is 1:15am here in the UK
just can't stay awake any more.
Thanks & Regards,
Peter
________________________________________
From: Scott Gray [mailto: lektran@gmail.com]
Sent: 05 April 2007 01:16
To: user@ofbiz.apache.org; peter@ec4b.com
Subject: Re: Inaccurate Calculation of Order
Here is the configuration file, you can change the settings to whatever you
want them to be:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/arit
hmetic.properties?view=markup
>From the default settings, it looks like calculation takes place at 3 digits
then gets rounded up to 2 places.
Regards
Scott
On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
Hi,
There must be something we are missing here. This can't be a bug, someone
would have noticed already. Especially something so fundimental.
Thanks & Regards,
Peter
-----Original Message-----
From: peter@ec4b.com [mailto: peter@ec4b.com]
Sent: 05 April 2007 00:11
To: 'user@ofbiz.apache.org '
Subject: RE: Inaccurate Calculation of Order
Importance: High
Hi,
Whichever way I work it out the Order Entry system does seem to be slightly
out.
>From Excel...
Price tax 2 digits tax 3 digits tax 9 digits
Product 1 35.74 6.25 6.255
6.254500000
Product 2 35.74 6.25 6.255
6.254500000
shipping 6 1.05 1.050
1.050000000
Tax 13.56 13.56 13.56 13.56
Total 91.04
The Order Manager came up with 91.05, I have screenshots if anyone is
interested.
Thanks & Regards,
Peter
-----Original Message-----
From: Adrian Crum [mailto:adrianc@hlmksw.com]
Sent: 04 April 2007 23:34
To: user@ofbiz.apache.org
Subject: Re: Inaccurate Calculation of Order
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> < peter@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
>>>
>>>
>>
>>
>
RE: The Return of...Inaccurate Calculation of Order
Posted by pe...@ec4b.com.
Hi,
Thanks for looking in to this David.
I have broken this down in to 'What is Actually Happening' and 'What I Would
Like to Happen'. Is this enough detail (see below)?
It is worth mentioning that the Procuts & Shipping calculations seem fine,
it is the Tax calculations that seem to be the issue.
For the following calculations using...'Tax' at a rate of 17.5% (known as
VAT).
----------------------------
----------------------------
WHAT IS ACTUALLY HAPPENING
----------------------------
----------------------------
0 : start
35.74: add product1 price of 35.742 (after a 30% discount)
35.74: add product2 price of 35.742 (after a 30% discount)
71.48: Goods Sub Total)
6.00: Shipping and Handling
77.48: Total to Charge (Pre-Tax)
...order.decimals = 2
...order.rounding = ROUND_HALF_UP
: add tax of 6.26 for Product1
: add tax of 6.26 for Product2
: add tax of 1.05 for Shipping
13.57: vat(tax) Sub Total
...salestax.calc.decimals = 3
...salestax.final.decimals = 2
...salestax.rounding = ROUND_HALF_UP
91.05: Grand Total (This is wrong it should be 91.04)
-----------------------------
-----------------------------
WHAT I WOULD LIKE TO HAPPEN
-----------------------------
-----------------------------
0 : start
35.74: add product1 price of 35.742 (after a 30% discount)
35.74: add product2 price of 35.742 (after a 30% discount)
71.48: Goods Sub Total
6.00: Shipping and Handling
77.48: Total to Charge (Pre-Tax)
...order.decimals = 2
...order.rounding = ROUND_HALF_UP
: add tax of 6.2545 for Product1
: add tax of 6.2545 for Product2
: add tax of 1.050 for Shipping
13.56: tax Sub Total (at 3 digits...13.559)
...salestax.calc.decimals = ? (Need to know what to set this to)
...salestax.final.decimals = 2
...salestax.rounding = ? (Need to know what to set this to)
91.04: Grand Total (at 3 digits...91.039)
Thanks & Regards,
Peter
-----Original Message-----
From: David E. Jones [mailto:jonesde@hotwaxmedia.com]
Sent: 18 April 2007 22:12
To: user@ofbiz.apache.org
Subject: Re: The Return of...Inaccurate Calculation of Order
Peter,
Sorry it took me so long to take a peek at this...
My guess is that the calculation process is not what you are
expected, namely in terms of when the rounding is done and such.
In order to spot exactly what is going on we need to see exactly how
you are doing your calculations to check the numbers. This goes back
to the common questions we need answers to in order to understand a
bug report, namely:
1. what did you expect to happen?
2. what happened?
3. how was it different than what you expected?
What we need in order for this discussion to make progress and not
continue to flounder, and to see if and what the problem might be, is
to describe this step by step. To really check things I'd also
recommend using a hand calculator to reproduce the steps and then
you'll have more control over what is happening.
My guess is that the lack of helpful replies stems from the fact that
there are insufficient details here to spot what might be going wrong.
In other words, something like:
0: start
35.74: add product price of 35.74
41.9945: add tax of 6.2545
41.995: round to three digits using ROUNG_HALF_UP method
Also, instead of using arbitrary numbers, please use something that
is in OFBiz itself so that people reviewing this can test it for
themselves and see what is happening. The best way to do this is to
describe a set of steps on demo.hotwaxmedia.com, which is just a
stock demo of OFBiz with the demo data in place and that is updated
daily.
-David
On Apr 18, 2007, at 2:33 PM, <pe...@ec4b.com> <pe...@ec4b.com> wrote:
> Hi,
>
>
> I have tried 10 digits, exact same problem.
>
> salestax.calc.decimals = 10
>
>
> Can anyone offer some assistance.
>
>
> Thanks & Regards,
>
> Peter
>
> ________________________________________
> From: Scott Gray [mailto:lektran@gmail.com]
> Sent: 18 April 2007 01:27
> To: user@ofbiz.apache.org; peter@ec4b.com
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
> Peter
>
> Change this line:
> salestax.calc.decimals = 10
> and see if that gives you the results you are expecting.
>
> Regards
> Scott
> On 18/04/07, peter@ec4b.com <pe...@ec4b.com> wrote:
> Hi,
>
>
>
>
>
> There is something very odd about the way Ofbiz calculates tax (in
> the order
> manager).
>
>
>
> Using this model from Excel;
>
> US$ price tax p+tax
>
> Product1 35.74 6.2545 41.995
>
> Product2 35.74 6.2545 41.995
>
> Shipping 6.00 1.050 7.050
>
> Total 77.48 (3 digit)
>
> Tax 13.56 13.559
>
> -------------------------------------------------
>
> Grand Total 91.04 91.039
>
>
>
>
>
> Method1 gives 91.05
>
> Method2 gives 91.03
>
>
>
> Tried each of the different big-decimal rounding scheme, not give
> the value
> I was expecting (91.04 ). I get either 91.03 or 91.05
>
>
>
>
>
> From the arithmetic.properties file;
>
>
>
> METHOD1
>
> # 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
>
>
>
> METHOD2
>
> # 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 = 3
>
> salestax.final.decimals = 2
>
> salestax.rounding = ROUND_HALF_UP
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
> _____
>
> From: Tim Ruppert [mailto:tim.ruppert@hotwaxmedia.com]
> Sent: 16 April 2007 19:06
> To: user@ofbiz.apache.org
> Cc: 'Chris Howe'
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
>
>
> He means - kill the process - and then restart it. Shut it down and
> start it
>
> up.
>
>
>
>
>
> Cheers,
>
> Tim
>
> --
>
> Tim Ruppert
>
> HotWax Media
>
> http://www.hotwaxmedia.com
>
>
>
> o:801.649.6594
>
> f:801.649.6595
>
>
>
>
>
>
>
> On Apr 16, 2007, at 12:02 PM, <pe...@ec4b.com> <pe...@ec4b.com> wrote:
>
>
>
>
>
> Hi Chris,
>
>
>
>
>
> Thanks very much for your quick response.
>
>
>
> Exactly do you mean by 'restart ofbiz', by your definition?
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
> -----Original Message-----
>
> From: Chris Howe [mailto:cjhowe76013@yahoo.com]
>
> Sent: 16 April 2007 18:04
>
> To: user@ofbiz.apache.org ; peter@ec4b.com
>
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
>
>
> Hi Peter,
>
>
>
> You need to restart OFBiz, not just clear the cache. Hope that helps.
>
>
>
>
>
> --- peter@ec4b.com wrote:
>
>
>
> Hi,
>
>
>
>
>
> Sure hope you can help with this, I have been going around in
>
> circles.
>
>
>
> I am having a problem with the way that Ofbiz calculates tax and
>
> order
>
> totals.
>
>
>
> From what I can gather, the file
>
> './applications/accounting/config/arithmetic.properties' controls the
>
> rounding and digit length for the calculation of taxes & order
>
> totals.
>
>
>
> I am starting to think the changes I make to the file are not being
>
> applied,
>
> I say this because when I look at the 'Unit Price' in an order it
>
> shows
>
> 35.742, rather than 35.74. Which would tend to indicate that settings
>
> are
>
> not being used because the number of decimal points in each of the
>
> settings
>
> in 'arithmetic.properties ' are set to 2 digits. I have pasted in the
>
> contents of the 'arithmetic.properties' file below so you can have a
>
> look. I
>
> have changed the 'rounding' to a different method to try to achieve
>
> the
>
> correct figures.
>
>
>
> There is only a disparity of +0.1 but, technically it is wrong. Ofbiz
>
> keeps
>
> giving me a total of 91.05, but it should be 91.04. I am been given a
>
> hard
>
> time about it...
>
>
>
> Essentially;
>
>
>
> Using Excel;
>
> US$ tax p+tax
>
> Product1 35.74 6.2545 41.995
>
> Product2 35.74 6.2545 41.995
>
> Shipping 6.00 1.050 7.050
>
> Total 77.48 (3 digit)
>
> Tax 13.56 13.559
>
> ------------------------
>
> Grand Total 91.04 91.039
>
>
>
> Simply put, I think that the problem is a combination of two issues;
>
> (i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2
>
> digits).
>
> and
>
> (ii). Uses rounding 'ROUND_HALF_UP', I would tend to use
>
> 'ROUND_HALF_DOWN'.
>
> I think the ' arithmetic.properties' file below, should do the trick.
>
> But it
>
> doesn't seem to being 'applied' to the calculation.
>
>
>
>
>
> So I have two Questions;
>
>
>
> 1). (BIGGEST ISSUE) Do I have to 'activate' the
>
> 'arithmetic.properties'
>
> file, and if so how do I do that? (All I have been doing is clearing
>
> the
>
> cache and logging out then logging in again, as I had been told this
>
> is the
>
> way to do it).
>
> 2). Do you see my point about 94.05 and 94.04, and the best way to
>
> make this
>
> calculation?
>
>
>
>
>
> ---CONTENTS OF---
>
>
>
> .../Ofbiz/trunk/applications/accounting/config/arithmetic.properties
>
>
>
>
>
> #
>
> # 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_DOWN
>
>
>
> # 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_DOWN
>
>
>
> # For setting decimal precision and rounding method of operations
>
> related to
>
> customer accounts
>
> # such as Financial Accounts
>
> finaccount.decimals = 2
>
> finaccount.rounding = ROUND_HALF_DOWN
>
>
>
> # 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_DOWN
>
>
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
>
>
> ________________________________________
>
>
>
> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
>
> Hi Scott,
>
>
>
>
>
> Just strikes me that the file should be 'correct' for everyone. What
>
> would
>
> be your guidance as to what the file should be?
>
>
>
> Appreciate your fast responses this evening. It is 1:15am here in the
>
> UK
>
> just can't stay awake any more.
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
>
>
>
>
> ________________________________________
>
> From: Scott Gray [mailto: lektran@gmail.com]
>
> Sent: 05 April 2007 01:16
>
> To: user@ofbiz.apache.org; peter@ec4b.com
>
>
>
> Subject: Re: Inaccurate Calculation of Order
>
>
>
> Here is the configuration file, you can change the settings to
>
> whatever you
>
> want them to be:
>
>
>
> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/
> config/arit
>
>
> hmetic.properties?view=markup
>
>
>
> From the default settings, it looks like calculation takes place at 3
>
> digits
>
> then gets rounded up to 2 places.
>
>
>
> Regards
>
> Scott
>
> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
>
> Hi,
>
>
>
>
>
> There must be something we are missing here. This can't be a bug,
>
> someone
>
> would have noticed already. Especially something so fundimental.
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
>
>
> -----Original Message-----
>
> From: peter@ec4b.com [mailto: peter@ec4b.com]
>
> Sent: 05 April 2007 00:11
>
> To: 'user@ofbiz.apache.org '
>
> Subject: RE: Inaccurate Calculation of Order
>
> Importance: High
>
>
>
> Hi,
>
>
>
>
>
> Whichever way I work it out the Order Entry system does seem to be
>
> slightly
>
> out.
>
>
>
>
>
> From Excel...
>
>
>
> Price tax 2 digits tax 3 digits tax 9
>
> digits
>
>
>
> Product 1 35.74 6.25 6.255
>
> 6.254500000
>
> Product 2 35.74 6.25 6.255
>
> 6.254500000
>
> shipping 6 1.05 1.050
>
>
>
> === message truncated ===
>
>
>
>
>
>
Re: OfBiz newbie - prototyping in OfBiz
Posted by Jacques Le Roux <ja...@les7arts.com>.
Mathius,
> 2. We need to provide an access right control in which some screen
may not available for some users. In my previous j2ee web application
(modified version struts framework) we implemented this functionality by
storing the access right (read, read/write, no access) to modules and/or
functions in a database table and provided a custom tag with user and
module/function IDs as parameters. The decision to show/hide a
particular module will be checked in either JSP/Command class. Is there
any existing functionality for such access control in OfBiz? Any other
recommended way of achieving this requirement?
In OFBiz this is achieved thru roles and permissions wich are related to
parties.
> 3. Looks like our sponsor have look at the SugarCRM module builder
and likes the module builder provided by SugarCRM. Is there any similar
functionality on OfBiz? may be not exactly the same but may be closer in
terms of functionality.
I don't know what module builder is in SugarCRM. But if you are looking
for similar functionnalities than in SugarCRM you should look at
Opentaps : http://www.opentaps.org/
Jacques
OfBiz newbie - prototyping in OfBiz
Posted by Mathius Allo <mg...@yahoo.com>.
Hi OfBiz Expert,
We are currently doing our final year project and we decided to use OfBiz as it is part of ASF and it seems to fit to our project. We did quite extensive research on OfBiz and we knew that there will be a very high learning curve. I think we are progressing (but quite slow) by making use of the freely available OfBiz documentations. Our sponsor decided to purchase the Advanced Training material from Undersun but it seems that Undersun may be running out of stock on the DVD training (don't know exactly). Ok. that's enough for overview...
My questions are:
1. One of the best practice in OfBiz is to prototype using BeanShell. I have been searching for documentation how to do this prototyping using OfBiz. We have existing prototyping using PHP but we really want to use OfBiz as we'll be learning the framework at the same time. Any sample documentation on this? Any pointer on how to do it is really appreciated.
2. We need to provide an access right control in which some screen may not available for some users. In my previous j2ee web application (modified version struts framework) we implemented this functionality by storing the access right (read, read/write, no access) to modules and/or functions in a database table and provided a custom tag with user and module/function IDs as parameters. The decision to show/hide a particular module will be checked in either JSP/Command class. Is there any existing functionality for such access control in OfBiz? Any other recommended way of achieving this requirement?
3. Looks like our sponsor have look at the SugarCRM module builder and likes the module builder provided by SugarCRM. Is there any similar functionality on OfBiz? may be not exactly the same but may be closer in terms of functionality.
Please let me know if I should ask question 2 & 3 in a separate email for easier tracking/searching.
Thanks in advance.
Mathius
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
Check outnew cars at Yahoo! Autos.
Re: The Return of...Inaccurate Calculation of Order
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
It's been an hour and a half since you sent that message... It is
very rare that questions are answered that quickly.
I'd also recommend being WAY WAY WAY more specific. I can't emphasize
that enough.
Saying that the problem is with tax calculation was helpful, and may
be the key to your question (ie most of the other stuff you said was
totally misleading if that really is the problem).
Hopefully I or someone can answer your most recent question soon.
I would still recommend, as I did in my email below, that you list
steps to reproduce for out of the box OFBiz with demo data, or use
demo.hotwaxmedia.com as I mentioned. That makes it WAY easier for
people to see exactly what you're talking about, with only a little
effort on your part.
Remember it's 100% about communication, and because OFBiz is such a
big system you need to be very specific.
-David
On Apr 18, 2007, at 5:15 PM, <pe...@ec4b.com> wrote:
> Hi David,
>
>
> Please find attached my response, don't seem to be getting any
> response from
> the userlist. Can you help?
>
>
> Thanks & Regards,
>
> Peter
>
>
> -----Original Message-----
> From: David E. Jones [mailto:jonesde@hotwaxmedia.com]
> Sent: 18 April 2007 22:12
> To: user@ofbiz.apache.org
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
>
> Peter,
>
> Sorry it took me so long to take a peek at this...
>
> My guess is that the calculation process is not what you are
> expected, namely in terms of when the rounding is done and such.
>
> In order to spot exactly what is going on we need to see exactly how
> you are doing your calculations to check the numbers. This goes back
> to the common questions we need answers to in order to understand a
> bug report, namely:
>
> 1. what did you expect to happen?
> 2. what happened?
> 3. how was it different than what you expected?
>
> What we need in order for this discussion to make progress and not
> continue to flounder, and to see if and what the problem might be, is
> to describe this step by step. To really check things I'd also
> recommend using a hand calculator to reproduce the steps and then
> you'll have more control over what is happening.
>
> My guess is that the lack of helpful replies stems from the fact that
> there are insufficient details here to spot what might be going wrong.
>
> In other words, something like:
>
> 0: start
> 35.74: add product price of 35.74
> 41.9945: add tax of 6.2545
> 41.995: round to three digits using ROUNG_HALF_UP method
>
> Also, instead of using arbitrary numbers, please use something that
> is in OFBiz itself so that people reviewing this can test it for
> themselves and see what is happening. The best way to do this is to
> describe a set of steps on demo.hotwaxmedia.com, which is just a
> stock demo of OFBiz with the demo data in place and that is updated
> daily.
>
> -David
>
>
>
> On Apr 18, 2007, at 2:33 PM, <pe...@ec4b.com> <pe...@ec4b.com> wrote:
>
>> Hi,
>>
>>
>> I have tried 10 digits, exact same problem.
>>
>> salestax.calc.decimals = 10
>>
>>
>> Can anyone offer some assistance.
>>
>>
>> Thanks & Regards,
>>
>> Peter
>>
>> ________________________________________
>> From: Scott Gray [mailto:lektran@gmail.com]
>> Sent: 18 April 2007 01:27
>> To: user@ofbiz.apache.org; peter@ec4b.com
>> Subject: Re: The Return of...Inaccurate Calculation of Order
>>
>> Peter
>>
>> Change this line:
>> salestax.calc.decimals = 10
>> and see if that gives you the results you are expecting.
>>
>> Regards
>> Scott
>> On 18/04/07, peter@ec4b.com <pe...@ec4b.com> wrote:
>> Hi,
>>
>>
>>
>>
>>
>> There is something very odd about the way Ofbiz calculates tax (in
>> the order
>> manager).
>>
>>
>>
>> Using this model from Excel;
>>
>> US$ price tax p+tax
>>
>> Product1 35.74 6.2545 41.995
>>
>> Product2 35.74 6.2545 41.995
>>
>> Shipping 6.00 1.050 7.050
>>
>> Total 77.48 (3 digit)
>>
>> Tax 13.56 13.559
>>
>> -------------------------------------------------
>>
>> Grand Total 91.04 91.039
>>
>>
>>
>>
>>
>> Method1 gives 91.05
>>
>> Method2 gives 91.03
>>
>>
>>
>> Tried each of the different big-decimal rounding scheme, not give
>> the value
>> I was expecting (91.04 ). I get either 91.03 or 91.05
>>
>>
>>
>>
>>
>> From the arithmetic.properties file;
>>
>>
>>
>> METHOD1
>>
>> # 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
>>
>>
>>
>> METHOD2
>>
>> # 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 = 3
>>
>> salestax.final.decimals = 2
>>
>> salestax.rounding = ROUND_HALF_UP
>>
>>
>>
>>
>>
>> Thanks & Regards,
>>
>>
>>
>> Peter
>>
>>
>>
>> _____
>>
>> From: Tim Ruppert [mailto:tim.ruppert@hotwaxmedia.com]
>> Sent: 16 April 2007 19:06
>> To: user@ofbiz.apache.org
>> Cc: 'Chris Howe'
>> Subject: Re: The Return of...Inaccurate Calculation of Order
>>
>>
>>
>> He means - kill the process - and then restart it. Shut it down and
>> start it
>>
>> up.
>>
>>
>>
>>
>>
>> Cheers,
>>
>> Tim
>>
>> --
>>
>> Tim Ruppert
>>
>> HotWax Media
>>
>> http://www.hotwaxmedia.com
>>
>>
>>
>> o:801.649.6594
>>
>> f:801.649.6595
>>
>>
>>
>>
>>
>>
>>
>> On Apr 16, 2007, at 12:02 PM, <pe...@ec4b.com> <pe...@ec4b.com>
>> wrote:
>>
>>
>>
>>
>>
>> Hi Chris,
>>
>>
>>
>>
>>
>> Thanks very much for your quick response.
>>
>>
>>
>> Exactly do you mean by 'restart ofbiz', by your definition?
>>
>>
>>
>>
>>
>> Thanks & Regards,
>>
>>
>>
>> Peter
>>
>>
>>
>> -----Original Message-----
>>
>> From: Chris Howe [mailto:cjhowe76013@yahoo.com]
>>
>> Sent: 16 April 2007 18:04
>>
>> To: user@ofbiz.apache.org ; peter@ec4b.com
>>
>> Subject: Re: The Return of...Inaccurate Calculation of Order
>>
>>
>>
>> Hi Peter,
>>
>>
>>
>> You need to restart OFBiz, not just clear the cache. Hope that helps.
>>
>>
>>
>>
>>
>> --- peter@ec4b.com wrote:
>>
>>
>>
>> Hi,
>>
>>
>>
>>
>>
>> Sure hope you can help with this, I have been going around in
>>
>> circles.
>>
>>
>>
>> I am having a problem with the way that Ofbiz calculates tax and
>>
>> order
>>
>> totals.
>>
>>
>>
>> From what I can gather, the file
>>
>> './applications/accounting/config/arithmetic.properties' controls the
>>
>> rounding and digit length for the calculation of taxes & order
>>
>> totals.
>>
>>
>>
>> I am starting to think the changes I make to the file are not being
>>
>> applied,
>>
>> I say this because when I look at the 'Unit Price' in an order it
>>
>> shows
>>
>> 35.742, rather than 35.74. Which would tend to indicate that settings
>>
>> are
>>
>> not being used because the number of decimal points in each of the
>>
>> settings
>>
>> in 'arithmetic.properties ' are set to 2 digits. I have pasted in the
>>
>> contents of the 'arithmetic.properties' file below so you can have a
>>
>> look. I
>>
>> have changed the 'rounding' to a different method to try to achieve
>>
>> the
>>
>> correct figures.
>>
>>
>>
>> There is only a disparity of +0.1 but, technically it is wrong. Ofbiz
>>
>> keeps
>>
>> giving me a total of 91.05, but it should be 91.04. I am been given a
>>
>> hard
>>
>> time about it...
>>
>>
>>
>> Essentially;
>>
>>
>>
>> Using Excel;
>>
>> US$ tax p+tax
>>
>> Product1 35.74 6.2545 41.995
>>
>> Product2 35.74 6.2545 41.995
>>
>> Shipping 6.00 1.050 7.050
>>
>> Total 77.48 (3 digit)
>>
>> Tax 13.56 13.559
>>
>> ------------------------
>>
>> Grand Total 91.04 91.039
>>
>>
>>
>> Simply put, I think that the problem is a combination of two issues;
>>
>> (i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2
>>
>> digits).
>>
>> and
>>
>> (ii). Uses rounding 'ROUND_HALF_UP', I would tend to use
>>
>> 'ROUND_HALF_DOWN'.
>>
>> I think the ' arithmetic.properties' file below, should do the trick.
>>
>> But it
>>
>> doesn't seem to being 'applied' to the calculation.
>>
>>
>>
>>
>>
>> So I have two Questions;
>>
>>
>>
>> 1). (BIGGEST ISSUE) Do I have to 'activate' the
>>
>> 'arithmetic.properties'
>>
>> file, and if so how do I do that? (All I have been doing is clearing
>>
>> the
>>
>> cache and logging out then logging in again, as I had been told this
>>
>> is the
>>
>> way to do it).
>>
>> 2). Do you see my point about 94.05 and 94.04, and the best way to
>>
>> make this
>>
>> calculation?
>>
>>
>>
>>
>>
>> ---CONTENTS OF---
>>
>>
>>
>> .../Ofbiz/trunk/applications/accounting/config/arithmetic.properties
>>
>>
>>
>>
>>
>> #
>>
>> # 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_DOWN
>>
>>
>>
>> # 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_DOWN
>>
>>
>>
>> # For setting decimal precision and rounding method of operations
>>
>> related to
>>
>> customer accounts
>>
>> # such as Financial Accounts
>>
>> finaccount.decimals = 2
>>
>> finaccount.rounding = ROUND_HALF_DOWN
>>
>>
>>
>> # 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_DOWN
>>
>>
>>
>>
>>
>>
>>
>> Thanks & Regards,
>>
>>
>>
>> Peter
>>
>>
>>
>>
>>
>> ________________________________________
>>
>>
>>
>> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
>>
>> Hi Scott,
>>
>>
>>
>>
>>
>> Just strikes me that the file should be 'correct' for everyone. What
>>
>> would
>>
>> be your guidance as to what the file should be?
>>
>>
>>
>> Appreciate your fast responses this evening. It is 1:15am here in the
>>
>> UK
>>
>> just can't stay awake any more.
>>
>>
>>
>>
>>
>> Thanks & Regards,
>>
>>
>>
>> Peter
>>
>>
>>
>>
>>
>>
>>
>> ________________________________________
>>
>> From: Scott Gray [mailto: lektran@gmail.com]
>>
>> Sent: 05 April 2007 01:16
>>
>> To: user@ofbiz.apache.org; peter@ec4b.com
>>
>>
>>
>> Subject: Re: Inaccurate Calculation of Order
>>
>>
>>
>> Here is the configuration file, you can change the settings to
>>
>> whatever you
>>
>> want them to be:
>>
>>
>>
>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/
>> config/arit
>>
>>
>> hmetic.properties?view=markup
>>
>>
>>
>> From the default settings, it looks like calculation takes place at 3
>>
>> digits
>>
>> then gets rounded up to 2 places.
>>
>>
>>
>> Regards
>>
>> Scott
>>
>> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
>>
>> Hi,
>>
>>
>>
>>
>>
>> There must be something we are missing here. This can't be a bug,
>>
>> someone
>>
>> would have noticed already. Especially something so fundimental.
>>
>>
>>
>>
>>
>> Thanks & Regards,
>>
>>
>>
>> Peter
>>
>>
>>
>>
>>
>> -----Original Message-----
>>
>> From: peter@ec4b.com [mailto: peter@ec4b.com]
>>
>> Sent: 05 April 2007 00:11
>>
>> To: 'user@ofbiz.apache.org '
>>
>> Subject: RE: Inaccurate Calculation of Order
>>
>> Importance: High
>>
>>
>>
>> Hi,
>>
>>
>>
>>
>>
>> Whichever way I work it out the Order Entry system does seem to be
>>
>> slightly
>>
>> out.
>>
>>
>>
>>
>>
>> From Excel...
>>
>>
>>
>> Price tax 2 digits tax 3 digits tax 9
>>
>> digits
>>
>>
>>
>> Product 1 35.74 6.25 6.255
>>
>> 6.254500000
>>
>> Product 2 35.74 6.25 6.255
>>
>> 6.254500000
>>
>> shipping 6 1.05 1.050
>>
>>
>>
>> === message truncated ===
>>
>>
>>
>>
>>
>>
>
>
> From: <pe...@ec4b.com>
> Date: April 18, 2007 3:49:49 PM MDT
> To: <us...@ofbiz.apache.org>
> Subject: RE: The Return of...Inaccurate Calculation of Order
> Reply-To: <pe...@ec4b.com>
>
>
> Hi,
>
>
> Thanks for looking in to this David.
>
> I have broken this down in to 'What is Actually Happening' and
> 'What I Would Like to Happen'. Is this enough detail (see below)?
>
> It is worth mentioning that the Procuts & Shipping calculations
> seem fine, it is the Tax calculations that seem to be the issue.
>
>
> For the following calculations using...'Tax' at a rate of 17.5%
> (known as VAT).
>
> ----------------------------
> ----------------------------
> WHAT IS ACTUALLY HAPPENING
> ----------------------------
> ----------------------------
>
> 0 : start
> 35.74: add product1 price of 35.742 (after a 30% discount)
> 35.74: add product2 price of 35.742 (after a 30% discount)
> 71.48: Goods Sub Total)
> 6.00: Shipping and Handling
> 77.48: Total to Charge (Pre-Tax)
>
> ...order.decimals = 2
> ...order.rounding = ROUND_HALF_UP
>
> : add tax of 6.26 for Product1
> : add tax of 6.26 for Product2
> : add tax of 1.05 for Shipping
>
> 13.57: vat(tax) Sub Total
>
> ...salestax.calc.decimals = 3
> ...salestax.final.decimals = 2
> ...salestax.rounding = ROUND_HALF_UP
>
> 91.05: Grand Total (This is wrong it should be 91.04)
>
>
> -----------------------------
> -----------------------------
> WHAT I WOULD LIKE TO HAPPEN
> -----------------------------
> -----------------------------
>
> 0 : start
> 35.74: add product1 price of 35.742 (after a 30% discount)
> 35.74: add product2 price of 35.742 (after a 30% discount)
> 71.48: Goods Sub Total
> 6.00: Shipping and Handling
> 77.48: Total to Charge (Pre-Tax)
>
> ...order.decimals = 2
> ...order.rounding = ROUND_HALF_UP
>
> : add tax of 6.2545 for Product1
> : add tax of 6.2545 for Product2
> : add tax of 1.050 for Shipping
>
> 13.56: tax Sub Total (at 3 digits...13.559)
>
> ...salestax.calc.decimals = ? (Need to know what to set this to)
> ...salestax.final.decimals = 2
> ...salestax.rounding = ? (Need to know what to set this to)
>
> 91.04: Grand Total (at 3 digits...91.039)
>
>
> Thanks & Regards,
>
> Peter
>
>
> -----Original Message-----
> From: David E. Jones [mailto:jonesde@hotwaxmedia.com]
> Sent: 18 April 2007 22:12
> To: user@ofbiz.apache.org
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
>
> Peter,
>
> Sorry it took me so long to take a peek at this...
>
> My guess is that the calculation process is not what you are
> expected, namely in terms of when the rounding is done and such.
>
> In order to spot exactly what is going on we need to see exactly how
> you are doing your calculations to check the numbers. This goes back
> to the common questions we need answers to in order to understand a
> bug report, namely:
>
> 1. what did you expect to happen?
> 2. what happened?
> 3. how was it different than what you expected?
>
> What we need in order for this discussion to make progress and not
> continue to flounder, and to see if and what the problem might be, is
> to describe this step by step. To really check things I'd also
> recommend using a hand calculator to reproduce the steps and then
> you'll have more control over what is happening.
>
> My guess is that the lack of helpful replies stems from the fact that
> there are insufficient details here to spot what might be going wrong.
>
> In other words, something like:
>
> 0: start
> 35.74: add product price of 35.74
> 41.9945: add tax of 6.2545
> 41.995: round to three digits using ROUNG_HALF_UP method
>
> Also, instead of using arbitrary numbers, please use something that
> is in OFBiz itself so that people reviewing this can test it for
> themselves and see what is happening. The best way to do this is to
> describe a set of steps on demo.hotwaxmedia.com, which is just a
> stock demo of OFBiz with the demo data in place and that is updated
> daily.
>
> -David
>
>
>
> On Apr 18, 2007, at 2:33 PM, <pe...@ec4b.com> <pe...@ec4b.com> wrote:
>
> > Hi,
> >
> >
> > I have tried 10 digits, exact same problem.
> >
> > salestax.calc.decimals = 10
> >
> >
> > Can anyone offer some assistance.
> >
> >
> > Thanks & Regards,
> >
> > Peter
> >
> > ________________________________________
> > From: Scott Gray [mailto:lektran@gmail.com]
> > Sent: 18 April 2007 01:27
> > To: user@ofbiz.apache.org; peter@ec4b.com
> > Subject: Re: The Return of...Inaccurate Calculation of Order
> >
> > Peter
> >
> > Change this line:
> > salestax.calc.decimals = 10
> > and see if that gives you the results you are expecting.
> >
> > Regards
> > Scott
> > On 18/04/07, peter@ec4b.com <pe...@ec4b.com> wrote:
> > Hi,
> >
> >
> >
> >
> >
> > There is something very odd about the way Ofbiz calculates tax (in
> > the order
> > manager).
> >
> >
> >
> > Using this model from Excel;
> >
> > US$ price tax p+tax
> >
> > Product1 35.74 6.2545 41.995
> >
> > Product2 35.74 6.2545 41.995
> >
> > Shipping 6.00 1.050 7.050
> >
> > Total 77.48 (3 digit)
> >
> > Tax 13.56 13.559
> >
> > -------------------------------------------------
> >
> > Grand Total 91.04 91.039
> >
> >
> >
> >
> >
> > Method1 gives 91.05
> >
> > Method2 gives 91.03
> >
> >
> >
> > Tried each of the different big-decimal rounding scheme, not give
> > the value
> > I was expecting (91.04 ). I get either 91.03 or 91.05
> >
> >
> >
> >
> >
> > From the arithmetic.properties file;
> >
> >
> >
> > METHOD1
> >
> > # 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
> >
> >
> >
> > METHOD2
> >
> > # 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 = 3
> >
> > salestax.final.decimals = 2
> >
> > salestax.rounding = ROUND_HALF_UP
> >
> >
> >
> >
> >
> > Thanks & Regards,
> >
> >
> >
> > Peter
> >
> >
> >
> > _____
> >
> > From: Tim Ruppert [mailto:tim.ruppert@hotwaxmedia.com]
> > Sent: 16 April 2007 19:06
> > To: user@ofbiz.apache.org
> > Cc: 'Chris Howe'
> > Subject: Re: The Return of...Inaccurate Calculation of Order
> >
> >
> >
> > He means - kill the process - and then restart it. Shut it down and
> > start it
> >
> > up.
> >
> >
> >
> >
> >
> > Cheers,
> >
> > Tim
> >
> > --
> >
> > Tim Ruppert
> >
> > HotWax Media
> >
> > http://www.hotwaxmedia.com
> >
> >
> >
> > o:801.649.6594
> >
> > f:801.649.6595
> >
> >
> >
> >
> >
> >
> >
> > On Apr 16, 2007, at 12:02 PM, <pe...@ec4b.com> <pe...@ec4b.com>
> wrote:
> >
> >
> >
> >
> >
> > Hi Chris,
> >
> >
> >
> >
> >
> > Thanks very much for your quick response.
> >
> >
> >
> > Exactly do you mean by 'restart ofbiz', by your definition?
> >
> >
> >
> >
> >
> > Thanks & Regards,
> >
> >
> >
> > Peter
> >
> >
> >
> > -----Original Message-----
> >
> > From: Chris Howe [mailto:cjhowe76013@yahoo.com]
> >
> > Sent: 16 April 2007 18:04
> >
> > To: user@ofbiz.apache.org ; peter@ec4b.com
> >
> > Subject: Re: The Return of...Inaccurate Calculation of Order
> >
> >
> >
> > Hi Peter,
> >
> >
> >
> > You need to restart OFBiz, not just clear the cache. Hope that
> helps.
> >
> >
> >
> >
> >
> > --- peter@ec4b.com wrote:
> >
> >
> >
> > Hi,
> >
> >
> >
> >
> >
> > Sure hope you can help with this, I have been going around in
> >
> > circles.
> >
> >
> >
> > I am having a problem with the way that Ofbiz calculates tax and
> >
> > order
> >
> > totals.
> >
> >
> >
> > From what I can gather, the file
> >
> > './applications/accounting/config/arithmetic.properties' controls
> the
> >
> > rounding and digit length for the calculation of taxes & order
> >
> > totals.
> >
> >
> >
> > I am starting to think the changes I make to the file are not being
> >
> > applied,
> >
> > I say this because when I look at the 'Unit Price' in an order it
> >
> > shows
> >
> > 35.742, rather than 35.74. Which would tend to indicate that
> settings
> >
> > are
> >
> > not being used because the number of decimal points in each of the
> >
> > settings
> >
> > in 'arithmetic.properties ' are set to 2 digits. I have pasted in
> the
> >
> > contents of the 'arithmetic.properties' file below so you can have a
> >
> > look. I
> >
> > have changed the 'rounding' to a different method to try to achieve
> >
> > the
> >
> > correct figures.
> >
> >
> >
> > There is only a disparity of +0.1 but, technically it is wrong.
> Ofbiz
> >
> > keeps
> >
> > giving me a total of 91.05, but it should be 91.04. I am been
> given a
> >
> > hard
> >
> > time about it...
> >
> >
> >
> > Essentially;
> >
> >
> >
> > Using Excel;
> >
> > US$ tax p+tax
> >
> > Product1 35.74 6.2545 41.995
> >
> > Product2 35.74 6.2545 41.995
> >
> > Shipping 6.00 1.050 7.050
> >
> > Total 77.48 (3 digit)
> >
> > Tax 13.56 13.559
> >
> > ------------------------
> >
> > Grand Total 91.04 91.039
> >
> >
> >
> > Simply put, I think that the problem is a combination of two issues;
> >
> > (i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2
> >
> > digits).
> >
> > and
> >
> > (ii). Uses rounding 'ROUND_HALF_UP', I would tend to use
> >
> > 'ROUND_HALF_DOWN'.
> >
> > I think the ' arithmetic.properties' file below, should do the
> trick.
> >
> > But it
> >
> > doesn't seem to being 'applied' to the calculation.
> >
> >
> >
> >
> >
> > So I have two Questions;
> >
> >
> >
> > 1). (BIGGEST ISSUE) Do I have to 'activate' the
> >
> > 'arithmetic.properties'
> >
> > file, and if so how do I do that? (All I have been doing is clearing
> >
> > the
> >
> > cache and logging out then logging in again, as I had been told this
> >
> > is the
> >
> > way to do it).
> >
> > 2). Do you see my point about 94.05 and 94.04, and the best way to
> >
> > make this
> >
> > calculation?
> >
> >
> >
> >
> >
> > ---CONTENTS OF---
> >
> >
> >
> > .../Ofbiz/trunk/applications/accounting/config/arithmetic.properties
> >
> >
> >
> >
> >
> > #
> >
> > # 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_DOWN
> >
> >
> >
> > # 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_DOWN
> >
> >
> >
> > # For setting decimal precision and rounding method of operations
> >
> > related to
> >
> > customer accounts
> >
> > # such as Financial Accounts
> >
> > finaccount.decimals = 2
> >
> > finaccount.rounding = ROUND_HALF_DOWN
> >
> >
> >
> > # 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_DOWN
> >
> >
> >
> >
> >
> >
> >
> > Thanks & Regards,
> >
> >
> >
> > Peter
> >
> >
> >
> >
> >
> > ________________________________________
> >
> >
> >
> > On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
> >
> > Hi Scott,
> >
> >
> >
> >
> >
> > Just strikes me that the file should be 'correct' for everyone. What
> >
> > would
> >
> > be your guidance as to what the file should be?
> >
> >
> >
> > Appreciate your fast responses this evening. It is 1:15am here in
> the
> >
> > UK
> >
> > just can't stay awake any more.
> >
> >
> >
> >
> >
> > Thanks & Regards,
> >
> >
> >
> > Peter
> >
> >
> >
> >
> >
> >
> >
> > ________________________________________
> >
> > From: Scott Gray [mailto: lektran@gmail.com]
> >
> > Sent: 05 April 2007 01:16
> >
> > To: user@ofbiz.apache.org; peter@ec4b.com
> >
> >
> >
> > Subject: Re: Inaccurate Calculation of Order
> >
> >
> >
> > Here is the configuration file, you can change the settings to
> >
> > whatever you
> >
> > want them to be:
> >
> >
> >
> > http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/
> > config/arit
> >
> >
> > hmetic.properties?view=markup
> >
> >
> >
> > From the default settings, it looks like calculation takes place
> at 3
> >
> > digits
> >
> > then gets rounded up to 2 places.
> >
> >
> >
> > Regards
> >
> > Scott
> >
> > On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
> >
> > Hi,
> >
> >
> >
> >
> >
> > There must be something we are missing here. This can't be a bug,
> >
> > someone
> >
> > would have noticed already. Especially something so fundimental.
> >
> >
> >
> >
> >
> > Thanks & Regards,
> >
> >
> >
> > Peter
> >
> >
> >
> >
> >
> > -----Original Message-----
> >
> > From: peter@ec4b.com [mailto: peter@ec4b.com]
> >
> > Sent: 05 April 2007 00:11
> >
> > To: 'user@ofbiz.apache.org '
> >
> > Subject: RE: Inaccurate Calculation of Order
> >
> > Importance: High
> >
> >
> >
> > Hi,
> >
> >
> >
> >
> >
> > Whichever way I work it out the Order Entry system does seem to be
> >
> > slightly
> >
> > out.
> >
> >
> >
> >
> >
> > From Excel...
> >
> >
> >
> > Price tax 2 digits tax 3 digits tax 9
> >
> > digits
> >
> >
> >
> > Product 1 35.74 6.25 6.255
> >
> > 6.254500000
> >
> > Product 2 35.74 6.25 6.255
> >
> > 6.254500000
> >
> > shipping 6 1.05 1.050
> >
> >
> >
> > === message truncated ===
> >
> >
> >
> >
> >
> >
>
Re: The Return of...Inaccurate Calculation of Order
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
Peter,
Sorry it took me so long to take a peek at this...
My guess is that the calculation process is not what you are
expected, namely in terms of when the rounding is done and such.
In order to spot exactly what is going on we need to see exactly how
you are doing your calculations to check the numbers. This goes back
to the common questions we need answers to in order to understand a
bug report, namely:
1. what did you expect to happen?
2. what happened?
3. how was it different than what you expected?
What we need in order for this discussion to make progress and not
continue to flounder, and to see if and what the problem might be, is
to describe this step by step. To really check things I'd also
recommend using a hand calculator to reproduce the steps and then
you'll have more control over what is happening.
My guess is that the lack of helpful replies stems from the fact that
there are insufficient details here to spot what might be going wrong.
In other words, something like:
0: start
35.74: add product price of 35.74
41.9945: add tax of 6.2545
41.995: round to three digits using ROUNG_HALF_UP method
Also, instead of using arbitrary numbers, please use something that
is in OFBiz itself so that people reviewing this can test it for
themselves and see what is happening. The best way to do this is to
describe a set of steps on demo.hotwaxmedia.com, which is just a
stock demo of OFBiz with the demo data in place and that is updated
daily.
-David
On Apr 18, 2007, at 2:33 PM, <pe...@ec4b.com> <pe...@ec4b.com> wrote:
> Hi,
>
>
> I have tried 10 digits, exact same problem.
>
> salestax.calc.decimals = 10
>
>
> Can anyone offer some assistance.
>
>
> Thanks & Regards,
>
> Peter
>
> ________________________________________
> From: Scott Gray [mailto:lektran@gmail.com]
> Sent: 18 April 2007 01:27
> To: user@ofbiz.apache.org; peter@ec4b.com
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
> Peter
>
> Change this line:
> salestax.calc.decimals = 10
> and see if that gives you the results you are expecting.
>
> Regards
> Scott
> On 18/04/07, peter@ec4b.com <pe...@ec4b.com> wrote:
> Hi,
>
>
>
>
>
> There is something very odd about the way Ofbiz calculates tax (in
> the order
> manager).
>
>
>
> Using this model from Excel;
>
> US$ price tax p+tax
>
> Product1 35.74 6.2545 41.995
>
> Product2 35.74 6.2545 41.995
>
> Shipping 6.00 1.050 7.050
>
> Total 77.48 (3 digit)
>
> Tax 13.56 13.559
>
> -------------------------------------------------
>
> Grand Total 91.04 91.039
>
>
>
>
>
> Method1 gives 91.05
>
> Method2 gives 91.03
>
>
>
> Tried each of the different big-decimal rounding scheme, not give
> the value
> I was expecting (91.04 ). I get either 91.03 or 91.05
>
>
>
>
>
> From the arithmetic.properties file;
>
>
>
> METHOD1
>
> # 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
>
>
>
> METHOD2
>
> # 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 = 3
>
> salestax.final.decimals = 2
>
> salestax.rounding = ROUND_HALF_UP
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
> _____
>
> From: Tim Ruppert [mailto:tim.ruppert@hotwaxmedia.com]
> Sent: 16 April 2007 19:06
> To: user@ofbiz.apache.org
> Cc: 'Chris Howe'
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
>
>
> He means - kill the process - and then restart it. Shut it down and
> start it
>
> up.
>
>
>
>
>
> Cheers,
>
> Tim
>
> --
>
> Tim Ruppert
>
> HotWax Media
>
> http://www.hotwaxmedia.com
>
>
>
> o:801.649.6594
>
> f:801.649.6595
>
>
>
>
>
>
>
> On Apr 16, 2007, at 12:02 PM, <pe...@ec4b.com> <pe...@ec4b.com> wrote:
>
>
>
>
>
> Hi Chris,
>
>
>
>
>
> Thanks very much for your quick response.
>
>
>
> Exactly do you mean by 'restart ofbiz', by your definition?
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
> -----Original Message-----
>
> From: Chris Howe [mailto:cjhowe76013@yahoo.com]
>
> Sent: 16 April 2007 18:04
>
> To: user@ofbiz.apache.org ; peter@ec4b.com
>
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
>
>
> Hi Peter,
>
>
>
> You need to restart OFBiz, not just clear the cache. Hope that helps.
>
>
>
>
>
> --- peter@ec4b.com wrote:
>
>
>
> Hi,
>
>
>
>
>
> Sure hope you can help with this, I have been going around in
>
> circles.
>
>
>
> I am having a problem with the way that Ofbiz calculates tax and
>
> order
>
> totals.
>
>
>
> From what I can gather, the file
>
> './applications/accounting/config/arithmetic.properties' controls the
>
> rounding and digit length for the calculation of taxes & order
>
> totals.
>
>
>
> I am starting to think the changes I make to the file are not being
>
> applied,
>
> I say this because when I look at the 'Unit Price' in an order it
>
> shows
>
> 35.742, rather than 35.74. Which would tend to indicate that settings
>
> are
>
> not being used because the number of decimal points in each of the
>
> settings
>
> in 'arithmetic.properties ' are set to 2 digits. I have pasted in the
>
> contents of the 'arithmetic.properties' file below so you can have a
>
> look. I
>
> have changed the 'rounding' to a different method to try to achieve
>
> the
>
> correct figures.
>
>
>
> There is only a disparity of +0.1 but, technically it is wrong. Ofbiz
>
> keeps
>
> giving me a total of 91.05, but it should be 91.04. I am been given a
>
> hard
>
> time about it...
>
>
>
> Essentially;
>
>
>
> Using Excel;
>
> US$ tax p+tax
>
> Product1 35.74 6.2545 41.995
>
> Product2 35.74 6.2545 41.995
>
> Shipping 6.00 1.050 7.050
>
> Total 77.48 (3 digit)
>
> Tax 13.56 13.559
>
> ------------------------
>
> Grand Total 91.04 91.039
>
>
>
> Simply put, I think that the problem is a combination of two issues;
>
> (i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2
>
> digits).
>
> and
>
> (ii). Uses rounding 'ROUND_HALF_UP', I would tend to use
>
> 'ROUND_HALF_DOWN'.
>
> I think the ' arithmetic.properties' file below, should do the trick.
>
> But it
>
> doesn't seem to being 'applied' to the calculation.
>
>
>
>
>
> So I have two Questions;
>
>
>
> 1). (BIGGEST ISSUE) Do I have to 'activate' the
>
> 'arithmetic.properties'
>
> file, and if so how do I do that? (All I have been doing is clearing
>
> the
>
> cache and logging out then logging in again, as I had been told this
>
> is the
>
> way to do it).
>
> 2). Do you see my point about 94.05 and 94.04, and the best way to
>
> make this
>
> calculation?
>
>
>
>
>
> ---CONTENTS OF---
>
>
>
> .../Ofbiz/trunk/applications/accounting/config/arithmetic.properties
>
>
>
>
>
> #
>
> # 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_DOWN
>
>
>
> # 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_DOWN
>
>
>
> # For setting decimal precision and rounding method of operations
>
> related to
>
> customer accounts
>
> # such as Financial Accounts
>
> finaccount.decimals = 2
>
> finaccount.rounding = ROUND_HALF_DOWN
>
>
>
> # 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_DOWN
>
>
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
>
>
> ________________________________________
>
>
>
> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
>
> Hi Scott,
>
>
>
>
>
> Just strikes me that the file should be 'correct' for everyone. What
>
> would
>
> be your guidance as to what the file should be?
>
>
>
> Appreciate your fast responses this evening. It is 1:15am here in the
>
> UK
>
> just can't stay awake any more.
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
>
>
>
>
> ________________________________________
>
> From: Scott Gray [mailto: lektran@gmail.com]
>
> Sent: 05 April 2007 01:16
>
> To: user@ofbiz.apache.org; peter@ec4b.com
>
>
>
> Subject: Re: Inaccurate Calculation of Order
>
>
>
> Here is the configuration file, you can change the settings to
>
> whatever you
>
> want them to be:
>
>
>
> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/
> config/arit
>
>
> hmetic.properties?view=markup
>
>
>
> From the default settings, it looks like calculation takes place at 3
>
> digits
>
> then gets rounded up to 2 places.
>
>
>
> Regards
>
> Scott
>
> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
>
> Hi,
>
>
>
>
>
> There must be something we are missing here. This can't be a bug,
>
> someone
>
> would have noticed already. Especially something so fundimental.
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
>
>
> -----Original Message-----
>
> From: peter@ec4b.com [mailto: peter@ec4b.com]
>
> Sent: 05 April 2007 00:11
>
> To: 'user@ofbiz.apache.org '
>
> Subject: RE: Inaccurate Calculation of Order
>
> Importance: High
>
>
>
> Hi,
>
>
>
>
>
> Whichever way I work it out the Order Entry system does seem to be
>
> slightly
>
> out.
>
>
>
>
>
> From Excel...
>
>
>
> Price tax 2 digits tax 3 digits tax 9
>
> digits
>
>
>
> Product 1 35.74 6.25 6.255
>
> 6.254500000
>
> Product 2 35.74 6.25 6.255
>
> 6.254500000
>
> shipping 6 1.05 1.050
>
>
>
> === message truncated ===
>
>
>
>
>
>
RE: The Return of...Inaccurate Calculation of Order
Posted by pe...@ec4b.com.
Hi,
I have tried 10 digits, exact same problem.
salestax.calc.decimals = 10
Can anyone offer some assistance.
Thanks & Regards,
Peter
________________________________________
From: Scott Gray [mailto:lektran@gmail.com]
Sent: 18 April 2007 01:27
To: user@ofbiz.apache.org; peter@ec4b.com
Subject: Re: The Return of...Inaccurate Calculation of Order
Peter
Change this line:
salestax.calc.decimals = 10
and see if that gives you the results you are expecting.
Regards
Scott
On 18/04/07, peter@ec4b.com <pe...@ec4b.com> wrote:
Hi,
There is something very odd about the way Ofbiz calculates tax (in the order
manager).
Using this model from Excel;
US$ price tax p+tax
Product1 35.74 6.2545 41.995
Product2 35.74 6.2545 41.995
Shipping 6.00 1.050 7.050
Total 77.48 (3 digit)
Tax 13.56 13.559
-------------------------------------------------
Grand Total 91.04 91.039
Method1 gives 91.05
Method2 gives 91.03
Tried each of the different big-decimal rounding scheme, not give the value
I was expecting (91.04 ). I get either 91.03 or 91.05
>From the arithmetic.properties file;
METHOD1
# 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
METHOD2
# 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 = 3
salestax.final.decimals = 2
salestax.rounding = ROUND_HALF_UP
Thanks & Regards,
Peter
_____
From: Tim Ruppert [mailto:tim.ruppert@hotwaxmedia.com]
Sent: 16 April 2007 19:06
To: user@ofbiz.apache.org
Cc: 'Chris Howe'
Subject: Re: The Return of...Inaccurate Calculation of Order
He means - kill the process - and then restart it. Shut it down and start it
up.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Apr 16, 2007, at 12:02 PM, <pe...@ec4b.com> <pe...@ec4b.com> wrote:
Hi Chris,
Thanks very much for your quick response.
Exactly do you mean by 'restart ofbiz', by your definition?
Thanks & Regards,
Peter
-----Original Message-----
From: Chris Howe [mailto:cjhowe76013@yahoo.com]
Sent: 16 April 2007 18:04
To: user@ofbiz.apache.org ; peter@ec4b.com
Subject: Re: The Return of...Inaccurate Calculation of Order
Hi Peter,
You need to restart OFBiz, not just clear the cache. Hope that helps.
--- peter@ec4b.com wrote:
Hi,
Sure hope you can help with this, I have been going around in
circles.
I am having a problem with the way that Ofbiz calculates tax and
order
totals.
>From what I can gather, the file
'./applications/accounting/config/arithmetic.properties' controls the
rounding and digit length for the calculation of taxes & order
totals.
I am starting to think the changes I make to the file are not being
applied,
I say this because when I look at the 'Unit Price' in an order it
shows
35.742, rather than 35.74. Which would tend to indicate that settings
are
not being used because the number of decimal points in each of the
settings
in 'arithmetic.properties ' are set to 2 digits. I have pasted in the
contents of the 'arithmetic.properties' file below so you can have a
look. I
have changed the 'rounding' to a different method to try to achieve
the
correct figures.
There is only a disparity of +0.1 but, technically it is wrong. Ofbiz
keeps
giving me a total of 91.05, but it should be 91.04. I am been given a
hard
time about it...
Essentially;
Using Excel;
US$ tax p+tax
Product1 35.74 6.2545 41.995
Product2 35.74 6.2545 41.995
Shipping 6.00 1.050 7.050
Total 77.48 (3 digit)
Tax 13.56 13.559
------------------------
Grand Total 91.04 91.039
Simply put, I think that the problem is a combination of two issues;
(i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2
digits).
and
(ii). Uses rounding 'ROUND_HALF_UP', I would tend to use
'ROUND_HALF_DOWN'.
I think the ' arithmetic.properties' file below, should do the trick.
But it
doesn't seem to being 'applied' to the calculation.
So I have two Questions;
1). (BIGGEST ISSUE) Do I have to 'activate' the
'arithmetic.properties'
file, and if so how do I do that? (All I have been doing is clearing
the
cache and logging out then logging in again, as I had been told this
is the
way to do it).
2). Do you see my point about 94.05 and 94.04, and the best way to
make this
calculation?
---CONTENTS OF---
.../Ofbiz/trunk/applications/accounting/config/arithmetic.properties
#
# 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_DOWN
# 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_DOWN
# For setting decimal precision and rounding method of operations
related to
customer accounts
# such as Financial Accounts
finaccount.decimals = 2
finaccount.rounding = ROUND_HALF_DOWN
# 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_DOWN
Thanks & Regards,
Peter
________________________________________
On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
Hi Scott,
Just strikes me that the file should be 'correct' for everyone. What
would
be your guidance as to what the file should be?
Appreciate your fast responses this evening. It is 1:15am here in the
UK
just can't stay awake any more.
Thanks & Regards,
Peter
________________________________________
From: Scott Gray [mailto: lektran@gmail.com]
Sent: 05 April 2007 01:16
To: user@ofbiz.apache.org; peter@ec4b.com
Subject: Re: Inaccurate Calculation of Order
Here is the configuration file, you can change the settings to
whatever you
want them to be:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/arit
hmetic.properties?view=markup
>From the default settings, it looks like calculation takes place at 3
digits
then gets rounded up to 2 places.
Regards
Scott
On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
Hi,
There must be something we are missing here. This can't be a bug,
someone
would have noticed already. Especially something so fundimental.
Thanks & Regards,
Peter
-----Original Message-----
From: peter@ec4b.com [mailto: peter@ec4b.com]
Sent: 05 April 2007 00:11
To: 'user@ofbiz.apache.org '
Subject: RE: Inaccurate Calculation of Order
Importance: High
Hi,
Whichever way I work it out the Order Entry system does seem to be
slightly
out.
>From Excel...
Price tax 2 digits tax 3 digits tax 9
digits
Product 1 35.74 6.25 6.255
6.254500000
Product 2 35.74 6.25 6.255
6.254500000
shipping 6 1.05 1.050
=== message truncated ===
Re: The Return of...Inaccurate Calculation of Order
Posted by Scott Gray <le...@gmail.com>.
Peter
Change this line:
salestax.calc.decimals = 10
and see if that gives you the results you are expecting.
Regards
Scott
On 18/04/07, peter@ec4b.com <pe...@ec4b.com> wrote:
>
> Hi,
>
>
>
>
>
> There is something very odd about the way Ofbiz calculates tax (in the
> order
> manager).
>
>
>
> Using this model from Excel;
>
> US$ price tax p+tax
>
> Product1 35.74 6.2545 41.995
>
> Product2 35.74 6.2545 41.995
>
> Shipping 6.00 1.050 7.050
>
> Total 77.48 (3 digit)
>
> Tax 13.56 13.559
>
> -------------------------------------------------
>
> Grand Total 91.04 91.039
>
>
>
>
>
> Method1 gives 91.05
>
> Method2 gives 91.03
>
>
>
> Tried each of the different big-decimal rounding scheme, not give the
> value
> I was expecting (91.04). I get either 91.03 or 91.05
>
>
>
>
>
> From the arithmetic.properties file;
>
>
>
> METHOD1
>
> # 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
>
>
>
> METHOD2
>
> # 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 = 3
>
> salestax.final.decimals = 2
>
> salestax.rounding = ROUND_HALF_UP
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
> _____
>
> From: Tim Ruppert [mailto:tim.ruppert@hotwaxmedia.com]
> Sent: 16 April 2007 19:06
> To: user@ofbiz.apache.org
> Cc: 'Chris Howe'
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
>
>
> He means - kill the process - and then restart it. Shut it down and start
> it
> up.
>
>
>
>
>
> Cheers,
>
> Tim
>
> --
>
> Tim Ruppert
>
> HotWax Media
>
> http://www.hotwaxmedia.com
>
>
>
> o:801.649.6594
>
> f:801.649.6595
>
>
>
>
>
>
>
> On Apr 16, 2007, at 12:02 PM, <pe...@ec4b.com> <pe...@ec4b.com> wrote:
>
>
>
>
>
> Hi Chris,
>
>
>
>
>
> Thanks very much for your quick response.
>
>
>
> Exactly do you mean by 'restart ofbiz', by your definition?
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
> -----Original Message-----
>
> From: Chris Howe [mailto:cjhowe76013@yahoo.com]
>
> Sent: 16 April 2007 18:04
>
> To: user@ofbiz.apache.org; peter@ec4b.com
>
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
>
>
> Hi Peter,
>
>
>
> You need to restart OFBiz, not just clear the cache. Hope that helps.
>
>
>
>
>
> --- peter@ec4b.com wrote:
>
>
>
> Hi,
>
>
>
>
>
> Sure hope you can help with this, I have been going around in
>
> circles.
>
>
>
> I am having a problem with the way that Ofbiz calculates tax and
>
> order
>
> totals.
>
>
>
> From what I can gather, the file
>
> './applications/accounting/config/arithmetic.properties' controls the
>
> rounding and digit length for the calculation of taxes & order
>
> totals.
>
>
>
> I am starting to think the changes I make to the file are not being
>
> applied,
>
> I say this because when I look at the 'Unit Price' in an order it
>
> shows
>
> 35.742, rather than 35.74. Which would tend to indicate that settings
>
> are
>
> not being used because the number of decimal points in each of the
>
> settings
>
> in 'arithmetic.properties' are set to 2 digits. I have pasted in the
>
> contents of the 'arithmetic.properties' file below so you can have a
>
> look. I
>
> have changed the 'rounding' to a different method to try to achieve
>
> the
>
> correct figures.
>
>
>
> There is only a disparity of +0.1 but, technically it is wrong. Ofbiz
>
> keeps
>
> giving me a total of 91.05, but it should be 91.04. I am been given a
>
> hard
>
> time about it...
>
>
>
> Essentially;
>
>
>
> Using Excel;
>
> US$ tax p+tax
>
> Product1 35.74 6.2545 41.995
>
> Product2 35.74 6.2545 41.995
>
> Shipping 6.00 1.050 7.050
>
> Total 77.48 (3 digit)
>
> Tax 13.56 13.559
>
> ------------------------
>
> Grand Total 91.04 91.039
>
>
>
> Simply put, I think that the problem is a combination of two issues;
>
> (i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2
>
> digits).
>
> and
>
> (ii). Uses rounding 'ROUND_HALF_UP', I would tend to use
>
> 'ROUND_HALF_DOWN'.
>
> I think the 'arithmetic.properties' file below, should do the trick.
>
> But it
>
> doesn't seem to being 'applied' to the calculation.
>
>
>
>
>
> So I have two Questions;
>
>
>
> 1). (BIGGEST ISSUE) Do I have to 'activate' the
>
> 'arithmetic.properties'
>
> file, and if so how do I do that? (All I have been doing is clearing
>
> the
>
> cache and logging out then logging in again, as I had been told this
>
> is the
>
> way to do it).
>
> 2). Do you see my point about 94.05 and 94.04, and the best way to
>
> make this
>
> calculation?
>
>
>
>
>
> ---CONTENTS OF---
>
>
>
> .../Ofbiz/trunk/applications/accounting/config/arithmetic.properties
>
>
>
>
>
> #
>
> # 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_DOWN
>
>
>
> # 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_DOWN
>
>
>
> # For setting decimal precision and rounding method of operations
>
> related to
>
> customer accounts
>
> # such as Financial Accounts
>
> finaccount.decimals = 2
>
> finaccount.rounding = ROUND_HALF_DOWN
>
>
>
> # 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_DOWN
>
>
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
>
>
> ________________________________________
>
>
>
> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
>
> Hi Scott,
>
>
>
>
>
> Just strikes me that the file should be 'correct' for everyone. What
>
> would
>
> be your guidance as to what the file should be?
>
>
>
> Appreciate your fast responses this evening. It is 1:15am here in the
>
> UK
>
> just can't stay awake any more.
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
>
>
>
>
> ________________________________________
>
> From: Scott Gray [mailto: lektran@gmail.com]
>
> Sent: 05 April 2007 01:16
>
> To: user@ofbiz.apache.org; peter@ec4b.com
>
>
>
> Subject: Re: Inaccurate Calculation of Order
>
>
>
> Here is the configuration file, you can change the settings to
>
> whatever you
>
> want them to be:
>
>
>
>
> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/arit
>
> hmetic.properties?view=markup
>
>
>
> From the default settings, it looks like calculation takes place at 3
>
> digits
>
> then gets rounded up to 2 places.
>
>
>
> Regards
>
> Scott
>
> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
>
> Hi,
>
>
>
>
>
> There must be something we are missing here. This can't be a bug,
>
> someone
>
> would have noticed already. Especially something so fundimental.
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
>
>
> -----Original Message-----
>
> From: peter@ec4b.com [mailto: peter@ec4b.com]
>
> Sent: 05 April 2007 00:11
>
> To: 'user@ofbiz.apache.org '
>
> Subject: RE: Inaccurate Calculation of Order
>
> Importance: High
>
>
>
> Hi,
>
>
>
>
>
> Whichever way I work it out the Order Entry system does seem to be
>
> slightly
>
> out.
>
>
>
>
>
> From Excel...
>
>
>
> Price tax 2 digits tax 3 digits tax 9
>
> digits
>
>
>
> Product 1 35.74 6.25 6.255
>
> 6.254500000
>
> Product 2 35.74 6.25 6.255
>
> 6.254500000
>
> shipping 6 1.05 1.050
>
>
>
> === message truncated ===
>
>
>
>
>
>
Re: The Return of...Inaccurate Calculation of Order
Posted by BJ Freeman <bj...@free-man.net>.
if I read this right
Grand Total 91.04 91.039
so if you round to two places on 91.039 you get 91.04
which means they equal.
peter@ec4b.com sent the following on 4/17/2007 4:00 PM:
> Hi,
>
>
>
>
>
> There is something very odd about the way Ofbiz calculates tax (in the order
> manager).
>
>
>
> Using this model from Excel;
>
> US$ price tax p+tax
>
> Product1 35.74 6.2545 41.995
>
> Product2 35.74 6.2545 41.995
>
> Shipping 6.00 1.050 7.050
>
> Total 77.48 (3 digit)
>
> Tax 13.56 13.559
>
> -------------------------------------------------
>
> Grand Total 91.04 91.039
>
>
>
>
>
> Method1 gives 91.05
>
> Method2 gives 91.03
>
>
>
> Tried each of the different big-decimal rounding scheme, not give the value
> I was expecting (91.04). I get either 91.03 or 91.05
>
>
>
>
>
>>>From the arithmetic.properties file;
>
>
>
> METHOD1
>
> # 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
>
>
>
> METHOD2
>
> # 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 = 3
>
> salestax.final.decimals = 2
>
> salestax.rounding = ROUND_HALF_UP
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
> _____
>
> From: Tim Ruppert [mailto:tim.ruppert@hotwaxmedia.com]
> Sent: 16 April 2007 19:06
> To: user@ofbiz.apache.org
> Cc: 'Chris Howe'
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
>
>
> He means - kill the process - and then restart it. Shut it down and start it
> up.
>
>
>
>
>
> Cheers,
>
> Tim
>
> --
>
> Tim Ruppert
>
> HotWax Media
>
> http://www.hotwaxmedia.com
>
>
>
> o:801.649.6594
>
> f:801.649.6595
>
>
>
>
>
>
>
> On Apr 16, 2007, at 12:02 PM, <pe...@ec4b.com> <pe...@ec4b.com> wrote:
>
>
>
>
>
> Hi Chris,
>
>
>
>
>
> Thanks very much for your quick response.
>
>
>
> Exactly do you mean by 'restart ofbiz', by your definition?
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
> -----Original Message-----
>
> From: Chris Howe [mailto:cjhowe76013@yahoo.com]
>
> Sent: 16 April 2007 18:04
>
> To: user@ofbiz.apache.org; peter@ec4b.com
>
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
>
>
> Hi Peter,
>
>
>
> You need to restart OFBiz, not just clear the cache. Hope that helps.
>
>
>
>
>
> --- peter@ec4b.com wrote:
>
>
>
> Hi,
>
>
>
>
>
> Sure hope you can help with this, I have been going around in
>
> circles.
>
>
>
> I am having a problem with the way that Ofbiz calculates tax and
>
> order
>
> totals.
>
>
>
>>>From what I can gather, the file
>
> './applications/accounting/config/arithmetic.properties' controls the
>
> rounding and digit length for the calculation of taxes & order
>
> totals.
>
>
>
> I am starting to think the changes I make to the file are not being
>
> applied,
>
> I say this because when I look at the 'Unit Price' in an order it
>
> shows
>
> 35.742, rather than 35.74. Which would tend to indicate that settings
>
> are
>
> not being used because the number of decimal points in each of the
>
> settings
>
> in 'arithmetic.properties' are set to 2 digits. I have pasted in the
>
> contents of the 'arithmetic.properties' file below so you can have a
>
> look. I
>
> have changed the 'rounding' to a different method to try to achieve
>
> the
>
> correct figures.
>
>
>
> There is only a disparity of +0.1 but, technically it is wrong. Ofbiz
>
> keeps
>
> giving me a total of 91.05, but it should be 91.04. I am been given a
>
> hard
>
> time about it...
>
>
>
> Essentially;
>
>
>
> Using Excel;
>
> US$ tax p+tax
>
> Product1 35.74 6.2545 41.995
>
> Product2 35.74 6.2545 41.995
>
> Shipping 6.00 1.050 7.050
>
> Total 77.48 (3 digit)
>
> Tax 13.56 13.559
>
> ------------------------
>
> Grand Total 91.04 91.039
>
>
>
> Simply put, I think that the problem is a combination of two issues;
>
> (i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2
>
> digits).
>
> and
>
> (ii). Uses rounding 'ROUND_HALF_UP', I would tend to use
>
> 'ROUND_HALF_DOWN'.
>
> I think the 'arithmetic.properties' file below, should do the trick.
>
> But it
>
> doesn't seem to being 'applied' to the calculation.
>
>
>
>
>
> So I have two Questions;
>
>
>
> 1). (BIGGEST ISSUE) Do I have to 'activate' the
>
> 'arithmetic.properties'
>
> file, and if so how do I do that? (All I have been doing is clearing
>
> the
>
> cache and logging out then logging in again, as I had been told this
>
> is the
>
> way to do it).
>
> 2). Do you see my point about 94.05 and 94.04, and the best way to
>
> make this
>
> calculation?
>
>
>
>
>
> ---CONTENTS OF---
>
>
>
> .../Ofbiz/trunk/applications/accounting/config/arithmetic.properties
>
>
>
>
>
> #
>
> # 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_DOWN
>
>
>
> # 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_DOWN
>
>
>
> # For setting decimal precision and rounding method of operations
>
> related to
>
> customer accounts
>
> # such as Financial Accounts
>
> finaccount.decimals = 2
>
> finaccount.rounding = ROUND_HALF_DOWN
>
>
>
> # 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_DOWN
>
>
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
>
>
> ________________________________________
>
>
>
> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
>
> Hi Scott,
>
>
>
>
>
> Just strikes me that the file should be 'correct' for everyone. What
>
> would
>
> be your guidance as to what the file should be?
>
>
>
> Appreciate your fast responses this evening. It is 1:15am here in the
>
> UK
>
> just can't stay awake any more.
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
>
>
>
>
> ________________________________________
>
> From: Scott Gray [mailto: lektran@gmail.com]
>
> Sent: 05 April 2007 01:16
>
> To: user@ofbiz.apache.org; peter@ec4b.com
>
>
>
> Subject: Re: Inaccurate Calculation of Order
>
>
>
> Here is the configuration file, you can change the settings to
>
> whatever you
>
> want them to be:
>
>
>
> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/arit
>
> hmetic.properties?view=markup
>
>
>
>>>From the default settings, it looks like calculation takes place at 3
>
> digits
>
> then gets rounded up to 2 places.
>
>
>
> Regards
>
> Scott
>
> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
>
> Hi,
>
>
>
>
>
> There must be something we are missing here. This can't be a bug,
>
> someone
>
> would have noticed already. Especially something so fundimental.
>
>
>
>
>
> Thanks & Regards,
>
>
>
> Peter
>
>
>
>
>
> -----Original Message-----
>
> From: peter@ec4b.com [mailto: peter@ec4b.com]
>
> Sent: 05 April 2007 00:11
>
> To: 'user@ofbiz.apache.org '
>
> Subject: RE: Inaccurate Calculation of Order
>
> Importance: High
>
>
>
> Hi,
>
>
>
>
>
> Whichever way I work it out the Order Entry system does seem to be
>
> slightly
>
> out.
>
>
>
>
>
>>>From Excel...
>
>
>
> Price tax 2 digits tax 3 digits tax 9
>
> digits
>
>
>
> Product 1 35.74 6.25 6.255
>
> 6.254500000
>
> Product 2 35.74 6.25 6.255
>
> 6.254500000
>
> shipping 6 1.05 1.050
>
>
>
> === message truncated ===
>
>
>
>
>
>
RE: The Return of...Inaccurate Calculation of Order
Posted by pe...@ec4b.com.
Hi,
There is something very odd about the way Ofbiz calculates tax (in the order
manager).
Using this model from Excel;
US$ price tax p+tax
Product1 35.74 6.2545 41.995
Product2 35.74 6.2545 41.995
Shipping 6.00 1.050 7.050
Total 77.48 (3 digit)
Tax 13.56 13.559
-------------------------------------------------
Grand Total 91.04 91.039
Method1 gives 91.05
Method2 gives 91.03
Tried each of the different big-decimal rounding scheme, not give the value
I was expecting (91.04). I get either 91.03 or 91.05
>From the arithmetic.properties file;
METHOD1
# 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
METHOD2
# 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 = 3
salestax.final.decimals = 2
salestax.rounding = ROUND_HALF_UP
Thanks & Regards,
Peter
_____
From: Tim Ruppert [mailto:tim.ruppert@hotwaxmedia.com]
Sent: 16 April 2007 19:06
To: user@ofbiz.apache.org
Cc: 'Chris Howe'
Subject: Re: The Return of...Inaccurate Calculation of Order
He means - kill the process - and then restart it. Shut it down and start it
up.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Apr 16, 2007, at 12:02 PM, <pe...@ec4b.com> <pe...@ec4b.com> wrote:
Hi Chris,
Thanks very much for your quick response.
Exactly do you mean by 'restart ofbiz', by your definition?
Thanks & Regards,
Peter
-----Original Message-----
From: Chris Howe [mailto:cjhowe76013@yahoo.com]
Sent: 16 April 2007 18:04
To: user@ofbiz.apache.org; peter@ec4b.com
Subject: Re: The Return of...Inaccurate Calculation of Order
Hi Peter,
You need to restart OFBiz, not just clear the cache. Hope that helps.
--- peter@ec4b.com wrote:
Hi,
Sure hope you can help with this, I have been going around in
circles.
I am having a problem with the way that Ofbiz calculates tax and
order
totals.
>From what I can gather, the file
'./applications/accounting/config/arithmetic.properties' controls the
rounding and digit length for the calculation of taxes & order
totals.
I am starting to think the changes I make to the file are not being
applied,
I say this because when I look at the 'Unit Price' in an order it
shows
35.742, rather than 35.74. Which would tend to indicate that settings
are
not being used because the number of decimal points in each of the
settings
in 'arithmetic.properties' are set to 2 digits. I have pasted in the
contents of the 'arithmetic.properties' file below so you can have a
look. I
have changed the 'rounding' to a different method to try to achieve
the
correct figures.
There is only a disparity of +0.1 but, technically it is wrong. Ofbiz
keeps
giving me a total of 91.05, but it should be 91.04. I am been given a
hard
time about it...
Essentially;
Using Excel;
US$ tax p+tax
Product1 35.74 6.2545 41.995
Product2 35.74 6.2545 41.995
Shipping 6.00 1.050 7.050
Total 77.48 (3 digit)
Tax 13.56 13.559
------------------------
Grand Total 91.04 91.039
Simply put, I think that the problem is a combination of two issues;
(i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2
digits).
and
(ii). Uses rounding 'ROUND_HALF_UP', I would tend to use
'ROUND_HALF_DOWN'.
I think the 'arithmetic.properties' file below, should do the trick.
But it
doesn't seem to being 'applied' to the calculation.
So I have two Questions;
1). (BIGGEST ISSUE) Do I have to 'activate' the
'arithmetic.properties'
file, and if so how do I do that? (All I have been doing is clearing
the
cache and logging out then logging in again, as I had been told this
is the
way to do it).
2). Do you see my point about 94.05 and 94.04, and the best way to
make this
calculation?
---CONTENTS OF---
.../Ofbiz/trunk/applications/accounting/config/arithmetic.properties
#
# 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_DOWN
# 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_DOWN
# For setting decimal precision and rounding method of operations
related to
customer accounts
# such as Financial Accounts
finaccount.decimals = 2
finaccount.rounding = ROUND_HALF_DOWN
# 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_DOWN
Thanks & Regards,
Peter
________________________________________
On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
Hi Scott,
Just strikes me that the file should be 'correct' for everyone. What
would
be your guidance as to what the file should be?
Appreciate your fast responses this evening. It is 1:15am here in the
UK
just can't stay awake any more.
Thanks & Regards,
Peter
________________________________________
From: Scott Gray [mailto: lektran@gmail.com]
Sent: 05 April 2007 01:16
To: user@ofbiz.apache.org; peter@ec4b.com
Subject: Re: Inaccurate Calculation of Order
Here is the configuration file, you can change the settings to
whatever you
want them to be:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/arit
hmetic.properties?view=markup
>From the default settings, it looks like calculation takes place at 3
digits
then gets rounded up to 2 places.
Regards
Scott
On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
Hi,
There must be something we are missing here. This can't be a bug,
someone
would have noticed already. Especially something so fundimental.
Thanks & Regards,
Peter
-----Original Message-----
From: peter@ec4b.com [mailto: peter@ec4b.com]
Sent: 05 April 2007 00:11
To: 'user@ofbiz.apache.org '
Subject: RE: Inaccurate Calculation of Order
Importance: High
Hi,
Whichever way I work it out the Order Entry system does seem to be
slightly
out.
>From Excel...
Price tax 2 digits tax 3 digits tax 9
digits
Product 1 35.74 6.25 6.255
6.254500000
Product 2 35.74 6.25 6.255
6.254500000
shipping 6 1.05 1.050
=== message truncated ===
Re: The Return of...Inaccurate Calculation of Order
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
He means - kill the process - and then restart it. Shut it down and
start it up.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Apr 16, 2007, at 12:02 PM, <pe...@ec4b.com> <pe...@ec4b.com> wrote:
> Hi Chris,
>
>
> Thanks very much for your quick response.
>
> Exactly do you mean by 'restart ofbiz', by your definition?
>
>
> Thanks & Regards,
>
> Peter
>
> -----Original Message-----
> From: Chris Howe [mailto:cjhowe76013@yahoo.com]
> Sent: 16 April 2007 18:04
> To: user@ofbiz.apache.org; peter@ec4b.com
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
> Hi Peter,
>
> You need to restart OFBiz, not just clear the cache. Hope that helps.
>
>
> --- peter@ec4b.com wrote:
>
>> Hi,
>>
>>
>> Sure hope you can help with this, I have been going around in
>> circles.
>>
>> I am having a problem with the way that Ofbiz calculates tax and
>> order
>> totals.
>>
>> From what I can gather, the file
>> './applications/accounting/config/arithmetic.properties' controls the
>> rounding and digit length for the calculation of taxes & order
>> totals.
>>
>> I am starting to think the changes I make to the file are not being
>> applied,
>> I say this because when I look at the 'Unit Price' in an order it
>> shows
>> 35.742, rather than 35.74. Which would tend to indicate that settings
>> are
>> not being used because the number of decimal points in each of the
>> settings
>> in 'arithmetic.properties' are set to 2 digits. I have pasted in the
>> contents of the 'arithmetic.properties' file below so you can have a
>> look. I
>> have changed the 'rounding' to a different method to try to achieve
>> the
>> correct figures.
>>
>> There is only a disparity of +0.1 but, technically it is wrong. Ofbiz
>> keeps
>> giving me a total of 91.05, but it should be 91.04. I am been given a
>> hard
>> time about it...
>>
>> Essentially;
>>
>> Using Excel;
>> US$ tax p+tax
>> Product1 35.74 6.2545 41.995
>> Product2 35.74 6.2545 41.995
>> Shipping 6.00 1.050 7.050
>> Total 77.48 (3 digit)
>> Tax 13.56 13.559
>> ------------------------
>> Grand Total 91.04 91.039
>>
>> Simply put, I think that the problem is a combination of two issues;
>> (i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2
>> digits).
>> and
>> (ii). Uses rounding 'ROUND_HALF_UP', I would tend to use
>> 'ROUND_HALF_DOWN'.
>> I think the 'arithmetic.properties' file below, should do the trick.
>> But it
>> doesn't seem to being 'applied' to the calculation.
>>
>>
>> So I have two Questions;
>>
>> 1). (BIGGEST ISSUE) Do I have to 'activate' the
>> 'arithmetic.properties'
>> file, and if so how do I do that? (All I have been doing is clearing
>> the
>> cache and logging out then logging in again, as I had been told this
>> is the
>> way to do it).
>> 2). Do you see my point about 94.05 and 94.04, and the best way to
>> make this
>> calculation?
>>
>>
>> ---CONTENTS OF---
>>
>> .../Ofbiz/trunk/applications/accounting/config/arithmetic.properties
>>
>>
>> #
>> # 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_DOWN
>>
>> # 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_DOWN
>>
>> # For setting decimal precision and rounding method of operations
>> related to
>> customer accounts
>> # such as Financial Accounts
>> finaccount.decimals = 2
>> finaccount.rounding = ROUND_HALF_DOWN
>>
>> # 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_DOWN
>>
>>
>>
>> Thanks & Regards,
>>
>> Peter
>>
>>
>> ________________________________________
>>
>> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
>> Hi Scott,
>>
>>
>> Just strikes me that the file should be 'correct' for everyone. What
>> would
>> be your guidance as to what the file should be?
>>
>> Appreciate your fast responses this evening. It is 1:15am here in the
>> UK
>> just can't stay awake any more.
>>
>>
>> Thanks & Regards,
>>
>> Peter
>>
>>
>>
>> ________________________________________
>> From: Scott Gray [mailto: lektran@gmail.com]
>> Sent: 05 April 2007 01:16
>> To: user@ofbiz.apache.org; peter@ec4b.com
>>
>> Subject: Re: Inaccurate Calculation of Order
>>
>> Here is the configuration file, you can change the settings to
>> whatever you
>> want them to be:
>>
> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/
> config/arit
>> hmetic.properties?view=markup
>>
>> From the default settings, it looks like calculation takes place at 3
>> digits
>> then gets rounded up to 2 places.
>>
>> Regards
>> Scott
>> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
>> Hi,
>>
>>
>> There must be something we are missing here. This can't be a bug,
>> someone
>> would have noticed already. Especially something so fundimental.
>>
>>
>> Thanks & Regards,
>>
>> Peter
>>
>>
>> -----Original Message-----
>> From: peter@ec4b.com [mailto: peter@ec4b.com]
>> Sent: 05 April 2007 00:11
>> To: 'user@ofbiz.apache.org '
>> Subject: RE: Inaccurate Calculation of Order
>> Importance: High
>>
>> Hi,
>>
>>
>> Whichever way I work it out the Order Entry system does seem to be
>> slightly
>> out.
>>
>>
>> From Excel...
>>
>> Price tax 2 digits tax 3 digits tax 9
>> digits
>>
>> Product 1 35.74 6.25 6.255
>> 6.254500000
>> Product 2 35.74 6.25 6.255
>> 6.254500000
>> shipping 6 1.05 1.050
>>
> === message truncated ===
>
RE: The Return of...Inaccurate Calculation of Order
Posted by pe...@ec4b.com.
Hi Chris,
Thanks very much for your quick response.
Exactly do you mean by 'restart ofbiz', by your definition?
Thanks & Regards,
Peter
-----Original Message-----
From: Chris Howe [mailto:cjhowe76013@yahoo.com]
Sent: 16 April 2007 18:04
To: user@ofbiz.apache.org; peter@ec4b.com
Subject: Re: The Return of...Inaccurate Calculation of Order
Hi Peter,
You need to restart OFBiz, not just clear the cache. Hope that helps.
--- peter@ec4b.com wrote:
> Hi,
>
>
> Sure hope you can help with this, I have been going around in
> circles.
>
> I am having a problem with the way that Ofbiz calculates tax and
> order
> totals.
>
> From what I can gather, the file
> './applications/accounting/config/arithmetic.properties' controls the
> rounding and digit length for the calculation of taxes & order
> totals.
>
> I am starting to think the changes I make to the file are not being
> applied,
> I say this because when I look at the 'Unit Price' in an order it
> shows
> 35.742, rather than 35.74. Which would tend to indicate that settings
> are
> not being used because the number of decimal points in each of the
> settings
> in 'arithmetic.properties' are set to 2 digits. I have pasted in the
> contents of the 'arithmetic.properties' file below so you can have a
> look. I
> have changed the 'rounding' to a different method to try to achieve
> the
> correct figures.
>
> There is only a disparity of +0.1 but, technically it is wrong. Ofbiz
> keeps
> giving me a total of 91.05, but it should be 91.04. I am been given a
> hard
> time about it...
>
> Essentially;
>
> Using Excel;
> US$ tax p+tax
> Product1 35.74 6.2545 41.995
> Product2 35.74 6.2545 41.995
> Shipping 6.00 1.050 7.050
> Total 77.48 (3 digit)
> Tax 13.56 13.559
> ------------------------
> Grand Total 91.04 91.039
>
> Simply put, I think that the problem is a combination of two issues;
> (i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2
> digits).
> and
> (ii). Uses rounding 'ROUND_HALF_UP', I would tend to use
> 'ROUND_HALF_DOWN'.
> I think the 'arithmetic.properties' file below, should do the trick.
> But it
> doesn't seem to being 'applied' to the calculation.
>
>
> So I have two Questions;
>
> 1). (BIGGEST ISSUE) Do I have to 'activate' the
> 'arithmetic.properties'
> file, and if so how do I do that? (All I have been doing is clearing
> the
> cache and logging out then logging in again, as I had been told this
> is the
> way to do it).
> 2). Do you see my point about 94.05 and 94.04, and the best way to
> make this
> calculation?
>
>
> ---CONTENTS OF---
>
> .../Ofbiz/trunk/applications/accounting/config/arithmetic.properties
>
>
> #
> # 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_DOWN
>
> # 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_DOWN
>
> # For setting decimal precision and rounding method of operations
> related to
> customer accounts
> # such as Financial Accounts
> finaccount.decimals = 2
> finaccount.rounding = ROUND_HALF_DOWN
>
> # 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_DOWN
>
>
>
> Thanks & Regards,
>
> Peter
>
>
> ________________________________________
>
> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
> Hi Scott,
>
>
> Just strikes me that the file should be 'correct' for everyone. What
> would
> be your guidance as to what the file should be?
>
> Appreciate your fast responses this evening. It is 1:15am here in the
> UK
> just can't stay awake any more.
>
>
> Thanks & Regards,
>
> Peter
>
>
>
> ________________________________________
> From: Scott Gray [mailto: lektran@gmail.com]
> Sent: 05 April 2007 01:16
> To: user@ofbiz.apache.org; peter@ec4b.com
>
> Subject: Re: Inaccurate Calculation of Order
>
> Here is the configuration file, you can change the settings to
> whatever you
> want them to be:
>
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/arit
> hmetic.properties?view=markup
>
> From the default settings, it looks like calculation takes place at 3
> digits
> then gets rounded up to 2 places.
>
> Regards
> Scott
> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
> Hi,
>
>
> There must be something we are missing here. This can't be a bug,
> someone
> would have noticed already. Especially something so fundimental.
>
>
> Thanks & Regards,
>
> Peter
>
>
> -----Original Message-----
> From: peter@ec4b.com [mailto: peter@ec4b.com]
> Sent: 05 April 2007 00:11
> To: 'user@ofbiz.apache.org '
> Subject: RE: Inaccurate Calculation of Order
> Importance: High
>
> Hi,
>
>
> Whichever way I work it out the Order Entry system does seem to be
> slightly
> out.
>
>
> From Excel...
>
> Price tax 2 digits tax 3 digits tax 9
> digits
>
> Product 1 35.74 6.25 6.255
> 6.254500000
> Product 2 35.74 6.25 6.255
> 6.254500000
> shipping 6 1.05 1.050
>
=== message truncated ===
Re: The Return of...Inaccurate Calculation of Order
Posted by Chris Howe <cj...@yahoo.com>.
Hi Peter,
You need to restart OFBiz, not just clear the cache. Hope that helps.
--- peter@ec4b.com wrote:
> Hi,
>
>
> Sure hope you can help with this, I have been going around in
> circles.
>
> I am having a problem with the way that Ofbiz calculates tax and
> order
> totals.
>
> From what I can gather, the file
>
/applications/accounting/config/arithmetic.properties controls the
> rounding and digit length for the calculation of taxes & order
> totals.
>
> I am starting to think the changes I make to the file are not being
> applied,
> I say this because when I look at the Unit Price in an order it
> shows
> 35.742, rather than 35.74. Which would tend to indicate that settings
> are
> not being used because the number of decimal points in each of the
> settings
> in arithmetic.properties are set to 2 digits. I have pasted in the
> contents of the arithmetic.properties file below so you can have a
> look. I
> have changed the rounding to a different method to try to achieve
> the
> correct figures.
>
> There is only a disparity of +0.1 but, technically it is wrong. Ofbiz
> keeps
> giving me a total of 91.05, but it should be 91.04. I am been given a
> hard
> time about it...
>
> Essentially;
>
> Using Excel;
> US$ tax p+tax
> Product1 35.74 6.2545 41.995
> Product2 35.74 6.2545 41.995
> Shipping 6.00 1.050 7.050
> Total 77.48 (3 digit)
> Tax 13.56 13.559
> ------------------------
> Grand Total 91.04 91.039
>
> Simply put, I think that the problem is a combination of two issues;
> (i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2
> digits).
> and
> (ii). Uses rounding ROUND_HALF_UP, I would tend to use
> ROUND_HALF_DOWN.
> I think the arithmetic.properties file below, should do the trick.
> But it
> doesnt seem to being applied to the calculation.
>
>
> So I have two Questions;
>
> 1). (BIGGEST ISSUE) Do I have to activate the
> arithmetic.properties
> file, and if so how do I do that? (All I have been doing is clearing
> the
> cache and logging out then logging in again, as I had been told this
> is the
> way to do it).
> 2). Do you see my point about 94.05 and 94.04, and the best way to
> make this
> calculation?
>
>
> ---CONTENTS OF---
>
> .../Ofbiz/trunk/applications/accounting/config/arithmetic.properties
>
>
> #
> # 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_DOWN
>
> # 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_DOWN
>
> # For setting decimal precision and rounding method of operations
> related to
> customer accounts
> # such as Financial Accounts
> finaccount.decimals = 2
> finaccount.rounding = ROUND_HALF_DOWN
>
> # 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_DOWN
>
>
>
> Thanks & Regards,
>
> Peter
>
>
> ________________________________________
>
> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
> Hi Scott,
>
>
> Just strikes me that the file should be 'correct' for everyone. What
> would
> be your guidance as to what the file should be?
>
> Appreciate your fast responses this evening. It is 1:15am here in the
> UK
> just can't stay awake any more.
>
>
> Thanks & Regards,
>
> Peter
>
>
>
> ________________________________________
> From: Scott Gray [mailto: lektran@gmail.com]
> Sent: 05 April 2007 01:16
> To: user@ofbiz.apache.org; peter@ec4b.com
>
> Subject: Re: Inaccurate Calculation of Order
>
> Here is the configuration file, you can change the settings to
> whatever you
> want them to be:
>
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/arit
> hmetic.properties?view=markup
>
> From the default settings, it looks like calculation takes place at 3
> digits
> then gets rounded up to 2 places.
>
> Regards
> Scott
> On 05/04/07, peter@ec4b.com < peter@ec4b.com> wrote:
> Hi,
>
>
> There must be something we are missing here. This can't be a bug,
> someone
> would have noticed already. Especially something so fundimental.
>
>
> Thanks & Regards,
>
> Peter
>
>
> -----Original Message-----
> From: peter@ec4b.com [mailto: peter@ec4b.com]
> Sent: 05 April 2007 00:11
> To: 'user@ofbiz.apache.org '
> Subject: RE: Inaccurate Calculation of Order
> Importance: High
>
> Hi,
>
>
> Whichever way I work it out the Order Entry system does seem to be
> slightly
> out.
>
>
> From Excel...
>
> Price tax 2 digits tax 3 digits tax 9
> digits
>
> Product 1 35.74 6.25 6.255
> 6.254500000
> Product 2 35.74 6.25 6.255
> 6.254500000
> shipping 6 1.05 1.050
>
=== message truncated ===