Hypersoft procedure with tip bookings

In general, Hypersoft recommends booking all tips, both cash and non-cash. Through the Hypersoft Pay System, non-cash tip bookings can be largely automated. But the recording of cash tips also has advantages: you do not have to separate this income from the others, or you can prove this share in the case of a cash register inspection and it can be deducted. In addition, you receive evaluable tip information for your operation and per operator, which can be an important KPI for quality control.

Further documentation: Book a tip

tip bookings

Tip entries are recorded in the Hypersoft // system like all other entries and are also signed.

Further documentation: Accounting journal, logic and filing from a fiscal point of view

With the function Remaining amount is tip, the tip is already known when the voucher is created and is also posted in the standard.

Treatment of Tip Subsequent

By default, customers ask for a bill and then pay a tip later. When (in Germany) customers are presented with a billing document, this has been signed beforehand. If a customer then pays a tip, the signature must be counter-booked and re-signed with the new payment. For this purpose, Hypersoft has developed the Tip function retrospectively.

Payment database...

 

Payments are stored in the payment database. Item bookings in the booking journal. The original bookings are retained and are counter-booked with a congruent set of bookings and the number (NH_GVNO+1). This neutralises the original booking. Subsequently, new payment records containing the tip are posted again under the (NH_GVNO+2):

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

A record is added to the existing transaction (TransactionID) in the journal. (Tip Subsequent with the sum), this sum 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 signature.

ID 30 _ NH_GVNO = 2 the New Signing including the tip.

 

In the info table, the process (Tip Subsequent) is documented:

Status = 21 = Tip retrospectively

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

DblVal1 = Total of the tip

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

Tip retrospectively on transactions without signature

For example, a transaction cannot be signed due to TSE failure. The TSE failure is provided for in the TSE system according to precise conditions. If a tip is subsequently given on a transaction that is not signed, for example due to technical problems, the tip is not subsequently signed on this transaction because the original signature is not present. The entries in the journal and in the payment data are posted in the standard.

Change journal export tip retroactively and payment type

The processing of a transaction by tipping afterwards is mapped in the export. The unique consecutive TransactionID from Hypersoft is used as the Receipt_ID in the export. The Receipt_ID contains (from SP 16) the number of the respective work step:

The receipt ID 620123 thus becomes 620123-00 (-00 is the original transaction here).

If a tip is booked subsequently, 2 further processing steps are always logged for the transaction.

-01 is the "credit" of the original operation -00

-02 then maps the complete process after adding.

Further subsequent changes then result in "-03" & "-04" etc.

Change during export...

Change receipts and payments are not recorded in our turnover journals but in a separate database. Thus, it is now not possible to export the "Receipt_ID" numerically consecutively.

We use the "ID" from the change database here and add to this value

2000000000 ( 2 billion )

The "BON_ID" from the change thus forms its own number range (over 2 billion), which is then continuous in itself.

Warning against mishandling tip bookings

Train your staff to make the bookings as promptly as possible and according to the actual situation. Not allowed are for example:

  • Post subsequent tip entries on any transaction.

  • Collect subsequent tip entries and post them cumulatively to one transaction.

  • Post tip entries to a separate transaction that is not the associated payment transaction.

These wrong practices lead to tips no longer being traceable. For tips to be tax-exempt in Germany, there must be a relationship between the giver and the recipient (who must not be the owner).

Extensions and corrections

With Hotfix 7 from 16.01.2024, the tip function was subsequently optimised in conjunction with the TSE. Equivalent tips that have been entered twice can now be traced more easily.

Further documentation: Change Hypersoft procedure for payment type

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