Posted by
David Garrett on
Oct 07, 2005; 2:59am
URL: http://ofbiz.116.s1.nabble.com/OFBiz-Users-VAT-and-rounding-tp135121p135131.html
Si
[sorry this mail was held up in my outbox for a day]
I generally agree.
I am of the view that, for me, there is a short-term and a medium term
solution.
The short-term solution that I need to implement for this weekend is to
change the price to numeric(18,6). This is a solution while the quantity
remain low/reasonable.
The medium term solution is to operate on gross price. This needs more
investigation but I feel it is the better solution.
I also believe the approach of using configuration settings in the
TaxAuthority entities as advocated by David is a more preferable method than
the plugin idea, which I think your master/sub-service idea alludes to.
I will be taking a closer look but I don't think the OrderAdjustment.addback
field will be required. It should be possible based on TaxAuthority config
to work back from the gross to the adjustment and base.
Anyway ... I'm giving it a go ...
David
-----Original Message-----
From:
[hidden email] [mailto:
[hidden email]]
On Behalf Of Si Chen
Sent: Thursday, 6 October 2005 10:06 AM
To: OFBiz Users / Usage Discussion
Subject: Re: [OFBiz] Users - VAT and rounding
Manuel, David, David, et al -
That's a pretty clever hack, and I'm glad it works for you.
It seems, though, that longer term we'll need to be able to support both the
US (tax added on top of price) and European (flat price including a
tax) formats. It seems that it might not be so hard if we do it this way:
1. Create a new tax type
2. Additional code which calculates that tax for that type, including
correct rounding formulae
3. An added field for OrderAdjustment which denotes whether it should be
added back to the order item's amounts (in the case of US sales
taxes) or is there just for informational purposes (in the case of
European/VAT), since the flat price includes the tax
4. GL posting should work fine once the correct amounts in OrderAdjustment
or at most require a small change.
I think it might be nice to break the sales tax calculation code into a
master which calls several different routines or services depending on the
tax type, so we can keep the implementation separate or call an outside
service if it's available.
Just some general ideas. Anybody up for doing this?
Si
Manuel Meyer wrote:
>Hi All,
>
>Further to what I've red and understood in this thread, here is what
>I've done in order to resolve my issue, which was more a rounding
>problem rather than a VAT problem:
>
>My big concern was that to sell a product of 120 VAT included, I could
>not enter a net amount with 2 digits of precision giving 120 after
>having applied 19.6% of taxes, or by entering a net price of 125.43 for
>a product, I got 150 for 1 product tax included, but 450.01 for 3.
>
>So, I've set all the currency entries in the DB to be numeric(18,6) (I
>am using postgres), and removed all the rounding made in the code
>(mainly in the OrderServices.getTaxAmount() and
>OrderReadHelper.calcOrderAdjustment()
>routines).
>I am only rounding when displaying amounts to the customer.
>
>And since that, I've resolved all my rounding and therefore VAT issues,
>and the site is a real Swiss clock :)
>
>The devil is in the details, so I might have missed something, but it
>looks like working so far.
>
>Best regards,
>Manuel
>
>-----Message d'origine-----
>De :
[hidden email]
>[mailto:
[hidden email]] De la part de T E Schmitz Envoyé
>: Wednesday, October 05, 2005 3:17 PM À : OFBiz Users / Usage
>Discussion Objet : Re: [OFBiz] Users - VAT and rounding
>
>David Garrett wrote:
>
>
>>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.
>>
>>
>
>The VAT Guide describes several rounding modes (unfortunately fails to
>be specific enough for invoicing at retailers).
>
>For our example
>gross = £123.45
>vatRate = 15%
>vatFraction = 0.1304
>==> vatAmount = 16.09788
>
>Invoicing at line level (B2B)
>a) round down to nearest 0.1p -> 16.097
>b) round to nearest 1p or 0.5p -> 16.095
>
>For invoicing at retailers, rounding *down* is forbidden:
>c) round to nearest 0.1p -> 16.098
>
>
>
>>Thanks for the excellent summary.
>>
>>
>
>Sadly, I seem to spend more time in accounting newsgroups than in Java
>newsgroups. ;-)
>
>
>
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users