From 6dc72e1e5d0debf3e22fabb55d7f990be8fde687 Mon Sep 17 00:00:00 2001 From: deboragracio Date: Wed, 10 Jun 2026 16:05:58 +0200 Subject: [PATCH 1/6] AT/BE https://github.com/fiskaltrust/engineering/issues/1135 --- .../reference-tables/reference-tables.md | 294 +++++++++--------- .../reference-tables/reference-tables.md | 20 +- .../service-status-ftstate.md | 28 +- .../type-of-journal-ftjournaltype.md | 8 +- .../type-of-payment-ftpayitemcase.md | 64 ++-- .../type-of-receipt-ftreceiptcase.md | 114 ++++--- .../type-of-service-ftchargeitemcase.md | 62 ++-- .../type-of-signature-ftsignatureformat.md | 11 +- .../type-of-signature-ftsignaturetype.md | 43 +-- 9 files changed, 327 insertions(+), 317 deletions(-) diff --git a/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md index 4be167f..98ea995 100644 --- a/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md @@ -5,7 +5,7 @@ title: Reference Tables # Reference Tables -This chapter expands on the reference tables covered in the Chapter [Reference tables](../../general/reference-tables/reference-tables-v1.md) of the General Part, with country-specific information applicable to the Austrian market. +This page expands on the reference tables covered in the [Reference Tables](../../general/reference-tables/reference-tables-v1.md) of the Compliance Middleware, with country-specific information applicable to the Austrian market. ## Service Status: ftState @@ -13,201 +13,201 @@ The table below describes the supported statuses for the ftState field following 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 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 | +| **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 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* +*Table 1. Service Status: ftState (AT - RKSVO)* -### Type of Receipt: ftReceiptCase +## 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.SecurityMechanismsPlus, 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 another 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 | +| **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.SecurityMechanismsPlus, 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 another 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)* +*Table 2. 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#ftreceiptcaseflag) of with values applicable to the Austrian market. +This table expands on the values provided in the table [Type of Receipt: ftReceiptCaseFlag](../../general/reference-tables/reference-tables.md#ftreceiptcaseflag) 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"
Used to retrieve an already processed receipt from the fiskaltrust.Middleware using the `cbReceiptReference` field. The `cbTerminalID` can also be included in this request. ChargeItems and PayItems must be exactly the same as in the requested receipt. If a matching receipt is found, its content will be returned. If no matching receipt is found, a null value is returned. This may be necessary if a communication problem occurs while the fiskaltrust.Middleware processes a request. | | +| **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"
Used to retrieve an already processed receipt from the fiskaltrust.Middleware using the `cbReceiptReference` field. The `cbTerminalID` can also be included in this request. ChargeItems and PayItems must be exactly the same as in the requested receipt. If a matching receipt is found, its content will be returned. If no matching receipt is found, a null value is returned. This may be necessary if a communication problem occurs while the fiskaltrust.Middleware processes a request. | | -*Table 23. Type of Receipt: ftReceiptCase Flags(AT - RKSVO)* +*Table 3. 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#format-of-signature-ftsignatureformat) 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 | +This table expands on the values provided in the table [Type of Service: ftChargeItemCase](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) 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)* +*Table 4. 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#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 | +This table expands on the values provided in the table [Type of Payment: ftPayItemCase](../../general/reference-tables/reference-tables.md#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)* +*Table 5. Type of Payment: ftPayItemCase (AT - RKSVO)* -## Type of Signature: ftSignatureFormat +## Type of Signature: ftSignatureType -This table expands on the values provided in the table ["Format of Signature: ftSignatureFormat"](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) with values applicable to the Austrian market. +This table expands on the values provided in the table [Type of Signature: ftSignatureType](../../general/reference-tables/reference-tables.md#type-of-signature-ftsignaturetype) 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** | **Middleware 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 | -| **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 7. Type of Signature: ftSignatureType (AT - RKSVO)* -*Table 26. Type of Signature: ftSignatureFormat (AT - RKSVO)* +## Format of Signature: ftSignatureFormat -## Type of Signature: ftSignatureType +This table expands on the values provided in the table [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) with values applicable to the Austrian market. -This table expands on the values provided in the table ["Type of Signature: ftSignatureType"](../../general/reference-tables/reference-tables.md#type-of-signature-ftsignaturetype) 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 [Printing of QR-Code not supported](#printing-of-qr-code-not-supported) section. -| **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 | +| **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 27. Type of Signature: ftSignatureType (AT - RKSVO)* +*Table 6. Format of Signature: ftSignatureFormat (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#type-of-journal-ftjournaltype) of the General part with values applicable to the Austrian market. +This table expands on the values provided in the table [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) with values applicable to the Austrian market. -| **Value** | **Description** | **Version** | -|----------------------|--------------------------------|-------------| -| `0x4154000000000000` | status information for QueueAT | 1.0 | -| `0x4154000000000001` | RKSV-DEP-Export | 1.0 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x4154000000000000` | status information for QueueAT | 1.0 | +| `0x4154000000000001` | RKSV-DEP-Export | 1.0 | -*Table 28. Type of Journal: ftJournalType (AT - RKSVO)* +*Table 8. Type of Journal: ftJournalType (AT - RKSVO)* ## Printing of QR-Code not supported diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md index 8f01302..2aba18a 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md @@ -5,7 +5,13 @@ title: Reference Tables # Reference Tables -This chapter expands on the reference tables covered in [Reference Tables in General Part](../../general/reference-tables/reference-tables.md), with country-specific information applicable to the Belgian market. The respective tables can be found in the following sub-sections. +This page expands on the reference tables covered in the [Reference Tables](../../general/reference-tables/reference-tables.md) of the Compliance Middleware, with country-specific information applicable to the Belgian market. The respective tables can be found in the following subsections. + +:::info POSSystem API v2 Reference + +The Compliance Middleware [Reference Tables](../../general/reference-tables/reference-tables.md) contain the core POSSystem API v2 tagging structure used across all markets and should be your primary reference. + +::: As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for Belgian 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. @@ -19,9 +25,9 @@ _4245_2000_0010_0001 _CCCC_vIII_gggg_xxxx -| **Value** | **Description** | -|----------------------|-----------------------------------------------------------------------------------------------------| -|CCCC|(e.g 4245): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. BE = 4245) | -|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 leave 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 | \ No newline at end of file +| **Value** | **Description** | +| --------- | ----------------| +| CCCC | (e.g 4245): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. BE = 4245) | +| 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 leave 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. | diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/service-status-ftstate.md b/poscreators/middleware-doc/middleware-be/reference-tables/service-status-ftstate.md index 1742c12..d02d4fe 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/service-status-ftstate.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/service-status-ftstate.md @@ -13,22 +13,22 @@ _CCCC_vlll_gggg_gggg_ version 2 #### gggg_gggg - global tagging/flag -| **Value** | **Description** | **Middleware Version** | -|----------------------|-----------------------------------------------------------------------------------------------------|---------------------| -| `0000_0001 ` | **Security Mechanism is 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_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_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_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 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 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0000_0001` | **Security Mechanism is 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_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_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_0100` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 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 +#### llll - local flags -| **Value** | **Description** | **Middleware Version** | -|----------------------|-----------------------------------------------------------------------------------------------------|---------------------| -|TBD|TBD|TBD| +cba c=reserved; b=reporting; a=scu related +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| TBD | TBD | TBD | diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md index a3f8397..f4c78a9 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md @@ -5,8 +5,8 @@ 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#type-of-journal-ftjournaltype) of the General part with values applicable to the Belgian market. +This table expands on the values provided in the table [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) of the Compliance Middleware with values applicable to the Belgian market. -| **Value** | **Description** | **Version** | -|----------------------|--------------------------------|-------------| -| `000` | Status Information QueueBE | 1.3.45 | +| **Value** | **Description** | **Version** | +| --------- | --------------- | ----------- | +| `000` | Status Information QueueBE | 1.3.45 | diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md index 3cc6e94..5cdf2cc 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md @@ -5,7 +5,7 @@ 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 Belgian market. +This table expands on the values provided in the table [ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) of the Compliance Middleware with values applicable to the Belgian market. ## Format @@ -15,38 +15,40 @@ _CCCC_vlll_gggg_xxPP_ version 2 #### PP - payment type -| **Value** | **Description** | **Middleware version** | -| -------------------- | ---------------------------------------------------------------------------------------------- | ---------------------- | -| `00` | **Unknown payment type for BE**
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| + +| **Value** | **Description** | **Middleware version** | +| --------- | --------------- | ---------------------- | +| `00` | **Unknown payment type for BE**
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 | -| `0100` | **IsInterface/AmountVerified**
Was verified by interface, automated amount transfer | 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 + +| **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 | +| `0100` | **IsInterface/AmountVerified**
Was verified by interface, automated amount transfer | 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 | diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-receipt-ftreceiptcase.md index 9dd0e43..aaf77e5 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-receipt-ftreceiptcase.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-receipt-ftreceiptcase.md @@ -1,6 +1,6 @@ --- slug: /poscreators/middleware-doc/belgium/reference-tables/ftreceiptcase -title: 'Type of receipt: ftReceiptCase' +title: 'Type of Receipt: ftReceiptCase' --- # Type of Receipt: ftReceiptCase @@ -16,74 +16,72 @@ _CCCC_vlll_gggg_txcc_ #### v - version version 2 -| **Value** | **Description** | -|----------------------|-----------------------------------------------------------------------------------------------------| -|t|ReceiptCaseType| -|txcc|ReceiptCase| -|gggg|global tagging/flag| -|lll|local tagging/flag| +| **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 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) | - +| --------- | ------------ | --------------- | +| `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 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 "BE"**

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 exception 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 | -| `2011` | **Daily 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 | -| `4011` | **Initiate SCU-switch**

| 1.3.45 | -| `4012` | **Finish SCU-switch**

| 1.3.45 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0000` | **Unknown type for country-code "BE"**
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 exception 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 | +| `2011` | **Daily 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 | +| `4011` | **Initiate SCU-switch** | 1.3.45 | +| `4012` | **Finish SCU-switch** | 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 marker. | 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, Address, VAT-ID, other local info. | 1.3.45 | -| `0080` | **IsSaleInForeignCountry**

| 1.3.45 | +| **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 marker. | 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, Address, 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 or 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 | - +| `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 or 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** | -|-----------|-----------------|-------------------------| -|TBD|TBD|TBD| \ No newline at end of file +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| TBD | TBD | TBD | diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-service-ftchargeitemcase.md index db26d5c..57bdacc 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-service-ftchargeitemcase.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-service-ftchargeitemcase.md @@ -1,11 +1,11 @@ --- slug: /poscreators/middleware-doc/belgium/reference-tables/ftchargeitemcase -title: 'Type of service: 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 Belgian market. +This table expands on the values provided in the table [ftChargeItemCase](../../general/reference-tables/reference-tables.md#type-of-service-ftchargeitemcase) of the Compliance Middleware, with country-specific values applicable to the Belgian market. ## Format _CCCC_vlll_gggg_NNSV_ @@ -13,15 +13,16 @@ _CCCC_vlll_gggg_NNSV_ #### v - version version 2 -#### V - VAT -https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm +#### V - VAT -| **Value** | **Description**| **Middleware Version** | -| -------------------- | -------------- | ---------------------- | -| `0` | **Unknown type of service for BE**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.45 | +For more information, see [VAT rules and rates](https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm). + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0` | **Unknown type of service for BE**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.45 | | `1` | **Discounted-1 VAT rate**
(as of 1.1.2022, this is 10%). | 1.3.45 | -| `2` | **Discounted 2 VAT rate**
(as of 1.1.2022, this is calculated with 5%). | 1.3.45 | -| `3` | **Normal VAT rate**
(as of 1.1.2022, this is calculated with 22%). | 1.3.45 | +| `2` | **Discounted 2 VAT rate**
(as of 1.1.2022, this is calculated with 5%). | 1.3.45 | +| `3` | **Normal VAT rate**
(as of 1.1.2022, this is calculated with 22%). | 1.3.45 | | `4` | **Super reduced 1 VAT rate**
| 1.3.45 | | `5` | **Super reduced 2 VAT rate**
| 1.3.45 | | `6` | **Parking VAT rate**
Reversal of tax liability. | 1.3.45 | @@ -31,28 +32,28 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm #### 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 | +| **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**
Receivable creation is negative (-) amount
Receivable 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| +| `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**
Receivable creation is negative (-) amount
Receivable 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** | **Spec. for Belgian reg.** | **Middleware Version** | -| -------------------- | -------------- | -------------- | ---------------------- | -| `00` | **usual VAT applies**
| | 1.3.45 | +| **Value** | **Description** | **Spec. for Belgian reg.** | **Middleware Version** | +| ---------- | --------------- | -------------------------- | ---------------------- | +| `00` | **usual VAT applies**
| | 1.3.45 | | `10` | **Not Taxable**
1x can be used to specify more country specific details. For example, IGL|*NI (N3) marker mandatory
[10] not taxable - exports
[11] non-taxable - intra-community supplies
[12] non-taxable - transfers to San Marino
[13] non-taxable - transactions assimilated to export supplies
[14] non-taxable - following declarations of intent
[15] non-taxable - other operations which do not contribute to the formation of the ceiling | 1.3.45 | -| `20` | **Not Subject**
2x can be used to specify more country specific details.| *NS (N2) marker mandatory
[20] not subject to VAT pursuant to articles from 7 to 7-septies of Presidential Decree 633/72
[21] not subject, other cases| 1.3.45 | -| `30` | **Exempt**
3x| *BE (N4) marker mandatory
[30] exempt | 1.3.45 | +| `20` | **Not Subject**
2x can be used to specify more country specific details.| *NS (N2) marker mandatory
[20] not subject to VAT pursuant to articles from 7 to 7-septies of Presidential Decree 633/72
[21] not subject, other cases| 1.3.45 | +| `30` | **Exempt**
3x| *BE (N4) marker mandatory
[30] exempt | 1.3.45 | | `40` | **Margin scheme**
Do not print/show VAT rate and amount on receipt/invoice.
4x can be used to specify more country specific details. | *RM (N5) marker mandatory
[40] margin scheme / VAT not shown on the invoice | 1.3.45 | | `50` | **Reverse charge**
5x | *AL (N6) marker mandatory
[50] reverse charge - disposal of scrap and other salvage materials
[51] reverse charge - sale of gold and silver pursuant to law 7/2000 as well as used jewellery to OPO
[52] reverse charge - subcontracting in the construction sector
[53] reverse charge - sale of buildings
[54] reverse charge - supply of mobile phones
[55] reverse charge - supply of electronic products
[56] reverse charge - performance in the construction sector and related sectors
[57] reverse charge - energy sector transactions
[58] reverse charge - other cases | 1.3.45 | | `60` | **VAT paid in other EU country**
6x| (N7) marker mandatory
[60] paid in another EU country (provision of telecommunications, broadcasting and electronic services pursuant to art. 7-octies, paragraph 1 letter a, b, art. 74-sexies of Presidential Decree 633/72) | 1.3.45 | @@ -66,15 +67,16 @@ TBD #### 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 | +| **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 | +| `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 Belgian market. diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignatureformat.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignatureformat.md index ee2a5fa..55dd89f 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignatureformat.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignatureformat.md @@ -1,14 +1,15 @@ --- slug: /poscreators/middleware-doc/belgium/reference-tables/ftsignatureformat -title: 'Format of signature: ftSignatureFormat' +title: 'Format of Signature: ftSignatureFormat' --- # Format of Signature: ftSignatureFormat -The Middleware uses the same _ftSignatureFormats_ in Belgium as in all other countries, as described in the [general part](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat). + +The Middleware uses the same ftSignatureFormat in Belgium as in all other countries, as described in the table [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) of the Compliance Middleware. ## ftSignatureFormatFlag -| Value | Description | Middleware-Version | -|-------|-------------|--------------------| -|TBD|TBD|TBD| \ No newline at end of file +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| TBD | TBD | TBD | diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignaturetype.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignaturetype.md index d6ef4ce..2ea0423 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignaturetype.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignaturetype.md @@ -1,14 +1,13 @@ --- slug: /poscreators/middleware-doc/belgium/reference-tables/ftsignaturetype -title: 'Type of signature: ftSignatureType' +title: 'Type of Signature: ftSignatureType' --- # Type of Signature: ftSignatureType The `ftSignatureType` indicates the type and origin of the signature. The data type is `Int64` and can contain a country-specific code, a value following the ISO-3166-1-ALPHA-2 standard, converted from ASCII into hex and used as byte 8 and 7. - -For definitions regarding national laws, please refer to the appropriate appendix. +For definitions regarding national laws, refer to the appropriate appendix. ## Format @@ -17,24 +16,26 @@ _CCCC_vlll_gggg_tsss #### v - version version 2 -#### t - Type/Category -| **Value** | **Description** | **Middleware-Version** | -|-----------|-----------------|------------------------| -| `0` | Uncategorized, Normal use (notification) | 1.3.45 | -| `1` | Information (notification), low priority | 1.3.45 | -| `2` | Alert (notification), high priority | 1.3.45 | -| `3` | Failure (notification), high priority | 1.3.45 | - -#### gggg - global flags -| **Value** | **Description** | **Middleware-Version** | -|-----------|-----------------|------------------------| -| `0001` | Archiving required.
Signatures marked with this flag are known to be archived related to market specific bookkeeping requirements. In case of offline usage or pure open-source usage, receipts/artefacts having this flag need to be handled as bookkeeping/accounting-relevant item. | 1.3.45 | -| `0010` | Printing/Visualization is optional | 1.3.45 | -| `0020` | Do not print/visualize | 1.3.45 | -| `0040` | Printed receipt only | 1.3.45 | -| `0080` | Digital receipt only | 1.3.45 | +#### t - Type/Category + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0` | Uncategorized, Normal use (notification) | 1.3.45 | +| `1` | Information (notification), low priority | 1.3.45 | +| `2` | Alert (notification), high priority | 1.3.45 | +| `3` | Failure (notification), high priority | 1.3.45 | + +#### gggg - global flags + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0001` | Archiving required.
Signatures marked with this flag are known to be archived related to market specific bookkeeping requirements. In case of offline usage or pure open-source usage, receipts/artefacts having this flag need to be handled as bookkeeping/accounting-relevant item. | 1.3.45 | +| `0010` | Printing/Visualization is optional. | 1.3.45 | +| `0020` | Do not print/visualize. | 1.3.45 | +| `0040` | Printed receipt only. | 1.3.45 | +| `0080` | Digital receipt only. | 1.3.45 | #### sss - SignatureCase | **Value** | **Description** | **Caption** | **Middleware-Version** | -|-----------|-----------------|-----------------|------------------------| -|TBD|TBD|TBD| +| --------- | --------------- | ----------- | ---------------------- | +| TBD | TBD | TBD | TBD | From 8ac0f7b85244e0650f64181a103b403a11c402d2 Mon Sep 17 00:00:00 2001 From: deboragracio Date: Wed, 10 Jun 2026 17:14:31 +0200 Subject: [PATCH 2/6] DE https://github.com/fiskaltrust/engineering/issues/1135 --- .../type-of-journal-ftjournaltype.md | 4 +- .../type-of-payment-ftpayitemcase.md | 24 +- .../type-of-signature-ftsignaturetype.md | 2 +- .../reference-tables/reference-tables.md | 2 +- .../service-status-ftstate.md | 8 +- .../type-of-journal-ftjournaltype.md | 14 +- .../type-of-payment-ftpayitemcase.md | 18 +- .../type-of-receipt-ftreceiptcase.md | 107 ++++---- .../type-of-service-ftchargeitemcase.md | 258 +++++++++--------- .../type-of-signature-ftsignatureformat.md | 12 +- .../type-of-signature-ftsignaturetype.md | 58 ++-- 11 files changed, 252 insertions(+), 255 deletions(-) diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md index f4c78a9..c5da349 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md @@ -7,6 +7,6 @@ title: 'Type of Journal: ftJournalType' This table expands on the values provided in the table [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) of the Compliance Middleware with values applicable to the Belgian market. -| **Value** | **Description** | **Version** | -| --------- | --------------- | ----------- | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | | `000` | Status Information QueueBE | 1.3.45 | diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md index 5cdf2cc..1a78624 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md @@ -9,7 +9,7 @@ This table expands on the values provided in the table [ftPayItemCase](../../gen ## Format -_CCCC_vlll_gggg_xxPP_ +_CCCC_vlll_gggg_xxPP_ #### v - version version 2 @@ -17,7 +17,7 @@ version 2 #### PP - payment type | **Value** | **Description** | **Middleware version** | -| --------- | --------------- | ---------------------- | +| --- | --- | --- | | `00` | **Unknown payment type for BE**
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 | @@ -28,7 +28,7 @@ version 2 | `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 | +| `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 | @@ -41,14 +41,14 @@ 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 | +| `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 | | `0100` | **IsInterface/AmountVerified**
Was verified by interface, automated amount transfer | 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 | +| `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 | diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignaturetype.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignaturetype.md index 2ea0423..d4acaa4 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignaturetype.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignaturetype.md @@ -36,6 +36,6 @@ version 2 | `0080` | Digital receipt only. | 1.3.45 | #### sss - SignatureCase -| **Value** | **Description** | **Caption** | **Middleware-Version** | +| **Value** | **Description** | **Caption** | **Middleware Version** | | --------- | --------------- | ----------- | ---------------------- | | TBD | TBD | TBD | TBD | diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/reference-tables.md index e184af8..cf16d0b 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/reference-tables.md @@ -5,4 +5,4 @@ title: Reference Tables # Reference Tables -This chapter expands on the reference tables covered in [Reference Tables in General Part](../../general/reference-tables/reference-tables-v1.md), with country-specific information applicable to the German market. The respective tables can be found in the following sub-sections. +This page expands on the reference tables covered in the [Reference Tables](../../general/reference-tables/reference-tables-v1.md) of the Compliance Middleware, with country-specific information applicable to the German market. The respective tables can be found in the following subsections. diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/service-status-ftstate.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/service-status-ftstate.md index 1a886b3..5b2cf51 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/service-status-ftstate.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/service-status-ftstate.md @@ -9,7 +9,7 @@ The country-specific code is made of the country's code value following the ISO- The table below describes its supported statuses for the ftState field following German law. These codes can be added through the logic operator `OR`. -| **Value** | **Description** | **Middleware Version** | -|----------------------|-----------------------------------------------------------------------------------------------------|---------------------| -| `0x4445000000000002` | The security mechanism was not able to communicate with the TSE device for at least one cycle. If this is the case, no more communication attempts are done to avoid long waiting times for each Receipt request/Receipt response sequence. To leave this state, a Zero-Receipt must be sent, which forces a communication retry towards the TSE device.
Receipts created in a state where no communication is possible with the TSE device are protected by the security mechanism of fiskaltrust. | 1.0 | -| `0x4445000000000100` | The Middleware is in the process of switching SCUs. This state is returned in case any receipts are processed between the _initialize-switch receipt_ and the _finish-switch receipt_. These receipts are protected by the fiskaltrust.SecurityMechanism, but not sent to any TSE, as no SCU is connected at this point. | 1.3.19 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x4445000000000002` | The security mechanism was not able to communicate with the TSE device for at least one cycle. If this is the case, no more communication attempts are done to avoid long waiting times for each Receipt request/Receipt response sequence. To leave this state, a Zero-Receipt must be sent, which forces a communication retry towards the TSE device.
Receipts created in a state where no communication is possible with the TSE device are protected by the security mechanism of fiskaltrust. | 1.0 | +| `0x4445000000000100` | The Middleware is in the process of switching SCUs. This state is returned in case any receipts are processed between the _initialize-switch receipt_ and the _finish-switch receipt_. These receipts are protected by the fiskaltrust.SecurityMechanism, but not sent to any TSE, as no SCU is connected at this point. | 1.3.19 | diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md index f8ead1f..7fa973e 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md @@ -5,11 +5,11 @@ 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#type-of-journal-ftjournaltype) of the General part with values applicable to the German market. +This table expands on the values provided in table ["Type of Journal: ftJournalType"](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) of the Compliance Middleware with values applicable to the German market. -| **Value** | **Description** | **Version** | -|----------------------|--------------------------------|-------------| -| `0x4445000000000000` | Status information for QueueDE | 1.3.1 | -| `0x4445000000000001` | .TAR-File from TSE device. Please note that the TSE's log messages are automatically exported during each daily closing receipt and deleted on the device afterwards for performance reasons. Hence, this export will only return the log files created since the last daily closing. To get the full TAR file, please use the type `0x4445000000000003`. | 1.3.1 | -| `0x4445000000000002` | DSFinV-K export as .ZIP file | 1.3.6 | -| `0x4445000000000003` | .TAR-File from Middleware database. This export should be preferred over `0x4445000000000001` generally, as it's populated from the already exported data and therefore faster than the direct TSE export. | 1.3.11 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x4445000000000000` | Status information for QueueDE | 1.3.1 | +| `0x4445000000000001` | .TAR-File from TSE device. Please note that the TSE's log messages are automatically exported during each daily closing receipt and deleted on the device afterwards for performance reasons. Hence, this export will only return the log files created since the last daily closing. To get the full TAR file, please use the type `0x4445000000000003`. | 1.3.1 | +| `0x4445000000000002` | DSFinV-K export as .ZIP file | 1.3.6 | +| `0x4445000000000003` | .TAR-File from Middleware database. This export should be preferred over `0x4445000000000001` generally, as it's populated from the already exported data and therefore faster than the direct TSE export. | 1.3.11 | diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md index 8f7dbd3..99a94ed 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md @@ -5,26 +5,26 @@ 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 German market. +This table expands on the values provided in table [ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) of the Compliance Middleware with values applicable to the German market. -| **Value** | **Description** | **ZAHLART_TYP (DSFinV-K)** | **Middleware-Version** | -|---|---|---|---| +| **Value** | **Description** | **ZAHLART_TYP (DSFinV-K)** | **Middleware Version** | +| --------- | --------------- | -------------------------- | ---------------------- | | `0x4445000000000000` | Unknown payment type for DE
This is handled like a cash payment in national currency. | Bar | 1.3- | | `0x4445000000000001` | Cash payment in national currency | Bar | 1.3- | | `0x4445000000000002` | Cash payment in foreign currency | Bar | 1.3- | -| `0x4445000000000003` | Crossed cheque | Unbar | 1.3- | +| `0x4445000000000003` | Crossed cheque | Unbar | 1.3- | | `0x4445000000000004` | Debit card payment | ECKarte | 1.3- | | `0x4445000000000005` | Credit card payment | Kreditkarte | 1.3- | | `0x4445000000000006` | Online payment | ElZahlungsdienstleister | 1.3- | | `0x4445000000000007` | Customer card payment | Guthabenkarte | 1.3- | -| `0x4445000000000008` | SEPA transfer | Unbar | 1.3- | +| `0x4445000000000008` | SEPA transfer | Unbar | 1.3- | | `0x4445000000000009` | Other Bank transfer | Unbar | 1.3- | | `0x444500000000000A` | Internal / material consumption | Keine | 1.3- | | `0x444500000000000B` | Change in national currency | Bar | 1.3- | | `0x444500000000000C` | Change in foreign currency | Bar | 1.3- | | `0x444500000000000D` | Voucher
not taxable
DSFinV-K transformation required. UST_Schluessel=5. Negative amount gets converted to GV_TYP=MehrzweckgutscheinKauf. Positive amount gets converted to TYP_GV=MehrzweckgutscheinEinlösung. amount=-amount. In case of void-receipt everything is returned. | Keine | 1.3 | -| `0x444500000000000E` | Receivable
not taxable
DSFinV-K transformation required. UST_Schluessel=5. Negative amount gets converted to GV_TYP=Forderungsauflösung. Positive amount gets converted to GV_TYP=Forderungsentstehung. amount=-amount. In case of cancellation-receipt the +/- sign has to be returned. | Keine | 1.3- | -| `0x444500000000000F` | Down payment
not taxable
DSFinV-K transformation required. UST_Schluessel=5. Negative amount gets converted to GV_TYP=Anzahlungseinstellung. Positive amount gets converted to GV_TYP=Anzahlungsaufloesung. amount=-amount. In case of void-receipt everything is returned. Not valid for taxable down payments, where it is clearly defined what the service is for. | Keine | 1.3- | +| `0x444500000000000E` | Receivable
not taxable
DSFinV-K transformation required. UST_Schluessel=5. Negative amount gets converted to GV_TYP=Forderungsauflösung. Positive amount gets converted to GV_TYP=Forderungsentstehung. amount=-amount. In case of cancellation-receipt the +/- sign has to be returned. | Keine | 1.3- | +| `0x444500000000000F` | Down payment
not taxable
DSFinV-K transformation required. UST_Schluessel=5. Negative amount gets converted to GV_TYP=Anzahlungseinstellung. Positive amount gets converted to GV_TYP=Anzahlungsaufloesung. amount=-amount. In case of void-receipt everything is returned. Not valid for taxable down payments, where it is clearly defined what the service is for. | Keine | 1.3- | | `0x4445000000000010` | Tip to employee
not taxable
DSFinV-K transformation required. UST_Schluessel=5. Negative amount required, get converted to GV_TYP=TrinkgeldAN. amount=-amount. In case of void-receipt everything returned. | Keine | 1.3- | | `0x4445000000000011` | (real) Grant
not taxable
DSFinV-K transformation required. UST_Schluessel=5. Positive amount required, get converted to GV_TYP=ZuschussEcht. amount=-amount. In case of void-receipt everything is returned. | Keine | 1.3- | | `0x4445000000000012` | Cash transfer to empty till
not taxable
DSFinV-K transformation required. UST_Schluessel=5. Negative amount required, get converted to GV_TYP=Anfangsbestand. amount=-amount. In case of void-receipt everything is returned. | Keine | 1.3- | @@ -38,8 +38,8 @@ This table expands on the values provided in table [ftPayItemCase in General Par This table shows flags that can be added to each `ftPayItemCase` with values applicable to the German market. -| Value | Description | Middleware-Version | -|---|---|---| +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | | 0x00000000002000001 | **Position cancellation flag**
When this flag is sent: Only the amount is used for calculating the sums in the Middleware, the DSFinV-K and the DFKA (instead of our common approach with the Quantity-based calculation). Sets the STORNO field in the DSFinV-K and the DFKA | 1.3.1- | 1 Previous documentation contained a typo regarding this flag. The documentation has been corrected to align with the [middleware implementation](https://docs.fiskaltrust.eu/changelog/middleware/1.3.66#-feature-support-line-cancellations). diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md index a64cbf9..f3380e6 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md @@ -1,6 +1,6 @@ --- slug: /poscreators/middleware-doc/germany/reference-tables/ftreceiptcase -title: 'Type of receipt: ftReceiptCase' +title: 'Type of Receipt: ftReceiptCase' --- # Type of Receipt: ftReceiptCase @@ -9,60 +9,61 @@ The `ftReceiptCase` indicates the receipt type and defines how the fiskaltrust.S For Germany (DE), the country code is `0x4445`. Thus, the value of an unknown `ftReceiptCase` in Germany is `0x4445000000000000`. -| **Value** | **Description** | **BON_TYP (DSFinV-K)**
**processType (TSE)** | **Middleware- Version** | -|-----------|-----------------|-----------------------------------------------------|-------------------------| -| `0x4445000000000000` | **Unknown type for country-code "DE"**

This receipt case is handled like a "pos-receipt" (`0x4445000000000001`). See below: | Beleg
Kassenbeleg-V1 | 1.3- | -| `0x4445000000000001` | **Pos-receipt**

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

Use the `ftChargeItems` and `ftPayItems` to hand over details for processing. The `ftChargeItems` and `ftPayItems` should contain the full final state of the receipt. Turnover and cash amount is increased by the final pos-receipt content, intermediate start-transaction, update-transaction and delta-transaction content doesn't influence turnover and cash amount. The pos-receipt case can be used with **implicit and explicit** flow.

The duration of the represented action is calculated using the minimum (start time) and maximum (end time) of datetimes over `ftReceiptRequest`/`ftChargeItems`/`ftPayItems`

The BON_TYP (Beleg) of DSFinV-K can be overwritten by an `ftReceiptCaseFlag`. | Beleg
Kassenbeleg-V1 | 1.3- | -| `0x4445000000000002` | **Zero-receipt**

Used for communication test and functional test of the fiskaltrust.SecurityMechanism. In addition, the response also contains a detailed status information about the used TSE-Device. TSE data is herefore loaded and that may cause a long running request.

The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.

This receipt case works **only** with **implicit** flow. Using it without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception.

If you want to end an ongoing transaction without turnover (e.g. all items on a receipt are voided) then please use a regular `ftReceiptCase`.

Informations returned in the response are: | [none]
SonstigerVorgang | 1.3- | -| `0x4445000000000003` | **Initial operation receipt / start-receipt**

The request is only valid with the same property requirements as a zero-receipt. It initialises a new fiskaltrust.SecurityMechanism including the used TSE in the background. Depending on the TSE-Type used, this includes different actions.

On successful initialisation, a notification is created which includes the queue-id, scu-id, certificate/public-key, tse-serialnumber=hash(public-key). This notification needs to be reported to the tax administration.

The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.

This receipt case works **only** with **implicit flow**. calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3- | -| `0x4445000000000004` | **Out of operation receipt / stop-receipt**

The request is only valid with the same property requirements as a zero-receipt. It is disabling the fiskaltrust.SecurityMechanism including the deactivation of the client ID used in the TSE for the current queue.
**This request also permanently disables the connected TSE, which is an irreversible action on production TSEs**. Optionally, one can avoid deactivating the TSE using the ftReceiptCaseFlag `0x0000000001000000` (see below).

On successful deactivation, a notification is created which includes the queue-id, scu-id, certificate/public-key, tse-serialnumber=hash(public-key). This notification needs to be reported to tax administration.

The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.

This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3- | -| `0x4445000000000005` | **Monthly-closing**

This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. This is a zero-receipt. It is recommended to send this receipt at the end of each month to define the time of the accounting closure. | [none]
SonstigerVorgang | 1.3- | -| `0x4445000000000006` | **Yearly-closing**

This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3- | -| `0x4445000000000007` | **Daily-closing**

This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. This is a zero-receipt. It is required to send this receipt at the end of each day to define the time of the accounting closure. | [none]
SonstigerVorgang | 1.3- | -| `0x4445000000000008` | **Start-transaction-receipt**

Starts a new, unfinished action. Use `ftChargeItems` and `ftPayItems` to hand over already known details for the final receipt. Using the same `cbReceiptReference` in further calls connects the action items.

This receipt case works **only** with **explicit flow**. Calling with the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
[empty] | 1.3- | -| `0x4445000000000009` | **Update-transaction-receipt**

Updates an ongoing action. Use `ftChargeItems` and `ftPayItems` to hand over all details for the final receipt. Using the same `cbReceiptReference` in further calls connects the action items.

This receipt case works **only** with **explicit flow**. Calling with the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
[empty] | 1.3- | -| `0x444500000000000A` | **Delta-transaction-receipt**

Updates an ongoing action. Use `ftChargeItems` and `ftPayItems` to hand over changes for the final receipt. Using the same `cbReceiptReference` in further calls connects the action items.

This receipt case works **only** on **explicit flow**. Calling with the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
[empty] | 1.3- | -| `0x444500000000000B` | **Fail-transaction-receipt**

Fails an ongoing transaction. It tries to finish either one or multiple open transaction (accepts fail, continue on fail) and clears the `cbReceiptReference <-> Transaction-ID` relations.

To close **single open transactions**, an **explicit** fail-transaction receipt needs to be used. The open transaction needs to be referenced via `cbReceiptReference`. If this value is not provided or no open transaction exists, the fiskaltrust.Middleware will throw an exception and the call will fail.

To close **multiple open transactions**, an **implicit** fail-transaction receipt needs to be sent. This can also be used to close transactions that were not opened by the fiskaltrust.Middleware (e.g. manually during testing). The transaction numbers that should be closed need to be passed via JSON in `ftReceiptCaseData`, using the array property `CurrentStartedTransactionNumbers` (e.g.: `ftReceiptCaseData: "{\"CurrentStartedTransactionNumbers\": [1, 2, 3]}"`). `cbReceiptReference` must be empty in this case, otherwise the fiskaltrust.Middleware will throw an exception and return an error. | AVBelegabbruch
Kassenbeleg-V1 | 1.3- | -| `0x444500000000000C` | **B2B-invoice**

The BON_TYP (Beleg) of DSFinV-K can be overwritten by an `ftReceiptCaseFlag`. | Beleg
Kassenbeleg-V1 | 1.3- | -| `0x444500000000000D` | **B2C-invoice**

The BON_TYP (Beleg) of DSFinV-K can be overwritten by an `ftReceiptCaseFlag`. | Beleg
Kassenbeleg-V1 | 1.3- | -| `0x444500000000000E` | **Info-invoice**

| AVRechnung
Kassenbeleg-V1 | 1.3- | -| `0x444500000000000F` | **Info-delivery-note**

| AVTransfer
Kassenbeleg-V1 | 1.3- | -| `0x4445000000000010` | **Info-order**

To be used when goods are already delivered to customer and the `ftPayItems` array of the request is filled. Usually, this is filled by using `ftPayItemCase` material consumption ('0x444500000000000A').
`(ReceiptRequest.PayItems != [])` | AVBestellung
Kassenbeleg-V1 | 1.3- | -| `0x4445000000000010` | **Info-order**

To be used when recording an ongoing order and the `ftPayItems` array of the request is empty. This request must contain at least one `ftChargeItems` entry, empty `ftChargeItems` array is not allowed.
`(ReceiptRequest.PayItems == [] and ReceiptRequest.ChargeItems != [])` | [none]
Bestellung-V1 | 1.3- | -| `0x4445000000000011` | **Cash deposit / cash pay-in / cash pay-out / exchange**

The BON_TYP (Beleg) of DSFinV-K can be overwritten by an `ftReceiptCaseFlag`. | Beleg
Kassenbeleg-V1 | 1.3- | -| `0x4445000000000012` | **Material consumption**

| AVSachbezug
Kassenbeleg-V1 | 1.3- | +| **Value** | **Description** | **BON_TYP (DSFinV-K)**
**processType (TSE)** | **Middleware Version** | +| --------- | --------------- | --------------------------------------------------- | ----------------------- | +| `0x4445000000000000` | **Unknown type for country-code "DE"**
This receipt case is handled like a "pos-receipt" (`0x4445000000000001`). See below: | Beleg
Kassenbeleg-V1 | 1.3- | +| `0x4445000000000001` | **Pos-receipt**
Represents the main kind of receipt processed by a POS-System. Creates a turnover and/or change in the amount of cash in the till or similar operations.

Use the `ftChargeItems` and `ftPayItems` to hand over details for processing. The `ftChargeItems` and `ftPayItems` should contain the full final state of the receipt. Turnover and cash amount is increased by the final pos-receipt content, intermediate start-transaction, update-transaction and delta-transaction content doesn't influence turnover and cash amount. The pos-receipt case can be used with **implicit and explicit** flow.

The duration of the represented action is calculated using the minimum (start time) and maximum (end time) of datetimes over `ftReceiptRequest`/`ftChargeItems`/`ftPayItems`

The BON_TYP (Beleg) of DSFinV-K can be overwritten by an `ftReceiptCaseFlag`. | Beleg
Kassenbeleg-V1 | 1.3- | +| `0x4445000000000002` | **Zero-receipt**
Used for communication test and functional test of the fiskaltrust.SecurityMechanism. In addition, the response also contains a detailed status information about the used TSE-Device. TSE data is herefore loaded and that may cause a long running request.

The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.

This receipt case works **only** with **implicit** flow. Using it without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception.

If you want to end an ongoing transaction without turnover (e.g. all items on a receipt are voided) then please use a regular `ftReceiptCase`.

Informations returned in the response are: | [none]
SonstigerVorgang | 1.3- | +| `0x4445000000000003` | **Initial operation receipt / start-receipt**
The request is only valid with the same property requirements as a zero-receipt. It initialises a new fiskaltrust.SecurityMechanism including the used TSE in the background. Depending on the TSE-Type used, this includes different actions.

On successful initialisation, a notification is created which includes the queue-id, scu-id, certificate/public-key, tse-serialnumber=hash(public-key). This notification needs to be reported to the tax administration.

The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.

This receipt case works **only** with **implicit flow**. calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3- | +| `0x4445000000000004` | **Out of operation receipt / stop-receipt**
The request is only valid with the same property requirements as a zero-receipt. It is disabling the fiskaltrust.SecurityMechanism including the deactivation of the client ID used in the TSE for the current queue.
**This request also permanently disables the connected TSE, which is an irreversible action on production TSEs**. Optionally, one can avoid deactivating the TSE using the ftReceiptCaseFlag `0x0000000001000000` (see below).

On successful deactivation, a notification is created which includes the queue-id, scu-id, certificate/public-key, tse-serialnumber=hash(public-key). This notification needs to be reported to tax administration.

The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.

This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3- | +| `0x4445000000000005` | **Monthly-closing**
This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. This is a zero-receipt. It is recommended to send this receipt at the end of each month to define the time of the accounting closure. | [none]
SonstigerVorgang | 1.3- | +| `0x4445000000000006` | **Yearly-closing**
This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3- | +| `0x4445000000000007` | **Daily-closing**
This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. This is a zero-receipt. It is required to send this receipt at the end of each day to define the time of the accounting closure. | [none]
SonstigerVorgang | 1.3- | +| `0x4445000000000008` | **Start-transaction-receipt**
Starts a new, unfinished action. Use `ftChargeItems` and `ftPayItems` to hand over already known details for the final receipt. Using the same `cbReceiptReference` in further calls connects the action items.

This receipt case works **only** with **explicit flow**. Calling with the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
[empty] | 1.3- | +| `0x4445000000000009` | **Update-transaction-receipt**
Updates an ongoing action. Use `ftChargeItems` and `ftPayItems` to hand over all details for the final receipt. Using the same `cbReceiptReference` in further calls connects the action items.

This receipt case works **only** with **explicit flow**. Calling with the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
[empty] | 1.3- | +| `0x444500000000000A` | **Delta-transaction-receipt**
Updates an ongoing action. Use `ftChargeItems` and `ftPayItems` to hand over changes for the final receipt. Using the same `cbReceiptReference` in further calls connects the action items.

This receipt case works **only** on **explicit flow**. Calling with the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
[empty] | 1.3- | +| `0x444500000000000B` | **Fail-transaction-receipt**
Fails an ongoing transaction. It tries to finish either one or multiple open transaction (accepts fail, continue on fail) and clears the `cbReceiptReference <-> Transaction-ID` relations.

To close **single open transactions**, an **explicit** fail-transaction receipt needs to be used. The open transaction needs to be referenced via `cbReceiptReference`. If this value is not provided or no open transaction exists, the fiskaltrust.Middleware will throw an exception and the call will fail.

To close **multiple open transactions**, an **implicit** fail-transaction receipt needs to be sent. This can also be used to close transactions that were not opened by the fiskaltrust.Middleware (e.g. manually during testing). The transaction numbers that should be closed need to be passed via JSON in `ftReceiptCaseData`, using the array property `CurrentStartedTransactionNumbers` (e.g.: `ftReceiptCaseData: "{\"CurrentStartedTransactionNumbers\": [1, 2, 3]}"`). `cbReceiptReference` must be empty in this case, otherwise the fiskaltrust.Middleware will throw an exception and return an error. | AVBelegabbruch
Kassenbeleg-V1 | 1.3- | +| `0x444500000000000C` | **B2B-invoice**
The BON_TYP (Beleg) of DSFinV-K can be overwritten by an `ftReceiptCaseFlag`. | Beleg
Kassenbeleg-V1 | 1.3- | +| `0x444500000000000D` | **B2C-invoice**
The BON_TYP (Beleg) of DSFinV-K can be overwritten by an `ftReceiptCaseFlag`. | Beleg
Kassenbeleg-V1 | 1.3- | +| `0x444500000000000E` | **Info-invoice** | AVRechnung
Kassenbeleg-V1 | 1.3- | +| `0x444500000000000F` | **Info-delivery-note** | AVTransfer
Kassenbeleg-V1 | 1.3- | +| `0x4445000000000010` | **Info-order**
To be used when goods are already delivered to customer and the `ftPayItems` array of the request is filled. Usually, this is filled by using `ftPayItemCase` material consumption ('0x444500000000000A').
`(ReceiptRequest.PayItems != [])` | AVBestellung
Kassenbeleg-V1 | 1.3- | +| `0x4445000000000010` | **Info-order**
To be used when recording an ongoing order and the `ftPayItems` array of the request is empty. This request must contain at least one `ftChargeItems` entry, empty `ftChargeItems` array is not allowed.
`(ReceiptRequest.PayItems == [] and ReceiptRequest.ChargeItems != [])` | [none]
Bestellung-V1 | 1.3- | +| `0x4445000000000011` | **Cash deposit / cash pay-in / cash pay-out / exchange**
The BON_TYP (Beleg) of DSFinV-K can be overwritten by an `ftReceiptCaseFlag`. | Beleg
Kassenbeleg-V1 | 1.3- | +| `0x4445000000000012` | **Material consumption** | AVSachbezug
Kassenbeleg-V1 | 1.3- | | `0x4445000000000013` | **Info-internal**

First case: "charge items and pay items exist"
`(ReceiptRequest.ChargePayItems != [] && ReceiptRequest.PayItems != [])` | AVSonstige
Kassenbeleg-V1 | 1.3- | -| `0x4445000000000013` | **Info-internal**

Second case: "no charge items or no pay items"
`(ReceiptRequest.ChargePayItems == [] \|\| ReceiptRequest.PayItems == [])` | [none]
SonstigerVorgang | 1.3- | -| `0x4445000000000014` | **Protocol**

| [none]
SonstigerVorgang | 1.3- | -| `0x4445000000000015` | **Foreign sales**

| To be used in case of a sale in a country where there is no need to fiscalize. For example you have a German foodtruck and goes to Hungary and sell food there.
Kassenbeleg-V1 | 1.3- | -| `0x4445000000000016` | **Cancel/void a receipt**

Please note that according to the DSFinV-K, this receipt type can only be used on systems **without** a TSE. For "regular" cancellations, please use the respective _ftReceiptCaseFlag_. | AVBelegstorno
Kassenbeleg-V1 | 1.3.14- | -| `0x4445000000000017` | **Initiate SCU switch**

This request is only valid with the same property requirements as a zero-receipt and can only be used after the SCU switch process was initiated in the fiskaltrust.Portal ([click here for more details](https://link.fiskaltrust.cloud/market-de/scu-switch)). It disconnects the Queue from the currently used, "old" SCU, hence preparing it for connecting another SCU. To finish this process, a _finish SCU switch_ receipt has to be called (see below). After sending this receipt, the Middleware will not contact the SCU/TSE and returns the _ftState_ `0x0000000000000008` until the _finish SCU switch_ receipt is sent.

On successful execution, a notification is created which includes relevant data for financial authority notifications.

The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.

This receipt case works **only** with **implicit flow**. Calling it without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception.

Please note that like the _out-of-operation receipt_, this receipt deactivates the currently used TSE by default. To avoid this, please use the respective _ftReceiptCaseFlag_. | [none]
SonstigerVorgang | 1.3.19- | -| `0x4445000000000018` | **Finish SCU switch**

This request is only valid with the same property requirements as a zero-receipt and can only be used after the SCU switch process was initiated in the fiskaltrust.Portal and an _initiate SCU switch_ receipt was sent ([click here for more details](https://link.fiskaltrust.cloud/market-de/scu-switch)). It connects the Queue to the new SCU, finishing the SCU switch process and making the Middleware operational again.

On successful execution, a notification is created which includes relevant data for financial authority notifications.

The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.

This receipt case works **only** with **implicit flow**. Calling it without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3.19- | -| `0x4445000000000019` | **Prepare Queue for (cloud) migration**

This request is only valid with the same property requirements as a zero-receipt. It permanently sets the currently installed instance of this Queue (on the current machine) to readonly-mode to prepare it for the migration to another runtime environment, e.g. to the CloudCashbox. This is required to prevent concurrent signatures on different instances; the migration wizard in the fiskaltrust.Portal will verify that the last receipt sent to the Queue is of this type before performing the actual migration.
Please note that this receipt will prevent any further sign operations in the current installed version of the Queue, and signing will only be again possible after the Queue was migrated to e.g. the CloudCashbox.

The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.

This receipt case works **only** with **implicit flow**. Calling it without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3.64- | +| `0x4445000000000013` | **Info-internal**
Second case: "no charge items or no pay items"
`(ReceiptRequest.ChargePayItems == [] \|\| ReceiptRequest.PayItems == [])` | [none]
SonstigerVorgang | 1.3- | +| `0x4445000000000014` | **Protocol** | [none]
SonstigerVorgang | 1.3- | +| `0x4445000000000015` | **Foreign sales**
To be used in case of a sale in a country where there is no need to fiscalize. For example you have a German foodtruck and goes to Hungary and sell food there. | Kassenbeleg-V1 | 1.3- | +| `0x4445000000000016` | **Cancel/void a receipt**
Note that according to the DSFinV-K, this receipt type can only be used on systems **without** a TSE. For "regular" cancellations, use the respective _ftReceiptCaseFlag_. | AVBelegstorno
Kassenbeleg-V1 | 1.3.14- | +| `0x4445000000000017` | **Initiate SCU switch**
This request is only valid with the same property requirements as a zero-receipt and can only be used after the SCU switch process was initiated in the fiskaltrust.Portal ([click here for more details](https://link.fiskaltrust.cloud/market-de/scu-switch)). It disconnects the Queue from the currently used, "old" SCU, hence preparing it for connecting another SCU. To finish this process, a _finish SCU switch_ receipt has to be called (see below). After sending this receipt, the Middleware will not contact the SCU/TSE and returns the _ftState_ `0x0000000000000008` until the _finish SCU switch_ receipt is sent.

On successful execution, a notification is created which includes relevant data for financial authority notifications.

The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.

This receipt case works **only** with **implicit flow**. Calling it without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception.

Note that like the _out-of-operation receipt_, this receipt deactivates the currently used TSE by default. To avoid this, please use the respective _ftReceiptCaseFlag_. | [none]
SonstigerVorgang | 1.3.19- | +| `0x4445000000000018` | **Finish SCU switch**
This request is only valid with the same property requirements as a zero-receipt and can only be used after the SCU switch process was initiated in the fiskaltrust.Portal and an _initiate SCU switch_ receipt was sent ([click here for more details](https://link.fiskaltrust.cloud/market-de/scu-switch)). It connects the Queue to the new SCU, finishing the SCU switch process and making the Middleware operational again.

On successful execution, a notification is created which includes relevant data for financial authority notifications.

The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.

This receipt case works **only** with **implicit flow**. Calling it without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3.19- | +| `0x4445000000000019` | **Prepare Queue for (cloud) migration**
This request is only valid with the same property requirements as a zero-receipt. It permanently sets the currently installed instance of this Queue (on the current machine) to readonly-mode to prepare it for the migration to another runtime environment, e.g. to the CloudCashbox. This is required to prevent concurrent signatures on different instances; the migration wizard in the fiskaltrust.Portal will verify that the last receipt sent to the Queue is of this type before performing the actual migration.
Note that this receipt will prevent any further sign operations in the current installed version of the Queue, and signing will only be again possible after the Queue was migrated to e.g. the CloudCashbox.

The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.

This receipt case works **only** with **implicit flow**. Calling it without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3.64- | ## ftReceiptCaseFlag -This table expands on the values provided in table [ftReceiptCaseFlag in General Part](../../general/reference-tables/reference-tables.md#ftreceiptcaseflag) with values applicable to the German market. -| Value | Description | Middleware-Version | -|-------|-------------|--------------------| -| 0x0000000000010000 | **Failed receipt**
Using this flag will enable the late signing mode `ftState` `0x0000000000000008` , this ftState is only returned when the mentioned flag is included into the receipts. A zero receipt is necessary to solve the situation even if the middleware responds with `ftState` `0x0000000000000000` This is described in the [Failure scenarios](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/general/cash-register-integration/failure-scenarios#failure-scenarios) . | 1.3- | -| 0x0000000000020000 | **Training receipt**
DSFinV-K: overrides BON_TYP=AVTraining | 1.3- | -| 0x0000000000040000 | **Reverse/voided receipt**
To cancel a receipt, resend it with this flag added to the _ftReceiptCase_ and inverse the _cbPayItems_ or _cbChargeItems_ (**This is not the same behavior as described in the [general part](../../general/reference-tables/reference-tables.md#ftreceiptcaseflag)** — in Germany, this flag requires **only one** of _cbPayItems_ or _cbChargeItems_ to be negative, and **both must not be negative at the same time**). In the DSFinV-K export, this flag will set the column `BON_STORNO` to `true`.
In Middleware versions lower than 1.3.14, this flag created a receipt with the BON_TYP _AVBelegStorno_. This behavior got replaced by a separate _ftReceiptCase_. | 1.3- | -| 0x0000000000080000 | **paper/handwritten receipt** | 1.3- | -| 0x0000000000100000 | **Small business, not taxable sales.** | 1.3- | -| 0x0000000000200000 | **Receiver is a company** | 1.3- | -| 0x0000000000400000 | **Contains characteristics related to UStG.** | 1.3- | -| 0x0000000000800000 | **Requests additional information from a used TSE device.** This flag applies to zero-receipts only and responses a `TseInfo` entry in `ftStateData` field. Content of this item is same as declared in the IDESSCD interface described at [github.com/fiskaltrust](https://github.com/fiskaltrust/middleware-interface-dotnet/blob/master/src/fiskaltrust.ifPOS/v1/de/Models/TseInfo.cs) | 1.3.1 | -| 0x0000000001000000 | **Requests `ExecuteSelftest` and `ExecuteTimeUpdate` from a used TSE device.**
This flag applies to zero-receipts only and initiates a self-test and time-update at the used TSE device. Some devices (e.g. Swissbit) require a self-test periodically (e.g. every 25 hours for Swissbit). On some devices, this self-test is time-consuming (e.g. up to 2 minutes on Swissbit). To not block the receipt generation, a pos-system can trigger the self-test during off-peak service hours.
If the pos-system does not use this flag, the fiskaltrust.Middleware takes care of the self-test execution and time-update. | 1.3.1 | -| 0x0000000001000000 | **Requests `clientId` registration only.**
This flag applies to _initial-operation_ and _finish SCU switch_ receipts only. If one of these receipts is executed with this flag set, no lifecycle-check is done for the connected TSE-device, and no initialization is triggered. Use this flag to register the current `cbCashBoxIdentification` of the queue as a `clientId` at the TSE-device, if the device is already properly initialized. | 1.3.1 | -| 0x0000000001000000 | **Requests `clientId` de-registration only.**
This flag applies to _out-of-operations_ and _initiate SCU switch_ receipts only. A receipt executed with this flag only de-registers the current `cbCashBoxIdentification` of the queue as a `clientId` at the TSE-device without deactivating the TSE. Use this flag if the TSE-device should remain in an initialized lifecycle to use it with a different queue for further operations.
"De-registration only" is not supported by all TSE-devices.
The normal behavior of out-of-operation-receipts to disable the queue is not influenced by this flag. The queue will not be useable anymore after executing an out-of-operations-receipt. | 1.3.1 | -| 0x0000000002000000 | **Requests a download of the TSE-device TAR file.**
This flag applies to zero-receipts only and processes a data-download from the TSE-device. It also triggers a data-upload to the fiskaltrust.Cloud to provide the latest TAR file data on the fiskaltrust.Portal for tax audits.
A TSE-device TAR file download is time-consuming and may take more than 10 minutes to complete. It requires not to run any other TSE-device operations to be successful.
If the pos-system does not use this flag, the fiskaltrust.Middleware takes care of the TAR file download after executing the daily-, monthly-, and yearly-closing. | 1.3.8 | -| 0x0000000004000000 | **Requests to bypass the download of a TSE-device TAR file.**
This flag applies to daily-, monthly-, and yearly-closings only. A TSE-device TAR file download is time-consuming and may take more than 10 minutes to complete. It requires not to run any other TSE-device operations to be successful. This flag can be used to bypass a TSE-device TAR file download and keep the TSE-device usable for immediate receipt signing requests. | 1.3.8 | -| 0x0000000008000000 | **Requests to update the master data.**
This flag applies to daily-, monthly-, and yearly-closings only. The fiskaltrust.Middleware pulls changes in the master data provided by the fiskaltrust.Portal after a rebuild of the configuration. The master data changes will be included in the next successful execution of a daily-, monthly-, or yearly-closing.
Master data is determined by the fiskaltrust.Portal. Manual changes and updates can be made by the UI of the fiskaltrust-portal; automated changes and updates will be possible by API.
This flag gives a local point-of-sale-terminal the possibility to execute previously prepared master-data changes. A default implementation could be to execute this flag before each daily-closing to receive changes as soon as the cashbox/queue reflects them without restarting the fiskaltrust-Middleware. | 1.3.4 | -| 0x0000000010000000 | **Requests to throw an exception if any transactions are open.**
Open transactions are automatically closed by the fiskaltrust.Middleware when sending a daily-closing receipt because TSE-devices usually have a low limit of concurrent open transactions allowed.
When sending this flag, transactions will not be closed, but an exception will be thrown if any are open, to manage open transactions within the pos-system. | 1.3.1 | -| 0x0000000020000000 | **Requests to close transactions that are marked open in the Middleware's database, but not open in the TSE.**
This flag applies to _daily-closing_ and _zero_ receipts (if in failed mode) only and can be used to unblock the closing in case of a power- or network failure that lead to an inconsistent state between Middleware and TSE (e.g. when the TSE finished a transaction, but the network failed and the Middleware could not read the result). It should not be used per default to avoid hiding recurring issues of this kind. | 1.3.16 (Support for zero receipts was added in version 1.3.23) | -| 0x0000000040000000 | **Requests to bypass TSEInfo-Call on initiate-SCU-switch**
This flag applies to _initiate-SCU-switch_ only and can be used to unblock the SCU-switch in case the Middleware is not able to recover from "SSCD failed" mode but the TSEInfo-Call is successful. It should not be used per default to avoid hiding recurring issues of this kind. | 1.3.47| -| 0x0000000100000000 | **Implicit Transaction.**
No Start-Transaction call to the `Sign` method is required, it is done implicitly. If the unique identifier set in property `cbReceiptReference` already started a transaction, this will throw an exception. | 1.3.0 | -| 0x0000000200000000 | **Close transactions on daily closing**
This receiptCaseFlag for Daily-Closing will closes all open transactions on the TSE when a dailyclosing is done. This solves the problem of open transactions from other queues, in a setup where multiple queues are used on one tse. | 1.3.75 | -| 0x0000800000000000 | **Receipt request**
Used to retrieve an already processed receipt from the fiskaltrust.Middleware using the `cbReceiptReference` field. The `cbTerminalID` can also be included in this request. ChargeItems and PayItems must be exactly the same as in the requested receipt. If a matching receipt is found, its content will be returned. If no matching receipt is found, a null value is returned. This may be necessary if a communication problem occurs while the fiskaltrust.Middleware processes a request. | 1.3- | +This table expands on the values provided in table [ftReceiptCaseFlag](../../general/reference-tables/reference-tables.md#ftreceiptcaseflag) of the Compliance Middleware with values applicable to the German market. + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x0000000000010000` | **Failed receipt**
Using this flag will enable the late signing mode `ftState` `0x0000000000000008`, this ftState is only returned when the mentioned flag is included into the receipts. A zero receipt is necessary to solve the situation even if the middleware responds with `ftState` `0x0000000000000000` This is described in the [Failure scenarios](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/general/cash-register-integration/failure-scenarios#failure-scenarios) . | 1.3- | +| `0x0000000000020000` | **Training receipt**
DSFinV-K: overrides BON_TYP=AVTraining | 1.3- | +| `0x0000000000040000` | **Reverse/voided receipt**
To cancel a receipt, resend it with this flag added to the _ftReceiptCase_ and inverse the _cbPayItems_ or _cbChargeItems_ (**This is not the same behavior as described in the [general part](../../general/reference-tables/reference-tables.md#ftreceiptcaseflag)** — in Germany, this flag requires **only one** of _cbPayItems_ or _cbChargeItems_ to be negative, and **both must not be negative at the same time**). In the DSFinV-K export, this flag will set the column `BON_STORNO` to `true`.
In Middleware versions lower than 1.3.14, this flag created a receipt with the BON_TYP _AVBelegStorno_. This behavior got replaced by a separate _ftReceiptCase_. | 1.3- | +| `0x0000000000080000` | **Paper/handwritten receipt** | 1.3- | +| `0x0000000000100000` | **Small business, not taxable sales** | 1.3- | +| `0x0000000000200000` | **Receiver is a company** | 1.3- | +| `0x0000000000400000` | **Contains characteristics related to UStG** | 1.3- | +| `0x0000000000800000` | **Requests additional information from a used TSE device**
This flag applies to zero-receipts only and responses a `TseInfo` entry in `ftStateData` field. Content of this item is same as declared in the IDESSCD interface described at [github.com/fiskaltrust](https://github.com/fiskaltrust/middleware-interface-dotnet/blob/master/src/fiskaltrust.ifPOS/v1/de/Models/TseInfo.cs) | 1.3.1 | +| `0x0000000001000000` | **Requests `ExecuteSelftest` and `ExecuteTimeUpdate` from a used TSE device**
This flag applies to zero-receipts only and initiates a self-test and time-update at the used TSE device. Some devices (e.g. Swissbit) require a self-test periodically (e.g. every 25 hours for Swissbit). On some devices, this self-test is time-consuming (e.g. up to 2 minutes on Swissbit). To not block the receipt generation, a pos-system can trigger the self-test during off-peak service hours.
If the pos-system does not use this flag, the fiskaltrust.Middleware takes care of the self-test execution and time-update. | 1.3.1 | +| `0x0000000001000000` | **Requests `clientId` registration only**
This flag applies to _initial-operation_ and _finish SCU switch_ receipts only. If one of these receipts is executed with this flag set, no lifecycle-check is done for the connected TSE-device, and no initialization is triggered. Use this flag to register the current `cbCashBoxIdentification` of the queue as a `clientId` at the TSE-device, if the device is already properly initialized. | 1.3.1 | +| `0x0000000001000000` | **Requests `clientId` de-registration only**
This flag applies to _out-of-operations_ and _initiate SCU switch_ receipts only. A receipt executed with this flag only de-registers the current `cbCashBoxIdentification` of the queue as a `clientId` at the TSE-device without deactivating the TSE. Use this flag if the TSE-device should remain in an initialized lifecycle to use it with a different queue for further operations.
"De-registration only" is not supported by all TSE-devices.
The normal behavior of out-of-operation-receipts to disable the queue is not influenced by this flag. The queue will not be useable anymore after executing an out-of-operations-receipt. | 1.3.1 | +| `0x0000000002000000` | **Requests a download of the TSE-device TAR file**
This flag applies to zero-receipts only and processes a data-download from the TSE-device. It also triggers a data-upload to the fiskaltrust.Cloud to provide the latest TAR file data on the fiskaltrust.Portal for tax audits.
A TSE-device TAR file download is time-consuming and may take more than 10 minutes to complete. It requires not to run any other TSE-device operations to be successful.
If the pos-system does not use this flag, the fiskaltrust.Middleware takes care of the TAR file download after executing the daily-, monthly-, and yearly-closing. | 1.3.8 | +| `0x0000000004000000` | **Requests to bypass the download of a TSE-device TAR file**
This flag applies to daily-, monthly-, and yearly-closings only. A TSE-device TAR file download is time-consuming and may take more than 10 minutes to complete. It requires not to run any other TSE-device operations to be successful. This flag can be used to bypass a TSE-device TAR file download and keep the TSE-device usable for immediate receipt signing requests. | 1.3.8 | +| `0x0000000008000000` | **Requests to update the master data**
This flag applies to daily-, monthly-, and yearly-closings only. The fiskaltrust.Middleware pulls changes in the master data provided by the fiskaltrust.Portal after a rebuild of the configuration. The master data changes will be included in the next successful execution of a daily-, monthly-, or yearly-closing.
Master data is determined by the fiskaltrust.Portal. Manual changes and updates can be made by the UI of the fiskaltrust-portal; automated changes and updates will be possible by API.
This flag gives a local point-of-sale-terminal the possibility to execute previously prepared master-data changes. A default implementation could be to execute this flag before each daily-closing to receive changes as soon as the cashbox/queue reflects them without restarting the fiskaltrust-Middleware. | 1.3.4 | +| `0x0000000010000000` | **Requests to throw an exception if any transactions are open**
Open transactions are automatically closed by the fiskaltrust.Middleware when sending a daily-closing receipt because TSE-devices usually have a low limit of concurrent open transactions allowed.
When sending this flag, transactions will not be closed, but an exception will be thrown if any are open, to manage open transactions within the pos-system. | 1.3.1 | +| `0x0000000020000000` | **Requests to close transactions that are marked open in the Middleware's database, but not open in the TSE**
This flag applies to _daily-closing_ and _zero_ receipts (if in failed mode) only and can be used to unblock the closing in case of a power- or network failure that lead to an inconsistent state between Middleware and TSE (e.g. when the TSE finished a transaction, but the network failed and the Middleware could not read the result). It should not be used per default to avoid hiding recurring issues of this kind. | 1.3.16 (Support for zero receipts was added in version 1.3.23) | +| `0x0000000040000000` | **Requests to bypass TSEInfo-Call on initiate-SCU-switch**
This flag applies to _initiate-SCU-switch_ only and can be used to unblock the SCU-switch in case the Middleware is not able to recover from "SSCD failed" mode but the TSEInfo-Call is successful. It should not be used per default to avoid hiding recurring issues of this kind. | 1.3.47 | +| `0x0000000100000000` | **Implicit Transaction**
No Start-Transaction call to the `Sign` method is required, it is done implicitly. If the unique identifier set in property `cbReceiptReference` already started a transaction, this will throw an exception. | 1.3.0 | +| `0x0000000200000000` | **Close transactions on daily closing**
This receiptCaseFlag for Daily-Closing will closes all open transactions on the TSE when a dailyclosing is done. This solves the problem of open transactions from other queues, in a setup where multiple queues are used on one tse. | 1.3.75 | +| `0x0000800000000000` | **Receipt request**
Used to retrieve an already processed receipt from the fiskaltrust.Middleware using the `cbReceiptReference` field. The `cbTerminalID` can also be included in this request. ChargeItems and PayItems must be exactly the same as in the requested receipt. If a matching receipt is found, its content will be returned. If no matching receipt is found, a null value is returned. This may be necessary if a communication problem occurs while the fiskaltrust.Middleware processes a request. | 1.3- | diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-service-ftchargeitemcase.md index 8964695..1847a8e 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-service-ftchargeitemcase.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-service-ftchargeitemcase.md @@ -1,153 +1,153 @@ --- slug: /poscreators/middleware-doc/germany/reference-tables/ftchargeitemcase -title: 'Type of service: 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 German market. +This table expands on the values provided in the table [ftChargeItemCase](../../general/reference-tables/reference-tables.md#type-of-service-ftchargeitemcase) of the Compliance Middleware, with country-specific values applicable to the German market. -| **Value** | **Description** | **UST_SCHLUESSEL (DSFinV-K)** | **GV_TYP (DSFinV-K)** | **Service-Version** | -|---|---|---|---|---| +| **Value** | **Description** | **UST_SCHLUESSEL (DSFinV-K)** | **GV_TYP (DSFinV-K)** | **Middleware Version** | +| --- | --- | --- | --- | --- | | `0x4445000000000000` | Unknown type of service for DE | 7 | Umsatz | 1.3- | -| `0x4445000000000001` | Undefined type of service for DE normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | Umsatz | 1.3- | -| `0x4445000000000002` | Undefined type of service for DE discounted-1
1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | Umsatz | 1.3- | -| `0x4445000000000003` | Undefined type of service for DE special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | Umsatz | 1.3- | -| `0x4445000000000004` | Undefined type of service for DE special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | Umsatz | 1.3- | -| `0x4445000000000005` | Undefined type of service for DE not taxable | 5 | Umsatz | 1.3- | -| `0x4445000000000006` | Undefined type of service for DE zero | 6 | Umsatz | 1.3- | +| `0x4445000000000001` | Undefined type of service for DE normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | Umsatz | 1.3- | +| `0x4445000000000002` | Undefined type of service for DE discounted-1
1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | Umsatz | 1.3- | +| `0x4445000000000003` | Undefined type of service for DE special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | Umsatz | 1.3- | +| `0x4445000000000004` | Undefined type of service for DE special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | Umsatz | 1.3- | +| `0x4445000000000005` | Undefined type of service for DE not taxable | 5 | Umsatz | 1.3- | +| `0x4445000000000006` | Undefined type of service for DE zero | 6 | Umsatz | 1.3- | | `0x4445000000000007` | Undefined type of service for DE unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | Umsatz | 1.3- | -| `0x4445000000000011` | Delivery normal. For processing, see (0x4445000000000001) | 1 | Umsatz | 1.3- | -| `0x4445000000000012` | Delivery discounted-1. For processing, see (0x4445000000000002) | 2 | Umsatz | 1.3- | -| `0x4445000000000013` | Delivery special-1. For processing, see (0x4445000000000003) | 3 | Umsatz | 1.3- | -| `0x4445000000000014` | Delivery special-2. For processing, see (0x4445000000000004) | 4 | Umsatz | 1.3- | +| `0x4445000000000011` | Delivery normal. For processing, see (0x4445000000000001) | 1 | Umsatz | 1.3- | +| `0x4445000000000012` | Delivery discounted-1. For processing, see (0x4445000000000002) | 2 | Umsatz | 1.3- | +| `0x4445000000000013` | Delivery special-1. For processing, see (0x4445000000000003) | 3 | Umsatz | 1.3- | +| `0x4445000000000014` | Delivery special-2. For processing, see (0x4445000000000004) | 4 | Umsatz | 1.3- | | `0x4445000000000015` | Delivery not taxable. For processing, see (0x4445000000000005) | 5 | Umsatz | 1.3- | | `0x4445000000000016` | Delivery zero. For processing, see (0x4445000000000005) | 6 | Umsatz | 1.3- | | `0x4445000000000017` | Delivery unknown vat. For processing, see (0x4445000000000007) | 7 or > 1000 | Umsatz | 1.3- | -| `0x4445000000000019` | Other services normal. For processing, see (0x4445000000000003) | 1 | Umsatz | 1.3- | -| `0x444500000000001A` | Other services discounted-1.For processing, see (0x4445000000000001) | 2 | Umsatz | 1.3- | -| `0x444500000000001B` | Other services special-1. For processing, see (0x4445000000000004) | 3 | Umsatz | 1.3- | -| `0x444500000000001C` | Other services special-2. For processing, see (0x4445000000000002) | 4 | Umsatz | 1.3- | -| `0x444500000000001D` | Other services not taxable. For processing, see (0x4445000000000005) | 5 | Umsatz | 1.3- | -| `0x444500000000001E` | Other services zero. For processing, see (0x4445000000000005) | 6 | Umsatz | 1.3- | -| `0x444500000000001F` | Other services unknown vat. For processing, see (0x4445000000000007) | 7 or > 1000 | Umsatz | 1.3- | -| `0x4445000000000021` | Returnable normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) |1|Pfand | 1.3- | -| `0x4445000000000022` | Returnable discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | Pfand | 1.3- | -| `0x4445000000000023` | Returnable special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) |3|Pfand | 1.3- | -| `0x4445000000000024` | Returnable special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) |4|Pfand | 1.3- | -| `0x4445000000000025` | Returnable not taxable |5|Pfand 1.3- || -| `0x4445000000000026` | returnable zero |6|Pfand | 1.3- | -| `0x4445000000000027` | Returnable vat unknown.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` |7 or > 1000|Pfand 1.3- || -| `0x4445000000000029` | Returnable reverse normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) |1|PfandRueckzahlung | 1.3- | -| `0x444500000000002A` | Returnable reverse discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) |2|PfandRueckzahlung | 1.3- | -| `0x444500000000002B` | Returnable reverse special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) |3|PfandRueckzahlung | 1.3- | -| `0x444500000000002C` | Returnable reverse special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) |4|PfandRueckzahlung | 1.3- | -| `0x444500000000002D` | Returnable reverse not taxable|5|PfandRueckzahlung |1.3- | -| `0x444500000000002E` | Returnable reverse zero|6|PfandRueckzahlung |1.3- | -| `0x444500000000002F` | Returnable reverse vat unknown.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000`|7 or > 1000|PfandRueckzahlung |1.3- | -| `0x4445000000000031` | Discount normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) |1|Rabatt | 1.3- | -| `0x4445000000000032` | Discount discounted-1 . 1.1.2019: 7% (DE: Ermäßigter Steuersatz) |2|Rabatt | 1.3-| -| `0x4445000000000033` | Discount special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) |3|Rabatt | 1.3- | -| `0x4445000000000034` | Discount special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) |4|Rabatt | 1.3- | -| `0x4445000000000035` | Discount not taxable |5|Rabatt | 1.3- | -| `0x4445000000000036` | Discount zero |6|Rabatt | 1.3- | -| `0x4445000000000037` | Discount unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` |7 or > 1000|Rabatt | 1.3- | -| `0x4445000000000039` | Extra charge normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) |1|Aufschlag | 1.3- | -| `0x444500000000003A` | Extra charge discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) |2|Aufschlag | 1.3-| -| `0x444500000000003B` | Extra charge special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) |3|Aufschlag | 1.3- | -| `0x444500000000003C` | Extra charge special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) |4|Aufschlag | 1.3- | -| `0x444500000000003D` | Extra charge not taxable |5|Aufschlag | 1.3- | -| `0x444500000000003E` | Extra charge zero |6|Aufschlag | 1.3- | -| `0x444500000000003F` | Extra charge unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` |7 or > 1000 |Aufschlag | 1.3- | -| `0x4445000000000041` | Unreal grant normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) |1|ZuschussUnecht | 1.3- | -| `0x4445000000000042` | Unreal grant discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) |2|ZuschussUnecht | 1.3-| -| `0x4445000000000043` | Unreal grant special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) |3|ZuschussUnecht | 1.3- | -| `0x4445000000000044` | Unreal grant special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) |4|ZuschussUnecht | 1.3- | -| `0x4445000000000045` | Unreal grant not taxable |5|ZuschussUnecht | 1.3- | -| `0x4445000000000046` | Unreal grant zero |6|ZuschussUnecht | 1.3- | -| `0x4445000000000047` | Unreal grant unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` |7 or > 1000|ZuschussUnecht | 1.3- | -| `0x4445000000000049` | Real grant not taxable | 5 |ZuschussEcht | 1.3- | -| `0x4445000000000051` | Tip to owner normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) |1|TrinkgeldAG | 1.3- | -| `0x4445000000000052` | Tip to owner discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) |2|TrinkgeldAG | 1.3-| -| `0x4445000000000053` | Tip to owner special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) |3|TrinkgeldAG | 1.3- | -| `0x4445000000000054` | Tip to owner special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) |4|TrinkgeldAG | 1.3- | -| `0x4445000000000055` | Tip to owner not taxable |5|TrinkgeldAG | 1.3- | -| `0x4445000000000056` | Tip to owner zero |6|TrinkgeldAG | 1.3- | -| `0x4445000000000057` | Tip to owner unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` |7 or > 1000|TrinkgeldAG | 1.3- | -| `0x4445000000000059` | Tip to employee no vat | 5 |TrinkgeldAN | 1.3- | -| `0x4445000000000060` | Voucher sale not taxable | 5 |MehrzweckgutscheinKauf | 1.3- | -| `0x4445000000000061` | Coupon sales normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) |1|EinzweckgutscheinKauf | 1.3- | -| `0x4445000000000062` | Coupon sales discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) |2|EinzweckgutscheinKauf | 1.3-| -| `0x4445000000000063` | Coupon sales special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) |3|EinzweckgutscheinKauf | 1.3- | -| `0x4445000000000064` | Coupon sales special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) |4|EinzweckgutscheinKauf | 1.3- | -| `0x4445000000000065` | Coupon sales not taxable |5|EinzweckgutscheinKauf | 1.3- | -| `0x4445000000000066` | Coupon sales zero |6|EinzweckgutscheinKauf | 1.3- | -| `0x4445000000000067` | Coupon sales unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` |7 or > 1000|EinzweckgutscheinKauf | 1.3- | -| `0x4445000000000068` | Voucher redeem not taxable | 5 |MehrzweckgutscheinEinloesung | 1.3- | -| `0x4445000000000069` | Coupon redeem normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) |1|EinzweckgutscheinEinloesung | 1.3- | -| `0x444500000000006A` | Coupon redeem discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) |2|EinzweckgutscheinEinloesung | 1.3-| -| `0x444500000000006B` | Coupon redeem special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) |3|EinzweckgutscheinEinloesung | 1.3- | -| `0x444500000000006C` | Coupon redeem special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) |4|EinzweckgutscheinEinloesung | 1.3- | -| `0x444500000000006D` | Coupon redeem not taxable |5|EinzweckgutscheinEinloesung | 1.3- | -| `0x444500000000006E` | Coupon redeem zero |6|EinzweckgutscheinEinloesung | 1.3- | -| `0x444500000000006F` | Coupon redeem unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` |7 or > 1000|EinzweckgutscheinEinloesung | 1.3- | -| `0x4445000000000071` | Receivable creation normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) |1|Forderungsentstehung | 1.3- | -| `0x4445000000000072` | Receivable creation discounted-1 . 1.1.2019: 7% (DE: Ermäßigter Steuersatz) |2|Forderungsentstehung | 1.3-| -| `0x4445000000000073` | Receivable creation special-1. 1.1.2019: 10,70% (DE: Durchschnittssatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) |3|Forderungsentstehung | 1.3- | -| `0x4445000000000074` | Receivable creation special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) |4|Forderungsentstehung | 1.3- | -| `0x4445000000000075` | Receivable creation not taxable |5|Forderungsentstehung | 1.3- | -| `0x4445000000000076` | Receivable creation zero |6|Forderungsentstehung | 1.3- | -| `0x4445000000000077` | Receivable creation unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` |7 or > 1000|Forderungsentstehung | 1.3- | -| `0x4445000000000079` | Receivable reduction normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) |1|Forderungsaufloesung | 1.3- | -| `0x444500000000007A` | Receivable reduction discounted-1 . 1.1.2019: 7% (DE: Ermäßigter Steuersatz) |2|Forderungsaufloesung | 1.3-| -| `0x444500000000007B` | Receivable reduction special-1 . 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) |3|Forderungsaufloesung | 1.3- | -| `0x444500000000007C` | Receivable reduction special-2 . 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) |4|Forderungsaufloesung | 1.3- | -| `0x444500000000007D` | Receivable reduction not taxable |5|Forderungsaufloesung | 1.3- | -| `0x444500000000007E` | Receivable reduction zero |6|Forderungsaufloesung | 1.3- | -| `0x444500000000007F` | Receivable reduction unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` |7 or > 1000|Forderungsaufloesung | 1.3- | -| `0x4445000000000081` | Down payment creation normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) |1|Anzahlungseinstellung | 1.3- | -| `0x4445000000000082` | Down payment creation discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) |2|Anzahlungseinstellung | 1.3-| -| `0x4445000000000083` | Down payment creation special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) |3|Anzahlungseinstellung | 1.3- | -| `0x4445000000000084` | Down payment creation special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) |4|Anzahlungseinstellung | 1.3- | -| `0x4445000000000085` | Down payment creation not taxable |5|Anzahlungseinstellung | 1.3- | -| `0x4445000000000086` | Down payment creation zero |6|Anzahlungseinstellung | 1.3- | -| `0x4445000000000087` | Down payment creation unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` |7 or > 1000|Anzahlungseinstellung | 1.3- | -| `0x4445000000000089` | Down payment reduction normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) |1|Anzahlungsaufloesung | 1.3- | -| `0x444500000000008A` | Down payment reduction discounted-1 . 1.1.2019: 7% (DE: Ermäßigter Steuersatz) |2|Anzahlungsaufloesung | 1.3-| -| `0x444500000000008B` | Down payment reduction special-1 . 1.1.2019: 10,70% (DE: Durchschnittssatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) |3|Anzahlungsaufloesung | 1.3- | -| `0x444500000000008C` | Down payment reduction special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) |4|Anzahlungsaufloesung | 1.3- | -| `0x444500000000008D` | Down payment reduction not taxable |5|Anzahlungsaufloesung | 1.3- | -| `0x444500000000008E` | Down payment reduction zero |6|Anzahlungsaufloesung | 1.3- | -| `0x444500000000008F` | Down payment reduction unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` |7 or > 1000|Anzahlungsaufloesung | 1.3- | -| `0x4445000000000090` | Cash transfer to empty till not taxable | 5 |Anfangsbestand | 1.3- | -| `0x4445000000000091` | Cash transfer from till to owner not taxable | 5 |Privatentnahme | 1.3- | -| `0x4445000000000092` | Cash transfer from owner to till not taxable | 5 |Privateinlage | 1.3- | -| `0x4445000000000093` | Cash transfer from/to till not taxable | 5 |Geldtransit | 1.3- | -| `0x4445000000000094` | Cash transfer from till to employee not taxable | 5 |Lohnzahlung | 1.3- | +| `0x4445000000000019` | Other services normal. For processing, see (0x4445000000000003) | 1 | Umsatz | 1.3- | +| `0x444500000000001A` | Other services discounted-1.For processing, see (0x4445000000000001) | 2 | Umsatz | 1.3- | +| `0x444500000000001B` | Other services special-1. For processing, see (0x4445000000000004) | 3 | Umsatz | 1.3- | +| `0x444500000000001C` | Other services special-2. For processing, see (0x4445000000000002) | 4 | Umsatz | 1.3- | +| `0x444500000000001D` | Other services not taxable. For processing, see (0x4445000000000005) | 5 | Umsatz | 1.3- | +| `0x444500000000001E` | Other services zero. For processing, see (0x4445000000000005) | 6 | Umsatz | 1.3- | +| `0x444500000000001F` | Other services unknown vat. For processing, see (0x4445000000000007) | 7 or > 1000 | Umsatz | 1.3- | +| `0x4445000000000021` | Returnable normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | Pfand | 1.3- | +| `0x4445000000000022` | Returnable discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | Pfand | 1.3- | +| `0x4445000000000023` | Returnable special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | Pfand | 1.3- | +| `0x4445000000000024` | Returnable special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | Pfand | 1.3- | +| `0x4445000000000025` | Returnable not taxable | 5 | Pfand | 1.3- | +| `0x4445000000000026` | returnable zero | 6 | Pfand | 1.3- | +| `0x4445000000000027` | Returnable vat unknown.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | Pfand | 1.3- | +| `0x4445000000000029` | Returnable reverse normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | PfandRueckzahlung | 1.3- | +| `0x444500000000002A` | Returnable reverse discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | PfandRueckzahlung | 1.3- | +| `0x444500000000002B` | Returnable reverse special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | PfandRueckzahlung | 1.3- | +| `0x444500000000002C` | Returnable reverse special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | PfandRueckzahlung | 1.3- | +| `0x444500000000002D` | Returnable reverse not taxable | 5 | PfandRueckzahlung | 1.3- | +| `0x444500000000002E` | Returnable reverse zero | 6 | PfandRueckzahlung | 1.3- | +| `0x444500000000002F` | Returnable reverse vat unknown.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | PfandRueckzahlung | 1.3- | +| `0x4445000000000031` | Discount normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | Rabatt | 1.3- | +| `0x4445000000000032` | Discount discounted-1 . 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | Rabatt | 1.3- | +| `0x4445000000000033` | Discount special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | Rabatt | 1.3- | +| `0x4445000000000034` | Discount special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | Rabatt | 1.3- | +| `0x4445000000000035` | Discount not taxable | 5 | Rabatt | 1.3- | +| `0x4445000000000036` | Discount zero | 6 | Rabatt | 1.3- | +| `0x4445000000000037` | Discount unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | Rabatt | 1.3- | +| `0x4445000000000039` | Extra charge normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | Aufschlag | 1.3- | +| `0x444500000000003A` | Extra charge discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | Aufschlag | 1.3- | +| `0x444500000000003B` | Extra charge special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | Aufschlag | 1.3- | +| `0x444500000000003C` | Extra charge special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | Aufschlag | 1.3- | +| `0x444500000000003D` | Extra charge not taxable | 5 | Aufschlag | 1.3- | +| `0x444500000000003E` | Extra charge zero | 6 | Aufschlag | 1.3- | +| `0x444500000000003F` | Extra charge unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | Aufschlag | 1.3- | +| `0x4445000000000041` | Unreal grant normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | ZuschussUnecht | 1.3- | +| `0x4445000000000042` | Unreal grant discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | ZuschussUnecht | 1.3- | +| `0x4445000000000043` | Unreal grant special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | ZuschussUnecht | 1.3- | +| `0x4445000000000044` | Unreal grant special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | ZuschussUnecht | 1.3- | +| `0x4445000000000045` | Unreal grant not taxable | 5 | ZuschussUnecht | 1.3- | +| `0x4445000000000046` | Unreal grant zero | 6 | ZuschussUnecht | 1.3- | +| `0x4445000000000047` | Unreal grant unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | ZuschussUnecht | 1.3- | +| `0x4445000000000049` | Real grant not taxable | 5 | ZuschussEcht | 1.3- | +| `0x4445000000000051` | Tip to owner normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | TrinkgeldAG | 1.3- | +| `0x4445000000000052` | Tip to owner discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | TrinkgeldAG | 1.3- | +| `0x4445000000000053` | Tip to owner special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | TrinkgeldAG | 1.3- | +| `0x4445000000000054` | Tip to owner special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | TrinkgeldAG | 1.3- | +| `0x4445000000000055` | Tip to owner not taxable | 5 | TrinkgeldAG | 1.3- | +| `0x4445000000000056` | Tip to owner zero | 6 | TrinkgeldAG | 1.3- | +| `0x4445000000000057` | Tip to owner unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | TrinkgeldAG | 1.3- | +| `0x4445000000000059` | Tip to employee no vat | 5 | TrinkgeldAN | 1.3- | +| `0x4445000000000060` | Voucher sale not taxable | 5 | MehrzweckgutscheinKauf | 1.3- | +| `0x4445000000000061` | Coupon sales normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | EinzweckgutscheinKauf | 1.3- | +| `0x4445000000000062` | Coupon sales discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | EinzweckgutscheinKauf | 1.3- | +| `0x4445000000000063` | Coupon sales special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | EinzweckgutscheinKauf | 1.3- | +| `0x4445000000000064` | Coupon sales special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | EinzweckgutscheinKauf | 1.3- | +| `0x4445000000000065` | Coupon sales not taxable | 5 | EinzweckgutscheinKauf | 1.3- | +| `0x4445000000000066` | Coupon sales zero | 6 | EinzweckgutscheinKauf | 1.3- | +| `0x4445000000000067` | Coupon sales unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | EinzweckgutscheinKauf | 1.3- | +| `0x4445000000000068` | Voucher redeem not taxable | 5 | MehrzweckgutscheinEinloesung | 1.3- | +| `0x4445000000000069` | Coupon redeem normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | EinzweckgutscheinEinloesung | 1.3- | +| `0x444500000000006A` | Coupon redeem discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | EinzweckgutscheinEinloesung | 1.3- | +| `0x444500000000006B` | Coupon redeem special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | EinzweckgutscheinEinloesung | 1.3- | +| `0x444500000000006C` | Coupon redeem special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | EinzweckgutscheinEinloesung | 1.3- | +| `0x444500000000006D` | Coupon redeem not taxable | 5 | EinzweckgutscheinEinloesung | 1.3- | +| `0x444500000000006E` | Coupon redeem zero | 6 | EinzweckgutscheinEinloesung | 1.3- | +| `0x444500000000006F` | Coupon redeem unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | EinzweckgutscheinEinloesung | 1.3- | +| `0x4445000000000071` | Receivable creation normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | Forderungsentstehung | 1.3- | +| `0x4445000000000072` | Receivable creation discounted-1 . 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | Forderungsentstehung | 1.3- | +| `0x4445000000000073` | Receivable creation special-1. 1.1.2019: 10,70% (DE: Durchschnittssatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | Forderungsentstehung | 1.3- | +| `0x4445000000000074` | Receivable creation special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | Forderungsentstehung | 1.3- | +| `0x4445000000000075` | Receivable creation not taxable | 5 | Forderungsentstehung | 1.3- | +| `0x4445000000000076` | Receivable creation zero | 6 | Forderungsentstehung | 1.3- | +| `0x4445000000000077` | Receivable creation unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | Forderungsentstehung | 1.3- | +| `0x4445000000000079` | Receivable reduction normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | Forderungsaufloesung | 1.3- | +| `0x444500000000007A` | Receivable reduction discounted-1 . 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | Forderungsaufloesung | 1.3- | +| `0x444500000000007B` | Receivable reduction special-1 . 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | Forderungsaufloesung | 1.3- | +| `0x444500000000007C` | Receivable reduction special-2 . 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | Forderungsaufloesung | 1.3- | +| `0x444500000000007D` | Receivable reduction not taxable | 5 | Forderungsaufloesung | 1.3- | +| `0x444500000000007E` | Receivable reduction zero | 6 | Forderungsaufloesung | 1.3- | +| `0x444500000000007F` | Receivable reduction unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | Forderungsaufloesung | 1.3- | +| `0x4445000000000081` | Down payment creation normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | Anzahlungseinstellung | 1.3- | +| `0x4445000000000082` | Down payment creation discounted-1. 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | Anzahlungseinstellung | 1.3- | +| `0x4445000000000083` | Down payment creation special-1. 1.1.2019: 10,70% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | Anzahlungseinstellung | 1.3- | +| `0x4445000000000084` | Down payment creation special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | Anzahlungseinstellung | 1.3- | +| `0x4445000000000085` | Down payment creation not taxable | 5 | Anzahlungseinstellung | 1.3- | +| `0x4445000000000086` | Down payment creation zero | 6 | Anzahlungseinstellung | 1.3- | +| `0x4445000000000087` | Down payment creation unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | Anzahlungseinstellung | 1.3- | +| `0x4445000000000089` | Down payment reduction normal. 1.1.2019: 19,00% (DE: Regelsteuersatz) | 1 | Anzahlungsaufloesung | 1.3- | +| `0x444500000000008A` | Down payment reduction discounted-1 . 1.1.2019: 7% (DE: Ermäßigter Steuersatz) | 2 | Anzahlungsaufloesung | 1.3- | +| `0x444500000000008B` | Down payment reduction special-1 . 1.1.2019: 10,70% (DE: Durchschnittssatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle) | 3 | Anzahlungsaufloesung | 1.3- | +| `0x444500000000008C` | Down payment reduction special-2. 1.1.2019: 5,50% (DE: Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)) | 4 | Anzahlungsaufloesung | 1.3- | +| `0x444500000000008D` | Down payment reduction not taxable | 5 | Anzahlungsaufloesung | 1.3- | +| `0x444500000000008E` | Down payment reduction zero | 6 | Anzahlungsaufloesung | 1.3- | +| `0x444500000000008F` | Down payment reduction unknown vat.

`chargeItem.VATRate == 0.0 ? UST_SCHLUESSEL = 7 : UST_SCHLUESSEL = (chargeItem.VATRate * 100) + 1000` | 7 or > 1000 | Anzahlungsaufloesung | 1.3- | +| `0x4445000000000090` | Cash transfer to empty till not taxable | 5 | Anfangsbestand | 1.3- | +| `0x4445000000000091` | Cash transfer from till to owner not taxable | 5 | Privatentnahme | 1.3- | +| `0x4445000000000092` | Cash transfer from owner to till not taxable | 5 | Privateinlage | 1.3- | +| `0x4445000000000093` | Cash transfer from/to till not taxable | 5 | Geldtransit | 1.3- | +| `0x4445000000000094` | Cash transfer from till to employee not taxable | 5 | Lohnzahlung | 1.3- | | `0x4445000000000095` | Cash transfer to cash book not taxable | 5 | Einzahlung | 1.3- | -| `0x4445000000000096` | Cash transfer from cash book not taxable | 5 | Auszahlung | 1.3- | -| `0x4445000000000097` | Cash amount difference from/to till not taxable | 5 | DifferenzSollIst | 1.3- | +| `0x4445000000000096` | Cash transfer from cash book not taxable | 5 | Auszahlung | 1.3- | +| `0x4445000000000097` | Cash amount difference from/to till not taxable | 5 | DifferenzSollIst | 1.3- | | `0x44450000000000A1` | Reverse charge | 5 | Umsatz | 1.3- | -| `0x44450000000000A2` | Not own sales | 5 | Umsatz | 1.3- | +| `0x44450000000000A2` | Not own sales | 5 | Umsatz | 1.3- | ## ftChargeItemCaseFlag -This table shows flags that can be added to each `ftChargeItemCase` with values applicable to the German market. +This table shows flags that can be added to each `ftChargeItemCase` with values applicable to the German market. -| Value | Description | Middleware-Version | -|---|---|---| -| 0x0000000000010000 | **Take away marker.**
For some cases, it is necessary to differ for the same good from in-house-consumption and take away. This flag signals a take away situation or in other words, a not-in-house-consumption if it is set. | 1.3.1- | -| 0x00000000002000001 | **Position cancellation flag**
When this flag is sent: Only the amount is used for calculating the sums in the Middleware, the DSFinV-K and the DFKA (instead of our common approach with the Quantity-based calculation). Sets the STORNO field in the DSFinV-K and the DFKA | 1.3.1- | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x0000000000010000` | **Take away marker**
For some cases, it is necessary to differ for the same good from in-house-consumption and take away. This flag signals a take away situation or in other words, a not-in-house-consumption if it is set. | 1.3.1- | +| `0x0000000000200000`1 | **Position cancellation flag**
When this flag is sent: Only the amount is used for calculating the sums in the Middleware, the DSFinV-K and the DFKA (instead of our common approach with the Quantity-based calculation). Sets the STORNO field in the DSFinV-K and the DFKA | 1.3.1- | 1 Previous documentation contained a typo regarding this flag. The documentation has been corrected to align with the [middleware implementation](https://docs.fiskaltrust.eu/changelog/middleware/1.3.66#-feature-support-line-cancellations). -#### Table with vat rate reference numbers defined in DSFinV-K +#### Table with VAT rate reference numbers defined in DSFinV-K -This table will be removed in the future / replaced by a reference +This table will be removed in the future and replaced by a reference. -| ID | USt-Satz | Beschreibung | -|---|---|---| +| **ID** | **USt-Satz** | **Beschreibung** | +| ------ | ------------ | ---------------- | | 1 | 19,00% | Regelsteuersatz | | 2 | 7,00% | Ermäßigter Steuersatz | | 3 | 10,70% | Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle | @@ -155,7 +155,5 @@ This table will be removed in the future / replaced by a reference | 5 | 0,00% | Nicht Steuerbar | | 6 | 0,00% | Umsatzsteuerfrei | | 7 | 0,00% | UmsatzsteuerNichtErmittelbar | -| 8-999 | | reserviert für Änderungen der DFKA-Taxonomie/DSFinV-K | -| ab 1000 | | individuelle Sachverhalte (Altsteuersätze, § 13b UStG, o.ä.) | - - +| 8-999 | | Reserviert für Änderungen der DFKA-Taxonomie/DSFinV-K | +| ab 1000 | | Individuelle Sachverhalte (Altsteuersätze, § 13b UStG, o.ä.) | diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-signature-ftsignatureformat.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-signature-ftsignatureformat.md index 07d91b3..f2493f3 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-signature-ftsignatureformat.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-signature-ftsignatureformat.md @@ -1,15 +1,15 @@ --- slug: /poscreators/middleware-doc/germany/reference-tables/ftsignatureformat -title: 'Format of signature: ftSignatureFormat' +title: 'Format of Signature: ftSignatureFormat' --- # Format of Signature: ftSignatureFormat -The Middleware uses the same _ftSignatureFormats_ in Germany as in all other countries, as described in the [general part](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat). +The Middleware uses the same ftSignatureFormat in Germany as in all other countries, as described in the table [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) of the Compliance Middleware. :::info -Please note that starting from June 2021, it's possible to **either** print the fiscalization details as a QR code **or** as text (while previously, the textual information was mandatory). Printing both is still allowed. More details can be found in the [enactment by the German government](https://dserver.bundestag.de/btd/19/290/1929085.pdf). +Starting from June 2021, it's possible to **either** print the fiscalization details as a QR code **or** as text (while previously, the textual information was mandatory). Printing both is still allowed. More details can be found in the [enactment by the German government](https://dserver.bundestag.de/btd/19/290/1929085.pdf). ::: @@ -17,6 +17,6 @@ As of today, there are two options when printing receipts: either print all deta ## ftSignatureFormatFlag -| Value | Description | Middleware-Version | -|-------|-------------|--------------------| -| `0x0000000000010000` | **Printing is optional**
When included in the _ftSignatureFormat_, printing the signature to the physical receipt is _not_ required. Please note that the returned QR code is used to replace several therefore optional signatures - if the used hardware does not support printing QR codes, these values are required to be printed instead. The Queue configuration parameter `FlagOptionalSignatures` (which can be set in the Portal) can be set to `false` to disable adding this flag to any items. | 1.3.23- | \ No newline at end of file +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x0000000000010000` | **Printing is optional**
When included in the ftSignatureFormat, printing the signature to the physical receipt is _not_ required. Please note that the returned QR code is used to replace several therefore optional signatures - if the used hardware does not support printing QR codes, these values are required to be printed instead. The Queue configuration parameter `FlagOptionalSignatures` (which can be set in the Portal) can be set to `false` to disable adding this flag to any items. | 1.3.23- | \ No newline at end of file diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-signature-ftsignaturetype.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-signature-ftsignaturetype.md index 693c618..5f76183 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-signature-ftsignaturetype.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-signature-ftsignaturetype.md @@ -1,6 +1,6 @@ --- slug: /poscreators/middleware-doc/germany/reference-tables/ftsignaturetype -title: 'Type of signature: ftSignatureType' +title: 'Type of Signature: ftSignatureType' --- # Type of Signature: ftSignatureType @@ -13,32 +13,30 @@ The German Middleware returns multiple additional signature items that are later ::: - - -For definitions regarding national laws, please refer to the appropriate appendix. - -| **Value** | **Description** | **Middleware-Version** | -|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------| -| `0x4445000000000001` | Signature according to KassenSichV (QR-code content) | 1.3 | -| `0x4445000000000002` | Archiving required | 1.3 | -| `0x4445000000000003` | Notification | 1.3 | -| `0x4445000000000010` | Start-transaction-result | 1.3 | -| `0x4445000000000011` | Finish-transaction-payload | 1.3 | -| `0x4445000000000012` | Finish-transaction-result | 1.3 | -| `0x4445000000000013` | Receipt / qr-version | 1.3 | -| `0x4445000000000014` | Receipt / POS serial number | 1.3 | -| `0x4445000000000015` | Receipt / processtype | 1.3 | -| `0x4445000000000016` | Receipt / processdata | 1.3 | -| `0x4445000000000017` | Receipt / transaction number | 1.3 | -| `0x4445000000000018` | Receipt / signature counter | 1.3 | -| `0x4445000000000019` | Receipt / start time (start-transaction) | 1.3 | -| `0x444500000000001A` | Receipt / logtime | 1.3 | -| `0x444500000000001B` | Receipt / signature algorithm | 1.3 | -| `0x444500000000001C` | Receipt / logtime-format | 1.3 | -| `0x444500000000001D` | Receipt / signature | 1.3 | -| `0x444500000000001E` | Receipt / public-key | 1.3 | -| `0x444500000000001F` | Receipt / process start (action) | 1.3 | -| `0x4445000000000020` | Update-transaction-payload | 1.3.14 | -| `0x4445000000000021` | Update-transaction-result | 1.3.16 | -| `0x4445000000000022` | Certification identification (e.g. BSI-K-TR-1234-5678). Also contains information about the certification state (for non certified TSEs) and the state of the environmental protection. | 1.3.16 | -| `0x4445000000000023` | TSE Serial Number | 1.3.49 | +For definitions regarding national laws, refer to the appropriate appendix. + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x4445000000000001` | Signature according to KassenSichV (QR-code content) | 1.3 | +| `0x4445000000000002` | Archiving required | 1.3 | +| `0x4445000000000003` | Notification | 1.3 | +| `0x4445000000000010` | Start-transaction-result | 1.3 | +| `0x4445000000000011` | Finish-transaction-payload | 1.3 | +| `0x4445000000000012` | Finish-transaction-result | 1.3 | +| `0x4445000000000013` | Receipt / qr-version | 1.3 | +| `0x4445000000000014` | Receipt / POS serial number | 1.3 | +| `0x4445000000000015` | Receipt / processtype | 1.3 | +| `0x4445000000000016` | Receipt / processdata | 1.3 | +| `0x4445000000000017` | Receipt / transaction number | 1.3 | +| `0x4445000000000018` | Receipt / signature counter | 1.3 | +| `0x4445000000000019` | Receipt / start time (start-transaction) | 1.3 | +| `0x444500000000001A` | Receipt / logtime | 1.3 | +| `0x444500000000001B` | Receipt / signature algorithm | 1.3 | +| `0x444500000000001C` | Receipt / logtime-format | 1.3 | +| `0x444500000000001D` | Receipt / signature | 1.3 | +| `0x444500000000001E` | Receipt / public-key | 1.3 | +| `0x444500000000001F` | Receipt / process start (action) | 1.3 | +| `0x4445000000000020` | Update-transaction-payload | 1.3.14 | +| `0x4445000000000021` | Update-transaction-result | 1.3.16 | +| `0x4445000000000022` | Certification identification (e.g. BSI-K-TR-1234-5678). Also contains information about the certification state (for non certified TSEs) and the state of the environmental protection. | 1.3.16 | +| `0x4445000000000023` | TSE Serial Number | 1.3.49 | From 99806d6edde8e2623b4492719644bb2a92ad1bd3 Mon Sep 17 00:00:00 2001 From: deboragracio Date: Wed, 10 Jun 2026 18:08:22 +0200 Subject: [PATCH 3/6] ES https://github.com/fiskaltrust/engineering/issues/1135 --- .../reference-tables/reference-tables.md | 12 +- .../type-of-journal-ftjournaltype.md | 2 +- .../type-of-payment-ftpayitemcase.md | 2 +- .../type-of-service-ftchargeitemcase.md | 2 +- .../type-of-signature-ftsignatureformat.md | 2 +- .../type-of-journal-ftjournaltype.md | 2 +- .../type-of-payment-ftpayitemcase.md | 2 +- .../type-of-receipt-ftreceiptcase.md | 2 +- .../type-of-service-ftchargeitemcase.md | 2 +- .../type-of-signature-ftsignatureformat.md | 2 +- .../reference-tables/reference-tables.md | 20 ++- .../service-status-ftstate.md | 30 ++-- .../type-of-journal-ftjournaltype.md | 8 +- .../type-of-payment-ftpayitemcase.md | 66 ++++----- .../type-of-receipt-ftreceiptcase.md | 130 +++++++++--------- .../type-of-service-ftchargeitemcase.md | 89 ++++++------ .../type-of-signature-ftsignatureformat.md | 11 +- .../type-of-signature-ftsignaturetype.md | 50 +++---- 18 files changed, 222 insertions(+), 212 deletions(-) diff --git a/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md index 98ea995..66689de 100644 --- a/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md @@ -62,7 +62,7 @@ For Austria (AT) the country code is `0x4154`. Thus, the value for an unknown ft ### ftReceiptCaseFlag -This table expands on the values provided in the table [Type of Receipt: ftReceiptCaseFlag](../../general/reference-tables/reference-tables.md#ftreceiptcaseflag) with values applicable to the Austrian market. +This table expands on the values provided in the [Type of Receipt: ftReceiptCaseFlag](../../general/reference-tables/reference-tables.md#ftreceiptcaseflag) reference table with values applicable to the Austrian market. | **Value** | **Description** | **Middleware Version** | | --------- | --------------- | ---------------------- | @@ -81,7 +81,7 @@ This table expands on the values provided in the table [Type of Receipt: ftRecei ## Type of Service: ftChargeItemCase -This table expands on the values provided in the table [Type of Service: ftChargeItemCase](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) with values applicable to the Austrian market. +This table expands on the values provided in the [Type of Service: ftChargeItemCase](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) reference table with values applicable to the Austrian market. | **Value** | **Description** | **Middleware Version** | | --------- | --------------- | ---------------------- | @@ -128,7 +128,7 @@ This table expands on the values provided in the table [Type of Service: ftCharg ## Type of Payment: ftPayItemCase -This table expands on the values provided in the table [Type of Payment: ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) with values applicable to the Austrian market. +This table expands on the values provided in the [Type of Payment: ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) reference table with values applicable to the Austrian market. | **Value** | **Description** | **Middleware Version** | | --------- | --------------- | ---------------------- | @@ -159,7 +159,7 @@ This table expands on the values provided in the table [Type of Payment: ftPayIt ## Type of Signature: ftSignatureType -This table expands on the values provided in the table [Type of Signature: ftSignatureType](../../general/reference-tables/reference-tables.md#type-of-signature-ftsignaturetype) with values applicable to the Austrian market. +This table expands on the values provided in the [Type of Signature: ftSignatureType](../../general/reference-tables/reference-tables.md#type-of-signature-ftsignaturetype) reference table with values applicable to the Austrian market. | **Value** | **Description** | **Middleware Version** | | --------- | --------------- | ----------- | @@ -174,7 +174,7 @@ This table expands on the values provided in the table [Type of Signature: ftSig ## Format of Signature: ftSignatureFormat -This table expands on the values provided in the table [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) with values applicable to the Austrian market. +This table expands on the values provided in the [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) reference table 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 [Printing of QR-Code not supported](#printing-of-qr-code-not-supported) section. @@ -200,7 +200,7 @@ According to the RKSV, there is one exception: if the fiskaltrust.SecurityMechan ## Type of Journal: ftJournalType -This table expands on the values provided in the table [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) with values applicable to the Austrian market. +This table expands on the values provided in the [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) reference table with values applicable to the Austrian market. | **Value** | **Description** | **Middleware Version** | | --------- | --------------- | ---------------------- | diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md index c5da349..f27e842 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md @@ -5,7 +5,7 @@ title: 'Type of Journal: ftJournalType' # Type of Journal: ftJournalType -This table expands on the values provided in the table [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) of the Compliance Middleware with values applicable to the Belgian market. +This table expands on the values provided in the [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) reference table of the Compliance Middleware with values applicable to the Belgian market. | **Value** | **Description** | **Middleware Version** | | --------- | --------------- | ---------------------- | diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md index 1a78624..98d1355 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md @@ -5,7 +5,7 @@ title: 'Type of Payment: ftPayItemCase' # Type of Payment: ftPayItemCase -This table expands on the values provided in the table [ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) of the Compliance Middleware with values applicable to the Belgian market. +This table expands on the values provided in the [Type of Payment: ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) reference table of the Compliance Middleware with values applicable to the Belgian market. ## Format diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-service-ftchargeitemcase.md index 57bdacc..9849326 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-service-ftchargeitemcase.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-service-ftchargeitemcase.md @@ -5,7 +5,7 @@ title: 'Type of Service: ftChargeItemCase' # Type of Service: ftChargeItemCase -This table expands on the values provided in the table [ftChargeItemCase](../../general/reference-tables/reference-tables.md#type-of-service-ftchargeitemcase) of the Compliance Middleware, with country-specific values applicable to the Belgian market. +This table expands on the values provided in the [Type of Service: ftChargeItemCase](../../general/reference-tables/reference-tables.md#type-of-service-ftchargeitemcase) reference table of the Compliance Middleware, with country-specific values applicable to the Belgian market. ## Format _CCCC_vlll_gggg_NNSV_ diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignatureformat.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignatureformat.md index 55dd89f..a47ded3 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignatureformat.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-signature-ftsignatureformat.md @@ -5,7 +5,7 @@ title: 'Format of Signature: ftSignatureFormat' # Format of Signature: ftSignatureFormat -The Middleware uses the same ftSignatureFormat in Belgium as in all other countries, as described in the table [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) of the Compliance Middleware. +The Middleware uses the same ftSignatureFormat in Belgium as in all other countries, as described in the [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) reference table of the Compliance Middleware. ## ftSignatureFormatFlag diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md index 7fa973e..cbad3ae 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md @@ -5,7 +5,7 @@ title: 'Type of Journal: ftJournalType' # Type of Journal: ftJournalType -This table expands on the values provided in table ["Type of Journal: ftJournalType"](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) of the Compliance Middleware with values applicable to the German market. +This table expands on the values provided in the [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) reference table of the Compliance Middleware with values applicable to the German market. | **Value** | **Description** | **Middleware Version** | | --------- | --------------- | ---------------------- | diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md index 99a94ed..9d4d057 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md @@ -5,7 +5,7 @@ title: 'Type of Payment: ftPayItemCase' # Type of Payment: ftPayItemCase -This table expands on the values provided in table [ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) of the Compliance Middleware with values applicable to the German market. +This table expands on the values provided in the [Type of Payment: ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) reference table of the Compliance Middleware with values applicable to the German market. | **Value** | **Description** | **ZAHLART_TYP (DSFinV-K)** | **Middleware Version** | | --------- | --------------- | -------------------------- | ---------------------- | diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md index f3380e6..5888dff 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md @@ -43,7 +43,7 @@ For Germany (DE), the country code is `0x4445`. Thus, the value of an unknown `f ## ftReceiptCaseFlag -This table expands on the values provided in table [ftReceiptCaseFlag](../../general/reference-tables/reference-tables.md#ftreceiptcaseflag) of the Compliance Middleware with values applicable to the German market. +This table expands on the values provided in the [ftReceiptCaseFlag](../../general/reference-tables/reference-tables.md#ftreceiptcaseflag) reference table of the Compliance Middleware with values applicable to the German market. | **Value** | **Description** | **Middleware Version** | | --------- | --------------- | ---------------------- | diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-service-ftchargeitemcase.md index 1847a8e..8fbeccb 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-service-ftchargeitemcase.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-service-ftchargeitemcase.md @@ -5,7 +5,7 @@ title: 'Type of Service: ftChargeItemCase' # Type of Service: ftChargeItemCase -This table expands on the values provided in the table [ftChargeItemCase](../../general/reference-tables/reference-tables.md#type-of-service-ftchargeitemcase) of the Compliance Middleware, with country-specific values applicable to the German market. +This table expands on the values provided in the [Type of Service: ftChargeItemCase](../../general/reference-tables/reference-tables.md#type-of-service-ftchargeitemcase) reference table of the Compliance Middleware, with country-specific values applicable to the German market. | **Value** | **Description** | **UST_SCHLUESSEL (DSFinV-K)** | **GV_TYP (DSFinV-K)** | **Middleware Version** | | --- | --- | --- | --- | --- | diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-signature-ftsignatureformat.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-signature-ftsignatureformat.md index f2493f3..a63f6e3 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-signature-ftsignatureformat.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-signature-ftsignatureformat.md @@ -5,7 +5,7 @@ title: 'Format of Signature: ftSignatureFormat' # Format of Signature: ftSignatureFormat -The Middleware uses the same ftSignatureFormat in Germany as in all other countries, as described in the table [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) of the Compliance Middleware. +The Middleware uses the same ftSignatureFormat in Germany as in all other countries, as described in the [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) reference table of the Compliance Middleware. :::info diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-es/reference-tables/reference-tables.md index 00e313a..d4e043f 100644 --- a/poscreators/middleware-doc/middleware-es/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-es/reference-tables/reference-tables.md @@ -5,7 +5,13 @@ title: Reference Tables # Reference Tables -This chapter expands on the reference tables covered in [Reference Tables in General Part](../../general/reference-tables/reference-tables.md), with country-specific information applicable to the Spanish market. The respective tables can be found in the following sub-sections. +This page expands on the reference tables covered in the [Reference Tables](../../general/reference-tables/reference-tables.md) of the Compliance Middleware, with country-specific information applicable to the Spanish market. The respective tables can be found in the following subsections. + +:::info POSSystem API v2 Reference + +The Compliance Middleware [Reference Tables](../../general/reference-tables/reference-tables.md) contain the core POSSystem API v2 tagging structure used across all markets and should be your primary reference. + +::: As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for Spanish 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. @@ -19,9 +25,9 @@ _4553_2000_0010_0001 _CCCC_vIII_gggg_xxxx -| **Value** | **Description** | -|----------------------|-----------------------------------------------------------------------------------------------------| -|CCCC|(e.g 4553): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. ES = 4553) | -|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 leave 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 | \ No newline at end of file +| **Value** | **Description** | +| --------- | --------------- | +| CCCC | (e.g 4553): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. ES = 4553) | +| 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 leave 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. | \ No newline at end of file diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/service-status-ftstate.md b/poscreators/middleware-doc/middleware-es/reference-tables/service-status-ftstate.md index d8d2b6e..6be05ef 100644 --- a/poscreators/middleware-doc/middleware-es/reference-tables/service-status-ftstate.md +++ b/poscreators/middleware-doc/middleware-es/reference-tables/service-status-ftstate.md @@ -7,28 +7,28 @@ title: 'Service Status: ftState' ## Format -_CCCC_vlll_gggg_gggg_ +_CCCC_vlll_gggg_gggg_ #### v - version version 2 #### gggg_gggg - global tagging/flag -| **Value** | **Description** | **Middleware Version** | -|----------------------|-----------------------------------------------------------------------------------------------------|---------------------| -| `0000_0001 ` | **Security Mechanism is 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_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_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_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 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 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0000_0001 ` | **Security Mechanism is 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_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_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_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 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 +#### llll - local flags -| **Value** | **Description** | **Middleware Version** | -|----------------------|-----------------------------------------------------------------------------------------------------|---------------------| -|TBD|TBD|TBD| +cba c=reserved; b=reporting; a=scu related +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| TBD | TBD | TBD | diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-journal-ftjournaltype.md b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-journal-ftjournaltype.md index ac63a4a..570265e 100644 --- a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-journal-ftjournaltype.md +++ b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-journal-ftjournaltype.md @@ -5,8 +5,8 @@ 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#type-of-journal-ftjournaltype) of the General part with values applicable to the Spanish market. +This table expands on the values provided in the [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) reference table of the Compliance Middleware with values applicable to the Spanish market. -| **Value** | **Description** | **Version** | -|----------------------|--------------------------------|-------------| -| `000` | Status Information QueueES | 1.3.45 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `000` | Status Information QueueES | 1.3.45 | diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-payment-ftpayitemcase.md b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-payment-ftpayitemcase.md index f1f1ce5..beb1021 100644 --- a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-payment-ftpayitemcase.md +++ b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-payment-ftpayitemcase.md @@ -5,48 +5,50 @@ 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 Spanish market. +This table expands on the values provided in the [Type of Payment: ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) reference table of the Compliance Middleware with values applicable to the Spanish market. ## Format -_CCCC_vlll_gggg_xxPP_ +_CCCC_vlll_gggg_xxPP_ #### v - version version 2 #### PP - payment type -| **Value** | **Description** | **Middleware version** | -| -------------------- | ---------------------------------------------------------------------------------------------- | ---------------------- | -| `00` | **Unknown payment type for ES**
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| + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `00` | **Unknown payment type for ES**
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 | -| `0100` | **IsInterface/AmountVerified**
Was verified by interface, automated amount transfer | 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 + +| **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 | +| `0100` | **IsInterface/AmountVerified**
Was verified by interface, automated amount transfer | 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 | diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-receipt-ftreceiptcase.md index 899a742..a121b81 100644 --- a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-receipt-ftreceiptcase.md +++ b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-receipt-ftreceiptcase.md @@ -1,6 +1,6 @@ --- slug: /poscreators/middleware-doc/spain/reference-tables/ftreceiptcase -title: 'Type of receipt: ftReceiptCase' +title: 'Type of Receipt: ftReceiptCase' --- # Type of Receipt: ftReceiptCase @@ -11,79 +11,77 @@ For Spain (ES), the country code is `0x4553`. Thus, the value of an unknown `ftR ## Format -_CCCC_vlll_gggg_txcc_ +_CCCC_vlll_gggg_txcc_ #### v - version version 2 -| **Value** | **Description** | -|----------------------|-----------------------------------------------------------------------------------------------------| -|t|ReceiptCaseType| -|txcc|ReceiptCase| -|gggg|global tagging/flag| -|lll|local tagging/flag| +| **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 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) | - +| --------- | ------------ | --------------- | +| `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 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 "ES"**

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 exception 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 | -| `2011` | **Daily 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 | -| `4011` | **Initiate SCU-switch**

| 1.3.45 | -| `4012` | **Finish SCU-switch**

| 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 marker. | 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, Address, 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 or 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** | -|-----------|-----------------|-------------------------| -|TBD|TBD|TBD| \ No newline at end of file +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0000` | **Unknown type for country-code "ES"**
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 exception 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 | +| `2011` | **Daily 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 | +| `4011` | **Initiate SCU-switch** | 1.3.45 | +| `4012` | **Finish SCU-switch** | 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 marker. | 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, Address, 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 or 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** | +| --------- | --------------- | ---------------------- | +| TBD | TBD | TBD | \ No newline at end of file diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-service-ftchargeitemcase.md index 0e154da..fd1d66d 100644 --- a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-service-ftchargeitemcase.md +++ b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-service-ftchargeitemcase.md @@ -1,75 +1,76 @@ --- slug: /poscreators/middleware-doc/spain/reference-tables/ftchargeitemcase -title: 'Type of service: 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 Spanish market. +This table expands on the values provided in the [Type of Service: ftChargeItemCase](../../general/reference-tables/reference-tables.md#type-of-service-ftchargeitemcase) reference table of the Compliance Middleware with country-specific values applicable to the Spanish market. ## Format -_CCCC_vlll_gggg_NNSV_ +_CCCC_vlll_gggg_NNSV_ #### v - version version 2 -#### V - VAT -https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm +#### V - VAT -| **Value** | **Description**| **Middleware Version** | -| -------------------- | -------------- | ---------------------- | -| `0` | **Unknown type of service for ES**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.67 | +For more information, see [VAT rules and rates](https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm). + +| **Value** | **Description** | **Middleware Version** | +| --------- | -------------- | ---------------------- | +| `0` | **Unknown type of service for ES**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.67 | | `1` | **Discounted-1 VAT rate**
(as of 1.1.2022, this is 10%). | 1.3.67 | -| `2` | **Discounted 2 VAT rate**
(as of 1.1.2022, this is calculated with 5%). | 1.3.67 | -| `3` | **Normal VAT rate**
(as of 1.1.2022, this is calculated with 22%). | 1.3.67 | -| `4` | **Super reduced 1 VAT rate**
| 1.3.67 | -| `5` | **Super reduced 2 VAT rate**
| 1.3.67 | +| `2` | **Discounted 2 VAT rate**
(as of 1.1.2022, this is calculated with 5%). | 1.3.67 | +| `3` | **Normal VAT rate**
(as of 1.1.2022, this is calculated with 22%). | 1.3.67 | +| `4` | **Super reduced 1 VAT rate** | 1.3.67 | +| `5` | **Super reduced 2 VAT rate** | 1.3.67 | | `6` | **Parking VAT rate**
Reversal of tax liability. | 1.3.67 | | `7` | **Zero VAT rate**
In the data, a VAT-rate can be indicated. | 1.3.67 | | `8` | **Not Taxable**
For processing, see (`0x4553000000000001`) | 1.3.67 | -#### 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.67 | -| `1` | **Delivery (supply of goods)**
| 1.3.67 | -| `2` | **Other service (supply of service)**
| 1.3.67 | -| `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.67 | -| `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.67 | -| `5` | **Catalog service**
| 1.3.67 | -| `6` | **Not own sales / Agency business**
| 1.3.67 | -| `7` | **Own Consumption**
| 1.3.67 | -| `8` | **Grant**
For Unreal Grant use V=0 to 7
For Real Grant use V=8 |1.3.67| -| `9` | **Receivable**
Receivable creation is negative (-) amount
Receivable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.67| -| `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.67| +#### S - Type of Service -#### NN - nature of VAT +| **Value** | **Description** | **Middleware Version** | +| --------- | -------------- | ---------------------- | +| `0` | **Unknown type of service**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.67 | +| `1` | **Delivery (supply of goods)** | 1.3.67 | +| `2` | **Other service (supply of service)** | 1.3.67 | +| `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.67 | +| `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.67 | +| `5` | **Catalog service** | 1.3.67 | +| `6` | **Not own sales / Agency business** | 1.3.67 | +| `7` | **Own Consumption** | 1.3.67 | +| `8` | **Grant**
For Unreal Grant use V=0 to 7
For Real Grant use V=8 | 1.3.67 | +| `9` | **Receivable**
Receivable creation is negative (-) amount
Receivable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. | 1.3.67 | +| `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.67 | -| **Value** | **Description** | **Spec. for Spanish reg.** | **Middleware Version** | -| -------------------- | -------------- | -------------- | ---------------------- | -| `00` | **usual VAT applies**
| | 1.3.67 | -| `20` | **Not Subject**
2x can be used to specify more country specific details.| *NS (N2) marker mandatory
[20] not subject by articles 7 and 14
[21] not subject, location rules| 1.3.67 | -| `30` | **Exempt**
3x| *ES (N4) marker mandatory
[30] Exempt by article 20
[31] Exempt by article 21
[32] Exempt by article 22
[33] Exempt by article 23 and 24
[34] Exempt by article 25
[35] Exempt, other cases | 1.3.67 | -| `50` | **Reverse charge**
5x | *AL (N6) marker mandatory
[50] reverse charge | 1.3.67 | +#### NN - nature of VAT +| **Value** | **Description** | **Spec. for Spanish reg.** | **Middleware Version** | +| --------- | -------------- | ------------------------- | ---------------------- | +| `00` | **Usual VAT applies** | | 1.3.67 | +| `20` | **Not Subject**
2x can be used to specify more country specific details. | *NS (N2) marker mandatory
[20] not subject by articles 7 and 14
[21] not subject, location rules | 1.3.67 | +| `30` | **Exempt**
3x | *ES (N4) marker mandatory
[30] Exempt by article 20
[31] Exempt by article 21
[32] Exempt by article 22
[33] Exempt by article 23 and 24
[34] Exempt by article 25
[35] Exempt, other cases | 1.3.67 | +| `50` | **Reverse charge**
5x | *AL (N6) marker mandatory
[50] reverse charge | 1.3.67 | #### lll - local tagging/flag TBD -#### gggg - global tagging/flag +#### 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.67 | +| **Value** | **Description** | **Middleware Version** | +| --------- | -------------- | ---------------------- | +| `0001` | **IsVoid**
Marks ChargeItem as Void previous position. Quantity and amount are inverted, related to original item. | 1.3.67 | | `0002` | **IsReturn/IsRefund**
Marks ChargeItem as Return of good or service. Quantity and amount are inverted, related to original item. | 1.3.67 | -| `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.67 | -| `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.67 | -| `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.67 | -| `0020` | **TakeAway**
Marks ChargeItem as TakeAway item to prove special VAT application | 1.3.67 | -| `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.67 | +| `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.67 | +| `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.67 | +| `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.67 | +| `0020` | **TakeAway**
Marks ChargeItem as TakeAway item to prove special VAT application | 1.3.67 | +| `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.67 | ## ftChargeItemCaseFlag -This table shows flags that can be added to each `ftChargeItemCase` with values applicable to the Spanish market. + +This table shows flags that can be added to each `ftChargeItemCase` with values applicable to the Spanish market. diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-signature-ftsignatureformat.md b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-signature-ftsignatureformat.md index 5c29a90..a200370 100644 --- a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-signature-ftsignatureformat.md +++ b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-signature-ftsignatureformat.md @@ -1,14 +1,15 @@ --- slug: /poscreators/middleware-doc/spain/reference-tables/ftsignatureformat -title: 'Format of signature: ftSignatureFormat' +title: 'Format of Signature: ftSignatureFormat' --- # Format of Signature: ftSignatureFormat -The Middleware uses the same _ftSignatureFormats_ in Spain as in all other countries, as described in the [general part](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat). + +The Middleware uses the same ftSignatureFormat in Spain as in all other countries, as described in the [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) reference table of the Compliance Middleware. ## ftSignatureFormatFlag -| Value | Description | Middleware-Version | -|-------|-------------|--------------------| -|TBD|TBD|TBD| \ No newline at end of file +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| TBD | TBD | TBD | \ No newline at end of file diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-signature-ftsignaturetype.md b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-signature-ftsignaturetype.md index 33704df..5f9f4c4 100644 --- a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-signature-ftsignaturetype.md +++ b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-signature-ftsignaturetype.md @@ -1,40 +1,42 @@ --- slug: /poscreators/middleware-doc/spain/reference-tables/ftsignaturetype -title: 'Type of signature: ftSignatureType' +title: 'Type of Signature: ftSignatureType' --- # Type of Signature: ftSignatureType The `ftSignatureType` indicates the type and origin of the signature. The data type is `Int64` and can contain a country-specific code, a value following the ISO-3166-1-ALPHA-2 standard, converted from ASCII into hex and used as byte 8 and 7. - For definitions regarding national laws, please refer to the appropriate appendix. ## Format -_CCCC_vlll_gggg_tsss +_CCCC_vlll_gggg_tsss #### v - version version 2 -#### t - Type/Category -| **Value** | **Description** | **Middleware-Version** | -|-----------|-----------------|------------------------| -| `0` | Uncategorized, Normal use (notification) | 1.3.45 | -| `1` | Information (notification), low priority | 1.3.45 | -| `2` | Alert (notification), high priority | 1.3.45 | -| `3` | Failure (notification), high priority | 1.3.45 | - -#### gggg - global flags -| **Value** | **Description** | **Middleware-Version** | -|-----------|-----------------|------------------------| -| `0001` | Archiving required.
Signatures marked with this flag are known to be archived related to market specific bookkeeping requirements. In case of offline usage or pure open-source usage, receipts/artefacts having this flag need to be handled as bookkeeping/accounting-relevant item. | 1.3.45 | -| `0010` | Printing/Visualization is optional | 1.3.45 | -| `0020` | Do not print/visualize | 1.3.45 | -| `0040` | Printed receipt only | 1.3.45 | -| `0080` | Digital receipt only | 1.3.45 | - -#### sss - SignatureCase -| **Value** | **Description** | **Caption** | **Middleware-Version** | -|-----------|-----------------|-----------------|------------------------| -|TBD|TBD|TBD| +#### t - Type/Category + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0` | Uncategorized, Normal use (notification) | 1.3.45 | +| `1` | Information (notification), low priority | 1.3.45 | +| `2` | Alert (notification), high priority | 1.3.45 | +| `3` | Failure (notification), high priority | 1.3.45 | + +#### gggg - global flags + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0001` | Archiving required.
Signatures marked with this flag are known to be archived related to market specific bookkeeping requirements. In case of offline usage or pure open-source usage, receipts/artefacts having this flag need to be handled as bookkeeping/accounting-relevant item. | 1.3.45 | +| `0010` | Printing/Visualization is optional. | 1.3.45 | +| `0020` | Do not print/visualize. | 1.3.45 | +| `0040` | Printed receipt only. | 1.3.45 | +| `0080` | Digital receipt only. | 1.3.45 | + +#### sss - SignatureCase + +| **Value** | **Description** | **Caption** | **Middleware Version** | +| --------- | --------------- | ----------- | ---------------------- | +| TBD | TBD | TBD | TBD | From 38420eb3eea8d2e46011c6e3a3b7897d231ce1cd Mon Sep 17 00:00:00 2001 From: deboragracio Date: Thu, 11 Jun 2026 16:08:01 +0200 Subject: [PATCH 4/6] FR/GR https://github.com/fiskaltrust/engineering/issues/1135 --- .../reference-tables/reference-tables.md | 260 +++++++++--------- .../reference-tables/reference-tables.md | 24 +- .../service-status-ftstate.md | 29 +- .../type-of-journal-ftjournaltype.md | 8 +- .../type-of-payment-ftpayitemcase.md | 66 ++--- .../type-of-receipt-ftreceiptcase.md | 130 +++++---- .../type-of-service-ftchargeitemcase.md | 51 ++-- .../type-of-signature-ftsignatureformat.md | 10 +- .../type-of-signature-ftsignaturetype.md | 52 ++-- 9 files changed, 320 insertions(+), 310 deletions(-) diff --git a/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/reference-tables/reference-tables.md index 77edb6e..14937a5 100644 --- a/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/reference-tables/reference-tables.md @@ -5,7 +5,7 @@ title: Reference Tables # Reference Tables -This chapter expands on the reference tables covered in [Reference Tables in General Part](../../general/reference-tables/reference-tables-v1.md), with country-specific information applicable to the French market. The respective tables can be found in the following sub-sections. +This page expands on the reference tables covered in the [Reference Tables](../../general/reference-tables/reference-tables-v1.md) of the Compliance Middleware, with country-specific information applicable to the French market. ## Service Status: ftState @@ -15,11 +15,11 @@ The country-specific code is made of the country's code value following the ISO- The table below describes supported statuses for the ftState field. Those codes can be combined by using the logic operator `OR`. -| **Value** | **Description** | **Middleware Version** | -|----------------------|------------------------------------------------------------------|------------------------| -| `0x4652000000000040` | Message Pending
Use Zero-Receipt to show Message on Receipt | 1.0 | - +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x4652000000000040` | Message Pending
Use Zero-Receipt to show Message on Receipt | 1.0 | +*Table 1. Service Status: ftState (FR – BOI-TVA-DECLA 30-10-30)* ## Type of Receipt: ftReceiptCase @@ -27,49 +27,49 @@ The `ftReceiptCase` defines the type of receipt and hence how fiskaltrust.Securi 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 France (FR), the country code is `0x4652`. Thus, the value for an unknown `ftReceiptCase` in France is `0x4652000000000000`. -| **Value** | **Description** | **Middleware-Version** | -|----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------| -| `0x4652000000000000` | **Unknown receipt for FR**
Processed like a ticket | 1.2 | -| `0x4652000000000001` | **Ticket**
Legal document; has to be signed.
Sign: Yes
Chain and national numbering: T
Details: GT counters are raised | 1.2 | -| `0x4652000000000002` | **Payment Prove**
Payment without knowing what was paid.
Legal document; has to be signed.
Sign: Yes
Chain and national numbering: P
No ChargeItems on payment-prove, the total amount is always zero, a negative payitem of type `0x4652000000000011` is used to get the sum of PayItems to zero.
Details: GT counters are not raised | | -| `0x4652000000000003` | **Invoice**
Legal document; has to be signed.
Sign: Yes
Chain and national numbering: I
A reference to the ticket can be created by using `cbPreviousReceiptNumber` in the request.
Detail: GT counters are raised | | -| `0x4652000000000004` | **Shift Receipt / Grand Total Ticket / Grand Total Invoice: Shift**
Sign: Yes
Chain and national numbering: G
Details: Resets the shift-counter, keeps all other counters | 1.2 | -| `0x4652000000000005` | **Daily Receipt / Grand Total Ticket / Grand Total Invoice: Daily**
Sign: Yes
Chain and national numbering: G
Details:
- Adds a daily-counter to the monthly-counter and then resets the daily-counter
- keeps the shift-counter | 1.2 | -| `0x4652000000000006` | **Monthly Receipt / Grand Total Ticket / Grand Total Invoice: Month**
Sign: Yes
Chain and national numbering: G
Details:
- Adds a daily-counter to the monthly-counter and then resets the daily-counter
- Adds a monthly-counter to the yearly-counter and then resets the monthly-counter
- keeps the shift-counter | 1.2 | -| `0x4652000000000007` | **Yearly Receipt / Grand Total Ticket / Grand Total Invoice: Year**
Sign: Yes
Chain and national numbering: G
Details:
- Adds a daily-counter to the monthly-counter and then resets the daily-counter
- Adds a monthly-counter to the yearly-counter and then resets the monthly-counter
- Resets the yearly-counter
- keeps the shift-counter | 1.2 | -| `0x4652000000000008` | **Bill**
List of ChargeItems to be paid. Used to inform customers about their open ChargeItems. PayItemType `0x4652000000000011` is used
Sign: Yes
Chain and national numbering: B
Details: GT counters are not raised. When the bill is used, the phrase "document provisoire" is returned with the fiskaltrust signature and must be printed on the bill. If bill and payment prove are created, this does not replace a ticket creation. A ticket or an invoice has to be issued to raise turnover and raise the GT counters as well | | -| `0x4652000000000009` | **Delivery Note**
Sign: no
Chain and national numbering: no | | -| `0x465200000000000A` | **Cash pay-in / Cash Deposit**
Same handling as payment prove
Chain and national numbering: P | | -| `0x465200000000000B` | **Cash pay-out**
Same handling as payment prove
Chain and national numbering: P | | -| `0x465200000000000C` | **Payment transfer**
Switch between payment method, e.g. from cash to credit card
Sign: Yes
Chain and national numbering: P | | -| `0x465200000000000D` | **Internal / Material**
Sign: No
Chain and national numbering: no | | -| `0x465200000000000E` | **Foreign sales**
Same handling as bill. To be used when something sold in another country.
Sign: Yes
Chain and national numbering: B | | -| `0x465200000000000F` | **Zero-Receipt**
Sign: Yes
Chain and national numbering: G
Details: A receipt with empty charge items block `ftChargeItem` and empty payment block `ftPayItem` which amounts to a total of "0". | | -| `0x4652000000000010` | **Start-Receipt**
Sign: Yes
Chain and national numbering: G | | -| `0x4652000000000011` | **Stop-Receipt**
Sign: Yes
Chain and national numbering: G | | -| `0x4652000000000012` | **Protocol / Technical Event Log**
Has to be signed
Sign: Yes
Chain and national numbering: L
Details: Can be used by the POS-System to log custom data. | 1.2 | -| `0x4652000000000013` | **Protocol / Accounting / Audit**
Has to be signed
Sign: Yes
Chain and national numbering: L
Details: Can be used by the POS-System to log custom data. | 1.2 | -| `0x4652000000000014` | **Protocol / Custom**
Does not need to be signed
Sign: No
Chain and national numbering: No
Details: Can be used by the POS-System to log custom data. | 1.2 | -| `0x4652000000000015` | **Archive**
Has to be Signed
Sign: Yes
Chain and national numbering: A
Details: Will trigger a daily closing automatically.
Creates an archive starting with the first receipt of the queue (or the last archive receipt) until the last receipt before this request. It must not contain more than 365 days.
To retrieve the export as a zip-file (containing the certificate, ReceiptJournals and QueueItems), a normal `/journal`request has to be sent to the `ftJournalType`: `0x4652000000010010`. The value of `ftQueueRow` in the response of this ReceiptCase has to be sent in the `from`-parameter.
The content of the retrieved zip-file can be verified with the _ExportTool_ for France. It can be downloaded [here](https://github.com/fiskaltrust/interface-doc/files/10928504/fiskaltrust.TaxAuditorTool.zip) | 1.2 | -| `0x4652000000000016` | **Copy**
Has to be Signed
Sign: Yes
Chain and national numbering: C
Details: in a request the `cbPreviousReceiptReference` is mandatory. It contains the receipt number which was handed out as a copy, issued by the original cash register. When a copy of a receipt is requested, the phrase "duplicata" is returned with the fiskaltrust signature and must be printed on the receipt. Every time the receipt is reprinted, an up-counting number denoting how many times the receipt has been printed, is returned. It must be printed on the receipt and is then recorded in the journal.The layout and the information contained shall be the same as in the original document. | 1.2 | - -*Table 33. Type of Receipt: ftReceiptCase (FR – BOI-TVA-DECLA 30-10-30)* +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x4652000000000000` | **Unknown receipt for FR**
Processed like a ticket | 1.2 | +| `0x4652000000000001` | **Ticket**
Legal document; has to be signed.
Sign: Yes
Chain and national numbering: T
Details: GT counters are raised | 1.2 | +| `0x4652000000000002` | **Payment Prove**
Payment without knowing what was paid.
Legal document; has to be signed.
Sign: Yes
Chain and national numbering: P
No ChargeItems on payment-prove, the total amount is always zero, a negative payitem of type `0x4652000000000011` is used to get the sum of PayItems to zero.
Details: GT counters are not raised | | +| `0x4652000000000003` | **Invoice**
Legal document; has to be signed.
Sign: Yes
Chain and national numbering: I
A reference to the ticket can be created by using `cbPreviousReceiptNumber` in the request.
Details: GT counters are raised | | +| `0x4652000000000004` | **Shift Receipt / Grand Total Ticket / Grand Total Invoice: Shift**
Sign: Yes
Chain and national numbering: G
Details:
- Resets the shift-counter
- Keeps all other counters | 1.2 | +| `0x4652000000000005` | **Daily Receipt / Grand Total Ticket / Grand Total Invoice: Daily**
Sign: Yes
Chain and national numbering: G
Details:
- Adds a daily-counter to the monthly-counter and then resets the daily-counter
- Keeps the shift-counter | 1.2 | +| `0x4652000000000006` | **Monthly Receipt / Grand Total Ticket / Grand Total Invoice: Month**
Sign: Yes
Chain and national numbering: G
Details:
- Adds a daily-counter to the monthly-counter and then resets the daily-counter
- Adds a monthly-counter to the yearly-counter and then resets the monthly-counter
- Keeps the shift-counter | 1.2 | +| `0x4652000000000007` | **Yearly Receipt / Grand Total Ticket / Grand Total Invoice: Year**
Sign: Yes
Chain and national numbering: G
Details:
- Adds a daily-counter to the monthly-counter and then resets the daily-counter
- Adds a monthly-counter to the yearly-counter and then resets the monthly-counter
- Resets the yearly-counter
- Keeps the shift-counter | 1.2 | +| `0x4652000000000008` | **Bill**
List of ChargeItems to be paid. Used to inform customers about their open ChargeItems. PayItemType `0x4652000000000011` is used
Sign: Yes
Chain and national numbering: B
Details: GT counters are not raised. When the bill is used, the phrase "document provisoire" is returned with the fiskaltrust signature and must be printed on the bill. If bill and payment prove are created, this does not replace a ticket creation. A ticket or an invoice has to be issued to raise turnover and raise the GT counters as well. | | +| `0x4652000000000009` | **Delivery Note**
Sign: no
Chain and national numbering: no | | +| `0x465200000000000A` | **Cash pay-in / Cash Deposit**
Same handling as payment prove
Chain and national numbering: P | | +| `0x465200000000000B` | **Cash pay-out**
Same handling as payment prove
Chain and national numbering: P | | +| `0x465200000000000C` | **Payment transfer**
Switch between payment method, e.g. from cash to credit card
Sign: Yes
Chain and national numbering: P | | +| `0x465200000000000D` | **Internal / Material**
Sign: No
Chain and national numbering: no | | +| `0x465200000000000E` | **Foreign sales**
Same handling as bill. To be used when something sold in another country.
Sign: Yes
Chain and national numbering: B | | +| `0x465200000000000F` | **Zero-Receipt**
Sign: Yes
Chain and national numbering: G
Details: A receipt with empty charge items block `ftChargeItem` and empty payment block `ftPayItem` which amounts to a total of "0". | | +| `0x4652000000000010` | **Start-Receipt**
Sign: Yes
Chain and national numbering: G | | +| `0x4652000000000011` | **Stop-Receipt**
Sign: Yes
Chain and national numbering: G | | +| `0x4652000000000012` | **Protocol / Technical Event Log**
Has to be signed
Sign: Yes
Chain and national numbering: L
Details: Can be used by the POS-System to log custom data. | 1.2 | +| `0x4652000000000013` | **Protocol / Accounting / Audit**
Has to be signed
Sign: Yes
Chain and national numbering: L
Details: Can be used by the POS-System to log custom data. | 1.2 | +| `0x4652000000000014` | **Protocol / Custom**
Does not need to be signed
Sign: No
Chain and national numbering: No
Details: Can be used by the POS-System to log custom data. | 1.2 | +| `0x4652000000000015` | **Archive**
Has to be Signed
Sign: Yes
Chain and national numbering: A
Details: Will trigger a daily closing automatically.
Creates an archive starting with the first receipt of the queue (or the last archive receipt) until the last receipt before this request. It must not contain more than 365 days.
To retrieve the export as a zip-file (containing the certificate, ReceiptJournals and QueueItems), a normal `/journal`request has to be sent to the `ftJournalType`: `0x4652000000010010`. The value of `ftQueueRow` in the response of this ReceiptCase has to be sent in the `from`-parameter.
The content of the retrieved zip-file can be verified with the _ExportTool_ for France. It can be downloaded [here](https://github.com/fiskaltrust/interface-doc/files/10928504/fiskaltrust.TaxAuditorTool.zip) | 1.2 | +| `0x4652000000000016` | **Copy**
Has to be Signed
Sign: Yes
Chain and national numbering: C
Details: in a request the `cbPreviousReceiptReference` is mandatory. It contains the receipt number which was handed out as a copy, issued by the original cash register. When a copy of a receipt is requested, the phrase "duplicata" is returned with the fiskaltrust signature and must be printed on the receipt. Every time the receipt is reprinted, an up-counting number denoting how many times the receipt has been printed, is returned. It must be printed on the receipt and is then recorded in the journal.The layout and the information contained shall be the same as in the original document. | 1.2 | + +*Table 2. Type of Receipt: ftReceiptCase (FR – BOI-TVA-DECLA 30-10-30)* ### ftReceiptCaseFlag According to French law and regulations, various business transactions can result in specific combinations of types of receipts. For this, bytes 6, 5, 4 and 3 are used as combinable codes. These codes can be added with the logic operator "OR". -| **Value** | **Description** | **Version** | -|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------| +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | | `0x0000000000010000` | **Failed receipt**
If a ReceiptRequest includes this flag, the fiskaltrust.Middleware is set to "late signing mode." To exit this mode, an "end-of-failure" ReceiptRequest must be issued by the cash register terminal using a Zero Receipt. This may be necessary, for example, after a power or server outage.
For more information, see [Zero Receipt](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/general/cash-register-integration#zero-receipt). | 1.2 | | `0x0000000000020000` | **Training receipt**
All requests issued with this flag are chained and signed in a separate chain. The phrase "mode école" is printed on any artefact that is printed while the flag is being used. For national numbering "X" is used.
GT counters are not raised. | 1.2 | -| `0x0000000000040000` | **Reverse/voided receipt**
Used to distinguish regular receipts from receipts that have been voided by setting negative values for **both** Amount **and** Quantity in the ChargeItems and PayItems of the receipt. The `cbPreviousReceiptReference` should be set to the ReceiptReference of the receipt to be voided.| | -| `0x0000800000000000` | **Receipt request**
To prevent duplication of a requested receipt, the cash register terminal can include an additional parameter in the queue to influence the behavior of this "receipt request" when no receipt is found.
Parameter name: "receiptrequestmode"
Parameter values:
0 (default) … null is returned
1 … the request is handled in the same way as a new request. If processing is successful, the created ReceiptResponse is returned.| 1.2 | -| | Used to retrieve an already processed receipt from the fiskaltrust.Middleware using the `cbReceiptReference` field. The `cbTerminalID` can also be included in this request. ChargeItems and PayItems must be exactly the same as in the requested receipt. If a matching receipt is found, its content will be returned. If no matching receipt is found, a null value is returned. This may be necessary if a communication problem occurs while the fiskaltrust.Middleware processes a request. | 1.1 | +| `0x0000000000040000` | **Reverse/voided receipt**
Used to distinguish regular receipts from receipts that have been voided by setting negative values for **both** Amount **and** Quantity in the ChargeItems and PayItems of the receipt. The `cbPreviousReceiptReference` should be set to the ReceiptReference of the receipt to be voided. | | +| `0x0000800000000000` | **Receipt request**
To prevent duplication of a requested receipt, the cash register terminal can include an additional parameter in the queue to influence the behavior of this "receipt request" when no receipt is found.
Parameter name: "receiptrequestmode"
Parameter values:
0 (default) … null is returned
1 … the request is handled in the same way as a new request. If processing is successful, the created ReceiptResponse is returned. | 1.2 | +| | Used to retrieve an already processed receipt from the fiskaltrust.Middleware using the `cbReceiptReference` field. The `cbTerminalID` can also be included in this request. ChargeItems and PayItems must be exactly the same as in the requested receipt. If a matching receipt is found, its content will be returned. If no matching receipt is found, a null value is returned. This may be necessary if a communication problem occurs while the fiskaltrust.Middleware processes a request. | 1.1 | -*Table 34. Type of Receipt: ftReceiptCase Flags (FR – BOI-TVA-DECLA 30-10-30)* +*Table 3. Type of Receipt: ftReceiptCase Flags (FR – BOI-TVA-DECLA 30-10-30)* ## Type of Service: ftChargeItemCase @@ -77,124 +77,126 @@ The `ftChargeItemCase` defines the type of service in charge item blocks and how For France (FR), the country code is 0x4652. Thus, the value for an unknown `ftChargeItemCase` in France is `0x4652000000000000`. -| **Value** | **Description** | **Middleware Version** | -|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------| -| `0x4652000000000000` | **Unknown type of service for FR**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms, an allocation to standard /reduced-1 /reduced-2 / super-reduced/zero is attempted. | 1.2 | -| `0x4652000000000001` | **Undefined type of service for FR reduced-1**
(as of 1.1.2017, this is calculated with 5,5%). | 1.2 | -| `0x4652000000000002` | **Undefined type of service for FR reduced-2**
(as of 1.1.2016, this is calculated with 10%,
Loi n° 2015-1786 du 29 décembre 2015, art. 79). | 1.2 | -| `0x4652000000000003` | **Undefined type of service for FR normal**
(as of 1.1.2014, this is 20%,
Loi n° 2012-1510 du 29 décembre 2012, art. 68-III-B). | 1.2 | -| `0x4652000000000004` | **Undefined type of service for FR special (super-reduced)**
Includes all rates that are not contained in the previous ones (as of 1.1.2017, this can be, for example, 2,1%). | 1.2 | -| `0x4652000000000005` | **Undefined type of service for FR zero**
Includes data indicated with 0% sales tax and data where the sales tax is unknown, for example, about an outgoing invoice. Also, in cases where the sales tax should not be apparent, for example, in differential taxation, the data can be issued with this code. | 1.2 | -| `0x4652000000000006` | **Reverse charge**
Reversal of tax liability. | 1.2 | -| `0x4652000000000007` | **Not own sales**
In the data, a VAT-rate can be indicated. | 1.2 | -| `0x4652000000000008` | **Delivery reduced-1**
For processing, see (`0x4652000000000001`) | 1.2 | -| `0x4652000000000009` | **Delivery reduced-2**
For processing, see (`0x4652000000000002`) | 1.2 | -| `0x465200000000000A` | **Delivery normal**
For processing, see (`0x4652000000000003`) | 1.2 | -| `0x465200000000000B` | **Delivery special**
For processing, see (`0x4652000000000004`) | 1.2 | -| `0x465200000000000C` | **Delivery zero**
For processing, see (`0x4652000000000005`) | 1.2 | -| `0x465200000000000D` | **Other services reduced-1**
For processing, see (`0x4652000000000001`) | 1.2 | -| `0x465200000000000E` | **Other services reduced-2**
For processing, see (`0x4652000000000002`) | 1.2 | -| `0x465200000000000F` | **Other services normal**
For processing, see (`0x4652000000000003`) | 1.2 | -| `0x4652000000000010` | **Other services special**
For processing, see (`0x4652000000000004`) | 1.2 | -| `0x4652000000000011` | **Other services zero**
For processing, see (`0x4652000000000005`) | 1.2 | -| `0x4652000000000012` | **Catalogue services reduced-1**
For processing, see (`0x4652000000000001`) | 1.2 | -| `0x4652000000000013` | **Catalogue services reduced-2**
For processing, see (`0x4652000000000002`) | 1.2 | -| `0x4652000000000014` | **Catalogue services normal**
For processing, see (`0x4652000000000003`) | 1.2 | -| `0x4652000000000015` | **Catalogue services special**
For processing, see (`0x4652000000000004`) | 1.2 | -| `0x4652000000000016` | **Catalogue services zero**
For processing, see (`0x4652000000000005`) | 1.2 | -| `0x4652000000000017` | **Own consumption reduced-1**
For processing, see (`0x4652000000000001`) | 1.2 | -| `0x4652000000000018` | **Own consumption reduced-2**
For processing, see (`0x4652000000000002`) | 1.2 | -| `0x4652000000000019` | **Own consumption normal**
For processing, see (`0x4652000000000003`) | 1.2 | -| `0x465200000000001A` | **Own consumption special**
For processing, see (`0x4652000000000004`) | 1.2 | -| `0x465200000000001B` | **Own consumption zero**
For processing, see (`0x4652000000000005`) | 1.2 | -| `0x465200000000001C` | **Prepayment reduced-1**
For processing, see (`0x4652000000000001`) | 1.2 | -| `0x465200000000001D` | **Prepayment reduced-2**
For processing, see (`0x4652000000000002`) | 1.2 | -| `0x465200000000001E` | **Prepayment normal**
For processing, see (`0x4652000000000003`) | 1.2 | -| `0x465200000000001F` | **Prepayment special**
For processing, see (`0x4652000000000004`) | 1.2 | -| `0x4652000000000020` | **Prepayment zero**
For processing, see (`0x4652000000000005`) | 1.2 | -| `0x4652000000000021` | **Account of a third party/ third party name/ collection**
For processing, see (`0x4652000000000007`) | 1.2 | -| `0x4652000000000022` | **Obligation** | 1.2 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x4652000000000000` | **Unknown type of service for FR**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms, an allocation to standard /reduced-1 /reduced-2 / super-reduced/zero is attempted. | 1.2 | +| `0x4652000000000001` | **Undefined type of service for FR reduced-1**
(as of 1.1.2017, this is calculated with 5,5%). | 1.2 | +| `0x4652000000000002` | **Undefined type of service for FR reduced-2**
(as of 1.1.2016, this is calculated with 10%,
Loi n° 2015-1786 du 29 décembre 2015, art. 79). | 1.2 | +| `0x4652000000000003` | **Undefined type of service for FR normal**
(as of 1.1.2014, this is 20%,
Loi n° 2012-1510 du 29 décembre 2012, art. 68-III-B). | 1.2 | +| `0x4652000000000004` | **Undefined type of service for FR special (super-reduced)**
Includes all rates that are not contained in the previous ones (as of 1.1.2017, this can be, for example, 2,1%). | 1.2 | +| `0x4652000000000005` | **Undefined type of service for FR zero**
Includes data indicated with 0% sales tax and data where the sales tax is unknown, for example, about an outgoing invoice. Also, in cases where the sales tax should not be apparent, for example, in differential taxation, the data can be issued with this code. | 1.2 | +| `0x4652000000000006` | **Reverse charge**
Reversal of tax liability. | 1.2 | +| `0x4652000000000007` | **Not own sales**
In the data, a VAT-rate can be indicated. | 1.2 | +| `0x4652000000000008` | **Delivery reduced-1**
For processing, see (`0x4652000000000001`) | 1.2 | +| `0x4652000000000009` | **Delivery reduced-2**
For processing, see (`0x4652000000000002`) | 1.2 | +| `0x465200000000000A` | **Delivery normal**
For processing, see (`0x4652000000000003`) | 1.2 | +| `0x465200000000000B` | **Delivery special**
For processing, see (`0x4652000000000004`) | 1.2 | +| `0x465200000000000C` | **Delivery zero**
For processing, see (`0x4652000000000005`) | 1.2 | +| `0x465200000000000D` | **Other services reduced-1**
For processing, see (`0x4652000000000001`) | 1.2 | +| `0x465200000000000E` | **Other services reduced-2**
For processing, see (`0x4652000000000002`) | 1.2 | +| `0x465200000000000F` | **Other services normal**
For processing, see (`0x4652000000000003`) | 1.2 | +| `0x4652000000000010` | **Other services special**
For processing, see (`0x4652000000000004`) | 1.2 | +| `0x4652000000000011` | **Other services zero**
For processing, see (`0x4652000000000005`) | 1.2 | +| `0x4652000000000012` | **Catalogue services reduced-1**
For processing, see (`0x4652000000000001`) | 1.2 | +| `0x4652000000000013` | **Catalogue services reduced-2**
For processing, see (`0x4652000000000002`) | 1.2 | +| `0x4652000000000014` | **Catalogue services normal**
For processing, see (`0x4652000000000003`) | 1.2 | +| `0x4652000000000015` | **Catalogue services special**
For processing, see (`0x4652000000000004`) | 1.2 | +| `0x4652000000000016` | **Catalogue services zero**
For processing, see (`0x4652000000000005`) | 1.2 | +| `0x4652000000000017` | **Own consumption reduced-1**
For processing, see (`0x4652000000000001`) | 1.2 | +| `0x4652000000000018` | **Own consumption reduced-2**
For processing, see (`0x4652000000000002`) | 1.2 | +| `0x4652000000000019` | **Own consumption normal**
For processing, see (`0x4652000000000003`) | 1.2 | +| `0x465200000000001A` | **Own consumption special**
For processing, see (`0x4652000000000004`) | 1.2 | +| `0x465200000000001B` | **Own consumption zero**
For processing, see (`0x4652000000000005`) | 1.2 | +| `0x465200000000001C` | **Prepayment reduced-1**
For processing, see (`0x4652000000000001`) | 1.2 | +| `0x465200000000001D` | **Prepayment reduced-2**
For processing, see (`0x4652000000000002`) | 1.2 | +| `0x465200000000001E` | **Prepayment normal**
For processing, see (`0x4652000000000003`) | 1.2 | +| `0x465200000000001F` | **Prepayment special**
For processing, see (`0x4652000000000004`) | 1.2 | +| `0x4652000000000020` | **Prepayment zero**
For processing, see (`0x4652000000000005`) | 1.2 | +| `0x4652000000000021` | **Account of a third party/ third party name/ collection**
For processing, see (`0x4652000000000007`) | 1.2 | +| `0x4652000000000022` | **Obligation** | 1.2 | -*Table 35. Type of Service: ftChargeItemCase (FR – BOI-TVA-DECLA 30-10-30)* +*Table 4. Type of Service: ftChargeItemCase (FR – BOI-TVA-DECLA 30-10-30)* -In the following there are further guidelines for using ftChargeItemCase. +In the following section there are further guidelines for using ftChargeItemCase. ## Type of Payment: ftPayItemCase The `ftPayItemCase` defines the type of payment within the pay items block and how the fiskaltrust.SecurityMechanism processes individual payment of the receipt. -| **Value** | **Description** | **Middleware Version** | -|----------------------|------------------------------------------------------------------------------------------------------------------------------------|------------------------| -| `0x4652000000000000` | **Default value**
Unknown payment type: Automatic processing through the fiskaltrust.SecurityMechanism settings is attempted. | 1.2 | -| `0x4652000000000000` | **Unknown payment type for FR**
This is handled like a cash payment in national currency. | 1.2 | -| `0x4652000000000001` | **Cash payment in national currency**
cash | 1.2 | -| `0x4652000000000002` | **Cash payment in foreign currency**
cash | 1.2 | -| `0x4652000000000003` | **Crossed cheque**
cash | 1.2 | -| `0x4652000000000004` | **Debit card payment**
noncash | 1.2 | -| `0x4652000000000005` | **Credit card payment**
cash | 1.2 | -| `0x4652000000000006` | **Voucher payment (coupon) - voucher by money value**
cash | 1.2 | -| `0x4652000000000007` | **Online payment**
noncash | 1.2 | -| `0x4652000000000008` | **Customer card payment**
noncash | 1.2 | -| `0x4652000000000009` | **Other debit card**
noncash | 1.2 | -| `0x465200000000000A` | **Other credit card**
cash | 1.2 | -| `0x465200000000000B` | **Account receivable**
Delivery note/ settlement in foreign currency
internal | 1.2 | -| `0x465200000000000C` | **SEPA transfer**
noncash | 1.2 | -| `0x465200000000000D` | **Other transfer**
noncash | 1.2 | -| `0x465200000000000E` | **Cash book expense**
internal | 1.2 | -| `0x465200000000000F` | **Cash book contribution**
internal | 1.2 | -| `0x4652000000000010` | **Levy**
internal | 1.2 | -| `0x4652000000000011` | **Internal/ material consumption**
Can be used for bill
internal | 1.2 | -| `0x4652000000000012` | **Change**
tip
cash | 1.2 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x4652000000000000` | **Default value**
Unknown payment type: Automatic processing through the fiskaltrust.SecurityMechanism settings is attempted. | 1.2 | +| `0x4652000000000000` | **Unknown payment type for FR**
This is handled like a cash payment in national currency. | 1.2 | +| `0x4652000000000001` | **Cash payment in national currency**
cash | 1.2 | +| `0x4652000000000002` | **Cash payment in foreign currency**
cash | 1.2 | +| `0x4652000000000003` | **Crossed cheque**
cash | 1.2 | +| `0x4652000000000004` | **Debit card payment**
noncash | 1.2 | +| `0x4652000000000005` | **Credit card payment**
cash | 1.2 | +| `0x4652000000000006` | **Voucher payment (coupon) - voucher by money value**
cash | 1.2 | +| `0x4652000000000007` | **Online payment**
noncash | 1.2 | +| `0x4652000000000008` | **Customer card payment**
noncash | 1.2 | +| `0x4652000000000009` | **Other debit card**
noncash | 1.2 | +| `0x465200000000000A` | **Other credit card**
cash | 1.2 | +| `0x465200000000000B` | **Account receivable**
Delivery note/ settlement in foreign currency
internal | 1.2 | +| `0x465200000000000C` | **SEPA transfer**
noncash | 1.2 | +| `0x465200000000000D` | **Other transfer**
noncash | 1.2 | +| `0x465200000000000E` | **Cash book expense**
internal | 1.2 | +| `0x465200000000000F` | **Cash book contribution**
internal | 1.2 | +| `0x4652000000000010` | **Levy**
internal | 1.2 | +| `0x4652000000000011` | **Internal/ material consumption**
Can be used for bill
internal | 1.2 | +| `0x4652000000000012` | **Change**
tip
cash | 1.2 | -*Table 36. Type of Payment: ftPayItemCase (FR - BOI-TVA-DECLA 30-10-30)* +*Table 5. Type of Payment: ftPayItemCase (FR - BOI-TVA-DECLA 30-10-30)* ## Type of Signature: ftSignatureType The `ftSignatureType` indicates the type and origin of the signature. -| **Value** | **Description** | **Version** | -|----------------------|---------------------|-------------| -| `0x4652000000000000` | unknown FR | | -| `0x4652000000000001` | JWT | 1.2 | -| `0x4652000000000002` | Shift Closing Sum | 1.2 | -| `0x4652000000000003` | Day Closing Sum | 1.2 | -| `0x4652000000000004` | Month Closing Sum | 1.2 | -| `0x4652000000000005` | Year Closing Sum | 1.2 | -| `0x4652000000000006` | Archive Totals Sum | 1.2 | -| `0x4652000000000007` | Perpetual Total Sum | 1.2 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x4652000000000000` | unknown FR | | +| `0x4652000000000001` | JWT | 1.2 | +| `0x4652000000000002` | Shift Closing Sum | 1.2 | +| `0x4652000000000003` | Day Closing Sum | 1.2 | +| `0x4652000000000004` | Month Closing Sum | 1.2 | +| `0x4652000000000005` | Year Closing Sum | 1.2 | +| `0x4652000000000006` | Archive Totals Sum | 1.2 | +| `0x4652000000000007` | Perpetual Total Sum | 1.2 | -*Table 37. Type of Signature: ftSignatureType (FR - BOI-TVA-DECLA 30-10-30)* +*Table 6. Type of Signature: ftSignatureType (FR - BOI-TVA-DECLA 30-10-30)* ## Type of Journal: ftJournalType The `ftJournalType` is used in connection with the journal function and defines the journal stream given back according to the French law. In the `ftJournalType`, the ISO-3166-1-ALPHA-2 from ASCII value is converted into hex and used as byte 8 and 7. For France (FR) this is 0x4652. -| **Value** | **Description** | **Version** | -|----------------------|-------------------------------------|-------------| -| `0x4652000000000000` | Status information for queue FR | 1.2 | -| `0x4652000000000001` | Ticket ("T" group) export | 1.2 | -| `0x4652000000000002` | Payment Prove ("P" group) export | 1.2 | -| `0x4652000000000003` | Invoice ("I" group) export | 1.2 | -| `0x4652000000000004` | Grand Total ("G" group) export | 1.2 | -| `0x4652000000000007` | Bill ("B" group) export | 1.2 | -| `0x4652000000000008` | Archive ("A" group) export | 1.2 | -| `0x4652000000000009` | Log ("L" group) export | 1.2 | -| `0x465200000000000A` | Copy ("C" group) export | 1.2 | -| `0x465200000000000B` | Training ("X" group) export | 1.2 | -| `0x4652000000000010` | Export (in conjunction with Archiv) | 1.2 | - -*Table 38. Type of Journal: ftJournalType (FR - BOI-TVA-DECLA 30-10-30)* +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x4652000000000000` | Status information for queue FR | 1.2 | +| `0x4652000000000001` | Ticket ("T" group) export | 1.2 | +| `0x4652000000000002` | Payment Prove ("P" group) export | 1.2 | +| `0x4652000000000003` | Invoice ("I" group) export | 1.2 | +| `0x4652000000000004` | Grand Total ("G" group) export | 1.2 | +| `0x4652000000000007` | Bill ("B" group) export | 1.2 | +| `0x4652000000000008` | Archive ("A" group) export | 1.2 | +| `0x4652000000000009` | Log ("L" group) export | 1.2 | +| `0x465200000000000A` | Copy ("C" group) export | 1.2 | +| `0x465200000000000B` | Training ("X" group) export | 1.2 | +| `0x4652000000000010` | Export (in conjunction with Archiv) | 1.2 | + +*Table 7. Type of Journal: ftJournalType (FR - BOI-TVA-DECLA 30-10-30)* ### ftJournalTypeFlag Journals can be extracted in combination with these flags, indicated using codes in byte 5. These codes can be combined using the logic operator `OR`. -| **Value** | **Description** | **Version** | -|----------------------|---------------------------------------------------------------------------|-------------| -| `0x0000000000010000` | Receive Archive as zip-file created with ReceiptCase `0x4652000000000015` | 1.2 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0x0000000000010000` | Receive Archive as zip-file created with ReceiptCase `0x4652000000000015` | 1.2 | + +*Table 8. Type of Journal: ftJournalTypeFlag (FR - BOI-TVA-DECLA 30-10-30)* diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-gr/reference-tables/reference-tables.md index 2599e1e..54b4884 100644 --- a/poscreators/middleware-doc/middleware-gr/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-gr/reference-tables/reference-tables.md @@ -5,7 +5,13 @@ title: Reference Tables # Reference Tables -This chapter expands on the reference tables covered in [Reference Tables in General Part](../../general/reference-tables/reference-tables.md), with country-specific information applicable to the Greek market. The respective tables can be found in the following sub-sections. +This page expands on the reference tables covered in the [Reference Tables](../../general/reference-tables/reference-tables.md) of the Compliance Middleware, with country-specific information applicable to the Greek market. The respective tables can be found in the following subsections. + +:::info POSSystem API v2 Reference + +The Compliance Middleware [Reference Tables](../../general/reference-tables/reference-tables.md) contain the core POSSystem API v2 tagging structure used across all markets and should be your primary reference. + +::: As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for Greek 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. @@ -15,13 +21,13 @@ Every case that is sent to the middleware, or every Item that is being returned The overall format is built up of 4 sections: -_4752_2000_0010_0001 +_4752_2000_0010_0001 -_CCCC_vIII_gggg_xxxx +_CCCC_vIII_gggg_xxxx -| **Value** | **Description** | -|----------------------|-----------------------------------------------------------------------------------------------------| -|CCCC|(e.g 4752): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. GR = 4752) | -|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 leave 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 | \ No newline at end of file +| **Value** | **Description** | +| --------- | --------------- | +| CCCC |(e.g 4752): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. GR = 4752) | +| 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 leave 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. | diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/service-status-ftstate.md b/poscreators/middleware-doc/middleware-gr/reference-tables/service-status-ftstate.md index b447f17..29b19d6 100644 --- a/poscreators/middleware-doc/middleware-gr/reference-tables/service-status-ftstate.md +++ b/poscreators/middleware-doc/middleware-gr/reference-tables/service-status-ftstate.md @@ -17,23 +17,22 @@ _CCCC_vlll_gggg_gggg_ version 2 #### gggg_gggg - global tagging/flag -| **Value** | **Description** | **Middleware Version** | -|----------------------|-----------------------------------------------------------------------------------------------------|---------------------| -| `0000_0000 ` | Ready status. | 1.3.45 | -| `0000_0001 ` | **Security Mechanism is 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_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_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_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 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 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0000_0000` | Ready status. | 1.3.45 | +| `0000_0001` | **Security Mechanism is 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_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_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_0100` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 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** | -|----------------------|-----------------------------------------------------------------------------------------------------|---------------------| -|TBD|TBD|TBD| +cba c=reserved; b=reporting; a=scu related +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| TBD | TBD | TBD | diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-journal-ftjournaltype.md b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-journal-ftjournaltype.md index 5f2251a..1130dc4 100644 --- a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-journal-ftjournaltype.md +++ b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-journal-ftjournaltype.md @@ -5,8 +5,8 @@ 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#type-of-journal-ftjournaltype) of the General part with values applicable to the Greek market. +This table expands on the values provided in the [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) reference table of the Compliance Middleware with values applicable to the Greek market. -| **Value** | **Description** | **Version** | -|----------------------|--------------------------------|-------------| -| `000` | Status Information QueueGR | 1.3.45 | +| **Value** | **Description** | **Version** | +| --------- | --------------- |------------ | +| `000` | Status Information QueueGR | 1.3.45 | diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-payment-ftpayitemcase.md b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-payment-ftpayitemcase.md index 519d1c6..9d31871 100644 --- a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-payment-ftpayitemcase.md +++ b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-payment-ftpayitemcase.md @@ -5,48 +5,50 @@ 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 Greek market. +This table expands on the values provided in the [Type of Payment: ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) reference table of the Compliance Middleware with values applicable to the Greek market. ## Format -_CCCC_vlll_gggg_xxPP_ +_CCCC_vlll_gggg_xxPP_ #### v - version version 2 #### PP - payment type -| **Value** | **Description** | **Middleware version** | -| -------------------- | ---------------------------------------------------------------------------------------------- | ---------------------- | -| `00` | **Unknown payment type for GR**
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| + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `00` | **Unknown payment type for GR**
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 | -| `0100` | **IsInterface/AmountVerified**
Was verified by interface, automated amount transfer | 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 + +| **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 | +| `0100` | **IsInterface/AmountVerified**
Was verified by interface, automated amount transfer | 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 | diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-receipt-ftreceiptcase.md index fa81d20..641da1f 100644 --- a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-receipt-ftreceiptcase.md +++ b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-receipt-ftreceiptcase.md @@ -1,6 +1,6 @@ --- slug: /poscreators/middleware-doc/greece/reference-tables/ftreceiptcase -title: 'Type of receipt: ftReceiptCase' +title: 'Type of Receipt: ftReceiptCase' --- # Type of Receipt: ftReceiptCase @@ -11,79 +11,77 @@ For Greece (GR), the country code is `0x4752`. Thus, the value of an unknown `ft ## Format -_CCCC_vlll_gggg_txcc_ +_CCCC_vlll_gggg_txcc_ #### v - version version 2 -| **Value** | **Description** | -|----------------------|-----------------------------------------------------------------------------------------------------| -|t|ReceiptCaseType| -|txcc|ReceiptCase| -|gggg|global tagging/flag| -|lll|local tagging/flag| +| **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 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) | - +| --------- | ------------ | --------------- | +| `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 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 "GR"**

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 exception 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 | -| `2011` | **Daily 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 | -| `4011` | **Initiate SCU-switch**

| 1.3.45 | -| `4012` | **Finish SCU-switch**

| 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 marker. | 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, Address, 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 or 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** | -|-----------|-----------------|-------------------------| -|TBD|TBD|TBD| \ No newline at end of file +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0000` | **Unknown type for country-code "GR"**
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 exception 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 | +| `2011` | **Daily 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 | +| `4011` | **Initiate SCU-switch** | 1.3.45 | +| `4012` | **Finish SCU-switch** | 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 marker. | 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, Address, 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 or 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** | +| --------- | --------------- | ---------------------- | +| TBD | TBD | TBD | diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-service-ftchargeitemcase.md index a046f8c..1e00d16 100644 --- a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-service-ftchargeitemcase.md +++ b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-service-ftchargeitemcase.md @@ -1,46 +1,46 @@ --- slug: /poscreators/middleware-doc/greece/reference-tables/ftchargeitemcase -title: 'Type of service: 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 Greek market. +This table expands on the values provided in the [Type of Service: ftChargeItemCase](../../general/reference-tables/reference-tables.md#type-of-service-ftchargeitemcase) reference table of the Compliance Middleware with country-specific values applicable to the Greek market. ## Format -_CCCC_vlll_gggg_NNSV_ +_CCCC_vlll_gggg_NNSV_ #### v - version version 2 -#### V - VAT -https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm +#### V - VAT -| **Value** | **Description**| -| -------------------- | -------------- | -| `0` | **Unknown type of service for GR**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | -| `1` | **Discounted-1 VAT rate**
| -| `2` | **Discounted 2 VAT rate**
| -| `3` | **Normal VAT rate**
| -| `4` | **Super reduced 1 VAT rate**
| -| `5` | **Super reduced 2 VAT rate**
| -| `6` | **Parking VAT rate**
| -| `7` | **Zero VAT rate**
| -| `8` | **Not Taxable**
| +For more information, see [VAT rules and rates](https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm). +| **Value** | **Description**| +| --------- | -------------- | +| `0` | **Unknown type of service for GR**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | +| `1` | **Discounted-1 VAT rate** | +| `2` | **Discounted 2 VAT rate** | +| `3` | **Normal VAT rate** | +| `4` | **Super reduced 1 VAT rate** | +| `5` | **Super reduced 2 VAT rate** | +| `6` | **Parking VAT rate** | +| `7` | **Zero VAT rate** | +| `8` | **Not Taxable** | #### S - Type of Service -| **Value** | **Description** | -| -------------------- | -------------- | +| **Value** | **Description** | +| --------- | --------------- | | `0` | **Unknown type of service**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | -| `1` | **Delivery (supply of goods)**
| -| `2` | **Other service (supply of service)**
| +| `1` | **Delivery (supply of goods)** | +| `2` | **Other service (supply of service)** | | `3` | **Tip**
For owner use V=0 to 7, related to total amount
For Employee use V=8, Not Taxable. | 1.3.67 | | `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. | -| `5` | **Catalog service**
| -| `6` | **Not own sales / Agency business**
| -| `7` | **Own Consumption**
| +| `5` | **Catalog service** | +| `6` | **Not own sales / Agency business** | +| `7` | **Own Consumption** | | `8` | **Grant**
For Unreal Grant use V=0 to 7
For Real Grant use V=8 | | `9` | **Receivable**
Receivable creation is negative (-) amount
Receivable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.67| | `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.67| @@ -55,8 +55,8 @@ TBD #### gggg - global tagging/flag -| **Value** | **Description** | -| -------------------- | -------------- | +| **Value** | **Description** | +| --------- | --------------- | | `0001` | **IsVoid**
Marks ChargeItem as Void previous position. Quantity and amount are inverted, related to original item. | | `0002` | **IsReturn/IsRefund**
Marks ChargeItem as Return of good or service. Quantity and amount are inverted, related to original item. | | `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.67 | @@ -66,4 +66,5 @@ TBD | `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. | ## ftChargeItemCaseFlag + This table shows flags that can be added to each `ftChargeItemCase` with values applicable to the Greek market. diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-signature-ftsignatureformat.md b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-signature-ftsignatureformat.md index 7eee899..5b6f09c 100644 --- a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-signature-ftsignatureformat.md +++ b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-signature-ftsignatureformat.md @@ -1,14 +1,14 @@ --- slug: /poscreators/middleware-doc/greece/reference-tables/ftsignatureformat -title: 'Format of signature: ftSignatureFormat' +title: 'Format of Signature: ftSignatureFormat' --- # Format of Signature: ftSignatureFormat -The Middleware uses the same _ftSignatureFormats_ in Greece as in all other countries, as described in the [general part](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat). +The Middleware uses the same ftSignatureFormat in Greece as in all other countries, as described in the [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) reference table of the Compliance Middleware. ## ftSignatureFormatFlag -| Value | Description | Middleware-Version | -|-------|-------------|--------------------| -|TBD|TBD|TBD| \ No newline at end of file +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | -----------------------| +| TBD | TBD | TBD | \ No newline at end of file diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-signature-ftsignaturetype.md b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-signature-ftsignaturetype.md index 1f30a30..0144c23 100644 --- a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-signature-ftsignaturetype.md +++ b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-signature-ftsignaturetype.md @@ -1,40 +1,42 @@ --- slug: /poscreators/middleware-doc/greece/reference-tables/ftsignaturetype -title: 'Type of signature: ftSignatureType' +title: 'Type of Signature: ftSignatureType' --- # Type of Signature: ftSignatureType The `ftSignatureType` indicates the type and origin of the signature. The data type is `Int64` and can contain a country-specific code, a value following the ISO-3166-1-ALPHA-2 standard, converted from ASCII into hex and used as byte 8 and 7. - -For definitions regarding national laws, please refer to the appropriate appendix. +For definitions regarding national laws, refer to the appropriate appendix. ## Format -_CCCC_vlll_gggg_tsss +_CCCC_vlll_gggg_tsss #### v - version version 2 -#### t - Type/Category -| **Value** | **Description** | **Middleware-Version** | -|-----------|-----------------|------------------------| -| `0` | Uncategorized, Normal use (notification) | 1.3.45 | -| `1` | Information (notification), low priority | 1.3.45 | -| `2` | Alert (notification), high priority | 1.3.45 | -| `3` | Failure (notification), high priority | 1.3.45 | - -#### gggg - global flags -| **Value** | **Description** | **Middleware-Version** | -|-----------|-----------------|------------------------| -| `0001` | Archiving required.
Signatures marked with this flag are known to be archived related to market specific bookkeeping requirements. In case of offline usage or pure open-source usage, receipts/artefacts having this flag need to be handled as bookkeeping/accounting-relevant item. | 1.3.45 | -| `0010` | Printing/Visualization is optional | 1.3.45 | -| `0020` | Do not print/visualize | 1.3.45 | -| `0040` | Printed receipt only | 1.3.45 | -| `0080` | Digital receipt only | 1.3.45 | - -#### sss - SignatureCase -| **Value** | **Description** | **Caption** | **Middleware-Version** | -|-----------|-----------------|-----------------|------------------------| -|TBD|TBD|TBD| +#### t - Type/Category + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0` | Uncategorized, Normal use (notification) | 1.3.45 | +| `1` | Information (notification), low priority | 1.3.45 | +| `2` | Alert (notification), high priority | 1.3.45 | +| `3` | Failure (notification), high priority | 1.3.45 | + +#### gggg - global flags + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0001` | Archiving required.
Signatures marked with this flag are known to be archived related to market specific bookkeeping requirements. In case of offline usage or pure open-source usage, receipts/artefacts having this flag need to be handled as bookkeeping/accounting-relevant item. | 1.3.45 | +| `0010` | Printing/Visualization is optional. | 1.3.45 | +| `0020` | Do not print/visualize. | 1.3.45 | +| `0040` | Printed receipt only. | 1.3.45 | +| `0080` | Digital receipt only. | 1.3.45 | + +#### sss - SignatureCase + +| **Value** | **Description** | **Caption** | **Middleware Version** | +| --------- | --------------- | ----------- | ---------------------- | +| TBD | TBD | TBD | From baeb7ab4e4fed8c8e74b51a2cbd436826cf47baa Mon Sep 17 00:00:00 2001 From: deboragracio Date: Thu, 11 Jun 2026 17:26:12 +0200 Subject: [PATCH 5/6] IT/PT https://github.com/fiskaltrust/engineering/issues/1135 --- .../reference-tables/reference-tables.md | 24 ++-- .../service-status-ftstate.md | 27 ++-- .../type-of-journal-ftjournaltype.md | 6 +- .../type-of-payment-ftpayitemcase.md | 66 +++++----- .../type-of-receipt-ftreceiptcase.md | 119 +++++++++--------- .../type-of-service-ftchargeitemcase.md | 41 +++--- .../type-of-signature-ftsignatureformat.md | 5 +- .../type-of-signature-ftsignaturetype.md | 78 ++++++------ .../reference-tables/reference-tables.md | 24 ++-- .../service-status-ftstate.md | 25 ++-- .../type-of-journal-ftjournaltype.md | 8 +- .../type-of-payment-ftpayitemcase.md | 66 +++++----- .../type-of-receipt-ftreceiptcase.md | 112 ++++++++--------- .../type-of-service-ftchargeitemcase.md | 49 ++++---- .../type-of-signature-ftsignatureformat.md | 10 +- .../type-of-signature-ftsignaturetype.md | 52 ++++---- 16 files changed, 364 insertions(+), 348 deletions(-) diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/reference-tables.md index d038d06..29c8f5b 100644 --- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/reference-tables.md @@ -5,7 +5,13 @@ title: Reference Tables # Reference Tables -This chapter expands on the reference tables covered in [Reference Tables in General Part](../../general/reference-tables/reference-tables.md), with country-specific information applicable to the Italian market. The respective tables can be found in the following sub-sections. +This page expands on the reference tables covered in the [Reference Tables](../../general/reference-tables/reference-tables.md) of the Compliance Middleware, with country-specific information applicable to the Italian market. The respective tables can be found in the following subsections. + +:::info POSSystem API v2 Reference + +The Compliance Middleware [Reference Tables](../../general/reference-tables/reference-tables.md) contain the core POSSystem API v2 tagging structure used across all markets and should be your primary reference. + +::: As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for Italian 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. @@ -15,16 +21,16 @@ Every case that is sent to the middleware, or every Item that is being returned The overall format is built up of 4 sections: -_4954_2000_0010_0001 +_4954_2000_0010_0001 -_CCCC_vIII_gggg_xxxx +_CCCC_vIII_gggg_xxxx -| **Value** | **Description** | -|----------------------|-----------------------------------------------------------------------------------------------------| -|CCCC|(e.g 4954): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. IT = 4954) | -|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 leave 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 | +| **Value** | **Description** | +| --------- | --------------- | +| CCCC | (e.g 4954): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1). (e.g. IT = 4954) | +| 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 leave 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. | diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/service-status-ftstate.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/service-status-ftstate.md index 1875231..cba122e 100644 --- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/service-status-ftstate.md +++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/service-status-ftstate.md @@ -13,22 +13,21 @@ _CCCC_vlll_gggg_gggg_ version 2 #### gggg_gggg - global tagging/flag -| **Value** | **Description** | **Middleware Version** | -|----------------------|-----------------------------------------------------------------------------------------------------|---------------------| -| `0000_0001 ` | **Security Mechanism is 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_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_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_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 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 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0000_0001` | **Security Mechanism is 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_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_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_0100` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 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 | +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/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-journal-ftjournaltype.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-journal-ftjournaltype.md index 289101e..7bc4baf 100644 --- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-journal-ftjournaltype.md +++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-journal-ftjournaltype.md @@ -5,8 +5,8 @@ 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#type-of-journal-ftjournaltype) of the General part with values applicable to the Italian market. +This table expands on the values provided in the [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) reference table of the Compliance Middleware with values applicable to the Italian market. -| **Value** | **Description** | **Version** | -|----------------------|--------------------------------|-------------| +| **Value** | **Description** | **Version** | +| --------- | --------------- | ----------- | | `000` | Status Information QueueIT | 1.3.45 | diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-payment-ftpayitemcase.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-payment-ftpayitemcase.md index 09729d0..5098c84 100644 --- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-payment-ftpayitemcase.md +++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-payment-ftpayitemcase.md @@ -5,48 +5,50 @@ 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 Italian market. +This table expands on the values provided in the [Type of Payment: ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) reference table of the Compliance Middleware with values applicable to the Italian market. ## Format -_CCCC_vlll_gggg_xxPP_ +_CCCC_vlll_gggg_xxPP_ #### v - version version 2 #### PP - payment type -| **Value** | **Description** | **Middleware version** | -| -------------------- | ---------------------------------------------------------------------------------------------- | ---------------------- | -| `00` | **Unknown payment type for IT**
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| + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `00` | **Unknown payment type for IT**
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 | -| `0100` | **IsInterface/AmountVerified**
Was verified by interface, automated amount transfer | 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 + +| **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 | +| `0100` | **IsInterface/AmountVerified**
Was verified by interface, automated amount transfer | 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 | diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-receipt-ftreceiptcase.md index bce561d..a3e7307 100644 --- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-receipt-ftreceiptcase.md +++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-receipt-ftreceiptcase.md @@ -1,6 +1,6 @@ --- slug: /poscreators/middleware-doc/italy/reference-tables/ftreceiptcase -title: 'Type of receipt: ftReceiptCase' +title: 'Type of Receipt: ftReceiptCase' --- # Type of Receipt: ftReceiptCase @@ -16,76 +16,73 @@ _CCCC_vlll_gggg_txcc_ #### v - version version 2 -| **Value** | **Description** | -|----------------------|-----------------------------------------------------------------------------------------------------| -|t|ReceiptCaseType| -|txcc|ReceiptCase| -|gggg|global tagging/flag| -|lll|local tagging/flag| +| **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) | - +| --------- | ------------ | --------------- | +| `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 "IT"**

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 exception 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 | -| `2011` | **Daily 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 | -| `4011` | **Initiate SCU-switch**

| 1.3.45 | -| `4012` | **Finish SCU-switch**

| 1.3.45 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0000` | **Unknown type for country-code "IT"**
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 exception 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 | +| `2011` | **Daily 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 | +| `4011` | **Initiate SCU-switch** | 1.3.45 | +| `4012` | **Finish SCU-switch** | 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, Address, 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 | - +| **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, Address, 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** | -|-----------|-----------------|-------------------------| -| `001` | **X Report**

(Only for RT Devices - only for Zero receipts) Prints the X report containing the snapshot of sales totals and activities | 1.3.45 | -| `002` | **Print as non fiscal document**

(Only for RT Devices - only for Protocol receipts) Prints the protocol receipt | 1.3.67 | - +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `001` | **X Report**
(Only for RT Devices - only for Zero receipts) Prints the X report containing the snapshot of sales totals and activities | 1.3.45 | +| `002` | **Print as non fiscal document**
(Only for RT Devices - only for Protocol receipts) Prints the protocol receipt | 1.3.67 | diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-service-ftchargeitemcase.md index a863228..ac6e648 100644 --- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-service-ftchargeitemcase.md +++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-service-ftchargeitemcase.md @@ -1,23 +1,24 @@ --- slug: /poscreators/middleware-doc/italy/reference-tables/ftchargeitemcase -title: 'Type of service: 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 Italian market. +This table expands on the values provided in the [Type of Service: ftChargeItemCase](../../general/reference-tables/reference-tables.md#type-of-service-ftchargeitemcase) reference table of the Compliance Middleware with country-specific values applicable to the Italian market. ## Format -_CCCC_vlll_gggg_NNSV_ +_CCCC_vlll_gggg_NNSV_ #### v - version version 2 -#### V - VAT -https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm +#### V - VAT -| **Value** | **Description**| **Middleware Version** | -| -------------------- | -------------- | ---------------------- | +For more information, see [VAT rules and rates](https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm). + +| **Value** | **Description**| **Middleware Version** | +| --------- | -------------- | ---------------------- | | `0` | **Unknown type of service for IT**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.45 | | `1` | **Discounted-1 VAT rate**
(as of 1.1.2022, this is 10%). | 1.3.45 | | `2` | **Discounted 2 VAT rate**
(as of 1.1.2022, this is calculated with 5%). | 1.3.45 | @@ -28,11 +29,10 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm | `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** | -| -------------------- | -------------- | ---------------------- | +| **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 | @@ -47,12 +47,12 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm #### NN - nature of VAT -| **Value** | **Description** | **Spec. for Italian reg.** | **Middleware Version** | -| -------------------- | -------------- | -------------- | ---------------------- | -| `00` | **usual VAT applies**
| | 1.3.45 | +| **Value** | **Description** | **Spec. for Italian reg.** | **Middleware Version** | +| --------- | --------------- | ------------------------- | ---------------------- | +| `00` | **Usual VAT applies** | | 1.3.45 | | `10` | **Not Taxable**
1x can be used to specify more country specific details. For example, IGL|*NI (N3) marker mandatory
[10] not taxable - exports
[11] non-taxable - intra-community supplies
[12] non-taxable - transfers to San Marino
[13] non-taxable - transactions assimilated to export supplies
[14] non-taxable - following declarations of intent
[15] non-taxable - other operations which do not contribute to the formation of the ceiling | 1.3.45 | -| `20` | **Not Subject**
2x can be used to specify more country specific details.| *NS (N2) marker mandatory
[20] not subject to VAT pursuant to articles from 7 to 7-septies of Presidential Decree 633/72
[21] not subject, other cases| 1.3.45 | -| `30` | **Exempt**
3x| *ES (N4) marker mandatory
[30] exempt | 1.3.45 | +| `20` | **Not Subject**
2x can be used to specify more country specific details.| *NS (N2) marker mandatory
[20] not subject to VAT pursuant to articles from 7 to 7-septies of Presidential Decree 633/72
[21] not subject, other cases| 1.3.45 | +| `30` | **Exempt**
3x| *ES (N4) marker mandatory
[30] exempt | 1.3.45 | | `40` | **Margin scheme**
Do not print/show VAT rate and amount on receipt/invoice.
4x can be used to specify more country specific details. | *RM (N5) marker mandatory
[40] margin scheme / VAT not shown on the invoice | 1.3.45 | | `50` | **Reverse charge**
5x | *AL (N6) marker mandatory
[50] reverse charge - disposal of scrap and other salvage materials
[51] reverse charge - sale of gold and silver pursuant to law 7/2000 as well as used jewellery to OPO
[52] reverse charge - subcontracting in the construction sector
[53] reverse charge - sale of buildings
[54] reverse charge - supply of mobile phones
[55] reverse charge - supply of electronic products
[56] reverse charge - performance in the construction sector and related sectors
[57] reverse charge - energy sector transactions
[58] reverse charge - other cases | 1.3.45 | | `60` | **VAT paid in other EU country**
6x| (N7) marker mandatory
[60] paid in another EU country (provision of telecommunications, broadcasting and electronic services pursuant to art. 7-octies, paragraph 1 letter a, b, art. 74-sexies of Presidential Decree 633/72) | 1.3.45 | @@ -62,19 +62,20 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm #### lll - local tagging/flag -None +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 | +| **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 | +| `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 Italian market. diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-signature-ftsignatureformat.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-signature-ftsignatureformat.md index 14bd953..d24fbd3 100644 --- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-signature-ftsignatureformat.md +++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-signature-ftsignatureformat.md @@ -1,7 +1,8 @@ --- slug: /poscreators/middleware-doc/italy/reference-tables/ftsignatureformat -title: 'Format of signature: ftSignatureFormat' +title: 'Format of Signature: ftSignatureFormat' --- # Format of Signature: ftSignatureFormat -The Middleware uses the same _ftSignatureFormats_ in Italy as in all other countries, as described in the [general part](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat). + +The Middleware uses the same ftSignatureFormat in Italy as in all other countries, as described in the [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) reference table of the Compliance Middleware. diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-signature-ftsignaturetype.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-signature-ftsignaturetype.md index d7f0b10..3f5e5d6 100644 --- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-signature-ftsignaturetype.md +++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-signature-ftsignaturetype.md @@ -1,53 +1,55 @@ --- slug: /poscreators/middleware-doc/italy/reference-tables/ftsignaturetype -title: 'Type of signature: ftSignatureType' +title: 'Type of Signature: ftSignatureType' --- # Type of Signature: ftSignatureType The `ftSignatureType` indicates the type and origin of the signature. The data type is `Int64` and can contain a country-specific code, a value following the ISO-3166-1-ALPHA-2 standard, converted from ASCII into hex and used as byte 8 and 7. - -For definitions regarding national laws, please refer to the appropriate appendix. +For definitions regarding national laws, refer to the appropriate appendix. ## Format -_CCCC_vlll_gggg_tsss +_CCCC_vlll_gggg_tsss #### v - version version 2 -#### t - Type/Category -| **Value** | **Description** | **Middleware-Version** | -|-----------|-----------------|------------------------| -| `0` | Uncategorized, Normal use (notification) | 1.3.45 | -| `1` | Information (notification), low priority | 1.3.45 | -| `2` | Alert (notification), high priority | 1.3.45 | -| `3` | Failure (notification), high priority | 1.3.45 | - -#### gggg - global flags -| **Value** | **Description** | **Middleware-Version** | -|-----------|-----------------|------------------------| -| `0001` | Archiving required.
Signatures marked with this flag are known to be archived related to market specific bookkeeping requirements. In case of offline usage or pure open-source usage, receipts/artefacts having this flag need to be handled as bookkeeping/accounting-relevant item. | 1.3.45 | -| `0010` | Printing/Visualization is optional | 1.3.45 | -| `0020` | Do not print/visualize | 1.3.45 | -| `0040` | Printed receipt only | 1.3.45 | -| `0080` | Digital receipt only | 1.3.45 | - -#### sss - SignatureCase -| **Value** | **Description** | **Caption** | **Middleware-Version** | -|-----------|-----------------|-----------------|------------------------| -| `001` | Print below [PayItemBlock] / Document fiscalization

**RT-Printer**
[DATE(DD-MM-YYYY)] [TIME(HH:MM)][NEWLINE]
DOCUMENTO N. [z-Number]-[Document-Number][NEWLINE]
Codice Lotteria: [LotteryID][NEWLINE]
Codice Fiscale: [CustomerID][NEWLINE]
RT [SERIALNUMBER][NEWLINE]

**RT-Server**
[DATE(DD-MM-YYYY)] [TIME(HH:MM)][NEWLINE]
DOCUMENTO N. [z-Number]-[Document-Number][NEWLINE]
Codice Lotteria: [LotteryID][NEWLINE]
Codice Fiscale: [CustomerID][NEWLINE]
Server RT [SERIALNUMBER][NEWLINE]
Cassa [ftCashboxIdentification][NEWLINE]
-----FIRMA ELETTRONICA-----[NEWLINE]
[SHA-METADATA][NEWLINE]
---------------------------[NEWLINE]

**FE (Fattura Elettronica)**
[DATE(DD-MM-YYYY)] [TIME(HH:MM)][NEWLINE]
[VAT-ID][NEWLINE]
[ftReceiptIdentification][NEWLINE]
[ftCashboxIdentification][NEWLINE]
If number/signature is present/not null | [www.fiskaltrust.it] | 1.3.45 | -| `002` | Print below [Header] / Document Type

**Document-Type (1) Vendita**
di vendita o prestazione[NEWLINE]

**Document-Type (3) Reso**
emesso per ANNULLAMENTO[NEWLINE]
[NEWLINE]
Documento di riferimento:
N. [reference-z-Number]-[reference-Document-Number] del [reference-Document-Date(DD-MM-YYYY)][NEWLINE]
N. [reference-z-Number]-[reference-Document-Number] del [reference-Document-Date(DD-MM-YYYY)][NEWLINE]
RT [reference-RT-Printer-Serialnumber][NEWLINE]
Server RT [reference-RT-Server-Serialnumber][NEWLINE]
Cassa [reference-ftCashboxIdentification][NEWLINE]
XXX(\*) del [reference-Document-Date(DD-MM-YYYY)][NEWLINE]

**Document-Type (5) Annullo**
emesso per RESO MERCE[NEWLINE]
[NEWLINE]
Documento di riferimento:
N. [reference-z-Number]-[reference-Document-Number] del [reference-Document-Date(DD-MM-YYYY)][NEWLINE]
N. [reference-z-Number]-[reference-Document-Number] del [reference-Document-Date(DD-MM-YYYY)][NEWLINE]RT [reference-RT-Printer-Serialnumber][NEWLINE]
Server RT [reference-RT-Server-Serialnumber][NEWLINE]
Cassa [reference-ftCashboxIdentification][NEWLINE]
XXX(\*) del [reference-Document-Date(DD-MM-YYYY)][NEWLINE]
If number is on same system

If number is on different system
If number is unknown XXX(\*)
"POS" in the case of a POS receipt;
"VR" in the case of returnable containers;
“ND” in other cases | DOCUMENTO COMMERCIALE | 1.3.45 | -| `010` | RT printer/server serial number | | 1.3.45 | -| `011` | RT printer/server Z-Number | | 1.3.45 | -| `012` | RT printer/server Document-Number | | 1.3.45 | -| `013` | RT printer/server Document-Moment | | 1.3.45 | -| `014` | RT printer/server Document Type | | 1.3.45 | -| `015` | RT printer/server LotteryID | | 1.3.45 | -| `016` | RT printer/server CustomerID | | 1.3.45 | -| `017` | RT server SHA Metadata | | 1.3.45 | -| `018` | Amount | | 1.3.45 | -| `020` | RT Reference ZNumber | | 1.3.45 | -| `021` | RT Reference DocNumber | | 1.3.45 | -| `022` | RT Reference Document Moment | | 1.3.45 | +#### t - Type/Category + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0` | Uncategorized, Normal use (notification) | 1.3.45 | +| `1` | Information (notification), low priority | 1.3.45 | +| `2` | Alert (notification), high priority | 1.3.45 | +| `3` | Failure (notification), high priority | 1.3.45 | + +#### gggg - global flags + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0001` | Archiving required.
Signatures marked with this flag are known to be archived related to market specific bookkeeping requirements. In case of offline usage or pure open-source usage, receipts/artefacts having this flag need to be handled as bookkeeping/accounting-relevant item. | 1.3.45 | +| `0010` | Printing/Visualization is optional. | 1.3.45 | +| `0020` | Do not print/visualize. | 1.3.45 | +| `0040` | Printed receipt only. | 1.3.45 | +| `0080` | Digital receipt only. | 1.3.45 | + +#### sss - SignatureCase + +| **Value** | **Description** | **Caption** | **Middleware Version** | +| --------- | --------------- | ----------- | ---------------------- | +| `001` | Print below [PayItemBlock] / Document fiscalization

**RT-Printer**
[DATE(DD-MM-YYYY)] [TIME(HH:MM)][NEWLINE]
DOCUMENTO N. [z-Number]-[Document-Number][NEWLINE]
Codice Lotteria: [LotteryID][NEWLINE]
Codice Fiscale: [CustomerID][NEWLINE]
RT [SERIALNUMBER][NEWLINE]

**RT-Server**
[DATE(DD-MM-YYYY)] [TIME(HH:MM)][NEWLINE]
DOCUMENTO N. [z-Number]-[Document-Number][NEWLINE]
Codice Lotteria: [LotteryID][NEWLINE]
Codice Fiscale: [CustomerID][NEWLINE]
Server RT [SERIALNUMBER][NEWLINE]
Cassa [ftCashboxIdentification][NEWLINE]
-----FIRMA ELETTRONICA-----[NEWLINE]
[SHA-METADATA][NEWLINE]
---------------------------[NEWLINE]

**FE (Fattura Elettronica)**
[DATE(DD-MM-YYYY)] [TIME(HH:MM)][NEWLINE]
[VAT-ID][NEWLINE]
[ftReceiptIdentification][NEWLINE]
[ftCashboxIdentification][NEWLINE]
If number/signature is present/not null | [www.fiskaltrust.it] | 1.3.45 | +| `002` | Print below [Header] / Document Type

**Document-Type (1) Vendita**
di vendita o prestazione[NEWLINE]

**Document-Type (3) Reso**
emesso per ANNULLAMENTO[NEWLINE]
[NEWLINE]
Documento di riferimento:
N. [reference-z-Number]-[reference-Document-Number] del [reference-Document-Date(DD-MM-YYYY)][NEWLINE]
N. [reference-z-Number]-[reference-Document-Number] del [reference-Document-Date(DD-MM-YYYY)][NEWLINE]
RT [reference-RT-Printer-Serialnumber][NEWLINE]
Server RT [reference-RT-Server-Serialnumber][NEWLINE]
Cassa [reference-ftCashboxIdentification][NEWLINE]
XXX(\*) del [reference-Document-Date(DD-MM-YYYY)][NEWLINE]

**Document-Type (5) Annullo**
emesso per RESO MERCE[NEWLINE]
[NEWLINE]
Documento di riferimento:
N. [reference-z-Number]-[reference-Document-Number] del [reference-Document-Date(DD-MM-YYYY)][NEWLINE]
N. [reference-z-Number]-[reference-Document-Number] del [reference-Document-Date(DD-MM-YYYY)][NEWLINE]RT [reference-RT-Printer-Serialnumber][NEWLINE]
Server RT [reference-RT-Server-Serialnumber][NEWLINE]
Cassa [reference-ftCashboxIdentification][NEWLINE]
XXX(\*) del [reference-Document-Date(DD-MM-YYYY)][NEWLINE]
If number is on same system

If number is on different system
If number is unknown XXX(\*)
"POS" in the case of a POS receipt;
"VR" in the case of returnable containers;
“ND” in other cases | DOCUMENTO COMMERCIALE | 1.3.45 | +| `010` | RT printer/server serial number | | 1.3.45 | +| `011` | RT printer/server Z-Number | | 1.3.45 | +| `012` | RT printer/server Document-Number | | 1.3.45 | +| `013` | RT printer/server Document-Moment | | 1.3.45 | +| `014` | RT printer/server Document Type | | 1.3.45 | +| `015` | RT printer/server LotteryID | | 1.3.45 | +| `016` | RT printer/server CustomerID | | 1.3.45 | +| `017` | RT server SHA Metadata | | 1.3.45 | +| `018` | Amount | | 1.3.45 | +| `020` | RT Reference ZNumber | | 1.3.45 | +| `021` | RT Reference DocNumber | | 1.3.45 | +| `022` | RT Reference Document Moment | | 1.3.45 | diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-pt/reference-tables/reference-tables.md index afefa6a..df78ea5 100644 --- a/poscreators/middleware-doc/middleware-pt/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-pt/reference-tables/reference-tables.md @@ -5,7 +5,13 @@ title: Reference Tables # Reference Tables -This chapter expands on the reference tables covered in [Reference Tables in General Part](../../general/reference-tables/reference-tables.md), with country-specific information applicable to the Portuguese market. The respective tables can be found in the following sub-sections. +This page expands on the reference tables covered in the [Reference Tables](../../general/reference-tables/reference-tables.md) of the Compliance Middleware, with country-specific information applicable to the Portuguese market. The respective tables can be found in the following subsections. + +:::info POSSystem API v2 Reference + +The Compliance Middleware [Reference Tables](../../general/reference-tables/reference-tables.md) contain the core POSSystem API v2 tagging structure used across all markets and should be your primary reference. + +::: As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for Portuguese 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. @@ -15,13 +21,13 @@ Every case that is sent to the middleware, or every Item that is being returned The overall format is built up of 4 sections: -_5054_2000_0010_0001 +_5054_2000_0010_0001 -_CCCC_vIII_gggg_xxxx +_CCCC_vIII_gggg_xxxx -| **Value** | **Description** | -|----------------------|-----------------------------------------------------------------------------------------------------| -|CCCC|(e.g 5054): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. PT = 5054) | -|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 leave 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 | \ No newline at end of file +| **Value** | **Description** | +| --------- | --------------- | +| CCCC | (e.g 5054): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1). (e.g. PT = 5054) | +| 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 leave 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. | diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/service-status-ftstate.md b/poscreators/middleware-doc/middleware-pt/reference-tables/service-status-ftstate.md index 393fc68..5f282b4 100644 --- a/poscreators/middleware-doc/middleware-pt/reference-tables/service-status-ftstate.md +++ b/poscreators/middleware-doc/middleware-pt/reference-tables/service-status-ftstate.md @@ -13,22 +13,21 @@ _CCCC_vlll_gggg_gggg_ version 2 #### gggg_gggg - global tagging/flag -| **Value** | **Description** | **Middleware Version** | -|----------------------|-----------------------------------------------------------------------------------------------------|---------------------| -| `0000_0001 ` | **Security Mechanism is 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_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_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_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 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 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0000_0001 ` | **Security Mechanism is 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_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_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_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 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** | -|----------------------|-----------------------------------------------------------------------------------------------------|---------------------| -|TBD|TBD|TBD| - +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| TBD | TBD | TBD | diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-journal-ftjournaltype.md b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-journal-ftjournaltype.md index fc0f176..ec600f5 100644 --- a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-journal-ftjournaltype.md +++ b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-journal-ftjournaltype.md @@ -5,8 +5,8 @@ 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#type-of-journal-ftjournaltype) of the General part with values applicable to the Portuguese market. +This table expands on the values provided in the [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) reference table of the Compliance Middleware with values applicable to the Portuguese market. -| **Value** | **Description** | **Version** | -|----------------------|--------------------------------|-------------| -| `000` | Status Information QueuePT | 1.3.45 | +| **Value** | **Description** | **Version** | +| --------- | --------------- | ----------- | +| `000` | Status Information QueuePT | 1.3.45 | diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-payment-ftpayitemcase.md b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-payment-ftpayitemcase.md index d38c739..696e214 100644 --- a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-payment-ftpayitemcase.md +++ b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-payment-ftpayitemcase.md @@ -5,48 +5,50 @@ 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 Portuguese market. +This table expands on the values provided in the [Type of Payment: ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) reference table of the Compliance Middleware with values applicable to the Portuguese market. ## Format -_CCCC_vlll_gggg_xxPP_ +_CCCC_vlll_gggg_xxPP_ #### v - version version 2 #### PP - payment type -| **Value** | **Description** | **Middleware version** | -| -------------------- | ---------------------------------------------------------------------------------------------- | ---------------------- | -| `00` | **Unknown payment type for PT**
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| + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `00` | **Unknown payment type for PT**
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 | -| `0100` | **IsInterface/AmountVerified**
Was verified by interface, automated amount transfer | 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 + +| **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 | +| `0100` | **IsInterface/AmountVerified**
Was verified by interface, automated amount transfer. | 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 | diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-receipt-ftreceiptcase.md index 7d1aafc..71f1666 100644 --- a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-receipt-ftreceiptcase.md +++ b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-receipt-ftreceiptcase.md @@ -1,6 +1,6 @@ --- slug: /poscreators/middleware-doc/portugal/reference-tables/ftreceiptcase -title: 'Type of receipt: ftReceiptCase' +title: 'Type of Receipt: ftReceiptCase' --- # Type of Receipt: ftReceiptCase @@ -16,74 +16,72 @@ _CCCC_vlll_gggg_txcc_ #### v - version version 2 -| **Value** | **Description** | -|----------------------|-----------------------------------------------------------------------------------------------------| -|t|ReceiptCaseType| -|txcc|ReceiptCase| -|gggg|global tagging/flag| -|lll|local tagging/flag| +| **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 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) | - +| --------- | ------------ | --------------- | +| `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 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 "PT"**

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 exception 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 | -| `2011` | **Daily 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 | -| `4011` | **Initiate SCU-switch**

| 1.3.45 | -| `4012` | **Finish SCU-switch**

| 1.3.45 | +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0000` | **Unknown type for country-code "PT"**
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 exception 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 | +| `2011` | **Daily 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 | +| `4011` | **Initiate SCU-switch** | 1.3.45 | +| `4012` | **Finish SCU-switch** | 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 marker. | 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, Address, 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 or 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 | - +|-----------|-----------------|------------------------| +| `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 marker. | 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, Address, 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 or 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** | -|-----------|-----------------|-------------------------| -|TBD|TBD|TBD| \ No newline at end of file +| --------- | --------------- | ---------------------- | +| TBD | TBD | TBD | diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-service-ftchargeitemcase.md index a38aa1d..a06e99b 100644 --- a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-service-ftchargeitemcase.md +++ b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-service-ftchargeitemcase.md @@ -1,24 +1,25 @@ --- slug: /poscreators/middleware-doc/portugal/reference-tables/ftchargeitemcase -title: 'Type of service: 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 Portuguese market. +This table expands on the values provided in the [Type of Service: ftChargeItemCase](../../general/reference-tables/reference-tables.md#type-of-service-ftchargeitemcase) reference table of the Compliance Middleware with country-specific values applicable to the Portuguese market. ## Format -_CCCC_vlll_gggg_NNSV_ +_CCCC_vlll_gggg_NNSV_ #### v - version version 2 -#### V - VAT -https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm +#### V - VAT -| **Value** | **Description**| **Middleware Version** | -| -------------------- | -------------- | ---------------------- | -| `0` | **Unknown type of service for PT**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.45 | +For more information, see [VAT rules and rates](https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm). + +| **Value** | **Description**| **Middleware Version** | +| --------- | -------------- | ---------------------- | +| `0` | **Unknown type of service for PT**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.45 | | `1` | **Discounted-1 VAT rate**
(as of 1.1.2022, this is 10%). | 1.3.45 | | `2` | **Discounted 2 VAT rate**
(as of 1.1.2022, this is calculated with 5%). | 1.3.45 | | `3` | **Normal VAT rate**
(as of 1.1.2022, this is calculated with 22%). | 1.3.45 | @@ -28,28 +29,27 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm | `7` | **Zero VAT rate**
In the data, a VAT-rate can be indicated. | 1.3.45 | | `8` | **Not Taxable**
For processing, see (`0x5054000000000001`) | 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 | +| **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**
Receivable creation is negative (-) amount
Receivable 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** | **Spec. for Portuguese reg.** | **Middleware Version** | -| -------------------- | -------------- | -------------- | ---------------------- | -| `00` | **usual VAT applies**
| | 1.3.45 | +| **Value** | **Description** | **Spec. for Portuguese reg.** | **Middleware Version** | +| --------- | --------------- | ---------------------------- | ---------------------- | +| `00` | **Usual VAT applies** | | 1.3.45 | | `10` | **Not Taxable**
1x can be used to specify more country specific details. For example, IGL|*NI (N3) marker mandatory
[10] not taxable - exports
[11] non-taxable - intra-community supplies
[12] non-taxable - transfers to San Marino
[13] non-taxable - transactions assimilated to export supplies
[14] non-taxable - following declarations of intent
[15] non-taxable - other operations which do not contribute to the formation of the ceiling | 1.3.45 | | `20` | **Not Subject**
2x can be used to specify more country specific details.| *NS (N2) marker mandatory
[20] not subject to VAT pursuant to articles from 7 to 7-septies of Presidential Decree 633/72
[21] not subject, other cases| 1.3.45 | | `30` | **Exempt**
3x| *ES (N4) marker mandatory
[30] exempt | 1.3.45 | @@ -66,8 +66,8 @@ TBD #### gggg - global tagging/flag -| **Value** | **Description** | **Middleware Version** | -| -------------------- | -------------- | ---------------------- | +| **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 | @@ -77,4 +77,5 @@ TBD | `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 Portuguese market. diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-signature-ftsignatureformat.md b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-signature-ftsignatureformat.md index 659fc7d..8a16494 100644 --- a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-signature-ftsignatureformat.md +++ b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-signature-ftsignatureformat.md @@ -1,14 +1,14 @@ --- slug: /poscreators/middleware-doc/portugal/reference-tables/ftsignatureformat -title: 'Format of signature: ftSignatureFormat' +title: 'Format of Signature: ftSignatureFormat' --- # Format of Signature: ftSignatureFormat -The Middleware uses the same _ftSignatureFormats_ in Portugal as in all other countries, as described in the [general part](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat). +The Middleware uses the same ftSignatureFormat in Portugal as in all other countries, as described in the [Format of Signature: ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat) reference table of the Compliance Middleware. ## ftSignatureFormatFlag -| Value | Description | Middleware-Version | -|-------|-------------|--------------------| -|TBD|TBD|TBD| \ No newline at end of file +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| TBD | TBD | TBD | diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-signature-ftsignaturetype.md b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-signature-ftsignaturetype.md index 547e3da..c16da08 100644 --- a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-signature-ftsignaturetype.md +++ b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-signature-ftsignaturetype.md @@ -1,40 +1,42 @@ --- slug: /poscreators/middleware-doc/portugal/reference-tables/ftsignaturetype -title: 'Type of signature: ftSignatureType' +title: 'Type of Signature: ftSignatureType' --- # Type of Signature: ftSignatureType The `ftSignatureType` indicates the type and origin of the signature. The data type is `Int64` and can contain a country-specific code, a value following the ISO-3166-1-ALPHA-2 standard, converted from ASCII into hex and used as byte 8 and 7. - -For definitions regarding national laws, please refer to the appropriate appendix. +For definitions regarding national laws, refer to the appropriate appendix. ## Format -_CCCC_vlll_gggg_tsss +_CCCC_vlll_gggg_tsss #### v - version version 2 -#### t - Type/Category -| **Value** | **Description** | **Middleware-Version** | -|-----------|-----------------|------------------------| -| `0` | Uncategorized, Normal use (notification) | 1.3.45 | -| `1` | Information (notification), low priority | 1.3.45 | -| `2` | Alert (notification), high priority | 1.3.45 | -| `3` | Failure (notification), high priority | 1.3.45 | - -#### gggg - global flags -| **Value** | **Description** | **Middleware-Version** | -|-----------|-----------------|------------------------| -| `0001` | Archiving required.
Signatures marked with this flag are known to be archived related to market specific bookkeeping requirements. In case of offline usage or pure open-source usage, receipts/artefacts having this flag need to be handled as bookkeeping/accounting-relevant item. | 1.3.45 | -| `0010` | Printing/Visualization is optional | 1.3.45 | -| `0020` | Do not print/visualize | 1.3.45 | -| `0040` | Printed receipt only | 1.3.45 | -| `0080` | Digital receipt only | 1.3.45 | - -#### sss - SignatureCase -| **Value** | **Description** | **Caption** | **Middleware-Version** | -|-----------|-----------------|-----------------|------------------------| -|TBD|TBD|TBD| +#### t - Type/Category + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0` | Uncategorized, Normal use (notification) | 1.3.45 | +| `1` | Information (notification), low priority | 1.3.45 | +| `2` | Alert (notification), high priority | 1.3.45 | +| `3` | Failure (notification), high priority | 1.3.45 | + +#### gggg - global flags + +| **Value** | **Description** | **Middleware Version** | +| --------- | --------------- | ---------------------- | +| `0001` | Archiving required.
Signatures marked with this flag are known to be archived related to market specific bookkeeping requirements. In case of offline usage or pure open-source usage, receipts/artefacts having this flag need to be handled as bookkeeping/accounting-relevant item. | 1.3.45 | +| `0010` | Printing/Visualization is optional. | 1.3.45 | +| `0020` | Do not print/visualize. | 1.3.45 | +| `0040` | Printed receipt only. | 1.3.45 | +| `0080` | Digital receipt only. | 1.3.45 | + +#### sss - SignatureCase + +| **Value** | **Description** | **Caption** | **Middleware Version** | +| --------- | --------------- | ----------- | ---------------------- | +| TBD | TBD | TBD | TBD | From b0b06086d106bf1cbb6593ab87a1f24c646c796f Mon Sep 17 00:00:00 2001 From: deboragracio Date: Thu, 25 Jun 2026 16:31:44 +0200 Subject: [PATCH 6/6] Applied changes to AT, DE, FR https://github.com/fiskaltrust/engineering/issues/1135 --- .../reference-tables/reference-tables.md | 8 ++++++++ .../middleware-be/reference-tables/reference-tables.md | 2 +- .../reference-tables/reference-tables.md | 8 ++++++++ .../middleware-es/reference-tables/reference-tables.md | 2 +- .../reference-tables/reference-tables.md | 8 ++++++++ .../middleware-gr/reference-tables/reference-tables.md | 2 +- .../reference-tables/reference-tables.md | 2 +- .../middleware-pt/reference-tables/reference-tables.md | 2 +- 8 files changed, 29 insertions(+), 5 deletions(-) diff --git a/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md index 66689de..b6e336b 100644 --- a/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md @@ -7,6 +7,14 @@ title: Reference Tables This page expands on the reference tables covered in the [Reference Tables](../../general/reference-tables/reference-tables-v1.md) of the Compliance Middleware, with country-specific information applicable to the Austrian market. +:::info POSSystem API v2 Reference + +The Compliance Middleware [Reference Tables](../../general/reference-tables/reference-tables.md) contain the core POSSystem API v2 tagging structure used across all markets and should be your primary reference. + +::: + +As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for the 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. + ## Service Status: ftState The table below describes the 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`. diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md index 2aba18a..ea2a6ea 100644 --- a/poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md @@ -13,7 +13,7 @@ The Compliance Middleware [Reference Tables](../../general/reference-tables/refe ::: -As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for Belgian 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. +As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for the Belgian 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. ## Format diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/reference-tables.md index cf16d0b..3f77289 100644 --- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/reference-tables.md @@ -6,3 +6,11 @@ title: Reference Tables # Reference Tables This page expands on the reference tables covered in the [Reference Tables](../../general/reference-tables/reference-tables-v1.md) of the Compliance Middleware, with country-specific information applicable to the German market. The respective tables can be found in the following subsections. + +:::info POSSystem API v2 Reference + +The Compliance Middleware [Reference Tables](../../general/reference-tables/reference-tables.md) contain the core POSSystem API v2 tagging structure used across all markets and should be your primary reference. + +::: + +As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for the German 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. diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-es/reference-tables/reference-tables.md index d4e043f..597efc9 100644 --- a/poscreators/middleware-doc/middleware-es/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-es/reference-tables/reference-tables.md @@ -13,7 +13,7 @@ The Compliance Middleware [Reference Tables](../../general/reference-tables/refe ::: -As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for Spanish 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. +As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for the Spanish 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. ## Format diff --git a/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/reference-tables/reference-tables.md index 14937a5..bb81b68 100644 --- a/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/reference-tables/reference-tables.md @@ -7,6 +7,14 @@ title: Reference Tables This page expands on the reference tables covered in the [Reference Tables](../../general/reference-tables/reference-tables-v1.md) of the Compliance Middleware, with country-specific information applicable to the French market. +:::info POSSystem API v2 Reference + +The Compliance Middleware [Reference Tables](../../general/reference-tables/reference-tables.md) contain the core POSSystem API v2 tagging structure used across all markets and should be your primary reference. + +::: + +As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for the French 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. + ## Service Status: ftState The ftState is returned with every receipt response. Through this status, fiskaltrust.Middleware can signal its operability or request processing logic. diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-gr/reference-tables/reference-tables.md index 54b4884..7af2ee9 100644 --- a/poscreators/middleware-doc/middleware-gr/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-gr/reference-tables/reference-tables.md @@ -13,7 +13,7 @@ The Compliance Middleware [Reference Tables](../../general/reference-tables/refe ::: -As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for Greek 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. +As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for the Greek 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. ## Format diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/reference-tables.md index 29c8f5b..c03352b 100644 --- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/reference-tables.md @@ -13,7 +13,7 @@ The Compliance Middleware [Reference Tables](../../general/reference-tables/refe ::: -As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for Italian 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. +As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for the Italian 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. ## Format diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-pt/reference-tables/reference-tables.md index df78ea5..504f03a 100644 --- a/poscreators/middleware-doc/middleware-pt/reference-tables/reference-tables.md +++ b/poscreators/middleware-doc/middleware-pt/reference-tables/reference-tables.md @@ -13,7 +13,7 @@ The Compliance Middleware [Reference Tables](../../general/reference-tables/refe ::: -As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for Portuguese 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. +As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for the Portuguese 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. ## Format