CRITICAL BUG: CORRUPTION OF STOCK TABLE DATA!
Posted: Thu Jan 24, 2013 4:27 pm
Dale,
I found this one through an oddball series of key strokes trying to cancel a transaction.
This bug corrupts the INVENTORY for an item by reducing the inventory count for an item that was not actually sold with what looks like a canceled sales transaction.
This bug is consistant and can be reproduced.
Tested with version 7.1g and 7.1j. (good chance it exists in previous also)
This can happen when using the [Tab] key to modify the quantity sold of the first item scanned into a sales transaction. (Note: register is set up to work with a scanner or if the scanner option is set to "3. All stock numbers are assumed to be scanned." or if the [F8] option is used when entering an item.)
How to reproduce:
SETUP: To be able to verify results, first go to the stock table and note a test item and its Inventory count.
1. From the sales transaction screen, Scan the barcode of your noted item. (On screen will show ┤PRESS [TAB] TO MODIFY LAST LINE├)
2. Press the [TAB] key as if you want to change quanity. (Cursor returns to Quanity field)
3. (Change your mind about it) and Press the [Esc] key. (Cursor returns to Stock # field)
4. Press the [Esc] key again. (program appears to Cancel the sale and returns to POS main menu)
What appears to be a canceled transaction has actually corrupted the the inventory count by reducing the item's count by 1 as if the transaction was completed sale. ie it doesn't return the item to inventory like when a transaction is [F5]Voided.
To verify results, go back into the stock table and note the test item's Inventory count is now one less than before even though the sale was never completed.
Note this can only happen if it's the first (only) item scanned in a transaction. Attempts with subsiquent items scanned and [Esc] as above obviously won't cause the problem because one would need to [F5]Void the entire transaction, which does return the items to the inventory as it should.
I found this one through an oddball series of key strokes trying to cancel a transaction.
This bug corrupts the INVENTORY for an item by reducing the inventory count for an item that was not actually sold with what looks like a canceled sales transaction.
This bug is consistant and can be reproduced.
Tested with version 7.1g and 7.1j. (good chance it exists in previous also)
This can happen when using the [Tab] key to modify the quantity sold of the first item scanned into a sales transaction. (Note: register is set up to work with a scanner or if the scanner option is set to "3. All stock numbers are assumed to be scanned." or if the [F8] option is used when entering an item.)
How to reproduce:
SETUP: To be able to verify results, first go to the stock table and note a test item and its Inventory count.
1. From the sales transaction screen, Scan the barcode of your noted item. (On screen will show ┤PRESS [TAB] TO MODIFY LAST LINE├)
2. Press the [TAB] key as if you want to change quanity. (Cursor returns to Quanity field)
3. (Change your mind about it) and Press the [Esc] key. (Cursor returns to Stock # field)
4. Press the [Esc] key again. (program appears to Cancel the sale and returns to POS main menu)
What appears to be a canceled transaction has actually corrupted the the inventory count by reducing the item's count by 1 as if the transaction was completed sale. ie it doesn't return the item to inventory like when a transaction is [F5]Voided.
To verify results, go back into the stock table and note the test item's Inventory count is now one less than before even though the sale was never completed.
Note this can only happen if it's the first (only) item scanned in a transaction. Attempts with subsiquent items scanned and [Esc] as above obviously won't cause the problem because one would need to [F5]Void the entire transaction, which does return the items to the inventory as it should.