Change Hypersoft procedure for payment type

The Hypersoft system has the functions Change payment method and Modify payment method. Both act in the same way in the sense of this description. Changing payment types is carried out by the POS system or the (technically identical) subsystem of an mPOS system, so the description Change payment type refers to both terms. Changing a payment method often occurs, for example, when you present a customer with an invoice in standard cash and the customer then pays cashless. Even if the operator knew that the customer (in full service at the table) would like to pay cashless, he cannot present him with a complete payment receipt, since the payment method (giropay, Mastercard, etc.) is not determined until the actual cashless payment and, for security reasons, the payment is usually booked automatically in the payment terminal.

Examples of signings from full-service practice

An example of change payment method:

  1. A customer asks for the invoice in the full service. TSE is signed, receipt created.

  2. When the bill is presented at the table, the customer says that they would like to pay without cash. The operator informs that he is now fetching the payment terminal.

  3. The operator uses the Change Payment Type function because the item entries no longer change. The payment receives a counter entry (cancellation) because the cash payment was not made.

  4. The payment is completed again, but this time to cashless payment. In our example with a connected payment terminal with the payment in the background variant.  The TSE signing is done on non-cash so that a receipt can be generated.

  5. For the guest, the payment is made cashless incl. tip, the TSE signature is counter-booked, a new TSE signature is made as a non-cash payment incl. tip. The transaction still available via the special method when paying in the background receives the tip payment as a booking. The tip is booked in the payment with the total amount to the corresponding /scheme and the new payment voucher is created.

In the case of a client who has been involved in step II. paid separately, individual transactions are then completed according to the individual payments.

Comparison example, in which not only the payment is updated with process, but also all other bookings:

  1. A customer asks for the invoice in the full service. TSE is signed, receipt created.

  2. When the bill is presented at the table, the customer says that they would like to pay without cash. The operator informs that he is now fetching the payment terminal. The customer takes the opportunity to order 3 coffees.

  3. The operator must process the operation as 3 coffees are now added. When editing, the signatures are counter-booked. The Hypersoft system must post (cancel) all the items because the process is reopened. The payment also receives an offsetting entry (cancellation) because the cash payment was not made.

  4. The operation is completed again on Cashless Payment. In our example with a connected payment terminal with the payment in the background variant. In order for a receipt to be created, the TSE first signs the payment as "non-cash" (the TSE does not know the exact card payment).

  5. At the guest's the payment is made cashless, the bookings including tip are booked, the TSE signature of the payment is counter-booked again so that a new TSE signature of the payment including tip can be created on non-cash, the payment is booked with the total amount on the corresponding /scheme and the new payment voucher is created.

The customer could also tip in cash and this can be added afterwards.

Further documentation:

Hypersoft procedure for payment terminals

Hypersoft procedure with tip bookings

Process from a fiscal point of view

Change payment database for payment type

The original (original) entries are retained and are counter-posted with a set of entries and the number (NH_GVNO+1) to neutralise the value of the original entry. A new payment record with the updated payment type is then posted again under the (NH_GVNO+2):

 

The transaction database receives this NH_GVNO number as the current NH_GVNO number:

In the journal, a record is added to the existing transaction (TransactionID), (Tip Subsequent with the corresponding sum) this receives the new NH_GVNO number:

In the AddOn table, the signature is stored for the respective NH_GVNO numbers:

ID 28 - NH_GVNO = 0 the original signature

ID 29 - NH_GVNO = 1 the neutralisation (cancellation) of the original signing.

ID 30 _ NH_GVNO = 2 the new signature with the new payment type.

The Info Table documents the process (Modify Payment or Change Payment Type):

Status = 20 = Change payment type

Status= 23 = Modify payment

IntVal1 = Date of the action

IntVal2 = Time of the action

IntVal3 = SigTransNo from the TSE for signing neutralisation

IntVal4 = SigTransNo from the TSE for the new signature

DblVal3 = TSE ID of neutralisation (belongs to IntVal3 TSE unit of neutralisation).

DblVal4 = TSE ID of re-signing (belongs to IntVal4 TSE unit of re-signing)

NH_GVNO = Business transaction number

Edit payment database and journal for transaction

Transaction database:

After reopening the transaction, a credit note is created and the items are counter-booked. There is therefore an original transaction and an offsetting transaction. Both processes are marked with mutual reference in the RefID column. The process is now back in the system as an open process and this is inserted again after completion:

Payment database:

After reopening, the credit note is also generated in the payment and then a payment data record is generated again when the transaction is completed again. In this case, a tip was added and the transaction was completed on credit:

Chaining for traceability of the actual conclusion....

If the Hypersoft system offsets transactions, the question arises during checks as to whether (and where exactly) the transaction was actually completed. From the programme concept, the process must be completed again, here we show the chaining of these processes for traceability.

In the journal, the entries are cancelled accordingly and posted again. For the second operation, the NH_RefID column shows which operation was the origin. The tip that was subsequently booked is also visible, as it does not include NH_RefID.

The InterfaceRef_from_D_Trn column is shown here only informatively. The values are in the D_Transaction table:

In the AddOn table, the signing of the individual operations is saved:

Further documentation:

Payment type Modification report

Fraud Protection with Hypersoft Trace

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