RE: [OFBiz] Users - VAT and rounding

Posted by David Garrett on Sep 29, 2005; 5:46am
URL: http://ofbiz.116.s1.nabble.com/OFBiz-Users-VAT-and-rounding-tp135121p135123.html

OK maybe I missed the obvious.

I will try using
<field name="sourcePercentage" type="floating-point"><!-- for tax entries
this is the tax percentage --></field>

Also thought the amount (which I see is deprecated had more decimal points
available).


The rate % will help but I suspect there may still be issues with respect to
the finalPrice.

Eg
See the attached XLS which has errors for most quantities when base price is
$123.45


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of David Garrett
Sent: Thursday, 29 September 2005 1:33 PM
To: 'OFBiz Users / Usage Discussion'
Subject: RE: [OFBiz] Users - VAT and rounding

Help!!! I have run into a rounding issue similar issues , although I am
using Item Adjustments not calcTax.

I am struggling. In theory it should be easy but when dealling with the Tax
Office calculation rules I find myself fighting with Ofbiz.

The problem comes in using the "Line Item method" where the tax payable must
be maintained in maximum precision and then rounded for the order total.
Consequently by using (item.basePrice +itemAdjustment) the total item price
has too many decimal places.

The situation is even worse since what really needs to happen is that the
price really needs to be based on the final rounded incTax price.
Ref: http://www.ato.gov.au/corporate/content.asp?doc=/content/mr200036.htm

Ie given a taxRate of 10%, the VAT is 1/11 of the final selling price.
Because of rounding of the final sale price ...

basePrice x 10%
does not always equal

Round( base x 1.1 ) / 11


Further, as indicated below customers expect the incTax price to remain
constant and not be subject to the rounding in the mail below.
This will always be a problem with ShoppingCartItem.getItemSubTotal() being
...
return (getBasePrice() * quantity * getRentalAdjustment()) +
getOtherAdjustments();


This would all be OK if I could set the ProductPrice.price db field to
sufficient precision but in postgres it is limited to 2 decimal points -
probably for very good SALES_TAX reasons.
    <field-type-def type="currency-amount" sql-type="NUMERIC(18,2)"
java-type="Double"><validate method="isSignedDouble" /></field-type-def>

The only other solution I can see is a big job. That is, to modify all the
places where base price is used for calculations and allow the option based
on a Store/Tax setting to work based on a "finalPrice". My GST is all really
based on the final price that is actually paid.

I am prepared to live with these rounding issues in the short term ...

BUT ...
Is there a better approach that I should be following?
Have I missed the obvious?
Am I making this too complex?

David

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Manuel Meyer
Sent: Tuesday, 19 July 2005 7:48 PM
To: [hidden email]
Subject: [OFBiz] Users - VAT and rounding

Hi All,

I have a question regarding taxes and rounding.
In France, every product sold on a site has a VAT of 19.6%.

When the administrator enters a product, he enters it without tax, and I've
added an entry in the product store tax setting, with a tax rate of 19.6.

In order to show taxes very time a product is added in the basket, I've
modified the calcTax service to ask the system to compute tax even if a
shipping address hasn't been entered, as this tax is always applied.

Up to here everything is fine, except that if an price admin enters a
product of 150 tax included, he will enter 125.42 as a default price, and
125.42 turns into 150 when you add tax on it.

The problem is that if a user put 3 items of the same type in his basket,
the price is rounded to 450.01. By adding 7 products of the same type, the
price tax included will be 1050.02 and so on. As the site is a BtoC, the
customer does not want to know about VAT; he only needs to see how much
money he'll spend globally.

I've try to play with the currency format in the general.properties file, as
it is referenced in the code, but I still have this rounding problem.
If I enter 150 as default price and remove the simple tax entry, the
accounting will be false as I won't have anymore vat entries in the
accounting part.

What is the best practice to apply in terms of product price in order to
avoid this rounding problem?

Any advice or comments are very welcome

Thanks in advance and bst regards,
Manuel Meyer

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users


 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users