Rails based Point of Sale?

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

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.

- 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 http://www.marketcircle.com/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

- 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.

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

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,

* 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

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,

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.