Restaurant POS Systems?
glamslam asks: "As the newly appointed technology director at a large restaurant chain, I've been given the task of evaluating and implementing a Point of Sale (POS) system. The main goal is to save costs on deployment across hundreds of restaurants. Another goal is to find a solution that is flexible enough to adapt to our unique operational model. Most of the vendors' products I have seen are based on Windows. I prefer the openness, flexibility, and cost-savings of Linux, yet I do not want to build the system from the ground up. Has anyone been involved in POS projects and managed to put Linux into the mix?" Are there any features that restaurants need that your traditional POS system may not include?
You should google before doing an ask slashdot question. This question is however a good question for us all. I think dennies uses linux based pos units... burlington coat factory switched everything to linux... i think including the pos units... Perhaps a google search, or just calling those companies up and asking who supplied their pos systems would be a good start.
And when you say you want "flexible", what's more flexible than a system that you have complete freedom to tailor, can be deployed on whatever hardware you deem appropriate, and doesn't come with ties to the future whims of a proprietary OS provider.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
Once all the POS systems at Fuddruckers were down because thir windows based network was infected with NIMDA. They couldn't figure out how to sell hamburgers without them. Four people had to suggest using pen, paper and a calculator to record sales before the manager would do it. You are right to want to avoid windows, but you need to be ready to stay open if all the computers crash even on Linux. Keep the old style guest checks on hand, and some pocket calculators.
How ya like dat?
Perhaps you could use this as an opportunity to help drag the USA into the 21st century but using those wireless handheld credit-card swipe devices that are common in Europe, Japan and elsewhere?
There is nothing worse in the US than being ready to leave after a nice meal, the waiter/waitress having dissapeared somewhere with your credit card, and you are waiting impatiently for their return - which often takes an inordinate amount of time for some reason (perhaps they get distracted?).
There are several low-cost PDAs that can run Linux around.
/..sig file not found - permission denied.
(1) Older or revamped OS/2 solutions... highest flexibility, but requiring someone who knows OS/2 and such to allow use of such flexibility.
(2) AIX/*NIX with OS/2, Win__, etc clients
(3) Entirely Win systems
Now my breakdown on the matter...
(1) OS/2 - will be difficult (unless you know people who are on Sears' support team or that of some other company like them) to find someone with the "expertise" to implement or expand or customize an OS/2 solution... even though it is far easier (even 5 years ago) than most every other solution.
- "Unlimited" expandability (add up all the SEARS POS terminals, catalog system and multimedia kiosks and then you see what a true network OS with a high end commercial scale POS system can do on "mere" PC hardware. The Win solutions will never approach that level. - handles POS and related systems for 3,000 departments.
- All in all, unless or until eComStation continues to gain more Win converts that the POS market on OS/2 is revitalized, it is probably not the way to go.
(2) Numerous packages can still be bought with phenomenal support (at a phenomenal cost though).
*IX solutions use some TTY interface (depends on implementation) so most client OS's work. Not very flexible or customizable.
There are GUI (Solaris) apps available, including with perl scripting support, but they are very very expensive, and (thus) usually "customized" for each client. We used one such at UUNet back in the late 90's (and I think still today, but I no longer work there).
(3) Win apps seem mostly to be VB apps, poorly written, (ask CompUSA who dumped a perfectly running RS/6000 POS setup for a "glitzy" Win95/98 in house written, crash a lot system - they never even finished transferring the whole system to it due to the problems, hence the sales and stock system is still separate and on the mainframe, or ask Best Buy and PetCo who are having nothing but crashing issues on package "off the shelf" (well, the "high-end" commercial version).
I've researched a lot of the issues, and have yet to find any people truly happy with the lower end systems, most especially on Win__. (I researched it because we were in teh process of writing our own app, but as the maker of our main development tool fell behind on their final release, we never were able to release ours (required DLLs from their final release).
From our plans based off feedback just like you are requesting, here is what I've gleaned is needed nowadays (as well as 4 years ago when we planned this)...
- integrated fax capabilites (user selectable per customer as method of invoicing and statements)
- integrated email capabilities (same)
- web integration of most or all components
- integrated account and contact database (with all components such as web, fax, email, phone, etc)
- online ordering (web integration, "shopping cart")
- barcoding and barcode reading
- credit card processing (directly or through a third party processor)
- callout feature [larger scale users (collections purposes, cold calling, re-calls, etc) or "glitz" feature for smaller users]
- image and basic catalog support (output to pdf or direct to print for those with their own high end printers)
- Caller ID incoming capabilities (larger firms for increased productivity in auto records retrieval, etc, or smaller firms "glitz" feature).
- Variable print formats (sorry those who sell these retardely overprice POS systems, but STAR and other printers are simple Epson graphics mode with a couple extra codes for cash drawer machines, or HPPL/PCL printers... you dont need to charge a fortune to add 3 extra control sequences and a manual that explains how large a graphic can be).
- Contract, form and misc document feature (to for instance, print a web contract with the related invoice with all the appropriate info - I mean, c'mon gang (who writes this expensive crap), it can even be done with a simple "mail merge" into a pre-typeset document).
- flexibility for various network schemes (really simply use of __SQL back end and appropriate net protocol to talk to the ___SQL server.
- Of course, all the standard accounting features
- Job and item numbering, serialization (serial number tracking and recording), etc.
- Item lookup by serial number or product number (makes selling and invoicing a breeze with most computer and electronic devices... the beginning of the serial number on most identifies the product, meaning, you can inventory by serial number scanning once the identifier is in the database and let the system handle all the rest. Sell a product, scan only the serial number and let the system cross reference all the rest also allowing for fully accurate SN tracking).
- Contact manager (I dont mean an address book - I mean "12/10/2001 13:45 Called Joe and advised payment late. He said check in mail." etc... with related options always available that generate Contact entries such as click "Re-Invoice" and the next entry is "12/10/2001 13:47 Generated new invoice to be sent via regular mail" (or preferred method per customer).
- EASY options to change on the fly methods of sending invoices and documents
Those are just a few off the top of my head...Rob
WebMaster:
BinFeeds
XXX Thumbnailed Image Newsgroups but