We recently had an occurance where a user was posting an Inventory Batch Transaction with about 76 Item Transactions. During the posting, the user's pc lost network connectivity and the transaction hung. So she re-posted it and it processed. However, the hung transaction was in the system. During talks with Microsoft Customer Source, one of their steps actually made the original transaction finish, resulting in the same batch showing up for two different transactions in IV30100, and each item getting duplicate quantity updates. This of course is a problem. One thing to note before we go on, neither of these transactions go to GL as the items have no cost associated with them. So it is only on the Inventory side.
I have been in pretty constant communication with Microsoft on this problem and I have a preferred and unpreferred solution. Below is an overview of each.
First the preferred solution:
- Make an Inventory Transaction to back out each duplicate transaction.
- Delete the duplicate Batch ID from the IV30100 table
- Delete the associated historical transactions from the IV30300 table
- Perform both the Check Links and Reconcile functions
The good thing about this solution is that Microsoft preferrs it because it is the cleanest solution. We do not have to worry about any dependencies with other tables or areas. The down side is that we lose our history regarding this problem. In essence, if we were to tally up the count of all transactions for any of the items it would not equal the amount in the item's quantity.
The non-preferred method (by Microsoft that is):
- Make an Inventory Transaction to back out each duplicate transaction.
- Delete the duplicate Batch ID from the IV30100 table
- Update the original Batch ID from IV30100 table to have double the BCHTOTAL value (total number of items)
- Update all associated items from duplicate Batch in IV30300 to have the same TRXSORCE field value (IVADJ #) as original batch
- Perform both the Check Links and Reconcile functions
Microsoft warns that it is risky because there will be data in the table that does not follow the standards of how the system inputs it (some fields are incremented in a specific way,i.e. LineSequenceNo, and they wouldn't follow those specifications). However, they do say that it really wouldn't affect much because they are in the history table and the transaction cannot be viewed from GP. Additionally, we would have traceability for each item in the batch as every transaction that has affected the quantity would be kept.
So my question is, would following the second method create any other problems that have not been identified. I, along with some other system power users, like the idea of having the history accurately reflect the item quantities. I would appreciate any feedback on this.
Thanks in advance
Brian
![[cheers]](/data/assets/smilies/cheers.gif "[cheers] [cheers]")
I have been in pretty constant communication with Microsoft on this problem and I have a preferred and unpreferred solution. Below is an overview of each.
First the preferred solution:
- Make an Inventory Transaction to back out each duplicate transaction.
- Delete the duplicate Batch ID from the IV30100 table
- Delete the associated historical transactions from the IV30300 table
- Perform both the Check Links and Reconcile functions
The good thing about this solution is that Microsoft preferrs it because it is the cleanest solution. We do not have to worry about any dependencies with other tables or areas. The down side is that we lose our history regarding this problem. In essence, if we were to tally up the count of all transactions for any of the items it would not equal the amount in the item's quantity.
The non-preferred method (by Microsoft that is):
- Make an Inventory Transaction to back out each duplicate transaction.
- Delete the duplicate Batch ID from the IV30100 table
- Update the original Batch ID from IV30100 table to have double the BCHTOTAL value (total number of items)
- Update all associated items from duplicate Batch in IV30300 to have the same TRXSORCE field value (IVADJ #) as original batch
- Perform both the Check Links and Reconcile functions
Microsoft warns that it is risky because there will be data in the table that does not follow the standards of how the system inputs it (some fields are incremented in a specific way,i.e. LineSequenceNo, and they wouldn't follow those specifications). However, they do say that it really wouldn't affect much because they are in the history table and the transaction cannot be viewed from GP. Additionally, we would have traceability for each item in the batch as every transaction that has affected the quantity would be kept.
So my question is, would following the second method create any other problems that have not been identified. I, along with some other system power users, like the idea of having the history accurately reflect the item quantities. I would appreciate any feedback on this.
Thanks in advance
Brian