Moving Decimal Bug Loses Money

mario.m7 writes "Poste Italiane, the Italian postal service, suffered yesterday from an abnormal computation in ATM and credit card operations, since the decimal comma was not taken into account. The whole sum was therefore multiplied by 100, resulting in a 115,00 Euro transaction being debited as 11.500 Euro! Thousands of accounts are deep in the red and locked (link pumped through translator), so that no more operations are possible. Poste Italiane is gradually recovering the problem, fixing the error and re-crediting the sum debited in excess. Consumer associations have offered support to clients in case this lasts longer and causes damage."

Comments

Re:God Bless the USA!

[Yvanhoe]

Do you know the nightmarish hell that is an Excel localized in French while being part of an international team ? Copy-paste of the same data using Excel EN or Excel FR will result in either 115.5 or 115,5 leading to interesting bugs to track...

Re:For the most part.

[Anonymous Coward]

Until you need to list many numbers in sequence. Is 153 987 182 991 equal to 153,987,182,991 or is it 153, 987, 182, & 991 or maybe 153,987 & 182,991?

Happened to me recently

[Acer500]

I made a similar mistake recently... I made a (.NET) data entry software that received monetary quantities as user input, and I converted them without taking into account the Windows settings for decimals and thousands separators.

It worked fine until somebody used a different language OS... and some strange quantities were recorded, one slipped all the way through the process and a confused customer received a bill for 17.000.000 local currency (about U$ 1.000.000) . I fixed it by using the CultureInfo, etc.. .when converting, but it wasn't nice, messed with all of the higher ups' reports and everything ("Hey, hadn't we sold about U$ 1.000.000 more?" "No, it was an error from G in Development")

I'm sure there are better ways and good practices, but keep in mind that where I work we don't even have testing, so I guess I'm getting sloppy. If someone wants to give advice, go ahead, I'll appreciate it (or at least should :) ).

Re:Happened to me recently

[Monkeedude1212]

You've got to handle that problem at the application layer, preferably as soon as possible.

Before converting it to a double or float point or whatever you are using, you have to do some data verification. Similarily, you wouldn't want someone putting in "ABC.75" dollars, because that can't be parsed, you have to handle all those scenarios. A try-catch will work for the obvious ones (like I stated) but there are some simple tips to help with the , and . translation done by the OS's.

All of it is done by handling it while its a string, before it goes to a numeric data class. You check if there are any Comma's. If so, how many characters follow the comma. 2 would be like 1,00 (one dollar) , and 3 would be like 1,000 (one thousand dollars). In no case in English formatting should a comma be followed by any less than 3 characters, and assuming they are inputing their information properly, French users won't have any more than 2.

Similarily, you apply the exact same logic for periods, just vice versa. This will allow your program to determine which standard is being used independant of operating system OS. Once you've nailed that, you can change comma's to decimals or what not depending on which case you are in, and then converting it to your double from there.

You should be able to test it on your own at least a few times, to make sure it works, then it SHOULD work across all OS languages.

The beautiful part about it is that this only needs to be done for Data Input, not Data output, since the OS (should) handles the display of Ints and other numeric Datatypes, when your users go to pull up a workorder - it should display in whatever standard they are using on their computer.

Re:God Bless the USA!

[teg]

Not only that, the function names are localized too IIRC - meaning that a simple sum() doesn't work, as you should be using summ(). Copy, paste, and just plain sharing internationally doesn't work too well.

Re:You mean 11,500 Euro

[Anonymous Coward]

That does not make sense.
Presuming the amount was 115,00 and somebody (stupidly) padded the number with zeroes it would result in 115,000 -> 115 000 Euro if we interpret the comma as a kilo seperator.
But there is not really a way that you can convert 115,00 to 11 500; not without _moving_ the seperator (or omitting it completely) and that is beyond stupidity.

Re:Periods and commas.

[mccalli]

In matters of custom, the more universally recognized method is the right one.

OK then - here you go. I await the US and Britain's change to the 'universal' standard with interest.

If you want to implement a new worldwide custom then that's fine but I suspect you will need a very good justification and not simply the desire to do something new.

New? Err...no, no this isn't new. It's centuries old. What's happened here is some US-centric programmer has forgotten to do a locale conversion. Happened to me too about ten years back when I unwisely sent .csv to Switzerland.

Cheers,
Ian

Re:For the most part.

[Anonymous Coward]

So you've obviously never coded an intrabank transfer system then. Packed decimal (using COBOL or PL/1) is the way to go...

Re:Periods and commas.

[Hatta]

If a comma is a separator, why not use it to separate decimals?

A number can only have one decimal separator. A sentence can have only one period.

A number can have many thousands separators. A sentence can have many commas.

This isn't a strong argument, but in the absence of any reason to do it otherwise it's better to do it in the marginally more consistent way.

Re:You mean 11,500 Euro

[Lord Ender]

Yeah, why can't everyone do it like I do it?

That's a bit naive of you. A better question is: why can't everyone do it the same way? Having a universal standard like this would have many advantages, while having multiple differing formats has only disadvantages.

So a reasonable person is left with the conclusion: doing it the same way everywhere is better. The question naturally follows: which would make a better standard?

The answer to this is: the English way. Why? Because when writing in any language, multiple commas may be used indicating the continuation of the sentence, just as they may be used indicating the continuation of an integer in English number notation. Furthermore, in any language, a period is used to indicate the end of a sentence, similarly to how they are used in English number notation to indicate the end of the integer.

The English way of writing numbers is simply superior, as it is consistent with the way punctuation is used in all languages.

To illustrate my point. I leave you with this bizzare. confusing continental-style punctuation use,

Silly. n'est-ce pas?

Re:Good to be a programmer

[scamper_22]

well I'm a 'formal' engineer... but let's be frank here.

The world has not come to an end.
The accounts will be fixed.
The clients will not lose any money.

Yeah, nothing would make me happy than requiring every line of software to be written by a real engineer with responsibilities, but it's more for my benefit than society's (job security, competent colleagues.. you know how doctors and lawyers do it).

In the end, society is making the trade offs.
Society is choosing to have features developed faster than a proper 'engineer' would implement them.
Society is choosing to lower the cost of programs at the expense of quality.
Society is choosing to deal with the results of bad quality instead of paying up front for quality engineers.

There is no 'right' and 'wrong' with these choices for society. It's easy to see the loss of quality. It's harder to see the loss of opportunity.

For example, you can say that only doctors should be able to prescribe medications for 'quality' reasons. Sure, it is easy to find an example where someone took a medicine they were not supposed to and it cost them their health. No doubt such a thing would make the news. Yet what about the missed opportunity? The person who doesn't see a doctor at all due to cost? Or the doctor who is too busy to properly diagnose and care for patients? Would society actually end up better off if less qualified people like nurses could prescribe medications? I'll leave that an open question.

I'll trivialize the issue even further. I've started seeing self-checkouts at many places.
Now you can most certainly pay for quality of process and make sure no body steals.
But that's not what the store/people care about. The store only cares about the following:

if( savings_from_no_cashiers > additional_money_lost_to_theft )
{
        cout "we made a good decision" endl;
}

And so it is with this bank. If they can deliver cheap systems with unregulated programmers that work without anything systemically catastrophic happening, why would they not? They will pay the cost to fix their mistake and maybe even lose business as customers loss faith in that bank.

Re:You mean 11,500 Euro

[ivucica]

I've located a bug in Opera involving decimal comma/point handling; partially they took native locale into account, partially they don't. I reported the bug, and on the newsgroup got an astonished response from a dev. I've just checked, and they've fixed it. A pretty funny bug.