Vendors are working hard to understand how to best use retail POS and inventory data which is made available via EDI 852 or a web portal. Here are five very common questions vendors ask as they work with our team to put a data analysis solution in place.

What is the difference between EDI 852 and data available on my retail customers web site? The most obvious difference is the format of the data. EDI 852 is a standard document template but it is encoded using line identifiers and other language necessary for computers to make sense of the data. EDI 852 must be parsed and translated to be of any use to a business user. Data available in a retail portal is typically either presented on screen or saved into a text or spreadsheet format. These files do not require translation and can be opened in a variety of Windows programs. A second difference is the level of detail available. An EDI 852 document always includes units sold by UPC but it may not include on-hand data. And receiving store level EDI 852 data is often an additional selection and cost. Most retail portals will provide detailed store level data files, or presentation of detailed data on the screen. Finally, and most importantly, EDI 852 values for each UPC can be different than the values reported in a file available on the portal. This can be due to different reporting periods, different source and/or additional source system data, or a different method of handling of returns.

If I can choose between EDI 852 and a file from my retailers' portal which one should I choose? This decision comes down to a few factors. First, does the retailer charge a fee for sending data via EDI as opposed to accessing the data on the portal. Second, does the EDI 852 data provide less information than the the portal. For example as noted above some EDI 852 files do not include on-hand or store level data. Finally, research the data accuracy of the two sources and choose the one which will best support your decision making process.

What types of reports should I be using? There are three reports that form the backbone of retail POS data analysis: item sell-thru by store, inventory on-hand by item and store, and top selling items. From these three reports you can create a library of very useful decision support tools segmented by geographic region, product category, and by retail partner.

Why should I consider an outsourced service for POS data analysis? For most vendors working with POS data falls outside their IT organizations typical scope of expertise and tools. Simply put there is a fairly large volume of data which requires translation, scrubbing, and organization into a sophisticated data warehouse. The data does not fit into most organizations ERP, forecasting, or accounting system so the IT department if faced with building a custom application. Then end users need a simple and quick tool to access the data for analysis and decision making. An outsourced service can deliver the necessary engineering and software tools in a very short period of time without an expensive investment. And outsourcing provides a cost effective monthly expenditure which aligns with your cash flow instead of a large capital expense.

Why can't I just use a spreadsheet for analyzing POS data? Spreadsheets have many limitations when it comes to analyzing POS data not the least of which is simple row and column limitations. But more importantly there is a significant amount of work required each day or week to accept, transform, format, and analyze data in an Excel spreadsheet. Time which your staff can avoid all together by using more sophisticated tools and/or an outsourced service. In addition spreadsheets are generally not well suited for team based collaboration on data. Each time a spreadsheet is opened the user has the opportunity to change/edit data which can rapidly deteriorate the quality of the data and cause significant duplication of effort.

Do you have a question not listed here? Check out our FAQ or email us and we will post your question (anonymously) to the blog along with an answer.

> return to Blog home