Hi Peter

Did you try what I suggested?

Change this line:
salestax.calc.decimals = 10
and see if that gives you the results you are expecting.

Regards
Scott

On 18/04/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Hi,

Actually 91.04 is what i need as a result, but i can't seem to get Ofbiz
to reproduce this result. Technically right now Ofbiz is not calculating it
correctly. I have tried most permatations of the big decimal class and a
varying the digit length and mostly get 91.03 or 91.05.

Surely, Ofbiz must be able to calculate the tax (at 17.5%) correctly, it
is such a basic requirement.

I must be overlooking something. Anyone, can you help.


Thanks & Regards,

Peter.


- original message -
Subject:        Re: The Return of...Inaccurate Calculation of Order
From:   "BJ Freeman" <[EMAIL PROTECTED]>
Date:           18/04/2007 02:19

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.

[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
> 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, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
>
> Sent: 16 April 2007 18:04
>
> To: user@ofbiz.apache.org; [EMAIL PROTECTED]
>
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
>
>
> Hi Peter,
>
>
>
> You need to restart OFBiz, not just clear the cache. Hope that helps.
>
>
>
>
>
> --- [EMAIL PROTECTED] 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, [EMAIL PROTECTED] < [EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>
> Sent: 05 April 2007 01:16
>
> To: user@ofbiz.apache.org; [EMAIL PROTECTED]
>
>
>
> 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, [EMAIL PROTECTED] < [EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]
>
> 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 ===
>
>
>
>
>
>


Reply via email to