- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
incompetance knows no bounds.
-Adam
Wine Making Journal
Admin
A certain franchisee for a Pizza chain had the same issue with their POS.
To top it off, they tried to store many store's data in an Access Database in 2000.
Admin
Ooh, nice example of one hand not knowing what the other does! Perhaps a case of management thought monkeys with typewriters were cheaper and statistically identical to competent programmers?
Joke aside, I can see how this problem might arise, but it is hell of an arsine, not to say lethal, bug.
Admin
Well, that should be an easy fix, yeah.
Just get every customer to bring in their receipts from the last three years.
Admin
I just had to deal with something like this from a user's standpoint
Somehow for the first three hours the store was open on November the 25th, the system thought that it was actually November 24th (this is probably related to processing the end day for Black Friday.) The records were corrected quickly, but it doesn't fix the fact that our return system requires store number, transaction number and date. That means for the next several months I have to look for reciepts labeled the 24th and manually correct them to the 25th whenever I get a reciept that the system doesn't recognize.
Admin
There is a reason why so many POS's are a P.O.S.
Enough said.
CAPTCHA: craptastic
Admin
That's a WTF in itself...with everything from Internet to radio receivers available, a database server for anything that touches money should absolutely know the correct time, +/- one second. One would assume that this system is doing at least a nightly data upload even if it doesn't have full-time live networking to home base...
And...note to self: expire old data by counting distinct days in the transaction database.
Admin
Poor bastards. Once enough customers figure out they can return anything (you can't deny a return), the looting will commence.
/captha: stfu. Like what the sales clerks will be thinking, over and over and over...
Admin
sounds like an easy fix to me. take the previous full backup, and then add all the incremental daily backups until the day of the issue. then merge in single day data.
Oh wait, don't tell me, they didn't store backups?
Admin
Are you telling me that a company which provides point of sale systems to a huge retailer like this would not have a daily backup? come on!
If they didn't, that in itself is a huge WTF. Not to mention the fact that they should have been looking at the current day to determine the cutoff for 3 years of data, not the business transaction date.
Admin
As a non-programmer many of these are beyond me, but when i got to the end of this one I went "OOHHHH!"
That's nasty.
Admin
see, it made sense at the time the programmers got to the point of "if it's 3 years old or older purge it" but they forgot they're dealing with a POS and users who don't know much of anything other than I have inventory and gosh darn it I'm selling it. Nice to know their dba doesn't have a log to go by...or is that a little minor detail they also forgot to tell the developers about?
Admin
...backups? If you reach for the backup tapes and somehow the AC has dumped water on them, THEN it's a real WTF!
Admin
I think that regardless of the checks you put into the system to try to prevent this, you are are still going to rely on cashiers to put in reasonable data.
Basic problem: You need to close the register. You prompt the cashier for the next days date (you have to prompt because you may perform multiple closes within a single calendar date). The cashier can fat-finger the date.
Basic problem 2: You need to archive transaction data. Somehow the decision was made to archive date over three years old. Maybe this wasn't archived and just deleted (that is a problem).
So how many checks can you put into the system to try to prevent this? You ask the cashier if they are really, really sure about the input date. You know the cashier is just going to click ok and next until the cash register does what he wants (man over machine, you know). You can require manager approval if the date delta is going to cause data deletion (say that three times fast).
You still are asking for your data to be protected by people barely making over minimum wage...
(and if you couldn't tell - I have worked in the retail POS business in a past life)
Admin
That's not THAT big a deal--restore from backup and merge the 2009 data in with the correct dates... In retrospect, a better idea would be to have the purge functionality called manually--File | Database Maintainence | Purge Old Data. But I think the solution provided wasn't the worst one possible and apparently worked for many customers for 15 years. Perhaps another good idea would be to raise a warning when the business date and the system date are off by more than 24 hours.
Admin
Apparently people have never heard of NTP.
Admin
Admin
The purge process maybe-coulda-shoulda purged transactions into a separate transaction file. Keep them forever! Take too much disk space to do it that way? Well... Purge into a separate files for every month's data. Then delete any files with a time/date stamp over three years old... Wait, we're back where we started.
Admin
Oh, they had backups, printed out, and photographed on a wooden table, then digitized, and stored in the same database as xml
Admin
As it said in the original, it is not uncommon for an open or close to be for a date that isn't the current date. Having a highly-accurate system time doesn't help in this case.
Admin
Kudos to the tech for catching the deleted data! The manager's day could have been much, much, much worse if that little detail had been missed.
Admin
The user's of our POS product crack me up, they're so pathetic. They get so stressed out over the most retarded things. Like if one of their 8 tills break it's the end of the fucking world and they can't believe we won't be able to get them a replacement in one hour. I guess there's a reason they make minimum wage. That or you get some super cheapass motherfucker of an owner who won't even buy a 100$ UPS then phones in in a panic because the power flickered.
Admin
Aside from the fact that they should have a daily backup, in reality a 'purge' is never a purge, it should, at the least) be spun out to tape and then cleared. I don't know of any reasonable system that just does an automatic 'delete' without any sort of automatic contingency.
Admin
Word! I doubt that many tech's would have caught that.
Admin
Wow!.. this site is not only senseless fun, Is also usefull!. I have this bug on one of my applications. I think I will need to check that. : /
Admin
I bet the words "History Table" where creeping into their heads right then.
Admin
Of course, when I did my time in the trenches, I noticed the POS system was a nice pile of junk. Usability wise, it could have used a little work. Security was lacking (I could use the dummy account to change daily balances. The first day I was trained how to avoid the manager check for canceling a sale [you needed manager's password to cancel a transaction with items or continue a sale after deleting an item, but you could cancel a sale in which you deleted all the items...]). Half the features were only partially implemented.
But the best part was that the registers could be crashed with certian combinations of key strokes ( and for a while, a certian key would crash the system -- useful for punishing people who annoyed me too much. That and demagnitizing their credit cards with the magnet on my nametag.) Oh, and occasionally, the machines would get triggered so that they went down one by one over the course of an hour and took as long to get any working (I couldn't get that to replicate consistantly).
So I think perhaps there are idiots on both ends? :P
Admin
It is also surprising that a retail chain grew to that size ($500,000 a day) without this occuring sooner! They would have had the benefit of "experience*" then.
*Experience is the name we give to our mistakes.
Admin
I physically winced.
Admin
I think he means that knowing the actual time/date would prevent purging of "old" data that really wasn't old. The problem is not allowing future dates to be entered, the problem is assuming this date is actually close to the actual date.
Admin
In my past life I worked for the company with the big arches over their name and even then I knew that if one of the part time managers boned up to this extent it NEVER affected past data, at worst we had to manually enter the days product mix and hourly sales tracking but not 3 years worth. That a pos system takes care of archives just doesn't make sense, it's a back office job. For a company that is nation-wide chain of stores, with each bringing in nearly $500,000/day in sales their WTF is buying such a craptastic system.
Admin
What date was on all the credit/debit card transactions? They probably have another big WTF to get that straight with the card processing agency!
Wonder if the customers get to wait three years for the transaction to appear on their statement? LOL
Admin
IF RECEIPT.AGE = "OLD"
THEN RETURN "I LOST MY RECEIPT."
Admin
Wow, things have gone downhill since the last time I worked for *insert major credit card company here*.
There are so many WTFs here, it's hard to say where to begin. But every story has a beginning and an ending, and usually a mddle ... so, are we sitting comfortably? Then I'll begin.
(1) Apparently no backups. Audit trail? Financial data? Real(ish) time capture and commit? WTF #1.
(2) And yes, backups on their own are not sufficient. I wouldn't admit this, except that I cut my old company's name out, but sometimes we had to write scripts (of course, in those days, we called it "programming in C") to fix the database. It's difficult to say whether this is WTF #2, but it probably is.
(3) What's all this whining about time-stamps? Oh yeah, I get it. I spent eighteen months writing a 350 page re-engineering document about how POS works for *insert major credit card company here*, and all the developers, testers, managers and god-knows-what-else-ers could do is moan about timestamps. (There are basically three of these in ISO8583, if memory serves.)
And none of them are important, except in that you have to figure out what they mean on your system. I don't think that UTC or a network time server would help here. This is programming, matey. WTF #3.
(4) Wot, no paperwork? Tear yourself away from the computer for a while and make the assumption that you own and run a corner store. Do you trust your POS supplier? Hell no. One of my major pains (although absolutely justified) when working for *insert major credit card company here* was ensuring that, when we did screw up, we had enough information at our end to hire, ooh, I dunno, maybe three or four hundred temporary data entry clerks and the like to sort it out. Yes, you got it. That takes paper backup/ WTF #4.
(5) Testing. How did anything get into production that would allow such a stupid decision as to delete all previous transactions based on the date of the current transaction? This is a big, big, WTF #5.
(6) Why would anyone buy a POS system from these bozos? WTF #6 thru infinity...
BTW, I just deal with large-scale systems and stuff. What's a "tech"? Is it like a Klingon, only with bad breath?
Admin
Oh, my God, my blood actually ran cold when I read that...
Admin
Note to self: Archive expired data instead of deleting it.
Further note to self: Make sure all data has backups.
Admin
Sure it helps.
<p>"The transaction date you selected is more than [three days | a week | a month | a year] in the [future | past]. Do you want to continue?"
"You are about to close for a day that is 3 years in the future. Do you want to continue?"
Admin
Now purging is a feature that I would'n implements without a backup or warehousing.
We had a problem with a server that on daylight saving time change would change to some random date, thank god we did not create any code that did any DELETE's.
Admin
A better system would probably store the actual system time with every transaction and have a separate "business date" field that stored the entered date. The only thing you'd use the business date for would be to query all transactions for a particular date.
A sane system would also put up a warning or even an error if the user tried to enter a business date that wasn't within a day of the actual system date.
Admin
Admin
If they didn't have backups in place, then the store's fate is well deserved. If they did, then this shouldn't be a big deal from the manager's point of view.
However, if they didn't have backups, to what degree is the software vendor responsible for the loss of data, considering that it was their crazy stupid bug that did the data wipe in the first place?
Admin
Spelling has well-defined bounds and you are outside of them.
Admin
A whole bunch, as a POS should be a "turn-key" system handling all aspects of the data's lifetime, including backup.
Further, consider the example given as the premise for having this feature in the first place: a 24-hour store, wanting to close out at 11PM instead of midnight. OK, so what date/time do we put on the transactions that take place between 11pm & midnight? If we stamp them with the correct time but the new day, they will sort after all the other transactions that day, even though they took place eariler. Or we could start stampingthem as midnight, and have every transaction off by an hour.
The only sensible (and pretty much necessary for internal audit) method would be to have an actual date/time field and a businessday field.
Admin
Everyone knows that you then need to have a box for the user to type "Y" "E" "S" as a failsafe to ensure that they understand what they are doing.. no clicking or shortcuts.. I tease, but only because I've seen it done ;)
Admin
So what exactly does it mean to "purge" old transactions? Hopefully, it means inserting into an archive partition prior to performing the delete. That simplifies disaster recovery, auditing, and historical reporting.
Admin
If you aren't going to do the necessary backups, then at least you should ARCHIVE records to another file instead of PURGING them.
Admin
Just how reliable does a clock have to be if you're going to be still keeping 3 years worth of data? Are they worried about accidentally deleting transactions that are only 2 years, 11 months, 30 days, 23 hours old that they need to keep? And by the way, what more reliable clock was used to record the business date of the last transaction?
Admin
BWAAAA! Thanks for playing! The correct answer is: "All users are stupid. No data submitted by a user should ever be taken at face value."
I deal with a lot of processes that take user input or user data or just a monkey pushing the button, and I have problems all down the line. There are no two ways about it. Users will find creative ways of screwing you if you ever give them the opportunity.
The WTF today is a prime example. That is a perfectly good solution, in a world where there are no users. But any programmer worth a dollar should have known better than to base his data retention policy on a user entered value. That's just madness.
Admin
It seems intriguing that 'incompetence' is misspelled in this post.
Admin
You know what, if I had been writing up this Daily WTF, I'd have deliberately changed the date in the header to "11-28-2009".