Postings to activities

When cashing up, a distinction is first made between free sales in Quick-Service mode and transaction-based sales (restaurant service). Other supported variants of transaction-based sales are prepaid systems and cashless areas. A transaction can therefore also be a table with guests, a customer card, anonymous transaction card or simply a reference to a customer account. Transaction-based sales that are not settled immediately therefore have a wide range of requirements and variations, so it is important to be clear about the setting of operator authorisations and provision of cash register functions. Some of these special cash register functions are:

table transfer
Split invoice
Tipping (also retrospectively)
Activity overview, open postings

To post to customer transactions, go to the chapter Customer base at the POS.

process responsibility

Transactions contain postings and are settled during closing. If several operators work on one system, the responsibility of the operations must be regulated. Otherwise, it may happen that another operator sells items on the transaction and elsewhere or settles the transaction for himself, including tips. Hypersoft supports these regulations through the /procedural responsibility. In the standard system, the operator who opens a task has the task responsibility posted in it. Via Operator authorisations you can determine whether other operators may then book into the transaction of another operator and separately set the authorisation whether other operators may settle this transaction. The functions Change operator can be used to change the responsibility for the operation among the operators.

In-House Ordering and 3rd Party Connections...

For processes from in-house ordering or from 3rd party systems or interfaces, there are often no operators assigned in the sense of Hypersoft POS, so such processes are handled in a special way. These tasks are available to every operator (even those who only have their own tasks) until one of the operators opens the task and thus receives the task responsibility. See also Transaction responsibility for in-house ordering.

Best Practice Only prohibit closure

"I'll tell my colleague" unfortunately too often leads to forgotten orders and thus to unhappy guests (even worse, of course, is not taking the order). Our recommendation for service operations is therefore access to all tables in conjunction with Closing of other people's tables forbidden.... This allows all operators to take orders and enter them directly into the POS system.

By prohibiting the closing of other tables, only the operator with transaction responsibility can settle the table and, together with the guests, will be able to easily notice unauthorised overbooked items. With the booking details function, a responsible operator can quickly recognise at any time if incorrect bookings have been made in this way in his process and clarify this directly with the executing colleague. With the table transfer function, he can even post the bookings back to the colleague.

The operators then regulate such things among themselves and the stress of such manoeuvres will soon be a thing of the past with a well-adjusted hypersoft system.

Fraud Protection Logging External Access

If an operator opens an operation for which he is not responsible and does not make a booking (which would indicate this), this access is logged. Operators with process responsibility can then see these accesses listed in their user account (and user overview in the front office) in the area External access to my processes.

This function is used for fraud protection and clarifies misunderstandings when another operator settles a transaction without "closing this transaction in his name".

The list distinguishes between open transactions and completed transactions: