The ABCs of POS

What point-of-sale (POS) system does your co-op use, and how well does it work for you?” “Should we be recording cost of product in our POS system?” “How do you create a sale sign from your POS system?”

At Sacramento Natural Foods Co-op (SNFC), I receive such inquiries on occasion from other co-op data technicians who are seeking advice about managing their POS systems. Although I’m no expert in this technology, I do have a good sense of how our Scanmaster/BR-data system works, and I don’t hesitate to call our service technician when that system doesn’t work the way I think it should. As a manager who appreciates accounting and other data as decision-making tools, I want my POS system to function effectively for my co-op.

I am also well aware that most co-op managers don’t really understand how their POS systems work, nor the extent of daily processing functions needed to keep those systems functioning properly, the exacting detail they require and provide, or even what work their POS systems could do for their organization. Co-ops invest tens of thousands of dollars in POS technology and still struggle to get these systems to do the work they need them to do. 

In this article, I want to share a few useful concepts for co-op managers and data technicians that may help them to get more from their POS system software and that may provide some insights about assessing software capabilities when your co-op considers buying a new POS system. 

Conceptualize POS tools correctly 

POS system technology extends beyond cash registers. It is really a collection of electronic hardware devices and software programs that, if properly configured and managed, should carry out most of the detailed, drudgery paperwork retailers hate. Optical bar-code scanning technology not only speeds and simplifies the checkout process for customers and cashiers, it also provides exacting transaction detail on demand. Likewise, hand-held optical scanners make the same exacting detail available for all back-room recording processes such as purchasing, receiving, and inventory valuation—all with greater accuracy, efficiency, and control. 

POS software accomplishes this work through the use of several different “modules” or software applications. A front-end software module will record products sold at the register, the customer associated with the transaction, and the cashier who completed it. A frequent- or loyal-shopper module links customers to sales transactions, aggregates purchase history, and links to products purchased. Back-office modules link product costs to vendors and associated vendor costs for purchasing, receiving, and inventory valuations. 

For these reasons, POS systems today are better conceptualized as the retailer’s primary business information and transaction recording tool. It takes a lot of dedicated effort, however, to get them to function properly and to do the work you need them to do.  

Assessing POS software developers 

When considering investments in POS technology, co-op managers will be wise to consider the reputation and receptiveness of the POS software developer. The software developer is the company name behind your POS system, such as NCR, StoreNext, or ECRS.

POS developers write software on top of the underlying database engine. In so doing, the developer defines the tables and field characteristics that will house the retailer’s data records. POS software developers also write software scripts to do work they think a retailer needs. These scripts are often generalized for, and influenced by, mass retailers—especially with large developers like NCR, IBM, or Fujitsu. Their conceptions of retailing do not always meet the needs of grocery stores, let alone co-op grocery stores.

Less risk is often associated with big-name developers since they are well-established and well-financed. They are likely to be around for several years. However, these systems also tend to be more expensive and more rigid. Smaller developers, such as ECRS or LOC, may introduce more risk into your investment calculations if you intend to keep your system for 10 or 20 years, simply because they haven’t been around as long and have less financing behind them. On the other hand, smaller POS developers look for ways to distinguish themselves from the big-name developers and are potentially more willing to listen to retailer  needs in niche markets. Independent grocers and co-ops are likely to have less clout when it comes to asking big-name POS developers to rewrite software script or to add fields to their tables.  

Database engines 

POS software modules are built upon large and powerful data storage and retrieval platforms, referred to as “database engines.” These platforms allow POS software developers to write business applications through the standard structures and capabilities of the database engine. 

The database engines, or relational database platforms, provide multiple distinct tables that can hold thousands of individual records. These platforms afford developers tremendous flexibility and can be programmed to do almost anything a business enterprise may need. POS system developers make these tables available to the user through different software modules. There are tables for products, customers, vendors, employees, and many others. 

Each table contains several different “fields” or data segments. Each field houses like kinds of information, applicable to all records in a given class. A product table, for example, has fields of information for UPC number, brand, size, and price; while a customer table holds fields of information relevant to customers, such as name, address, and phone number. Fields may be defined by length and type. There are text fields, numeric fields, logical fields, algebraic fields, date fields, and others. Each individual record in a product database is likely to have as many as three dozen fields of data associated with it. Keeping each of these fields in all records current is the major challenge of database administrators. 

The underlying database engine can also cross-reference information within different tables. For instance, a vendor code field in a specific product record can be linked to the vendor code in the vendor table. This allows the user to link information about a product with information about the vendor who supplies the product, such as the vendor’s minimum order, discounts, shipping charges, and payment terms. In order for these links to work properly, however, data in a given field must be exact. Incorrect data entered into a field may produce incorrect information links or no linked information at all.

Finally, the underlying relational database engine can communicate data to and from other external devices or software programs through specific communication protocols. This allows users to send information about sales to software that produces sale signs, or current prices to service department scales that print bar codes for weighted items, or to transmit scanned product orders to vendors.  

Activity logs

Database developers utilize this cross-reference capability of database engines to produce transaction or activity logs. A transaction log at the front end, for instance, allows a particular transaction to be accessed in multiple ways. The transaction number will take you right to the specific transaction. However, in lieu of the transaction number, you can still find the particular transaction through a cashier number, a customer number, or a product number. A receiving activity log links key fields of information about products received with known information about vendors such as shipping costs, discounts, and other factors that may affect the cost of product.    

Accessing all that information 

Even though the underlying database engine affords programmers incredible power to perform searches, conduct work, record activities, and communicate with other devices or software, your POS software developer may not provide all of that power and flexibility to the user. This shortfall manifests in two basic forms: reporting and communications.

POS software developers often provide “canned” or prescribed reports that can be viewed on the computer monitor or sent to a printer. These reports often look like they were written for the Geek Squad rather than the inquiring retailer. Rather than having one succinct closing report, users will likely have to print out several different reports to gather the specific summary information they need to post to their general ledger or subsidiary journals. Reports may give UPC number and short description but leave out a critical field such as brand.  

Secondly, POS developers often lock up the underlying communication capabilities of the database engine so that if you want different devices to talk to each other, you have to buy hardware components designed, licensed, or authorized by the developer. This can be costly when there are more-affordable or better designed devices available. 

Perhaps the most aggravating problem is when POS developers turn off the basic import/export functionality of the underlying database engine. This forces the user to work within the developer’s self-contained software environment and work within the software’s limitations. In these instances, I recommend asking the software vendor to provide a routine import-export solution. Whatever reports or communication needs you may have today, your needs likely will change in the future. Having routine import-export solutions for as many fields of information as possible provides the means to move information to where it is needed and allows the user to design reports that are helpful for developing insights about business performance. 

Accounting concerns

POS systems are not accounting systems, but they should provide the summaries you need for posting sales-related revenue to your cash receipts journal or general ledger. They are also very useful for researching transaction detail when problems occur with daily closings. Properly maintained department fields in the product records should allow accurate department sales recording at the front end and provide correct department allocations at the back end—such as when valuing inventories with handheld scanners—since both functions draw from the same data set. POS systems should work as useful tools for all routine merchandise accounting functions.  

Not all POS systems are well geared to work-order accounting, however. These accounting processes are typically used by wholesale distributors: an order is placed, packing slips or work orders are generated, and delivery occurs at a future point in time. Sales order accounting makes extensive use of accounts receivable and customer balances. Some co-ops may desire sales work order accounting functions in their POS system, particularly if the co-op processes cases or special orders for customers or provides other such wholesaler services.  

Manufacturing accounting methodologies affect food service departments. Manufacturing accounting treats inventory in stages of raw materials, works in progress, and finished goods. Inventory valuations in food service differ from the rest of your retail and are probably better handled by your food service software. The ability to transport ingredient cost and pricing information for food service products from your food service software to your POS system, however, is a valid concern and should be examined when you evaluate a POS system.  

Utilize your vendor 

Asking discerning questions and articulating your needs yields better results when dealing with POS vendors. Understanding the complete POS system concept and database terminology will aid you in getting what you need from your software vendor. Knowing your software developer’s reputation and market position will aid you in evaluating the company’s receptiveness to new ideas. Understanding accounting methodologies will put you in a better position to evaluate how you handle different kinds of problems, such as costs and valuations, within your existing system and any competing system you may consider in the future.

I always recommend informing your POS vendor when you don’t like something that you see. Let them know of any missing fields within tables, as well as fields that are not of the right length or type. In order to be effective in your dealings with POS vendors, you must define the tables, fields, and functions you need to make the software work for you. 

ECRS Catapult released a version 10 years ago adding user-definable fields. I had suggested this idea to my vendor before I bought it for another co-op because the product table didn’t have a field for product category. In the last few years, I’ve watched BR-data add logical operands to their search parameters, increase data field import/export functionality, and user-definable fields. I am not saying these program enhancements came about because of my requests, but if you don’t make your vendor aware of your needs, don’t expect them to communicate with the developer to fix those parts of the program that don’t work for you.  

Appeal for greater dialogue

I cannot think of a more costly, complex, and strategically important investment decision that co-op managers make than choosing their POS systems. POS system decisions impact every division in an organization including accounting, marketing, IT, and human resources, as well as every departmental operation. There is not a customer or vendor transaction that it can’t record. There is not a price, product, or customer it can’t recognize or recall in exact detail. There is not an item or transaction discount, refund, or a selling policy decision your co-op makes that is not configured and reflected through your POS system. 

Given POS systems’ cost, complexity, and importance, this technology should really be considered a retailer’s primary business information-retrieval and operational tool. Food co-ops can only benefit from greater dialogue about POS system limitations, successes, and development standards. By their very nature, co-ops have specific needs and detailed requirements for member/customer software modules. We also need more exacting product information than our POS product tables typically handle. Regulatory requirements such as country of origin, nutrition facts, and the dozens of product attributes need to be made readily accessible through our product tables to serve the public’s growing food concerns and demands.  

 Given how much money, time, and collective effort we spend on our local POS systems, shouldn’t this basic information tool enable us to be more efficient, more effective, and more informed co-op grocers? Although each of us can influence our developer’s future releases a little, it’s not likely that we will ever have the influence of mass retailers. By defining POS system needs clearly and comprehensively, perhaps co-ops will someday approach specific POS developers to write system software that will work for co-ops across the country. Such an effort can only help all co-ops to do a better job in serving their local communities.   

System integration 

System integration makes POS work easier and provides better control. Retailers want to know if inventory valuations can be posted automatically to the general ledger, or if direct store delivery (DSD) will communicate with accounts payable. They want to know if changing weighted-item pricing in the POS product table will automatically update prices in random weight scales in service departments. They want to know if food-costing software in their food service department will automatically transfer to appropriate Type 2 UPC codes in the POS product table. 

The Internet poses new challenges as well. Can you update product prices on your website’s shopping cart when you update them at your front end? Do you set up separate deposit summaries for products or services you sell on the Internet, or do those electronic payments pass through to your POS daily closing summaries? Will your new POS system prompt cashiers to remind the customer of the cooking class she registered for on your website? 

These refinements in POS technology may not be applicable to your co-op’s particular business goals and objectives now, but it is advisable to think about these questions before you define your POS purchase needs or problems too narrowly.