UnifiedPOS FAQ

A: Because a POS system is typically constructed by combining three very distinct types of product offerings, each of which may be supplied from a different set of competing vendors:

Without POS standards the retailer is left with the unenviable choice of buying all three components as a unified package from the same vendor, or of deploying a POS application which has been hard-wired to support a specific POS Terminal and/or a set of associated peripherals. Requiring selected POS vendor products to be in conformance with appropriate industry standards allows the retailer to mix and match components when constructing a POS system, thereby removing the “single vendor lock” that has proven so costly in the past.

In other words, POS standards are all about giving the retailer a choice - the choice to select best of breed components, the choice to replace a vendor whose product offerings haven’t kept pace with evolving technology or one whose prices are no longer competitive.

This is why the development of all widely-accepted POS standards has been driven primarily by retailers, and why ensuring conformance to these standards is in the best interests of every retailer.

A: The UnifiedPOS standard was created under the auspices of the Association for Retail Standards (ARTS) to define a common architecture for describing POS peripherals. The latest version (V1.12) defines the model for accessing and controlling 36 distinct types of retail peripherals by specifying a unique set of properties, methods and events for each. These models are documented using the widely accepted Unified Modeling Language (UML), and provide:

The end result for the retailer who selects UnifiedPOS compliant device peripherals is that the POS application can be written independently of any peripheral vendor or model number. Upgrading or replacing the peripherals no longer impacts the application … a major advantage.

A: The architectural model provided by UnifiedPOS is extremely useful, but it only goes so far. Because the model is platform-neutral (that is, is independent of both the language the POS software is written in, and the operating system of the POS terminal on which it executes) it must be “mapped” to the leading POS platforms in a standardized way, before these platforms can be said to fully support UnifiedPOS.

OPOS: Provides the UnifiedPOS mapping for a POS application running on the Windows operating system.

JavaPOS: Provides the UnifiedPOS mapping for a Java Language POS application running on any operating system.

POS for .NET: Provides a UnifiedPOS mapping for a Microsoft .NET POS application running on the Windows operating system with the POS for .NET class libraries.

The OPOS mapping was first created in 1995. It is widely supported by device vendors, POS terminal manufacturers and POS applications, and has been deployed extensively within the retail industry.

It allows applications written in one of a wide variety of languages -- including C, C++, Basic, C# and many others -- to utilize any device, which has an OPOS driver, as long as the operating system running on the POS terminal is Windows. Thus OPOS decouples the retail application from the devices.

The JavaPOS mapping's first version was completed in 1996. It is supported by a growing number of device vendors, POS Terminal manufacturers and POS applications, and several major deployments including Home Depot, Apple, Lens Crafters and Men’s Wearhouse have already occurred. Java applications may utilize any devices that have a JavaPOS driver, irrespective of the operating system (such as Linux or Windows), thus decoupling it from both the devices and the POS terminal. Also, a device manufacturer often can write a Java device driver once for various operating systems, if the device uses a supported communication interface; otherwise an operating system dependent layer (which is typically quite small) can be added to perform this interfacing.

The POS for .NET mapping was first released in 2006, and requires the Microsoft POS for .NET class library. For applications using .NET, its API set is simple and consistent, and easier to use than OPOS within .NET. Also, base classes simplify the development of POS for .NET drivers.

The availability of UnifiedPOS mappings for three leading platforms in the computing industry today -- Windows, Java, and .NET -- makes its POS architecture the natural choice for retailers developing or upgrading their POS systems.

A: This ability to deploy the UnifiedPOS architecture on multiple operating systems offers retailers some definite advantages, as it means that every component used in a UnifiedPOS solution is now replaceable.

Replaceability provides choice, and choice is important in protecting POS investment. POS is the highest cost component of a retailer’s IT investment, including hardware, software and retraining of all store associates. Unlike the normal two or three year desktop PC replacement, a seven-year upgrade cycle is not untypical for POS terminal deployments. However, retailers need to continually add new functionality to the POS sales floor application to remain competitive in customer service offerings such as cross-channel sales, loyalty, stored value, and debit cards. Application changes may require hardware changes in peripherals or terminals. Bringing the benefits of the Internet to store operations requires changing the operating system from DOS to a next-generation OS. A UnifiedPOS compliant application allows retailers to change either of the three principal POS components, application, hardware or operating systems in phases, reducing capital investment and perhaps more importantly preserving the base software to dramatically reduce the cost and customer disruption of associate retraining.

A: POS is more than an application, hardware and operating system, it is part of the network infrastructure. The network is the connector to other processors: back office, central, outside agents (banks, registries, etc.) that can be persistent, dial-up, or Internet. The more open and standard the network infrastructure is the easier it is to provide the customer with a wider range of services, and to capture more POS data to be integrated with other business critical applications. If your current POS will not support Internet connectivity you should seriously consider replacement.

With an open POS that can directly connect to the Internet, true multi-channel retailing is easily accomplished. One system, providing a consistent view of your business, can support the customer whether in the store, on the web or at a kiosk. Further the customer is afforded many new services at any of these locations. These include, stored value cards, registries that extend beyond one retailer, purchases on the web that can be picked up immediately in the closest store, cross-store inventory lookup, analysis of similar products from multiple vendors for “right” selections, review of promotions to encourage additional purchases, etc. Many of these customer services increase sales and reduce retailer cost of services. This is a true win-win.

A: Retail is a “real time” enterprise. It is rare that customers make appointments with retailers…they just show up. It is rare that a customer would expect to hear from a retail clerk “I’m busy now, could you come back some other time?” Retail is RIGHT NOW!!

Can you do business without having your store POS systems connected real time to corporate and third party business partner (network centric)? Absolutely!! And you might not even feel the disadvantage. In 2002 retailers can operate quite successfully without being in a real time environment. However the future is coming to a store near you…and sooner than you think.

In the future, non-networked retailers will pay more for almost everything than their network-centric competitors will. They will be forced to carry larger inventories because they don’t have up to the minute information about how to allocate this shipment of merchandise. They will not have the capability to participate in exchange supply purchases.

Real time network-centric retailers utilizing the Internet or private networks have the opportunity to provide the customer service functions discussed in the previous questions. As networks both public and private become more reliable retailers can reduce the expense of purchase and maintenance of in store processors. Some are already doing so.

Belt

Electronic Value Reader/Writer

Pin Pad

Bill Acceptor

Fiscal Printer

Point Card Reader/Writer

Bill Dispenser

Gate

POS Keyboard

Biometrics

Hard Totals

POS Power

Bump Bar

Image Scanner

POS Printer

Cash Changer

Item Dispenser

Remote Order Display

Cash Drawer

Keylock

RFID Scanner

CAT

Lights

Scale

Check Scanner

Line Display

Scanner

Coin Acceptor

MagStripe Reader

Signature Capture

Coin Dispenser

MICR

Smart Card Reader/Writer

Electronic Journal

Motion Sensor

Tone Indicator

	POS device manufacturers with the interface architecture they must support in their device drivers (the software which actually communicates with the device), and
	POS application developers with the interface architecture they must use to access and control each type of device (scanner, fiscal printer, scale, cash drawer, etc.). This interface remains unchanged despite any variations in the particular device configurations of the POS terminals where the application may be deployed.