Linux-Based Point-of-Sale Software
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
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
- 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
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!)
||$200 / 3 = $66|
||$1000 / 9 = $111|
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
- 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
- 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.