Posted by
David Garrett on
Oct 01, 2005; 10:42am
URL: http://ofbiz.116.s1.nabble.com/OFBiz-Users-VAT-and-rounding-tp135121p135127.html
I am in strong agreement with most of the details presented by Tarlika.
The points have been well articulated and agree in general with Australian
requirements.
I particularly like the terms gross and vatFraction ... in the interests of
a common language.
The only inconsequential differences:
* the VAT at the line level for Australia needs to be not 3 decimals but the
maximum available.
I will follow up the the BigDecimal and Jira 459.
I previously saw a the "plugin" suggestion but I couldn't find the reference
again. I will follow up Jacopo's suggestion.
Out of interest why are there differences in the vatAmount
vatAmount = 16.097 or 16.095 or 16.098
depending on which algorithm you use and on whether you are a retailer or
wholesaler.
Thanks for the excellent summary.
David G
-----Original Message-----
From:
[hidden email] [mailto:
[hidden email]]
On Behalf Of T E Schmitz
Sent: Saturday, 1 October 2005 5:32 PM
To: OFBiz Users / Usage Discussion
Subject: Re: [OFBiz] Users - VAT and rounding
(My knowledge is specifically relating to UK VAT.)
David E. Jones wrote:
> The calculations shown here aren't quite right and demonstrate an
> interesting quirk in VAT tax calculation. I just researched this a
> bit ago because I'm working (slowly) on revamping the tax calculation
> stuff
David, in principle your formulae are correct, but they will *not* lead to
the correct results.
> There are 2 ways of looking at a 15% VAT for a 110 Euro total price.
> The trick is that the total (gross) price, or the price including (or
> after) tax is 110 EUR. ... the 110 includes the tax,
correct
> after tax total = before tax total + (tax rate * before tax total)
By "total", do you mean invoice total? This would be incorrect.
Different products might incur different rates of VAT. A UK invoice might
contain differently rated products and where delivery charges can be
attributed to products, they are rated at the same rate as the product.
VAT is calculated at line level (as they do Australia). This means, the VAT
amount is worked out for every "line" on an invoice, and a line is the
sub-total of quantity * Product.
> So, to calculate the pre-tax amount you would do:
>
> before tax total = after tax total / (1 + tax rate)
or, to avoid the word "total":
gross = net / (1 + vatRate)
> tax amount = (tax rate * after tax total) / 1 + tax rate
You have worked out what we call the VAT Fraction:
First of all, we calculate the so-called VAT Fraction from the VAT rate.
This is the rate the gross (=VAT inclusive) amount needs to be multiplied
with to calculate the amount of VAT contained in it:
vatFraction = vatRate / (vatRate+1)
Example:
vatRate = 17.5% ==>
vatFraction = 0.175/(1+0.175) = 0.1489
If a product retails at £117.50, the VAT amount is £117.50 * vatFraction =
£17.50
The line VAT is calculated with a 4-digit precision and stored with a
3-digit precision (10th of a penny). The final (invoice) total amount of VAT
has a 2-digit precision (1 penny).
> Keeping base prices in the system that don't include tax could lead
> to
At no point does a retailer work out or even think in terms of the net (VAT
exclusive) amount. As far as data entry is concerned, I would not dream of
asking my customers to enter net prices!
You *cannot* store the prices as VAT exclusive amounts because you will not
be able to work out the correct VAT amount from that because:
- VAT is calculated at line level where the quantity comes in
- VAT at line level is at 3-digit precision
- gross (=VAT inclusive) amount has to be displayed for product
> but I think it pretty much always
> works out fine with the proper rounding to 2 places.
I think I'll frame this sentence and send it to my customer when he gets a
VAT inspection ;-)
> For 123.45 for example, you would calculate the base price by
> dividing it by 1.15 which leads to 107.347826... which rounds to
> 107.35. If you calculate a 15% tax on that it would be 16.1025, which
> rounds to 16.10, which added to the base price results in the desired
123.45.
No.
gross = £123.45
vatRate = 15% (I wish!)
vatFraction = 0.1304
vatAmount = 16.097 or 16.095 or 16.098
depending on which algorithm you use and on whether you are a retailer or
wholesaler.
In any case this line VAT amount *must* be held with a 3-digit precision.
The total VAT amount will be rounded to penny precision at the bottom of the
invoice.
Calculations must be carried out using BigDecimal (although Java's
BigDecimal has a few shortcomings, see
http://www2.hursley.ibm.com/decimalj/decimald.html).
My knowledge is specifically relating to UK VAT. Other European countries
and Australia handle retail prices and VAT in a similar manner
but the actual calculations differ and therefore the "one calculation fits
all" approach will *not* be suitable (see Jira issue 459).
The only thing that will work for all is a "plug-in" archictecture as
suggested by Jacopo, which will allow OFBiz users to write a
country-specific VAT calculation, which could possibly be loaded based on
the local settings. Over time, the OFBiz users will contribute and maintain
(!) the French, UK, Australian ... algorithms. At this point, all you can do
is pick a country (for instance using Dave Garrett's link to the Australian
Revenue site) and develop that one calculation as a template. The rules and
regulations are constantly changing. You can impossibly maintain this alone.
But you can provide a structure that allows us to drop in our calculations.
The crucial thing at the moment is to identify the entity and datatype
structure that will fit all.
--
Regards,
Tarlika Elisabeth Schmitz, Scotland
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users