This thread inspired by this post in a nearby thread:
This question is for people with experience as cashiers or retail store managers:
Do your modern computerized cash register hang, crash, or otherwise fail often? Particularly in mid-sale, requiring you to ring up an entire sale again from the beginning?
I worked for a small company for several years, that was in the business of making computer cash register software. It seemed to me that our product was full of bugs and strange idiosyncrasies, and it did crash a lot. But I spent a lot of time working the telephones, so I was on the front lines and saw all that. It was a small company, with a product that wasn’t one of the major players.
OTOH, speaking as a run-of-the-mill consumer, buying stuff at markets and other stores, I’ve never seen a cash register crash. I wonder: Cashiers and store managers out there, do you see this happen often? Is your cash register system a commercial product from a major vendor, or a commercial product from a small second-rate vendor? Or a completely in-house system?
It’s maddening when it happens. It’s never on a one or two item transaction, but only when you’ve already rung through $300-$400 worth of merchandise.
The registers at KMart were really old, so I thought that was the problem. I’ve been in the store recently, and they still haven’t upgraded. Of course, I don’t even expect the store to be there next year, so I’m sure it’s not a priority for them.
It’s probably only going to be on big orders that it’s going to crash. The memory allocated for some specific function gets filled when the order gets too big, and once it overflows it will become highly unstable.
The POS at my husband’s store runs on Windows, probably XP, or maybe CE. AFAIK, it’s never really crashed or frozen in a transaction, but once in a while, I have seen Windows errors break through the fourth wall, so to speak, and appear over the otherwise full-screen terminal software.
There are some vendors who are moving to a Unix server / iPad client solution (OpenTable is one of them), but largely it’s shitty code scrabbled together in Access or dBase (bet you didn’t even remember that one) and slapped on top of a badly secured and not-at-all backed up Windows installation.
The largest “integrated” system is pcAmerica’s “Restaurant Pro Express” which runs on Windows and is to modern technology what Lindsay Lohan is to the Blessed Sisters of Perpetual Chastity.*
We recently got new registers and printers. Three weeks later, my printer died.
The only time the whole system failed was when a car hit an electric pole that was on our system. Two hours of making returns and then standing there looking at each other.
I used to run a sunglass store that had two cash registers that were essentially Windows machines with cash drawers. As far as I can recall, they never failed. We had issues once when the credit card readers were replaced and the new readers required separate software, but we were still able to run cash/check transactions. This was from 2003-2005.
Not really. The biggest problem we have is power outages and my town seems to have a lot of them. Probably due to the antiquated electrical system. They recently got a grant to upgrade the system and it will triple the capacity (and hopefully solve the seemingly constant outages). The last outage blew away our credit card machines and the one before that blew away one of the cash registers.
I can say as a customer, a POS or cash register has only failed, when I was at it, one time in my life. And it was a POS at a Safeway. I swiped my card and the transaction was stuck but the terminal registered zero and told me to take my groceries.
There are any number of ways any software system could fail, and the above is just one of them.
After I left my POS (in all senses of that acronym) company, I continued doing free-lance consulting work with those systems. The company didn’t sell much to end-users (that is, the retail stores); it sold the software to independent dealers who then sold integrated systems to stores. I did work for some of those dealers. I saw, diagnosed, and found work-arounds for problems for years. I also wrote add-on modules for dealers to implement custom needs for their stores.
One such custom module crashed their back-office server, which brought the whole store down. The failure was an index error in one of the data tables. I’m pretty sure there’s nothing I could have possibly written into an add-on script that could cause that. And I’m pretty sure that the same is true of base product (which was otherwise known to be buggy). I can only imagine that the underlying database libraries, where all the code for handling indexes resides, must have a bug and my code somehow ran into it.
Perusing an on-line forum for programmers who write applications in that particular programming language, I did find mentions of bugs in the underlying libraries that might have been the cause.
Anyway, they rebooted their server and all their registers. A day or so later, it happened again.
They had to shut their entire store down for a couple of hours each time. The dealer told me that this must have cost them tens of thousands of dollars. They de-installed the module. I spent a week of 20-hour days, largely re-writing the whole thing to work differently, in the hope that the same bug would simply not show up again. They’ve been using the module for about ten years now in several different stores with no further crashes like that.
There was another bug that clearly came from their credit card processor.
It seemed that sometimes a credit card would be tendered, and the register would accept the tender for a different amount than the amount the cashier (or customer) had entered! :eek:
The dealer worked with me, and with the store, and with the credit card processor company. We got hexadecimal dumps of the packets transmitted back and forth. Who do you suppose, poring over a stack of hex dumps, figured out what was going on? I did, that’s who.
It seems that when two registers rang up credit card tenders at almost exactly the same time, and the registers sent these to the credit card processor at just about the same time, the credit card processor would sometimes send the “card accepted” response to the wrong register. Thus, if one of the registers just rang up a $25.35 credit card tender, it showed up at the other register :eek: – I was able to see this clearly happening in those dumps.
The credit card processor didn’t believe it, even through I wrote it up in exquisite detail for them. The dealer figured he was just to small a small-time dealer for them to give a shit about.
Fast forward about three months. Suddenly, the dealer tells me that it’s all been fixed. It seems that a MAJOR restaurant chain was reporting the same problem. (No, they don’t use the same POS system. Just the same credit card processor.) Suddenly it matters, and it got fixed.
We would routinely have one or two registers that would be out of commission. Fortunately it was usually apparent from the beginning of the day, so they wouldn’t fail in the middle of a transaction; we just wouldn’t use those registers. I don’t know whether those were hardware or software issues.
But maybe one out of every ten register shifts I would have a register fail in the middle of a transaction. Generally customers were understanding; I’d just shift all their stuff over to a new register and start over.
There were maybe four or five occasions when the entire store system went out nationwide, which was always exciting. Not just the registers, but all the systems including those that were used for tracking and pulling pre-paid orders. Those were the really fun times.
I left that job two months ago, so these were all pretty modern systems.
On the other end, we found out the hard way a flaw of the POS system at our local international market: If you swipe the credit card at the same time an item is scanned: reboot time. Mrs. FtG wants to swipe early and she’s learned to wait until the clerk’s hand has moved away from the scanner to swipe.
At Blockbuster, the satellite used to go down all the time when it rained. A lot of the time it would only affect card transactions, but every now and then the entire POS system would crash too.
That’s kinda-sorta plausible. Scanners, scales, and pin-pads are connected to the computer in various ways. One popular way has each one connected to a COM port. Well, fifteen years ago, before USB devices were so common. There were plug-in cards you could get for your PC that had 8 or 12 extra COM ports on them. Today, they might all be USB devices.
But another scheme, especially common older systems, was the keyboard wedge. This set-up causes all input from any device to appear, to the computer, that it’s just coming from the keyboard. It might be implemented in some hard-wired way (you could get special POS keyboards with all those wedge ports right on the keyboard), or in special-purpose drivers that merged all the data from all these sources into one keyboard input stream.
If you scanned and swiped at the same time, at just about the same moment, a sufficiently badly programmed system could produce one stream of data from both sources interleaved together in some more-or-less unpredictable way. A sufficiently smart POS system might detect the erroneous and unparsable input. Or it might just screw up and crash or do who knows what.
Another problem with POS systems, especially the modern database-driven ones that manage lots of data: There has been no known method yet devised to assure that back-ups are reliably done, if at all. You just cannot get store managers to do it, or hire someone else to do it. They just won’t.
We were called upon from time-to-time to try to recover a crashed system’s data. I’ve fixed data files with text editors, with hexadecimal dumps and hexadecimal file editors, and with special utility programs we had that would try their best to recover scraps of usable data from scrambled files.
But the most common resolution was simply: Tough shit. Your file is trashed and it ain’t coming back.
Secondhand experience of a drivethrough KFC - the POS didn’t exactly fail all on its own; the cashier accidentally entered 22 of the meal I ordered instead of 2. The meal came with a choice of dip, drink and side - which were presented as questions - so the thing stacked up a list of 66 questions for the cashier - all of which were required to be painstakingly answered and confirmed before anything on the order could be cancelled or amended.
It froze up completely about a quarter of the way through.
In the first couple of years that I worked at my recent retail job, the POS would occasionally spontaneously flip between input fields in the middle of the scan; specifically between the SKU field and the quantity field. Which means sometimes the SKU would end up in the quantity field, and then the cursor would quickly switch back to SKU. Which means that the next thing scanned would come up with a quantity of whatever the last SKU was. The quantity field actually maxed out at 400, so the system would try to sell the customer 400 of whatever was scanned next. Fortunately, it was extremely obvious when this happened, as the subtotal would be totally out of whack relative to what the customer was buying.
I was once checking out one of my coworkers when this happened. The thing she was buying cost $119. She glanced down at the screen and saw that her total was $47,600 and had a mild panic attack. (Hey, with her employee discount it was only $28, 560.)
Our POS system had a bazillion configuration options (most of them horribly poorly documented), one of which was a maximum allowable quantity. A store could set that to, say, 15 and any larger quantity would be disallowed. Mangetout’s errant quantity story is a good example of a massive user interface fail. A non-negligible part of my private consulting work consisted of writing custom user-interface details to replace the stock interface details for things like that.
Here was a biggie: If any input error happens, an error message window pops up. You have to press the Enter key to clear it. But it doesn’t turn the scanner off. When you scan an item, the scanner sends the bar code digits followed by a carriage return byte. And keyboard wedge interfaces just funnel that into the keyboard input stream.
See where this is going? The cashier is just shoveling items past the scanner as fast as possible, hardly ever glancing at the screen. (Yeah, they do that.) Some item has an error, like it’s mis-scanned or requires some special confirmation or something. Message window pops up. Cashier doesn’t even notice it, and just keeps shoveling items across the scanner.
So the next scanned item sends a bunch of digits, which the register ignores, followed by a carriage return byte which closes the message box. So the item with the error doesn’t get rung up, but the cashier has already shoved it onto the bagger’s conveyor belt by now. And the next item doesn’t get rung up, but the cashier just shoves that onto the bagger’s area too. Then with the next item, the register begins ringing up items again. So the customer gets two items for free, and the cashier probably never even notices it.
All the custom add-on modules I wrote, I wrote my own custom message windows (which was a lot more trouble than using the standard message functions that come with the system) just to make that not happen.
:eek: