@ahmedrashed3210 : you do not do VAT calcs like that. You need a VAT Table of all standard rates, then each of your charge types will have a link to that. When you pull Visa, Hotel or Ticket etc, into an invoice it will know the VAT rate to charge. You then store that calc into the VAT field to each charge line. You then add up the goods field and add up the VAT field for an invoice total.
The standard VAT Table should also have dates for the date range which the VAT Rate is applicable. As the VAT Rates change so will the VAT Table. If the VAT rates change on Dec31st, from January1st you will need to charge at the December rate as you will/can be invoicing Dec charges in Jan. There can be other complications regarding the date at which the Tax Point is set. Is it delivery date or is it invoice date?
VAT unless given some consideration and analysis can be a nightmare if incorrect. With your method if a copy of a Dec invoice is printed next July what VAT rates will it have, if the VAT rate has changed between those dates?
Strictly speaking you should show the VAT% on each line but most just show a code or nothing at all. If there are several VAT rates, 5%, 20%, due to the allocation of one line for one VAT rate, how can your invoice layout show them? Which is why the VAT rate (and/or the VAT charge) is shown on a line by line basis.
I would also advise that the goods line and VAT line totals are stored in your table as pence. (ie using INTEGER CALCS - Longs) in order that the totals on the invoice correspond with the printed values. You then total the pence and string handle the decimal to show correctly in the invoice. If you use decimal totals, using currency, singles or doubles in your Table you can have rounding errors in your totals. Using longs, totals can never be incorrect, even on invoices with a huge number of charge lines. Take a look at SAGE or Pegasus Opera invoices as a guide.