Oops...
A great read from a website I just stumbled across:
The Daily WTF
The story in question is this one:
Don't Worry, We'll Fix It!
Don't Worry, We'll Fix It!
We're in a bit of a jam, an email to the support desk read, we accidentally ran an entire day's worth of transactions for 11 Oct 2009 instead of 11 Oct 2006. Can you fix this?
In the world of retail, it's not an uncommon practice to "open" for a business date that is not the current date. Think of 24-hour stores that want to "close" the day at 11:00 PM instead of midnight, or the cases when the registers are out of commission. Whatever the reason, it's a feature that customers want and a feature that T. Ferguson's company provides in their point-of-sale systems.
Obviously, there's no way for the software to know if a different date is purposeful or accidental; all it can do is default the "open" date to the current date and hope that someone would notice a mistake on the registers, receipts, etc. before the day was "closed" out. The support email was the first "problem" that T.'s company had with this feature since first offering fifteen years ago.
Despite having a nation-wide chain of stores, with each bringing in nearly $500,000/day in sales, this company decided not to go for the extended-hours support contract. With no one to call at 9:30 PM for support, the shift manager ignored the incorrect date and "closed out" the store's point-of-sale system. He left a note for the general manager, who promptly emailed support the next morning.
The general manager also called the support line at 9:01 AM -- just after it opened -- to make sure they got the email. He was very concerned that the error would gravely impact their October reports, forecasting reports, inventory, and just about anything else that relied on that day's transactional data. The support rep assured the general manager that the development team was working on a way to fix the issue.
From a programming perspective, this was actually an easy thing to fix. All of the daily transactions are stored in a single database table, so a simple UPDATE script and a "re-close" should do the trick. They reproduced the "problem" on a test machine, ran the fix script, and watched it worked like a charm. T. called up the store to let the manager know how they planned to resolve the issue.
"But," the manager asked, "what about when someone makes a return? Their printed receipt will have a different transaction date. Won't the register refuse the return?"
"Nope," T. replied, "we only use the store number, register number, and transaction number when we validate the receipts for returns."
"Sounds great," the manager said in a much less stressful tone, "what a relief! I was really worried about how bad this would be."
Of course it was not that easy... The technical support group made a fix and the store technicians ran it but when they opened their database, they only found that one day's worth of transactions...
From the story:
The technician reported this back to the development team. After a bit of digging, they figured out why only the one day of data was left: part of the register closing code purges data that's over three years old. And how does one find three-year old data when the system clock is not a reliable indicator? Why, by taking the business date of the newest transaction and subtracting three years, of course!
The manager's day was about to get much, much worse.
Makes you wonder why the TLA for
Point of Sale is the same as the one for
Piece of S*it. And this sort of "automatic feature" is common even in high-end software -- a simple dialog box asking if you wanted to purge old data or purging the data quietly but writing it to another database file named with today's date would be the way to go...
(stepping off programming soapbox)
Posted by DaveH at November 28, 2006 9:02 PM