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, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>]
Sent: 28 April 2007 05:56
To: [email protected] <mailto:[email protected]>
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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
>
>
> --- [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>]
> > Sent: 18 April 2007 10:50
> > To: [email protected] <mailto:[email protected]>
> > 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, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<[EMAIL PROTECTED] <mailto:[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]
<mailto:[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] <mailto:[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
> >
> === message truncated ===
>
>
