VAT and gross pricing

[Jacques Le Roux]

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)

[cjhowe]

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 <[hidden email]>
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)
>

[Andrew Sykes]

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 <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[cjhowe]

100/ (1-.175) = 121.21212121212121
% = 1/100

--- Andrew Sykes <[hidden email]> 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 <[hidden email]>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
>
>

[Si Chen-2]

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
[hidden email]

[Scott Gray]

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 <[hidden email]> wrote:

>
> 100/ (1-.175) = 121.21212121212121
> % = 1/100
>
> --- Andrew Sykes <[hidden email]> 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 <[hidden email]>
> > Sykes Development Ltd
> > http://www.sykesdevelopment.com
> >
> >
>
>

[cjhowe]

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 <[hidden email]> 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 <[hidden email]>
> wrote:
> >
> > 100/ (1-.175) = 121.21212121212121
> > % = 1/100
> >
> > --- Andrew Sykes <[hidden email]>
> 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 <[hidden email]>
> > > Sykes Development Ltd
> > > http://www.sykesdevelopment.com
> > >
> > >
> >
> >
>

[Scott Gray]

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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>>    
>>> 100/ (1-.175) = 121.21212121212121
>>> % = 1/100
>>>
>>> --- Andrew Sykes <[hidden email]>
>>>      
>> 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 <[hidden email]>
>>>> Sykes Development Ltd
>>>> http://www.sykesdevelopment.com
>>>>
>>>>
>>>>        
>>>      
>
>
>  

[Jacques Le Roux]

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

[cjhowe]

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 <[hidden email]>
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
>
>

[Jacopo Cappellato]

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

[Andrew Sykes]

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 <[hidden email]>
> 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 <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Iain Fogg]

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 <[hidden email]>
>> 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

[David E Jones-2]

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

[Jacques Le Roux]

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 <[hidden email]>
> > 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 <[hidden email]>
> Sykes Development Ltd
> http://www.sykesdevelopment.com

[cjhowe]

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 <[hidden email]>
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
> <[hidden email]>
> > > 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 <[hidden email]>
> > Sykes Development Ltd
> > http://www.sykesdevelopment.com
>

[Jacques Le Roux]

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

[cjhowe]

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
>
>

[Iain Fogg]

Chris,

In Australia, it is required to show the tax-inclusive prices. There are
also rules about showing the amount of GST - if the total order is more
than $50 (I think), you need to show the GST component as a subtotal; if
it is smaller your can get away with a statement like ("The total price
includes GST"). The latter is really designed for small traders (like
corner stores) that almost never sell large quantities. There is no
legal require to show the GST component at the item level, although
there is nothing to stop you doing this provided the above rules are
adhered to (a lot of business do include the item-level tax component).

Re: your last comment, I think it is both marketing and tax. We need a
little more flexibility to be able to display the right thing to
users/customers (in this context, "the right thing" means whether to
show tax-inclusive price, ex-tax price, tax component, item level or
order level tax subtotals). The other critical thing is to make sure the
GL tracks the tax component. I've found I can do all/most of these
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

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
>>
>>
>>    
>
>
>
>  

--
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

[Iain Fogg]

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