Spa & Sauna POS

  

Table of Contents

By Scott Seong

1. Introduction.

The popular Korean style Spa & Sauna facilities (pronounces "jjim-jil-bang" or "bul-han-jung-mak") debuted in the United States in 2006. This traditional Korean Spa & Sauna is not only a place to enjoy Spa and Sauna, but also a place where your entire family can camp out on a weekend utilizing multi-leisure health and beauty facilities including Internet/PC room, movie theater, barber/beauty salon, public bath and a restaurant.

With locations in New Jersey, Georgia, Virginia, Nevada, California and Illinois to name a few, Korean style Spa and Sauna is becoming popular in the USA. This unique business model requires a specialized touch POS system that can manage operation and management of Spa & Sauna business. No existing POS systems designed for Restaurant, Retail, or Salon/Spa POS systems meet requirements of the Korean Spa & Sauna business.

In late 2008, King Spa & Sauna started construction in Niles Illinois with a plan to begin its operation in mid 2009. King Spa & Sauna turned to TouchPOS.net (a subsidiary of Broadband Media, Inc.) to custom design a POS system that can manage their Spa & Sauna business. This article explains how we went about designing and implementing a Spa & Sauna Touch POS system from the ground up.

2. Platform & Architecture

When King Spa & Sauna asked us to deploy a Touch POS system, we looked at a number of existing POS systems both commercial and Open Source ("Free") to customize the solution for them. After gathering system requirements, evaluating commercial POS systems, and performing cost analysis; we couldn't find a single solution that met King's requirements out of the box. We came to the conclusion that the best plan was to develop custom software for this customer. Building a POS system from scratch is no small task, and developing a software for a single enterprise "generally" is not justified in terms of cost and effectiveness.

Looking at the requirements, developing software from scratch was not an option. It just cost us too much to develop and test the solution for a single customer. We've searched the Internet and found a few open source POS products that can be used to develop the final product. The biggest hurdle was deciding on the platform and the "open source" software. Searching for the "Open Source POS", we found about a dozen software frameworks, mostly developed in PHP and Java on Linux and Windows platforms. As expected, we weren't able to find any .NET POS system that are "Free" and "Open Source".

We preferred a web-based POS system that has the capability to operate various serial and USB peripherals. We also needed a POS system that has the restaurant mode of operation, so that multiple "tickets" can be opened simultaneously. None of the web-based POS system had the peripheral interfaces AND restaurant mode of operation, so we had to choose a client/server architecture. The strong contenders included: Posterita (Web Based/Java-Perl), IS4C (Web Based/PHP), Freemercator (Client/Server, Java) and Openbravo POS (Client/Server, Java). Of those listed, we chose the Openbravo POS system as it requires minimum coding changes to develop the solution we desire. The bullets below describe our analysis on each of the products considered.

• Posterita: This is the product we considered very seriously as it is web-based, and well accepted by the Internet community. This product is developed in Java/Perl and utilizes Postgres database. The user interface is very clean, and has the capability to manage serial and USB peripherals such as MSR, Thermal Printers and Pole display; and has pretty good documentation. This POS system is designed for retail purpose only, so multiple tickets cannot be opened simultaneously. Adding "restaurant" functionality is considered a major rewrite of the software, so we did not choose this product as the base platform. Otherwise, this product would have made it to the final.
• IS4C: This is a very interesting product, to which we gave a lot of attention as it is designed in PHP and it is web-based. The peripheral control is mostly done by the "Linux" daemons written is C and Perl, and uses the server and lane to mimic client/server functionality. The documentation was very poor, and installation script was very specific to a couple of Linux variants. We didn't like the idea of having each lane operating from it's own database and synchronizing from the server instead of working from the master database. Also, this software was written for retail business so it didn't meet the "restaurant" requirements.
• Freemercator: This product is designed on client/server architecture, and has very intuitive user interface. The GUI is very basic but very intuitive. We really liked the GUI (the big buttons are great!) which is well designed and ideal for touch screen use. The only problem with this software is that it's old (written in 2003), and there is no activity in the project. The code is written in Java 1.4, which is no longer supported. We were able to upgrade the software to Java 1.6, but with no documentation reverse engineering this product would have rquired a significant amount of development time.
• Openbravo POS: Of those listed, Openbravo POS meets the intended system requirements very closely. It has very nice GUI, but buttons are too small to fully utilize "touch" POS functionality. It supports "restaurant" mode, and supports MySQL database which is a big plus. It has enough documentation to understand and customize the product, and it's well accepted by the Internet community and large installed base. As it is client/server software, adding additional peripheral support such as the serial "tag" reader (widely used by Spa & Sauna facilities) is not a problem.

3. Openbravo POS

Openbravo POS is a desktop application developed entirely in Java programming language. Since it is a desktop application (as opposed to a web application), dealing with the POS hardware such as receipt printers, customer displays, and card reader is a lot easier to manage. The GUI is designed for use in touch screen environments, but the buttons aren't big enough as compare to other touch screen POS systems (IMO). Regardless, the Openbravo POS is the closest one we have found, so the development will branch from the core Openbravo POS (v2.2) platform.

The 36,000 square foot King Spa & Sauna facility will require approximately 10-11 stations: (3) front desk stations, (1) female bath, (1) male bath, (1) food court, (1) heat bath, (1) ground foot pressure room, (1) ground pressure room, (1) natural ore room, and optionally (1) back office station. Each front desk station will have a magnetic card reader (for membership card and credit card processing) and a receipt printer at a minimum; and one of three front desk station will control a webcam that will take the pictures of the members when a customer signs up for a monthly, quarterly, semi-annual or annual membership. The bath, pressure room and massage room stations will not have any peripherals attached to it. The food court will have a dot-matrix printer, which will print orders in the kitchen. Every station except for the bath, pressure and massage rooms will have a tag reader which is connected via a serial port. A tag is a "wrist watch" like device that will allow customers to buy products and services inside the Spa & Sauna facility as well as using it to open the locker.

Openbravo POS does not support serial tag reader out-of-the-box, so we had to write custom code to support this device. Touch screen and magnetic card reader emulate mouse and keyboard by the device driver software, so there is no special programming needed to support these devices. Although both Linux and Windows operating system can handle Openbravo POS application, we have chosen to deploy the application in the Windows XP platform as many operators are already familiar with the Windows OS. From the list of databases supported (Apache Derby, MySQL, PostgresSQL, Oracle and HSQLDB), we've chosen to use MySQL database as it's one of the most popular open source database used in the market.

Each and every Openbravo POS stations will operate independently of each other, except for the shared database. The station that stores the database becomes a server, and remaining stations will become clients (although they are technically peer stations). Every station will run same copy of Openbravo POS software. Credit card processing will be performed on front desk stations (ones with MSR) via Authorize.net gateway service. Since all credit card processing will be done via swiping the physical card, it is important to ensure that we use the Authorize.net gateway API that uses the "Card Present" application and lower the per-transaction fee (i.e. retail as opposed to MOTO service). For information on Card Present implementation, please read Card Present Transactions Implementation Guide

4. Development Environment

The development environment will be setup as close to the production environment as possible. The application will be developed on Windows XP with Java 1.6 SDK, and Netbean IDE. Netbean will allow us to edit swing components visually, whereas the more popular Eclipse will not. Setting up the development environment is pretty easy to setup by following the Openbravo POS Developer Guide documentation. For general Openbravo POS documentation, please visit Openbravo Wiki and click on the POS tab.

Openbravo uses RXTX API to implement serial port functionality on Microsoft Windows. Due to change in Microsoft kernel drivers for serial and parallel port support, Sun dropped support for javacomm package on Microsoft platform. In order to read characters from a serial device within Openbravo, we need to place the rxtxSerial.dll file bundled with the Openbravo POS in the Java directory where java.exe resides. Also, RXTXcomm.jar file must be within the classpath in order to resolve necessary library calls. For information on serial port support, please read Javacomm alternative thread on forums.sun.com.

The production machines ("stations") will only need the Java 1.6 JRE to run Openbravo application, and hence Java SDK will not be installed. We still have to copy rxtxSerial.dll file in the %JAVA_HOME%/bin folder to utilize the serial port functionality on the production machines.

5. Conclusion

We have yet to develop the application, and complete the proejct. Our estimate for completing the project is approximately 3 months, from initial assessments to final testing and deployments. It may take another month to fix all software bugs, and complete the documentation. Our goal is to write a series of articles to document our development process, and provide this work as a case study to the Openbravo community.