| How do POS systems communicate?
Data communications are critical to the function of any multi store retail solution. There are a number of methods employed by POS systems to communicate data from stores to other stores or the back office. In addition to this some systems require small networks in the stores themselves as part of the data communications structure.
Polling – Type 1 (modem based)
Historically (before the internet) most pos solutions relied on polling. This is a method where at the end of each day all the sales for the day were “batched” together and sent in a file to the back office. Once all the files had been received the back office then processed all of the files and created a result file for transfer back to the stores. At the start of each day the stores would then process these files and then be ready for the next days operation.
Since the internet was not available this transfer was performed using modem dial up. The back office would ring each store in turn at a specified time and ask for the end of day file. After processing it would ring the store again and send it the new file for the day.
You will find that this method is still widely used today by many of the DOS based systems.
Problems: There are very high costs involved in the long distance phone calls. In order to poll a moderate to large number of stores companies have to create a “modem bank” and contact multiple stores at once in order to transfer all of the data in a short space of time.
If a store is not contactable, either because the PC is off or the modem is experiencing problems then the store is missed from the update and data synchronisation becomes an issue.
Stores usually cannot perform any activity while the transactions are being batched, or while the start of day file is being processed. This means store staff must remain in the store longer.
Polling – Type 2 (internet based)
With the widespread availability of the internet many POS solution providers have removed the costs associated with modems and long distance STD phone calls and have moved their file transfer mechanisms to a method known as FTP. This still involves the batching of transactions and however instead of waiting for modems to dial the transaction file is sent to a holding location (an FTP server). At a specific time the back office processes the files from the FTP site and places start of day files back on the FTP site. At the start of the next day the store must retrieve the file from the FTP site and processes it before being ready for the next days operation.
Problems: Stores may be off and could fail to transfer the daily file. Alternatively they may transfer the file, but it may be late and could miss the daily update. This could easily cause data loss in the back office. The down time associated with batching transactions means stores still have a “non-operational” period.
Polling – Type 3 (email)
This version of polling works in much the same way as the FTP method, however all files are transferred via the email protocols instead of FTP. The limitations and drawbacks are the same with the addition of extra work required to get the transfer files out of the emails and make them available for the back office or store to process. Automatic email processing has potential problems in terms of security and email spam.
Notes on Polling: Some vendors reduce the non-operational period of the stores by batching transactions as the day progresses, however the start of day inactivity is still an issue. Other vendors require every store to have a separate machine in the back room that performs the batching and processing of data (a store server). This is an added cost and should be avoided where possible.
To avoid the problems with polling many vendors are now using the power of the internet to provide direct update to the back office through a permanent internet connection. Each time a transaction is made the details are sent to the back office and updated immediately. This gives the back office staff live up to the minute information on what is happening in store. It also provides stores with the ability to query stock levels in other stores and to have accurate information as a result.
This is a great method of communication as long as the network connections are on and all systems are functioning as they should.
Problems: The cost of these solutions is definitely higher both in terms of the software and also the hardware and networking involved. Depending on how the software is written there are a number of other potential problems.
Firstly, when a connection becomes unavailable, or the back office server goes down the stores may not be able to process anything at all. This is typically the case with some of the newer “browser based” solutions.
Secondly, if a connection is lost in the middle of a transaction the transaction may be lost. The sale could still be completed in the store but the back office may never be aware of it.
Note: The connection problems can be overcome by having a special server in store (separate to the PC’s used for the point of sale) that handles the communications however this increases the cost of the solution.
Store and Forward
This solution is a mix of the best parts of both the online model and the polling model. It still uses the flexibility and power of the internet for communications but instead of requiring a permanent connection and a special in store communications server the store and forward model allows stores to be either online or offline without any disruption to service at all.
Each transaction in the store is treated as a message and queued on the PC ready to be sent to the back office. If the store is offline the message remains in the queue until an internet connection becomes available.
Once a connection is made all of the queued messages are transferred to the back office and processed immediately by the back office.
In a similar manner all messages from the back office to the stores are queued. When the store comes online the messages are transferred.
This provides you with the greatest flexibility in terms of deployment of your system. You can choose which stores to make permanently connected and which to use in dialup mode.
You do not lose time waiting for batch files to be processed and all data is as up to date as the last time the store connected.
The cost of a store and forward solution can be affected by the store and forward mechanism involved.
Note: Arel Retail uses the bChat B2B framework for its store and forward mechanism. Due to the low cost of this product, Arel Retail is able to offer this functionality at no extra cost to the customer.