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?"
Wow, didn't see that coming from a /. reader ;)
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.
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.
John Locke? I'm Lost...
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.
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)
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
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.
Not only that, but if any programming is involved, now the manager is doubly-screwed when this employee finally moves out of his parent's house and quits his comic book shop job. If there's a problem with the system, or some added functionality needed, now he's got to find someone who's both a programmer and willing to work for minimum wage.
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
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.
Actually, quite the opposite. In that situation, the manager now needs to pay the programmer a much larger wage to keep working on it, or to train someone new.
You guys always think of the client's interests, but you seem to forget that the client's interests fall into five areas -- not spending money, not spending time, not spending effort, not learning anything new, and still getting lots of work out of the vendor. That's business.
The trick with any lock-in style effort is to balance the client's interests with the vendor's interests in order to achieve a relationship that grows both businesses, ultimately giving each side more money with less effort down the road.
There's nothing wrong with supplying a solution that requires a compatent and trained individual to maintain it. And there's nothing wrong with the original vendor being in the significantly better position to do so. In can actually be a great thing for the client when you consider the extra work that a vendor can do when the vendor knows it's a long-term commitment.
In my company, we call it "aligned interests". It's the "you lose, we lose; you win, we win" philosophy that ultimately penalizes everyone should either party quit at any stage, and rewards everyone each time either party continues forward.
It's also called being proud of and empassioned in your work.
What you guys keep suggesting, by favouring the client in every stage, is more of a "you lose, we lose; you win, we lose" scenario because when everything pans out perfectly for the client, and the solution works, and their business grows, the original vendor is undoubtedly replaced by someone cheaper -- or no one at all.
Long-term business just doesn't work that way. The business world isn't the cosumer world where you sell a product, and hope to never pseak with the customer again -- because customer service and technical support are expensive to supply -- and hope the product breaks just after the warranty period -- so the customer comes and buys another.
The idea of "aligned interests" is that the client and the vendor both want the same thing and both benefit from that thing. The client wants a solution that lasts forever. The vendor needs to want that too. The client wants to get the best quality parts. The vendow needs to want that too. Otherwise you get today's consumer computers -- cheap parts, low-quality components, crap customer service, worse techincal support, and really easy to purchase a new one. The companies tend to start with the letters "D", "G", "A", or "H". And of course that's the case, they spend less money, charge more, and profit more. The only people who get screwed are the customers -- who've come to expect the products to be crap, but don't realize why.
In the business world, you can't throw out your iPod and get a new one when it breaks. In the business world you can't sell an iPod and replace it when it breaks. In the business world, you have to take the broken iPod and not only replace the device, but also replace the data stored on the device. Your clients are not consumers -- they don't consume your product/service. In the business world, the solution that you provide to your clients needs to be reliable enough for your client to base his business on -- if that solution is integral to their business, obviously.
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!