OFBiz › OFBiz - Dev

[jira] Created: (OFBIZ-366) Separate VAT from Sales Tax

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Nicolas Malin (Jira)

[jira] Created: (OFBIZ-366) Separate VAT from Sales Tax

Separate VAT from Sales Tax
---------------------------

Key: OFBIZ-366
URL: http://issues.apache.org/jira/browse/OFBIZ-366
Project: OFBiz (The Open for Business Project)
Issue Type: Improvement
Components: accounting, ecommerce, order, party, pos, product
Affects Versions: SVN trunk
Reporter: Jacques Le Roux
Fix For: SVN trunk

We need to separate VAT from Sales Tax.

The main reason is that VAT taxe is a very important type of tax in EU (and I guess on some other places) but not in US. An example of problems that arise if we not distinguish them is shown in OFBIZ-362. There we see that VAT in EU has specific mandatory constraints.

This is a huge work I guess. We will see from futur if it's really needed...

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-366) Separate VAT from Sales Tax

[ http://issues.apache.org/jira/browse/OFBIZ-366?page=comments#action_12441644 ]

Jacques Le Roux commented on OFBIZ-366:
---------------------------------------

I believe something is always missing in OFBiz. Ability for users to enter prices with taxes (gross pricing). Not only ability to show prices with taxes as it is now (in eCommerce for instance) .

This message is mostly intended to summarise situation and hopefully find a reasonable solution (perhaps but I hope not, only for my future usage). Sorry for the long post.

Here is a David's quote from a thread initiated by Manuel Meyer : http://www.nabble.com/-OFBiz--Users---VAT-and-rounding-tf156901.html
<<Perhaps the biggest problem with having prices that include tax is
that then you either have to have all sorts of prices for different
tax authorities, or, well, or I don't know. This wouldn't be a
problem if are only selling from one place, ie only have one tax
"nexus", but designing for that is something I'm trying to avoid...>>

At beginning a very simple way for POS (and even some eCommerce sites) should be sufficient (one "nexus" option). I have no time yet but I wonder if before going for others POS tasks this one should not be fulfilled. I had a discussion with Ray Barlow about that point and for him (and others people I guess) it's really a problem for some prospective clients. Specially if they want to use OFBiz accounting :
Ray's quote :
<<I'm sure tax in general works using the normal USA method of entering
net prices for products but I don't think any UK retailers actually work
with net prices they all think and work in gross values. To date I've
not actually delivered a system that anybody is using to do their
invoicing from so I've been able to avoid this issue, but I can't ask
users to change their thinking and habits to start working with net prices.>>

This Si's quote is also interesting ("keep it simple" way, even if I'm not sure it's not deprecated now by the Tax Autorithies mechanism)
<<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.>>

But this David's response from previous comment seems to have stopped this thread so far...
http://www.nabble.com/-OFBiz--Users---VAT-and-rounding-tf156901.html#a999193

Here are also some newer interesting threads
http://www.nabble.com/GST-VAT-status-tf2056121.html
http://www.nabble.com/Users---UK-VAT-p4640028.html
http://www.nabble.com/Users---tax-functionality-tf1428622.html
http://www.nabble.com/GST-VAT-on-purchases-tf2061686.html (discouraged by David)
http://www.nabble.com/Re%3A-Dev---Adding-the-taxAuthorityRateSeqId-field-to%09theOrderAdjustment-entity-tf1374986.html
http://www.nabble.com/Dev---Mods-to-the-TaxAuth-services-to-display-party%27s-taxes-in-prices-instead-of-product-store%27s-one-tf1498508.html

And older threads about Tax Autorithies implementation
http://www.nabble.com/Re%3A-Users----OFBiz--Dev---VAT-in-POS-tf825562.html (this has to be generalised)
http://www.nabble.com/-OFBiz--Dev---RE%3A-VAT-price-guidance-tf342240.html

There are also valuable informations in old Wiki : search "VAT" (notably http://ofbizwiki.go-integral.com/Wiki.jsp?page=TaxAuthorityDataModel)

> Separate VAT from Sales Tax
> ---------------------------
>
> Key: OFBIZ-366
> URL: http://issues.apache.org/jira/browse/OFBIZ-366
> Project: OFBiz (The Open for Business Project)
> Issue Type: Improvement
> Components: accounting, ecommerce, order, party, pos, product
> Affects Versions: SVN trunk
> Reporter: Jacques Le Roux
> Fix For: SVN trunk
>
>
> We need to separate VAT from Sales Tax.
> The main reason is that VAT taxe is a very important type of tax in EU (and I guess on some other places) but not in US. An example of problems that arise if we not distinguish them is shown in OFBIZ-362. There we see that VAT in EU has specific mandatory constraints.
> This is a huge work I guess. We will see from futur if it's really needed...

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Nicolas Malin (Jira)