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

On 25 Feb 2008, at 17:22, Scott Ward wrote:

set

  • The item and sub-menu buttons would need to be configurable by
    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.

On 25 Feb 2008, at 18:22, Scott Ward wrote:

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

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.

second, DONT go for a linear system. Go for a graphical oriented system,
NOT intuit quickbook, microsoft pos or myob pos.

so your choices are Radiant Systems Aloha, or ChikPOS. The price of
ChikPOS means the Aloha system simply SUCKS (it’s double the price, and
half the features!)

ChikPOS has been fantastic. I’ve had NO problems with it whatsoever.
It’s a Jeremy Shum Invent so its a quality Aussie product too - helping
the economy. The features are also endless… multi-language support,
managerial decision making reports, not locked to hardware, fully
multi-touch (like iphone), external monitor support, xbrl compliant,
auto-generation of online sh0p, can advertise “related products”,
corporate chat support, show time/date/news on external screen… it’s
just top stuff. AND it’s Windows 7 compatible!

Peter De Berdt wrote:

On 25 Feb 2008, at 18:22, Scott Ward wrote:

  • 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

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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

  • 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

http://rimantas.com/

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

The POS software system we
use works like a dream. You may want to look into it for yourself, you
might be inspired with what you see.

Rimantas L. 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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs