Type of Receipt: ftReceiptCase
The ftReceiptCase indicates the receipt type and defines how the fiskaltrust.SecurityMechanism should process it following German law.
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 cbReceiptReferece 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 cbReceiptReferece 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 cbReceiptReferece 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 cbReceiptReferece <-> 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). 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). 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.19- |
ftReceiptCaseFlag
This table expands on the values provided in table ftReceiptCaseFlag in General Part 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 . | 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 and cbChargeItems (Same behavior as described in the general part). 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 BONTYP _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 | 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 |
| 0x0000800000000000 | Receipt request. Common behavior, see general part. | 1.3- |