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] |
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 ***************************************************************** |
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 > ***************************************************************** |
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 > ***************************************************************** |
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 |
Free forum by Nabble | Edit this page |