Note: since this was written, we've decided not to go this route, and to just buy cheap-o non-networked cash registers. They work fine. Perhaps someday in the future, when we have nothing else to worry about and money to burn (ha!) we will upgrade to a point-of-sale system. Maybe that future system will be based on this code, but most likely not.

Apparently a lot of people are interested in this topic, because I regularly get mail asking me ``have you gotten any farther with this?'' Rest assured, if I had, it would be here. There's nothing to see here. Move along, move along...

-- jwz, May 2002

---

February 2001

Do you have any idea how expensive cash registers are? Oh, wow! I'd seen them in office supply stores for like $200, so that set my expectations. But apparently those kinds of registers are really slow and generally crappy. Registers that you'd actually want to use are over a thousand dollars. Oh, but if you want them to network together (so that you can change prices from one register without having to go and touch all of them, and so that only the night manager has access to the end-of-night totals, which I'm told is a good way to circumvent one of the main ways that bartenders steal from their employers) then they're like $2,200 each!

Each. We need nine.

These are the requirements we have:

• Fast order entry for around a dozen products (touchscreen or application-specific keypad);
• Not more than a dozen registers total;
• One cash drawer per register;
• Log all sales and voids to a central location, inaccessible to cashiers during the night;
• Ability to get that data as a tab-delimited file of some kind;
• Unique user ID/password for each cashier;
• Ability to reprogram each register from a central location (change prices depending on the night's event, e.g., drink specials);
• Ability to mark a product as complimentary (bartenders need to be able to give away drinks every now and then);
• Ability to print a receipt, when requested (not common: one receipt printer per bar, rather than per register, would be fine);
• Reasonably durable and waterproof;
• It must not require use of any Microsoft products.

• We don't need it to do credit card or ATM transactions.
• We don't need it to do ``merchant processing'' stuff: in a bar, ``merchant processing'' is ``carrying a bag of one dollar bills to the bank.''
• We don't need fancy tax table handling: we only have one type of product.

So I started looking around for Linux-based point-of-sale systems. There are quite a few out there, but most of them seem incredibly flaky, or like they're just nowhere near being completed. The most promising one was LinuxPOS, whose main feature is that it's the only one I got to actually open a window. But, its interface seems to be geared toward stores with huge inventories, where you'd either be typing in a product number, or scanning it off a barcode. In particular, it doesn't seem to have a way to put up a grid of products, like you'd want in a bar or fast-food restaurant, where there are less than a dozen products total and you want to just be able to smack the button labelled ``hamburger'' or ``beer, imported.''

So now I'm playing around with writing my own from scratch. The software side of it seems pretty simple, since it doesn't really have to do very much (e.g., we don't need it to scale to hundreds of tellers.) I think that if I do it this way, I can keep the hardware unit cost per register down around $800, maybe more if I can find better prices for serial-port-controllable cash drawers, and so on. (If you have experience with using this hardware, advice on which are known to work well with Linux would be greatly appreciated!)

Diskless PC: $200 14" monitor: $90 Touchscreen: $180 Cash drawer: $160 Receipt printer: $200 / 3 = $66 Server: $1000 / 9 = $111 $807

My thought is that it would work basically the same way as my kiosk network: there would be a server machine locked in the back office, providing DHCP and NFS service to a bunch of diskless workstations (the cash registers.) The point-of-sale application would be loaded from the server, and run on the cash registers, writing its log files to the server's disks. There would be an ethernet between the server and the registers, but they would be otherwise completely isolated from other networks: data would get out of the server and into our accounting software via floppy disk.

Reasons why this is a good idea: It will do exactly what we need, and not be a product that doesn't quite fit, because it's slightly too large or too small; It will be easy to customize. E.g., we can do things like have the register warn when it's time for last call, and then have it refuse to ring up alcohol products after 2:00AM. It will be much less expensive than a commercial product. Did I mention that it will be cheap? Also it will be cheap.

Reasons why this is a bad idea: I have a lot of other things to do, and this is one more project I'm taking on: I'll be plenty busy figuring out how to run the business, without also having to develop and support the software and hardware for the cash registers; Even if what I come up with is really good, it will still be version 1.0: I'd rather not be beta-testing cash registers, I'd rather have ones that have seen combat, and have had all the bugs shaken out by other people. Specifically, I have no idea how well a cheapo PC is going to hold up in a behind-the-bar environment. If we ever want to add integrated credit card transactions (as opposed to using a separate box), that will be a pain in the butt. (But possible, I'm told, with an $80 card reader and the CCVS software.) If there's a power failure, this thing will take a few minutes to boot: that's money down the drain.

But did I mention that it will probably be pretty cheap?

Anyway, I took a weekend and hacked up a little prototype of the kind of thing I have in mind. You can download it here:

This requires GTK+ 1.2 or newer.

To compile: ./configure ; make

To run: dnapos. But you'll need the file config.txt to be in the current directory when you start up.

For demo purposes, there are two users built in: user 100 (password 100) and user 200 (password 200.) User 100 is a manager. When he logs in, he gets the option to turn on manager access (currently, just the ability to do ``No Sale.'') The manager password is 900.

(User IDs and passwords are numeric because these things won't have keyboards at all. I'm assuming they'll have touchscreens, so you'll use an on-screen keypad to log in.)

Let me know what you think...

What I think is, this project really screams ``endless time-sucking rathole.'' Though I think it would be really cool to have registers that ran software that I wrote, and though it sounds cheap now, when I factor in the time and headaches it may cause, it very easily could end up being an expensive mistake.