Fraud Protection User Authorisations
The operator authorisations are decisive for the delimitation of responsibility. The Hypersoft system has extensive evaluations, you cannot simply delete bookings, so you have a high level of security. In practice, however, it happens that employees trick others into taking their place. Here you are in charge, otherwise you keep "bad" employees and part with "good" employees. Thus, undetected employee fraud can lead to significant disadvantages.
The possibilities are very versatile and the operator permissions can usually secure everything - as long as it is set appropriately for their use. Fundamental things are secure login procedures - for example with a operator lock, and the attitude to transaction responsibility in full service (who is allowed to book on "my" table and when).
In fact, it has happened many times in practice that an operator spies on another operator's login, books onto it and then gets separated from the other operator. However, operators should also take care of their keys and not hang them on a key board, for example.
You will find most hints and solutions by reading the chapter Operator authorisations and the possible switches. We mention special things separately here.
In the operator authorisations, you can allow the operator to enter prices freely at . The item master protects you twice:
-
Only items for which a free price has been activated allow the price to be changed.
-
For each item released for this purpose, you can also define a permissible price range.
A definable price range protects you and the operator from mistyping a decimal place, for example. Operators who are up to it make an extra mistake, point out the supposed typing error on the invoice, and then of course collect the actual amount.
Fraud with Discount and the Assign Customer function
If your customer data has discounts (or other benefits) stored, a transaction can be assigned to a customer to apply the discount (and other benefits). Depending on how the system is used and whether customers are selected and billed, this can enable fraud. Although the Hypersoft system has an authorisation for the maximum application of discounts, this is deliberately not checked and applied when booking to customers or assigning customers to transactions. For example, a "friends" transaction could simply be charged more favourably to a customer, or even a settled transaction could be reopened with appropriate authorisation, then assigned to a customer with discounts (or other benefits) and then re-billed with a lower amount. The operator could use the resulting credit for himself. Reports on Reopen Cancellation will of course show you this, if you evaluate them.
We recommend that you also use the authorisation Assign customer so that only authorised employees can assign customers.
Table transfers are necessary. In Hypersoft, you can still distinguish in the permissions between transfers before settlement and after reopening a transaction.
Especially with buffets and similar offers with standards, fraud attempts occur again and again. The operators do not book these items, but account for them later ("Here is your receipt with the drinks and, oh you still had 2 x buffet..." or "Do you need a receipt?"). Aware of this risk, managers then check whether "the buffet" has been booked on the corresponding transactions. However, this check does not hold up if the operator transfers "the buffet" to another operation before creating the invoice. IN practice, such items always make a trip through the restaurant during our examinations.
You can switch off the transfer in the operator authorisations or - what is better - allow transfers to control the reports on transfers and transfers after Reopen with our reports as well as evaluate the transfer bookings in the front office reporting per operator.
Also use the special report Transfer report by responsibility, which can analyse the passing through of bookings.
Back to the parent page: fraud protection