The main reason for this article is to provide some technical and functional points that POS systems generally require. Those issues could serve to improve the Adempiere POS functionality, or to possibly help to integrate some existing Open Source POS into ADempiere. Surely many of those points are matter of discussion, and could be added a lot more of them. Here are not considered legal aspects the different countries can have. This article just claims to be an introduction to the issue and should be seen as such. So, all contributions are welcome.
The POS Systems must be analyzed separately from other environments based on significant differences that the requirements for this type of systems have.
Point of Sale systems (POS) are used in restaurants, hotels, stadiums, casinos, as well as retail environments. Maybe the most traditional use is in the stores; there a checkout (a check-out counter) is the aisle where people place items they have choosed to purchase from a store, such as supermaket or departament store. The cashier rings up each item on the cash register and obtains the total. The items are placed in bags and the customer can take them after paying.
In those environments the time is gold! This is a critical factor.
A popular feature of POS today is that they also have systems to connect to alternative forms of payment such as merchant banks' credit card system.
In our ADempiere case, we intend to do more by integrating as part of the ERP and give visibilty and control over the Supply Chain Management.
A very common issue in the POS systems are the Peripherals. They are a special devices used to operate in this type of environments. There are several types of peripherals and any POS system must be enabled to manage all them.
Some of those devices are (the most commons):
- Receipt/Invoice Printer
- Bar Code Hardware
- Electronic Cash Drawer
- Customer pole Display
- Programmable keyboard
- Magnetic, Smart or Chip Card Readers
Here is one of the more complexes issues: the selection and programming to the physical POS devices, because of the significant disparity in features, functionality and interfaces from vendor to vendor (and sometimes even within devices from a same vendor).
Basically there are two ways to do it:
- Via direct access to the device, using a communication protocol (i.e. Epson Esc/POS, UTC Standard, DSP-500, etc).
- Problem: Hardware dependent
- Via some standard defined to interconnect devices (i.e. OPOS, JavaPOS, UnifiedPOS)
- Problem: Alternative implementations, when the specification is not sufficiently descriptive (you can find different implementation for the same device).
Currently, the biggest devices vendors have done implementations of those standards (Epson, IBM, Siemmens, Sun, NCR, etc.).
To improve the ADempiere POS functionality, and achieve the devices independence, there are two main alternatives:
- The JavaPOS standard, which was developed to help integrate those devices into Java applications.
- For details: The official JavaPOS site
- The UnifiedPOS standard, initiated by a consortium of retailers, and is led by the National Retail Federation. Beginning with release 1.5, both OPOS and JavaPOS have delegated ownership of language- and operating system-independent POS device interfaces to UnifiedPOS. OPOS then maps these interfaces to COM within Windows, and JavaPOS maps them to Java.
- For details: The official UnifiedPOS site
Note: Beginning with the 1.7 release, only the UnifiedPOS document is released. Separate OPOS and JavaPOS documents are no longer maintained.
Architectural Overview for the Standards
Both standards (JavaPOS and UnifiedPOS) defines a multi-layered architecture in which a POS Application interacts with the Physical or Logical Device through the standard Control layer.
The POS Application (or Application) is an Application that uses one or more UnifiedPOS/JavaPOS devices. UnifiedPOS/JavaPOS Devices are divided into categories called Device Categories, such as Cash Drawer and POS Printer. Each UnifiedPOS/JavaPOS Device is a combination of these components:
- Control for a device category. The Control class provides the interface between the Application and the device category. It contains no graphical component and is therefore invisible at runtime. The Control has been designed so that all implementations of a device category’s control will be compatible. Therefore, the Control can be developed independently of the Service for the same device category (they can even be developed by different companies).
- Service, which is a component called by the Control through the Service Interface. The Service is used by the Control to implement UnifiedPOS/JavaPOS-prescribed functionality for a Physical Device. It can also call special event methods provided by the Control to deliver events to the Application. A set of Service classes can be implemented to support Physical Devices with multiple Device Categories.
The Application manipulates the Physical Device (the hardware unit or peripheral) by calling the platform specific APIs which conform to the UnifiedPOS/JavaPOS standard. Some Physical Devices support more than one device category. For example, some POS Printers include a Cash Drawer kickout, and some Bar Code Scanners include an integrated Scale. However with UnifiedPOS/JavaPOS, an application treats each of these device categories as if it were an independent Physical Device. The UnifiedPOS Device standard developer is responsible for presenting the peripheral in this way.
Note: Occasionally, a Device may be implemented in software with no userexposed hardware, in which case it is called a Logical Device.
POS Configurations - Distributed environments & Data Replication
The Store Configuration
One of the most important requests to the POS systems, is to guarantee the high availability. You must operate without fails all the time.
The most common environment to the POS systems is when you have more of one POS into the store, such as:
The main issue: the POS must be enabled to operate independently, without requiring a connection to the central site or local server. Maybe the better way to achieve it, is to have a dual configuration into the POS; this mean, the POS must have a Local DB copy into the POS, in addition to the server DB.
In normal situation, the POS operate with the DB from the Store, but if for any reason it’s impossible connect to DB, then the POS must switch to the Local DB automatically. This local DB must be synchronized with the Store DB, and it contain a copy of the information from the main (products, customers, credit cards bulletins, etc.).
For that, you need a replication agent. You can use a DB replication, provided from the proper DB, or you can develop your replication agent. For the second option you will have a program running on background into each POS, who is looking for changes into the main DB and copy them into the local DB.
While the main DB connection is broken, the transactions are saved into the local DB, so the POS can continue operating in standalone mode (off-line) without problems.
When the communication is established again, the POS is switched to On-Line – automatically - and all the transactions are saved in the main DB. Now, all the transactions saved into the local DB will be sended to the main DB automatically, via the replication agent.
In most cases, the companies have more of one store. In this case the schemma showed before, can be replicated to all stores.
But now, you will have a additional communication case: Stores <-> Headquarter. Here you can have something such as:
Again, you will need replicate the information, but now between the Stores and Headquarter. The idea is the same, and here you can have more of one alternatives to synchronize the datas, depending of your communication schema:
- Synchronic connection: in mode on-line, such as ADSL, Point To Point lines, VPN, etc.
- Asynchronic connection: such as via email or via magnetic devices.
Now you must have in mind some criticals points such as:
- How long a remote site can remain unsynchronized ? The application must control it.
- Data updated at a remote site is not updated at any other sites (critical example: customer credit).
- Prevention: Conflict with data updated from different remotes sites.
Maybe one of the most difficult issues is the synchronization when the remotes sites can update the master tables (customers, products, etc.). In most systems, the master tables update are limited to the Headquarters (the stores are not permited update this tables, to prevent conflicts). Here the point is: What happen with the new customers? Surely you want to add the new customer in the Store, so you must prevent the duplicate ID for the customer table (because more of one Store can add customers). BTW, could be to assign a ID’s range for each Store, avoiding thus the same ID to different customers (just a suggestion).
The operation mode: A Closed Circle
Generally a Sales POS operation can be looked as a closed circle. The operations a cashier do generally are:
In the figure you can see the typical operation mode for a POS process. There are 2 basic operations:
- Sales Process: the operation for the sale.
- Administrative task, such as X/Z out, Correct payments entered (i.e. change from Cash to Credit Card), cash out from the cash drawer, etc.
The Sales process can be showed as:
When you ended a document, the system is ready to open a new one. This is a Closed circle mode.
The Sales Rep. Enter, showed in the first image, can be present or not depending from the operation mode (in supermarket environment usually there are not sales rep).
In some environments, instead of document print when you close it, the print is performed at the same time that the items are entered (when you input a item, it is printed), so you win time when the customer bring many items.
A very important requirement into the POS environments is to have 2 roles for the users:
- Cashier: the user perform the sale and collect the payment.
- Supervisor: the user authorize some operations, such as items cancel, change payment registered, cash out, etc.
Other point to be careful: It is highly recommendable that when the user power-on the PC, the POS system be loaded automatically. When the user leaves (logoff from the POS) the PC is power-off. The user shouldn't be enabled to switch tasks, neither play with the desktop (set the screensaver as example). The POS behavior must be equal to a Cash Register.
Some of the most usefuls requirement in POS systems are:
- Point of Sale Summary Reports (X/Z Out): The daily X/Z Out Report provides a summary of all the day's activity at a POS station, or for a particular clerk, or for the whole store. It totals up sales, returns, tax, shipping, and sums paid in and paid out for each tender and each credit card. It lists and totals all sums in or out for special transactions, such as gift certificates. It totals all line item discounts (and can have the reasons they were given). This report reconciles the drawer easily and swiftly, and its exact breakdowns can help isolate procedural errors for correction.
Functionality at 80% completed in Posterita.
- Barcode Support: the POS must enable to manage the most commons barcode systems, such as UPC, EAN-13, CODE-39, EAN-8, etc.
Barcode Support 100% Completed in Posterita.
- Adding or Editing Customers on the Fly: When creating an invoice for a new customer, you can click on the new customer button to create the customer right then and there. The POS system must have an advanced customer search facilities. In addition, you can edit the existing customer if you need to update the address or phone number, etc.
100% Completed in Posterita.
- Audit Trails: If you make a mistake, you can easily edit and correct the invoices, payments, bills or checks. To protect the store, all transactions are posted to a secure audit trail (with some information like date, time, terminal number, user, invoice number, customer name and the amount for each transaction). This gives you both the ability to fix mistakes and help prevent fraud.
75% Completed in Posterita.
- Integrated Credit Card Processing: Supports to authorization and processing of credit cards and debit cards. Credit cards are readed in POS (vía MSR) and the authorization information prints on the customer receipt, as does the signature line.
Work in Progress.
- Promotions: Module for many promotion systems including loyalty programs, mix 'n' match, 3 for 2, and seasonal sales. This promotions will be managed centrally (configured at Central Office and replicated to all stores automatically).
Not implemented in Posterita.
- Multi-level permission based security: some operations, such as anule a item, change a tender registered, etc. must be authorized by a user with mayor privileges, instead as cashier. All those authorizations must be logged in the audit trail.
70% Completed in Posterita.
- Refunds: must be enable to manage refunds with authorization in order to improving margins, reducing fraud, and improving customer service.
100% Completed in Posterita.
- Transaction suspension and recall: Is common when you are doing a invoice, by some issue, delay the closing of the sale. In these cases, the POS should permit to leave the invoice in suspense, to emit other and then, when it be required, to recover the invoice in wait to complete it.
100% Completed in Posterita.
- Configurable GUI in Standard, Touch Screen: for some cases, generally the stores with few items to sale, the best way to input the items is via a touch screen. To do it the POS should permit to configure the items in the screen.
50% Completed in Posterita. Touchscreen is supported, but configuration is not done.
- Advanced Product/Customer search facilities: must have fast way to search, products and customers into the POS.
100% Completed in Posterita.
- Mixing payments: support to multiple forms of payment; any mix of credit card, checks, store credits or what have you can be applied to a purchase. (i.e. Cash & Credit Card & Check to the same ticket).
100% Completed in Posterita.
There are many others features could be added the previous list.
ADempiere POS Road Map
- There is already an inherited from Compiere half completed POS java client
- OpenXpertya completed that and offered to ADempiere Bazaar
- Carlos Ruiz started adaptation into ADempiere
- Hengsin completed the adaptation and tests - assisted by Joseph Brower as spanish translator
- Due for release either 3.1.5 or 3.2
- Posterita Web UI
- Contributed by posterita, Mauritius - headed by Alexander and Frederick Tsang
- Includes multiple webstores interface
- SaaS ready
- Undergoing initiation in Bazaar
- Due probably in 3.3