I thought it was just an overdramatic way of saying that it’s difficult to change the tax rate, but:
But a compromise has surfaced: the government is now floating the idea of reducing the tax on food to 1%, which could be done in five or six months.
How could you possibly build something this stupid? Maybe we’ll just store the tax rate, as a percentage, minus 1, in 4 bits.
I guess realistically it’s probably something about creating multiple transactions and having one of them be invalid, but wouldn’t that also break when the tax gets rounded to zero?
How could you possibly build something this stupid?
Out gereric VAT rate changed to 25,5% about a year go. It’s been a whole number since current implementation was introduced in 1994. There was quite a few big systems running on accounting, cash registers, payment processors and whatever which couldn’t store decimals on VAT value. And obviously all the official information never stated that VAT couldn’t have decimals at some point, it just never had them before and thus vendors have just stored it as an plain integer and quite a lot of systems needed upgrade or on some cases full replacement.
So, apparently it’s pretty easy to build something that stupid.
I agree with division/multiplication issue. Or maybe just simply an assumption that VAT is always there and sanity checks on the systems just won’t allow 0 (or negative number) as a tax percentage.
I meant that in general even ‘official’ systems have stupid bugs or practices just because things have been in a certain way for long time. Years ago I wrote a small invoicing program which had obviously manage VAT and it would’ve been a simple mistake to assume that VAT (or any tax percentage) is just a whole number since that’s what I’ve ever seen before. That particular piece of software is well obsolete now, but that would’ve managed the decimals since it handled all the numbers in the same way just to keep things simple and monetary values obviously need decimals. However, without any verification it wouldn’t been a crazy assumption to store tax percentages as a two digit integer everywhere.
There were concerns that if the tax rate is zero they have to check everywhere that nothing is ever divided by the tax rate or the computed tax. If it’s 1% they just have to change the number everywhere. And then I guess a significant part of the “months” that takes is also just testing, certifications, etc.
Huh, I hadn’t considered division. I guess that would explain why 0 is harder than 1, at least for tax rate. They must have already been able to handle 0 computed tax e.g. 5円 at 8%.
Have you actually seen a technical discussion about this? I find it fascinating
I thought it was just an overdramatic way of saying that it’s difficult to change the tax rate, but:
How could you possibly build something this stupid? Maybe we’ll just store the tax rate, as a percentage, minus 1, in 4 bits.
I guess realistically it’s probably something about creating multiple transactions and having one of them be invalid, but wouldn’t that also break when the tax gets rounded to zero?
Out gereric VAT rate changed to 25,5% about a year go. It’s been a whole number since current implementation was introduced in 1994. There was quite a few big systems running on accounting, cash registers, payment processors and whatever which couldn’t store decimals on VAT value. And obviously all the official information never stated that VAT couldn’t have decimals at some point, it just never had them before and thus vendors have just stored it as an plain integer and quite a lot of systems needed upgrade or on some cases full replacement.
So, apparently it’s pretty easy to build something that stupid.
That I at least sort of understand, but 1 being easier to support than 0? Neighbour comment might be onto something with the division thing.
I agree with division/multiplication issue. Or maybe just simply an assumption that VAT is always there and sanity checks on the systems just won’t allow 0 (or negative number) as a tax percentage.
I meant that in general even ‘official’ systems have stupid bugs or practices just because things have been in a certain way for long time. Years ago I wrote a small invoicing program which had obviously manage VAT and it would’ve been a simple mistake to assume that VAT (or any tax percentage) is just a whole number since that’s what I’ve ever seen before. That particular piece of software is well obsolete now, but that would’ve managed the decimals since it handled all the numbers in the same way just to keep things simple and monetary values obviously need decimals. However, without any verification it wouldn’t been a crazy assumption to store tax percentages as a two digit integer everywhere.
There were concerns that if the tax rate is zero they have to check everywhere that nothing is ever divided by the tax rate or the computed tax. If it’s 1% they just have to change the number everywhere. And then I guess a significant part of the “months” that takes is also just testing, certifications, etc.
Huh, I hadn’t considered division. I guess that would explain why 0 is harder than 1, at least for tax rate. They must have already been able to handle 0 computed tax e.g. 5円 at 8%.
Have you actually seen a technical discussion about this? I find it fascinating