Posted by
Si Chen-2 on
Oct 06, 2005; 1:05am
URL: http://ofbiz.116.s1.nabble.com/OFBiz-Users-VAT-and-rounding-tp135121p135130.html
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