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?"
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
Try searching freshmeat before asking questions about software. http://freshmeat.net/projects/ibookshelf/
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.
Make a virtual machine with the software for a register in it. Then companies could just customize that image and deploy it on any workstation. VMware has USB pass-through, so you can use a USB barcode scanner with whatever software you make/choose for the bundle.
I'd recommend doing it on the moka5 LivePC platform. Then the VMs can be updated via the web automatically.
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.
I am sure you could find a bunch of POS software for Linux. But chances are they will either be to powerful and hard to use or easy to use and underpowered. There is a chance that you find what you need but why limit yourself with Linux when you can have many more options if you let yourself free of software religon. Getting the wrong program even though it is free may cost the company more over time. There may be a POS system that is open source or freeware for windows that may fit your need better.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
The biggest issue you will have is creating a POS Software that integrates into an Inventory database. I had this experience in 2003. Firs off, you are going to have to create a LAMP application to handle sales and controlling the inventory, and Time cards. There are applications like this. But their interface leave much to be desired. I couldn't do it because I didn't have the PHP and MySQL needs to do it.
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.
You can get cheap barcode scanners that plug in beside the keyboard and generate characters as though they were typed. Even if you don't want one of them, there are millions of libraries out there for every conceivable mix of scanner/language/OS. The whole barcoding bit is irrelevant, the question should be "Can I write a very basic app over a very basic database?". To which the answer is "Who cares?"
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.
It also better work with CBG token ring network as well and after speed king let him down he may go nuts and fire you if this does not work out.
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.
Linux POS are quite common here in Brazil. One of great users of Linux POS is a store called Renner. They have several stores across the country, all of them using Linux. So is a feasable thing and good one too. Cheap reliable, with the right interface, easy to use too. Based in what I saw, the shop clerk have no problems at all. With the logo of the program doesn't have a Linux Penguin in the interface and I have read it in one IT specialized magazine, I'll never know it or notice :)
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>
At the last Linux conference I went to, there was a talk by a guy using Puppet to automate provisioning of POS and backend systems across a national equipment hire firm (here in Australia). Works much better than the old system (fewer staff, more sites), they are large enough (400+ stores) to warrant maintaining their own system. However I'd guess that unless you have a deployment that makes maintaining your own system worthwhile, something off-the-shelf (FOSS or otherwise) would be a better bet maintenance wise.
"Everything is adjustable, provided you have the right tools"
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
It's the real comic book guy!
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.
Yea. I have. And you're right, there's a lot of noise. But there's also enough signal to make it worth the time.
Here's the thing: If you want to make a good decision, you have to actually spend the time researching the topic. There's no way around it. And when the topic is availability of free software, freshmeat and sourceforge are the place to start.
Advice is great and all, but it should just be another component of your research. If everyone just relies on advice rather than looking into problems themselves, the same wrong answers and mistakes will just keep getting repeated over and over forever.
Now, my post was direct advice - based on real experience from actually implementing a POS system in a small retail environment like the one described in the question. And part of that advice - a small but key part - is to do the damn research before implementing anything.
-- The act of censorship is always worse than whatever is being censored. Always.
You might try Apache OFBiz (Open For Business). I haven't tried it yet, but I'm definitely eyeing it.
That said, I do tend to agree with the posters who are warning against setting up something your boss can't work with. OTOH, if the alternative is to do nothing, the business probably doesn't have all that much to lose. Better for them to actually learn something about their sales and inventory than to go out of business through simple ignorance.
no good for a single shop situation.
If you mod me down, I will become more powerful than you can imagine....
http://ask.slashdot.org/article.pl?sid=03/06/13/0116212
http://ask.slashdot.org/article.pl?sid=06/07/02/007254
Acts 17:28, "For in Him we live, and move, and have our being."
There's a program called AbanQ, formerly known as FacturaLUX, which works quite well in a POS. However, it is oriented mainly to the Spanish market and has little U.S. support, I'm afraid :-(
Probably the most effective solution would be to pick up one of long-living Open Source ERP projects, such as ERP5 and Compiere, because they have been proven to work in real business scenes for over 5 years, including both at SMEs and at large companies. The applications are very broad, like manufacturers, resellers, banks, hospitals, etc. So I don't think it would be difficult to apply such a solution to your target.
As for barcode, some USB barcode readers are broadly available, and they function just like keyboards. They are recognized as usual HIDs under Linux, so it is pretty easy to read code numbers as if they were key inputs from a keyboard.
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.
This isn't the worst post ever, it's not even close. This is a lot closer, and there's probably even worse (having read the above link, that's a scary thought).
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.
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.
... 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
<shamelessplug>
We develop some gym management software which has POS software integrated. Unfortunately, it's not open source.
However, the tools we use to do it are.
</shamelessplug>
By rolling his own solution, he's saying he is committed to working their for a lifetime!
I made a quick POS to do book sales with Python, PyGTK, Adodb, and MySQL. It was quite the learning experience, didn't take very long. I actually upgraded it just this past week to ensure that it worked on Windows (it did, so it's cross platform) I just cleaned up the UI a bit. If I had to do it again I would have coded it differently, but it works, and pretty well.
I recently came across Lemon POS, it looks good but haven't tried it yet, http://www.kde-apps.org/content/show.php/Lemon+POS?content=69945
In terms of bar code scanner, I had one for my own POS. I used the CueCat, modded by some entrepreneurial eBay seller. eBay for "USB Barcode Reader - Cue Cat CueCat CueCats Scanner", I think the seller was 'herder-of-cats'. He modded it to work like a keyboard, so it essentially just "types" out the barcode, no special programming required
I used my complete app in Linux, in Linux from Windows via NX, and on Windows XP, all three times with the CueCat barcode reader and a keypad (for when I had to manually enter ISBN numbers
If anyone is interested I can share the code, just need to remove some hard coded passwords.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
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.
We have used these for years in my office, they just keep going and going: http://www.ute.com/product_info.php?id=19/. They cost roughly $100 but sometimes they can be found for much less.
JUMP JUMP JUMP JUMP JUMP JUMP JUMP JUMP IRRIGATE
I know the original poster is looking for an open source solution that runs on Linux, but I wanted to point out that a colleague of mine created an extremely feature rich point of sale system specifically for the comic store industry. Check out MOBY by Bitter End Systems: http://bitterendsystems.com/ It not only will handle bar codes and the other features you mentioned, but it will import info about comics provided by Diamond Comics, the largest distributor of comics in the U.S.
http://freshmeat.net/search/?q=Point+of+sale§ion=projects&Go.x=0&Go.y=0
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
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!
It sounds like this is a untried solution seeking a problem.
Bottom line, is this going to make money for your boss?
Probably not. You're looking for a learning experience at his expense.
Unless you can show him good reason for doing this, it's best that you just can the idea and focus on something that will make him money.
Sorry, but I'm just fed up with lower-levels pitching high-end solutions non-problems, especially when their eyes glaze over at seeing a command line prompt.
Linux POS; how appropriate.
I read 30 posts and this one was the only one that had information beyond someone's gut reaction.
I don't know if an FOSS solution already exists. I think the work necessary to come up with a FOSS solution is non-trivial but is doable by one person. Being able to use GNU-Cash, any/all of the FOSS databases and OSCommerce would be nice. While being able to process charge/debit cards is nice the audit requirements could make it something for "Version 2", processing using a separate terminal is a LOT easier.
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.
A few notes (I have experience implementing this sort of system):
Hardware budget is probably going to be in the $2k - $3k range per register.
Software, setup, and services budget will likely be in the $2k range.
That is $4-$5k for one register with good hardware. Could even be more.
You probably won't save much money by going open source here, indeed you might actually end up paying more. However, you will get something that can be customized down the road to do exactly what you need (for a price, of course) so this doesn't mean that you need to abandon the open source idea.
However, where you are likely to save money is in the long-run if you choose a program which will be constantly maintained. In general a good support contract on an open source program may not cost as much as the proprietary package plus good support. Remember this is money you are dealing with.
BTW, LedgerSMB has a decent POS module for retain environments. It is a little bit of a pain to set up but so is L'ane and at least we don't store large amounts of client-side code in the database.... (We also don't refuse to send out security patches to general users and we have a better release cycle than L'ane.)
LedgerSMB: Open source Accounting/ERP
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.
My Suburban burns less gasoline than your Prius.
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.
One project (which is usable but still a little flakey now but which we expect to make robust as we go forward) is LedgerSMB. I would suggest you take a look at our origins, our progress on key issues (maintainability, security, spooky action at a distance), and consider us for future use. BTW, we forked from SQL-Ledger. Past Slashdot comments on that program should give you an idea what we were up against...
One of our main principles going forward is to separate interface from workflow, and both of these from core logic. This way you *will* be able to improve lots of things easily without worrying about spooky bugs that you may never be able to track down. In the mean time we settle for trying to help others grok the codebase which some have nominated for worst ever.
LedgerSMB: Open source Accounting/ERP
I saw a sig on Slashdot once that really sums up the problem:
Programming is like sex: make one little mistake and support it for the rest of your life.
That is really true of business apps such as POS applications. It is a good idea to know that this is what you want to do before you start.
LedgerSMB: Open source Accounting/ERP
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.
LedgerSMB: Open source Accounting/ERP
How much work does it take to go from a prototype to a fully documented and tested implementation ?
God yes. It's bad enough to rely on home brew software built by a beginner. The real challenge is when said beginner leaves town and the owner, or even the owner's successor, is left with a totaly undocumented system to struggle with. Especially since it likely requires at least a few secret tricks of the "I'll fix that next month" variety.
Trust me - been there, done that, burned the T-shirt and bought something in a box next time.
Three Squirrels
Ohloh.net is also a good place to look. You can often get better statistics about software development activity, team size, etc. from that site.
LedgerSMB: Open source Accounting/ERP
The local anarchist bookstone, Red Emmas, developed a POS and inventory system called Infoshopkeeper that might be a useful starting point.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
The market for Windows POS (ha ha, I see the joke too) systems is large and mature. Dell has sold them for years.
I just came back from a week of vacation on Grand Bahama and every shop, even the very small ones, has a Windows-based point of sale system. It was amazing how widespread they were.
Good luck to the open source guys. Small businesses have zero appreciation for the free-as-in-speech benefits.
Ask a stupid question and get a stupid answer. This question should never have been given airtime for a number of reasons. A lot of the time the advice is asked for because the person is lazy and wants everyone else to do the leg work they should be doing. If thats not the case then there is a good chance that what the person is asking is obviously above their skill level and any solution given no matter how correct and informative at the end of the day will not be implemented. Those that can do... those that can't ask slashdot. It would be a different matter if someone came out as said "I have done this, this and this and am having trouble / can't find..." but when you come out as say "...i haven't done anything to help myself tell me what to do people..." you are gonna get told that... no effort on your part = no effort on anyone elses part.
Users... the only thing keeping 1st level support from being the bottom feeders.
I tried out OpenBravo POS yesterday and quite liked it. It is Java based, and can use HSQLDB, MySQL, PostGreSQL or Oracle as the database. The interface looks straightforward and easy to use, and you can connect up a barcode scanner and cash drawer.
I like it because it has the ability to upload sales and download inventory from a central location. I think it is supposed to connect to OpenBravo ERP, but it uses web services to do this so it should be easy to connect it up to something custom built. My requirements are different though: My wife has a business with two small shops, and a third one on the way. We want to download inventory data from a central location and upload sales back to synchronise with the accounting system. This means that the accounting can be done offsite - a vast improvement from the current set-up.
I have to agree with what other posters have said - make sure an open source or custom solution is what you really want. The accounting software your boss uses might have a POS add-on that meets your needs - the integration with the accounting system would be a real bonus.
Also, make sure that the solution is well tested - the POS is a critical part of the business and it is a real pain when it goes down. (It happened to me the week before Xmas, which goes to show how universal Sods Law is).
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.
LedgerSMB: Open source Accounting/ERP
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.
nature loves variety::society hates it get your variety at http://www.monkeypantz.net
Let me guess: written entirely in Bendigo by the kid who packs shoeboxes and fixes the air conditioner.
http://michaelsmith.id.au
For something such as that, where you dont need to "swipe-scan" items on a flat scanning table, the easiest way is using a PS/2 keyboard and a PS/2 "wedge" barcode scanner... the scanner gets plugged into the keyboard port, the keyboard into a cable off the scanner... done deal. The scanner works just like a keyboard (though some come with programmable variants to how they act, such as [CR] after scan, [TAB] after scan, etc).
StarTrekPhase2 - The Five Year Mission Continues!
BananaPOS is a GPL licensed point-of-sale application that should do everything you are looking for.
Chad http://linuxappfinder.com
I've developed a comic shop management system totally out of free software (LAMP). It does subscriptions, cycle sheets, reordering and more and works with off the shelf bar code scanners.
The next version is being written now based on Google Gears for offline use and performance reasons.
Check it out : http://www.hijinxcomics.com/
It's all GPL code, and I run instances as a hosted service for shops around the country.
dan shahin
Hijinx Comics
www.hijinxcomics.com
www.comicbookshelf.com
to mail me, first remove the evil spam.
http://pages.prodigy.net/daleharris/pos.htm It doesn't run on Linux, but it does run under dosemu or any other dos emulator. It's not open source either, but it is free (as in beer). We've used it for several years and it works great. We used a Cuecat with it for a while, but eventually upgraded to a real barcode scanner. For a small business as a trial program, it should be ideal. Eventually, assuming you don't run the business into the ground, you'll want a real POS system that works with a real accounting system.
"And now, Frank N. Furter, your time has come. Say 'goodbye' to all of this, and 'hello'... to oblivion!"
Even if you find a decent pre-built FOSS POS (FOSS/POS as I like to call it) system, I think the real problem will be dealing with the weirdnesses of a comics and collectibles business. New issues, back issues, series relationships, price differences based on condition, and all that noise doesn't mesh well with any existing inventory system I've come across.
http://ofbiz.apache.org/
I use Quasar accounting and point-of-sale (GPL) for a small retail business, and I have no complaints.
http://www.linuxcanada.com/
First of all: what problem are you trying to solve? You mention bar codes and better inventory control, which is a larger scope that just point of sale. Are you wishing to receive into inventory? Perform physical inventory? Audit? Generate purchase orders?
You mention Linux compatibility with barcode and other retail equipment: generally speaking Linux is 'compatible' with a great variety of equipment. I really don't think that will be an issue.
You mention datamining. I don't know the scale of your retail operations, so I don't really know what you mean by that. I assume that you want to know what particular customers are buying so that you can a) improve your ability to accurately order inventory, b) suggest items of interest to customers based on similar purchase patterns, and c) realize better margins by more intelligent up-selling. All of these boil down to good domain knowledge of your retail sector, good awareness of the market, and developing a good understanding of your customers. That is, ask yourself how much datamining is going to help before you go down that road. [ Do you have any kind of customer loyalty program (frequent purchaser discounts, points, etc.)
You mention output in a useful format. The format isn't that important. Understanding what needs to be reported using useful metrics is important, and the harder question. Transforming data into CSV is not that hard.
To that I'll add that I agree with some other posters as to whether you should produce your own retail systems. There is plenty of risk in such an endeavor, not the least of which is your implicit agreement to keep such a system running... forever. Of course, that's a nice inventive to do it well, too.
Since a few others have mentioned their credentials, I'll add that I produced and managed the development of a significant number of *nix retail applications for a Fortune 500 retailer.
Jim Greer
The Norton Anthology of English Literature, 4th Ed., Vol 2
See SUSE Linux POS which is sold by Novell and IBM (iPOS). http://www.novell.com/products/linuxpointofservice/
Microsoft seem to actually admire Google and thinks its pasture is greener and wants a piece of it.
While it may not be a FOSS project, check out this freeware app:
DHPOS
I installed it a couple years back at a local retail store (single PC), and it's been working just fine. From the times I sent in support questions, the maintainer was good about addressing issues in short order.
While the program has some caveats, it seems to be well suited for most small businesses.
At the very least, it's another option to consider.
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.
This statement is false.
Just curious: If SQL-Ledger was so horrible then why did you fork it instead of starting from scratch?
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.
http://www.linuxcanada.com/
It's rather a strange user interface, but it's all OpenSource so you can change it.
They could have done the support community bit somewhat better, and you do need to be a middle-rank guru to set it up.
My experience when starting up a collectively-run bookstore 4 years ago(Red Emma's in Baltimore) was that there wasn't any free software solution for a easy to use retail POS tied to an inventory, so I started writing one - it's called infoshopkeeper, which is now being used by a bunch of similar bookstore projects. It definitely took a few years of development before things were really sorted out in terms of usability of the POS and the report generation - not that any of it is really challenging technically, but it took a while to figure out how to deal with the specifics of how our store was set up, what kind of information we needed when re-ordering, how our volunteers were likely to try and find merchandise in the computer, and so on....i'd be curious if any of the larger pos packages that have come up since are actually flexible and/or scriptable enough to deal with specialized use cases like bookstores....
1) I didn't realize how bad it was until about 2 months after we forked.
2) I had customers running SL and wanted to get serious security issues for them fixed without waiting for years to get a replacement ready.
Here are some choice decisions on the part of SL:
1) Use of logins as session keys, and timestamps as session validation values (which were only validated in the sense that "this is a recent time"). This was fixed after we forked.
2) some_function(\%$form, \%myconfig);
3) In one report, he pulls litterally every invoice from the database, does some calculations in Perl, filters them in the CGI script, and then procedes to build the page.
4) No protection against SQL injection attacks (we fixed this in LSMB 1.2)
5) Interesting ideas about code structure (wandering code logic, etc).
6) Interesting ideas about security beyond #1 above. For example, the template editor could be used to do all sorts of cool things (like change other people's passwords)
7) No data integrity constraints (you know it is bad when it takes us over a year to get referential integrity enforcement working on the database)
8) Interesting ideas about database design which allow for equally interesting data integrity problems beyond mere foreign key constraints.
I am sure there are more. But we are now ripping out the all the old code and rewriting which is what we need to be doing now.
LedgerSMB: Open source Accounting/ERP
POS is core to a small business, so it HAS to work. Hence, I'd recommend an Open Source solution with support from a commercial company. It gives the boss peace of mind.
IBM and Sun both appear to offer POS products, are there more commercial FOSS solutions which have been missed?
Hm, sounds indeed horrible.
But my expirience with codebases in such a shape is that they tend
to become a timesink and it just won't stop.
What I'm seeing on the screenshots is basically a webapp and not so much else.
Why not take the database schema (at least the sane part) and start from scratch
with a state-of-the-art web framework (django, RoR or whatever fits your bill)?
I imagine security is a major concern for a POS-app and that usually cannot
be retrofitted. For each bug you squished there may be two others still
lingering elsewhere.
Well, just my thoughts. But I wouldn't feel comfortable to base my
companies POS-system on some "inherited hack". I'd much rather use one
that the maintainer is honestly proud of and that doesn't make my eyes
bleed when I actually look at the code...
Still, unless you see an opportunity to do something that hasn't been done and you think there is a market to sell your system to additional customers OR your client is
- symbologies - not all barcodes are encoded in the same format
- encoded data - not all information on all barcodes are the same - some are EIN numbers, others are SKU's, and on and on
- hardware incompatibilities - barcode scanners are NOTORIOUSLY unreliable and the manufacturers are notoriously bad at fulfilling orders
- programming quirks on limited memory devices - forget about indexed databases - even commercial products like M$ PocketSQL quickly become major bottlenecks in performance
- concurrent use locking nightmares - your system will require either real-time wireless communication with an in-store server or a sophisticated offline locking strategy to ensure data integrity when dealing with concurrent users. Yes, it's likely that there will be more than one user scanning data at one time
It is very likely that this system will be a huge time sink and financial loss for you.I do like programming things that work super quickly, especially when they work super quickly, super quickly.
Because the database is as dreadful as the Perl code.
Oh, and I missed one thing about the Perl code. Use of cute, short variable names like $a and $b (*really* bad ideas since they are reserved in the language).
Here is what we are doing:
1.3 will have a new framework we developed for this purpose. It is clean, database-centric, flexible, and enforces importand boundaries in the program. We basically are refactoring with a chain saw. We cut out a section. Redesign the database from scratch. Rewrite the code from scratch, move onto another section. In 1.3, all of the contact management, and some of the financial logic will be moved onto the new framework. In 1.4, all of the financial logic will be on the new framework. We didn't use existing MVC implementations because the way they abstract database logic suggests that it encourages bad db design.
By 2.0, we will be free of the code.
LedgerSMB: Open source Accounting/ERP
.. because that is the easy part. Any decent scanner will emulate a keyboard entry (wedged or on USB connect), this also gives you a method for manual entry if the barcode reading fails.
However, if you print your own barcodes you better investigate how EAN codes work or you'll get a conflict - there is a specific prefix for in-house codes, use it or you may conflict with a vendor issued one. Alternatively, it's very cheap to implement Code 3 of 9 (it's just a font, print as **, i.e *12.30* and you're in business) but again you have to make sure you don't end up with conflicts with pre-printed info (I found a lot of 'on-the-box' serial numbers to be in Code 3 of 9, or 2 of 5 if they were purely numerical).
Good luck with it.
Insert
Monetra is credit card processing software that runs on Linux, FreeBSD, OS X, etc. It's pretty easy to interface with the Monetra server and process credit card transactions from your own code.
And i believe theres quite a few more.
Jaycar in AU though use fedora 6 (or maybe 7),... has a barcode scanner, cash draw and everything, and they're got quite a number of stores was shocked when i saw the screen with fedora on it.
Having said that, i know nothing about it, but its obviously possible!
Is it just me or did it take reading through the entire page before I realized POS did not stand for piece o' ****
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.
Chas - The one, the only.
THANK GOD!!!
Many retailers that are low budget usually don't put a whole sited network of bar-codes an network them together.. instead they do it the old fashion way.. Pen, paper, and signature of inventory control... Which this is mainly because networking as such is very expensive.. cause they would have to buy packages from Microsoft or Linux that deals in bar-code networking with that, thoses corporate packages costs 1,000s of dollars... That an its also more secure for some business to keep a written document.. which is for security reasons.. allows the business to keep track of thefts, and make sure they don't have untrustworthy employees..
So that issue could be for two reasons.. 1 is that your company does not have a massive budget an can not afford a massive network, or 2 they just want to keep every bit of data secure, and make sure they have trustworthy employees.. Many business still do it the old fashion way.. Just cause all the virus trends that go around.. an the ability to make numbers lie on inventory control.. It isn't a matter of laziness just a matter of security and/or low budget company..
Some time company like the old fashion way, which it also gives the ability to take a opinion on how well they're employees perform in that sort of task..
Maybe he likes what he is doing instead of being a corporate push-pin like you.
www.dhpos.com
it's also got folks from all around the world using it, but as for now is DOS based.
The question is how much functionality you want. I had a client who wanted the absolute minimum because the workforce was having trouble even using a department oriented cash register properly, but needed to go to barcode entry because the volumes were too great to do it by hand. The usual bewildering POS screens were a non-starter.
If you use something like PythonCard, you can get a shopping basket screen laid out very fast. As items go in, you add up the total value. You use a wedge scanner to read the codes. When the codes are entered, go to the inventory file and lookup price and description. You use kbarcode to generate labels. You use a free 3of9 font to generate cash register sheets with non-labelable items. You also put control codes on the sheets, stuff like void item, new sale... The user should never have to use the keyboard.
The thing about PythonCard or other hypercard type layouts is that you can have buttons for everything adminwise, and lots of text around explaining what they do for new users. Documentation and training is very easy. Obviously I needed to write it to minimize chargeable time, so this was important. I password protect the admin functions and we have quite a few logs to protect against abuse.
As sales are made and as items are booked in, you have to decrement or increment inventory.
You basically have two files. One is the inventory file, with code, price, description, department, number, price x number. This is the file against which lookups are done when people buy things or when bookins are done. The other is the transaction file, just a chrono record of everything bought. When it comes to reporting, you run your report generator against the transaction file. I do not track goods in as transactions at the moment, but we could easily have a goods in transaction file if we wanted. I use simple text files to store the data, and yes, they are religious about backups. I also do not allow multiple purchases - a transaction is just one item, and if more than one is bought, read it in again.
I would not try this with more than (say) 500 different items or a large turnover, or multiple points of sale, and would only do it where the overriding need is simplicity at a level which you just cannot buy commercially. It has worked fine up to about 15,000 transactions and probably would handle 50-60k just fine. After that maybe go to a proper database for the transaction file. Support is minimal so far.
Trying to do this in a spreadsheet is not going to work. Well, it might if you clear the totals every month. Remember they have a limitation on the number of rows.
He does not link to cash drawer or till. The shopping basket gives a total. Then this amount is rung up on the till and a receipt generated in the usual way. His items are not taxable. That would be an extra complication, but not insuperable, just another flag in the inventory file.
This is definitely not industrial strength. Its strictly thrift shop, small hobbyist store, charity type stuff. And it is not universal. It doesn't have all the configurability you get from a commercial operation. Its specific to the particular operation in lots of ways. That was the price of cheap rapid development and the simplicity. I did not charge normal rates owing to the particular nature of the institution, so if its a commercial relationship and time is being fully billed, it might not make sense for them. If you need industrial strength, go to a commercial system. Other posters are right about that. But it will cost.
For my client, OSS was a cost bonus. It would have been written pretty much the same in VB and Windows to get the minimalism. But on Linux the tools (kbarcode) were free and its very stable. Runs on an old $50 Compaq by the way, with a new drive. 500mhz PIII. Quite snappy. Gnome, not that they can see it, because its autostart. Probably fluxbox would be even faster.
http://whydontyou.justusegoogle.com?rOA I get my (information) from the internet, like a normal person under seventy. Farewell, dinosaur.
It just so happens that a friend and I are about to start a project in a course at uni to develop a POS/ERP solution, and in which we aim to build on top of existing FOSS solutions. We are about to start looking at existing solutions, so you are welcome to drop me a line, so that I can get back with what we find (or what we come up with) :-)
;-)
Incidentally, I have discovered that most cheap barcode scanners represent themselves to the OS as a keyboard, and internally decodes the barcode to an identifying string, which is then sent as if they were typed on a regular keyboard
Best regards,
F
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."
8 of 13 people found this answer helpful. Did you?
$a and $b are variables which expose the inner workings of sort().
$i and $j for things like iterators is OK, but $a and $b should be avoided....
LedgerSMB: Open source Accounting/ERP
Purpose built for the job, it'll be cheaper than the combination of hardware required to give similar functionality, never mind the time spent integrating it.
Deleted
A webcam and a script is all you need apparently. Tellico has a barcode recognition part to scan in barcode via the webcam. Check it out, some discussions on the mailing list, see eg nabble and search for the barcode patch
It's THERE you freaking moron. There is a location Their stuff is owned They're is really two words HOW HARD IS THAT?!
Brief article about NolaPro http://blogs.techrepublic.com.com/righttool/?p=129&tag=nl.e138 Website: http://nolapro.com/ http://nolapro.com/index.php DEMO of Online hosted version: https://demo.nolapro.com/ 33 Screenshots: http://content.techrepublic.com.com/2346-10877_11-185265.html The article focuses on it's point of sale capabilities, but it is capable of doing the entire gamut including Order Management, Accounts Receivable, Inventory Tracking, Accounts Payable, Payroll Services, General Ledger, Administration, Shopping Cart, Business-to-Business, Video Help Library and more.
I've been working on a POS project called Rizoma Comercio, doesn't have any translation but it's currently working on a few stores here in Chile. You may want to take a look at https://savannah.nongnu.org/projects/rizoma/ Regards,
My local shop uses this, for cash and card transactions. http://freshmeat.net/projects/qpos/
Most modern cash registers support barcode scanning and have a COM port for communicating with a PC. Let the register handle all of the POS and just focus on the the inventory control. The register should be able to give you daily reports on how many of each barcode were scanned, will have functions for handling refunds, etc and presents a robust and easy to use interface.
:)
Others have said this and I'll say it again: Don't reinvent the wheel
Indeed.
To get a hand scanner to work with linux is relatively easy, if it is one that connect via serial or keyboard connector. Did it, done it. As for software, check out freshmeat.net. They have alot of POS software there, many for the kind of store you work in. If it isn't exactly what you are looking for, but close, contact the developer and see if you can work out an agreement to get the features that you want/need.
Don't try this on your own. Make the owner pay for someone else to do this.
You best bet is to call around and find some local POS installer who has heard of Linux and isn't a diehard MS fan. You will still end up implementing a Windows-based POS system, in all likelihood, but maybe the POS installer will install a Linux-Samba fileserver or a Linux-based firewall. That is about as FOSS as it gets.
Most Windows-based POS software is good enough. The real challenge is to stop users from minimizing/closing the POS software and crapping up the underlying Windows install.
Trust everyone else's explanation... this is far more complicated than you can imagine and you don't want to be some charity programmer who has to fix everything for free.
I seem to remember an open source POS system called BananaPOS. it looked fairly complete although I seem to remember the inventory system was very basic and few reports.
Many years ago I worked with a product called Synchronics which was an add on to Real World accounting software. It was a really capable system with hooks into AR, GL, and AP. I haven't seen anything of them since the early 90's so show knows anymore.
I agree that off the shelf systems can get pretty pricey, but POS and distribution in general can get pretty complex even before you get to peripheral issues.
In '97, I met a record store owner through a friend, and as soon as he found out that I was a programmer, he wanted me to build a website for his store. I was a frequent customer of the store, and I was dropping about $100/month there, so I figured I could work out a good deal for both of us. I had a day job building websites, so I assumed it would be something quick I could do after work.
The only problem was, he wanted the site to interact with his POS system, and the POS system was several years out of date. It ran on SCO, and he had scanners, printers, and VT100s hooked into it. It worked well for his needs, but he had filled up the drive, and the database was big enough that the app was running low on memory for large queries. I spent the next several months learning SCO, specing out a new box, buying a new multi-port card for the VT100s, and putting it all together. I spent a couple weekends installing all of it, and I had some uncomfortable conversations with his POS vendor about moving everything over. I finally managed it with a null modem connection. Needless to say, the record store owner could not have done any of this himself.
After about six months of wrangling, my goodwill was exhausted, and I had accumulated more CDs than I could ever listen to. The store started making support calls to my day job, and I found myself running out during my lunch hour to help them out. The system finally proved solid, and I put the website idea on the backburner. My wife was pregnant, and I had a lot of catching up to do at work before the baby was due. The owner was extremely happy with the new POS, and I felt pretty good about the job.
On the last night before my wife gave birth, the owner of the store called me to say that he had dropped the external multi-port card on top of server. The hard drive in the box was mounted on the top, so it basically bounced off the drive, and now the machine was dead. I told him to call SCO, and he had to bring in a consultant to rescue the drive. The consultant was extremely expensive, and he knew less about the system than I did. He ended up calling me at work to talk him through the recovery. I don't know if they ever got the POS back up, and the store went out of business within the year. My wife had a healthy child, and I took a month of paternity leave.
My point isn't about SCO, the POS, or FOSS. It's about technology and small business. Small retail shops can't handle technology unless the owner can deal with it him or herself. If you get them in a position where they depend on you for software development or even system maintenance, you might be doing them a huge disservice, even if you use free solutions. (I believe SCO was already free as in beer at that point, BTW.) They need to focus on selling comics with as little technology as possible, and if you're frustrated that you're not doing development, it's a sign that you're ready to change careers. Get paid to develop software or do system administration and spend all your money on comics. The comic book shop should figure out how much it can afford to spend for set-up and maintenance, then use an off the shelf solution, where the costs are largely known and fixed. You'll save yourself a lot of support calls down the road, and you won't put the store in a position where they depend on you for services they really can't afford.
What you are describing sounds simple enough to handle with an OO Database. You can connect to a database server, or use the internal DB.
Key off the barcode, and any 'wedge scanner' you connect to the PC will pass data as if entered on the keyboard. Define your tables as necessary, and you can export/generate reports as a spreadsheet, etc..
Linux POS is not quite there yet. It seems like a no-brainer, but in my experience, there is little available outside of Big Name Software Products (360 Commerce, SAP/Triversity, etc..)
You should check out Openlpos.org, FreeMercator, and other Linux POS resources...
Theres only one system made for the comics and gaming industry...ComicSuite. During in in final production at Diamond Comic Distributors.
If the book is serialized, then the author can even write with no clue as to where the story is heading, change characters at whim, introduce and then abandon mysteries claiming that they will explained later, and extend the series to avoid ever doing so.
The biggest problem with POS on non-"Ruimdows" (*see note below) platforms in Brazil is with credit and debit card integration.
There are two basic ways to accept credit and debit card transactions in Brazil. One is called TEF (pronounced "tef," not "tay-ay-effy," which is how it would be pronounced if you were to read it as the names of the letters T, E, and F) and the other is called POS (pronounced "poz," not "pay-oh-essy," where "oh" is pronounced like the "o" in "box", which would be the pronunciation of the name were to be read as the names of the letters P, O, and S in Portuguese). TEF also happens to be the abbreviation used for "transferência eletrônica de fundos," or "electronic fund transfer" (EFT) in Portuguese, and "POS" comes from the English term "Point Of Sale."
Under POS, the integration is weak at best. Basically, you have to terminate the transaction in your point of sale system (and yes, it does get confusing that POS is not used in this context to refer to your point-of-sale system; for that you would use the abbreviation PDV for "ponto de venda," which means "point of sale" in Portuguese) and separately perform the transaction in the appropriate credit or debit card system (VISA; Mastercard; American Express; Hipercard - a card used by Wal*Mart here in Brazil; etc.). The store has to have a separate card reader and PINpad for each supported card system. At most, the amount of the transaction is sent by the point-of-sale system to the card system terminal, and even this level of integration usually doesn't exist, so the transaction amount has to be entered manually on the terminal by the cashier.
As for TEF, it's a vastly superior system in many ways, but it has its problems too. TEF integration allows for each point of sale to have a single terminal that works for all store-supported card systems. Also, the integration includes the finalization of a transaction. That is, after the transaction is either approved or not, the approval or non-approval is fed back into the point-of-sale software, which then either marks the transaction as completed or allows for another attempt at payment. So that's great. The problem comes in the communication. There are technically three ways that a TEF solution can talk to the card providers (VISA, Mastercard, Hipercard, American Express, Ticket, etc.), but I've only seen two actually implemented in Brazil. For larger retailers, "TEF Dedicado" ("dedicated TEF") is available. Under that solution, the retailer has a dedicated X.25 or Frame Relay communication channel to the card provider, and the approval process is carried out through that channel. The thing is that due to the cost of having such a channel, the basic guideline is that a dedicated TEF solution is economically viable for a retailer with ten or more points of sale. For a small retailer, the benefits of dedicated TEF just aren't worth the high cost. For those retailers, there are technically two other options, but as I said, I've never seen one of them, which happens to be the one that should be the nearly-ubiquitous one, implemented.
Specifically, the two remaining options are "TEF discado" ("dial-up TEF") and "IP-TEF" (TEF over IP). The one that retailers who can't afford a dedicated TEF solution tend to use is the dial-up solution. First, let's be honest. Even in Brazil, which does deserve the label of "third world nation" in some respects, IP is nearly ubiquitous, and is very easily accessible at least in state capitols and most other decent-sized cities. So having a dial-up solution in a city like São Paulo is absolutely ridiculous. But now we get to the really ugly part. For some reason, the approval of TEF dialers and of IP-TEF solutions is done by a specific company that develops and provides TEF solutions, and that company, not all that surprisingly, refuses to approve TEF dialers other than the one that is already approved and is Windows-only. There has been speculation that this company receives money f
"It is nice to know that the computer understands the problem. But I would like to understand it too." --Eugene Wigner
Have a look at Quasar, from Linux Canada. It's an integrated business accounting suite that has a POS module for it's commercially licensed version.
http://www.linuxcanada.com/pos.shtml
phppos: http://www.phppointofsale.com/ requires apache, mysql, php