Business Problem

In the ongoing struggle to maintain an accurate system on hand, we need to revisit recalculating on hand to account for depletion, received order, transfers in and out, and anything else that may impact the on hand while a count is in a draft state.

Details

Initially, we though that we could simply record the on hand when a count is created and subtract that from the on hand when a count is applied to provide an accurate representation of the depletion. It turns out that this is true in some cases but not others.

When this works:

1. If the user starts a count and counts everything immediately then makes no changes until the count is applied. Doing this ensures that any activity that impacts the on hand is independent of the starting on hand or the user count.

When this does not work:

Basically any other time.

1. The user starts a count in InFORM but does not count the item in the store immediately. When this happens depletion can occur, an order can be received, and/or transfers can be sent in or out. The user then counts what is in the store including these changes.

Additional Info

I have created a spreadsheet to help demonstrate the issue with several testing scenarios. Please take a look:

• https://fourthlimited-my.sharepoint.com/:x:/r/personal/jason_powell_fourth_com/Documents/CalculatedOnHand.xlsx?d=w0e27df751faf4508b9d4746e15a8013a&csf=1&web=1&e=u0p6h9

Where Should This Feature End Up?

The fact is that these draft orders are causing problems with the on hand and we need to find a solution. What we ultimately would like to happen is the following

1. The user opens a count
2. During the time the count is in the draft state, system depletion and other factors change the system on hand.
3. The user applies the draft count but instead of updating the on hand with the user entered value like we do today, the system recalculates the on hand based on what the user entered and the changes that impacted the system on hand while the count was in draft.

Main Question to Answer

1. Assuming the user does everything correctly, how can we make sure that the on hand is as accurate as possible and accounts for counts, depletion, etc....
   1. Anything goes here. Any suggestion that gets the job done.
2. We can assume that the user will only be able to keep an order in the draft state for a limited time. For the purposes of this research we will start that limit at 5 days. Starting with 5 days lets us determine what the system can handle under end of month style pressure. If 5 days is too long to recalculate then what is the max amount of days we are comfortable with?
3. How close can we get to real-time with our recalculation? This means can we save snapshots of system data every minute or does system pressure dictate that we can only save system snapshots every 15 minutes or more?
4. Where does our best solution break down?
   1. We can potentially make some additional changes to how the user interacts with the site to make this work. For example, currently, when the user starts a new count, they system checks to see if there are any open orders or transfers to be received. This check is not activated when the user opens a draft count. It's possible that we need to add this check to draft counts as well to improve our level of confidence with the on hand recalculation.