Rails based Point of Sale?

rubyonrails-talk
1

Hello,

The company I work for is a national franchisor of about 100 retail stores across Canada. We currently use proprietary, firmware based point of sale hardware that costs us thousands of dollars per store and still doesn't work properly. So, we're looking for alternatives.

We currently use RoR for our back-office pricing management. I like the idea of using RoR for our POS front-end as well. I've been searching for a Rails POS app online. It looks like various people are writing POS apps, but I'm certainly not seeing anything like “gem insall pos”!

One of the options on the table is to build our POS system from the ground up. There are plenty of options when it comes to open POS hardware (basically, a single unit that integrates low end computer, touch screen, printer, cash drawer connection, and USB ports for a barcode scanner).

But, I have mixed feelings about attempting to write our own POS software. We're not looking to become a software development firm. I do the current Rails programming in house, but I'm no expert and this would need to provide enterprise reliability.

One other twist is that the stores can't be without their POS even when their Internet connection goes down, which it will on occasion.

My thoughts on how it could work: - Have each location be running a local copy of the app on top of a single Mongrel server. That way, its not dependent on the Internet connection.

- Item pricing, etc. would be pushed down to the store via mysql master/slave replication. As far as I can tell, this would accommodate the occasional interruptions in connectivity (but again, I've never set up replication – I'm just going off of what I've read).

- Sales data would be pushed back to the main database here at head office from each location periodically via a backgroundrb worker.

- The app would be fully ajaxed and would need to provide very quick response since we're dealing with quick service retail (coffee shops and convenience stores)

- The item and sub-menu buttons would need to be configurable by store, since each store has different needs.

- I really like the idea of being able to upgrade all 100 stores overnight just by doing “cap deploy”!

- Would need to be able to integrate with the printer, cash drawer trigger, and poll display. Let's hope that those all have Linux drivers. That would be one of the requirements as we source the hardware. (The barcode scanner is simple to integrate since we'd just set it up to mimic keyboard input.)

So, my questions are: - Is this a bad idea? I'm looking for some expert input. Could a system like this deliver enterprise reliability and speed?

- Our company would be interested in financially supporting an open source POS gem or plugin. But we've never done anything like that before. Where do we start? How do we embrace the open development pattern while making sure that the features we need are included?

Your input is appreciated.

Sincerely,

Scott Ward

2

My thoughts on how it could work: - Have each location be running a local copy of the app on top of a single Mongrel server. That way, its not dependent on the Internet connection.

- Item pricing, etc. would be pushed down to the store via mysql master/slave replication. As far as I can tell, this would
accommodate the occasional interruptions in connectivity (but again, I've never
set up replication - I'm just going off of what I've read).

- Sales data would be pushed back to the main database here at head office from each location periodically via a backgroundrb worker.

- The app would be fully ajaxed and would need to provide very quick response since we're dealing with quick service retail (coffee shops
and convenience stores)

- The item and sub-menu buttons would need to be configurable by
store, since each store has different needs.

- I really like the idea of being able to upgrade all 100 stores overnight just by doing "cap deploy"!

- Would need to be able to integrate with the printer, cash drawer trigger, and poll display. Let's hope that those all have Linux drivers. That would be one of the requirements as we source the hardware. (The barcode scanner is simple to integrate since we'd just set it up to mimic keyboard input.)

So, my questions are: - Is this a bad idea? I'm looking for some expert input. Could a system like this deliver enterprise reliability and speed?

The sort of thing I would be worried about would be whether a web app
can provide the flexibility you need (especially when it gets to
things like controlling the printer - you're average web site can't do
that (thank god) and hitting control-P ain't going to cut it. Running
the app locally on each POS might sort that one out. At the point of transaction your app is doing very little probably
just inserting a row per thing sold, and then maybe a table which
bundles all those items into a single order, so I wouldn't have
thought speed would be too much of an issue. You're always going to
have more latency than a desktop app, but as long as it's sub 100ms no- one's actually going to notice. Then again I know nothing of POS apps,
so take everything I say with a pinch of salt.

3

- Would need to be able to integrate with the printer, cash drawer trigger, and poll display. Let's hope that those all have Linux drivers. That would be one of the requirements as we source the hardware. (The barcode scanner is simple to integrate since we'd just set it up to mimic keyboard input.)

My advise would be a mixed desktop/web app. The desktop app takes care of the POS hardware interaction and caches the products on sale in the outlet with sales prices. That way it will continue working and storing sales even if the internet connection goes down. At regular intervals it sends out the sold products to the web app (using a POST with form values). The web app is used for everything else: product management, reporting, …

- Is this a bad idea? I'm looking for some expert input. Could a system like this deliver enterprise reliability and speed?

Although not a web app, have you had a look at LightSpeed at http://www.xsilva.com/ ? I've heard very nice things about it from people i know that use it for their stores (one of them which does have several stores across the country). It's a proven product and I have to say it looks damn good. It uses OpenBase as a database and one of the key features (heavily used in another OpenBase powered app, namely Daylite Award-Winning Mac CRM Software for Your Small Business | Daylite) is transparent offline/online synchronisation. OpenBase is really a very very nice DBMS.

- Our company would be interested in financially supporting an open source POS gem or plugin. But we've never done anything like that before. Where do we start? How do we embrace the open development pattern while making sure that the features we need are included?

Well, for this kind of thing you're better off following the path Rails itself originated from, i.e. start off by letting someone develop your app for you, then give it to the community to see where it takes you. Do know that some projects lend themselves better for open source evolution than others. Rails is a development framework, so it can expect more contributions than a POS app. Same goes for CMS web apps, as most of the times developers see it as a way to cut down the initial development cost. A POS app is effectively an end user app used by non-developers, so I'd have my doubts about its continued development as an opensource app.

Best regards

Peter De Berdt

4

- Item pricing, etc. would be pushed down to the store via mysql master/slave replication. As far as I can tell, this would accommodate the occasional interruptions in connectivity (but again, I've never set up replication – I'm just going off of what I've read).

Or you get the price changes via cron job, etc. I strongly advice to test if and how well mysql replication works on a large client set over long distances.

In case you ditch that mysql idea, I also recommend to take a look over postgresql.

- The app would be fully ajaxed and would need to provide very quick response since we're dealing with quick service retail (coffee shops and convenience stores)

Ok, now at this point I give you one strong advice: Don't.

Seriously, look at the GUI toolkits, like TK, GTK or others. Complex ajax applications can be very hard to maintain.

- Would need to be able to integrate with the printer, cash drawer trigger, and poll display. Let's hope that those all have Linux drivers. That would be one of the requirements as we source the hardware. (The barcode scanner is simple to integrate since we'd just set it up to mimic keyboard input.)

Barcode scanner is simple. Most USB models will work also because they act like a generic HID device. For Printers, better have a look at the hardware first. For cash drawer I've absolutely no idea. How they are connected? RS232? USB?

Get yourself one piece of the used hardware each for initial testing before deciding which platform you will run on.

- Our company would be interested in financially supporting an open source POS gem or plugin.

Nice.

But we've never done anything like that before. Where do we start?

Start with experimenting. Check if your hardware is compatible, or how you get it compatible.

How do we embrace the open development pattern while making sure that the features we need are included?

I think this is a good example where once size doesn't fit all. So I strongly advice to separate framework and application.

What you probably want is an application framework which includes basic features like the hardware support and a basic GUI.

If you have another customer for it you can easily make and sell a customized GUI to him.

I also advice to use a proper open source licence. Since I assume every interested developer in your framework does it for a commercial project, it won't be much of use if you distribute it for example under GPL.

5

Scott,

I have just located your post, so I hope my reply is still relevant. Our company has developed a Point of Sale (POS) fully ajaxed Web application for SPA that includes Front Desk operations - checking in/out customers, Retail sales, and touch-screen-based Bar & Restaurant module. After two years of deployment in high-speed grilling retail environment we have quite an expertise in the field of Web-based POS. I must tell you, Web POS was much harder than we imagined.

Here is the setup: - POS devices with native interface - Cash Drawer, Receipt Printer   We used JPOS and applets to make Web app interface with those devices. Applets are controlled through JavaScript and do not paint anything at all (god forbid), they are just used to provide interface to devices.   (We also wrote the emulator applets for testing on PCs that do not have those devices attached)

- POS devices with Windows HID interface - Mag Card scanner, Barcode scanner.   These devices work like a keyboard by sending text to Web form fields. We have not done that for Linux, but I am sure the same is possible.

- Ajax UI. Although we have been using Ajax well before it was even given a name (employing old iframe trick) - Web POS required much more trickery. For example, we often load a large Web page with hundreds of DIVs which then can be switched lightening fast - on par with native desktop apps. Another example - POS personnel does not tolerate small text-based links and icons. Instead we redesigned UI that now often looks like a bunch of big colored buttons/images.

- MySQL server. No matter how much memory we threw at MySQL - the latency was just too high for the Web POS. We considered MySQL's memory-based storage engine (NDS), but it was not mature enough. We also considered memcached (which is often used in high-volume Web apps), and other third-party caching engines, but in the end decided to write our own transactional cache. We felt that the requirements here were quite different from the typical memcached setup: the App is heavy on writes; the objects are much more complex and form the complex trees. Some objects are small, while others are quite large, so serializing and de-serilizing objects and their trees to/from memcached would create and extra cost. In the end, bulk of the logic would be outside the memcached anyway, so it would not save us much work.

- Local Web/App server with a hot standby slave at the hosting facility. Master works on Windows, slave on Linux. The challenge here was a real-time replication/backup. We decided not to use MySQL replication. Instead, the in-store server pushes transactions in real-time to Amazon S3 highly reliable storage. Slave Web/App server on Amazon EC2 picks transactions up from S3 and applies locally. We also do incremental DB backup to S3 on a daily basis accompanied by a full symbolic backup to S3 on a weekly rotation basis. Benefits: a) master is completely decoupled from the Slave(s). b) we can have as many slaves as we want to without increasing load on a Master. c) all replication data is stored in a reliable storage facility (S3). d) replication and backup are integrated. e) all files uploaded via Web forms on Master are also replicated to Slave f) we can cherry pick what data to replicate in real-time and what not to - achieving high speed and bandwidth savings. Slave server serves as an aggregator for multiple store locations, for data warehousing, for testing, for off-site access by remote managers (franchise owner does not need to be on site yet can see all the operations) and for the personnel training. The setup is capable of replicating in the opposite direction - to push prices, for example.

- We have created a prototype Web UI working on iPhone, Nokia S60, Nokia 800 and future Android phones. These devices can be used in-store for on-the-spot customer service, by the remote managers and, in the future by customers for mobile e-commerce and customer support. Although we started with our existing Web UI and attempted to adjust it, in the end we threw it all away and built the completely new UI for mobile devices. This is really a separate topic. Let me know if you are interested and I will post more.

- One last bit - sorry for saving this for the end - it is not a Ruby app - App server is in Java. Is has a unique Web 3.0 architecture which allowed us to make the actual application code about 100 smaller than usual. App is a set of purely declarative domain objects (defined as Java classes). Business rules are written in server-side JavaScript (using Rhino JavaScript Engine) and it should not be hard to incorporate JRuby for this purpose.

I hope the above info was useful to you. P.S. You can see several flash movies of the above app in our app gallery at http://lablz.com. You can also live test the app there.

Gene Vayngrib

6

Cad Ho wrote:

First of all, I agree (and PLEASE listen) - DONT go web based. these systems are unreliable, and you will REGRET your purchase decision after a while, and your database will be DEAD and you will need to remake it, and it will waste a LOT of time. These people are just $$$ greedy, and computer dumb.

There may be good reasons to not use a Web-based POS system, but these aren't them. There's no intrinsic reason that a system running off an in-store Web server should be slow or unreliable. And database corruption is a non-issue in my experience. If your DB gets "dead", then it's your developers who are the "computer dumb" ones

Miscellaneous comments:

* mySQL replication probably isn't a great way to share price info, but I could be wrong. * Definitely consider PostgreSQL. It's a much better, higher-performance DB than mySQL. * Despite what Fred said, Web apps can control printing, through a mix of JS and other clever tricks.

Best,

7

* mySQL replication probably isn't a great way to share price info, but I could be wrong. * Definitely consider PostgreSQL. It's a much better, higher-performance DB than mySQL.

I would add that take these advices from someone who cannot even spell MySQL properly with a huge grain of salt :slight_smile:

Regards, Rimantas

8

Rimantas Liubertas wrote:

* mySQL replication probably isn't a great way to share price info, but I could be wrong. * Definitely consider PostgreSQL. It's a much better, higher-performance DB than mySQL.

I would add that take these advices from someone who cannot even spell MySQL properly with a huge grain of salt :slight_smile:

When I actively worked with mySQL, the website specifically said that the correct spelling started with a lowercase "m".

Regards, Rimantas -- http://rimantas.com/

Best,

9

The <a href="http://www.visualretailplus.com">POS software system</a> we use works like a dream. You may want to look into it for yourself, you might be inspired with what you see.