Home > Blog > SmartSpoke™ Point of Sale Interface

Posts Tagged ‘point of sale’

  • 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…

    2010.08.06 / 1 response / Category: Uncategorized

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

    Read the rest of this entry »

    2010.07.23 / no responses / Category: Uncategorized

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

    2009.12.05 / no responses / Category: Uncategorized