The interactive nature of the Inventory IQ system helps you supercharge your inventory management because every time a bar code is scanned, the system simultaneously accounts for that scan in terms of inventory on hand, consumption, and a host of other interconnected ways. Whenever something happens within a session that disrupts the order of the system, it creates an incident. Incidents are the system’s way of alerting you to an imbalance in your accounting.
The most common Incident message code is Item Transaction Incomplete. A typical situation is when inventory counts are inaccurate. For example, a user will take a pair of gloves from a bin, scan the bar code to check them out, but according to the system, there are no gloves available to check out.
When you view an incident on the Inventory IQ desktop app, one of the blocks of information on the VIEW INCIDENT page is the DETAILS section. In Item Transaction Incomplete situations as in this example, Mr. Otts scanned the barcode for leather gloves 3 times (Incident Qty) even though the system said there was no inventory available (Current Qty Available). The surveillance video shows that Mr. Otts did in fact take out 3 pairs of gloves despite the system believing there were none to take. The Processed Qty is 0 because you can’t take 3 pairs of gloves when the available quantity is 0.
There are a few different ways to resolve this incident. The way you choose to resolve it will impact the accuracy of your reporting and the likelihood that your team triggers more incidents down the road.
OPTION 1: Dismiss Incident
If you check this box, the incident will be resolved as if it never took place. The gloves that Mr. Otts removed will not be accounted for, and the system will still show an available quantity of 0. This is the option that sweeps problems under the rug; if used regularly, you will quickly lose most of the value of your system because none of the information you might use for analysis and tracking will be trustworthy.
OPTION 2: Receive (x) and Reprocess Transaction
If you check this box, the incident will be resolved and the gloves will be accounted for. The drawback to this option is that we won’t know where the gloves were received from. Also, the current quantity available will remain 0 since we only received in enough to cover the incident. Any time someone comes back to take out more gloves, it will trigger another incident for the exact same reason. For this reason, this SKU will come up first in the list of items due for cycle count so we can finally reconcile the quantity on hand with what the system says the quantity is. The sooner you do that cycle count, the better off you will be.
OPTION 3: Do some detective work and correct inaccuracies before resolving the incident
This is not a box to check, but a forensic investigation. In the tutorial video accompanying this article, Jonny shows how to investigate unreceived shipments, and how to correct counts by receiving the shipment into the system. In the case of the incident with Mr. Otts and the gloves, there is no pending shipment that applies here. Discrepancies can also occur when someone scans a bar code without taking the same number of items as was scanned, or if someone returns an item without scanning the return. The VIEW INCIDENT page also has a block called EVENTS, which is a historical listing of every transaction involving the SKU in question, which may be helpful in retracing steps and understanding how the discrepancy occurred. If you can find the problem and make the correction before resolving the incident, you will find the current quantity listed as a positive number, and you can check the box to reconcile the transaction using the quantity of gloves now on hand to resolve the incident.