Receipt sequences creation
In the chapter Single receipt creation, the creation of single receipts using either implicit and/or explicit flow has been described.
In this chapter, we will describe how to connect those single receipts to receipt sequences to integrate complex business cases.
Why and when is this needed?
Suppose orders, delivery notes, invoices and payments are being processed at different times, and the electronic recording system processes the business action not as a whole but in separate processes.
In that case, the business activities and other activities must be traceable in their creation and processing, and a unique identification number for the business action must exist. The same applies if different electronic recording systems are used in the course of the business action.
More details on the legal basis you can find here.
Referencing previous actions within a queue
Use case examples
- Multiple (long lasting) transactions/orders/consumptions before payment is made (gastronomy, ...)
- NFC-based/membership-based order solutions (e.g. accommodation/wellness, employee cards)
- Down payments
How to use
Connect requests representing a business action with 'cbReceiptReference'.
Workflow example
(Two friends are having a beer in a bar. Because it is good German beer, they are ordering another one. They pay with one bill.
Code examples
Code examples of receipt sequences can be found in our Postman collection.
Splitting actions
Use case examples
- pos-receipt(s) paid by multiple people
- Voiding/cancelling receipts
- Correction of orders (f.e. gastronomy)
How to use
Use 'cbReceiptPreviousReference' to point to a 'cbReceiptReference' of a previous request to split or void a receipt.
Workflow example
Two friends are having a beer in a bar. Each of them is paying his own consumption. Therefore, the receipt has to be split.
Code examples
Code examples of splitting receipts can be found in our Postman collection.
Merging actions
Use case examples
- invitation
- if you need to invoice more than one purchase receipt at a time/it can be paid all together
How to use
Merge receipts by combining 'cbReceiptReference' and 'cbReceiptPreviousReference'. Use ftReceiptCase 'Info-internal' to create a new 'cbReceiptReference' and refer via 'cbPreviousReceiptReference' to the order you want to merge. Repeat this for each order you want to merge using the same 'cbReceiptReference' and using 'cbPreviousReceiptPreference' to point to the order to be merged.
Workflow example
Two friends are having a beer in a bar. One of them has birthday. To celebrate that, he invites the guests on the table next to them to pay what they have ordered and consumed so far. Therefore, their receipt has to be merged with the other receipt.
Code examples
Code examples of merging receipts can be found in our Postman collection.
Changing the area in which the receipt is created
Use case examples
Changing the area of value creation; e.g.
- Consumption in Restaurant-Hotel -> Restaurant-Wellness -> Bar-Sauna
- Moving between different tables within a Restaurant
- Providing information how business actions are connected to each other across multiple POS-Systems
How to use
Document the field/section in which the receipt is created with cbArea.
Workflow example
Two friends are having a beer in a bar on a big table. They change to a smaller table so that a bigger group of people can sit on their previous table to order some food.
Referencing actions of external queues or external Systems
Use case examples
Multiple POS-Systems are involved in the business action and only one of them is used for invoice/receipt creation, e.g.:
- Restaurant/Bar using multiple queues; orders are done with one queue and payment with another queue
- Restaurant/Wellness/Hotel using different POS-Systems; one system is used for final invoice creation
- Membership cards/vouchers with multiple POS-Systems involved
Option A: ChargeItems collected via "internal" queue are payed at an external system or queue
How to use
ChargeItems are collected via ftReceiptCase 'Info-internal' or 'Info-order'. 'cbArea' can be used as an identifier for documenting the business action across multiple POS-Systems. The obligation to issue receipts arises at the external POS-System.
Workflow example
A couple checks-in in a hotel for one night. They have a beer at the hotel bar, which uses a different POS-System than at the reception. The couple wishes the consumption to be paid via accomodation invoice at checkout. Therefore, an 'info-internal' is used instead of a 'POS receipt'. 'cbArea' is used to provide the information about the connected business action using the room number as unique identifier.
Option B: ChargeItems collected at an external system or queue are payed at the internal queue
How to use
Use 'info-internal' with 'ftReceiptCaseData' according to the requirements of the DSFinV-K-specification to reference to an business-action recorded by an external queue or POS-System which needs to be merged with your ongoing internal business-action. By creating a new 'cbReceiptReference', you create the precondition to merge the receipt the external system with your internal receipts of the ongoing business-action. Repeat this step to collect and reference to multiple external POS-Systems with related business-actions to be charged. The obligation to issue receipts arises at the POS-System where the POS receipt is being created.
Prerequisites
For this workflow, the combination of following receipt-sequences is needed:
- Referencing previous receipts within a queue, using 'cbReceiptReference',
- Merging receipts, using 'cbReceiptreference' and 'cbPreviousReceiptReference',
- Providing additional information about how the business actions are connected to each other, using 'cbArea',
- Providing information about the external POS receipt, using 'ftReceiptCaseData'
Workflow example
- A couple performs a check-in at the reception of a hotel for one night.
- An info-order for the overnight-stay is created.
- After the check-in, it decides to have a beer at the hotel-bar, which uses a different POS-System (or fiskaltrust.queue). The consumption of the hotel-bar shall be paid with the final invoice of the overnight-stay. The room number is for 'cbArea' to provide information why the business actions across the different POS-Systems are connected.
- For the check-out, the receipt of the consumption of the hotel-bar and the receipt of the overnight stay need to be merged. Therefore, 'info-internal' receipts with a new, common 'cbReceiptReference' are created. One 'info-internal' receipt is used to reference to the external POS receipt using 'ftReceiptCaseData'.
- The other 'info-internal' receipt is used to reference to the internal 'info-order' of the overnight-stay using 'cbPreviousReceiptReference'.
- A 'POS receipt' is created, including all collected charge-items from external and internal POS-System(s), and the pay-items of the internal POS-System. The receipt is printed and handed over to the couple.
Code examples
Code examples of referencing external receipts can be found in our Postman collection.
Money substitutes based sequences (vouchers, membership cards,...)
Issuing and redeeming multi-purpose vouchers/cards
Use case examples
- Consumption in Hospitality/Wellness/Spa with cards/bracelets
- Use of employee cards in cafeteria/canteen
- Multi-purpose vouchers
How to use
Issuing and redeeming a multi-purpose voucher can be achieved with charge- and payitems or within payitems only as shown in following examples in the Postman collection.
Workflow
A customer at Club Med charges his bracelet with 100 €, which is used within the club area as a money substitute. Multiple consumptions are made using different POS-Systems. Each POS-System uses its own different POS receipt IDs, and 'cbArea' is changing as well. At check-out, the customer is getting paid out the remaining credit on the bracelet.
In this example, we are using the payitem option for managing the multi-purpose voucher transactions. A negative amount of 'ftPayItemCase' 0x444500000000000D gets converted to a multi-purpose voucher purchase. 'ftPayItemCaseData' is being used to add the additional information of the use of the NFC-bracelet (e.g."NFC-bracelet NR. 321"). In this case, the NFC-bracelet can be used as identifier across multiple involved POS-Systems.
After charging the bracelet, the customer redeems the voucher in several cases. A positive amount of 'ftPayItemCase' 0x444500000000000D gets converted to a multi-purpose voucher redemption. The negative amount of payment indicates the credit available after the redemption.
In the last business action, the customer wants to have his credit payed out. The positive amount of 'ftPayItemCase' 0x444500000000000D is set to the actual credit value so that the payment amount is zero.