- 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
there are many valid reasons for running transactions that are billed on less than the current date. There are very few (and inmost business models, NO) valid reasons for billing a transaction for a future date. Even without knowing a thing about processing POS transactions into a datamart I can say that they need to error all transaction records with a future date.
Admin
Years ago I wrote a macro for an accounting department. I put in lots of error handling. You know, just in case someone put in 2009 instead of 2006. My boss, not a tech person, yet part of the IT Department, told me to remove the code because she was giving very explicit instructions and no one would enter wrong data.
Yeah. That'll work.
Admin
We ran into this problem all the time. I worked for a major amusement park in the Cash Services Department and our responsibility was to start and close the business date. There was a huge sign next to the computer that said "Make sure it says todays date!" Talk about a mess if things got off kilter.
The other related problem would be with the database that reported the money we would audit from all the stands for that day. Auditors would key the wrong date in and when we went to import the money to the business reports from the registers, it wouldn't match up at all!
The solution? We'd have to rekey in every money deposit bag audited into the correct date. Usually at about 4am since we counted the money after the park was closed. Usually about 300-400 transactions. Not Fun!!
I can't stand people who goof up the dates on systems like this! I just want to smack them.
Admin
I died laughing. xD
Admin
Oh wow, the punchline really carried some punch today! I really hope they did have backups (in which case it's just an amusing story and some embarrassment). If they didn't then that far outstrips the WTF we have here.
Admin
Heheheh. Very true. Even better might be to not expire old delete by simply deleting it. Move it to a archive and have the IT department delete old data.
True, a single mom & pop operation wouldn't have an IT department to handle it, but they also probably wouldn't have a POS system either.
Admin
You can deny a return without a receipt. It's not like returns didn't exist before POS systems.
Admin
Exactly - the purge process should never have been linked to the date entered by the POS operator! I should have been triggered independantly and use an externally synchronised time source.
Admin
"(you can't deny a return)"
Ability to deny returns varies by locale. You can't make that blanket statement.
Admin
Why oh why can I not mod this +1 Funny? :(
Damn you forum software!
Admin
For some reason the end of this post made me involuntarily reach down to shield my testicles.
Admin
Having worked at fast food chain Y during a time when our server died, I can tell you that even tap back up are sometimes not enough. Our server downloaded to the main servers overnight and we printed out paper records of everything. When the store server died, the backups were a week behind (backing up that much dae takes time, and so they were usually behind since Fast food chain was open 24 hours a day.) We had to manually enter about a weeks worth of paper backups into the system. That takes a shit load of time, and it's a pain. Is it a horrible horrible ending, no but it's certainly the makings of a VERY bad day. We all took shifts punching data into the computer. 5 hours later we were done. I was stunned by how much data there was that corparate cared about, hell we had to enter hourly sales figures for insert fast food item here.
Admin
The common name for folks on the other end of the pay scale in your career. Like code monkey, but for administration and repair tasks.
This be one really nasty lawsuit comin'. I assume since it wasn't mentioned, everything got fixed a few hours later. I wonder if the manager made any big hot-backup rollouts after that.
Admin
And there were no backups? Or streamers are so expensive these days? No wonder that they did not worried about this after declining full support.
And yes, there are reasons not to trust system clocks and there are ways to get right time from centralized servers.
PS: This is not a WTF really. Its a bug that I wish no one of you will ever create.
Admin
Incompetance?
Hmmm... look who's talking.
It's spelled "incompetence".
Admin
if I had been writing up this Daily WTF, I'd have deliberately changed the date in the header to "11-28-2009".
Good god man! And wipe out three years worth of stories!?
Admin
Note to self: expire old data as part of the backup procedures (i.e. after the tapes are in the vault), never assuming that a record can be erased only because it's old.
Admin
Even though i know that POS stands for "Point Of Sale", while reading this thread my brain kept interpreting it as "Piece of Sh**".
Amusingly, the thread still made perfect sense.
Admin
Priceless!
To quote Strongbad.... Ah-DELETED!
undeleted!
undeleted!
Admin
you then need to have a box for the user to type "Y" "E" "S" as a failsafe
No, we tried this one. In a system where the Computer Operators (remember them?) had to be ultra-sure they had entered exactly the right paramers for a job, we used to put up a random 8-byte string for them to copy, to ultra-confirm they were ultra-right. Unfortunately, they just concentrated on copying the string ultra-correctly, rather than reading the prompt that they were supposed to be confirming. Jobs still got run for the wrong country and last Sunday's date...sigh.
Maybe we should just have put a prompt saying "Entering incorrect parameter data will ensure your P45* is issued to you tomorrow morning."
*For non-UK bods, P45 is basically a termination notice.
Admin
..using nothing but JavaScript!
Admin
The system I work on is not POS but it still involves transaction dates. We reject transactions more than a day in the future but allow that one day. Why? - International Date Line. If only we didn't have to worry about time zones!
Admin
Years ago our company stored periods in YYYYPP format. Periods could be input online in either PPYY or PPYYYY format. That was fine, except we did not limit the range of years. Usually, the users would discover that someone input "103102" for the last day of Oct 2002, rather than "102002" (although the field was labeled "date", it was actually a period field). Unfortunately, one client didn't - until they had rolled forward to "123102". Since we also had a purge process (items could be saved for many years), when you push the system forward 1,100 years and 1 month, all old stuff was gone. Kerblooie. Gone.
Fortunately, daily/weekly/monthly backups were taken, and we did have a convenient way for the user to process the incremental updates, so their year-end was not a disaster. We did learn our lesson and added minimum and maximum date ranges both in the background and a user-defined range.
As one comment had implied, not checking for valid (or at least reasonable) periods is its own WTF. As programmers, it is our job to goof-proof (I prefer "idiot-proof") the software as well as possible. The surprising thing? The software had been used in its various releases for over 20 years before this happened.
Admin
Admin
This sounds like a certain world's largest retailer, they purge records 3 years old, but they have their own programmers and run daily backups (hourly actually as its uploaded to the HQ) so maybe this is their next closest competitor..$500,000 a day per store is ALOT. Most of the world's largest retailer's stores don't make that
Admin
Admin
Whenever you create something that is idiot-proof, nature will build a better idiot
Admin
option 1 : restore the backup option 2 : hope that 1) the data is stored on a database that only flags records as deleted until a compact is issued and 2) the programmers didn't automate that task as well.
Admin
Fortunately they restored everything from their offsite nightly backup and all was well.
Admin
I downloaded this Tweak XP software and when i tried to "Tweak to the max" it froze my computer so bad that I had to delete the Tweak file altogether. Now I can't connect to the internet, have no IP address (only shows 0.0.0.0), cant do a sys restore bc I didnt have it turned on, have tried the reset and renew Ip from cmd, flush dns - you name it, i have probably tried it.. Can anyone help me go back to where I was before I tried this stupid software? I haverun out of ideas other than reinstalling XP and Im not sure that would work either, but it doesnt matter bc I dont have a copy of XP anyway.
Admin
1) don't delete anything out of anywhere. Disk space is cheap, and unless you are processing GB of data per day, you have no reason to delete things. At best, you are allowed to 'archive' data to lighten the load on a the server.
2) backup?
3) the law of unintended consequences always strikes unexpectedly (by definition)
There are good legitimate reasons why you would want to 'open' a different date, but 3 years ahead? I'd build the system so you can't open that far in advance without a phone call from the vice president and the key from at least 3 generals.
captcha: whiskey, yeah, lots of it!
Admin
The surprising thing? The software had been used in its various releases for over 20 years before this happened.
Admin
I've had an incident sort of like this. Historical production data was aged into lower and lower resolution as time went on. I didn't rely on anything like a user to get the date, though, I used the time from the server--the server that synched to a time server every 10 minutes. A reliable source of time??
Something went boom on the server during a mirroring operation, the whole thing had to be reinstalled and restored from tape. Unknown to anybody at the time the CMOS battery had also died at some point previously but since it was up 24/7 it didn't cause any trouble.
The system is brought back up and quickly put back into operation (it was essential for operation of the factory. No computers = no production.)
For some strange reason the dead CMOS battery caused the clock to be set to 2046. The program was brought back up before the server had managed to fix it's clock. A bunch of historical data got aged out of existence. This didn't show up until the next morning when people got an e-mail showing insanely low rolling averages for production.
Fortunately it was simply a matter of writing something to read the missing data in from a backup and store it into the file if there was no data there. Not a perfect answer but good enough for any use that's currently being made of the data.
Admin
Admin
This comment is the funniest thing I have read all day. (Hint: Go check a dictionary!)
Admin
ha
Admin
Unless the tech experienced it before. Then it is a whole new can of worms why it wasn't fixed if the first place.
Admin
Well, if it weren't for users all computer systems would be very easy to develop. If there's a GPF in a program but no-one is there to see it, is it really a bug?
I don't think there's any real WTF in this article. Not using the current date is very common in systems where a 'business day' has any meaning. Purging old data also makes sense (although I would probably copy it to an historic database instead of just purging it).
Restoring the old transactions should be very easy if they have access to yesterday's database backups.
They should probably have better date checks (if the logical date differs too much from the actual date - warn the user), but that's hardly a WTF.
Admin
> If you reach for the backup tapes and somehow the AC has
> dumped water on them, THEN it's a real WTF!
I had a customer do this with a database server I don't manage. Customer was very pleased to discover that the backups were packed into a tape archive, then the archive was copied out to tape. The archive still sat on the hard disk as well as in the wet tape, and I managed to copy it away about 10 minutes before the automated backup utility started re-creating it from (knackered) scratch.
I set the database up to backup three days' worth over the network, as well.
Admin
There is one fairly good way to prevent an accidental wrong year being input. Require the input of the day of the week as well as the date, and throw an error if they mismatch. Will not prevent all such errors, but most of them.
On a related note: I've lost count of the number of times I've recieved such non-existent dates in emails. This at a university where I'd expect people to know better. It's usually student societies but I've had it from the administration as well.
Admin
Hey, I discovered that at a certain large grocery chain here in the states (won't say the store name to protect them, but alert readers might find out anyway...) you can crash the register without really trying, and it is STILL a problem! I shut down two of them in a row -- the first was accidental, the next was me thinking about what I had done and duplicating it when they moved me (and the rest of the people in line behind me) to another register. Needless to say, after moving to yet another register I was a nice boy and never let on what was happening...I think I blamed my visa debit card since it was so old and I carry it in my wallet so that magnetism stuff gets rubbed off...
Anyway, when you buy something and use your debit card to pay, they have those stupid touch screen terminals that are made so you cannot use your fat finger to make selections, you have to use their silly little black pen pointer things. Well, I had gone through there so many times I knew exactly where I wanted to "touch" on the screen, so after I slid my card thru and did my PIN I =immediately= started rapidly tapping with the pointer on the screen where I knew the "no money back" area was.
This, due to VERY bad programming, loaded up a dozen or so "click" events in the queue and when the screen came back and actually displayed the selection for how much money I wanted back, it simply beeped one long beep before going silent and LOCKING UP HARD!! No one noticed the length of the beep because there were so many beeps going on at all the registers around us, and because it beeps at that point anyway.
So, the poor clerk tries to back out the card info (no good) and then tries to cancel the entire transaction (no good) and then calls over the manager who inserts their key and tries the same thing (no good) -- all with me standing there trying my best to look innocent. Shutting down that register, they move me and the whole line over to another register.
Wash. Rinse. Repeat.
I haven't done this in quite a while so I'm not sure if it is still a problem, but it worked at two different store locations I tried in different towns, so I'm thinking it is simply cr@ppy coding by the register/terminal POS company.
LOL...
Admin
*Clicks Yes*
*Clicks Yes*
Admin
Ok, confess up. This is for McDonald's POS right? The POS "server" runs Windows 98 and the registers run DOS(I got one to crash once and saw a 16 bit register dump as well). So I have to at least be close.