I would ponder having the tax in its own table.
create table tax
( rate DECIMAL not null
, date_from DATE
, date_to DATE
In my own db, I have the prices in their own columns and the applicable tax is retrieved from the db when the price is to be displayed. This means that if the tax rate changes, you only have to update the tax table with the new rate and the new start date - setting the end date of the previous tax to the last date when it was applicable.
I think you are in the UK so you may have noticed how some supermarkets had wierd prices in 2009 during the temporary 15% period. no longer ending in .99 or .49 for example, the prices ended sometimes in .23 and the shops explained this as a way of showing they hadn't taken advantage of the tax change to milk their customers. No rounding was needed, except the nearest penny).
Previous base price took account of the 17.5% so their end prices appeared normal with the 17.5% rate which of course they have now reverted to. If, as anticipated, the tax increases long term, post election, the base price would be better changed at that stage but not for a temporary levy.
Might save a lot of time if you reset the pricing to the base price and add that extra table. And I don't think it is a wise expense to undertake this price changing exercise for a third and fourth time.
I know that covers more than you asked but it may be of use as a way to manage time (therefore competitiveness), better
Just my suggestion.