Europe and VAT

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Europe and VAT

Roberto Santori
Hi,
I'm working at the European (Italian/Romanian) version of OfBiz and I'm struggling with VAT.

The main problem with the current version is the impossibility to separate VAT from Sales Tax.
Note also that VAT % could be different for each different line in the same order (and here a more difficult problem: rounding should be done only at VAT group level, not for each line in the order).
Finally, the management of VAT, free gift and accounting: in case of free gift (zero price) the taxable amount is 0, but the VAT MUST be paied anyway (by the client or by the vendor), based on the standard price / value of the gift.

The VAT problem is really a stopper for the entire European community. I saw the JIRA issue 366, and I'm writing to push.... Pls contact me if you need help (I'm a newbie in OfBiz but quite expert in european ERP systems management).            
 

Best regards,

Roberto Santori
[hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Europe and VAT

Andrew Ballantine
I am sympathetic to the VAT problem and have quite a bit of experience with
UK VAT.
Here are my comments:
1. UK allow calculation of VAT per item or for the whole invoice, but the
general practice is to calculate per item as it makes it easier to allow for
items with different VAT Rates and zero rated items.
2. NOT rounding the VAT on each line is a new one on me because you risk
getting an apparent rounding error unless you print the full fraction of VAT
on the invoice. This could cause problems on returns/refunds.
3. In general values printed on any financial document should add up exactly
so the rounding is generally done per item, in the UK anyway.
4. Accounting is generally done in whole cents/pence thus avoiding any
rounding errors providing the data is stored in whole cents/pence e.g.
Binary Coded Decimal. I understand that some bulk product items are priced
in fractions, but this is rounded at the item line in the invoice i.e. when
it has to enter the accounts.
5. Accounting generally keeps tax and VAT out of the profit and loss
accounting so that the tax/VAT is separated from each item/invoice and
recorded in a different account.

The logical thing for ofbiz to do to satisfy a variety of tax styles is to
have flags in the database at company level that the code checks and acts
accordingly. We are unlikely to come up with a scheme that works for all.

The flags required might be something like this:
USA
        Tax whole invoice
        Check customer location and local tax rules
        Round whole invoice
UK
        Tax by line
        Round each line
I (Italy)
        Tax by line
        Round whole invoice
and others

For ofbiz to be an international solution, potentially for global
corporations this is the structure needed. I assume that everyone is doing
local modifications to get around these issues at the moment, so a generic
solution is needed if a little difficult, at first, to implement.
Hope this is of interest.

Kind regards,

Andrew Ballantine.

-----Original Message-----
From: Roberto Santori [mailto:[hidden email]]
Sent: 19 December 2006 15:26
To: [hidden email]
Subject: Europe and VAT


Hi,
I'm working at the European (Italian/Romanian) version of OfBiz and I'm
struggling with VAT.

The main problem with the current version is the impossibility to separate
VAT from Sales Tax.
Note also that VAT % could be different for each different line in the same
order (and here a more difficult problem: rounding should be done only at
VAT group level, not for each line in the order).
Finally, the management of VAT, free gift and accounting: in case of free
gift (zero price) the taxable amount is 0, but the VAT MUST be paied anyway
(by the client or by the vendor), based on the standard price / value of the
gift.

The VAT problem is really a stopper for the entire European community. I saw
the JIRA issue 366, and I'm writing to push.... Pls contact me if you need
help (I'm a newbie in OfBiz but quite expert in european ERP systems
management).


Best regards,

Roberto Santori
[hidden email]
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.15.24/592 - Release Date: 18/12/2006
13:45

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.15.24/592 - Release Date: 18/12/2006
13:45



*****************************************************************
This email has been checked by the altohiway Mailcontroller Service
*****************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Europe and VAT

David E Jones-2

Just to quickly start a direction for this thread: the current  
TaxAuthority data model and code based on it supports a lot of these  
different things.

-David


On Dec 19, 2006, at 9:29 AM, Andrew Ballantine wrote:

> I am sympathetic to the VAT problem and have quite a bit of  
> experience with
> UK VAT.
> Here are my comments:
> 1. UK allow calculation of VAT per item or for the whole invoice,  
> but the
> general practice is to calculate per item as it makes it easier to  
> allow for
> items with different VAT Rates and zero rated items.
> 2. NOT rounding the VAT on each line is a new one on me because you  
> risk
> getting an apparent rounding error unless you print the full  
> fraction of VAT
> on the invoice. This could cause problems on returns/refunds.
> 3. In general values printed on any financial document should add  
> up exactly
> so the rounding is generally done per item, in the UK anyway.
> 4. Accounting is generally done in whole cents/pence thus avoiding any
> rounding errors providing the data is stored in whole cents/pence e.g.
> Binary Coded Decimal. I understand that some bulk product items are  
> priced
> in fractions, but this is rounded at the item line in the invoice  
> i.e. when
> it has to enter the accounts.
> 5. Accounting generally keeps tax and VAT out of the profit and loss
> accounting so that the tax/VAT is separated from each item/invoice and
> recorded in a different account.
>
> The logical thing for ofbiz to do to satisfy a variety of tax  
> styles is to
> have flags in the database at company level that the code checks  
> and acts
> accordingly. We are unlikely to come up with a scheme that works  
> for all.
>
> The flags required might be something like this:
> USA
> Tax whole invoice
> Check customer location and local tax rules
> Round whole invoice
> UK
> Tax by line
> Round each line
> I (Italy)
> Tax by line
> Round whole invoice
> and others
>
> For ofbiz to be an international solution, potentially for global
> corporations this is the structure needed. I assume that everyone  
> is doing
> local modifications to get around these issues at the moment, so a  
> generic
> solution is needed if a little difficult, at first, to implement.
> Hope this is of interest.
>
> Kind regards,
>
> Andrew Ballantine.
>
> -----Original Message-----
> From: Roberto Santori [mailto:[hidden email]]
> Sent: 19 December 2006 15:26
> To: [hidden email]
> Subject: Europe and VAT
>
>
> Hi,
> I'm working at the European (Italian/Romanian) version of OfBiz and  
> I'm
> struggling with VAT.
>
> The main problem with the current version is the impossibility to  
> separate
> VAT from Sales Tax.
> Note also that VAT % could be different for each different line in  
> the same
> order (and here a more difficult problem: rounding should be done  
> only at
> VAT group level, not for each line in the order).
> Finally, the management of VAT, free gift and accounting: in case  
> of free
> gift (zero price) the taxable amount is 0, but the VAT MUST be  
> paied anyway
> (by the client or by the vendor), based on the standard price /  
> value of the
> gift.
>
> The VAT problem is really a stopper for the entire European  
> community. I saw
> the JIRA issue 366, and I'm writing to push.... Pls contact me if  
> you need
> help (I'm a newbie in OfBiz but quite expert in european ERP systems
> management).
>
>
> Best regards,
>
> Roberto Santori
> [hidden email]
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.15.24/592 - Release Date:  
> 18/12/2006
> 13:45
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.15.24/592 - Release Date:  
> 18/12/2006
> 13:45
>
>
>
> *****************************************************************
> This email has been checked by the altohiway Mailcontroller Service
> *****************************************************************

Reply | Threaded
Open this post in threaded view
|

RE: Europe and VAT

David Garrett
I have started a VAT implementation. It is currently in JIRA
https://issues.apache.org/jira/browse/OFBIZ-416

I am happy with the way it has been stuctured at his point, but there are
improvements that I am aware that could be made. To date I have not received
any feedback as to the appropriateness of the implementation. (I understand
why... It is a BIG change.)

The general approach is based on keeping the product prices exTax and using
adjustments to store the VAT. While this works it leads to a further
complication when dealling with VAT on adjustments(such as shipping).

The current Jira patch allows (for my simple case) the creation of a
shopping cart, creation of an order, it deals with price rules and
adjustments correctly, it generates an invoice and posts to GL (probably
wrong accounts at the moment). The user interface has been altered for
ecommerce and not all of ordermgr (eg cart->order not done yet in ordermgr).
The database entries appear to be correct more work now is required on
formatting these for the user interface. (Note: UI has still debug and todo
notes which need implementation or fixing)

Not done and issues:
- returns
- probably need to create a relationship between adjustment and the tax on
that adjustment. This complicates the adjustment code at the moment.

What Next
Wait till after the Christmas period .... Let those shopping carts ring!!!!
Then get back and fix up the user interface, take out the debug and we may
have a usable 1st pass.


Comments welcome!

David G
 

-----Original Message-----
From: David E Jones [mailto:[hidden email]]
Sent: Wednesday, 20 December 2006 5:43 AM
To: [hidden email]
Subject: Re: Europe and VAT


Just to quickly start a direction for this thread: the current TaxAuthority
data model and code based on it supports a lot of these different things.

-David


On Dec 19, 2006, at 9:29 AM, Andrew Ballantine wrote:

> I am sympathetic to the VAT problem and have quite a bit of experience
> with UK VAT.
> Here are my comments:
> 1. UK allow calculation of VAT per item or for the whole invoice, but
> the general practice is to calculate per item as it makes it easier to
> allow for items with different VAT Rates and zero rated items.
> 2. NOT rounding the VAT on each line is a new one on me because you
> risk getting an apparent rounding error unless you print the full
> fraction of VAT on the invoice. This could cause problems on
> returns/refunds.
> 3. In general values printed on any financial document should add up
> exactly so the rounding is generally done per item, in the UK anyway.
> 4. Accounting is generally done in whole cents/pence thus avoiding any
> rounding errors providing the data is stored in whole cents/pence e.g.
> Binary Coded Decimal. I understand that some bulk product items are
> priced in fractions, but this is rounded at the item line in the
> invoice i.e. when it has to enter the accounts.
> 5. Accounting generally keeps tax and VAT out of the profit and loss
> accounting so that the tax/VAT is separated from each item/invoice and
> recorded in a different account.
>
> The logical thing for ofbiz to do to satisfy a variety of tax styles
> is to have flags in the database at company level that the code checks
> and acts accordingly. We are unlikely to come up with a scheme that
> works for all.
>
> The flags required might be something like this:
> USA
> Tax whole invoice
> Check customer location and local tax rules
> Round whole invoice
> UK
> Tax by line
> Round each line
> I (Italy)
> Tax by line
> Round whole invoice
> and others
>
> For ofbiz to be an international solution, potentially for global
> corporations this is the structure needed. I assume that everyone is
> doing local modifications to get around these issues at the moment, so
> a generic solution is needed if a little difficult, at first, to
> implement.
> Hope this is of interest.
>
> Kind regards,
>
> Andrew Ballantine.
>
> -----Original Message-----
> From: Roberto Santori [mailto:[hidden email]]
> Sent: 19 December 2006 15:26
> To: [hidden email]
> Subject: Europe and VAT
>
>
> Hi,
> I'm working at the European (Italian/Romanian) version of OfBiz and
> I'm struggling with VAT.
>
> The main problem with the current version is the impossibility to
> separate VAT from Sales Tax.
> Note also that VAT % could be different for each different line in the
> same order (and here a more difficult problem: rounding should be done
> only at VAT group level, not for each line in the order).
> Finally, the management of VAT, free gift and accounting: in case of
> free gift (zero price) the taxable amount is 0, but the VAT MUST be
> paied anyway (by the client or by the vendor), based on the standard
> price / value of the gift.
>
> The VAT problem is really a stopper for the entire European community.
> I saw the JIRA issue 366, and I'm writing to push.... Pls contact me
> if you need help (I'm a newbie in OfBiz but quite expert in european
> ERP systems management).
>
>
> Best regards,
>
> Roberto Santori
> [hidden email]
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.15.24/592 - Release Date:  
> 18/12/2006
> 13:45
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.15.24/592 - Release Date:  
> 18/12/2006
> 13:45
>
>
>
> *****************************************************************
> This email has been checked by the altohiway Mailcontroller Service
> *****************************************************************



Reply | Threaded
Open this post in threaded view
|

Re: Europe and VAT

Iain Fogg
David,

Needless to say, I'm very interested in the work you're doing to provide
better support for VAT/GST. Unfortunately, I'm in production and real
busy at the moment. I'd like to branch my SVN after Xmas and do some
testing...

You're right, having to make adjustments and remembering that they need
to be entered exTax is a royal pain in the posterior. The sooner we can
get OFBiz supporting exTax/incTax as a configuration parameter and have
all the UIs, services, etc respect this config the better.

Cheers, Iain


David Garrett wrote:

> I have started a VAT implementation. It is currently in JIRA
> https://issues.apache.org/jira/browse/OFBIZ-416
>
> I am happy with the way it has been stuctured at his point, but there are
> improvements that I am aware that could be made. To date I have not received
> any feedback as to the appropriateness of the implementation. (I understand
> why... It is a BIG change.)
>
> The general approach is based on keeping the product prices exTax and using
> adjustments to store the VAT. While this works it leads to a further
> complication when dealling with VAT on adjustments(such as shipping).
>
> The current Jira patch allows (for my simple case) the creation of a
> shopping cart, creation of an order, it deals with price rules and
> adjustments correctly, it generates an invoice and posts to GL (probably
> wrong accounts at the moment). The user interface has been altered for
> ecommerce and not all of ordermgr (eg cart->order not done yet in ordermgr).
> The database entries appear to be correct more work now is required on
> formatting these for the user interface. (Note: UI has still debug and todo
> notes which need implementation or fixing)
>
> Not done and issues:
> - returns
> - probably need to create a relationship between adjustment and the tax on
> that adjustment. This complicates the adjustment code at the moment.
>
> What Next
> Wait till after the Christmas period .... Let those shopping carts ring!!!!
> Then get back and fix up the user interface, take out the debug and we may
> have a usable 1st pass.
>
>
> Comments welcome!
>
> David G
>  
>
> -----Original Message-----
> From: David E Jones [mailto:[hidden email]]
> Sent: Wednesday, 20 December 2006 5:43 AM
> To: [hidden email]
> Subject: Re: Europe and VAT
>
>
> Just to quickly start a direction for this thread: the current TaxAuthority
> data model and code based on it supports a lot of these different things.
>
> -David
>
>
> On Dec 19, 2006, at 9:29 AM, Andrew Ballantine wrote:
>
>  
>> I am sympathetic to the VAT problem and have quite a bit of experience
>> with UK VAT.
>> Here are my comments:
>> 1. UK allow calculation of VAT per item or for the whole invoice, but
>> the general practice is to calculate per item as it makes it easier to
>> allow for items with different VAT Rates and zero rated items.
>> 2. NOT rounding the VAT on each line is a new one on me because you
>> risk getting an apparent rounding error unless you print the full
>> fraction of VAT on the invoice. This could cause problems on
>> returns/refunds.
>> 3. In general values printed on any financial document should add up
>> exactly so the rounding is generally done per item, in the UK anyway.
>> 4. Accounting is generally done in whole cents/pence thus avoiding any
>> rounding errors providing the data is stored in whole cents/pence e.g.
>> Binary Coded Decimal. I understand that some bulk product items are
>> priced in fractions, but this is rounded at the item line in the
>> invoice i.e. when it has to enter the accounts.
>> 5. Accounting generally keeps tax and VAT out of the profit and loss
>> accounting so that the tax/VAT is separated from each item/invoice and
>> recorded in a different account.
>>
>> The logical thing for ofbiz to do to satisfy a variety of tax styles
>> is to have flags in the database at company level that the code checks
>> and acts accordingly. We are unlikely to come up with a scheme that
>> works for all.
>>
>> The flags required might be something like this:
>> USA
>> Tax whole invoice
>> Check customer location and local tax rules
>> Round whole invoice
>> UK
>> Tax by line
>> Round each line
>> I (Italy)
>> Tax by line
>> Round whole invoice
>> and others
>>
>> For ofbiz to be an international solution, potentially for global
>> corporations this is the structure needed. I assume that everyone is
>> doing local modifications to get around these issues at the moment, so
>> a generic solution is needed if a little difficult, at first, to
>> implement.
>> Hope this is of interest.
>>
>> Kind regards,
>>
>> Andrew Ballantine.
>>
>> -----Original Message-----
>> From: Roberto Santori [mailto:[hidden email]]
>> Sent: 19 December 2006 15:26
>> To: [hidden email]
>> Subject: Europe and VAT
>>
>>
>> Hi,
>> I'm working at the European (Italian/Romanian) version of OfBiz and
>> I'm struggling with VAT.
>>
>> The main problem with the current version is the impossibility to
>> separate VAT from Sales Tax.
>> Note also that VAT % could be different for each different line in the
>> same order (and here a more difficult problem: rounding should be done
>> only at VAT group level, not for each line in the order).
>> Finally, the management of VAT, free gift and accounting: in case of
>> free gift (zero price) the taxable amount is 0, but the VAT MUST be
>> paied anyway (by the client or by the vendor), based on the standard
>> price / value of the gift.
>>
>> The VAT problem is really a stopper for the entire European community.
>> I saw the JIRA issue 366, and I'm writing to push.... Pls contact me
>> if you need help (I'm a newbie in OfBiz but quite expert in european
>> ERP systems management).
>>
>>
>> Best regards,
>>
>> Roberto Santori
>> [hidden email]
>> --
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.432 / Virus Database: 268.15.24/592 - Release Date:  
>> 18/12/2006
>> 13:45
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Free Edition.
>> Version: 7.5.432 / Virus Database: 268.15.24/592 - Release Date:  
>> 18/12/2006
>> 13:45
>>
>>
>>
>> *****************************************************************
>> This email has been checked by the altohiway Mailcontroller Service
>> *****************************************************************
>>    
>
>
>
>
>
>  



--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.25/593 - Release Date: 19/12/2006