• mitrebox (unregistered)

    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.

  • Anon E Mouse (unregistered) in reply to Larry

    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.

  • Patrick (unregistered)

    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.

     

  • Kronian (unregistered) in reply to Larry

    I died laughing. xD

  • (cs) in reply to Chris

    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.

  • jim (unregistered) in reply to Zygo
    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.

    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.

  • jim (unregistered) in reply to Monday
    Anonymous:

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

    You can deny a return without a receipt. It's not like returns didn't exist before POS systems.

  • Why? (unregistered) in reply to Satanicpuppy
    Satanicpuppy:
    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."

     

    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.

     

  • meme (unregistered) in reply to Monday

    "(you can't deny a return)"

     
    Ability to deny returns varies by locale. You can't make that blanket statement.

  • (cs) in reply to shaeffer
    Anonymous:

    Well, that should be an easy fix, yeah.

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

    Why oh why can I not mod this +1 Funny? :(

    Damn you forum software! 

  • Mr Black (unregistered)

    For some reason the end of this post made me involuntarily reach down to shield my testicles.

     

  • tsrblke (unregistered) in reply to Mr Black

    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.

  • (cs) in reply to Anonymous P.M.Doubleday
    Anonymous:

    BTW, I just deal with large-scale systems and stuff.  What's a "tech"? Is it like a Klingon, only with bad breath? 

    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.

     

    Anonymous:

    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? 

    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.

  • (cs)

    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.

     

  • BWilde (unregistered) in reply to boflexson

    Incompetance?

    Hmmm... look who's talking.

    It's spelled "incompetence".

  • Zetetic (unregistered) in reply to Chris

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

  • DAT (unregistered) in reply to Zygo
    Anonymous:

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

    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.

  • GORT (unregistered)

    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.

  • PLasmab (unregistered)

    Priceless!

     

    To quote Strongbad.... Ah-DELETED! 

     

    undeleted!

    undeleted! 

  • (cs) in reply to JD

    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.

  • (cs) in reply to A Businessman
    Anonymous:
    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

    ..using nothing but JavaScript! 

  • (cs) in reply to mitrebox

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

    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!

  • (cs)

    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.

     

  • Anon (unregistered) in reply to Why?
    Anonymous:
    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.
    Great.  So when the user opened the day with the wrong date, your externally synchronised time source decides that today's sales happened three years ago and wipes them out.  Congratulations: You just moved the bug from the close date to the open date.  You have only lost one days' transactions instead of three years' worth.  (Of course today's transactions haven't been backed up yet.  Damn!)
  • joe (unregistered)

    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 

  • joe (unregistered) in reply to Anon
    Anonymous:
    Anonymous:
    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.
    Great.  So when the user opened the day with the wrong date, your externally synchronised time source decides that today's sales happened three years ago and wipes them out.  Congratulations: You just moved the bug from the close date to the open date.  You have only lost one days' transactions instead of three years' worth.  (Of course today's transactions haven't been backed up yet.  Damn!)

    Solution: Timestamp what time/date you THINK it is and also what the user entered, and work it out later. Just NTP the register and server time and make sure everyone is in sync. Don't credit card transactions check to make sure times are correct anyway?

    captcha: clueless
  • (cs) in reply to TomWoolf

    As programmers, it is our job to goof-proof (I prefer "idiot-proof") the software as well as possible.

     

    Whenever you create something that is idiot-proof, nature will build a better idiot

  • lmodllmodl (unregistered)

    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.

  • Eric Bostrom (unregistered)

    Fortunately they restored everything from their offsite nightly backup and all was well.

  • PLEASE HELP!!! (unregistered) in reply to Eric Bostrom

    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.

  • Solo (unregistered)

    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! 

  • name (unregistered) in reply to TomWoolf

    The surprising thing?  The software had been used in its various releases for over 20 years before this happened.




    That you know of...

  • Loren Pechtel (unregistered)

    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.
     

  • Stroller (unregistered) in reply to Mike
    Anonymous:
    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!
    Hahahhahahahaqhhahah!
    You've clearly never worked in either retail or POS support.

    Honestly, this episode is the merest soucon of a WTF, a gentle introduction to industry norms. I really wish I'd known about this site during my last job (I became self-employed shortly after arguing with my boss one time) - I would have been able daily to supply anecdotes to the highest standards of WTFery.  As it was Dilbert gave us regular & deep belly laughs - reading that cartoon was a real case of life imitating art, and we frequently felt we were living inside the frames of Adam's comic.

    Stroller
  • John Doe (unregistered) in reply to boflexson
    boflexson:

    incompetance knows no bounds.

    This comment is the funniest thing I have read all day. (Hint: Go check a dictionary!)

     

  • ha (unregistered) in reply to PackRat

    ha

  • Dwayne (unregistered) in reply to doc0tis

    Unless the tech experienced it before.  Then it is a whole new can of worms why it wasn't fixed if the first place.

  • Gershon (unregistered) in reply to Satanicpuppy

      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.

  • Leon Brooks (unregistered) in reply to sir_flexalot

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

  • (cs) in reply to Leon Brooks

    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.
     

  • Safe Way to break grocery store registers (unregistered)

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

  • Anonymous coward (unregistered) in reply to Nate

    *Clicks Yes*

    *Clicks Yes* 

  • Earlz (unregistered)

    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.

Leave a comment on “Don't Worry, We'll Fix It!”

Log In or post as a guest

Replying to comment #:

« Return to Article