By Justin Hewitt
The topic for today is “big retail” and how an industry standard data container (the ARTS POSLog) can tackle common integration issues with different retail systems and abstract the “Point of Sale” data collection layer from the backend processing layers.
Usually we blog about using data once you have aggregated it; but today lets go back a step and talk about the data collection/transmission management and setting up the plumbing that will ultimately make data aggregation much easier, which in turn will makes your retail BI data collection easier and faster to gain insights from.
POSLog (the data container) is an industry open standard retail schema developed by ARTS, a subgroup of the National Retailer Federation. It has been around a while and is quite mature as a standard; but still not too many people have heard of it.
The primary goal of an industry defined schema like the ARTS POSLog, is to reduce costs through standards. That is, by setting a standard for data transmission and interchange that all POS vendors adhere too, you ensure consistency across platforms and this gives retailers more flexibility with their selection of software and hardware for the ‘point of sale’.
The POSLog is a standard that works internationally and reveals the similarities between POS practices country to country. Japanese, American, Australia or Icelandic retailers (as a sample set) can all map their retail data into the POSLog schema. The POSLog can be used as an asynchronous data transmission container or synchronous request/reply type data exchanges where both directions are POSLog.
Retail Data Collection.
Just as a background, your typical retail data collection from a customer interaction, will document:
- POS Channel.
- Sales Items (SKU’s/Services sold)
- Methods of payment, e.g. cash, EFT, cheque, account, layby, prepaid, voucher
- Physical location of outlet/POS e.g. site ID, lat/long, department, floor region
- Operator identification
- Supplemental data e.g. Item reference, customer personals, government requirements
- Control features, e.g., receipt number, date and time, etc.
- BLOB data e.g. images, encrypted data
- Money movements e.g cash out to HQ
- Operator logins/logouts & security changes
- Errors, surpluses, deficits etc.
<!–[if gte mso 9]>
<w:LsdException