[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locale-specific issues?

After reading this, I can't guarantee we will get this fixed very
soon, but as we get to the relevant portions of the software, I expect
we will be taking these concerns very seriously.


 They can all be worked around to a certain extent, it's just rough:

 - Invoices are "supposed" to have for each line the exact VAT rate in
effect stated (can be a symbol which is looked up in the index, or you can
simply asterisk anything which is non-standard).  The net and vat amount for
each line are supposed to be shown.  Then at the bottom you need to show
net, vat for each rate in effect, and gross.  In fact for 99% of common
transactions the rate will always be 17.5%, but there are some 5% goods
here, and also a peculiarity of some 0% goods...


Ok, so we need per-line tax calculation and display.  It would be
helpful if we can get a feature request submitted for this.  If I
don't see one by tomorrow evening, I will submit one.


 - In particular the invoicing breaks down (in SL!) if you tick the "VAT
Included" box when creating an invoice.  The subtotals don't *appear* to
allow the extraction of the net subtotal figure correctly?


Can you show some examples of exactly what the problem is?


 - The 0% thing is actually interesting because we have both goods at 0% VAT
and vat exempt items.  The handling is slightly different for each even
though they are arguably the same thing...  It's a historic attempt to cheat
the euro rules - basically it was required that we charge VAT on a whole
bundle of goods that we never charged VAT on before, but we were also
allowed to set the VAT rate, so we simply set a VAT rate of 0% on them
instead...  It's technically not the same as being VAT exempt on those items
though...


So, how does the software need to behave?


 - I think you will already cover shipping destinations as a tax calc, but
in the UK at least tax is charged solely on where the customer is receiving
the goods.  Businesses are different, but this is true for indivuals
(basically delivery inside EU charge VAT, delivery outside the EU charge
nothing)


So nothing complicated like tax rate set based on the township you are
sending to?  This is remakrably simple compared to what I have seen
here in the US :-(


 - Rounding is a pain.  Suppose I agree a price of £X for something, there
are several magic numbers where when you go a penny up or down then the
total goes to £X +/- £0.01, but never exactly £X.  It's a pain to have to
convert the whole invoice to "VAT Included" due to it not quite printing
correctly, simply in order to get the desired effect of rounding to the
exact amount


Exact specific problem scenarios would be helpful in helping to
resolve this for you.


 - Same problem when entering invoices from suppliers.  For sure we can
probably chuck out the odd penny here and there, but really if the supplier
incorrectly calculates tax then we should stick in what the supplier
calculates into the system.  For example I have one chap who obviously can't
use his calculator and sends me invoices where the vat on a £20 item is
often £2 out... Hard to imagine it's possible to be that wrong, but it's
impossible to enter this into the system without using multiple transactions
to straighten it all out.


Good point.  We should allow for specifically entered tax numbers for
suppliers.  Would make it simpler.


 The only workable solution I see to the last two points is that as per the
"Transaction" pages you have an override box for each line item where once
you tick it there is a (complicated) extra set of fields appear which allow
you to override the tax for that line item.  Probably it's a nightmare when
you have lots of tax rates, but I guess most jurisdictions have only a few
in practice...?  I think it's a workable solution for the majority of
countries...?


My vote (when we re-engineer the invoice system) is to have AP
invoices be entered exactly *including* the tax information.  In other
words, until the tax box is modified, it will calculate for you but
once you edit it, you are responsible for the numbers.

In the mean time, you will probably need to allow for the calculated
amount and if it is different, post an adjusting GL entry.



 At the same time it would make sense to add fields to freeze all the VAT
and address details for a given invoice.  Right now they appear to get
calculated each time and if you change something and then pull up an old
invoice and reprint it you do NOT get the old figures!!  This is a massive
no no for an accounting system and I simply don't understand why SL ever did
it this way?!!


Right,.  We need to change this.  If you don't file a bug report, I will :-)


 The whole invoice should really be stored and nothing ever
recalculated for it...


Agreed.....





 No, it's easier than that.  The "Margin Scheme" is only applicable where
you have a seperate record book and specifically record each transaction,
what you bought it for, what you paid for it and serial numbers, etc.


Ok, so we will have to wait until we allow for discrete handling of
some objects.


 It's mainly designed for the motor industry, but it can be used in other
areas as well.

 Probably for these transactions you wouldn't give the customer a VAT
receipt either (or else they would be figuring out your profit margin).
It's for individual, unique items (with a serial number generally), so the
manual override discussed above would solve this problem perfectly...


Understood.

Now, we just need to figure out how to deal with the locale specific
tax handling.  My suggestion is going to be to simply catalog those
who want to be maintainers of locale-specific modules.  But we could
bundle them if we have to (I am concerned about being responsible for
new releases every time anyone changes a tax rule though).  Imagine a
changelog for 1.2.1233: Updated tax rules for New Hampshire for June
15th change.

Best Wishes,
Chris Travers