Chances are that National’s new GST plans are keeping some small business owners up at night and making IT consultants rub their hands together with glee.
Most people will realise that a change in GST (or any other tax rate) will mean a change to any computer system that involves money. Fortunately the developers of most modern systems are usually smart enough to store things like tax percentages in the application’s configuration – well, most of them are. Murphy’s law states that as soon as anyone assumes that “The tax rate won’t ever change!” then odds are it will – tomorrow - twice.
However sometimes being able to change that figure alone isn’t enough, and that’s when the fun begins. For example, what about reporting – everyone loves reporting! If you’ve got a single setting for a certain tax rate in your system, then what happens when you’re reporting on a mix of past and present transactions? If the application calculates tax values on each transaction based on that one configuration value then the reporting will be incorrect, as it doesn’t take the variation in tax rate into consideration. Obvious, right? You’d be surprised – you really really would.
There’s many different ways to address this problem, however whatever approach is used one thing holds true – it’s always going to be cheaper if the application is designed to handle this scenario when it is built, rather than needing to have the fix retroactively applied. Hindsight is a wonderful thing, but foresight can save you a lot of money.
Last year when we were working on the ecommerce features of the Site Foundation Framework, we made some decisions around what data we’d store in the database. At the time, storing some of that information felt a little redundant – however we took the cautious route, and added a few figures which some systems may have been tempted to leave out for reasons of efficiency / disk space (the latter making very little sense with the cost of storage today).
In some ways this goes a little against the YAGNI principle however it was pretty easy to justify for the ecommerce information because when it comes to money, more information is always better. More money is always better too, but that’s another story entirely. For reasons of compliance, and of course graphing and reporting – more figures means more shiny graphs and reports, and as we know, people like their graphs and charts.
The result is that we’re currently in a position where we’re not going to have to modify any code when the tax changes kick in. We (or our customers themselves) simply update a configuration value using the Administration UI, and they’re good to go – simple.