Forgot your password?
typodupeerror
Linux Business

Linux At the Point of Sale 264

Posted by kdawson
from the pos-that-refreshes dept.
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 discussion has been archived. No new comments can be posted.

Linux At the Point of Sale

Comments Filter:
  • by Anonymous Coward on Sunday February 24, 2008 @04:20PM (#22538380)
    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.
  • by gladish (982899) on Sunday February 24, 2008 @04:25PM (#22538420)
    Or "Why?" Why should someone agree to replace an existing, presumably working, system with something that you aren't sure is going to work.
  • by copponex (13876) on Sunday February 24, 2008 @04:40PM (#22538560) Homepage
    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 (Score:5, Insightful)

    by ceroklis (1083863) on Sunday February 24, 2008 @04:47PM (#22538628)
    <paternalist advice>

    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 [jwz.org].

    </paternalist advice>

  • Why Open Source? (Score:5, Insightful)

    by DavidD_CA (750156) on Sunday February 24, 2008 @04:50PM (#22538666) Homepage
    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.
  • by Anonymous Coward on Sunday February 24, 2008 @04:52PM (#22538680)
    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.
  • by Skim123 (3322) <mitchell AT 4guysfromrolla DOT com> on Sunday February 24, 2008 @05:07PM (#22538816) Homepage

    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.

  • by The End Of Days (1243248) on Sunday February 24, 2008 @05:08PM (#22538818)
    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.
  • by Qbertino (265505) on Sunday February 24, 2008 @05:36PM (#22539098)
    ... 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 [amltd.com] 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. :-)
  • by Minwee (522556) <dcr@neverwhen.org> on Sunday February 24, 2008 @06:28PM (#22539592) Homepage

    The fact that the first response to "John Locke" was Lost [wikipedia.org] and not Second Treatise on Civil Government [wikipedia.org] or An Essay Concerning Human Understanding [wikipedia.org] 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!"

  • GO (Score:2, Insightful)

    by cecil_turtle (820519) on Sunday February 24, 2008 @06:34PM (#22539650)
    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.
  • by holophrastic (221104) on Sunday February 24, 2008 @06:38PM (#22539686)
    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.
  • by Shadowlore (10860) on Sunday February 24, 2008 @06:53PM (#22539798) Journal
    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.

  • by 7andrew (870879) on Sunday February 24, 2008 @08:58PM (#22540742) Journal
    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.
  • by 1u3hr (530656) on Sunday February 24, 2008 @10:52PM (#22541488)
    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.

  • by Chas (5144) on Monday February 25, 2008 @01:06AM (#22542552) Homepage Journal

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

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

  • Re:Much Thanks (Score:3, Insightful)

    by FlyingGuy (989135) <<moc.liamg> <ta> <yuggniylf>> on Monday February 25, 2008 @04:38AM (#22543592)

    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.
  • by neumayr (819083) on Monday February 25, 2008 @05:18AM (#22543764)
    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.

With all the fancy scientists in the world, why can't they just once build a nuclear balm?

Working...