need advice on POS system for new small retail business

dbrowne9212

dont know if this is the right place to post this but...

a small business a friends of mine has stared want to get setup with a proper POS (point of sale) and inventory system. It's a small enough shop and they jsut need a basic system to take some of the manual tedium out of their current mostly paper based sales system and also to eradicate the potential for human error in stock taking etc...

They want it done as cheaply as possible and have asked me to help. I have some experience in building databases have advised i could build them a basic system in Access or something but was wonder if anyone had any adive on a simple basic and cost effective solution that would work allow a new business to keep track of stock (in & out) customer details (if possible) and handle the transaction at the time of sale.

i have no real experience in a retail environment but here's how i'd imagine it to be setup (please correct me if i'm worng or recommend software/hardware where appropriate):

a fully fledged EPOS system with touchscreen input and all the bells and whistles seem VERY expensive from the small bit of research i;ve done so.... could They run some POS software on a PC connected to a cash drawer and barcode scanner (a PC till??) with a couple of barcode scanners for stock taking. would such software run on an access database (or whatever) or would the database somehow have to be built into the system.

as you can probably tell i'm a bit confuesd and could do with a kick start...

also could anyone recommend places to buy such software/hardware (POS software & barcode scanners)

thanks in advance.

daymobrew

I don't know anything about POS but did a quick search on sourceforge.net:
http://www.openbravo.com/product/pos/
http://www.phppointofsale.com/
http://sourceforge.net/projects/retailerorg/ (this seems to be a dead project)

Evil Phil

I looked into ePOS about a year ago as part of a feasibility study. Most good ePOS systems come with their own software which can provide a complete solution for retail based businesses, but you need to shop around.

The quotes I got for 1 unit ranged from between €900 and €2,500 for essentially the same system - that's a huge difference. Remember, that was a year ago, you'll be able to negotiate a better price than they initially quote you. Unfortunately I no longer have the details saved so I can't point you in the direction of a company - but google and goldenpages.ie did get me where I was going.

Of course you could develop your own but tbh, if your mate spends money on a good solution it will still be working in 10 years time.

<edit>

Actually now that I think of it, I was looking for an ePOS system that would work in a kitchen environment - standard retail units would be cheaper than that.

yop

Used to work as a developer of ePOS systems and did a bit of work with another so I will PM the details of the companies to you to see if they will suit your needs.

Depending on your requirement/budget/skills it MIGHT be an idea to develop your own.

Thanks

amen

I think you are crazy to do this for a friend. Go buy an off the shelf product. It will have everything he needs (reports, stock updates, reconcilliation and support etc). there is no way you could do all of this for less than what he could buy a commerical product for.

You will be in for years of grief supporting this

CountingCrows

Used to be a EPOS developer myself, like others have said I think you'd be mad to try and develop this yourself.

dbrowne9212

yeah thanks guys.

i did a bit of reasearch and called around a couple of companies. i also got a much better idea of what exactly the guys want from the system... which is quite alot really.

they basically want an EPOS and stock tracking system with integrated some accounting -which is a lot more than they initially led me to believe.

while technically i think have a pretty good idea of what would go into developing such a system it would take a massive amount of time for me to deliver anything that would come even remotely close to servicing their needs.

right now i think the best thing i can do for them is to offer advice.

figures i've getting have been anywhere from 6 to 12 thousand depending on the completeness of the solution.

somewhat understandably that has frightened the crap out of my friends but I think it's mostly a case of non-technical people not really grasping what goes into devloping and deploying viable software solutions... and maybe not seeing the big picture interms of what such a solution would deliver on their end.

anyhow... thanks for your input.

danny.

croo

I just finished a project implementing the open source OpenBravo POS (previously TinaPOS) in about 40 stores across the UK & Ireland. It works very well... and each POS station (consisting of a touchscreen, small low power (15w) box on which we ran ubuntu), drawer, receipt printer, barcode scanner and a touchscreen) was just under £2k - the UK guys sourced the hardware but if you need I can find out the precise details. OB POS uses by default an embedded Derby DB but in some cases we wanted multiple POS stations so we installed the postgres database and connect them all to one central (in store) DB. But basically any db that supports jdbc is supported. There is some basic inventory management in the POS app though we integrated it with the open source Adempiere ERP.

No point in developing something from scratch when such great applications exist - with source code - already.

Let me know if I can help more.

robindch

dbrowne9212 wrote: »

a small business a friends of mine has stared want to get setup with a proper POS (point of sale) and inventory system.

Don't forget that a fully-fledged POS system will also need to acquire and settle transactions from credit and debit cards.

This is something that you won't be able to develop yourself and I would imagine that few if any of the open-source apps do it either, as it requires some fairly serious experience with electronic payment systems as well as formal certification with the international card schemes (and I believe that no open-source app has been certified).

You can get by with a regular terminal from one of the banks or independent payment service providers, but it will slow things up a fair bit.

croo

re: credit card processing & open source
indeed this is an issue.
many open source applications do include gateways to credit card processing but the fairly recent inclusion of the pin numbers here has caused an issue. But I understood this problem is more because of a conflict between the algorithms needed and typical open source licensing - or a perceived potential conflict at least.

In the project I was working on we just used a separate device (small handhelds). It works but you are correct it would be better if this were integrated. Of course you don't have to process CC with pin numbers (web sites for example don't have access to pins) but then you face higher processing fees... so technically it's not mandatory but from a business prospective you do want this.

So in my case we didn't need to resolve this problem this time but I would like to see it addressed so have been looking at the question and I believe it is being addressed by a number of separate middleware type open projects... so now these must be integrated with the payment processing of existing POS - which being open source this is achievable.

So after saying that, the OP is considering writing a POS from scratch .. better start with an existing Open Source app in my opinion.

croo

after a little research I think I was misinformed about the reasons by chip & pin is not typical in open source and certification is indeed the issue.

found this an interesting article on the subject.
http://www.merchantaccountblog.com/735/pa-dss-and-you-thought-pci-was-a-mess

Given the numbers of companies using open source for ecommerce I can see this will be a big issue ahead. This may turn into a bonanza for 3rd party providers like google & paypal as open source projects turn to these service providers to process payments for them without needing certification themselves.

This will be an interesting topic to monitor I think.

dbrowne9212

robindch wrote: »

Don't forget that a fully-fledged POS system will also need to acquire and settle transactions from credit and debit cards.

hmm... yes. a very good point.

once again. thanks guys, really appreciate your input.

robindch

croo wrote: »

after a little research I think I was misinformed about the reasons by chip & pin is not typical in open source and certification is indeed the issue.

There are several different classes of certification -- PA-DSS is just one of them, and typically, it's relatively straightforward. The cost of PA-DSS validation given in that article ($100k) is ludicrous and speaking from personal experience, it can be done for far less than that, though if the code is as crap as most web payment systems I've seen, then perhaps $100k may not be unreasonable.

What's much more difficult than PA-DSS is writing the code which interacts with the chip on the credit card. A programmer with significant payment experience could perhaps produce one in under a year, but that's not guaranteed. And you need to certify your kernel with EMVCO before you can acquire EMV (chip and PIN) cards. More on the EMVCO Terminal Level 2 approvals process here.

You also need to figure out what card reader hardware you're using, but there are plenty of these around and most (all?) support the PC/SC interface which does make life easier, at least on Windows. If you're going to build your own card reader, then that needs to go through an EMVCO Terminal Level 1 approvals process.

If you're going to support PIN, which you're almost certainly going to have to, then you must either support each manufacturer's PIN Entry Device separately (there are no standards for PED interfaces) or else, you've to build your own PED hardware and that will also need to be certified. If you plan to run in certain countries, then you may also be required to embed symmetric (DES) and asymmetric (RSA) security hardware in your PED, and if you're not going to buy a pre-certified chip to do this, then you've to build your own which will require FIPS certification and add another couple of years to your schedule.

You will probably need to implement a Terminal Management System which is at least capable of loading and revoking the network public keys issued by Visa, MasterCard et al (though it will probably need to do far more than that -- load and revoke hotcard lists, update terminal configuration, terminal software etc). This is another six month's work, minimum, for an industry-experienced developer.

You need to consider whether or not you're going to support contactless payment methods - MasterCard PayPass, Visa payWave etc. If yes, then add yet another interface to your growing list, and another 30% to your terminal kernel development schedule.

Finally, you need to figure out how your terminal is going to speak to the bank that's acquiring your transactions. There are no fixed certification standards on the authorization side, since every country is different, but you will be required at least to demonstrate that your support all the network-defined transactions applicable for your application and your bank won't let you acquire without going through some testing. The ISO 8583 family of protocols is your friend here, but it's not used very much here in Ireland or in the UK, where the lousy APACS 30/40 POS standard is by far the most common. Oh yes, and you need to settle the transactions at end-of-day too, so add one more interface if you're using a dual-message format, which most are.

All in all, implementing a payment system is not for the inexperienced, the faint of heart nor those with shallow pockets.

Apologies about the length of this post

croo

Thanks for the very informative post robindch.

I think perhaps I have misunderstood something or perhaps we have crossed wires.

Usually in all the open source apps I know there is no actual payments processing but rather an ability to define the integration with some payments gateway. I wouldn't wish to change that personally. But from the very brief article in that link I provided (as well as some others I was reading) left me with the understanding that the new PA-DSS standard meant this approach would no longer be acceptable as it would require all software (or hardware) in the entire process to be certified, e.g. if we were talking about a simple eCommerce site that collects credit card details to pass to a payment gateway then as of the new PA-DSS, the software that collects the CC details must also be certified. Now perhaps I am reading this wrong?

As for integration with the cards themselves, well it's early days for me but I had hoped to use some existing projects such as OpenSC/OpenCT http://www.opensc-project.org which looked promising but as I say it's early days.

Thanks again for the very informative post and sorry to the OP for somewhat hijacking his POS question.

dbrowne9212

thats quite all right. i'm finding all this quite interesting myself.

robindch

croo wrote: »

if we were talking about a simple eCommerce site that collects credit card details to pass to a payment gateway then as of the new PA-DSS, the software that collects the CC details must also be certified.

Yes, that's right. Everything that transports payment card data must be PA-DSS certified. While it's certainly a PITA, there are excellent reasons for it since the older PCI standards simply haven't worked all that well when it comes to preventing massive security breaches. Think Heartland, TkMAXX, RBS and others.

croo wrote: »

As for integration with the cards themselves, well it's early days for me but I had hoped to use some existing projects such as OpenSC/OpenCT http://www.opensc-project.org which looked promising but as I say it's early days.

OpenSC does authentication using PKCS#11 and PKCS#15, and while they both use ISO 7816 to speak with cards, it's very different to, and much simpler than, what you need to do as a terminal application speaking with chip and PIN cards. A quick browse of the source doesn't really show much that you can reuse for a terminal kernel for a payment app. From the ten or fifteen files I flitted through last night, I think you'd be much better either finding something other than OpenSC, or start from scratch. Development on OpenSC also seems to have come to a halt which isn't going to help much.

As I said above, writing the code required to speak correctly with chip and PIN cards is a long and difficult undertaking. Last summer, I wrote a special restricted-use kernel in C++ -- implementing around 75% of what's required for a full app -- and that took me around two months, but I've code for what's effectively a full kernel already that I could reuse and I knew what I was doing. Somebody coming to it afresh without reusable code can expect to spend a minimum of between five and ten times as long doing the same thing, with a further period working on kernel certification.

Open-source-wise, I don't really know what you can do. The guys at JPOS have successfully implemented open-source within the payments industry, but they're working on the terminal-to-host and inter-host sides, not on the terminal-to-card which is typically the domain of the terminal manufacturers.

BTW, from January 2011, all European cards must adhere to the tougher DDA or CDA security standards which implement hard card authentication, rather than the simpler SDA standards that most European issuers currently use. Whilst any certified terminal kernel should support all three anyway and should therefore, notionally at least, be fully-working already, I have my suspicions about whether or not all actually are (cf the current problems in Germany with fully-certified cards, terminals and networks). And that, together with a parallel but unmandated move to encrypted offline PIN between the PED and card rather than the current cleartext PIN, are probably going to make life significantly harder for terminal kernel writers over the coming year or two.

I think I need to get out more

CuLT

I've been following this thread the last couple of days, purely academically, some fascinating insights into technology I'd not otherwise have encountered.

Much thanks to you both, croo and robindch.

croo

thanks again robindch.

re: jPOS
aha, yes I know of it as OB POS uses this for some receipt printing & cashdraw opening. I hadn't thought about it for card readers. Will check it out. thx.
Just to be clear, I don't want to develop an actual payments system; as you say the skills required are simple too specialized. As I see it, all I need is:
*the POS can tell the card reader/payments hardware, how much to bill, and
*the the reader can confirm payment to the POS with an authorization.
Hopefully that will not be rocket science.

Seeing as the OP needs more the POS now, another excellent open source project I know something about is "open for business" or ofbiz. It's an Apache project and is usually considered an eCommerce app, but actually it is a lot more with lots of "back office" functionality too... it's really an ERP. And it includes a POS; actually it has two a web based POS and version that runs "locally". I've not even looked at the web pos but their standard POS uses 3 levels of data replication to integrate with the back office. I've not implement this POS but the framework on which the whole OfBiz is built is excellent. Though be warned .. most people find the code a complete enigma initially. There is lots of info and some very good videos of how to use the framework on their website (www.ofbiz.org). But this is not so much an "off the shelf" product as OB POS, but rather this is aimed more at developers/implemeters and it is expected to be the basis of a solution you mold for the end customer. But I think it;s one of the best open source business apps out there.

karlr42

Given the complexity that appears to be arising, would the OP not be better served by telling his clients to speak with a company in the business of turnkey POS systems?

Owen

Be wary of Irish suppliers. I worked for an ePOS supplier in the North for 11 months who were really taking the piss when it came to software and hardware prices. They were buying thermal printers you could buy as a member of the public for 300 euro, wholesale for around 200, and charging customers 800 euro. And you would die when you heard the price of the touchscreen terminals, they really did push the boat out on profiteering.

Worse again, was that they were writing their own software, which was developing as they deployed it.

Buy a tiny PC, buy a touchscreen monitor, and go open-source. You won't look back, and your wallet will thank you.

dbrowne9212

karlr42 wrote: »

Given the complexity that appears to be arising, would the OP not be better served by telling his clients to speak with a company in the business of turnkey POS systems?

hmm... being the OP i think that the answer to that one is probably yes.

while if it were my own company I would be very tempted to go the PC,Touchscreen and OpenSource software route i dont think it's worth my while entering into the creation of an imperfect solution that leaves me suporting the bloody thing for the rest of my life.

Think the best thing i can do for em now is explain all the issues and maybe use some of my newly acquired expertise in POS systems and transaction processing to frighten the sh1te out of a couple of sales reps and help them negotiate the best deal they can get

Thanks for all the advice, input and PMs though, as i've said it is very much appreciated.

robindch

croo wrote: »

aha, yes I know of it as OB POS uses this for some receipt printing & cashdraw opening. I hadn't thought about it for card readers. Will check it out.

JPOS is not used for terminal-to-card interaction. It's only used on the upstream side of the terminal, when it's speaking to the bank (or for banks and payment networks chattering away amongst themselves).

croo wrote: »

all I need is the POS can tell the card reader/payments hardware how much to bill, and the the reader can confirm payment to the POS with an authorization. Hopefully that will not be rocket science.

No, it's not all that difficult but retail-class middleware like this is something I try really hard to avoid, and I can't advise you here.

Having said that, three local suppliers that spring to mind are Integral in Dun Laoghaire, Elavon and Payzone and each of these might be worth a call although I can't vouch for any of their products or services. I need hardly add that none of them are open-source, though they certainly will take care of a lot of the hard work for you.

Best of luck!

croo

robindch wrote: »

JPOS is not used for terminal-to-card interaction.

I think we must be talking about different things called jpos ... thanks for all the insights and advice. appreciated.

Tim M-U

Using openbravo, great!

I would use the external terminal because in any case the terminal is covered by he provider and you can choose in he pos software to have 'external' if you like..

Openbravo: http://openbravo.com . *****

homebrew.ie

Hello,

I run a small homebrew shop in Athlone which has grown a lot over the past year and I am now finding it very hard to keep track on stock and my little till that I purchased on ebay is really not doing the job anymore...

I dont have thousands to spend though on an EPOS solution prob max €500. Do you think Openbravo would be for me? I know very little about computers, need stock control and EPOS.

Does anyone know where I would be able to price a scanner, pc and touch screen? Do you need a lot of technical know how to setup this stuff?

Thanks

Donal

croo

Well the 2k I mentioned for an openbravo POS was all the hardware costs! So a touchscreen, barcode reader & drawer etc... and most of that cost was the touchscreen (they are still pretty pricey), the drawer and barcode reader are cheap enough I think.

But if you have an old PC lying around you could use that, the hardware requirements are not very high (the system we used was a atom based cpu - so not very powerful!)... the software costs are Zero so at least you could try it out see if you like it and it fits you needs. All you'd lose is a little time!

Trojan

Hey Donal, I know this thread was originally posted in Development but you might get better results asking your question of the retail gurus on the Entrepreneurial & Business Management forum.

jimmycrackcorm

It's not necessary for EPOS software to integrate electronically with payment gateways - it simply must be able to register that a payment was made with a card. you can always use the standalone terminals to process the actual payment.

It just means you have to cross check your balances between the epos reporting and the chip terminal reports. This might be inconvenient if there are problems but it would cost a lot to actually get the integrated certification.

OpenBravo looks interesting but I don't see any promotion facilities for example so I don't know if there is a lot in it.

Having written fully functional EPOS systems myself I think the time is ripe for a move to a web based EPOS service.

croo

the time is ripe for a move to a web based EPOS service

Apache Ofbiz have one. As well as a standalone POS (with replication) and an eCommerce solution and lots lots more. The downside is its complex.

I don't see any promotion facilities for example

There are no promotions (but apache ofbiz again is very complete in this respect) in OB POS but you can define template discounting and apply them ... but manually they are not automatically applied. Still, it's open source, the code is there it would not take a lot to add more complex pricing/discounts/promotions.

A UK company I partner with implemented OB POS for a restaurant and that raised issues with concurrency. It's unlikely to occur in a retail store scenario but in a restaurant two people could be modifying the "table's" order at the same time and this was not considered in the design. I don't think the solution was any great issue and again with the source code available all is possible.

The Apache OfBiz POS is in many respects just as capable and in some areas (such as promotions!) better but it perhaps doesn't look as well. Much can be changed in OB POS without coding changes but in Apache OfBiz that would require editing files (configuration files but it's still daunting if you are not a developer).

PS. OB POS was originally called TinaPOS until OpenBravo acquired it.

Freddio

Hi I put together a POS system for a friend a few years ago in a successful DIY fashion

what we used was
1 x PC with windows XP
Turbocash Software (Free)
1 x Barcode Scanner (eBay / New)
1 x cash drawer (eBay / New)
1 x epson receipt printer (eBay / Liquidation stock)

The learning curves were
getting the drivers for out of production receipt printers
setting the barcode gun to read the correct format barcode

You wouldnt need to worry about credit cards if you had one of those hand held card readers that most shops and restaurants have.

I think the whole solution (including PC) came to 900 euros

Hope this helps

jimmycrackcorm

I had looked at solutions such as Turbocash and OpenBravo but the problem with them is that they are not well suited for EPOS in a typical high speed retail situation.
E.g. Turbocash is geared towards normal invoicing and not typical retail cash sales. How many applications for example allow you to scan items and then simply press a €20 cash button to finalize the sale immediately. AlsoI haven't seen any that will allow you to do promotions such as the Boots buy any 3 get the cheapest item free type.

The more I think about the possibilities with an online EPOS using a rich Silverlight interface, the more I'm tempted to do a rewrite of my existing EPOS.