You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2006/10/11 07:57:41 UTC
VAT and gross pricing
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)
Re: VAT and gross pricing
Posted by David E Jones <jo...@undersunconsulting.com>.
On Oct 12, 2006, at 11:25 AM, Jacopo Cappellato wrote:
> http://docs.ofbiz.org/display/~jacopoc/OFBiz%27s+Tax+Authority+Data
> +Model
>
> because I think it's a great resource for understanding the OFBiz's
> tax auth data model; David Jones is the author of this document and
> as soon as the content of that page is updated and cleaned up I'd
> me more than happy to move it to one of the official Confluence
> spaces: David, could you please confirm that my assumption (see my
> note in the very last line of the document) about a typo in your
> original message, is correct?
Yes, that's correct. It should be billed as an alternative to the
shipping address.
-David
Re: VAT and gross pricing
Posted by Jacopo Cappellato <ti...@sastau.it>.
Jacques,
thanks for starting this interesting thread and for providing these
great links.
Just a side note: I've moved the old wiki page
to my personal space in the new Documentation site:
http://docs.ofbiz.org/display/~jacopoc/OFBiz%27s+Tax+Authority+Data+Model
because I think it's a great resource for understanding the OFBiz's tax
auth data model; David Jones is the author of this document and as soon
as the content of that page is updated and cleaned up I'd me more than
happy to move it to one of the official Confluence spaces: David, could
you please confirm that my assumption (see my note in the very last line
of the document) about a typo in your original message, is correct?
Thanks,
Jacopo
Jacques Le Roux wrote:
> Hi Si,
>
> Thanks for you interest in this
>
>> Can you post all of this on that JIRA issue you created for VAT?
>> I'll try to help out when I have a chance.
>
> OK, done : http://issues.apache.org/jira/browse/OFBIZ-366
>
>> Also same regarding the invoice header thing--I'll take a look at it
>> later. Can you confirm that Eriks is right--is a tax authority Id in
>> the bill-to geo really required in EU? (Funny, it's the exact
>> opposite of the US...)
>
> Yes Eriks correctly explained the EU rules. The Value Added Tax (VAT) ID number applies only if you are placing a business order for
> a business in the European Union that has a current VAT ID. For all other orders, you should leave this field blank. So this is a
> B2B only rule. Eriks also added the VAT ID of the seller. This is right too, both fields are mandatory for B2B in EU. In this case
> no VAT is charged (VAT Exemption).
>
> Here is an interesting link explaining simply (good examples) how that works :
> http://www.apptranslator.com/blog/2006/03/should-you-charge-vat-to-whom.html
>
> And last but not least a VAT : Definition, history, and more (VAT was invented by a french, sorry for that ;o) :
> http://en.wikipedia.org/wiki/Value-added_tax
>
> I put all this also in the Jira VAT issue (366)
>
> Jacques
Re: VAT and gross pricing (example of failed SALES DISC)
Posted by Jacques Le Roux <ja...@les7arts.com>.
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: ofbiz-dev@incubator.apache.org
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" <ia...@westnet.com.au>
+ 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
Re: VAT and gross pricing (example of failed SALES DISC)
Posted by Iain Fogg <ia...@westnet.com.au>.
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" <ia...@westnet.com.au>
>
>> + 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
>
>
>
>
Re: VAT and gross pricing
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Iain,
From: "Iain Fogg" <ia...@westnet.com.au>
> + 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
Re: VAT and gross pricing
Posted by Iain Fogg <ia...@westnet.com.au>.
Hi all,
My 2 cents on VAT/GST.
In Australia, most goods and services are subject to GST, but certainly
not all. The government determines which ones are taxed (don't ask -
it's a nightmare in some industries, though not mine thank goodness). If
they are subject to the tax, it is a flat 10%.
My experience with OFBiz and its ability to support GST has been pretty
good, although one or two things have had me scratching my head.
+ To ensure only taxable products are taxed create a GST category and
assign those taxable products to the category
+ Set up your tax authority Rate Product to only tax products in the GST
category
+ Make sure your store(s) have the VAT tax authority (and Geo) pointing
to your tax authority
+ The biggest hassle is the need to store prices exGST; at least I
haven't found a way to store the tax-inclusive price and still have the
GST reported properly (a requirement in Australia)
+ Customers (and sales staff) strongly prefer to see tax-inclusive
prices in all screens/invoices/receipts/etc. I found I needed to patch
the receipt generation code to allow me to do this. I still haven't
worked through all the screens/invoices/etc to make sure I've met this
requirement. Customers are the most important, so I'm focussing energy
there.
+ 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???
+ The accounting app seems to work well in assigning GST amounts to the
appropriate GL account. However, make sure your Tax Authority Rate
Product has NULL values in min_purchase and min_item_price. Otherwise,
when you do a return, the GST calculation will be skipped (because the
return generates negative numbers), the customer will be annoyed because
he won't get his GST back, and you'll be annoyed because the GST account
wasn't credited with the refund (ie, the business owner is out of pocket).
Overall, I'm pretty happy with the way OFBiz supports GST, but it would
be nice if we could improve in a couple of areas...
#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.
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). 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 :-)
Of course, I rather flippantly suggested we need another flag or two to
improve support for the GST/VAT tax regimes, but obviously we also need
to work through the applications to ensure they appropriately support
the additional features.
Cheers, Iain
Andrew Sykes wrote:
> Chris,
>
> It's a government decision.
>
> Some items are exempt, like children's clothes; books; food (I think)
> most require VAT though.
>
> - Andrew
>
> On Thu, 2006-10-12 at 03:15 -0700, Chris Howe wrote:
>
>> Jacques,
>> Thanks for the info.
>> The wikipedia reference says that the price MAY be
>> inclusive of VAT. At who's discretion is it
>> inclusive? Does the seller choose whether the agreed
>> upon price is inclusive or does the government decide?
>>
>> --- Jacques Le Roux <ja...@les7arts.com>
>> wrote:
>>
>>
>>> Hi Si,
>>>
>>> Thanks for you interest in this
>>>
>>>
>>>> Can you post all of this on that JIRA issue you
>>>>
>>> created for VAT?
>>>
>>>> I'll try to help out when I have a chance.
>>>>
>>> OK, done :
>>> http://issues.apache.org/jira/browse/OFBIZ-366
>>>
>>>
>>>> Also same regarding the invoice header thing--I'll
>>>>
>>> take a look at it
>>>
>>>> later. Can you confirm that Eriks is right--is a
>>>>
>>> tax authority Id in
>>>
>>>> the bill-to geo really required in EU? (Funny,
>>>>
>>> it's the exact
>>>
>>>> opposite of the US...)
>>>>
>>> Yes Eriks correctly explained the EU rules. The
>>> Value Added Tax (VAT) ID number applies only if you
>>> are placing a business order for
>>> a business in the European Union that has a current
>>> VAT ID. For all other orders, you should leave this
>>> field blank. So this is a
>>> B2B only rule. Eriks also added the VAT ID of the
>>> seller. This is right too, both fields are mandatory
>>> for B2B in EU. In this case
>>> no VAT is charged (VAT Exemption).
>>>
>>> Here is an interesting link explaining simply (good
>>> examples) how that works :
>>>
>>>
>> http://www.apptranslator.com/blog/2006/03/should-you-charge-vat-to-whom.html
>>
>>> And last but not least a VAT : Definition, history,
>>> and more (VAT was invented by a french, sorry for
>>> that ;o) :
>>> http://en.wikipedia.org/wiki/Value-added_tax
>>>
>>> I put all this also in the Jira VAT issue (366)
>>>
>>> Jacques
>>>
>>>
>>>
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.408 / Virus Database: 268.13.2/472 - Release Date: 11/10/2006
Re: VAT and gross pricing
Posted by Chris Howe <cj...@yahoo.com>.
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?
--- Jacques Le Roux <ja...@les7arts.com>
wrote:
> Chris,
>
> Yes it's the same in France (and I think everywhere,
> at least in EU)
>
> Jacques
>
> > Chris,
> >
> > It's a government decision.
> >
> > Some items are exempt, like children's clothes;
> books; food (I think)
> > most require VAT though.
> >
> > - Andrew
> >
> > On Thu, 2006-10-12 at 03:15 -0700, Chris Howe
> wrote:
> > > Jacques,
> > > Thanks for the info.
> > > The wikipedia reference says that the price MAY
> be
> > > inclusive of VAT. At who's discretion is it
> > > inclusive? Does the seller choose whether the
> agreed
> > > upon price is inclusive or does the government
> decide?
> > >
> > > --- Jacques Le Roux
> <ja...@les7arts.com>
> > > wrote:
> > >
> > > > Hi Si,
> > > >
> > > > Thanks for you interest in this
> > > >
> > > > > Can you post all of this on that JIRA issue
> you
> > > > created for VAT?
> > > > > I'll try to help out when I have a chance.
> > > >
> > > > OK, done :
> > > > http://issues.apache.org/jira/browse/OFBIZ-366
> > > >
> > > > > Also same regarding the invoice header
> thing--I'll
> > > > take a look at it
> > > > > later. Can you confirm that Eriks is
> right--is a
> > > > tax authority Id in
> > > > > the bill-to geo really required in EU?
> (Funny,
> > > > it's the exact
> > > > > opposite of the US...)
> > > >
> > > > Yes Eriks correctly explained the EU rules.
> The
> > > > Value Added Tax (VAT) ID number applies only
> if you
> > > > are placing a business order for
> > > > a business in the European Union that has a
> current
> > > > VAT ID. For all other orders, you should leave
> this
> > > > field blank. So this is a
> > > > B2B only rule. Eriks also added the VAT ID of
> the
> > > > seller. This is right too, both fields are
> mandatory
> > > > for B2B in EU. In this case
> > > > no VAT is charged (VAT Exemption).
> > > >
> > > > Here is an interesting link explaining simply
> (good
> > > > examples) how that works :
> > > >
> > >
>
http://www.apptranslator.com/blog/2006/03/should-you-charge-vat-to-whom.html
> > > >
> > > > And last but not least a VAT : Definition,
> history,
> > > > and more (VAT was invented by a french, sorry
> for
> > > > that ;o) :
> > > > http://en.wikipedia.org/wiki/Value-added_tax
> > > >
> > > > I put all this also in the Jira VAT issue
> (366)
> > > >
> > > > Jacques
> > > >
> > > >
> > >
> > --
> > Kind Regards
> > Andrew Sykes <an...@sykesdevelopment.com>
> > Sykes Development Ltd
> > http://www.sykesdevelopment.com
>
Re: VAT and gross pricing
Posted by Jacques Le Roux <ja...@les7arts.com>.
Chris,
Yes it's the same in France (and I think everywhere, at least in EU)
Jacques
> Chris,
>
> It's a government decision.
>
> Some items are exempt, like children's clothes; books; food (I think)
> most require VAT though.
>
> - Andrew
>
> On Thu, 2006-10-12 at 03:15 -0700, Chris Howe wrote:
> > Jacques,
> > Thanks for the info.
> > The wikipedia reference says that the price MAY be
> > inclusive of VAT. At who's discretion is it
> > inclusive? Does the seller choose whether the agreed
> > upon price is inclusive or does the government decide?
> >
> > --- Jacques Le Roux <ja...@les7arts.com>
> > wrote:
> >
> > > Hi Si,
> > >
> > > Thanks for you interest in this
> > >
> > > > Can you post all of this on that JIRA issue you
> > > created for VAT?
> > > > I'll try to help out when I have a chance.
> > >
> > > OK, done :
> > > http://issues.apache.org/jira/browse/OFBIZ-366
> > >
> > > > Also same regarding the invoice header thing--I'll
> > > take a look at it
> > > > later. Can you confirm that Eriks is right--is a
> > > tax authority Id in
> > > > the bill-to geo really required in EU? (Funny,
> > > it's the exact
> > > > opposite of the US...)
> > >
> > > Yes Eriks correctly explained the EU rules. The
> > > Value Added Tax (VAT) ID number applies only if you
> > > are placing a business order for
> > > a business in the European Union that has a current
> > > VAT ID. For all other orders, you should leave this
> > > field blank. So this is a
> > > B2B only rule. Eriks also added the VAT ID of the
> > > seller. This is right too, both fields are mandatory
> > > for B2B in EU. In this case
> > > no VAT is charged (VAT Exemption).
> > >
> > > Here is an interesting link explaining simply (good
> > > examples) how that works :
> > >
> > http://www.apptranslator.com/blog/2006/03/should-you-charge-vat-to-whom.html
> > >
> > > And last but not least a VAT : Definition, history,
> > > and more (VAT was invented by a french, sorry for
> > > that ;o) :
> > > http://en.wikipedia.org/wiki/Value-added_tax
> > >
> > > I put all this also in the Jira VAT issue (366)
> > >
> > > Jacques
> > >
> > >
> >
> --
> Kind Regards
> Andrew Sykes <an...@sykesdevelopment.com>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
Re: VAT and gross pricing
Posted by Andrew Sykes <an...@sykesdevelopment.com>.
Chris,
It's a government decision.
Some items are exempt, like children's clothes; books; food (I think)
most require VAT though.
- Andrew
On Thu, 2006-10-12 at 03:15 -0700, Chris Howe wrote:
> Jacques,
> Thanks for the info.
> The wikipedia reference says that the price MAY be
> inclusive of VAT. At who's discretion is it
> inclusive? Does the seller choose whether the agreed
> upon price is inclusive or does the government decide?
>
> --- Jacques Le Roux <ja...@les7arts.com>
> wrote:
>
> > Hi Si,
> >
> > Thanks for you interest in this
> >
> > > Can you post all of this on that JIRA issue you
> > created for VAT?
> > > I'll try to help out when I have a chance.
> >
> > OK, done :
> > http://issues.apache.org/jira/browse/OFBIZ-366
> >
> > > Also same regarding the invoice header thing--I'll
> > take a look at it
> > > later. Can you confirm that Eriks is right--is a
> > tax authority Id in
> > > the bill-to geo really required in EU? (Funny,
> > it's the exact
> > > opposite of the US...)
> >
> > Yes Eriks correctly explained the EU rules. The
> > Value Added Tax (VAT) ID number applies only if you
> > are placing a business order for
> > a business in the European Union that has a current
> > VAT ID. For all other orders, you should leave this
> > field blank. So this is a
> > B2B only rule. Eriks also added the VAT ID of the
> > seller. This is right too, both fields are mandatory
> > for B2B in EU. In this case
> > no VAT is charged (VAT Exemption).
> >
> > Here is an interesting link explaining simply (good
> > examples) how that works :
> >
> http://www.apptranslator.com/blog/2006/03/should-you-charge-vat-to-whom.html
> >
> > And last but not least a VAT : Definition, history,
> > and more (VAT was invented by a french, sorry for
> > that ;o) :
> > http://en.wikipedia.org/wiki/Value-added_tax
> >
> > I put all this also in the Jira VAT issue (366)
> >
> > Jacques
> >
> >
>
--
Kind Regards
Andrew Sykes <an...@sykesdevelopment.com>
Sykes Development Ltd
http://www.sykesdevelopment.com
Re: VAT and gross pricing
Posted by Chris Howe <cj...@yahoo.com>.
Jacques,
Thanks for the info.
The wikipedia reference says that the price MAY be
inclusive of VAT. At who's discretion is it
inclusive? Does the seller choose whether the agreed
upon price is inclusive or does the government decide?
--- Jacques Le Roux <ja...@les7arts.com>
wrote:
> Hi Si,
>
> Thanks for you interest in this
>
> > Can you post all of this on that JIRA issue you
> created for VAT?
> > I'll try to help out when I have a chance.
>
> OK, done :
> http://issues.apache.org/jira/browse/OFBIZ-366
>
> > Also same regarding the invoice header thing--I'll
> take a look at it
> > later. Can you confirm that Eriks is right--is a
> tax authority Id in
> > the bill-to geo really required in EU? (Funny,
> it's the exact
> > opposite of the US...)
>
> Yes Eriks correctly explained the EU rules. The
> Value Added Tax (VAT) ID number applies only if you
> are placing a business order for
> a business in the European Union that has a current
> VAT ID. For all other orders, you should leave this
> field blank. So this is a
> B2B only rule. Eriks also added the VAT ID of the
> seller. This is right too, both fields are mandatory
> for B2B in EU. In this case
> no VAT is charged (VAT Exemption).
>
> Here is an interesting link explaining simply (good
> examples) how that works :
>
http://www.apptranslator.com/blog/2006/03/should-you-charge-vat-to-whom.html
>
> And last but not least a VAT : Definition, history,
> and more (VAT was invented by a french, sorry for
> that ;o) :
> http://en.wikipedia.org/wiki/Value-added_tax
>
> I put all this also in the Jira VAT issue (366)
>
> Jacques
>
>
Re: VAT and gross pricing
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Si,
Thanks for you interest in this
> Can you post all of this on that JIRA issue you created for VAT?
> I'll try to help out when I have a chance.
OK, done : http://issues.apache.org/jira/browse/OFBIZ-366
> Also same regarding the invoice header thing--I'll take a look at it
> later. Can you confirm that Eriks is right--is a tax authority Id in
> the bill-to geo really required in EU? (Funny, it's the exact
> opposite of the US...)
Yes Eriks correctly explained the EU rules. The Value Added Tax (VAT) ID number applies only if you are placing a business order for
a business in the European Union that has a current VAT ID. For all other orders, you should leave this field blank. So this is a
B2B only rule. Eriks also added the VAT ID of the seller. This is right too, both fields are mandatory for B2B in EU. In this case
no VAT is charged (VAT Exemption).
Here is an interesting link explaining simply (good examples) how that works :
http://www.apptranslator.com/blog/2006/03/should-you-charge-vat-to-whom.html
And last but not least a VAT : Definition, history, and more (VAT was invented by a french, sorry for that ;o) :
http://en.wikipedia.org/wiki/Value-added_tax
I put all this also in the Jira VAT issue (366)
Jacques
Re: VAT and gross pricing
Posted by Si Chen <si...@opensourcestrategies.com>.
Jacques,
Can you post all of this on that JIRA issue you created for VAT?
I'll try to help out when I have a chance.
Also same regarding the invoice header thing--I'll take a look at it
later. Can you confirm that Eriks is right--is a tax authority Id in
the bill-to geo really required in EU? (Funny, it's the exact
opposite of the US...)
On Oct 10, 2006, at 10:57 PM, Jacques Le Roux 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)
Best Regards,
Si
sichen@opensourcestrategies.com
Re: VAT and gross pricing
Posted by Scott Gray <le...@gmail.com>.
As was mentioned previously, it's only an issue if your dealing with one
nexus. In New Zealand and Australia all items sold in a retail
situation are sold with GST (same as VAT) included in the price, it's
just the way things are, we don't like having to figure out a final cost
by adding some percentage and anyway the tax is charged on everything at
the same rate. But at the same time b2b trade usually involves GST
excl. prices because it is the end consumer who pays the tax at the end
of the day. While it's nice to have an international focus on sales
that isn't the reality for a lot of businesses.
Personally, I think if changes were to be made it would only need to be
applied to customer facing screens like ecommerce, sales order
confirmations and till receipts. The current flag on the webstore or
whatever it is should be enough unless your dealing with b2b trade.
Chris Howe wrote:
> Then let me get this straight...
> All of the hours of discussion and debuging put into
> differentiating VAT from US tax calculation is so that
> you can create a round marketing price point that will
> get screwed up if you sell in different markets with
> differing VAT rates? Interesting.
>
> I think it might be easier to topple the powers that
> be than to solve this problem ;) vive le resistance!
>
> --- Scott Gray <le...@gmail.com> wrote:
>
>
>> As the VAT is included in the price it would be:
>> 100/1.175 = 85.1063829787234
>> or
>> price/(1+VAT) = VAT exclusive
>> which would be the same as US tax
>>
>> i think the issue is more related to exclusion or
>> inclusion of tax in the
>> final price. They are both percentages on top of the
>> base price.
>>
>> Regards
>> Scott
>>
>> On 12/10/06, Chris Howe <cj...@yahoo.com>
>> wrote:
>>
>>> 100/ (1-.175) = 121.21212121212121
>>> % = 1/100
>>>
>>> --- Andrew Sykes <an...@sykesdevelopment.com>
>>>
>> wrote:
>>
>>>> Chris,
>>>>
>>>> I'm not sure I follow this...
>>>>
>>>>> VAT -> productPrice / (1-VAT) = final price
>>>>>
>>>> productPrice = 100
>>>> VAT = 17.5%
>>>>
>>>> 100 / (1-17.5) = -6.060606061 ???
>>>>
>>>> It should be...
>>>> ( productPrice / 100 ) * ( 100 + VAT ) = final
>>>>
>> price
>>
>>>> Am I misunderstanding your comment?
>>>> --
>>>> Kind Regards
>>>> Andrew Sykes <an...@sykesdevelopment.com>
>>>> Sykes Development Ltd
>>>> http://www.sykesdevelopment.com
>>>>
>>>>
>>>>
>>>
>
>
>
Re: VAT and gross pricing
Posted by Chris Howe <cj...@yahoo.com>.
Then let me get this straight...
All of the hours of discussion and debuging put into
differentiating VAT from US tax calculation is so that
you can create a round marketing price point that will
get screwed up if you sell in different markets with
differing VAT rates? Interesting.
I think it might be easier to topple the powers that
be than to solve this problem ;) vive le resistance!
--- Scott Gray <le...@gmail.com> wrote:
> As the VAT is included in the price it would be:
> 100/1.175 = 85.1063829787234
> or
> price/(1+VAT) = VAT exclusive
> which would be the same as US tax
>
> i think the issue is more related to exclusion or
> inclusion of tax in the
> final price. They are both percentages on top of the
> base price.
>
> Regards
> Scott
>
> On 12/10/06, Chris Howe <cj...@yahoo.com>
> wrote:
> >
> > 100/ (1-.175) = 121.21212121212121
> > % = 1/100
> >
> > --- Andrew Sykes <an...@sykesdevelopment.com>
> wrote:
> >
> > > Chris,
> > >
> > > I'm not sure I follow this...
> > > > VAT -> productPrice / (1-VAT) = final price
> > >
> > > productPrice = 100
> > > VAT = 17.5%
> > >
> > > 100 / (1-17.5) = -6.060606061 ???
> > >
> > > It should be...
> > > ( productPrice / 100 ) * ( 100 + VAT ) = final
> price
> > >
> > > Am I misunderstanding your comment?
> > > --
> > > Kind Regards
> > > Andrew Sykes <an...@sykesdevelopment.com>
> > > Sykes Development Ltd
> > > http://www.sykesdevelopment.com
> > >
> > >
> >
> >
>
Re: VAT and gross pricing
Posted by Scott Gray <le...@gmail.com>.
As the VAT is included in the price it would be:
100/1.175 = 85.1063829787234
or
price/(1+VAT) = VAT exclusive
which would be the same as US tax
i think the issue is more related to exclusion or inclusion of tax in the
final price. They are both percentages on top of the base price.
Regards
Scott
On 12/10/06, Chris Howe <cj...@yahoo.com> wrote:
>
> 100/ (1-.175) = 121.21212121212121
> % = 1/100
>
> --- Andrew Sykes <an...@sykesdevelopment.com> wrote:
>
> > Chris,
> >
> > I'm not sure I follow this...
> > > VAT -> productPrice / (1-VAT) = final price
> >
> > productPrice = 100
> > VAT = 17.5%
> >
> > 100 / (1-17.5) = -6.060606061 ???
> >
> > It should be...
> > ( productPrice / 100 ) * ( 100 + VAT ) = final price
> >
> > Am I misunderstanding your comment?
> > --
> > Kind Regards
> > Andrew Sykes <an...@sykesdevelopment.com>
> > Sykes Development Ltd
> > http://www.sykesdevelopment.com
> >
> >
>
>
Re: VAT and gross pricing
Posted by Chris Howe <cj...@yahoo.com>.
100/ (1-.175) = 121.21212121212121
% = 1/100
--- Andrew Sykes <an...@sykesdevelopment.com> wrote:
> Chris,
>
> I'm not sure I follow this...
> > VAT -> productPrice / (1-VAT) = final price
>
> productPrice = 100
> VAT = 17.5%
>
> 100 / (1-17.5) = -6.060606061 ???
>
> It should be...
> ( productPrice / 100 ) * ( 100 + VAT ) = final price
>
> Am I misunderstanding your comment?
> --
> Kind Regards
> Andrew Sykes <an...@sykesdevelopment.com>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
>
>
Re: VAT and gross pricing
Posted by Andrew Sykes <an...@sykesdevelopment.com>.
Chris,
I'm not sure I follow this...
> VAT -> productPrice / (1-VAT) = final price
productPrice = 100
VAT = 17.5%
100 / (1-17.5) = -6.060606061 ???
It should be...
( productPrice / 100 ) * ( 100 + VAT ) = final price
Am I misunderstanding your comment?
--
Kind Regards
Andrew Sykes <an...@sykesdevelopment.com>
Sykes Development Ltd
http://www.sykesdevelopment.com
Re: VAT and gross pricing
Posted by Chris Howe <cj...@yahoo.com>.
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 <ja...@les7arts.com>
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)
>