Information Centre
Whitepapers
The Data Integrity Challenge
Implementing a Scale Management application requires some thought as to how data integrity will be achieved across many devices scattered across a retail organization. Ensuring data integrity requires a well thought out plan. Careful consideration is needed to pinpoint each potential point of failure and address it accordingly.
A number of challenges present themselves when considering how data integrity can be assured. A properly designed and deployed application should address these challenges by using automated processes to pro-actively monitor, report and correct discrepancies as they are encountered.
Discrepancies occur when there is an error at some point in the update cycle. In a typical scale management installation, a central host system provides pricing for records that were changed since the last update took place. These updates can occur weekly, daily, or in some cases throughout the day, based on the retailer's capabilities. Where do these discrepancies arise and how are they addressed?
Data Changes in a Specific Scale
In this scenario, a store operator performs one of more unauthorized changes to the item data in the scale memory. The ability to access a scale's administrative functions is often known to various store personnel. Using the administration function, operators can recall PLU Items by number and change any of the associated data such as price, UPC code, tare, description or ingredients. Without a mechanism to monitor these changes and report them, they grow within the scale until the item is refreshed from the central system.
Preferred Method of Resolution:
Scale Management Systems should be capable of polling the stores periodically to retrieve a copy of the item file in each scale. The file can then be compared with the Master Item File to identify any discrepancies. An audit log of the results should be created for transmission back to the central system. All errors should be automatically updated and applied to the scales though a pending maintenance batch. This capability needs to target one or all scales as easily and as often as retailers need.
Changes to the Store's Scale Management Application
Normally, scale item changes are managed from a central or regional location and broadcast to all store locations where updates are applied to the weighing and labeling equipment. At times though, it becomes necessary to make temporary changes at the store itself. This can happen when data is not properly processed, a bad transmission is sent from the central host system, pricing is applied incorrectly, or markdowns are required to clear an overstocked item. In any of these events, an in-store pricing coordinator commonly makes the required changes and applies them to the scales.
As with any system, there is always the potential for abuse, however remote. Depending on the level of access granted by the retailer, any number of store personnel may have access to the system and can inadvertently make unauthorized changes. Price reductions for example, can be put into effect for valid reasons like an over-stock situation but subsequently left at the reduced price simply because store personnel forgot to reset the item back to the regular retail price.
Preferred Method of Resolution:
A proper scale management implementation will address these issues by providing the following functionality within the store and central host system software.
- Ability to setup users in the system. Prevent unauthorized access by users to certain departments and from the general configuration sections within the software. This requires certain security functions to exist in the application so that System Administrators can set up users, passwords and department level access.
- Ability to collect and maintain an audit trail of activity performed in the system by user, date and time. This allows head office to report on system and item maintenance as well as who performed the activity.
- Ability to retrieve the item file from the store and perform a discrepancy analysis at the central host system to identify changes that occurred within the store system.
- Ability to resolve those changes by automatically re-sending from the central host system those items for which discrepancies were encountered.
Errors Transmitting Data in One or More Scales
This type of error can affect a single scale that was inadvertently turned off before or during an update or can be caused by a wiring problem affecting one or more scales connected to the central system. Either way, the scale management system must be able to detect the failure and perform the required set of retry attempts before reporting the failure and moving on to the next scale. Retry attempts are low level communication events that are designed to overcome a temporary problem caused by noise interference, slow scale response etc. Scale communication protocols identify the number of retry events recommended by the manufacturer. The scale management system should at a minimum meet, if not exceed these recommendations. The level of severity is medium since only a single store is affected.
Preferred Method of Resolution:
Assuming that after the required number of retries, the transmission has not been successful, the error should be logged and reported back to both the store and the central office or a help desk. Automated processes could be invoked at a later time in order to retry the communication event. If successful, the original posting to the central system or help desk should be updated to maintain the audit log.
Errors Accepting Data From a Central Pricing System
A data feed was not accepted by the host component of the scale management system due to some form of data corruption. In this case, the scale management host should be able to confirm with the central host pricing system that data was received and processed properly. Any failure needs to be reported so corrective action can take place. The level of severity for this issue is high since a significant number of stores could be affected.
Preferred Method of Resolution:
The central pricing system should be able to detect transmission success or failure by requiring an acknowledgement from the scale management host. If not received by an appropriate time, an alert message would be automatically generated to IT Support.
Errors Transmitting to One or More Stores
In this instance, a central host data feed failed to arrive at the store due to a problem on the wide area network between the head office data center and the store. The level of severity is high for this issue since a significant number of stores could be affected.
Preferred Method of Resolution:
A central scale management system should have the ability to receive back from the stores a response that changes from the central system were received. Failure to generate a response from a specific store indicates a communications failure to that store or within the store itself. The scale management host system can then notify IT Support of the failure so corrective action can be taken. The notification should include all relevant information and batch number details.
Conclusions:
In order to achieve effective data integrity throughout each process and sub-system in a scale management application, pro-active error and corrupt data detection systems must be in place. These "detection agents" should be automated processes requiring no manual intervention. It is critical to the overall success of any data integrity process that these mechanisms pin-point errors when the data becomes corrupted. Downloading data from one system to the next without validation simply allows corrupt data to remain undetected. This is essentially the same problem before scale management was implemented; the problem is just centralized instead of confined to the stores.
