diff --git a/doc/middleware-at-rksv/reference-tables/reference-tables-v0.md b/doc/middleware-at-rksv/reference-tables/reference-tables-v0.md new file mode 100644 index 00000000..32ca2191 --- /dev/null +++ b/doc/middleware-at-rksv/reference-tables/reference-tables-v0.md @@ -0,0 +1,247 @@ +--- +slug: /poscreators/middleware-doc/austria/reference-tables-v0 +title: Reference tables v0 +--- + +## Reference tables + +This chapter expands on the reference tables covered in the Chapter ["Reference tables"](../../general/reference-tables/reference-tables.md) 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"](../../general/reference-tables/reference-tables.md#t-type-of-receipt-ftreceiptcaseflag-64) 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"](../../general/reference-tables/reference-tables.md#t-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"](../../general/reference-tables/reference-tables.md#t-type-of-payment-ftpayitemcase-90) 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"](../../general/reference-tables/reference-tables.md#t-type-of-signature-ftsignatureformat-112) 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"](#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"](../../general/reference-tables/reference-tables.md#t-type-of-signature-ftsignaturetype-127) 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"](../../general/reference-tables/reference-tables.md#c-type-of-journal-ftjournaltype-129) 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: + +```nohighlight +_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: + +```nohighlight +_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:** +```cs +string ocr = fiskaltrust.ifPOS.Utilities.AT_RKSV_Signature_ToBase32(qr_data); +``` + + + +*Code 17. Example for converting the QR-Code to OCR* diff --git a/doc/middleware-at-rksv/reference-tables/reference-tables.md b/doc/middleware-at-rksv/reference-tables/reference-tables.md index af8afd65..3fc15278 100644 --- a/doc/middleware-at-rksv/reference-tables/reference-tables.md +++ b/doc/middleware-at-rksv/reference-tables/reference-tables.md @@ -1,247 +1,53 @@ --- slug: /poscreators/middleware-doc/austria/reference-tables -title: Reference tables +title: Reference tables v2 +title: Reference tables v2 --- -## Reference tables - -This chapter expands on the reference tables covered in the Chapter ["Reference tables"](../../general/reference-tables/reference-tables.md) 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"](../../general/reference-tables/reference-tables.md#t-type-of-receipt-ftreceiptcaseflag-64) 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"](../../general/reference-tables/reference-tables.md#t-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"](../../general/reference-tables/reference-tables.md#t-type-of-payment-ftpayitemcase-90) 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 | - - +# Reference tables +This chapter expands on the reference tables covered in [Reference Tables in General Part](../../general/reference-tables/reference-tables.md#reference-tables), with country-specific information applicable to the Austrian market. The respective tables can be found in the following sub-sections. -*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"](../../general/reference-tables/reference-tables.md#t-type-of-signature-ftsignatureformat-112) 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"](#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"](../../general/reference-tables/reference-tables.md#t-type-of-signature-ftsignaturetype-127) 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 | - - +As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for Austrian market. This mapping is based upon the overall tagging system which gives the additional benefit of giving all receipts, chargeitems and payitems also a semantical value. The following section describes the overall format. -*Table 27. Type of Signature: ftSignatureType (AT - RKSVO)* +## Format -### Type of Journal: ftJournalType +Every case that is sent to the middleware, or every Item that is being returned from the middleware is based upon this tagging system. For the tagging system we are using hex based numbers since they make things like, flagging and having a consistend numbering scheme easier. -This table expands on the values provided in the table of Chapter ["Type of Journal: ftJournalType"](../../general/reference-tables/reference-tables.md#c-type-of-journal-ftjournaltype-129) of the General part with values applicable to the Austrian market. +The overall format is built up of 4 sections: -| **Value** | **Description** | **Version** | -|----------------------|--------------------------------|-------------| -| `0x4154000000000000` | status information for QueueAT | 1.0 | -| `0x4154000000000001` | RKSV-DEP-Export | 1.0 | +_4154_2000_0010_0001 -*Table 28. Type of Journal: ftJournalType (AT - RKSVO)* +_CCCC_vIII_gggg_xxxx -### Printing of QR-Code not supported +| **Value** | **Description** | +|----------------------|-----------------------------------------------------------------------------------------------------| +|CCCC|(e.g 4154): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. AT = 4154) | +|vIII|(e.g. 2000): This section is for versioning the tagging system (currently v2) and for future use | +|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will live the overall semantical meaning of a type the same. (e.g. voiding of a receipt)| +|xxxx|(e.g. 0001): The last category is usually case specific but always consists of 4 numbers | -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: + -```nohighlight -_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: +| **Value** | **Description** | +|----------------------|-----------------------------------------------------------------------------------------------------| +|CCCC|(e.g 4154): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. AT = 4154) | +|vIII|(e.g. 2000): This section is for versioning the tagging system (currently v2) and for future use | +|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will live the overall semantical meaning of a type the same. (e.g. voiding of a receipt)| +|xxxx|(e.g. 0001): The last category is usually case specific but always consists of 4 numbers | -```nohighlight -_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:** -```cs -string ocr = fiskaltrust.ifPOS.Utilities.AT_RKSV_Signature_ToBase32(qr_data); -``` - - - -*Code 17. Example for converting the QR-Code to OCR* diff --git a/doc/middleware-at-rksv/reference-tables/service-status-ftstate.md b/doc/middleware-at-rksv/reference-tables/service-status-ftstate.md new file mode 100644 index 00000000..7d29d324 --- /dev/null +++ b/doc/middleware-at-rksv/reference-tables/service-status-ftstate.md @@ -0,0 +1,37 @@ +--- +slug: /poscreators/middleware-doc/austria/reference-tables/ftstate +title: 'Service Status: ftState' +--- + +# Service Status: ftState + +## Format + +_CCCC_vlll_gggg_gggg_ + +#### v - version +version 2 + +#### gggg_gggg - global tagging/flag +| **Value** | **Description** | **Middleware Version** | +|----------------------|-----------------------------------------------------------------------------------------------------|---------------------| +| `0000_0001 ` | **Security Mechanism is out Out of Operation**
Queue is not started or already stopped. | 1.3.45 | +| `0000_0002 ` | **SCU (Signature Creation Unit) temporary out of service**
For at least one receipt, it was not possible to receive the signature from an allocated SCU, therefore the security mechanism has been put into "signature creation device out of service" mode. Regardless of whether an allocated SCU is available again or not, the mode remains in place until a ZeroReceipt cleans up the state and takes the market specific action required.| 1.3.45 | +| `0000_0004 ` | **SCU (Signature Creation Unit) 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.3.45 | +| `0000_0008 ` | **Deferred Queue Mode / Late Signing Mode is active**
When the cash register doesn’t reach the queue, it queues up the receipt requests while continuing to do business. Also, with a major failure of the cash register or a power outage, handwritten paper receipts are queued up while continuing to do business. After getting back to a full functional state, these queued-up ReceiptRequests are sent to the queue, having the original cbReceiptMoment of the business case and ReceiptCase tagged/flagged with 0001 (Deferred Queue / Late Signing) or 0008 (Handwritten).
A result of this is a marker within the ftState, which can be resolved via ZeroReceipt. The reason for the marker is a mismatch between processed time along the receipt chain and a manual event to clean up the state and maybe notify 3rd parties of an outage. | 1.3.45 | +| `0000_0010 ` | **MonthlyClosing due**
If the latest monthly has not been performed, the service will signal this. This status does not impact the signature conduct of the service; it is merely an indicative notification. | 1.3.45 | +| `0000_0020 ` | **AnnualClosing due**
If the latest annual closing has not been performed, the service will signal this. This status does not impact the signature conduct of the service; it is merely an indicative notification. | 1.3.45 | +| `0000_0040 ` | **Message Pending**
Middleware/Queue is a headless background service, but there are situations where communication with the cashier/operator or the cash register is necessary. For example, if the last daily closing was missed or if a special condition related to the signature creation unit or service happened. This is the moment when the message pending flag is set by the middleware, which should be signalled to the cashier by the POS system. By executing a ZeroReceipt, the cashier can read the message or instruction on the printed or displayed receipt.
Related to local regulations, this receipt may be stored/archived with/for bookkeeping purposes; if this is the case, this is also visualized. | 1.3.45 | +| `0000_0080 ` | **Backup SSCD in use**
The receipt was signed by a signature creation unit configured for backup use. | 1.3.45 | +| `EEEE_EEEE ` | **Error**
Something went wrong while processing the last request. QueueItem exists but didn’t reach the state of a ReceiptItem and didn’t consume a ftReceiptNumber within the chain. Error reason is shown within the responded ftSignatureItems.
This happens, for example, if the ReceiptCase is not recognized or is wrong. | 1.3.45 | +| `FFFF_FFFF ` | **Fail**
Something went wrong while processing the last request, and nothing persisted within the Queue. Fail reason is shown within the responded ftSignatureItems.
This happens, for example, when the flag ReceiptRequest is used after a communication outage, and no properly processed item is found. | 1.3.45 | + + +#### llll -local flags + +cba c=reserved; b=reporting; a=scu related + +| **Value** | **Description** | **Middleware Version** | +|----------------------|-----------------------------------------------------------------------------------------------------|---------------------| +| `001 ` | **[RT-Printer\|RT-Server\|Government Service] not reachable**
Responded in case of a zero-receipt and other hard dependencies to the service. | 1.3.45 | + diff --git a/doc/middleware-at-rksv/reference-tables/type-of-journal-ftjournaltype.md b/doc/middleware-at-rksv/reference-tables/type-of-journal-ftjournaltype.md new file mode 100644 index 00000000..c2a47e52 --- /dev/null +++ b/doc/middleware-at-rksv/reference-tables/type-of-journal-ftjournaltype.md @@ -0,0 +1,13 @@ +--- +slug: /poscreators/middleware-doc/austria/reference-tables/ftjournaltype +title: 'Type of Journal: ftJournalType' +--- + +# Type of Journal: ftJournalType + +This table expands on the values provided in table of Chapter ["Type of Journal: ftJournalType"](../../general/reference-tables/reference-tables.md#c-type-of-journal-ftjournaltype-129) of the General part with values applicable to the Austrian market. + +| **Value** | **Description** | **Version** | +|----------------------|--------------------------------|-------------| +| `000` | Status Information QueueAT | 1.3.45 | + diff --git a/doc/middleware-at-rksv/reference-tables/type-of-payment-ftpayitemcase.md b/doc/middleware-at-rksv/reference-tables/type-of-payment-ftpayitemcase.md new file mode 100644 index 00000000..d8cde161 --- /dev/null +++ b/doc/middleware-at-rksv/reference-tables/type-of-payment-ftpayitemcase.md @@ -0,0 +1,51 @@ +--- +slug: /poscreators/middleware-doc/austria/reference-tables/ftpayitemcase +title: 'Type of Payment: ftPayItemCase' +--- + +# Type of Payment: ftPayItemCase + +This table expands on the values provided in table [ftPayItemCase in General Part](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) with values applicable to the Austrian market. + +## Format + +_CCCC_vlll_gggg_xxPP_ + +#### v - version +version 2 + +#### PP - payment type +| **Value** | **Description** | **Middleware version** | +| -------------------- | ---------------------------------------------------------------------------------------------- | ---------------------- | +| `00` | **Unknown payment type for AT**
This is handled like a cash payment in national currency. | 1.3.45 | +| `01` | **Cash payment**
cash | 1.3.45 | +| `02` | **NonCash**
cash | 1.3.45 | +| `03` | **Crossed cheque**
cash | 1.3.45 | +| `04` | **Debit card payment**
cash | 1.3.45 | +| `05` | **Credit card payment**
cash | 1.3.45 | +| `06` | **Voucher payment (coupon) - voucher by money value**
cash | 1.3.45 | +| `07` | **Online payment**
noncash | 1.3.45 | +| `08` | **Loyalty program Customer card payment**
|1.3.45| +| `09` | **Accounts receivable**
| 1.3.45 | +| `0A` | **SEPA transfer**
| 1.3.45 | +| `0B` | **Other Bank transfer**
| 1.3.45 | +| `0C` | **Transfer to Cashbook / Vault / Owner / Employee**
Positive (+) amount contributes to cashbox/vault. This higher the amount in cashbox/vault.
Negative (-) amount lowers the amount in cashbox/vault. |1.3.45| +| `0D` | **Internal / Material consumption**
| 1.3.45| +| `0E` | **Grant**
| 1.3.45| +| `0F` | **Ticket Restaurant / (Sodexo, edenred, usw.)**
| 1.3.45| + +#### v - version +version 2 + +#### gggg - global tagging/flag +| **Value** | **Description** | **Middleware version** | +| -------------------- | ---------------------------------------------------------------------------------------------- | ---------------------- | +| `0001` | **IsVoid**
Marks PayItem as Void previous position. Quantity and amount are inverted, related to original item.
IsVoid is used in cases where the exchange of money has not been executed yet. | 1.3.45| +| `0002` | **IsReturn/IsRefund**
Marks PayItem as Return of good or service. Quantity and amount are inverted, related to original item.
IsReturn/IsRefund is used in cases where the exchange of money has been executed already.| 1.3.45| +| `0004` |**(reserved)**
| 1.3.45| +| `0008` |**Downpayment**
Marks PayItem as a downpayment.
Positive (+) amount is reduction of downpayment.
Negative (-) amount is creation of downpayment.| 1.3.45| +| `0010` | **IsForeignCurrency**
Amount is still in EUR, at the moment of acceptance. ftPayItemData requires two data elements with “foreignCurrencySymbol” and “foreignCurrencyAmount” to persist data for daily closing and later bookkeeping transactions| 1.3.45| +| `0020` | **IsChange**
Usually contains a negative (-) amount.
(IsVoid => can be inverted)| 1.3.45 | +| `0040` | **IsTip**
Must be a negative (-) amount to flow out of payment method.
ShowInChargeItems flag can be used to raise the total amount by the tip amount, to have a more convenient visualization.| 1.3.45 | +| `0080` | **IsDigital/IsElectronic**
Electronic money, digital money | 1.3.45 | +| `8000` | **ShowInChargeItems**
Visualize the item before Total Amount. This inverts amount and does include the amount into the visualized total amount on the receipt. |1.3.45| \ No newline at end of file diff --git a/doc/middleware-at-rksv/reference-tables/type-of-receipt-ftreceiptcase.md b/doc/middleware-at-rksv/reference-tables/type-of-receipt-ftreceiptcase.md new file mode 100644 index 00000000..55c564c8 --- /dev/null +++ b/doc/middleware-at-rksv/reference-tables/type-of-receipt-ftreceiptcase.md @@ -0,0 +1,87 @@ +--- +slug: /poscreators/middleware-doc/austria/reference-tables/ftreceiptcase +title: 'Type of receipt: ftReceiptCase' +--- + +# Type of Receipt: ftReceiptCase + +The `ftReceiptCase` indicates the receipt type and defines how the fiskaltrust.SecurityMechanism should process it following Austrian law. + +For Austria (AT), the country code is `0x4154`. Thus, the value of an unknown `ftReceiptCase` in Austria is `0x4154000000000000`. + +## Format + +_CCCC_vlll_gggg_txcc_ + +#### v - version +version 2 + +| **Value** | **Description** | +|----------------------|-----------------------------------------------------------------------------------------------------| +|t|ReceiptCaseType| +|txcc|ReceiptCase| +|gggg|global tagging/flag| +|lll|local tagging/flag| + +#### t - ReceiptCaseType + +| **Value** | **Category** | **Description** | +|-----------|-----------------|-------------------------| +| `0` | Receipt | A basic receipt that is generated as part of a POS sale. A receipt usually serves as proof of payment. The receipt is used after the transaction is done (if goods are received). This is the usual process that is done at a POS. | +| `1` | Invoice | An invoice is generated for those cases where payment isn't handled immediately. | +| `2` | DailyOperations | This category contains receipt cases that the Middleware requires for various downstream processes (e.g. book keeping) | +| `3` | Log | Logs can be used for storing / securing events that need are needed for additional processing or downstream processes. (e.g. log for cash drawer opened) | +| `4` | Lifecycle | These operations are used for changing the overall state of the Middleware. Depending on the local regulations these receipts are handed over as part of a notification (e.g. FinanzOnline) | + + +#### txcc - ReceiptCase + +| **Value** | **Description** | **Middleware version** | +|-----------|-----------------|-------------------------| +| `0000` | **Unknown type for country-code "AT"**

This receipt case is handled like a "pos-receipt" (`0001 `). See below: | 1.3.45 | +| `0001` | **POS receipt**

Represents the main kind of receipt processed by a POS system. Creates a turnover and/or a change in the amount of cash in the till or similar operations.

Use the `ftChargeItems` and `ftPayItems` to hand over details about goods, services and payments for processing. The `ftChargeItems` and `ftPayItems` should contain the full final state of the receipt. | 1.3.45 | +| `0002` | **Payment transfer receipt type**

| 1.3.45 | +| `0003` | **Point-Of-Sale receipt without fiscalization**

Obligation or with exeption on fiscalization regulation | 1.3.45 | +| `0004` | **E-Commerce receipt type**

| 1.3.45 | +| `0005` | **Delivery Note**

| 1.3.45 | +| `1000` | **Unknown invoice type**

| 1.3.45 | +| `1001` | **B2C invoice type**

| 1.3.45 | +| `1002` | **B2B invoice type**

| 1.3.45 | +| `1003` | **B2G invoice type**

| 1.3.45 | +| `2000` | **Zero Receipt**

Used for communication test and functional test of the fiskaltrust.SecurityMechanism. The request is only valid when the charge items block (ftChargeItems) and the pay items block (ftPayItems) in the ftReceiptRequest are empty arrays.| 1.3.45 | +| `2001` | **(reserved) One Receipt**

| 1.3.45 | +| `2010` | **Shift Closing Receipt**

| 1.3.45 | +| `2012` | **Monthly Closing Receipt**

| 1.3.45 | +| `2013` | **Yearly Closing Receipt**

| 1.3.45 | +| `3000` | **Protocol (unspecified type)**

| 1.3.45 | +| `3001` | **Protocol (technical event)**

| 1.3.45 | +| `3002` | **Protocol (audit event / accounting event)**

| 1.3.45 | +| `3003` | **Internal usage / Material consumption**

| 1.3.45 | +| `3004` | **Order**

| 1.3.45 | +| `3010` | **Copy Receipt / Print existing Receipt**

| 1.3.45 | +| `4001` | **Queue-Start-Receipt (Initial operations receipt)**

| 1.3.45 | +| `4002` | **Queue-Stop-Receipt (Out of operations receipt)**

| 1.3.45 | + +#### gggg - global tagging/flag + +| **Value** | **Description** | **Middleware version** | +|-----------|-----------------|-------------------------| +| `0001` | **Process as Late Signing Receipt**

The cash register lost connection to the queue and processed receipts without communicating with the queue. All processed receipts marked with the hint “Security mechanism not reachable” need to be sent to the queue with this maker. | 1.3.45 | +| `0002` | **Training Receipt** | 1.3.45 | +| `0004` | **IsVoid**

Marks Receipt as Void to previous one. Mark lineitems also as IsVoid to signal clear data. | 1.3.45 | +| `0008` | **Process as Handwritten Receipt**

During a power outage, the Cash register will not work, and the merchant hands out handwritten receipts. These handwritten receipts need to be sent to the Security Mechanism by using this flag. | 1.3.45 | +| `0010` | **IssuerIsSmallBusiness**

Businesses below a country-specific size in revenue need not declare VAT.
With this marker, the receipt shows no VAT, all prices are gross, and a country-specific hint must be printed. | 1.3.45 | +| `0020` | **ReceiverIsBusiness **

Specific data need to be placed onto the receipt. | 1.3.45 | +| `0040` | **ReceiverIsKnown**

Characteristics related to VAT taxes are given. For example, Name, Adress, VAT-ID, other local info. | 1.3.45 | +| `0080` | **IsSaleInForeignCountry**

| 1.3.45 | +| `0100` | **IsReturn/IsRefund**

Marks Receipt as Return of good or service. | 1.3.45 | +| `0800` | **Group by Position-Number / 100**

100 = first position, 101 first subitem, 102 second subitem.
The sum of all chargeitems within a position must count toward the total receipt amount.
If the quantity and amount are 0,00, the quantity and amount will not be visualized for this line on the digital receipt. Independent if main our subitem. | 1.3.45 | +| `8000` | **ReceiptRequest**

If you don’t receive a response, try this flag first before taking any other action.
This will return a stored result for example in case of a timeout when cashregister calls queue. | 1.3.45 | + + +#### lll - local tagging/flag + +| **Value** | **Description** | **Middleware version** | +|-----------|-----------------|-------------------------| + + diff --git a/doc/middleware-at-rksv/reference-tables/type-of-service-ftchargeitemcase.md b/doc/middleware-at-rksv/reference-tables/type-of-service-ftchargeitemcase.md new file mode 100644 index 00000000..cd3bdfcf --- /dev/null +++ b/doc/middleware-at-rksv/reference-tables/type-of-service-ftchargeitemcase.md @@ -0,0 +1,75 @@ +--- +slug: /poscreators/middleware-doc/austria/reference-tables/ftchargeitemcase +title: 'Type of service: ftChargeItemCase' +--- + +# Type of Service: ftChargeItemCase + +This table expands on the values provided in the table [ftChargeItemCase in General Part](../../general/reference-tables/reference-tables.md#type-of-service-ftchargeitemcase), with country-specific values applicable to the Austrian market. + +## Format +_CCCC_vlll_gggg_NNSV_ + +#### v - version +version 2 + +#### V - VAT +https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm + +| **Value** | **Description**| **Middleware Version** | +| -------------------- | -------------- | ---------------------- | +| `0` | **Unknown type of service for AT**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.45 | +| `1` | **Discounted-1 VAT rate**
(as of 1.7.2016, this is 10%). | 1.3.45 | +| `2` | **Discounted 2 VAT rate**
(as of 1.7.2016, this is calculated with 13%). | 1.3.45 | +| `3` | **Normal VAT rate**
(as of 1.7.2016, this is calculated with 20%). | 1.3.45 | +| `4` | **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.3.45 | +| `5` | **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.3.45 | +| `7` | **Zero VAT rate**
In the data, a VAT-rate can be indicated. | 1.3.45 | +| `8` | **Not Taxable**
For processing, see (`0x4954000000000001`) | 1.3.45 | + + +#### S - Type of Service + +| **Value** | **Description** | **Middleware Version** | +| -------------------- | -------------- | ---------------------- | +| `0` | **Unknown type of service**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.45 | +| `1` | **Delivery (supply of goods)**
| 1.3.45 | +| `2` | **Other service (supply of service)**
| 1.3.45 | +| `3` | **Tip**
For owner use V=0 to 7, related to total amount
For Employee use V=8, Not Taxable(as of 1.1.2022, this is calculated with 5%). | 1.3.45 | +| `4` | **Voucher**
For Single-Use-Voucher use V=0 to 7
For Multi-Use-Voucher use V=8, Not Taxable
Voucher Sale is a positive (+) amount.
Voucher Redeem is a negative (-) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this for Multi-Use-Voucher, use PayItem instead, with ShowInChargeItems flag. For Single-Use-Voucher, apply the ShowInPayItems flag to visualize it similar to payment and to keep the total amount unreduced. | 1.3.45 | +| `5` | **Catalog service**
| 1.3.45 | +| `6` | **Not own sales / Agency business**
| 1.3.45 | +| `7` | **Own Consumption**
| 1.3.45 | +| `8` | **Grant**
For Unreal Grant use V=0 to 7
For Real Grant use V=8 |1.3.45| +| `9` | **Receivable**
Receiveable creation is negative (-) amount
Receiveable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.45| +| `A` | **Cash Transfer**
Cash Transfer to till is positive (+) amount
Cash Transfer from till is negative (-) amount.
Only useable with V=8, Not Taxable.
IsVoid can be applied to reverse amounts|1.3.45| + +#### NN - nature of VAT + +| **Value** | **Description** | **Middleware Version** | +| -------------------- | -------------- | ---------------------- | +| `00` | **usual VAT applies**
| 1.3.45 | +| `10` | **Not Taxable**
| 1.3.45 | +| `30` | **Exempt**
| 1.3.45 | +| `50` | **Reverse charge**
| 1.3.45 | +| `60` | **VAT paid in other EU country**
| 1.3.45 | + + +#### lll - local taggin/flag + +None + +#### gggg - global tagging/flag + +| **Value** | **Description** | **Middleware Version** | +| -------------------- | -------------- | ---------------------- | +| `0001` | **IsVoid**
Marks ChargeItem as Void previous position. Quantity and amount are inverted, related to original item. | 1.3.45 | +| `0002` | **IsReturn/IsRefund**
Marks ChargeItem as Return of good or service. Quantity and amount are inverted, related to original item. | 1.3.45 | +| `0004` | **Discount**
Marks ChargeItem as Discount/Extra for previous position.
Positive (+) amount is extra.
Negative (-) amount is discount
IsVoid or IsReturn/IsRefund will invert this behavior.| 1.3.45 | +| `0008` | **Downpayment**
Marks ChargeItem as a downpayment.
Positive (+) amount is the creation of downpayment.
Negative (-) amount is reduction of downpayment.
IsVoid or IsReturn/IsRefund will invert this behavior. | 1.3.45 | +| `0010` | **Returnable**
Marks ChargeItem as a returnable.
Positive (+) amount/quantity is handout.
Negative (-) amount/quantity is reverse.
IsVoid or IsReturn/IsRefund will invert this behavior.| 1.3.45 | +| `0020` | **TakeAway**
Marks ChargeItem as TakeAway item to prove special VAT application | 1.3.45 | +| `8000` | **ShowInPayments**
Visualize the item after Total Amount. This inverts amount and does not include the amount into the visualized total amount on the receipt. | 1.3.45 | + +## ftChargeItemCaseFlag +This table shows flags that can be added to each `ftChargeItemCase` with values applicable to the Austrian market. diff --git a/doc/middleware-at-rksv/reference-tables/type-of-signature-ftsignatureformat.md b/doc/middleware-at-rksv/reference-tables/type-of-signature-ftsignatureformat.md new file mode 100644 index 00000000..6815be02 --- /dev/null +++ b/doc/middleware-at-rksv/reference-tables/type-of-signature-ftsignatureformat.md @@ -0,0 +1,7 @@ +--- +slug: /poscreators/middleware-doc/austria/reference-tables/ftsignatureformat +title: 'Format of signature: ftSignatureFormat' +--- + +# Format of Signature: ftSignatureFormat +The Middleware uses the same _ftSignatureFormats_ in Austria as in all other countries, as described in the [general part](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat). diff --git a/toc.js b/toc.js index 517022a7..ac818a6a 100644 --- a/toc.js +++ b/toc.js @@ -50,7 +50,20 @@ module.exports = { 'middleware-doc/doc/middleware-at-rksv/operation-modes/operation-modes', 'middleware-doc/doc/middleware-at-rksv/installation/installation', 'middleware-doc/doc/middleware-at-rksv/receipt-case-definitions/receipt-case-definitions', - 'middleware-doc/doc/middleware-at-rksv/reference-tables/reference-tables', + 'middleware-doc/doc/middleware-at-rksv/reference-tables/reference-tables-v0', + { + type: 'category', + label: 'Reference Tables v2', + items: [ + 'middleware-doc/doc/middleware-at-rksv/reference-tables/reference-tables', + 'middleware-doc/doc/middleware-at-rksv/reference-tables/service-status-ftstate', + 'middleware-doc/doc/middleware-at-rksv/reference-tables/type-of-receipt-ftreceiptcase', + 'middleware-doc/doc/middleware-at-rksv/reference-tables/type-of-service-ftchargeitemcase', + 'middleware-doc/doc/middleware-at-rksv/reference-tables/type-of-payment-ftpayitemcase', + 'middleware-doc/doc/middleware-at-rksv/reference-tables/type-of-signature-ftsignatureformat', + 'middleware-doc/doc/middleware-at-rksv/reference-tables/type-of-journal-ftjournaltype', + ] + } ] }, {