Hi All,

Can Wonderware or Citect be used to develop a point of sale application for retail shops? If not, is there any software or vendor you would recommend for such applications? You can contact me at xcsaal @ yahoo. com

Thanks in advance.

 

There are lots of off the shelf POS systems. IBM is the biggest vendor in the field, but there are many others. Many types of retailing use specialist POS software. You wouldn't use the same POS software for a restaurant as you would for a grocery store.

As for using Wonderware or Citect to develop a POS system, I can't imagine anything more futile. They don't have the capability, the flexibility, or the speed. If you want to write your own POS software, I would suggest either Python or Java.

If you want to look at a POS system, you can download the following examples.

http://www.stoq.com.br/index.php?lang=en http://www.linuxcanada.com/pos.shtml

I can't offer any recommendations about vendors, as POS systems aren't really my field. You want to talk to someone who has a lot of experience in the retail business. POS systems can be anywhere from small to large, and many are specialised to a particular type of retailing.

P.S. Sobey's (a large retail chain in Canada) tried to use SAP (a big MRP vendor) to run their business a couple of years ago. It went on line but was such a disaster that they had to scrap the entire project (at a cost of many tens of millions of dollars). SAP was simply far too slow to work in a retail environment.

 

I've used Citect and it has performed OK over time. It is kind of slow to load, but computers have gotten faster since we deployed this system. In general it seemed overkill for the basic pushbutton and number entry that we needed (Machine control application). I would consider using one of the .Net languages (C#) for the next project if possible. I've been told it is really easy to set up basic applications interfacing to database, etc.

~Ken

 

Of course it can be used to develop a point of sale application, but why on earth would you use industrial control software for that? If you really want to break into a cut-throat market like that, then use the tool-kits that the major cash register and UPC bar code reader manufacturers have. As far as I know they all are Windows based, so you have limited platform choices, but that's not different than Wonderware or Citect.

My best prediction is that even if you made a superb POS application with an industrial control systems package the run time license fees would price you right out of the POS market.

 

That was my first thought as well.
I've bid on some of these and price
is pretty important. I don't think you
could find a more expensive way to
do a POS system than to use an
automation product.  I'm pretty sure
there is free software out there if
you look. Even if it's pretty bad,
free would probably get you the contract. 

Regards
cww

 

Could you give an example of the cost for a run time license fee??

Bob

 

In reply to Michael Batchelor: POS applications seem to fall into two categories. There are ones that are just a step up from an electronic cash register. A lot of these are old VB apps running on MS Windows (including many MS Windows 95 systems). There are still many old MS-DOS text mode applications running as well. A lot of these systems were sold by small companies who are long since defunct.

Then there are the server based systems which integrate the sales terminals into the accounting and stock keeping and ordering system. Older versions of these tend to run on mini-computer operating systems, or on some version of Unix (this used to be the core business for SCO Unix). Newer versions tend to run on Linux. Many of the older ones have been shifted to Linux as well, sometimes running under an emulator. The server based systems are what most businesses above a hole-in-the-wall seem to use.

With many server based systems a PC is used as a terminal. The terminal could be running any OS, including MS-Windows. A lot of the newer dedicated "POS terminals" coming on the market use some sort of embedded Linux. Some use MS Windows CE, but suffer from higher cost (software license costs and greater hardware requirements). All the complex functionality still takes place on the server. Many of the dedicated "cash registers" that you see also interface to servers in some manner as well. McDonald's Restaurants was (are?) SCO's biggest customer (the company currently known as SCO has of course recently collapsed due to spectacularly bad management). A server in the back of each eatery would download the sales data from the cash registers to track sales and inventory (a lot of other fast food operations are similar).

As for bar code reader and printer drivers, if a manufacturer only offered a proprietary interface with sole-source binary drivers I wouldn't touch it with a barge pole. Something like that would integrate very poorly into a POS system and it would be impossible to support over the long run. We might tolerate rubbish like that in the industrial market, but it sounds like a recipe for going bankrupt in small slices if you are trying to support 5000 customers who have little technical knowledge and a high staff turnover.

As for the languages used on the server based systems, the older ones used a wide variety of obscure languages. The most common language for the newer systems seems to be Java. Some of the smaller systems in specialised markets are written in VB to run on MS Windows 2000 or XP and network to an MS-Windows 2000 server with an MS-Access database. These by the way, are typically the same developers we hear issuing screams of outrage whenever Microsoft hints at plans to drop the VB Dot Net product line, so I guess these guys are among the major remaining users of this language today.

As for your comments on the unsuitability of Citect or Wonderware (or other similar software) I would agree that cost is a major problem. This is a very cost sensitive market and the run-time fees would be crippling. I would also guess that the original poster was only thinking about the sales terminal part of the system, and not about the server functionality. I have serious technical doubts about whether these packages could be used on sales terminals, as speed is critical and MMI systems are not known for their speed.

 

In reply to Curt Wuollet: If you look at my first reply (28 March, 2008 - 11:46 pm) on this subject, you will see a URL link to the Stoq POS system which is GPL licensed. The company which is behind Stoq is also responsible for the Kiwi GUI toolkit (which they created for Stoq), so they seem to be a fairly professional outfit. There are others as well (e.g. jpos).

Just because the software is Free, doesn't mean you can't make a successful business out of it. There's more to the POS business than just selling CDs with binary bits on them. It's not like selling video games or word processors. It's more like putting in a small MRP system. Somebody has to put the system in, customise it, get it working, train the staff, support it, etc.

Anybody who wants to get into the POS business would probably be better off using one of these packages and adding to or changing it as necessary. The business is more about service than it is about writing code.

 

It depends on your position with the regional distributor. Last time I checked I think you could get a small tag count WW system for about $2,000.00US, but don't hold my feet to the fire on that number. Call your local WW rep and ask for a quote. All the Citect I've ever worked with has been modifications of existing systems, so I've never had to price them.

When you consider that the POS market is looking for cheap, cheap, cheap that's a pretty big line item to add to the invoice.

 

Preaching to the choir, Michael. I missed the link. Indeed, that business is just like this business. there's no reason to fear FOSS, because the money is in services. Nobody but AB makes big money on their hardware and software.

All the money is in what you do with it. In POS it's the same way in most cases where nearly any software package would do.  All the money is in installs, service, ACD, etc.  Some customers might do their own and you'd lose some potential revenue, but those customers would be too smart to get locked into proprietary solutions anyway.  Margins are too thin to support the
proprietary model anyways.

Regards
cww