Hi all, 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. 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 : http://www.nabble.com/-OFBiz--Users---VAT-and-rounding-tf156901.html#a999193 Now, David do you think that it's possible to do something for "gross pricing" with the current tax model and calculation ? 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 A new related Jira issue : http://issues.apache.org/jira/browse/OFBIZ-366 Other related stuffes in Jira http://issues.apache.org/jira/browse/OFBIZ-113 http://issues.apache.org/jira/browse/OFBIZ-147 (I will try to solve this today) http://issues.apache.org/jira/browse/OFBIZ-164 Jacques PS : There are also valuable informations in old Wiki : search "VAT" (notably http://ofbizwiki.go-integral.com/Wiki.jsp?page=TaxAuthorityDataModel)
