UK Vat will change from 17.5 to 15%. How will this affect your code?

Question

The UK VAT system is changing from 17.5% to 15%. What strategies did you use in your code for storing VAT and how changes will affect your applications. Do you keep a history of vats so you can calculate old prices or old bills stored in a separate table? Is this a simple configuration setting, or did you apply it? What is the ideal way to store VAT?

Answer 1

Do not calculate it. Save it!

HMRC is very fussy about paying the right amount of VAT. The rounding of VAT calculations is somewhat vaguely indicated in the user guides, and leaving it to future performers to understand this may pose problems. By saving the amount when entering an account / position, this problem can be avoided.

It seems like a waste of memory and a violation of the principles of redundancy, but the amount of storage used is tiny, and this can save a lot of trouble in the future. Of course, it goes without saying that currency amounts (and possibly even VAT rates with fractional parts) should be stored as a multiplied integer to avoid rounding errors of the binary representation, which is also creeping.

Central storage speed

You must absolutely use the central betting repository. However, I would recommend that this only provide the current default rates used when entering new invoices. They can be stored with start and end dates to automatically switch if necessary. These rates can be saved for each invoice (or invoice line) along with estimated VAT amounts at the time of invoicing, to give an absolute snapshot of the situation at that time.

Do not forget to take into account various VAT rates (for example, standard, reduced, zero, without VAT) and the possibility of trading with persons registered with VAT in other EU countries, where you may be required without VAT and an account that is usually taxed with VAT.

As a result, you can get a table similar to this one (example):

 id |  Rate name |  VAT rate |  Start date |  End date
 -------------------------------------------------- -  
 1 |  Standard |  1750 |  01/01/1991 |  11/30/2008
 2 |  Standard |  1500 |  12/12/2008 |  12/31/2009
 etc

The above table is just an example. The VAT rate is stored as an integer of “basis points” (for example, hundredths of a percentage point), but it assumes that the VAT rate will never be more than 2 decimal places. Obviously, you can expand it with an extra column to alleviate this problem, but it looks like it will be too far!

Answer 2

Do not store it. Calculate it!

---

My recommended way to store interest rates / percent:

You should have a table "VAT_param", for example

Interest rate | Valid from (date) | Effective until (date)

I believe,

" Everything that can be calculated does not need to be saved."

Especially in cases where you need to calculate values ​​based on the percentages of others (for example, taxes, percentages, etc.). Do not let the Time-Space compromise evade you. You bless yourself later by spending time in free space.

Then, VAT must be carefully calculated based on the effective rate for the period based on the invoice date. This will

• Provide the least redundancy (pls never talk about old tables or new tables .. within a few years you will start pulling your hair if the interest rate changes once a year)

• To control the speed, use a centralized single-threaded . Your table is VAT_param.

Answer 3

My thoughts...

a- I usually prefer to calculate through storage, but in this case, the estimated VAT (and the speed and codes used for the calculation) should be stored for each transaction. This is due to the fact that this will be the source data for documents that need to be regenerated. You also want to be able to compare the amount of VAT on the sale with the amount of VAT in the financial book. You do not want to risk not being able to re-create a document, such as an invoice or VAT report, every time.

b- The values ​​of VAT (or other taxes) must be absolutely stored in a table with effective dates and rates. If it is hard-coded, do this job now to program it, because in the near future it will change again.

c- This is a huge (and decisive) deal in the United States, as sales taxes vary between states, counties, and even cities. I live and work in Los Angeles County and the sales tax rate is 8.25%. 10 miles south in Orange County, the sales tax rate is 7.75%. The Internet and retail catalogs must know the correct bid, because it is determined by the place of delivery!

Good luck.

Answer 4

We extract VAT from the database table shared by all our internal applications, which means that it is not very important for us where our new code is. Maintaining its centralization, like this, should be a smart move.

Answer 5

I have an unpleasant feeling that the 2 systems I have inherited have a speed encoded somewhere.

Worse, if it is hard-coded, I will just replace hard-coded values, since I don’t have time to change it correctly.

Even worse, I don’t know where I am going to find the time to actually make the change. Therefore, I assume that this will not be done in time for the change on Monday. Of course, there are more interesting questions, for example, that our 10 pound subscription is based on the fact that it is 10 pounds sterling, including 17.5% VAT (8.515 pounds or something else). Now it will be £ 9.79 or so, which makes a complete mess of everything that advertises it at 10 pounds, and all site calculations based on 10 pounds.

All this, because the idiot in charge of the piggy bank wanted a headline.

Answer 6

We have VAT rates that are stored in the database table, so this is not a big deal for us, although I have to hold hand in hand and say that due to the nature of some of the changes we made to the code, VAT was hard-coded into pairs of places (my bad!), which I managed to push again in an even more exciting way!

Answer 7

I'm just working on something to do this when the speed changes.

Whatever you do, there is no need to write the start and end dates in your vat table, since vat periods start directly one after another.

You can access the correct vat by running a request similar to the one below, where vat_date is the start date of the VAT rate.

SELECT * FROM vat WHERE NOW() > vat_date ORDER BY vat_date DESC LIMIT 1 

Answer 8

Regarding the store vs calc argument. If you store it, you can always calculate it later - if you change your mind;)

Answer 9

Last night, I found a code table that stores important configuration settings for the application.

 Table tbl_config config_id int config_name varchar(255) config_value varchar(255) 

One of these options was our primary server username and password combination (unhashed). I think the developer who created it always wanted to access it if he forgot! Needless to say, it has disappeared now.