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

Basic principle

A transaction contains postings and is settled on completion.

If several operators are working on a system, it must be clearly regulated who is responsible for a process - the so-called process responsibility. Without this rule, it can happen that another operator posts items to another operator's transactions, enters sales twice or settles a transaction including tips for himself.

Technical implementation in Hypersoft POS

In the Hypersoft standard, the operator who opens and posts a transaction automatically receives the transaction responsibility.

You can define the user authorisations:

whether other operators are allowed to post to a colleague's processes, and
whether other operators are authorised to complete (settle) these transactions.

The change operator function can be used to transfer responsibility for the process to another operator if required.

Processes from in-house ordering and 3rd party systems

In the case of processes from in-house ordering or from 3rd party systems (e.g. online or app orders), there is often no operator assigned as defined by Hypersoft POS.

Such processes are therefore initially available to all users, including those who are normally only allowed to see their own processes.

However, as soon as an operator opens the process, they automatically assume responsibility for the process.

Further details on this can be found in the chapter on Transaction responsibility for in-house ordering.

Best practice: Only prohibit the conclusion of third-party transactions

In practice, the following arrangement has proved particularly effective:

Best practice: Only prohibit the closing of third-party tables - not ordering!

"I'll tell my colleague..." - sounds harmless, but in practice it regularly leads to forgotten orders, annoyed guests and lost sales. Even worse: sometimes the order is not even accepted.

But why should a guest even need to understand which employee is responsible for which table? For him, the only thing that counts is that ordering is a positive thing - it brings sales, experience and enjoyment.

In fact, this usual restriction often means that the system itself sabotages the service: the "responsible" colleague is not available at the moment, others are not allowed to order, the guest waits - and in the worst case, does not order at all. That is neither hospitable nor economically wise.

✅ Our recommendation for service operations:

Allow all operators to order on each table. Only prohibit the closing of third-party tables. Our recommendation for the service operation is therefore the settings Access to all tables in connection with Closing of other people's tables forbidden....

This is how it works:

Each waiter can book new items on tables at any time.
Only the operator with transaction responsibility (i.e. the employee originally assigned) is authorised to bill the table.
This automatically recognises unclear bookings using the "Booking details" function.
Incorrect bookings can be clarified directly with the colleague and returned via "table transfer".

The advantage:

Guests receive prompt service, sales flow faster - and potential errors are not blocked by technology, but recognised and resolved by people in the system.

A Hypersoft system configured in this way takes the pressure off the service team, protects against fraud - and improves team morale at the same time. There is another risk in this context that you can eliminate:

Fraud protection: Log external access

This function is used for fraud protection and clears up misunderstandings if another operator views a transaction in order to bill it without "finalising this transaction in their name".

Transparency is crucial in a well-organised operation - especially when several operators have access to the same tables. Hypersoft therefore protects you with automated logging of all unauthorised access:

If an operator opens a process for which they are not responsible and does not make a booking (which would legitimise access), this access is automatically documented. These accesses are visible to the responsible operator in their own operator accounting and in the operator overview in the front office - in the area: External accesses to my processes

The list distinguishes between open transactions and completed transactions:

This means that misunderstandings can be cleared up quickly - for example, if a colleague wanted to view a table in order to bill it himself, either accidentally or deliberately.

The display also differentiates:

Open processes: The table is still active.
Completed processes: The table has already been completed.

This function is a silent but effective component of Hypersoft Fraud Protection - particularly valuable in companies with changing responsibilities or a large team.

Logged external access in the Report Manager...