Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Micros 3700 possible Paid-Out theft vulnerability.

Status
Not open for further replies.

mikrotransynergy

Technical User
Nov 5, 2007
1
US
I manage a small restaurant with 4 workstations and is running RES 4.9

at least 2 or 3 of the seven days of the week, the deposit is always short by some "noticeable" amount. aside from internal system rounding, the sales should balance within pennies. if it's off by 5 dollars or more, I need to investigate.
I always come to a dead end when searching the journals and reports and can find nothing to account for the missing money.
yesterday I experienced the vulnerability first hand. I watched an employee do a paid-out from the bar terminal to a vendor (I was taking a call from the hostess desk so I watched the vendor get paid but did not see the keystrokes used to complete the transaction). any other vendor that came was paid by business check by myself. I was called back in the evening to close the restaurant as the closing bartender/manager had an emergency.
when I ran the EON report I couldn't help but notice there were no paid-outs and the deposit was short. I KNOW there was at least one paid out that was done using the drawer cash because I witnessed it earlier in the day, but did not reflect in the report. I searched the journals on the server and there were absolutely no "paid-out's" shown. the paid-out button does work and it does log in the journals because I went to previous days that I personally did paid-outs and they were documented.
I spent a dedicated hour this morning trying to replicate this problem. I did not ask the employee what happened because I believe this was done in error and I did not want to draw attention to the issue without proof, but that's not to say that if another employee who closes and has permissions enabled to use paidouts, cant exploit this vulnerability if they know about it.

"Paid-outs" are done and logged using the following standard procedure:
-sign in.... "function".... "paid-outs".... enter dollar amount.... enter reference description...."enter"
the drawer opens and a chit and receipt are both printed and user is returned to the main screen. i ran a report to confirm that the paidout is logged and shows up on the report.

This is how I replicated the vulnerability:
-sign in.... "Start check (by table or name)".... "function" .... "paid-outs" .... enter dollar amount.... enter reference description...."enter"
the drawer opens and a chit and receipt are both printed but the transaction for the table is still open and awaiting an entry for food to be ordered. at this point there is a check open with no items ordered and user can simply cancel the transaction, close the $0.00 check to cash, or "send" and keep the open check on the system to be closed later. transaction completed with paidout done and no record of the paidout anywhere. the only clue I have is a check that is canceled or a check closed to $0.00.

I feel that the work involved to investigate months and years of closed checks for $0.00 that did not have a legitimate void associated with it, would be too daunting and time consuming. and now that i think about it, (I'm going to try this later) a paid out can probably be done on any open check with food ordered or not, so a tendered check closed to credit card or cash could have a paidout associated with it that can't be tracked. the best I can hope for at this point is to somehow disable paidouts from being initiated while a check is open and being used to order.

any help or programming suggestions are greatly appreciated.

Thanks in advance,
Jay
 
Move your "Paid Out" button onto a management screen that is accessed before you can get to a sign-in to do a transaction screen.
 
Or set the priority high so it requires a manager auth to perform.

Honestly though, this isn't going to stop the problem. If a bartender is getting the drawer open and hitting transaction cancel, it's conscious theft; flat out. You can also limit the bartender employee class to require a manager authorization to close $0 checks. POS Configurator / Employees tab / Employee Classes button / Options tab. Uncheck "close zero balance check" for the bartender class. Using both may cut down on this, but only until they start using the No Sale button to open the drawer for payouts.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top