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?"
is that you?
John Locke's Open-Source Solutions for Small Business Problems dedicates space to POS issues.
No you may not
Wow, didn't see that coming from a /. reader ;)
Linux's critics will call it a POS operating system.
My new blog
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.
I've got a bunch of old CueCats! Want any? They haven't been modified... yet.
This comment will not be appreciated by Linux die-hards: I recommend you to opt for a relatively affordable and popular off-the shelf product. Why not something that you hack together from a collection of open source libraries? Well, if you will stop working at the shop then at least your boss will have access to support. Yes, I know that there are plenty of forums for support of OS software, but typically these are mainly good if you are already pretty techy.
In this case, I don't see the need for a religious OS war. Just buy a decent an popular tool, no matter what the OS is.
The pieces to implement any sort of reasonable retail POS setup using FOSS are all available.
There are two things that it sounds like you're going to have problems with though:
The last time I looked into this specific problem the nicest looking piece of software for my requirements was L'âne, but you'll want to actually do the research yourself (try searching on Freshmeat and Sourceforge at minimum).
-- The act of censorship is always worse than whatever is being censored. Always.
Librepos may be of interest. At my company we just started to implement this, so I can't tell alot about it, but from what I've seen and from my coworkers' responses, it does seem up for the job (replace old cash registers, inventory for merchandise). The software was incorporated in OpenBravo not too long ago, it's probably quite decent. They call it OpenBravo POS now.
I am so tired of these "look at sourceforge and freshmeat" answers we get everytime someone asks for advice on slashdot. I am sure peope already know those exists. But have you *really* tried looking for a software project in SourceForge lately? I have. And even though the filters are nice, the amount o garbage projects out there is amazing. And there are so many projects that misleadingly have the "stable" or "production ready" labels which are not even on pre-alpha. Or others that say they are focused to "end user" and is a darn API.
;-)) which one would they recommend...
Really, the noise-ratio of SourceForge is amazing, given that everyone and their mother can upload projects. When someone posts in slashdot is to know things that have *worked* and are working currently for other people. Sure, there are thousands of books about dating on amazon, but if you wanted one, you would go ask some people (not in slashdot of course
If you are going to recommend to look on SF or FM, then please consider just looking at the next story on slashdot... you really do not add anything useful to the conversation.
And to the parent, sorry it is nothing personal, but most of the posts I read at the time of my reply are among the same lines. I am also interested in the original question, but as I said before, I am looking for *experiences* from another people using such software rather than only a list of all the "Yet_Another_P0S I_started_for_school_homework.sf.net"
Ubuntu is an African word meaning 'I can't configure Debian'
That is where the works... integrating with the rest of the business software.
I have written an html/cgi Point-Of-Sale for my wife's hot sauce retail shop. Works excellent and is integrated with a custom and much larger web store builder, order manager, and inventory control. This is the hard part and consists of several thousands of lines of perl code.
As far as bar code reading you just use a wedge or y cable and it acts just like keyboard input. A little javascript to ensure which form field is the active/default field and you are away. Input can come from a bar code scan or keyboard input for those items which are not bar coded.
Same mechanisms on vendor order receive for inventory maintenance.
First, are you even sure you're doing the business to necessitate a POS system? Is there a problem with theft, being out of stock, or are you trying to sell things online? You may have a solution in search of a problem.
I highly recommend getting a turnkey system. $2500 may seem like a lot of money, but that's all it costs to get a complete solution from Dell or another provider for Quickbooks POS. It will work 99% of the time; it's compatible with QuickBooks, and it includes everything you need. Plus, with ODBC, you can easily tie in your inventory levels with an e-commerce solution.
Think about this: if the system only lasts for two years, you have spent a little more than $100 a month or $3.40 a day on probably the biggest expense (besides COGS, rent, utilities) in a retail environment. How much time and effort would it take to get a Linux solution to be usable, and how much are you paid per hour? Hopefully more than $3.40.
Don't do it.
For you it is "kicking around", a fun project, a proof of concept. For your boss it is a tool, essential for his business, that has to work flawlessly.
Now ask yourself a few questions:
Besides, realize that POS software is the least exciting thing you could work on. If it is not your job, forget it. If you want to tinker with linux and learn things, do something fun.
Remember: you are not the first.
</paternalist advice>
I realize this is Slashdot, but for your owner's business why does this have to be an open source solution?
There are plenty of businesses who are quite satisfied with solutions from Intuit or Microsoft that are very affordable, easy to use, and much more "out of the box" than any open product.
And if your owner is already using QuickBooks or Small Business Accounting, then a POS solution can tie directly into it.
Remember that your employer is going to pay either way. Either by paying you to piece together a solution for him or by paying for off-the-shelf software. You would be doing a disservice to your employer to only recommend one side of the fence.
-David
If you're going to 'break out the programming books' to work on something as vital to a retail business as a POS system, my only answer for you is to walk away slowly and forget such grandiose dreams. You aren't yet equipped for it.
I used to own a bookstore and had the exact same idea. Since I am a competent programmer I build my own scanning system. It worked fine. But.
I wasted a lot of time on that system, and should have just bought an off-the shelf product. But.
In actual point of fact, the data mined by using the scanner was useless. The reason for this is simple: the manager of a small store who spends a good part of their lives inside will already know what needs to be done, whats selling and whats not. There is little insight gained from the data you gather.
And.
It degrades the customer experience in subtle ways. First off, it makes the transaction just a little bit slower. This irritates customers. Next, it adds a level of distraction to the employees whey they have to pay attention to so fine a level of technical detail; the added 'cognitive load' of using and keeping the system up to date fatigues them and makes them more system oriented and less customer oriented.
In short: this sort of fine level of tracking is net negative to a small retail business.
To a PC, a barcode scanner is nothing strange: it looks and behaves exactly like a keyboard. The first barcode scanners I played around with even came with splitters so that you could attach them to the PS/2 port along with the keyboard. Those scanners also came with some templates (barcodes) so that you could set the barcode scanner to read the barcode type that you were using for your inventory. The rest is up to your Point-of-Sale software that only needs to support the principle. The cursor needs to start in a field where the barcode is filled in, it uses the barcode to look up the matching product in its database, it fills in the description and price and then jumps to the next product. In other words, if the scanner were to break down you could just as easily type in the human-readable codes on the barcode stickers and the software would work the same (except that it would take longer). I was relieved to see that there was nothing OS dependent about these devices: no drivers necessary. I'm not entirely sure anymore, but I believe the USB version of the same barcode scanner didn't come with a separate power supply as the PS/2 version did and simply looked like a second keyboard to the PC.
... but you have to follow some rules.
.... Unless of course it's super-easy to get Python (or any other favourite PL of yours) and MySQL running on it. Which wouldn't suprise me given the advancements in IT and raw processing power. Even then you want a hot spare backup at any case.
...) .
:-)
I've done a few small to medium business ERP setups based entirely on OSS. Point is: OSS or not isn't really the question, since you want openness, accessible Data and zero-fuss flexibility.
Small business systems actually are quite flaky - unless you're shop is using a well-designed vertical market system tailored for your shops needs. If that is the case I'd be carefull about attempting to 'improve' anything. Look at where the work is - like data migration and merging of data sources. That's enough work to start with and can have your boss notice that custom ERP can speed up the business. Measured by that regular closed-source bases small-business solutions can be exceptionally crappy beyond imagination. I've seen 15+ employee shops running on software so crappy you wouldn't even believe it.
For a portable barcode terminal running on OSS/Linux, AML should have you very much covered. That said, I'd personally recommend building the entire base system client-plattform independant, read: As an internal Web Solution with some small linux server tucked away somewhere and just using the PDA terminal for gathering.
If you plan well, the biggest trouble you'll have will be data-migration, syndication and integration, which actually is the fun part of ERP programming. Make sure that any client tools your boss is accustomed to use have zero-fuss in and outbound connectability, data-wise (CSV tables will do).
You want to plan your little project in such a way that it doesn't interfere with running business and that you and the people involved have time to test it. And you *do* want to test it thouroughly. If your boss discovers that your system has been omitting VAT and clipping it from the revenue at the end of a quarter, he'll have your ass and balls for breakfast. And for good reasons too.
Look into regular expressions and the powerfull data objects of the PL of your choice (Dictionaries in Python, Arrays in PHP and Hashes in Perl), they do wonders for this sort of job. I like to use OpenOffice for printing the bills - you can automate OOO within the CLI. I don't like the existing OSS ERP setups, because AFAICT they're more trouble than they are worth - I usually roll my own. You might want to do that too - maybe using some generic webkit or something (Zope, CakePHP, Django, Typo3, whatever
You also want to know your way about object modelling and entity relationship modelling. Don't even try this sort of thing without understanding the basics of ERM(!!). If you and the people involved aren't aware of, let's say, the difference between a product and the booking of a purchase of a product then you'll be in deep shit half way into the project the latest.
And do see to it that you understand *ALL* relevant business processes involved before you run your mouth with your boss. Could be that he very much likes to do things by hand at night just to slip the one or other sale past the IRS or something like that. If you don't know the details and can't say for sure that automating this or that would really improve business without any downsides be carefull. You can even run the shop into the ground if you boss doesn't think either and believes your freshly bred ERP pipe-dreams.
Good luck.
50 Cents from a professional web-centric business process automator and consultant.
We suffer more in our imagination than in reality. - Seneca
Linux is used a lot in the actual EFPOS terminals, particurly in Europe where the numbers are way higher than the corresponding US numbers.
Engineering is the art of compromise.
If you are interested, IBM does have a Linux POS software solution called IRES, based on Novell Linux. Check out http://www-03.ibm.com/products/retail/products/software/ires/ for more information. Good luck!
Freshmeat - off the table raw
Sourceforge - put into cold storage