Reference tables
This chapter expands on the reference tables covered in the Chapter "Reference tables" of the General Part, with country-specific information applicable to the Austrian market.
Service Status: ftState
The table below describes it supported statuses for the ftState field following the Austrian law. The ftState from this reference table and the general part of this documentation can be combined through the logic operator "OR". For example 0x4154000000000010 (monthly report due) and 0x4154000000000008 combined through OR results in 0x4154000000000018.
The country-specific code is made of the country's code value following the ISO-3166-1-ALPHA-2 standard, converted from ASCII into hex. For Austria (AT) this is 0x4154, which results in 0x4154000000000000 as the value for the "ready" status.
| Value | Description | Middleware-Version |
|---|---|---|
0x4154000000000001 | "out of service" No RKSV signatures are generated or sent back. No RKSV-DEP is written, as nothing is being signed. The E131-DEP records requests and responses. | 1.0 |
0x4154000000000002 | "SSCD temporary out of service" For at least one receipt, it was not possible to receive the signature from an allocated SSCD. Thus, the security mechanism has been put into "signature creation device out of service" mode. Regardless of whether an allocated SSCD is available again or not, the mode remains in place until, via zero receipt, all previous receipts can be signed. If this mode is activated, an out of service signature, in accordance with the RKSV, is generated and sent back. | 1.0 |
0x4154000000000004 | "SSCD permanently out of service" The status "SSCD temporary out of service" was activated more than 48h ago. Thus a FinanzOnline notification has been generated. For conduct and termination of this mode, see "SSCD temporary out of service". | 1.0 |
0x4154000000000008 | "subsequent entry activated" At least one receipt has been transferred with a subsequent entry flag. In order to finalize the subsequent entry and leave the mode, it is necessary to generate a zero receipt. This zero receipt signs and secures the preliminary receipts accordingly to the RKSV. | 1.0 |
0x4154000000000010 | "monthly report due" If the latest monthly or annual report are is in the current month, the service will signal this. This status does not impact the signature conduct of the service; it is merely an indicative notification. | 1.0 |
0x4154000000000020 | "annual report due" Same conduct as for "monthly report due" | 1.0 |
0x4154000000000040 | "message / notification pending" A status message and/or FinanzOnline notification is ready for collection. Using a zero receipt, the messages can be retrieved and archived or processed in bookkeeping. | 1.0 |
0x4154000000000080 | "backup SSCD in use" The receipt was signed by a signature creation unit configured for backup use. | 1.1.17248 |
Table 21. Service status: ftState for AT - RKSVO
Type of Receipt: ftReceiptCase
The ftReceiptCase indicates the receipt type and defines how it should be processed by the fiskaltrust.SecurityMechanism in accordance with the Austrian law.
For Austria (AT) the country code is 0x4154. Thus, the value for an unknown ftReceiptCase in Austria is 0x4154000000000000.
| Value | Description | Middleware- Version |
|---|---|---|
0x4154000000000000 | "unknown type of receipt for AT" This receipt is processed like a cash transaction with RKSV requirement. | 1.0 |
0x4154000000000001 | "Cash transaction with RKSV requirement for AT" The fiskaltrust decision tree is being run through, and, if needed, the signature process is started and the cumulative counter adjusted respectively. An example of a signature being needed is an "other service" paid for with a "credit card". An example of a case where no signature is needed is a receipt with only "no own sales" on it which has been paid for by "credit card". | 1.0 |
0x4154000000000002 | "zero receipt" Charge items block (ftChargeItems) as well as pay items block (ftPayItems) are empty. The "zero receipt" can be used to test operability by collecting a service status notification, such as an out-of-service notification for FinanzOnline. | 1.0 |
0x4154000000000003 | "initial operation receipt" The request is only valid as a zero receipt. The initial operation procedure is started. When using fiskaltrust.SecuritymMechansimsPlus, the receipt will also be checked for correctness. | 1.0 |
0x4154000000000004 | "out of operation receipt" The procedure to take the service out of operation is started. The request is only valid as a zero receipt. When using the fiskaltrust.Carefree package, the receipt will also be checked for correctness, and the notification to the "FinanzOnline" will be performed automatically in the background. | 1.0 |
0x4154000000000005 | "monthly receipt" The procedure for the creation of the monthly receipt is started. The request is only valid as a zero receipt. | 1.0 |
0x4154000000000006 | "annual receipt" The procedure for the creation of the annual receipt is started. The request is only valid as a zero receipt. When using the fiskaltrust.Carefree package, the receipt will also be checked for correctness, and the notification to the "FinanzOnline" will be performed automatically in the background. | 1.0 |
0x4154000000000007 | "cash transaction RKSV relief or cash revenue law" This is used to process cash transactions which do not have an RKSV requirement (e.g. emptying a vending machine). | 1.0 |
0x4154000000000008 | "target business" An outgoing invoice which does not necessarily have to be issued by a cash register but can also be issued by an invoicing system. | 1.0 |
0x4154000000000009 | "delivery note" Information about an internal or external delivery or also a transfer into a different IT system. The sales tax statement is issued through the outgoing invoice or in the other system. | 1.0 |
0x415400000000000A | "cash deposit" For example the payment of a target calculation, or deposit on the customer card. Usually, the receipt data only includes pay items while the charge items block remains empty. Since the total amount must always be zero, you must use a negative pay item to balance the sum of pay items to zero. | 1.0 |
0x415400000000000B | "cash pay-out" For example to pay for deliveries . | 1.0 |
0x415400000000000C | "means of payment transfer" For example the switching between "cash", "credit card", "ATM", etc. This function is also used to issue vouchers. | 1.0 |
0x415400000000000D | "protocol" Simple protocol function. The data sets that need to be logged can be transferred in the field ftReceiptCaseData in manufacturer-specific JSON format. For example, opening the cash drawer or changing master data. | 1.0 |
0x415400000000000E | "Internal / material consumption" For example recording breakages or own consumption. | 1.0 |
0x415400000000000F | "sales in an online shop, telephone-/fax orders" Through the cash revenue law, sales from online shops and similar are exempted, even if these have been paid by credit card or comparable means of payments with RKSV requirement but not paid on business premises. As a cash transaction, the issued receipt comes with a recording requirement in accordance with §131 BAO and needs to be processed in bookkeeping. | 1.0 |
0x4154000000000010 | "foreign sales" Foreign sales do not have an RKSV-requirement. To be used when something sold in an other country. As a cash transaction, the issued receipt comes with a recording requirement in accordance with §131 BAO and need to be processed in bookkeeping. Foreign requirements, for example in connection with receipt generation or cash register requirements, have to be taken into account. | 1.0 |
Table 22. Type of Receipt: ftReceiptCase (AT - RKSVO)
ftReceiptCaseFlag
This table expands on the values provided in the table "Type of Receipt: ftReceiptCaseFlag" of with values applicable to the Austrian market.
| Value | Description | Middleware-Version |
|---|---|---|
0x0000000000010000 | "out of service" The transferred receipt contains data which has been created during an outage of the security mechanism. The original receipts are available in handwritten or digital format and must now be transferred and subsequently consolidated and signed via zero receipt. In order to decide whether it is a temporary or permanent (more than 48 hours) outage of the security mechanism (for example in case of theft), the "oldest" or the receipt with the earliest date/time value of all retrieved receipts is used. This can be necessary, for example, after a power or server outage. | 1.0 |
0x0000000000020000 | "training receipt" Requests with this type of receipt are annotated with the reference "TRA" in the signature block. Instead of the encrypted cumulative sales counter, the BASE64 encrypted value of the TRA string is entered. The sales counter is, in accordance with the RKSV, not adjusted. | 1.0 |
0x0000000000040000 | "reverse receipt" Requests with this type of receipt are annotated with the reference "STO" in the signature block. Instead of the encrypted cumulative sales counter, a BASE64 encrypted value of the STO string is entered. Further processing depends on the underlying type of receipt. | 1.0 |
0x0000000000080000 | "handwritten receipt" or "subsequent entry" The transferred receipt contains data which has been collected in a handwritten receipt. Although there is no requirement for a time annotation on a handwritten receipt we recommend using 12:00 for this purpose. Further processing depends on the underlying type of receipt. For example, this can be conducted after §7 cash revenue law for sales made outside business premises. | 1.0 |
0x0000000000100000 | "small business, sales tax relief in accordance with §6 Abs 1 Z 27 UStG (sales tax law)" The transferred receipt contains data which have been generated by a small business. A special note "sales tax relief in accordance with §6 Abs 1 Z 27" is possible. The RKSV requirement is handled according to the basic business transaction. The transferred receipt data should contain the correct VAT rate and the correct ftChargeItemCase, even if the identified sales tax is 0%. | 1.0 |
0x0000000000200000 | "receiver is a company" The transferred receipt contains a sales receipt, and the receiver is a trader. Note regarding the characteristics of §11 UStG: for receipts with up to €400 gross amount, an invoice for small amounts can be issued. From €400 onwards, there are additional features to be displayed on the invoice, to enable the pre-tax deduction for the receiver of the invoice. For receipts with a gross amount of €10.000 or more, in addition, the service receiver’s UID number has to be indicated. We suggest transferring the data about the receiver in the field ftReceiptCaseData, in manufacturer-specific JSON format. | 1.0 |
0x0000000000400000 | "contains characteristics in accordance with §11 UStG" On the receipt, the characteristics are issued in accordance with §11 UStG, and the transferred receipt contains receiver data in manufacturer-specific JSON format within the field ftReceiptCaseData. | 1.0 |
0x0000800000000000 | Receipt request. Common behaviour. |
Table 23. Type of Receipt: ftReceiptCase Flags(AT - RKSVO)
Type of Service: ftChargeItemCase
This table expands on the values provided in the table "Type of Service: ftChargeItemCase" with values applicable to the Austrian market.
| Value | Description | Middleware-Version |
|---|---|---|
0x4154000000000000 | "unknown type of service for AT" With help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms, an allocation to normal /discounted-1 /discounted-2/zero is attempted. | 1.0 |
0x4154000000000001 | "undefined type of service for AT discounted-1" (as of 1.7.2016, this is calculated with 10%). | 1.0 |
0x4154000000000002 | "undefined type of service for AT discounted-2" (as of 1.7.2016, this is calculated with 13%). | 1.0 |
0x4154000000000003 | "undefined type of service for AT normal" (as of 1.7.2016, this is 20%). | 1.0 |
0x4154000000000004 | "undefined type of service for AT special" Includes all rates which are not contained in the previous ones (as of1.7.2016, this can be for example 12% or 19%). | 1.0 |
0x4154000000000005 | "undefined type of service for AT zero" Includes data which is indicated with 0% sales tax and also data where the sales tax is unknown, for example in a reference to an outgoing invoice. Also in cases where the sales tax should not be apparent, for example in the case of differential taxation, the data can be issued with this code. | 1.0 |
0x4154000000000006 | "reverse charge" Reversal of tax liability. These can e.g. include construction works, mobile phones from € 5.000,-, services abroad, etc. | 1.0 |
0x4154000000000007 | "not own sales" In the data, a VAT-rate can be indicated, whereby the gross amount according to the RKSV always has to be recorded in the signature field, set zero. | 1.0 |
0x4154000000000008 | "delivery discounted-1" For processing, see (0x4154000000000001) | 1.0 |
0x4154000000000009 | "delivery discounted-2" For processing, see (0x4154000000000002) | 1.0 |
0x415400000000000A | "delivery normal" For processing, see (0x4154000000000003) | 1.0 |
0x415400000000000B | "delivery special" For processing, see (0x4154000000000004) | 1.0 |
0x415400000000000C | "delivery zero" For processing, see (0x4154000000000005) | 1.0 |
0x415400000000000D | "other services discounted-1" For processing, see (0x4154000000000001) | 1.0 |
0x415400000000000E | "other services discounted-2" For processing, see (0x4154000000000002) | 1.0 |
0x415400000000000F | "other services normal" For processing, see (0x4154000000000003) | 1.0 |
0x4154000000000010 | "other services special" For processing, see (0x4154000000000004) | 1.0 |
0x4154000000000011 | "other services zero" For processing, see (0x4154000000000005) | 1.0 |
0x4154000000000012 | "catalogue services discounted-1" For processing, see (0x4154000000000001) | 1.0 |
0x4154000000000013 | "catalogue services discounted-2" For processing, see (0x4154000000000002) | 1.0 |
0x4154000000000014 | "catalogue services normal" For processing, see (0x4154000000000003) | 1.0 |
0x4154000000000015 | "catalogue services special" For processing, see (0x4154000000000004) | 1.0 |
0x4154000000000016 | "catalogue services zero" For processing, see (0x4154000000000005) | 1.0 |
0x4154000000000017 | "own consumption discounted-1" For processing, see (0x4154000000000001) | 1.0 |
0x4154000000000018 | "own consumption discounted-2" For processing, see (0x4154000000000002) | 1.0 |
0x4154000000000019 | "own consumption normal" For processing, see (0x4154000000000003) | 1.0 |
0x415400000000001A | "own consumption special" For processing, see (0x4154000000000004) | 1.0 |
0x415400000000001B | "own consumption zero" For processing, see (0x4154000000000005) | 1.0 |
0x415400000000001C | "down payment discounted-1" For processing, see (0x4154000000000001) | 1.0 |
0x415400000000001D | "down payment discounted-2" For processing, see (0x4154000000000002) | 1.0 |
0x415400000000001E | "down payment normal" For processing, see (0x4154000000000003) | 1.0 |
0x415400000000001F | "down payment special" For processing, see (0x4154000000000004) | 1.0 |
0x4154000000000020 | "down payment zero" For processing, see (0x4154000000000005) | 1.0 |
0x4154000000000021 | "account of a third party/ third party name/ collection" For processing, see (0x4154000000000007) | 1.0 |
0x4154000000000022 | "obligation with RKSV requirement" Obligations are to be equalized with pay items. If however, it is for technical reasons necessary to transfer obligations in the charge items block, then this code should be used for obligations with RKSV requirement. The gross amount due is recorded in the signature field, set zero, according to the RKSV. For example, a receipt for a voucher issuance, for which the voucher is indicated as item in the charge items block and the corresponding cash amount is indicated in the pay items block. An example for this would be a voucher intake via charge items block, or a payment of an outgoing invoice. | 1.0 |
0x4154000000000023 | "obligation without RKSV requirement" Obligations are to be equalized with pay items. If however, it is systematically necessary to transfer obligations in the charge items block, then this code should be used for obligations without RKSV requirement. The gross amount due is recorded in the signature field, set zero, according to the RKSV. For processing, also see (0x4154000000000007). | 1.0 |
Table 24. Type of Service: ftChargeItemCase (AT - RKSVO)
Type of Payment: ftPayItemCase
This table expands on the values provided in the table "Type of Payment: ftPayItemCase" with values applicable to the Austrian market.
| Value | Description | Middleware-Version |
|---|---|---|
0x4154000000000000 | "default value" unknown payment type: automatic processing through the fiskaltrust.SecurityMechanisms settings is attempted. | 1.0 |
0x4154000000000000 | "unknown payment type for AT" This is handled like a cash payment in national currency. | 1.0 |
0x4154000000000001 | "cash payment in national currency" | 1.0 |
0x4154000000000002 | "cash payment in foreign currency" | 1.0 |
0x4154000000000003 | "crossed cheque" | 1.0 |
0x4154000000000004 | "debit card payment" | 1.0 |
0x4154000000000005 | "credit card payment" | 1.0 |
0x4154000000000006 | "voucher payment (coupon)" | 1.0 |
0x4154000000000007 | "online payment" | 1.0 |
0x4154000000000008 | "customer card payment" | 1.0 |
0x4154000000000009 | "other debit card" | 1.0 |
0x415400000000000A | "other credit card" | 1.0 |
0x415400000000000B | "account receivable" delivery note/ settlement in foreign currency | 1.0 |
0x415400000000000C | "SEPA transfer" | 1.0 |
0x415400000000000D | "other transfer" | 1.0 |
0x415400000000000E | "cash book expense" | 1.0 |
0x415400000000000F | "cash book contribution" | 1.0 |
0x4154000000000010 | "levy" AT: Anzahlung | 1.0 |
0x4154000000000011 | "internal/ material consumption" | 1.0 |
0x4154000000000012 | "change" tip | 1.0 |
Table 25. Type of Payment: ftPayItemCase (AT - RKSVO)
Type of Signature: ftSignatureFormat
This table expands on the values provided in the table "Format of Signature: ftSignatureFormat" with values applicable to the Austrian market.
According to the RKSV, there is one exception: if the fiskaltrust.SecurityMechanism responds with a QR code but the printer, through which the receipt is supposed to be printed (or electronically issued), cannot display QR codes, it is allowed to convert the signature value and display it as bar code, link, or in OCR typeface on the receipt. This requirement and a sample code can be found in the Chapter "Printing of QR-Code not supported".
| Value | Description |
|---|---|
0x00 | unknown / without |
0x01 | Text |
0x02 | Link |
0x03 | QR code (2D code) |
0x04 | Code128 (bar code) |
0x05 | OCR-A (text recognition, Base32 compatible) |
0x06 | PDF417-(2D code) |
0x07 | DATAMATRIX-(2D code) |
0x08 | AZTEC-(2D Code) |
0x09 | EAN-8 (bar code) |
0x0A | EAN-13 (bar code) |
0x0B | UPC-A (bar code) |
0x0C | Code39 (bar code, Base32 compatible) |
Table 26. Type of Signature: ftSignatureFormat (AT - RKSVO)
Type of Signature: ftSignatureType
This table expands on the values provided in the table "Type of Signature: ftSignatureType" with values applicable to the Austrian market.
| Value | Description | Version |
|---|---|---|
0x4154000000000000 | unknown | 1.0 |
0x4154000000000001 | signature according to RKSV | 1.0 |
0x4154000000000002 | Archiving required according to RKSV or BAO §132. E.g. notification of collective receipt after failure, initial receipt, monthly receipt, etc.. | 1.0 |
0x4154000000000003 | FinanzOnline notification | 1.0 |
Table 27. Type of Signature: ftSignatureType (AT - RKSVO)
Type of Journal: ftJournalType
This table expands on the values provided in the table of Chapter "Type of Journal: ftJournalType" of the General part with values applicable to the Austrian market.
| Value | Description | Version |
|---|---|---|
0x4154000000000000 | status information for QueueAT | 1.0 |
0x4154000000000001 | RKSV-DEP-Export | 1.0 |
Table 28. Type of Journal: ftJournalType (AT - RKSVO)
Printing of QR-Code not supported
If no QR code can be issued, it is allowed to place text using OCR typeface onto the receipt. For this procedure, BASE64-coded data fields are displayed in BASE32 according to §11 para. 2 RKSV. This is because the capital "i" and lowercase "L" are not distinguishable from each other in many typefaces.
For example, the following signature value is converted in the way described above. Whereby the following output BASE64 (bold) is:
_R1-AT0_DEMO-CASH-BOX426_776730_2015-10-14T18:20:23_0,00_0,00_0,00_0,00_0,00_0gJTFI8/zqc=_968935007593160625_fP7/PMP-SnQ0=_Xh5wNe0akaTOVvMgLVrCcRh2xmIyP91ogbxc5xv4Rrw64lpQsqLm+1GZxuCz4D1sZl9WCv3wMMoE0p+gyLaufg==
Code 15. Example of OCR output in Base64
The BASE32 display in accordance with the RKSV for this OCR text output in BASE32 (bold) looks as follows:
_R1-AT0_DEMO-CASH-BOX426_776730_2015-10-14T18:20:23_0,00_0,00_0,00_0,00_0,00_2IBFGFEPH7HKO===_968935007593160625_PT7P6PGD2KOQ2===_LYPHANPNDKI2JTSW6MQC2WWCOEMHNRTCGI7522EBXROOOG7YI26DVYS2KCZKFZX3KGM4NYFT4A6WYZS7KYFP34BQZICNFH5AZC3K47Q=
Code 16. Example of OCR output in Base32
This procedure has to be carried out by the cash register or input station itself because the service does not know whether a QR code can be printed or not, and because the data format for DEP storage requires a BASE64 display anyway.
A conversion tool is provided in the class fiskaltrust.ifPOS.Utility.
C# code example Converting to OCR:
string ocr = fiskaltrust.ifPOS.Utilities.AT_RKSV_Signature_ToBase32(qr_data);
Code 17. Example for converting the QR-Code to OCR