OFBiz › OFBiz - User

Doesn't calculate tax correctly...Inaccurate Calculation of Order Total

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

29 messages Options

peter-230

Doesn't calculate tax correctly...Inaccurate Calculation of Order Total

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" <[hidden email]>
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.

[hidden email] 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:[hidden email]]
> Sent: 16 April 2007 19:06
> To: [hidden email]
> 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, <[hidden email]> <[hidden email]> 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:[hidden email]]
>
> Sent: 16 April 2007 18:04
>
> To: [hidden email]; [hidden email]
>
> Subject: Re: The Return of...Inaccurate Calculation of Order
>
>
>
> Hi Peter,
>
>
>
> You need to restart OFBiz, not just clear the cache. Hope that helps.
>
>
>
>
>
> --- [hidden email] 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, [hidden email] < [hidden email]> 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: [hidden email]]
>
> Sent: 05 April 2007 01:16
>
> To: [hidden email]; [hidden email]
>
>
>
> 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, [hidden email] < [hidden email]> 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: [hidden email] [mailto: [hidden email]]
>
> Sent: 05 April 2007 00:11
>
> To: '[hidden email] '
>
> 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 ===
>
>
>
>
>
>

Scott Gray

Re: Doesn't calculate tax correctly...Inaccurate Calculation of Order Total

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, [hidden email] <[hidden email]> 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" <[hidden email]>
> 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.
>
> [hidden email] 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:[hidden email]]
> > Sent: 16 April 2007 19:06
> > To: [hidden email]
> > 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, <[hidden email]> <[hidden email]> 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:[hidden email]]
> >
> > Sent: 16 April 2007 18:04
> >
> > To: [hidden email]; [hidden email]
> >
> > Subject: Re: The Return of...Inaccurate Calculation of Order
> >
> >
> >
> > Hi Peter,
> >
> >
> >
> > You need to restart OFBiz, not just clear the cache. Hope that helps.
> >
> >
> >
> >
> >
> > --- [hidden email] 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, [hidden email] < [hidden email]> 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: [hidden email]]
> >
> > Sent: 05 April 2007 01:16
> >
> > To: [hidden email]; [hidden email]
> >
> >
> >
> > 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, [hidden email] < [hidden email]> 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: [hidden email] [mailto: [hidden email]]
> >
> > Sent: 05 April 2007 00:11
> >
> > To: '[hidden email] '
> >
> > 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 ===
> >
> >
> >
> >
> >
> >
>
>

peter-230

Will Pay US$500 for a Solution to a basic tax calculation issue

Hi,

Ofbiz must be capable of calculating tax or vat correctly (the term vat is
used in the UK to describe tax on goods, tax at a rate of 17.5%).

TO BE CLEAR;
THE CALCULATION OF TAX IS THE PROBLEM.
THE CALCULATION OF PRODUCTS IS CORRECT.

'arithmetic.properties' is the file I have been working with. Essentially
there are three parameters I have looked at that control the rounding and
length of decimals used with regards to calculation of tax or vat.

salestax.calc.decimals = 3
salestax.final.decimals = 2
salestax.rounding = ROUND_HALF_UP

It is safe to say that I have tried every combination of 'Big Decimal'
rounding field types and 'decimals' length (for salestax.calc.decimals and
salestax.final.decimals) without any success!

I have of course been stopping and restarting the server after each change
to reload the file at startup. Even tried some crazy wild figures just to
ensure that I was getting a different figure, to ensure the process works.

Therefore, there must be other files that also have some bearing on this
calculation. Does anyone know what other files maybe relevant?

VERY HAPPY TO PAY SOMEONE 'US$500' for a solution at this point. On
condition that the solution actually works and produces the figures below,
only one payment to the first working model will be paid;

-------------------------------------------------
price tax product+tax
-------------------------------------------------
Product1 35.74 6.2545 41.995
Product2 35.74 6.2545 41.995
-------------------------------------------------
Product Total 71.48
Shipping 6.00 1.050 7.050
Tax (17.5%) 13.56 13.559
-------------------------------------------------
Grand Total 91.04 91.039
-------------------------------------------------

Let's see if someone can prove to me that Ofbiz is capable of calculating
vat correctly. Had this issue open is various threads for around a month.

Thanks & Regards,

Peter

-----Original Message-----
From: Scott Gray [mailto:[hidden email]]
Sent: 18 April 2007 10:50
To: [hidden email]
Subject: Re: Doesn't calculate tax correctly...Inaccurate Calculation of
Order Total

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, [hidden email] <[hidden email]> 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" <[hidden email]>
> 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.
>
> [hidden email] 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:[hidden email]]
> > Sent: 16 April 2007 19:06
> > To: [hidden email]
> > 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, <[hidden email]> <[hidden email]> 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:[hidden email]]
> >
> > Sent: 16 April 2007 18:04
> >
> > To: [hidden email]; [hidden email]
> >
> > Subject: Re: The Return of...Inaccurate Calculation of Order
> >
> >
> >
> > Hi Peter,
> >
> >
> >
> > You need to restart OFBiz, not just clear the cache. Hope that helps.
> >
> >
> >
> >
> >
> > --- [hidden email] 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, [hidden email] < [hidden email]> 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: [hidden email]]
> >
> > Sent: 05 April 2007 01:16
> >
> > To: [hidden email]; [hidden email]
> >
> >
> >
> > 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, [hidden email] < [hidden email]> 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: [hidden email] [mailto: [hidden email]]
> >
> > Sent: 05 April 2007 00:11
> >
> > To: '[hidden email] '
> >
> > 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 ===
> >
> >
> >
> >
> >
> >
>
>

cjhowe

Re: Will Pay US$500 for a Solution to a basic tax calculation issue

For those interested in Peter's challenge, IIRC, his total was ending
up at 91.03 or 91.05, depending on the arithmetic rules. he is
expecting 91.04. If someone could verify the following behavior, you
may claim his prize :) . (I don't have time at the moment to actually
dig for this occurrence, but if someone wanted to share, I wouldn't
complain...i wouldn't complain if they didn't want to share either ;-)
)

Since math is rather straight forward (assuming this is all
bigdecimal), there are only a few scenarios that can exist to give
these numbers.

::91.03::
Tax line item
round lineItemTax to two significant digits
Add each lineItemTax

::91.05::
Tax line item
round lineItemTax to three significant digits
add lineItemTax to line Item
round lineItemTotal to two significant digits
sum lineItemTotals

Applying the rules from 91.05 to two significant digits, you will get
the 91.03 as well.

The expected summation is as follows:
Tax line item
round lineItemTax to x significant digits.
sum all lineItemTax
add lineItemTaxTotal to lineItemTotal
round to two significant digits (cents)
This will produce the expected 91.04

--- [hidden email] wrote:

> Hi,
>
>
> Ofbiz must be capable of calculating tax or vat correctly (the term
> vat is
> used in the UK to describe tax on goods, tax at a rate of 17.5%).
>
> TO BE CLEAR;
> THE CALCULATION OF TAX IS THE PROBLEM.
> THE CALCULATION OF PRODUCTS IS CORRECT.
>
> 'arithmetic.properties' is the file I have been working with.
> Essentially
> there are three parameters I have looked at that control the rounding
> and
> length of decimals used with regards to calculation of tax or vat.
>
> salestax.calc.decimals = 3
> salestax.final.decimals = 2
> salestax.rounding = ROUND_HALF_UP
>
> It is safe to say that I have tried every combination of 'Big
> Decimal'
> rounding field types and 'decimals' length (for
> salestax.calc.decimals and
> salestax.final.decimals) without any success!
>
> I have of course been stopping and restarting the server after each
> change
> to reload the file at startup. Even tried some crazy wild figures
> just to
> ensure that I was getting a different figure, to ensure the process
> works.
>
> Therefore, there must be other files that also have some bearing on
> this
> calculation. Does anyone know what other files maybe relevant?
>
>
> VERY HAPPY TO PAY SOMEONE 'US$500' for a solution at this point. On
> condition that the solution actually works and produces the figures
> below,
> only one payment to the first working model will be paid;
>
> -------------------------------------------------
> price tax product+tax
> -------------------------------------------------
> Product1 35.74 6.2545 41.995
> Product2 35.74 6.2545 41.995
> -------------------------------------------------
> Product Total 71.48
> Shipping 6.00 1.050 7.050
> Tax (17.5%) 13.56 13.559
> -------------------------------------------------
> Grand Total 91.04 91.039
> -------------------------------------------------
>
>
> Let's see if someone can prove to me that Ofbiz is capable of
> calculating
> vat correctly. Had this issue open is various threads for around a
> month.
>
>
>
> Thanks & Regards,
>
> Peter
>
>
> -----Original Message-----
> From: Scott Gray [mailto:[hidden email]]
> Sent: 18 April 2007 10:50
> To: [hidden email]
> Subject: Re: Doesn't calculate tax correctly...Inaccurate Calculation
> of
> Order Total
>
> 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, [hidden email] <[hidden email]> 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" <[hidden email]>
> > 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.
> >
> > [hidden email] 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
>

=== message truncated ===

peter-230

Company Name - Order Confirmation #${orderid}

Hi,

In the 'Catalog Manager' in 'Stores' you can configure your 'email
confirmation' details, the documentation suggests using 'Company Name -
Order Confirmation #${orderid}'

However, when you use this syntax the E-Mail Subject comes out as 'Company
Name - Order Confirmation #${orderid}'

It seems like the '#${orderid}' syntax is wrong, any suggestions, anyone.

Thanks & Regards,

Peter

David E Jones

Re: Company Name - Order Confirmation #${orderid}

Where does the documentation say that? It looks like it is incorrect
because the "i" in "orderid" should be a capital, ie "orderId".

-David

On Apr 27, 2007, at 9:05 PM, <[hidden email]> wrote:

> Hi,
>
>
> In the 'Catalog Manager' in 'Stores' you can configure your 'email
> confirmation' details, the documentation suggests using 'Company
> Name -
> Order Confirmation #${orderid}'
>
> However, when you use this syntax the E-Mail Subject comes out as
> 'Company
> Name - Order Confirmation #${orderid}'
>
> It seems like the '#${orderid}' syntax is wrong, any suggestions,
> anyone.
>
>
> Thanks & Regards,
>
> Peter
>
>
>

smime.p7s (3K) Download Attachment

Scott Gray

Re: Will Pay US$500 for a Solution to a basic tax calculation issue

In reply to this post by cjhowe

From looking at the code, the tax is always calculated and rounded to 2
decimal places for each order (and invoice) line, so there is no way to get
a grand total of $91.04 regardless of what settings you place in
arithmetic.properties.

Your only solution would be to refactor quite of lot of code to support
calculating tax on the final taxable subtotal.

Regards
Scott

On 28/04/07, Chris Howe <[hidden email]> wrote:

>
> For those interested in Peter's challenge, IIRC, his total was ending
> up at 91.03 or 91.05, depending on the arithmetic rules. he is
> expecting 91.04. If someone could verify the following behavior, you
> may claim his prize :) . (I don't have time at the moment to actually
> dig for this occurrence, but if someone wanted to share, I wouldn't
> complain...i wouldn't complain if they didn't want to share either ;-)
> )
>
> Since math is rather straight forward (assuming this is all
> bigdecimal), there are only a few scenarios that can exist to give
> these numbers.
>
> ::91.03::
> Tax line item
> round lineItemTax to two significant digits
> Add each lineItemTax
>
> ::91.05::
> Tax line item
> round lineItemTax to three significant digits
> add lineItemTax to line Item
> round lineItemTotal to two significant digits
> sum lineItemTotals
>
>
> Applying the rules from 91.05 to two significant digits, you will get
> the 91.03 as well.
>
> The expected summation is as follows:
> Tax line item
> round lineItemTax to x significant digits.
> sum all lineItemTax
> add lineItemTaxTotal to lineItemTotal
> round to two significant digits (cents)
> This will produce the expected 91.04
>
>
> --- [hidden email] wrote:
>
> > Hi,
> >
> >
> > Ofbiz must be capable of calculating tax or vat correctly (the term
> > vat is
> > used in the UK to describe tax on goods, tax at a rate of 17.5%).
> >
> > TO BE CLEAR;
> > THE CALCULATION OF TAX IS THE PROBLEM.
> > THE CALCULATION OF PRODUCTS IS CORRECT.
> >
> > 'arithmetic.properties' is the file I have been working with.
> > Essentially
> > there are three parameters I have looked at that control the rounding
> > and
> > length of decimals used with regards to calculation of tax or vat.
> >
> > salestax.calc.decimals = 3
> > salestax.final.decimals = 2
> > salestax.rounding = ROUND_HALF_UP
> >
> > It is safe to say that I have tried every combination of 'Big
> > Decimal'
> > rounding field types and 'decimals' length (for
> > salestax.calc.decimals and
> > salestax.final.decimals) without any success!
> >
> > I have of course been stopping and restarting the server after each
> > change
> > to reload the file at startup. Even tried some crazy wild figures
> > just to
> > ensure that I was getting a different figure, to ensure the process
> > works.
> >
> > Therefore, there must be other files that also have some bearing on
> > this
> > calculation. Does anyone know what other files maybe relevant?
> >
> >
> > VERY HAPPY TO PAY SOMEONE 'US$500' for a solution at this point. On
> > condition that the solution actually works and produces the figures
> > below,
> > only one payment to the first working model will be paid;
> >
> > -------------------------------------------------
> > price tax product+tax
> > -------------------------------------------------
> > Product1 35.74 6.2545 41.995
> > Product2 35.74 6.2545 41.995
> > -------------------------------------------------
> > Product Total 71.48
> > Shipping 6.00 1.050 7.050
> > Tax (17.5%) 13.56 13.559
> > -------------------------------------------------
> > Grand Total 91.04 91.039
> > -------------------------------------------------
> >
> >
> > Let's see if someone can prove to me that Ofbiz is capable of
> > calculating
> > vat correctly. Had this issue open is various threads for around a
> > month.
> >
> >
> >
> > Thanks & Regards,
> >
> > Peter
> >
> >
> > -----Original Message-----
> > From: Scott Gray [mailto:[hidden email]]
> > Sent: 18 April 2007 10:50
> > To: [hidden email]
> > Subject: Re: Doesn't calculate tax correctly...Inaccurate Calculation
> > of
> > Order Total
> >
> > 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, [hidden email] <[hidden email]> 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" <[hidden email]>
> > > 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.
> > >
> > > [hidden email] 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
> >
> === message truncated ===
>
>

David E Jones

Re: Will Pay US$500 for a Solution to a basic tax calculation issue

This is something that needs to be fixed. One of the requirements
that I modeled with the TaxAuthority stuff was a common VAT
requirement of calculating tax to 3 decimals for each item/line in an
order and then summing it all, and then rounding it to 2 decimals.

It sounds like this has still not been implemented. Still, $500 may
cover it if someone is interested... If we weren't so busy right now
I'd get one of our guys working on it.

-David

On Apr 27, 2007, at 10:55 PM, Scott Gray wrote:

> From looking at the code, the tax is always calculated and rounded
> to 2
> decimal places for each order (and invoice) line, so there is no
> way to get
> a grand total of $91.04 regardless of what settings you place in
> arithmetic.properties.
>
> Your only solution would be to refactor quite of lot of code to
> support
> calculating tax on the final taxable subtotal.
>
> Regards
> Scott
>
> On 28/04/07, Chris Howe <[hidden email]> wrote:
>>
>> For those interested in Peter's challenge, IIRC, his total was ending
>> up at 91.03 or 91.05, depending on the arithmetic rules. he is
>> expecting 91.04. If someone could verify the following behavior, you
>> may claim his prize :) . (I don't have time at the moment to
>> actually
>> dig for this occurrence, but if someone wanted to share, I wouldn't
>> complain...i wouldn't complain if they didn't want to share
>> either ;-)
>> )
>>
>> Since math is rather straight forward (assuming this is all
>> bigdecimal), there are only a few scenarios that can exist to give
>> these numbers.
>>
>> ::91.03::
>> Tax line item
>> round lineItemTax to two significant digits
>> Add each lineItemTax
>>
>> ::91.05::
>> Tax line item
>> round lineItemTax to three significant digits
>> add lineItemTax to line Item
>> round lineItemTotal to two significant digits
>> sum lineItemTotals
>>
>>
>> Applying the rules from 91.05 to two significant digits, you will get
>> the 91.03 as well.
>>
>> The expected summation is as follows:
>> Tax line item
>> round lineItemTax to x significant digits.
>> sum all lineItemTax
>> add lineItemTaxTotal to lineItemTotal
>> round to two significant digits (cents)
>> This will produce the expected 91.04
>>
>>
>> --- [hidden email] wrote:
>>
>> > Hi,
>> >
>> >
>> > Ofbiz must be capable of calculating tax or vat correctly (the term
>> > vat is
>> > used in the UK to describe tax on goods, tax at a rate of 17.5%).
>> >
>> > TO BE CLEAR;
>> > THE CALCULATION OF TAX IS THE PROBLEM.
>> > THE CALCULATION OF PRODUCTS IS CORRECT.
>> >
>> > 'arithmetic.properties' is the file I have been working with.
>> > Essentially
>> > there are three parameters I have looked at that control the
>> rounding
>> > and
>> > length of decimals used with regards to calculation of tax or vat.
>> >
>> > salestax.calc.decimals = 3
>> > salestax.final.decimals = 2
>> > salestax.rounding = ROUND_HALF_UP
>> >
>> > It is safe to say that I have tried every combination of 'Big
>> > Decimal'
>> > rounding field types and 'decimals' length (for
>> > salestax.calc.decimals and
>> > salestax.final.decimals) without any success!
>> >
>> > I have of course been stopping and restarting the server after each
>> > change
>> > to reload the file at startup. Even tried some crazy wild figures
>> > just to
>> > ensure that I was getting a different figure, to ensure the process
>> > works.
>> >
>> > Therefore, there must be other files that also have some bearing on
>> > this
>> > calculation. Does anyone know what other files maybe relevant?
>> >
>> >
>> > VERY HAPPY TO PAY SOMEONE 'US$500' for a solution at this point. On
>> > condition that the solution actually works and produces the figures
>> > below,
>> > only one payment to the first working model will be paid;
>> >
>> > -------------------------------------------------
>> > price tax product+tax
>> > -------------------------------------------------
>> > Product1 35.74 6.2545 41.995
>> > Product2 35.74 6.2545 41.995
>> > -------------------------------------------------
>> > Product Total 71.48
>> > Shipping 6.00 1.050 7.050
>> > Tax (17.5%) 13.56 13.559
>> > -------------------------------------------------
>> > Grand Total 91.04 91.039
>> > -------------------------------------------------
>> >
>> >
>> > Let's see if someone can prove to me that Ofbiz is capable of
>> > calculating
>> > vat correctly. Had this issue open is various threads for around a
>> > month.
>> >
>> >
>> >
>> > Thanks & Regards,
>> >
>> > Peter
>> >
>> >
>> > -----Original Message-----
>> > From: Scott Gray [mailto:[hidden email]]
>> > Sent: 18 April 2007 10:50
>> > To: [hidden email]
>> > Subject: Re: Doesn't calculate tax correctly...Inaccurate
>> Calculation
>> > of
>> > Order Total
>> >
>> > 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, [hidden email] <[hidden email]> 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" <[hidden email]>
>> > > 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.
>> > >
>> > > [hidden email] 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
>> >
>> === message truncated ===
>>
>>

smime.p7s (3K) Download Attachment

peter-230

RE: Company Name - Order Confirmation #${orderid}

In reply to this post by David E Jones

Hi,

My mistake your quite right David.

Thanks & Regards,

Peter

-----Original Message-----
From: David E. Jones [mailto:[hidden email]]
Sent: 28 April 2007 04:44
To: [hidden email]
Subject: Re: Company Name - Order Confirmation #${orderid}
Importance: High

Where does the documentation say that? It looks like it is incorrect
because the "i" in "orderid" should be a capital, ie "orderId".

-David

On Apr 27, 2007, at 9:05 PM, <[hidden email]> wrote:

peter-230

RE: Will Pay US$500 for a Solution to a basic tax calculation issue

In reply to this post by Scott Gray

Hi,

Well that is indeed what needs to be done because, currently the fact of the
matter is that the figure is not worked out correctly.

See David's response.

Thanks & Regards,

Peter

-----Original Message-----
From: Scott Gray [mailto:[hidden email]]
Sent: 28 April 2007 05:56
To: [hidden email]
Subject: Re: Will Pay US$500 for a Solution to a basic tax calculation issue

From looking at the code, the tax is always calculated and rounded to 2
decimal places for each order (and invoice) line, so there is no way to get
a grand total of $91.04 regardless of what settings you place in
arithmetic.properties.

Your only solution would be to refactor quite of lot of code to support
calculating tax on the final taxable subtotal.

Regards
Scott

On 28/04/07, Chris Howe <[hidden email]> wrote:

Scott Gray

Re: Will Pay US$500 for a Solution to a basic tax calculation issue

Hi Peter

I've attached a patch file which should address the issues for your problem calculation. You will need to download the latest revision of Ofbiz (not opentaps) and apply the patch. Make sure you do this before running "ant run-install" as there is a small change to the data model.

Regards
Scott

On 29/04/07, [hidden email] <[hidden email]> wrote:

Hi,

Well that is indeed what needs to be done because, currently the fact of the
matter is that the figure is not worked out correctly.

See David's response.

Thanks & Regards,

Peter

-----Original Message-----
From: Scott Gray [mailto:[hidden email]]
Sent: 28 April 2007 05:56
To: [hidden email]
Subject: Re: Will Pay US$500 for a Solution to a basic tax calculation issue

From looking at the code, the tax is always calculated and rounded to 2
decimal places for each order (and invoice) line, so there is no way to get
a grand total of $91.04 regardless of what settings you place in
arithmetic.properties.

Your only solution would be to refactor quite of lot of code to support
calculating tax on the final taxable subtotal.

Regards
Scott

On 28/04/07, Chris Howe <[hidden email]> wrote:

>
> For those interested in Peter's challenge, IIRC, his total was ending
> up at 91.03 or 91.05, depending on the arithmetic rules.  he is
> expecting 91.04.  If someone could verify the following behavior, you
> may claim his prize :) .  (I don't have time at the moment to actually
> dig for this occurrence, but if someone wanted to share, I wouldn't
> complain...i wouldn't complain if they didn't want to share either ;-)
> )
>
> Since math is rather straight forward (assuming this is all
> bigdecimal), there are only a few scenarios that can exist to give
> these numbers.
>
> ::91.03::
> Tax line item
> round lineItemTax to two significant digits
> Add each lineItemTax
>
> ::91.05::
> Tax line item
> round lineItemTax to three significant digits
> add lineItemTax to line Item
> round lineItemTotal to two significant digits
> sum lineItemTotals
>

>
> Applying the rules from 91.05 to two significant digits, you will get
> the 91.03 as well.
>
> The expected summation is as follows:
> Tax line item
> round lineItemTax to x significant digits.
> sum all lineItemTax
> add lineItemTaxTotal to lineItemTotal
> round to two significant digits (cents)
> This will produce the expected 91.04
>
>
> --- [hidden email] wrote:
>
> > Hi,
> >
> >
> > Ofbiz must be capable of calculating tax or vat correctly (the term
> > vat is
> > used in the UK to describe tax on goods, tax at a rate of 17.5%).
> >
> > TO BE CLEAR;
> > THE CALCULATION OF TAX IS THE PROBLEM.
> > THE CALCULATION OF PRODUCTS IS CORRECT.
> >
> > 'arithmetic.properties' is the file I have been working with.
> > Essentially
> > there are three parameters I have looked at that control the rounding
> > and
> > length of decimals used with regards to calculation of tax or vat.
> >
> > salestax.calc.decimals = 3

> > salestax.final.decimals = 2
> > salestax.rounding = ROUND_HALF_UP
> >
> > It is safe to say that I have tried every combination of 'Big
> > Decimal'
> > rounding field types and 'decimals' length (for
> > salestax.calc.decimals and
> > salestax.final.decimals) without any success!
> >
> > I have of course been stopping and restarting the server after each
> > change
> > to reload the file at startup. Even tried some crazy wild figures
> > just to
> > ensure that I was getting a different figure, to ensure the process
> > works.
> >
> > Therefore, there must be other files that also have some bearing on
> > this
> > calculation. Does anyone know what other files maybe relevant?
> >
> >
> > VERY HAPPY TO PAY SOMEONE 'US$500' for a solution at this point. On
> > condition that the solution actually works and produces the figures
> > below,
> > only one payment to the first working model will be paid;
> >
> > -------------------------------------------------
> >                    price    tax      product+tax
> > -------------------------------------------------
> > Product1           35.74    6.2545   41.995
> > Product2           35.74     6.2545   41.995
> > -------------------------------------------------
> > Product Total      71.48
> > Shipping            6.00    1.050    7.050
> > Tax (17.5%)        13.56    13.559
> > -------------------------------------------------

> > Grand Total        91.04    91.039
> > -------------------------------------------------
> >
> >
> > Let's see if someone can prove to me that Ofbiz is capable of
> > calculating
> > vat correctly. Had this issue open is various threads for around a
> > month.
> >
> >
> >
> > Thanks & Regards,
> >
> > Peter
> >
> >
> > -----Original Message-----
> > From: Scott Gray [mailto:[hidden email]]
> > Sent: 18 April 2007 10:50
> > To: [hidden email]
> > Subject: Re: Doesn't calculate tax correctly...Inaccurate Calculation
> > of
> > Order Total
> >
> > 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, [hidden email] <[hidden email]> 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" <[hidden email]>
> > > 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.
> > >
> > > [hidden email] 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
> >
> === message truncated ===
>
>

taxRounding.patch (20K) Download Attachment

Jacopo Cappellato

Re: Will Pay US$500 for a Solution to a basic tax calculation issue

Hey Scott,

it seems you have won the 500$ prize!
Peter, is it tax included? ;-)

Jacopo

Scott Gray wrote:

peter-230

RE: Will Pay US$500 for a Solution to a basic tax calculation issue

In reply to this post by Scott Gray

Hi Scott,

Thanks for your help, will test the file now. Midnight here, hope to let you
know in the next ouple of hours if it worked.

Thanks & Regards,

Peter

_____

From: Scott Gray [mailto:[hidden email]]
Sent: 28 April 2007 21:46
To: [hidden email]; [hidden email]
Subject: Re: Will Pay US$500 for a Solution to a basic tax calculation issue

Hi Peter

I've attached a patch file which should address the issues for your problem
calculation. You will need to download the latest revision of Ofbiz (not
opentaps) and apply the patch. Make sure you do this before running "ant
run-install" as there is a small change to the data model.

Regards
Scott

On 29/04/07, [hidden email] <[hidden email]> wrote:

Hi,

Well that is indeed what needs to be done because, currently the fact of the

matter is that the figure is not worked out correctly.

See David's response.

Thanks & Regards,

Peter

-----Original Message-----
From: Scott Gray [mailto: [hidden email] <mailto:[hidden email]> ]
Sent: 28 April 2007 05:56
To: [hidden email]
Subject: Re: Will Pay US$500 for a Solution to a basic tax calculation issue

From looking at the code, the tax is always calculated and rounded to 2
decimal places for each order (and invoice) line, so there is no way to get
a grand total of $91.04 regardless of what settings you place in
arithmetic.properties.

Your only solution would be to refactor quite of lot of code to support
calculating tax on the final taxable subtotal.

Regards
Scott

On 28/04/07, Chris Howe <[hidden email]> wrote:

<mailto:[hidden email]> >

> > > 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.
> > >
> > > [hidden email] 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
> >
> === message truncated ===
>
>

David E Jones

Re: Will Pay US$500 for a Solution to a basic tax calculation issue

In reply to this post by Scott Gray

Scott,

Did this ever make it into OFBiz? I only reviewed it briefly, but if it is fixing this problem then it would be great to have it in the ofbiz trunk.

-David

Scott Gray wrote:

> Hi Peter
>
> I've attached a patch file which should address the issues for your
> problem calculation. You will need to download the latest revision of
> Ofbiz (not opentaps) and apply the patch. Make sure you do this before
> running "ant run-install" as there is a small change to the data model.
>
> Regards
> Scott
>
> On 29/04/07, *[hidden email] <mailto:[hidden email]>* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Hi,
>
>
> Well that is indeed what needs to be done because, currently the
> fact of the
> matter is that the figure is not worked out correctly.
>
> See David's response.
>
>
> Thanks & Regards,
>
> Peter
>
>
> -----Original Message-----
> From: Scott Gray [mailto: [hidden email] <mailto:[hidden email]>]
> Sent: 28 April 2007 05:56
> To: [hidden email] <mailto:[hidden email]>
> Subject: Re: Will Pay US$500 for a Solution to a basic tax
> calculation issue
>
> From looking at the code, the tax is always calculated and rounded
> to 2
> decimal places for each order (and invoice) line, so there is no way
> to get
> a grand total of $91.04 regardless of what settings you place in
> arithmetic.properties.
>
> Your only solution would be to refactor quite of lot of code to support
> calculating tax on the final taxable subtotal.
>
> Regards
> Scott
>
> On 28/04/07, Chris Howe <[hidden email]
> <mailto:[hidden email]>> wrote:
> >
> > For those interested in Peter's challenge, IIRC, his total was
> ending
> > up at 91.03 or 91.05, depending on the arithmetic rules. he is
> > expecting 91.04. If someone could verify the following behavior, you
> > may claim his prize :) . (I don't have time at the moment to
> actually
> > dig for this occurrence, but if someone wanted to share, I wouldn't
> > complain...i wouldn't complain if they didn't want to share
> either ;-)
> > )
> >
> > Since math is rather straight forward (assuming this is all
> > bigdecimal), there are only a few scenarios that can exist to give
> > these numbers.
> >
> > ::91.03::
> > Tax line item
> > round lineItemTax to two significant digits
> > Add each lineItemTax
> >
> > ::91.05::
> > Tax line item
> > round lineItemTax to three significant digits
> > add lineItemTax to line Item
> > round lineItemTotal to two significant digits
> > sum lineItemTotals
> >
> >
> > Applying the rules from 91.05 to two significant digits, you will get
> > the 91.03 as well.
> >
> > The expected summation is as follows:
> > Tax line item
> > round lineItemTax to x significant digits.
> > sum all lineItemTax
> > add lineItemTaxTotal to lineItemTotal
> > round to two significant digits (cents)
> > This will produce the expected 91.04
> >
> >
> > --- [hidden email] <mailto:[hidden email]> wrote:
> >
> > > Hi,
> > >
> > >
> > > Ofbiz must be capable of calculating tax or vat correctly (the term
> > > vat is
> > > used in the UK to describe tax on goods, tax at a rate of 17.5%).
> > >
> > > TO BE CLEAR;
> > > THE CALCULATION OF TAX IS THE PROBLEM.
> > > THE CALCULATION OF PRODUCTS IS CORRECT.
> > >
> > > 'arithmetic.properties' is the file I have been working with.
> > > Essentially
> > > there are three parameters I have looked at that control the
> rounding
> > > and
> > > length of decimals used with regards to calculation of tax or vat.
> > >
> > > salestax.calc.decimals = 3
> > > salestax.final.decimals = 2
> > > salestax.rounding = ROUND_HALF_UP
> > >
> > > It is safe to say that I have tried every combination of 'Big
> > > Decimal'
> > > rounding field types and 'decimals' length (for
> > > salestax.calc.decimals and
> > > salestax.final.decimals) without any success!
> > >
> > > I have of course been stopping and restarting the server after
> each
> > > change
> > > to reload the file at startup. Even tried some crazy wild figures
> > > just to
> > > ensure that I was getting a different figure, to ensure the process
> > > works.
> > >
> > > Therefore, there must be other files that also have some bearing on
> > > this
> > > calculation. Does anyone know what other files maybe relevant?
> > >
> > >
> > > VERY HAPPY TO PAY SOMEONE 'US$500' for a solution at this
> point. On
> > > condition that the solution actually works and produces the figures
> > > below,
> > > only one payment to the first working model will be paid;
> > >
> > > -------------------------------------------------
> > > price tax product+tax
> > > -------------------------------------------------
> > > Product1 35.74 6.2545 41.995
> > > Product2 35.74 6.2545 41.995
> > > -------------------------------------------------
> > > Product Total 71.48
> > > Shipping 6.00 1.050 7.050
> > > Tax (17.5%) 13.56 13.559
> > > -------------------------------------------------
> > > Grand Total 91.04 91.039
> > > -------------------------------------------------
> > >
> > >
> > > Let's see if someone can prove to me that Ofbiz is capable of
> > > calculating
> > > vat correctly. Had this issue open is various threads for around a
> > > month.
> > >
> > >
> > >
> > > Thanks & Regards,
> > >
> > > Peter
> > >
> > >
> > > -----Original Message-----
> > > From: Scott Gray [mailto:[hidden email]
> <mailto:[hidden email]>]
> > > Sent: 18 April 2007 10:50
> > > To: [hidden email] <mailto:[hidden email]>
> > > Subject: Re: Doesn't calculate tax correctly...Inaccurate
> Calculation
> > > of
> > > Order Total
> > >
> > > 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, [hidden email] <mailto:[hidden email]>
> <[hidden email] <mailto:[hidden email]>> 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" < [hidden email]
> <mailto:[hidden email]>>
> > > > 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.
> > > >
> > > > [hidden email] <mailto:[hidden email]> 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
> > >
> > === message truncated ===
> >
> >
>
>

Jacopo Cappellato

Re: Will Pay US$500 for a Solution to a basic tax calculation issue

Yes,

and, Scott, did you get your 500$ ? :-)

Jacopo

David E Jones wrote:
>
> Scott,
>
> Did this ever make it into OFBiz? I only reviewed it briefly, but if it
> is fixing this problem then it would be great to have it in the ofbiz
> trunk.
>
> -David
>

Scott Gray

Re: Will Pay US$500 for a Solution to a basic tax calculation issue

I had planned on working the patch in this weekend, I just need to clean it
up a bit.

One thing I need a framework guy to look at is the rounding currency
formatting in widgets and the freemarker transform, I think we need to set
the default to something like 10 decimal places instead of the currency's
default. That way any rounding problems aren't hidden by the display code
and it also allows us to display tax items to 3 decimal places (or whatever
the arithmetic.properties has set).

Also, salestax.calc.decimals is a bit of misnomer considering the best we
can do when storing intermediate tax is currency-precise at 3 decimal
places.

And yes I did get paid (tax free, for the moment at least) :-)

Regards
Scott

On 05/05/07, Jacopo Cappellato <[hidden email]> wrote:

>
> Yes,
>
> and, Scott, did you get your 500$ ? :-)
>
> Jacopo
>
> David E Jones wrote:
> >
> > Scott,
> >
> > Did this ever make it into OFBiz? I only reviewed it briefly, but if it
> > is fixing this problem then it would be great to have it in the ofbiz
> > trunk.
> >
> > -David
> >
>

Scott Gray

Re: Will Pay US$500 for a Solution to a basic tax calculation issue

I've committed the changes in rev. 535415

As I mentioned above, someone with framework commit privileges needs to look at the rounding of displayed currency. I've attached a patch with the changes I think are needed. If it doesn't see any action in the short term I'll throw it in the jira.

Regards
Scott

On 05/05/07, Scott Gray <[hidden email]> wrote:

I had planned on working the patch in this weekend, I just need to clean it up a bit.

One thing I need a framework guy to look at is the rounding currency formatting in widgets and the freemarker transform, I think we need to set the default to something like 10 decimal places instead of the currency's default. That way any rounding problems aren't hidden by the display code and it also allows us to display tax items to 3 decimal places (or whatever the arithmetic.properties has set).

Also, salestax.calc.decimals is a bit of misnomer considering the best we can do when storing intermediate tax is currency-precise at 3 decimal places.

And yes I did get paid (tax free, for the moment at least) :-)

Regards
Scott

On 05/05/07, Jacopo Cappellato <[hidden email]> wrote:
Yes,

and, Scott, did you get your 500$ ? :-)

Jacopo

David E Jones wrote:
>
> Scott,
>
> Did this ever make it into OFBiz? I only reviewed it briefly, but if it
> is fixing this problem then it would be great to have it in the ofbiz
> trunk.
>
> -David
>

currencyDisplay.patch (3K) Download Attachment

Jacopo Cappellato

Re: Will Pay US$500 for a Solution to a basic tax calculation issue

In reply to this post by Scott Gray

Scott Gray wrote:
> ...
> And yes I did get paid (tax free, for the moment at least) :-)
>

That's great. I'd like to thank Peter (and I'm sure I'm not alone) for
his sponsorship that helped to fix this issue... and of course also
thank Scott.

Jacopo

Jacopo Cappellato

Re: Will Pay US$500 for a Solution to a basic tax calculation issue

In reply to this post by Scott Gray

Scott,

I agree with you that (at least in the trunk) it is a good idea to
display numbers as they are stored in the db, with no rounding in the ui.
After a very quick review to rev. 535415, I have some doubts about some
of the design decisions (especially the change in the entity definition)
but all in all I think it is good to have the patch in, we should now
start from there to discuss about how to completely resolve the rounding
issues in OFBiz and the pros and cons of using currency-precise fields.

Thanks for your work,

Jacopo

Scott Gray wrote:

David E Jones

Re: Will Pay US$500 for a Solution to a basic tax calculation issue

In reply to this post by Scott Gray

Do we really want to commit this patch, and have OFBiz display all currency values with 10 decimal figures?

My opinion is: definitely no.

If we want to display more decimal digits in certain places we should add an optional attribute/parameter to the transform and then specify it explicitly in certain spots, like 3 or 4 or based on db data number of digits.

-David

Scott Gray wrote:

> I've committed the changes in rev. 535415
>
> As I mentioned above, someone with framework commit privileges needs to
> look at the rounding of displayed currency. I've attached a patch with
> the changes I think are needed. If it doesn't see any action in the
> short term I'll throw it in the jira.
>
> Regards
> Scott
>
> On 05/05/07, *Scott Gray* <[hidden email] <mailto:[hidden email]>>
> wrote:
>
> I had planned on working the patch in this weekend, I just need to
> clean it up a bit.
>
> One thing I need a framework guy to look at is the rounding currency
> formatting in widgets and the freemarker transform, I think we need
> to set the default to something like 10 decimal places instead of
> the currency's default. That way any rounding problems aren't
> hidden by the display code and it also allows us to display tax
> items to 3 decimal places (or whatever the arithmetic.properties has
> set).
>
> Also, salestax.calc.decimals is a bit of misnomer considering the
> best we can do when storing intermediate tax is currency-precise at
> 3 decimal places.
>
> And yes I did get paid (tax free, for the moment at least) :-)
>
> Regards
> Scott
>
>
> On 05/05/07, *Jacopo Cappellato* < [hidden email]
> <mailto:[hidden email]>> wrote:
>
> Yes,
>
> and, Scott, did you get your 500$ ? :-)
>
> Jacopo
>
> David E Jones wrote:
> >
> > Scott,
> >
> > Did this ever make it into OFBiz? I only reviewed it briefly,
> but if it
> > is fixing this problem then it would be great to have it in
> the ofbiz
> > trunk.
> >
> > -David
> >
>
>
>