mariposacoop/IS4C — Issue #151: Multiple transactions with same employee and transaction number on same day
Author: tmmagee
Created: 2011-12-31 22:42:17+00:00
State: open

The script that pushes transactions from IS4C to MESS depends upon the following combination of fields in the dtransactions table of the transaction database to be unique for each transaction
- The employee ID
- The transaction number
- The day of the transaction

There is currently a bug in IS4C where it is possible for two transactions to have the same employee ID and transaction number on the same day.

For every new transaction, IS4C looks up the last transaction number (which I will call last_trans_no for short) used on the day of the transaction for the employee/cashier who is logged in. It then sets the transaction number for the new transaction to last_trans_no+1 to ensure that every transaction us unique for that employee on that day.

HOWEVER, it is actually possible to change employees mid-transaction. If an employee (employee A) locks the screen in the middle of a transaction and then another employee (employee B) with equal or greater privileges logs in, then employee B will be logged in and the current transaction number will stay the same. All following transactions will increase by one from the previous transaction.

The following scenario has actually occurred and it is how the bug was discovered:

Employee A starts the day and runs twenty transactions. The screen is locked and employee B logs in. Current Employee: B. Current Transaction: 20.

Employee B completes 40 transactions and logs out. The final transaction number for employee B is 60.

Employee C logs in starting at transaction number 1. On transaction 20, employee C locks the screen. Employee B once again logs in to unlock the screen. Current Employee: B. Current Transaction: 20.

Employee B then completes 40 more transaction, all of which have duplicate transaction AND employee IDs to the preceding 40 then employee B completed earlier in the day.

Once again, the script that moves transactions from IS4C to MESS _depends_ upon the combination of employee ID and transaction number to be unique for any given day, so the duplicates cause IS4C to send bad transaction data to MESS.

The fix: when employee B logs in mid-transaction, IS4C should update the transaction number in localtemptrans with that employee B's last_trans_no + 1 for that day.