Slashdot Mirror
Linux At the Point of Sale
NegativeK writes "I work at a local comic and games shop, and I've been kicking around what it would take to implement a barcode scanner and more detailed inventory control. Currently, the setup is a low-tech register that tracks general areas of sales: new comics, ccgs, Games Workshop, rpgs, etc. Requirements include FOSS on Linux, the ability to use a cheap scanner, datamining, and output in a useful format (perhaps OpenOffice spreadsheet). The idea hasn't been pitched to the shop owner yet, so ease of use is probably more important than anything — but breaking out the programming books to work on parts isn't out of the question for me. Assuming the actual register stays, what resources are out there for a barcode/inventory implementation?"
This one comes to mind: Openbravo Again, try sourceforge.
I think Lemon POS fits the bill quite nicely:
http://lemonpos.sourceforge.net/
It runs on KDE 4 though, so it might not be completely production ready yet.
Don't forget that PCI requirements will force any credit card support get certified. If you want to "home brew" you will have to forgo the credit card support and still use the cc machine next to the register. (unless you have $25k laying around to get certified)
You don't need to be certified to process credit card charges. It really depends on the quantity of processing and how the data is handled. You can be investigated to see if all transactions and data are encrypted to standard. An easy way to get around this is to go with a company that allows access via HTTPS where you submit the holders info and they do all the processing. As long as you keep all data pertaining to credit card numbers and other special account numbers owned by banks encrypted and central to your own physical computer then there is a lot you don't have to do.
As well unless you are processing millions of charges a year it will not take you 25k to have some one certify you. That is if you are big enough to deal directly with lets say visa or a bank directly is when you need that type of audit. Many companies exist (Eigen is one of them) that will take care of the communication to the bank its self while provided they only allow communications via a certified secure protocol (HTTPS/SSH/SFTP) you are good to go. You are required to sanitize the card numbers by removing the middle digits preserving just the first and last number of the card.
A loop, by its nature, continues. If that didn't make sense, start reading this sentence again.
I had a similar idea as the poster a year ago with my father's retail shop. Previously they printed prices on products and typed these prices into the register (an old, gloried calculator mind you). Needless to say, with rising prices and 3000+ products, the menu costs were very high!
Having grown up on FOSS and thinking this would be a "fun" project, at first I seriously considered writing everything from scratch. I then realized how many moving pieces I had to deal with just from the register side: sales, discounts, sales tax, receipts, barcodes, prices, inventorying updating, holding receipts, canceling receipts, etc. Then consider all of the non-register functions: inventory management, ordering, vendor tracking, pricing, customer tracking, labeling, etc. Then consider all of the reports you want! If you're not careful, you'll end up writing your own SQL-like language to allow your boss a user-friendly way to figure out sales over given time periods or whatnot. Oh, don't forget financial integration: you'll want to have your costs and revenues automatically tracked, rolled into income taxes, and then nicely reported each fiscal year. I really could go on.
Sure, each piece is "simple." It's just the complexity associated with so many moving pieces that have to support transactions, security, and some easy way to backup. When your software makes a mistake, real money is on the line. Oh yeah, you'll have to do this on your free time by yourself.
It's not something you can do, I hate to say.
If you're like me, your next step is FOSS. I recall looking at SF last year and was very disappointed by what I saw. No system (not sure which ones) felt stable enough to bet my father's business on. It's ok when firefox crashes (and it does), but it's not ok when my dad can't take credit cards (did you plan that integration?) for even 15 minutes. Maybe things have changed in a year or I overlooked some amazing project. That's one of the great benefits of this community -- it will come out in the comments.
So, after all was said and done, I decided to just buy QuickBooks POS for dad. We bought Small Business Server for the server machine and run XP Pro on the register computer. The system came pre-configured with the hardware we needed -- the barcode scanner, label printer, receipt printer, and a nifty pole for customers. You can see the features on their website and decide if they fit for you. Dad uses their financial and tax software as well, and he seems to like how things "just work." Did it "cost" more than FOSS? Sure, we outlayed more cash up front. But I saved myself a bunch of time and headache, not to mention dad has an 800 number to call first (there is value to this!).
My advice, having implemented a POS system for a single-site small business: buy a pre-packaged solution. FOSS is great in some situations, but not yet for mine. It's cheaper than you think if you really need POS.
I don't work for Intuit, and I'm posting as AC for fear of blaspheming the TCO of FOSS on slashdot.
My company develops and supports retail point of sale software for a large number of retail chains. In the interest of ensuring my job security I will not identify my employer, but I can offer some insight.
The first thing to do is check out JPOS, an open source mini-framework for controlling POS peripherals such as MICRs, sigcaps, pole displays, barcode scanners, MSRs, receipt printers, etc. This will only help if you are using Java, but there may be similar libraries for other languages. Regardless, playing around with JPOS may help you understand the hardware and how all the pieces fit together.
Please realize that even a small inventory application is a major undertaking. The software I work on has an inventory module, and it is insanely complex to meet the requirements of retail inventory. Hardware abstraction can be a pain too, as you need to code at a high level in your application but deal with low level crap that most devices throw at you. For example, scanning a barcode sounds simple and may be relatively easy for UPCs, but what about SKU or inventory tags that are nonstandard? You can program the scanners to pad zeros, truncate to a specific length, strip or retain check digits, etc. and there are so many pieces of hardware out there that behave slightly differently it will give you a headache.
If you decide to add credit card processing, my advice: don't. If you have to ask this question to Slashdot, you are not prepared to deal with PCI-DSS compliance. It costs a lot of time and money to process cards securely and to prove to the payment processors that you can do it securely.
24 beers in a case, 24 hours in a day. Coincidence? I think not!