Five New POS Interfaces in Development

Over the past 26 years we have authored numerous POS interfaces to our inventory back office software. The previous peak of our output  was in 1999, when we shipped four new POS interfaces. 1999 marked the near zenith of the the dot com bubble. I recall I was regularly talking to investors, venture capitalists, and  piloting a  leased airplane around the country. Times were good.

Y2K issues also peaked in 1999, so we got to ride the need for software that was  2000 savvy and replaced some systems that were stuck in 1999 land.

From 2000 - 2010 we typically had one or two new POS partners join us each year; however, during the last two years (read as "during the recession") we authored only one new interface - the two way integration to the Microsoft Dynamics RMS POS system.

During November 2010 the market moved and new partnership opportunities sprang forward. We currently have  FIVE new POS interfaces in development.

They are in alphabetical order:

1. Book4Time
2. MICROS,  Simphony 1.5
3. Squirrel Systems
4. Transaction Data Systems - Rx30
5. Vivonet - Halo

We welcome our new partnerships and look forward to a long relationship with each company.

As a measurement of economic health, I suggest that you add a new economic indicator  to your existing list that may have previously included such mundane items as: new housing starts, same-store sales, and weekly jobless claims. Add the DataWorks-POS-Work-in-Progress (DWPOSWIP for short) to your important economic metrics.

So,  is the recession over?  From our point of view -  YES!

Talking Points for a Point of Sale Interface to DataWorks

We have been publishing point of sale interface standards for many years. Many POS companies offer a DataWorks interface solution and the initial discussion typically centers around technical details. How will data move around? What hand-shaking mechanism will be used? Most of those technical details are covered here and here. But what about features that the POS system should have to benefit from DataWorks functionality? That is a question that is a bit prickly because many of our partners are serving the hospitality (restaurant, resort, casino) market, and retail functionality is not what they think, design or dream about.

So beyond the bit and byte facts that DataWorks defines and exports inventory and the POS partner captures and exports sales, here is the list of features that a POS system needs to have to be effective in the mixed venue retail market, where one POS system is used in both the F&B and Retail outlets.

The Bare-Minimum List: --------------------- 1. Allow for the input of numeric value via a barcode scanner, as an alternative to a touchscreen input or keypad entry.

The Basic List: --------------------- 1. Allow multiple barcodes to be defined for an Item. Typically only two are needed to accommodate the SKU and an optional UPC. In some cases a SKU will have many UPC codes. We have some items that can have more than 50 barcodes - postcards are a great example of this. 2. Allow the same Item to be defined and sold in different outlets. 3. Allow a different Retail Price for the same Item in a different outlet. This needs to handle the geographic borders of currency. DataWorks jumps though the currency hoops. This is important in enterprise systems where one system may be configured to handle multiple outlets. 4. Have a description field that is at least 32 characters long. Allow the description to be individually handled for a preferred language. DataWorks supplies the translated data for the outlet. 5. Provide for a means to define tax rate for each individual item.

The Competitive List: ------------------------ 1. Allow a single temporary retail price to be defined separately from the normal retail price with both a start and stop date for the temporary price 2. Allow many temporary retail prices to be defined for a single item. This allows promotions like Halloween, Thanksgiving, Christmas, and After-Christmas to be predefined, rather than waiting for each promotion to finish before the retail manager can define another. 3. Provide a link to a tax look up table per item 4. Provide a quantity discount for an item. 5. Provide a preset discount for a classification of items. 6. Provide a discount for a type of customer. 7. Provide a means to look-up, add, edit and export a customer and attach a customer ID to a sales transaction. 8. Size the POS database to contain an average of 20,000 Items per Outlet, but test for 100,000 active items and 120,000 active barcodes.

The Uber Advantage : ------------------------ Provide the POS system with either: 1) the ability to handle LOTS of data inserts and updates during the course of the operational day or; 2) give the POS the means to share outlet data.

Even though we go to great lengths in our above list to define that every outlet needs to be autonomous and capable of individual prices and language, there is the real world need that requires information be available without it being replicated into each outlet. The idea is that similar outlets can share the same information. This is very common in Resort, Casino and Amusement Parks. This is VERY important if you want to be able to accept returned merchandise at any outlet, even though it may not be stocked there.

DataWorks has the ability to replicate data into the individual outlets, but it comes with a burden of having additional processing crunch on the POS application. So this is one of those features that really needs to be designed from the ground up - because it is a data structure issue.

If you already have a POS in the field your best bet is to spend some R&D budget on your inventory import feature - because it needs to be able to process new inventory items very quickly. Don't think in terms of a total F&B menu of only 1000 items, think in terms of 100-2000 NEW Retail items every day. And then imagine adding those 2000 items during the lunch hour. If your POS system can do that, now you got an Uber-Advantage.

SmartSpoke™ Point of Sale Interface

DataWorks has always had interfaces to Point of Sale (POS) systems. Even when we sold our own POS  back in the late 1980s and 1990s we had to create a two-way interface to talk to ourselves. We designed and wrote the mechanics for keeping track of what data changes (deltas) needed to be sent where, we also wrote the communication layer between the back office (HQ)  and the POS that delivered  the deltas where they needed to be and also engineered the processing of the remote changes into the local data base.

So after 20+ years of writing two-way POS  interfaces you would think we would have everything worked out.

Next week (08/09/2010) we ship SmartSpoke™, our fourth-generation point-of-sale interface.

SmartSpoke builds on our tradition of hub and spoke design, but turns the tables on the communication layer.  SmartSpoke sits by itself on the POS computer or server.  It uses FTPS protocol to pull inventory down from the hub and push sales and customers up to the hub.

Our HQ software -- NeXT® -- prepares batches of encrypted inventory and price changes that sit behind a secured FTPS server waiting to be picked up by SmartSpoke.  NeXT also prowls around its local system seeing if any SmartSpoke system has pushed new sales or customer information up from the field.

By switching the POS communication activity to be active rather than passive we have eliminated the need for any communication listener on the POS side. With PCI compliance issues on many folks' minds, having an open FTP port on your POS system was a security risk that the CTO or IT director had to allow -- which is not good for your mental or physical health when you worry if your POS system is going to be hacked today. The SmartSpoke is fully PCI compliant and removes any security worries.

We are shipping SmartSpoke integrated to the Microsoft Dynamics RMS Point of Sale system first.

We plan to follow the Microsoft work with full integration to the MICROS 9700.  After that, who knows where the market will take us...

RMS POS System and Customer Tracking

Ask anyone in the POS industry what "RMS" is and they will tell you that "RMS" is Microsoft's POS and Inventory Control system.  But back in 1988, when DataWorks started creating inventory control software for the fashion retail industry, we marketed and shipped our own  software called "RMS". RMS stood for Retail Management Solutions. One  year the "S" was changed to mean "Software", and for a month or two the "S" stood for System. As I recall the change may have not even been deliberate. A typesetter or a proof-reader may have made the switch without anyone knowing.

When I get a chance I will insert the DataWorks RMS logo here. It was the last logo I created for the company.

Twenty-three years later (2010) we have integrated  NeXT®,  our enterprise back office inventory software, to Microsoft Dynamics RMS POS software.

Lately there have been a lot of internal conversations between DataWorks staff about the "RMS POS System." As you can imagine, this has caused some confusion among the long-toothed, senior DataWorks staff.

"Are we talking about OUR "RMS" or THEIR "RMS"?  The pronoun THEIR referring to a little software outfit called Microsoft.

As the fickle winds of marketing blew through our corporate doorway, we changed our software's product name again to ARMS around 1992.  ARMS first stood for Apparel Retail Management System. Circa 1994 the acronym was once again changed to mean Advanced Retail Management System. We went Advanced when we started working with Resorts and Casinos.

So DataWorks has this long tradition of keeping the acronym but changing the words. This was in the early days of DataWorks; we were young, unfocused, trying to figure out how to make a buck,  product names were not registered,  and trademarks were a thing of our future.

Our agility (youthfullness?) is  probably why there never was any trademark infringement law suits.

Around the time we started marketing ARMS, DataWorks began integrating with third-party Point of Sale hospitality systems (MICROS® and Par-Springer Miller being our major partners).  What is unique about the Microsoft RMS system is that it  is a SPECIALTY RETAIL system - not a Hospitality System.

What's even more interesting is that the current Microsoft RMS  feature set is very similar to DataWorks' old RMS system from the late 1980's and early 1990's.

Customer relationship and purchase profiles were a key foundation in the DataWorks RMS system. Our marketing brochures from that time featured an equilateral  triangle. The apex angle was labeled "Sales." The left-base angle was tagged as "Inventory," and the right-base was identified as "Customers."  We often said that RMS was built on this foundation. From Sales you could learn "who" bought "what." From Inventory you could drill down to  "when" items sold and "who" bought them. From Customers you could research "what" and "when" they purchased items.

There were some cool drill-down links that would allow an end-user to dig into those relationships. Our end-users really liked that ability and many NeXT users still talk about it today.

Those early 1990's days predated email and "www" marketing.  The DataWorks RMS Customer module had features for generating call lists for trunk shows and printing mailing labels for bulk mail rates. As I often said, if you wanted to know who bought red socks at full retail for Valentines Day, RMS could do it.

The hospitality market has been our focus for the past 15 years, and we have not seen a demand for our customer tracking ability until now.  We are involved in a new rollout of 150 stores using the MicroSoft RMS system as the POS system. We  dusted off our existing customer module's intellectual property and inserted many of the features we had back into NeXT.

NeXT always had a customer database in it, but no one ever used it since the hospitality POS system did not track sales or share customer data that way.  For hospitality it's more about the room # and customer portfolio than the individual customer information - most hospitality systems don't even have a customer database in their POS (Springer Miller being the exception) - all that is back in their reservation or property management system (PMS) - so there was no way for us to extract customer data for any micro-market mining.

All that changes with RMS; it's all about the customers.

Customer profiling, customer import and export features, customer marketing, accounts receivable interfaces and customer loyalty triggers are features needed by specialty retailers.

Guess what we are building into NeXT?

You guessed it: Customer profiling, customer import and export features, customer marketing, accounts receivable interfaces and customer loyalty triggers.

With an enterprise headquarters system like ours, inventory is created in NeXT and  sales are created in the POS system. Inventory goes down to the POS.  Sales come up to NeXT. It's a two-way interface, but each type of data only goes one direction: up or down.

With customers it's a round-trip ticket. Edits at the POS come up to HQ. Edits at HQ go down to POS.

Think through this: Customer X walks into Store A, makes a purchase, and the Cashier updates the customer record with a new phone number.  The same day,  the same customer (this time the husband), drops into Store B and buys his wife a birthday present. He mentions that he has a new phone number and a new vacation address. The cashier at Store B enters all that information too.

What happens to those edits? And how do they get updated into the headquarters system?

And what about sharing customers between stores; how can that be easily managed?  And what about customer duplicates and record merging; how should that be controlled?

We built it all in. It was a huge advantage  that we had a 20-year head start. Doing it the second time, this time with FTPS communication rather than 1200 baud dial-up modems, made the communication layer much  easier.

(Anyone out there remember Blast software?)

If you have two (2) or more retail stores and are using the Microsoft RMS or Microsoft POS 2009 systems, consider using DataWorks as your Headquarters system for Purchasing, Inventory Operations and Customer Management.

Contact us and we will be happy to give you a demo.

Ask for Mark.

Retail Inventory Control Operations - The 10 Second Rule - Part 2

Our retail inventory control operations happen in the back office -  typically far away from the public eye.  The general public never sees our software in operation.  Our enterprise clients typically have buyers huddled as a corporate team and receivers staffed in one or more warehouses around the country. In single property operations, the store manager usually has their workstation in the midst of  the store's back stock where they do both the buying and the stocking for their outlet. DataWorks end-users  are behind the scenes,  making the decisions and preforming the prep work that enable all of the front of the house operations to work.  They decide on the right mix of merchandise, the proper merchandise presentation, the target margin, and when product needs to be marked down and moved out.

They also have a sense of how long something should take to accomplish.  In our last post I talked about how the receiving function is the most heavily used feature of our software. I said that we strive to live within a  10 second rule for our inventory transactions;  yet, I admitted that this function typically takes much longer than 10 seconds to process.

In our home we use to live by the "5 Second Rule".  If you drop something on the kitchen floor, and it has been there for less than 5 seconds you can plop it back on your plate, splash it into your bowl, or drop it into you mouth. More than 5 seconds? Meet Mr. Garbage Can.

We now have three reasons that make this rule obsolete:

1. Our 3 year old son is not fond of washing his hands.
2. Our maid is a Roomba robot who is long on determination, but short on suction.
3. We have Ringo - the pet ferret - who was last seen headed behind the dishwasher with a naked barbie doll clenched in his jaws.

So, if ANYTHING touches the kitchen floor in our home it is walking down the long dark hallway for an interview with the garbage can.

On the opposite side of this plate is my culinary rule when camping. If  dinner drops to the dirt, I give it a brush, blow on it once, then eat it up,  grime, grit and a grin - regardless of  elapsed contact time with terra firma.

A person's sense of cleanliness or sense of urgency depends a great deal about where they are.  The context of "where" determines our expectations on how long is too long.

Put another way: walking down a dark alley is not the same as a stroll in the park.

Now that I have wandered off  topic and stumbled over my metaphors, it is time to loop back and pick up the post where I dropped my chain of thought...

Our inventory control operations happen in the back office, far away from the glare of the public.  But our point of sale partners are right out there in the public's line of fire.  When one of our bar-codes is scanned, the price is expected to "instantly" appear.  When the sale is totaled we  expect the tax  to "instantly" appear.

Besides being done in front of the public, the point of sale transactions has some other special distinctions about the end of the transaction that separate it from the completion of other inventory control operations. The point of sale transaction has one or more connections to mechanical devices that can mask the time it takes to save the transaction.

1. Printing of the sales receipt can mask the time to save the transaction to the database back-end.
2. Popping the cash drawer will absorb a second or two of transaction time.
3. Rolling coins down an automatic change dispenser chute will amuse patrons,  keep the cashiers hands clean, and certainly hide any digital needs with analog springs.
4. The prompting of a signature or the requirement of a PIN input by the customer puts a great deal of slack time into the transaction.
5. Verification of ID, with the inspection of a Driver License Number or Phone Number eat up enormous amounts of CPU clock cycles
6. The Credit Card authorization can absorb any residual transactional latency.

The credit card authorization really is a separate financial subroutine event that happens outside the inventory control transaction, but it holds the final keys to locking the transaction down.  When the credit card is swiped we expect the approval to occur in -- what?  Two seconds?  Five seconds? Ten Seconds?

My experience is that when any sales transaction takes over five seconds (credit card or no credit card) the clerk will utter the universal face saving, "the system has been slow all day" disclaimer. (The exception to this is the patient staff manning AT&T cell phone stores, their transactions always take somewhere north of  30 seconds - and they never blink until the 45 second mark is passed)

When the credit card authorization subroutine takes more than 10 seconds, I start fanning my wallet,  looking for cash or alternate slices of plastic because I figure that the credit card processing company is about to bingo my card - a big blue banner of  broadcasted unhappiness is about to scroll across the Verifone's display.

Exception to the anxiety index?  Black Friday or Christmas Eve - I expect to wait for the authorization subroutine to complete and the delay will always be the result of the extra demand being pushed into the system - it is never my problem on those days.

Consider this - our retail inventory control operations typically occur as solo events --  no one is around to share the moment with, no one else can hear the  "this takes too long" statement. Additionally,  there are no mechanical contraptions to print, pop, roll, amuse or distract us from the event. All we offer are thermometer bars that mark time to the rhythm of the saving records. With the lack of distraction,  I believe our inventory control transactions seem to take longer than point of sales transactions even when they take the same amount of time. Of course how many 100 line item POS transactions have you ever heard of?

Having just said that, I remember that back in the late 1980s and throughout the 1990's our SCO Xenix and MS-DOS applications were designed to begin a print job  immediately on the save of a transaction. As soon as the receiving event was told to process we would start printing out a "report" that would document the event for accounting and paper back up. The first step of our transaction would be to dump the contents of the transaction out to a Dot Matrix Printer.  The print command would take a half a second or two to push, and once completed we could continue with the work of quantity, cost, retail and accounting updates. The printer would take a good 30 -60 seconds to weave fan fold paper under its 32 character per second print head and when the printer ejected the paper up to the rip line, the transactional data was safely saved and waiting for the next transaction to begin.

We now design our back office inventory control operations to only print on demand. A document that can be printed to the screen, or emailed to a department, or published as a PDF file has taken away our ability to hide the transaction's save in the shadow of the printer. Plus we feel pretty good about our green policy and the fact that we are saving acres of pine forests from being bound into journals full of DataWorks documents.

Having just pulled those two decade memories up to my frontal lobe, it might be possible to design the receiving transaction to spool up the bar-code ticket printer at the beginning of the transaction with the need for hang tags or adhesive sticker stock.

I have done a fair bit of political back peddling on this post.  I declare that we have a 10 Second Rule and then do a great deal of mental pondering on modifiers to the rule. The 10 Second Rule is a design goal.  Whenever I hear there is a "Rule" in computer programming,  I start toward the fire exit,  looking to protect myself with a new software vendor. Rules are created by programmers, designers or companies who have either a mental block, a framework restriction or a language weakness that is preventing them from doing something better.

Hopefully,  I have painted a picture that our inventory processing time is indeed relative to the where and when it occurs. Both the "where" and the "when" have something to do with our sense of urgency and our expectations on system performance. The next post will be "when" you will not have to wait any longer on how DataWorks will deal with transactions that do take over 10 seconds.