5 ms·
I develop software algorithms for automatic processing of invoices and receipts. I have analysed hundreds of them and you'd be surprised to see how many contain
by LeonM 9y ago
I develop software algorithms for automatic processing of invoices and receipts. I have analysed hundreds of them and you'd be surprised to see how many contain errors like totals not matching the products, VAT breakdowns not matching the percentages, rounding errors etc.
In my experience this is usually because 'financial software' systems used to create invoices is sold by companies with 90% sales people, and maybe one or two developers. There seems to be little to no quality control. No one seems to care, since 'financial software' is very lucrative anyway.
In the beginning I tried to report the faulty invoices to the suppliers, thinking that the'd immediately press the big red emergency button and fix it, but in most cases the servicedesk employee does not care or even understand what I am talking about. Most of them send the 'thank you for your report, we are working very hard to fix the problem' email, but never actually fix it.
- d2p 9y agoI could understand if something was a few pence out and it seemed like it could be a rounding error; but exactly £1.50 on a bill of around £20 doesn't seem like it could be rounding/tax/etc. (In the UK, all prices shown in the menus are inclusive of VAT and then the total on the bill shows how much of the total is the VAT, so both the amount you can add up yourself from the menu and the line items shown on the bill should match the total you're paying perfectly).
- pavel_lishin 9y agoI've seen a register app coded in Javascript.
- icebraining 9y agoSo what? There are ways to do precise calculations in JS; usually you just use some library.
- pavel_lishin 9y agoThis one did not.
- Thiez 9y agoI doubt the floating point errors are going to make much of a difference with the numbers the average register has to deal with. Javascript can represent integers up to 9007199254740991 accurately, so if you do all your calculations in cents your register can process a little over 90 trillion dollars before things get problematic.
- dragonwriter 9y agoOr the first time you need to multiply by a non-integer, for tax or other purposes, and floating point imprecision affects the side of a rounding boundary you end up.
- Thiez 9y agoAnd then, in that very very rare case, the customer pays one cent more, or one cent less, and nothing bad happens? And since all amounts are in a whole number of cents, you can round to an integer after each such multiplication, and the floating point imprecision doesn't slowly add up. You could even subtract some epsilon before rounding to ensure no customers are never negatively affected by rounding. Maybe I'm getting this all wrong, as I've never had to work with a register, nor do I have any experience with the software involved, but I hardly see the problem in accumulating a few cents of inaccuracy over time.
- pavel_lishin 9y agoPaying taxes on your purchase is a very rare case? Anyway, yes, your main thesis right: it's entirely possible to do this with Javascript without screwing it up. But it wasn't in this one particular case.
- dragonwriter 9y ago> Paying taxes on your purchase is a very rare case? I think the point is that the situation where floating point error changes the result when rounded to cents is rare. Which is true, except when it is not (e.g., if you happen to have a price that tickets commonly hit that results in an error.)