Currently, the process to reset qty allocation and on order start the process by zero out all item and inventory location qty allocation and on order. Then it start to read the open orders to accumulate the qty allocation and order. Depend on users system, this process can take a few minutes to 10 minutes.

During this period, the system is vulnerable if another user is creating orders to change allocation and on order. That is the reason why we suggest user to run reset allocation and on order at night time through defer processing. However, some users is having website running at 24x7 basis. Therefore, user still have vulnerability even this is run at night time.

So it is suggested that we should have a new method to perform reset. The idea is we will introduce a Reset Qty Adjustment table, say IMRSTQTY. It will consist of the following columns
Item Number Primary Key
Location Primary Key
Bin Number Primary Key
Serial Number Primary Key
Qty-Alloc-Before
Qty-BO-Before
Qty-On-Order-Before
Qty-Temp-Alloc-Before (For WMS users)
Qty-Alloc-After
Qty-BO-After
Qty-On-Order-After
Qty-Temp-Alloc-After (For WMS users)
The reset process is create this table from scratch, then copy the current allocation, BO and on order to to this table's Before columns. The After column will start with zero value. Then perform the reset process like before. Both reset allocation and on order can be ran at the same time which may result in some efficient.

After the process is finished, system will compare record by record to see if the before and after are the same. if they are not, we need to perform a "NET" adjustment. That is we will read the item or inventory location record. Their inventory allocation, backorder and on order is likely not changed. But if it is changed, there is no worry, because we only do net adjustment.

Because we only need to lock the item or inventory location record for a split of a second before the update, so there's no vulnerability. Also, if a user keep an item or inventory location record lock, currently, we skip the entire reset process. For the new process, we don't have to. We can just skip that record for updating.

We can also update bin allocation (for multi-bin users), and serial allocation (for serial number users) based on screen parameters.