Hypersoft procedure with SOT

Self Order Kiosk (SOT) fiscal requirements

The Hypersoft Self Order Kiosk SOT programme is used for self-service terminals as described in theeSolutions Self-Order Kiosk (SOT). In principle, the descriptions in the chapter Hypersoft process with eSolutions also apply to the SOT. The connection at the POS is carried out including TSE signing and output of the bookings during the KassenSichV Export according to DSFinV-K Signing takes place when the payment is called up and transferred to a payment terminal.

Since the users themselves book at the SOT, not everything that is typed at the SOT is always and immediately logged. However, if an order is transmitted to the POS system, it is securely stored (in Germany also TSE signed, in Austria also RKSV secured). Nevertheless, the Hypersoft POS system offers all the possibilities of reversal and trace to handle errors and misunderstandings from customers in such a way that everything remains traceable. However, when a guest calls up cashless payment, it must be assumed that the order has been completed. Now the bookings must be saved so that the payment can be triggered at the payment terminal. However, due to this special situation, the order receipts are still being held back until the payment has actually been made. The moment the payment is positively confirmed, the bookings are immediately forwarded to the production units such as kitchen and bar. If the situation arises that the payment does not take place (rejection by the computer centre or cancellation by the userClosed As users we call people who operate programs, in our case mostly the users of the MCP and the contained programs.), the transaction must be counter-posted with the status cancellation before order. You will then receive Reversal before Order entries in the evaluations to meet the tax requirements. Below you will find further details and technical background information.

TSE, RKSV and unpaid SOT transactions...

SOT transactions are stored in the cash journal and thus also signed with the TSE or the RKSV required in the standard. Unpaid SOT transactions are available to the POS system, these bookings and their cancellations are also signed in the TSE.

Exception Operation Abort At the SOT...

By default, a transaction termination is signed and exported at a Hypersoft POS system. Contrary to what is described under transaction termination in the rules, such bookings (as bookings by users) are not signed at the SOT and are not exported. The SOT has a timer and asks "if a userClosed As users we call people who operate programs, in our case mostly the users of the MCP and the contained programs. is still there at the SOT" when it expires:

After another timer without input, the SOT "notices" that no users are present and the process is reset. In this case, the transaction is not pre-signed, not cancelled and not counter-booked. Here, the situation is considered like bookings of a userClosed As users we call people who operate programs, in our case mostly the users of the MCP and the contained programs. in the webshop, since there, too, not owners or employees, but customers, guests or users make the bookings, so that no fraud motive is causal or conceivable. In practice, such "fun bookings" occur regularly, which would otherwise unnecessarily burden and distort the TSE system and the export.

Special feature: Payment termination at the SOT...

When bookings are sent to the payment terminal at the SOT, the system acts in the standard way as described with payment terminals in the foreground. For this purpose, an open transaction is created in the POS system when the payment order is transferred to the payment terminal. If the payment can be made, then the entries and the payment are signed and the receipt can be created. If the payment order is cancelled at the payment terminal or cannot be booked, the userClosed As users we call people who operate programs, in our case mostly the users of the MCP and the contained programs. receives a query at the SOT:

  1. If you try again, the payment order is transmitted to the payment terminal again. The open transaction at the POS system is then already available.

  2. If you select Pay at checkout, the transactions are signed and the open transaction is waiting to be processed or paid at the checkout.

  3. With Cancel order all bookings in the transaction are cancelled as a cancellation before order, then the bookings and the transaction are signed, this all then results in 0,- (0). Further documentation: Changeover of the cancellation level with SP 16...

Unpaid SOT transactions with status payment at POS

In this context, it happens that users complete transactions with the status payment at the checkout, but the transaction is never completed and paid because they do not go to the checkout with the receipt. There are solutions for this case: Of course, you can switch off the payment option at the checkout. Otherwise, there are settings for the transaction number range of the SOT, if it started with 900000, all unpaid transactions from there upwards should come from the SOT. You can cancel this and close it.

This activity can be automated as usual: Automate best practice day-end closing. The unpaid and therefore open SOT transactions are treated as table transactions and booked out as required at the end of the day.

If you trigger the order before payment as described above and losses are incurred as a result, you can also have these losses booked automatically before the transaction is cancelled. Otherwise, automatic cancellations before order are sufficient to complete the transaction.

Cancel payments from the SOT (Refund)

SOT payments are usually cashless payments made with a payment terminal by the customer in a self-service situation. For post-processing (cancellation or refund, or repayment to the customer), Hypersoft offers different solutions depending on the payment system. In the standard system, these are described here: Cancel and process cashless payments at the POS

Conversions and error corrections

Changeover of the cancellation level with SP 16...

The automatic cancellation function in the SOT, which is triggered if a payment is cancelled or times out during the payment process, was changed from the status cancellation after order to cancellation before order with SP 16. All previous cancellations of this type are therefore still available as cancellations by order.

Hypersoft process with eSolutions Further documentation:

Back to the parent page: Fiscal Law on the Application Decree on Section 146a AO