http://ofbiz.116.s1.nabble.com/OFBiz-Users-VAT-and-rounding-tp135121p135124.html
I'm finally starting to understand your problem. Is this a correct
Euros, of which 15% might be a VAT. So you will need to show the
What's the solution... Depends on:
>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>