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?"

Comments

Jeff Albertson

[Anonymous Coward]

is that you?

Re:Jeff Albertson

[crazed gremlin]

Jeff Albertson, aka "Comic Book Guy" from the Simpsons

Re:Jeff Albertson

[Anonymous Coward]

Linux is, always has been, and most likely always will be, a POS.

Re:Jeff Albertson

[cp.tar]

Google it. POS on linux is not at all new, on *nix it is positively ancient.

Quite. Konzum, the largest Croatian supermarket chain, runs all POSs on Red Hat.
The owner of the chain saved millions on Windows licences alone.

I don't like the store, but I was mightily impressed when I first saw the Red Hat login screen on their POS.
I considered it quite uncommonly sensible business practice, at least for Croatian standards.

Re:Jeff Albertson

[vhogemann]

Here at Brazil Carrefour also use Linux, or used at some point. I recall reading something like "Calypso Linux" at the LCD on top of the numeric pad you use to input your card password.

Just by googling a bit I've fount this page http://www.unisys.com.br/news/imprensa/release205.htm (portuguese). Calypso Linux is a Linux based POS developed by UNISYS. It's used both by Carrefour and "Pão de Açúcar", two of the largests supermarket chains here at Brazil.

Re:Jeff Albertson

[Daniel Phillips]

POS on linux is not at all new Indeed, Linux grew 32 percent year-over-year, according to figures released by IHL Group. The research firm reckons Linux accounted for $475 million of the $5.56 billion market, putting it third overall with an 8.5 percent market share.

32 percent is actually low growth in that sector for Linux. Linux would have a much larger share of POS today if Microsoft had not pulled out all the stops a few years back when Linux threatened to make major gains.

"We began the year projecting 300-400% growth for Linux," says Greg Buzek, President of IHL Consulting Group. "But two large retail defections from planned rollouts of POS units greatly hampered the growth of the operating system. Musicland was just about ready to roll with Linux when they were purchased by Best Buy, a Windows NT shop. Best Buy changed those Linux plans. And Home Depot also was looking to roll with Linux at the POS, but those plans were nixed when the company made several management changes."

So Microsoft succeeded in slowing Linux in the retail sector by that and other means. But by no means stopping it. Linux's success in the cell phone, umpc and embedded applications of all description plus IBM's support will no doubt contribute to a resurgence of Linux growth in that sector.

Re:Jeff Albertson

[lintux]

Yes, and the people who teamed up with Microsoft and ran an anti-Unix campaign. Not sure how anti-Linux it was though..

Re:Jeff Albertson

[hairyfeet]

Since he said FOSS,I'm assuming a little mom&pop with not much cash.So here you go.Seems to have the features you want at a price of $0.00

Book on this topic

[CRCulver]

John Locke's Open-Source Solutions for Small Business Problems dedicates space to POS issues.

Re:Book on this topic

[Anonymous Coward]

John Locke? I'm Lost...

Re:Book on this topic

[Anonymous Coward]

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)

Re:Book on this topic

[Anonymous Coward]

Good call on that one; we have some silly requirements from PCI at work like "can't broadcast SSID" to deal with. However, I am not sure this person wanted a real answer. His "requirements" started with FOSS on Linux - which is NOT the way you specify requirements. The "question" is almost a troll from that alone. Requirements would be more like, "inexpensive, secure, reliable, supports multi-level department inventory, bar code scanning, etc." It may well be that FOSS and Linux can meet those requirements (probably can). However stating that in your requirements basically isn't an appropriate way to ask the question. You'd laugh at someone who put that into an RFP.

Re:Book on this topic

[Nikker]

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.

Re:Book on this topic

[Ian.Waring]

Or you could go ask GNU Solutions or PCMS about how they fitted out one grocery retailer in the UK with an end to end Linux Point of Sale system.

Ian W.

Re:Book on this topic

[Minwee]

The fact that the first response to "John Locke" was Lost and not Second Treatise on Civil Government or An Essay Concerning Human Understanding really shouldn't surprise me nearly as much as it does.

In the words of the great philosophers The Human Ton and Handy, "Come on, people! Read a book!"

Re:Book on this topic

[OnslaughtQ]

But what really surprises me is that someone referenced The Tick, specifically the cartoon version, to emphasize reading...

Re:Book on this topic

[The Snowman]

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.

Re:Book on this topic

[Lehk228]

and here i thought microsoft had a monopoly on POS operating systems

Re:Book on this topic

[1u3hr]

I am not sure this person wanted a real answer. His "requirements" started with FOSS on Linux - which is NOT the way you specify requirements.

It is however likely to get him published on "Ask Slashdot". I long ago stopped believing that any of these "How do I..." questions had any relation to reality. Most are carefully crafted to give the Slashdot crown an opportunity to make posts about their usual obsessions. Almost all are effectively anonymous and have no way to confirm the "facts" , if any, of the situation, none ever have any follow up to say what was actually done and how it worked out.

Re:Book on this topic

[einhverfr]

No, you are missing my point. Being compliant means having your network and systems up to PCI-DSS standards. Certification (or self-certification) is an entirely different issue.

For a small vendor like this, the question is not the certification, it is what happens if something goes wrong, and you have an employee who, say, steals credit card numbers. At this point a few things are going to happen:
1) Compliance will be assessed by Visa/Mastercard.
2) You will be bumped up to the top tier in compliance certification requirements.
3) If you are not compliant, you will be charged an additional "fine" by Visa/MC up to half a million dollars.

For a small vendor, this means that you really need to read, understand, and implement the standards. That is a substantial amount of work and a substantial price if you screw up.

The vendors *need* to take the PCI-DSS compliance issue very seriously regardless of whether self-certification is acceptable.

Re:Book on this topic

[neumayr]

What ever the true nature of "Ask Slashdot" questions may be - I find that the discussions they spawn to be most interesting.
Maybe even the most interesting part of slashdot.org.

Your boss has responded

[awkScooby]

No you may not

Re:Your boss has responded

[gladish]

Or "Why?" Why should someone agree to replace an existing, presumably working, system with something that you aren't sure is going to work.

Re:Your boss has responded

[Skim123]

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.

Re:Your boss has responded

[holophrastic]

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.

Re:Your boss has responded

[7andrew]

The most thoughtful thing I've read in a week... and the idea applies not only to business:business relationships, but also to business:employee relationships as well. Its not trite or self-evident that the best way to get that sort of a relationship is to carefully look at the needs of both parties and work to ensure they are both well met.

Job

[DoofusOfDeath]

"I work at a local comic and games shop,

Wow, didn't see that coming from a /. reader ;)

I guess that settles it

[noamsml]

Linux's critics will call it a POS operating system.

iBookshelf would work

[vraddict]

Try searching freshmeat before asking questions about software. http://freshmeat.net/projects/ibookshelf/

Re:iBookshelf would work

[LingNoi]

Freshmeat - off the table raw
Sourceforge - put into cold storage

Re:iBookshelf would work

[budgenator]

Try searching freshmeat before asking questions about software.

iBookshelf - Default branch
Added: Sat, Mar 12th 2005 12:39 PDT (2 years, 11 months ago)
Updated: Fri, Apr 8th 2005 00:58 PDT (2 years, 10 months ago)
Development Status] 2 - Pre-Alpha

Doahh!
Try looking at your own links, beside for a comic shop, the software would have to be a chimera of an investment portfolio program, a POS program and a FDA 501K level inventory program in other words it don;t exists. I've been looking for an FDA 501K level inventory program for quite a while now it needs to keep track of
ordering, items received by quantity, lot numbers and expiration dates and keeps track of preferred, generic, depreciated and obsolete items and what went into which product and was assembeled by who and when

Try Sourceforge

[drewmoney]

This one comes to mind: Openbravo Again, try sourceforge.

Lemon POS

[martin-sandsmark]

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.

CueCat!

[erroneus]

I've got a bunch of old CueCats! Want any? They haven't been modified... yet.

Re:CueCat!

[merreborn]

In all seriousness, I wrote a custom linux/mysql-based POS system for a client over the course of a year, and had to spend some time with cuecats.

If you do any sort of volume at all, do yourself a favor and spring for a real scanner. They start at $60, but you'll make the difference back in increased employee efficiency in no time.

CueCats are great if you want to scan a half dozen things for kicks. If you need to scan hundreds of items a day, a point-and-shoot scanner is a necessity.

Buy something off the shelf

[Anonymous Coward]

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.

Re:Buy something off the shelf

[connorbd]

Well, a good point, but not exactly a deal-killer, especially when there are off-the-shelf open source packages out there. There is a fair amount of POS Linux experience out there -- I was reading about it in Linux Journal a decade ago. There should be some way to just turnkey it.

Re:Buy something off the shelf

[Anonymous Coward]

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.

Re:Buy something off the shelf

[fwarren]

I had a similar idea as the poster a year ago with my father's retail shop.

I am in the same boat with an in-law. He owns a small mini-mart. I am trying to find any solution that will work. Neither Quickbooks POS nor Microsoft RMS are anywhere near prime time for a grocery store.

1. You can't buy beer/soda by the case and sell it by the 1 can, 6 can, or 24 can units AND be able to handle bottle deposits. QB can sell units in sets of 1/6/24. Or can do tie one product to another. Like attaching a deposit to a can of soda. But it cant' do both. Don't even try either one with RMS.
2. They don't handle lottery tickets. What if you want to turn your winning $5.00 ticket back in for 5 more tickets? Nope in QB and RMS.
3. They don't handle tracking which products are food for food stamps. I.E. Receipt is for $7.50 and 4.25 is for food (stamps) and 2.75 is non-food. Nope for QB and RMS
4. If I am shooting for the stars. They rent videos as well. Any way to "rent" items, track customers, see what is late? Nope for QB and RMS.

Even if you are willing to pay. What off the shelf software is out there to handle a mini-mart/grocery store?

Re:Buy something off the shelf

[mp3phish]

You won't find out. I work with POS professionally and you just won't.

All chain grocery store POS systems are in-house written and typically don't even TOUCH the inventory. They all work on what we call a "dump" Where you scan the barcode and it does a lookup on the SKU, but doesn't subtrace the quantity from inventory, it just changes the price of the general ledger.

They do manual ordering and receiving which means that the POS doesn't tell them how much quantity they have on hand, but what dollar value they have instead.

With these methods, if you want to handle lottery tickets, deposits, splitting a 6pack to 6x 1 packs, etc.. you will just need to create a couple procedures for the cashiers to do things like.. Maybe put cheat sheets at each cashier station, and make it part of the training. You will then just have them type in the price of the lottery ticket charge, or credit, the price of the deposit charge or credit, etc. etc... Then you can use the automated system to do all the stuff that is "normal" and for all the special stuff you do it on a dump. (type in generic part and price).

You will never find a POS system that will track your inventory on the specialty items unless it was created for that type of system and has years of support already behind it. It just won't happen. And even regional grocery chains don't have each little special case done yet. They all use barcodes for standard stuff, but they all do manual stuff with all the special stuff. Walmart is probably the only ones doing a complete management system and its only because they have about 15 years and millions invested in a home brewed system.

The pieces are all there.

[Chandon Seldon]

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:

1. Budget - Doing this sort of project poorly is worse than not doing it at all - you're going to want to cough up the money for a real barcode scanner and a real POS cash drawer to replace your current register.
2. Realistic features - This problem has already been solved, and well, but if you make up a bunch of random features beforehand (like OO.o spreadsheet output) you can be sure that none of the existing solutions will have the exact feature set that you're imagining. Unless you're prepared to write an entire system from scratch, see what exists and adapt to it.

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).

Librepos

[UUDIBUUDI]

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.

Yeah, we know about sourceforge and freshmeat!!!!!

[xtracto]

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.

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 ;-)) which one would they recommend...

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"

Not much of a problem

[Camel Pilot]

Except for this part

more detailed inventory control

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.

Linux isn't an option.

[copponex]

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.

STOP

[ceroklis]

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:

• How much work does it take to go from a prototype to a fully documented and tested implementation ?
• Are you going to be paid for this ?
• When are you going to do it ? On the week-end ?
• Will your boss expect you to offer 24/24 support, since it was your idea ?

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>

Why Open Source?

[DavidD_CA]

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.

Re:Why Open Source?

[pbhj]

>>> "much more "out of the box" than any open product"

You know "any" is a pretty all-encompassing aspersion against the whole open source POS industry.

Check out the ones I know of (from a short review about 4 years ago):

Lane POS - http://l-ane.net/
Banana POS - http://www.bananahead.com/pos/home.html
easypos http://easypos.sourceforge.net/

Can't remember any others. The point is these are all tried and tested with details of hardware on which they're implemented. I think Lane is in Canada(?) and sells the whole systems not just the FOSS but they standardise on Epson which you can get nearly anywhere.

This is off the shelf for a small business. Tying it into an OSS accounting package shouldn't be hard either.

You're totally right however that you need to look at hidden costs as well as ticket costs too.

If I were your boss I'd be scared

[The End Of Days]

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.

Excellent advice, but let me add...

[rufusdufus]

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.

Barcode scanners are like keyboards

[FridayBob]

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.

bar codes are not hard

[dominux]

a simple LCD scanner purchased on ebay for £10 including shipping from Hong Kong to the UK works just fine on Linux. It is just a USB human input device. In other words it is a keyboard. Point it at a bar code and it will type the code into the current cursor position. If you get a more expensive laser scanner then you can scan barcodes from a longer distance rather than touching the barcode as my one needs. If you get an even more expensive one then you can have it wireless so you will forget where you put it. Printing bar codes is similarly easy, google the free3of9 font and put a * at either end of the data you want in the bar code, e.g. *134567823* and print that in free3of9. For some reason Firefox doesn't like that font. Can't remember the detailed reasons but they seemed rather academic and pedantic about the correct unicode glyph positions for things that are not quite fonts. In terms of software, you don't seem to have a clue. Find someone who has. OpenBravo has a new companion called OpenPOS which might be of interest (probably too big for your needs though) GNUcash might be of some interest too.

Small Business ERP / Fulfilment isn't that hard ..

[Qbertino]

... but you have to follow some rules.

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. .... 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.

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. :-)

Your lucky day

[EmbeddedJanitor]

LinuxDevices.com has a recent article on Linux POS. http://www.linuxdevices.com/news/NS8365122751.html .

Linux is used a lot in the actual EFPOS terminals, particurly in Europe where the numbers are way higher than the corresponding US numbers.

There are commercial Linux POS options . . .

[mdshaw89]

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!

GO

[cecil_turtle]

This kind of thinking is bad - that the status quo is good enough and it's not worth trying to improve something essential to a business out of fear of messing it up.

How do you know the boss isn't open to this? An opportunity for an easier to use, more efficient system that provides more accurate metrics? How do you know the current system is some commercial product with "24/24" [sic] support and not some other home-grown process developed by an employee who is no longer there?

I wish I had more employees that saw problems, or at least room for improvement, and wanted to solve them and were willing to do the research / testing as a side project. Nothing is set in stone here, the existing system works and can continue working, there is really very little risk to trying something new here. This guy should be encouraged to research, explore, and experiment. So what if he doesn't get paid for it? Maybe this IS fun for him. It's an experience he'll be able to draw on in the future. Solving a valid business problem is much more useful than just "tinkering" with some Linux desktop.

I hope you enjoy your dead-end job, because you're going to be there a while.

Re:Yeah, we know about sourceforge and freshmeat!!

[Shadowlore]

One of the biggest problems of SF is that you can't easily get rid of projects. If you create a project but then wind up not adding anything you still can't delete it. SF needs at a minimum an "archive" system that allows owners to archive the project and then use a separate search flag/filter to include them.

It also needs a rating/quality system that considers such items as age of open bugs, last update, etc.. Not to mention time of project still listed as alpha/beta/planning.

People start projects often for good intention, and often for school work as you noted. That isn't a problem. It's a problem the SF doesn't handle those in a reasonable fashion thus polluting the space.

Infoshopkeeper

[squidliberty]

You might take a look at Infoshopkeeper "a free software solution for tying together an databased backed inventory to point of sale terminals, with an emphasis on dealing with books." It was developed by an anarchist bookstore in Baltimore.

POS is a tough problem isn't it?

[einhverfr]

Build a system which is heavily optimized for work flow, which can be used fast, has no performance problems, gives all the data you want when you want it, etc.

I mean, all the pieces are easy, but it is hard to get right.

I could have been more clear

[einhverfr]

My point is that it is *really* easy to underestimate how much data you have to be able to handle.

For a tiny business with 2 cash registers, 1M records in a year is a *lot* more than one would likely expect. Generally at that point you may want to start thinking about the possibility of table partitioning, partial indexes, and the like. It also means that when you run complex reports, it might be a good idea to run them off a replica so you don't tie up the main server.

Otherwise you can introduce performance issues into your point of sale system which is a big no-no.

You are right-- it is not a lot of data on the enterprise scale, but it is enough to make the design a bit harder for even a small isntallation, and it introduces scalability issues in larger deployments if you aren't careful.

nolapro

[maryjanecapri]

I work at a salon (as hairstylist and sole IT person) and just implemented Nolapro. it's a pretty darned good solution that works with Linux. it's not open source but it's still free (as in cost) and is, so far, an outstanding solution.

RiversPOS

[MichaelSmith]

Let me guess: written entirely in Bendigo by the kid who packs shoeboxes and fixes the air conditioner.

Much Thanks

[NegativeK]

First off, I should've clarified: this isn't actually a POS concept - it's really a inventory tracking addon. The current register (which is, really, just a calculator with department codes and basic gross sales tracking) isn't going anywhere. My idea was a standing barcode scanner attached to the computer, and the computer attached to the serial port on the register, acting as the register's barcode scanner. No worries about credit card fiddliness. The stand alone unit isn't going anywhere. The hardest POS interface issues would be entering quantity and discount percentage.

Secondly, thank you for the constructive criticisms.. In response to the "just buy something," that, unfortunately, isn't an option. The budget simply wouldn't allow it, or else the shop would already have it. As for employee training, there are only two: myself and the owner. It's really one of the reasons I want a man-in-the-middle solution (scanner to inventory tracking Linux system, Linux system to register): if the system has issues and no one can support it (you'd be amazed at the number of older computer nerds at a college town comic/games store. Or.. Not.), just pull it out and revert to the current glorified calculator. The invested work, though, is a recognizable problem. As for excess complexity, I'm really not looking to manage the entire POS experience. Most of that is in the owner's head. This is simply an inventory tracking solution, which may make it less useful, but keep it from becoming intractable. But the idea that the owner might reject it is thoroughly acceptable, for the reasons mentioned.

And as for the Jeff Albertson remarks, I'd be a fool to not get paid to do something I enjoy. I play games in the back room, make sure people don't steal, and defer all comic questions to the owner - who's in the five days I'm not. Which, naturally, is exactly what was in the verbal job description. ;)

Re:Much Thanks

[FlyingGuy]

As someone who has written a Point of Sale System, with complete inventory tracking, let me give you a bit of advice...

There is nothing simple about inventory tracking.

I admire your concept, take the feed from a standard cash register and use that to update your inventory, ahhh if it were only that simple.. Here is the problem, vendors are constantly replacing sources for items. The SKU changes but not the UPC code and/or vice versa. Just working out the issues so when you run an inventory report the numbers make sense will make you pull your hair out!

Ordering rules from vendors.... Oy! Those can be insanely twisted. Items can be ordered singly, some can't. Some items can be ordered singly put you are charged a different unit cost because its a "break pack" ( they will break up the standard unit pack of say 16 if you only need three but the cost goes up ) so you ordering code has to take that into account and hopefully group those orders together as stock runs low, or even delay the order until your quantify makes a standard shipping pack. Shipping costs which have to taken into account, because if an order is over X then you get a break on shipping, or not! Or some items have to come by common freight, because they are to large for the vendors delivery truck.

And it gets worse from there! Returns will be complicated. Is there a restocking charge for this item, some items have them some don't, If you have UPC X and SKU Y then do you ++ that item or is it the item with UPC X and SKU Z. Not all items will have a UPC when you get them, only an SKU then you have to come up with a UPC code, because you WILL run into situations where small vendors have made up their own UPC codes instead of going to the UPC code consortium and getting a UPC code assigned to their product so that it does not duplicate other UPC codes that have been issued.

Thinking through this problem logically will help a little but you must remember one very simple yet salient fact, that all the schemes are thought up by salesmen and those people will come up with the most hair brained schemes you have ever heard of.

Populating the database can be a major headache. Trying to get the source data from vendors can be like pulling teeth from a chicken. I have a client that actually had to send the "its been nice doing business with you" letter to actually get the vendor to cough up a data file of the things they sold him! Most places want to charge rather large amounts of money to give this stuff up, and when you are talking about a potential inventory of say 25,000 items on the shelves, let me tell you, entering the stuff by hand gets really old, really fast.

And then there is just making the system smart enough to keep the users from really pooching their system by setting some variable to something very wrong ( which seems very right to them ) and then the next time some process runs, your inventory gets jacked.

A lot of people will give you great advice on hardware.. Bar code readers come in either Keyboard "Y" cables, serial, or god forbid USB style connectors, the whole point of them is getting the barcode they decoded into an input field, which is pretty easy. A printer and cash drawer combo are easy to come by and they are pretty much plug-n-play. since the software for these things is pretty fully represented by OPOS ( Open Point Of Sale ) drivers. But like I said the hardware is the easy part, its the software that will drive you mad.

CC Processing is very easy these days. Most major CC Processors will give you a bit of software that connects to their system via the net as long as you can communicate over SSL and provide the right info.

Agreed. The result will be awful.

[Animats]

Not only is a one-off do-it-yourself system a headache, what you're proposing slows things down at checkout.

You're proposing an inventory system that doesn't talk to the cash register. That's where things were in low-end retail systems about 10-15 years ago, and it was awful. You'd see a cash register, an inventory terminal, and a credit card terminal at the checkout, not talking to each other. Way too much duplicate data entry. Today, it's expected that a POS system will talk to the credit card system, the inventory system, the scanner, and the cash drawer.

You can buy all the components and the software to run them for well under $2000 from many vendors. A low-end system, Cash Register Express, has a downloadable demo version (200 transactions max). Try something like that to get a sense of what the existing products do. I'm not particularly recommending this one; it just happens to be something with a demo available.

PCI cert and the CC terminal.

[Chas]

Most comic shops I've been in have a separate CC terminal anyhoo.

Even the largest chain in our area Graham Cracker, with about ten locations, still doesn't do enough business to afford fully integrated system.