Back Office Inventory Features for Version 7

The velocity of new features being shipped in NeXT has really accelerated during the past 3 months.  Most of the work has been centered on our Food and Beverage modules, but plenty of features for Retail have shipped as well. Version 7.26.47 was released on Sunday, November 6, 2011. The full scope of Version 7 of DataWorks' NeXT Back Office Inventory system  is massive, but here is the short list of enhancements and features that I wanted to highlight. Product Form:

• New Wrapper to separately maintain Retail, Food and Supplies Products.
• New Menu to Review Archived Products
• New Lock / Unlock of  Cost and Retail Controls
• Standardization of Product Attributes to enable control for Retail, Food, Supplies or Global access.
•  Taxable Purchases setup for Supplies
• Catch Weight definition for Food
• Sysco 832 EDI order guide import
• Vendor Product EDI Linking / Unlinking capacity
• Vendor Product to Manufacturer product creation.

Purchase Orders:

• Reusable Templates for Shopping List and Common Reorders grouped by employee access
• The Ship To Facility was freed from Employee Access rights.
• Added Search for Outlets allocated on a purchase order(s)
• Suppress need for Retail Input for Food and Supply vendors
• Ability to define Catch Weights for One-Step PO's
• New Internal and External Documents that specify Order, Pack and Weight units
• Search Option for Input Method (i.e. Manual, Suggested, Requisition, or EDI Import)
• Email PO to Vendor option

Receiving

• Catch Weight Input
• Automatic and Manual Tax Calculation
• Addition Landed Cost Calculation
• Suppress Need of Retail Input for Food and Supply Vendors
• Posting to Accounts payable distribution enhanced to smoothly round to two decimals

Physical Inventory

• Initialization of Physical Counts HUGE speed increase. Example: 30 minutes now 5 minutes.

Markdowns

• Enhanced Selection Ability
• Added Previewer with multiple selector
• Added Hand held interface for uploads

Requisitions and Fulfillment

• Default "Work For" Facility by Employee
• Reusable Templates by Employee Access Group
• Support for Hand Held Uploads
• Sort Options for details
• Debugged Store Specific Requisition Option when From Facility is a Warehouse
•  Date Needed Always Calculated - not just for Events
• Allow Fulfillment options to be re-evaluated by Warehouse staff's Employee Access rights
• Start Fulfillment form with a Find form
• Loosen  Requisition rules to allow more liberal submitting
• Changed Transfer Specific Option for Transfer From Facility to be free from Employee Access

Reports

• Warehouse Location Reports (D013 and D014)
• Consolidation Report C001,002, and 003 dynamically display number of decimals for fractional food and supplies
• Detail Sales reports DCOG01-09 compare base, landed and theoretical cost of goods.
• Barcode label printing  for Warehouse locations

Interfaces

• Base, Net, Landed, Center of Plate and Theoretical Cost of Goods now saved for historical reporting.
• MICROS Symophony POS  support
• Added Zip file options for packaging multiple export files into a fix or unique file name
• RX30 POS support
• Book4Time POS Support
• Version 3.0 of AP and GL exports support single flatten csv file format.
• Version 3.1 of AP export supports all optional PO User Defined Attributes

General

• Input for Product No and Description are now "Contains " rather than "Begins With"
• Verify Barcode export to hand helds for Receiving and  Transfer Ins
• Sped up access routines associated with adding a new facility

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