This will probably just demonstrate my complete ignorance of VAT. Isn't this just an issue of multiplication (US Tax) and division (VAT) instead of addition and subtraction?
US ->productPrice * (1 + USTax) = final price VAT -> productPrice / (1-VAT) = final price or US-> productPrice * (1+USTax) - productPrice = tax adjustment VAT-> productPrice / (1-VAT) - productPrice = VAT adjustment >From there as far as entering "gross pricing" this would be on the screen level with the service determining the product by the above formula. Take care of your rounding (which is specific on the VAT or tax being applied) and you're home free yes/no? --- Jacques Le Roux <[EMAIL PROTECTED]> wrote: > 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) >
