Comment On Don't Worry, We'll Fix It!

incompetance knows no bounds.

-Adam

Wine Making Journal

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.

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.
 

Well, that should be an easy fix, yeah.

Just get every customer to bring in their receipts from the last three years.

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.

There is a reason why so many POS's are a P.O.S.

 

Enough said. 

 

CAPTCHA:  craptastic 

Alex Papadimoulis:

And how does one find three-year old data when the system clock is not a reliable indicator?

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.

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...
 

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?

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.

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.
 

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?

...backups?  If you reach for the backup tapes and somehow the AC has dumped water on them, THEN it's a real WTF!

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)

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.

Apparently people have never heard of NTP.

Anonymous:

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).

[snip]

(and if you couldn't tell - I have worked in the retail POS business in a past life)

True and true.  Thing is, yes, they probably have a backup from the previous night.  Problem is the solution just went from "Lemme run this script real quick, you don't even have to close the registers" to "You have to close your store for an hour or so while I pull the backups over the wire from Accounting then rebuild your DB."  Technically, this isn't much harder.  Business-wise, the manager's day just went to hell.

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.

accident:

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?

Oh, they had backups, printed out, and photographed on a wooden table, then digitized, and stored in the same database as xml

Anonymous:

Alex Papadimoulis:

And how does one find three-year old data when the system clock is not a reliable indicator?

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.

 
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.

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. 

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.


 

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.

Anonymous:

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. 

 

Word! I doubt that many tech's would have caught that.

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. : /

 

I bet the words "History Table" where creeping into their heads right then.

Anonymous:

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.

 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

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.

I physically winced.

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.

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.

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

IF RECEIPT.AGE = "OLD"

THEN RETURN "I LOST MY RECEIPT."

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? 

Oh, my God, my blood actually ran cold when I read that...

Anonymous:

And...note to self:  expire old data by counting distinct days in the transaction database.

Note to self: Archive expired data instead of deleting it.

Further note to self: Make sure all data has backups.

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.

Sure it helps.

"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?"

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. 

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. 

 

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? 

Spelling has well-defined bounds and you are outside of them.

Anonymous:

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? 

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.

Anonymous:

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.

Sure it helps.

"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?"

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 ;)

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.

 

If you aren't going to do the necessary backups, then at least you should ARCHIVE records to another file instead of PURGING them.

Alex Papadimoulis:

...

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.

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? 

Anonymous:

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.

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.
 

It seems intriguing that 'incompetence' is misspelled in this post.

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".