POS Systems

From ADempiere
Revision as of 11:49, 26 December 2006 by Afalcone (Talk) (Functionality Required)

Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

WORK IN PROGRESS - Please don't modify - Thanks - Alejandro

Introduction

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.

Device 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 we have two alternatives:

  • The JavaPOS standard, which was developed to help integrate those devices into Java applications.
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.
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.


POS scenarios - Distributed environments & Data Replication

The most common scenario from the POS systems is such as:

POS Typical Configuration.png

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

POS Typical Configuration2.png

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.

Distributed Environments

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:

POS Comunication - General Diagram.png

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

To be continued ASAP...

The operation mode: A Closed Circle

TODO...

Functionality Required

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.
  • Barcode Support: the POS must enable to manage the most commons barcode systems, such as UPC, EAN-13, CODE-39, EAN-8, etc.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • Refunds: must be enable to manage refunds with authorization in order to improving margins, reducing fraud, and improving customer service.
  • 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.
  • 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.
  • Advanced Product/Customer search facilities: must have fast way to search, products and customers into the POS.
  • 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).

There are many others features could be added the previous list.