Re: EU VAT

[Chris Travers <..hidden..>]

On Mon, Aug 8, 2011 at 2:19 PM, Nigel Titley <..hidden..> wrote:

> No, unfortunately that doesn't work. If I supply goods to one customer
> in France for whom I have the VAT number then I don't charge VAT but I
> have to report it on the ECSL form. On the other hand for his neighbour
> next door, for whom I don't have the VAT number, I charge VAT at the UK
> rate and *don't have to report it on the ECSL form (but I do have to
> report it as VAT).

Ok, so per customer then.  The tax form system of 1.3 would be
virtually ideal for this.  You could create three tax forms and attach
them to customer accounts, then track what's reportable or not, and
report on it.  The only issue is accrual vs cash (the current reports
are cash-basis, but accrual is easier to implement so that's not an
obstacle).
>
>> Would it be helpful to require that a transaction be tied to a
>> location (either store or shipping address)?  Then reports could be
>> generated using some sort of location-specific logic.  It would also
>> help with things like the SST insanity that seems to be sweeping the
>> US.
>
> No... it is customer specific... hence our solution using Sales
> accounts. You *could* use rough logic like

Perfect.  That makes this largely a reporting issue in 1.3.

>
> But this only works for us because we don't sell zero rated goods like
> baby clothes.

So basically we need to write EU vat tax reports.

> Cash is an option in UK, and can be helpful with cashflow

Ok, so the 1099 reports can serve as a basis there, though will
probably have to be tweaked for local rules.

>
>> > Although my personal needs would probably be served by a solution like
>> > Nigel's, I'd like to warn for the explosion of a chart of accounts, if too
>> > many information requirements are encoded into the accounts. I've worked for
>> > a company where 2 accounts have been blown up into 64 accounts, simply
>> > because they encoded required reporting information into them.
>> > The information encoded into the accounts was derived classification from
>> > the customers. As a result, the accountant was forced to redo the derivation
>> > regularly, finding differences and creating reclassification postings to
>> > keep accurate reporting information.
>
> I agree... it's a pain, but I can't think of any other way to do it in a
> general and portable fashion.

>From what you are saying in 1.2, that's probably the case.  In 1.3, we
have additional ways to categorize customers for tax reporting which
should help this a lot.
>
>> Just to be clear, in the end we would want to support whatever ways
>> people in the community find most helpful.  The larger issues have to
>> do with inventory tracking items and the fact that sales accounts
>> don't admit readily of this sort of default that Nigel is doing in
>> that case as a generally applicable approach.
>
> I'd really like to understand what the issues are with inventory
> tracking and multiple sales accounts.

Ok....  so example.... suppose I sell items I want to track in
different categories.  Maybe I sell complete computers, computer
repair services, and computer parts.  I might set up sales accounts
like:

4110 Computer Systems
4120 Computer Parts
4130 Computer Repair Services
4140 IT Consulting Services

Now I want to categorize sales by defaulting a customer account to an
income account.  I can't do that per se.  Instead I would have to
suffix them like:

4110-01 Computer Systems, VAT Taxable
4110-02 Computer Systems, Exmpt non-export
4110-03 Computer Systems, Export

etc.  However with the default account stuff, I fundamentally cannot
track accounts across multiple criteria.  Consequently, it can't work
as a general solution even if it works for a single customer.



> You need to record whether the delivery was made under the intra-EU
> reverse VAT scheme, but in my view that's a less general solution.

Ok.  Have to think about that more.

>>
>> > Nigel, does the above sound like what your perl script for ECSL form
>> > submission is doing?
>
> Yes, roughly. What my perl script does is searches for all invoices to
> EU countries (which, I must say, would be easier to do if the country
> fields were constrained to a list) and which have zero VAT. But as I
> say, this only works because we don't sell food and baby clothes.

1.3 constrains countries to a list.

>
> If we could set general attributes onto transactions then this would
> work in the general case and we could extract the appropriate reports.
> I'd be very happy to go down this route rather than the sales account
> route.

Ok,so what 1.3 does for you (and this is new since the patch was
commissioned is):

1)  Allow tax forms to be attached to customers/vendors. So you can
say "this vendor is an ECSL vendor" and "This customer is an ECSL
customer."  You could also say "This vendor is a VAT vendor" and "This
customer is a VAT customer" as well as
"This customer is a VAT export customer" etc.  This should make the
reporting a LOT easier.

2)  Countries are constrained to a list.

Is there anything else that would have to be stored that is not?

Bet wishes,
Chris Travers