Menu
The UK VAT system is changing from 17.5% to 15%. What strategies have you used in your code to store the VAT, and how will the change affect your applications. Do you store a history of vats so you can calculate old prices, or are old invoices stored in a separate table? Is it a simple config setting, or did you bodge it? What's the ideal way to store VAT?
653
Persons who are registered for VAT on the date of a change of a VAT rate(s) must account for VAT at the new rate(s) even though they may have been invoiced with VAT at the old rates. Such persons will already have been entitled to a credit for VAT on the purchase of that stock, subject to the usual conditions.
Temporary VAT cuts stimulate consumer purchases by reducing the post-tax prices individuals pay for goods and services. This in turn increases consumers' purchases of goods through two channels. Firstly, there is an income effect. Put simply, by reducing consumers' bills, a VAT cut puts money in their pockets.
If prices of goods and services fall, then the real income of consumers will increase - people will have more discretionary income to spend and therefore AD will rise. Some retailers might choose to take advantage of a lower % rate of VAT by keeping their prices constant and making higher profits.
The Minister of Finance announced a VAT rate increase from 14% to 15% effective 1 April 2018 in the 2018 Budget Speech.
HMRC are very fussy about getting paid the right amount of VAT. The rounding of VAT calculations is somewhat vaguely specified in the user guides, and leaving it up to future implementers to get it right is possibly asking for trouble. By storing the amount when the invoice/line-item is entered, this problem is avoided.
This seems like a waste of storage and a violation of redundancy principles, but the amount of storage involved is tiny and it could save a lot of trouble in the future. Of course, it goes without saying that the currency amounts (and potentially even VAT rates with a fractional part) should be stored as a multiplied integer to avoid binary fractional representation rounding errors creeping in too.
You should absolutely use central rate storage. However, I would recommend that this only provides the current default rates used when entering new invoices. These can be stored with start and end dates to give automatic changeover if necessary. These rates can be stored for each invoice (or invoice line) along with the calculated VAT amounts at the time the invoice is raised to give an absolute snapshot of the situation at the time.
Don't forget to accommodate the different VAT rates too (e.g. standard, reduced, zero-rated, no-VAT) and the possibility of trading with VAT registered entities in other EU countries where you may have to no-VAT an invoice that would normally be subject to VAT.
You could end up with a table like this (example):
id | Rate name | VAT rate | Start date | End date --------------------------------------------------- 1 | Standard | 1750 | 01/01/1991 | 30/11/2008 2 | Standard | 1500 | 01/12/2008 | 31/12/2009 etc
The above table is only an example. The VAT rate is stored as an integer of "basis points" (e.g. hundredths of a percentage point), but does assume that the VAT rate will never be to more than 2 decimal places. You could obviously extend this with an extra column to relieve this problem, but it would seem possibly a step too far!
171
My recommended way of storing percentage based rates/interest is:
You should have a table 'VAT_param' like
Interest rate | Effective from (date) | Effective Till(date)
I believe,
"Anything that can be calculated, should not be saved"
Especially in such cases where you need to calculate values based on percentage of others (like taxes, interest, etc.) Don't let the Time-Space trade-off dodge you. You'll bless yourself later for spending time over space.
Then the VAT should be neatly calculated based on the effective rate during the period, based on the Invoice date. It will
Ensure least redundancy (pls. never talk about old tables or new tables.. over a few years you'll start pulling your hairs if the interest rate changes once an year)
Have a centralised single-pivot to control the rate. Your VAT_param table.
21
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
