VAT and gross pricing
Locked
12
12
 
|
--- Iain Fogg <[hidden email]> wrote: > things with the current implementation, the only > hassle being that I > have to store all my prices ex-tax - this is > slightly painful because my > suppliers generally provide inc-tax prices and I > have to reach for my > calculator :-) > > Cheers, Iain > Then that should be a simple change to the purchase order services so that you're entering pricing inc-tax and it's storing prices ex-tax + storing an adjustment for tax |
|
|
Chris,
Can you walk me through the mods required to do this? Would it be smart enough to "invert" the tax rule for specific product. Eg, different products have different tax rates that are (presumably) dictated by the tax rule (or rules) that apply to them. Cheers, Iain Chris Howe wrote: > --- Iain Fogg <[hidden email]> wrote: > >> things with the current implementation, the only >> hassle being that I >> have to store all my prices ex-tax - this is >> slightly painful because my >> suppliers generally provide inc-tax prices and I >> have to reach for my >> calculator :-) >> >> Cheers, Iain >> >> > > Then that should be a simple change to the purchase > order services so that you're entering pricing inc-tax > and it's storing prices ex-tax + storing an adjustment > for tax > > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.3/473 - Release Date: 12/10/2006 |
|
|
You would create a custom component as descibed in the
wiki FAQ. Depending on how you're using OFBiz the custom component could be based on the order manager or the accounting component Depending on the uniformity of your tax code and the uniformity of your product(if your purchase tax rate is the same as your sale tax rate for that item...always AND you simply resell the product you purchased unchanged) you could divide price paid by (1+ tax) using the tax rules you've set up for the product and store that number as the base price then subtract base price from price paid to enter as tax adjustment. Otherwise, if your industry doesn't follow the uniformity or you have some sort of manufacturing component in your business, you'll have to set up additional tax rules that are related to the SupplierProduct entity. Because this won't be very elegant, if you have to go this route, it may be more worthwhile to rewrite the product entities to be generic and and strip Product.productId of any implied meaning outside of being a unique identifier (which would solve a lot of industry specific issues that would be very dificult for OFBiz to solve otherwise, but that currently fall in the category of worrying about issues that no one is currently worrying about). So, if your calculator is still working, that may be easier in this situation ;) --- Iain Fogg <[hidden email]> wrote: > Chris, > > Can you walk me through the mods required to do > this? > > Would it be smart enough to "invert" the tax rule > for specific product. > Eg, different products have different tax rates that > are (presumably) > dictated by the tax rule (or rules) that apply to > them. > > Cheers, Iain > > Chris Howe wrote: > > --- Iain Fogg <[hidden email]> wrote: > > > >> things with the current implementation, the only > >> hassle being that I > >> have to store all my prices ex-tax - this is > >> slightly painful because my > >> suppliers generally provide inc-tax prices and I > >> have to reach for my > >> calculator :-) > >> > >> Cheers, Iain > >> > >> > > > > Then that should be a simple change to the > purchase > > order services so that you're entering pricing > inc-tax > > and it's storing prices ex-tax + storing an > adjustment > > for tax > > > > > > > > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.1.408 / Virus Database: 268.13.3/473 - > Release Date: 12/10/2006 > > |
Administrator
|
In reply to this post by cjhowe
----- Original Message -----
From: "Chris Howe" <[hidden email]> > In the US, only the end user is paying sales tax as > well, yet we display prices excluding sales tax. > > Is the practice of quoting/showing prices including > VAT a government requirement or a market custom? > > The reason why I'm asking this question is because the > whole discussion about how to treat VAT is based on > US/nonUS marketing practices. The US has marketing > practices of certain price points that give the > illusion of value (ie $9.99, $49.00) or of using round > numbers (ie $10.00, $50.00) for simplicity with all of > these illusionary value numbers not including tax. > Yet, the VAT/GST countries want to use the same > illusion of value or simplicity but have it include > the tax adjustment. If it's an issue of marketing, the > solution should be handled by a marketing/ content/ > ecommerce approach, if it's an issue of tax, the > solution should be handled by a price adjustment/ tax > approach. As I said before it's a EU decision. Please see here : (more and more details in each link) http://ec.europa.eu/taxation_customs/taxation/vat/traders/invoicing_rules/index_en.htm http://europa.eu/rapid/pressReleasesAction.do?reference=MEMO/04/15&format=HTML&aged=1&language=en&guiLanguage=en http://ec.europa.eu/taxation_customs/taxation/vat/traders/invoicing_rules/article_1733_en.htm This rules are very clear for instance : http://ec.europa.eu/taxation_customs/taxation/vat/traders/invoicing_rules/article_1733_en.htm#1.4.1 Jacques |
|
Administrator
|
In reply to this post by cjhowe
From: "Chris Howe" <[hidden email]>
> --- Iain Fogg <[hidden email]> wrote: > > things with the current implementation, the only > > hassle being that I > > have to store all my prices ex-tax - this is > > slightly painful because my > > suppliers generally provide inc-tax prices and I > > have to reach for my > > calculator :-) > > > > Cheers, Iain > > > > Then that should be a simple change to the purchase > order services so that you're entering pricing inc-tax > and it's storing prices ex-tax + storing an adjustment > for tax Chris, This is not only a matter of PO : in retail people use to think in gross prices. BTW in France receipts of large retailers (supermarkets) do not show ex-tax prices nor VAT only gross prices. This rules are specific to each EU countries as specified in http://ec.europa.eu/taxation_customs/taxation/vat/traders/invoicing_rules/article_1733_en.htm#1.4.3 To see ex-tax prices and VAT you need to ask for an invoice. In this case VAT is calculated as explained Jacopo here http://www.nabble.com/Users---tax-functionality-tf1428622.html. And must be in compliance with http://ec.europa.eu/taxation_customs/taxation/vat/traders/invoicing_rules/article_1733_en.htm#1.4.1 In practice there are often only items gross prices (should be ex-tax prices), a total VAT by rate applied and rate applied, and a (grand) total. I hope it's clear Jacques |
|
|
In reply to this post by Jacques Le Roux
Thank you for the link. Looking over...
http://ec.europa.eu/taxation_customs/taxation/vat/traders/invoicing_rules/article_1733_en.htm#1.4.1 ... #12 says that you're to itemize things the same as we do in the US, unless your unit price includes VAT. So my question remains...who is making you include VAT in your unit price? The EC doesn't appear to be. Is it the local country governments or is it simply custom? --- Jacques Le Roux <[hidden email]> wrote: > ----- Original Message ----- > From: "Chris Howe" <[hidden email]> > > In the US, only the end user is paying sales tax > as > > well, yet we display prices excluding sales tax. > > > > Is the practice of quoting/showing prices > including > > VAT a government requirement or a market custom? > > > > The reason why I'm asking this question is because > the > > whole discussion about how to treat VAT is based > on > > US/nonUS marketing practices. The US has > marketing > > practices of certain price points that give the > > illusion of value (ie $9.99, $49.00) or of using > round > > numbers (ie $10.00, $50.00) for simplicity with > all of > > these illusionary value numbers not including tax. > > > Yet, the VAT/GST countries want to use the same > > illusion of value or simplicity but have it > include > > the tax adjustment. If it's an issue of marketing, > the > > solution should be handled by a marketing/ > content/ > > ecommerce approach, if it's an issue of tax, the > > solution should be handled by a price adjustment/ > tax > > approach. > > As I said before it's a EU decision. Please see here > : (more and more details in each link) > > http://europa.eu/rapid/pressReleasesAction.do?reference=MEMO/04/15&format=HTML&aged=1&language=en&guiLanguage=en > http://ec.europa.eu/taxation_customs/taxation/vat/traders/invoicing_rules/article_1733_en.htm > > This rules are very clear for instance : > http://ec.europa.eu/taxation_customs/taxation/vat/traders/invoicing_rules/article_1733_en.htm#1.4.1 > > Jacques > |
Re: VAT and gross pricing (example of failed SALES DISC)
|
Administrator
|
In reply to this post by Iain Fogg
Thanks Iain,
I will take a look at SALE DISC ASAP (did you try with amount and taxes ?). I saw that it was not showing adjustment but had no time to solve it. Yet receipts show no adjustment informations in general. I did nothing on this because I know that Ray barlow has done some work around receipts and I waited informations from him. But I have no news from him since a while. Ray if you read this please feel free to ring ;o) Jacques ----- Original Message ----- From: Iain Fogg To: [hidden email] Sent: Friday, October 13, 2006 2:19 AM Subject: Re: VAT and gross pricing (example of failed SALES DISC) Jacques, Yes, I tried on yesterday's SVN. I just ran an exampe again, and this is what the POS shows... Before Order adjustment ================= Item price: 17.23 (this is exTax price) GST: 1.72 (this is the Sales Tax subtotal) Grand Total: 18.95 I now apply a 20% SALE DISC, and we get After Order adjustment ================ Item price: 17.23 (this is exTax price) GST: 1.72 (this is the Sales Tax subtotal) Grand Total: 15.50 Neither the POS nor receipt show anything about the discount. If I do the same thing with an Item discount, the POS shows: Item price: 17.23 (adjustment): -3.45 GST: 1.38 (yes, the correct tax was calculated) Grand Total: 15.16 Note the difference in grand total prices. The SALE DISC is computing the discount on the exTax price and then adds the tax to get the (incorrect) grand total. Cheers, Iain Jacques Le Roux wrote: Hi Iain, From: "Iain Fogg" <[hidden email]> + Order level discounting doesn't work properly for in the GST environment. Eg, I have an item for $110, which includes $10 GST. If I discount the order, the price drops to $88, but the GST still shows as $10 - it should be $8.80. The correct behaviour depends on whether individual line items are subject to GST or not. Technically, if I give a 20% order level discount this discount should be distributed across all line items in the order, and then the GST would be calculated correctly. In practice, order level discounts are banned, and sales staff need to apply any discounts at the item level (which works well for GST calculations). It's not clear what a fixed-amount order-level discount means in a GST environment, since individual products (not whole orders) are subject to the tax - what if your order has a mixture of GST and GST-free products??? Did you try on POS with last svn (that's what I guess but not sure) ? Because I have tried only without taxes yet .... #1 for me is being able to record my prices tax-inclusive, yet still ensure that local reporting requirements are met (eg, displaying the amount of GST in the sale), and that the GL tracks the GST component. Yes that's the problem we have to cope with if we want to have happy customers :o) I think we already the flag to indicate whether prices include tax, but it's not clear that this has relevance for GST?VAT (please correct me if I'm wrong). For the moment taxes are not differentiated, please see : http://issues.apache.org/jira/browse/OFBIZ-366 We also need a flag(s) to indicate whether we need to report the tax component, and whether the reporting needs to be on the item or order level. As mentioned above, order adjustments need to be made sensitive to the GST/VAT environment, but perhaps the simplest thing is just to train users not to ever use order-level adjustments :-) Here they are some differents rules. For instance in Italy and France if you have Jacopo explained that here : http://www.nabble.com/Users---tax-functionality-tf1428622.html) But it's no the same in Germany for instance. Here is also an interesting remark going your way (customising cutomers ;o) http://www.nabble.com/Users---tax-functionality-tf1428622.html Thanks for your comments PS : One question out of subject : I do use Outlook Express (OE) on Windows (was trapped long before ;o). When I respond to an ML msg only to the sender, automatically OE send also a copy to ML. I wonder if it would not be a best practise to respond only to the ML (to avoid double messages to the intial sender). What do you think ? Jacques ------------------------------------------------------------------------------ No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.3/473 - Release Date: 12/10/2006 |
|
|
In reply to this post by cjhowe
Chris, Jacques,
This is a good point, despite the fact that the price is inclusive of VAT, EU members will still tend to use these popular price points (1.00 1.99 1.95 etc). Remember that for a VATable item, you are ultimately paying VAT only on the _V_alue you have _A_dded to the item For anyone unfamiliar, here is an example in british pounds although the principle is applicable to Euros too although the VAT rate may differ. Vendor buys product at £10,00 Vendor pays additional £1.75 (17.5% VAT) Vendor sells at £20,00 (inclusive of VAT) Vendor is liable for £3.50 (17.5% VAT) However vendor has already paid £1.75 to the distributor, leaving the balance of £1.75 due to the tax man. If these were the only two transactions in the VAT period, then your VAT bill would be £1.75. If however only the first transaction had happened (i.e. you hadn't sold-on the product) then you would be liable for a rebate of £1.75 from the tax man. VAT return statements reflect this dual aspect, i.e. you declare what the VAT man owes you and what you owe the VAT man. Does that make the process any clearer? - Andrew On Thu, 2006-10-12 at 15:26 -0700, Chris Howe wrote: > In the US, only the end user is paying sales tax as > well, yet we display prices excluding sales tax. > > Is the practice of quoting/showing prices including > VAT a government requirement or a market custom? > > The reason why I'm asking this question is because the > whole discussion about how to treat VAT is based on > US/nonUS marketing practices. The US has marketing > practices of certain price points that give the > illusion of value (ie $9.99, $49.00) or of using round > numbers (ie $10.00, $50.00) for simplicity with all of > these illusionary value numbers not including tax. > Yet, the VAT/GST countries want to use the same > illusion of value or simplicity but have it include > the tax adjustment. If it's an issue of marketing, the > solution should be handled by a marketing/ content/ > ecommerce approach, if it's an issue of tax, the > solution should be handled by a price adjustment/ tax > approach. > > --- Jacques Le Roux <[hidden email]> > wrote: > > > From: "Chris Howe" <[hidden email]> > > > Thanks for the responses, I guess I wasn't clear > > on my > > > question. If we agree on a price that is subject > > to > > > VAT, at who's discretion is it that the agreed > > price > > > is VAT inclusive/exclusive. > > > > > > ie, > > > the base price is 100 > > > VAT = 10% > > > final price = 110 > > > > > > When two parties agree upon a price, the agreed > > price > > > can either be 100 VAT exclusive or 110 VAT > > inclusive, > > > it's the same agreement and the end payment is 110 > > in > > > both situations. Who says that you have to list > > each > > > item on an invoice as VAT inclusive? Is it > > government > > > mandated that prices are promoted as VAT inclusive > > or > > > is it simply the custom of the marketplace? > > > > For an agreement (B2B you mean I guess, because > > there is no agreement in retail and there prices are > > fixed unilateraly - not in some > > parts of Africa BTW - always VAT inclusive) price > > are always VAT exclusive because only "end users" > > (customers) are paying VAT. > > In fact people that collect VAT for a tax authority > > (in the context of their work, me for instance) do > > not pay VAT for what they > > need in their business (they pay but when the send > > back VAT they have collected they deduce VAT they > > have paid). Of course ASA I'm > > going to buy bread I will pay VAT and will never see > > that money back (some are juggling with that but - > > no only with bread of > > course -, I already did see bad results, as > > everybody know : juggling is an art ;o). Some might > > say that it's not really true that I > > never see my money back : hospitals, roads, schools, > > etc. : 43% of them come from VAT in France. > > > > HTH > > > > Jacques > > > > > Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com |
|
|
Chris, Jacques,
On a more general note... VAT in EU is not quite as normalised as it should be, I think about 12 years ago the EU adopted an interim VAT solution, but has been stuck with it ever since due to lack of agreement. If you're interested in this sort of thing, the interim VAT solution has raised a bit of controversy recently as billions of euros have disappeared through loop-holes. Do a google search for "VAT carousel" to find out more about the problems with "carousel" fraud. Finally, carousel fraud is causing other side effects, such as distorting export figures, here's an interesting article on that... http://www.finfacts.com/irelandbusinessnews/publish/article_10005795.shtml This is probably a lot more detail than you need, but it's interesting to know a little detail about the whole EU VAT setup... -- Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |