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
to be entered exTax is a royal pain in the posterior. The sooner we can
> 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
>> *****************************************************************
>>
>
>
>
>
>
>
Version: 7.1.409 / Virus Database: 268.15.25/593 - Release Date: 19/12/2006