The ftReceiptCase indicates the receipt type and defines how it should be processed by the fiskaltrust.SecurityMechanism in accordance with the 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 initializes a new fiskaltrust.SecurityMachanism including also the initialization of the used TSE in the background. Depending on the TSE-Type used, this includes different actions. On successful initialization, 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 desabling the fiskaltrust.SecurityMachanism including the deactivation of the client ID used in the TSE for the current queue. Optionally one can also deactivate the complete TSE used in background. This option will be avalable by a using a special flag soon. 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. |
AVSonstige SonstigerVorgang |
1.3- |
0x4445000000000005 |
monthly-closing TBD: close all open cbReceiptReference <-> Transaction-ID This receipt case works only with implicit flow. Calling without the ftReceiptCaseFlag 0x0000000100000000 ends up in an exception. |
[none] SonstigerVorgang |
1.3- |
0x4445000000000006 |
yearly-closing TBD: close all open cbReceiptReference <-> Transaction-ID 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 TBD: close all open cbReceiptReference <-> Transaction-ID This receipt case works only with implicit flow. Calling without the ftReceiptCaseFlag 0x0000000100000000 ends up in an exception. |
[none] SonstigerVorgang |
1.3- |
0x4445000000000008 |
start-transaction-receipt Starts a new, unfinished action. Use ftChargeItems and ftPayItems to hand over already known details for 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 Stopps/fails an ongoing action. It tries to finish an open transaction (accepts fail, continue on fail) and clears the cbReceiptReferece <-> Transaction-ID relation. |
AVBelegabbruch Kassenbeleg-V1 |
1.3- |
0x444500000000000C |
b2b-invoice TBD The BON_TYP (Beleg) of DSFinV-K can be overwritten by an ftReceiptCaseFlag. |
Beleg Kassenbeleg-V1 |
1.3- |
0x444500000000000D |
b2c-invoice TBD The BON_TYP (Beleg) of DSFinV-K can be overwritten by an ftReceiptCaseFlag. |
Beleg Kassenbeleg-V1 |
1.3- |
0x444500000000000E |
info-invoice TBD |
AVRechnung Kassenbeleg-V1 |
1.3- |
0x444500000000000F |
info-delivery-note TBD |
AVTransfer Kassenbeleg-V1 |
1.3- |
0x4445000000000010 |
iinfo-order To be used when goods are already delivered to customer and the ftPayItems array of the request is filled. Usualy 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 TBD The BON_TYP (Beleg) of DSFinV-K can be overwritten by an ftReceiptCaseFlag. |
Beleg Kassenbeleg-V1 |
1.3- |
0x4445000000000012 |
material consumption TBD |
AVSachbezung 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 and no pay items" (ReceiptRequest.ChargePayItems == [] && ReceiptRequest.PayItems == []) |
[none] SonstigerVorgang |
1.3- |
0x4445000000000014 |
protocol TBD |
[none] SonstigerVorgang |
1.3- |
0x4445000000000015 |
foreign sales TBD |
AVSonstige Kassenbeleg-V1 |
1.3- |
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 | out of service ??? clarify | 1.3- |
| 0x0000000000020000 | training receipt DSFinV-K: overrides BON_TYP=AVTraining |
1.3- |
| 0x0000000000040000 | reverse/voided receipt DSFinV-K: overrides BON_TYP=AVBelegstorno |
1.3- |
| 0x0000000000080000 | paper/handwritten receipt | 1.3- |
| 0x0000000000100000 | small business, not taxable sales. TBD: law reference | 1.3- |
| 0x0000000000200000 | receiver is a company | 1.3- |
| 0x0000000000400000 | contains characteristics related to UStG. TBD: law reference | 1.3- |
| 0x0000000000800000 | Request additional informations from used TSE device. This is valid for 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 | Request ExecuteSelftest and ExecuteTimeUpdate of used TSE device. This is valid for Zero-Receipts only and initiates a selftest and timeupdate at the used TSE device. Some devices (e.g. Swissbit) do require a selftest on a special period (e.g. 25h for Swissbit). On some devices this selftest is timeconsuming (e.g. up to 2 minutes on Swissbit) and therefore a pos-system can trigger this off peak serivcehours, to not block on receipt generation. If this is not used by pos-system the fiskaltrust-middleware cares on execution of selftest and timeupdate. |
1.3.1 |
| 0x0000000001000000 | Request clientId registration only. This is valid for Initial-Operations-Receipt only. If an Initial-Operations-Receipt is executed with this flag set, no lifecycle-check is done for the connected TSE-device and also no initialization is triggerd. This requires a proper initialized TSE-device and then the current cbCashBoxIdentification of the Queue is registerd as a cliendId at the TSE-device. |
1.3.1 |
| 0x0000000001000000 | Request clientId de-registration only. This is valid for Out-of-Operations-Receipt only. If an Out-of-Operations-Receipt is executed with this flag set, no lifecycle-change done for the connected TSE-device and also no diabling of the secure element is triggerd. This leaves back a TSE-device in initialized lifecycle and the current cbCashBoxIdentification of the Queue is de-registerd as a cliendId at the TSE-device. De-registration only is not supported by all TSE-devices. The normal behaviour of the Out-of-Operations-Receipt to disable the Queue is not influenced by this flag, what mean the Queue will not be useable anymore after execution of a Out-of-Operations-Receipt, the TSE-device can be used with a different Queue for further operations. |
1.3.1 |
| 0x0000000002000000 | Request download of TSE device .Tar-File. This is valid for Zero-Receipts only and processes a data-download from TSE device and this also leads to a data-upload to fiskaltrust-cloud. In case of an audit this can be used to get latest .Tar-File data available for download by using fiskaltrust-portal. .Tar-File download from TSE device is time consuming an may take more than 10 minutes to complete. If this is not used by pos-system the fiskaltrust-middleware cares on .Tar-File download after execution of daily-closing, monthly-closing, and yearly-closing. |
later |
| 0x0000000004000000 | Request to bypass/avoid the download of TSE device .Tar-File. This is valid for daily-, montly-, and yearly-closing only. After the operations described before, a download of TSE device .Tar-File is done. This can be time consuming and also requires to not run any other operations on TSE device to be successfull. If this should not be executed, this flag can be used to bypass execution and keep TSE device useable for imediate receipt signing requests. | later |
| 0x0000000008000000 | Request to update masterdata. This is valid for daily-, montly-, and yearly-closing only. Change of master-data already prepared in fiskaltrust-portal after rebuild of configuration and polled by fiskaltrust-middleware will be included in the moment of successfull execution of daily-, montly-, and yearly-closing. Master data are leaded by fiskaltrust-portal, manual change and update can be executed by ui, automated change and update will be possible by api (description will be provided later). This ftReceiptCaseFlag give a local point-of-sale-terminal the power do execute peviouse prepared master-data change. A default implementation could be to execute this on each daily-closing to get changes as soon done as they are reflacted to cashbox/queue. |
later |
| 0x0000000010000000 | Request to fail an raise exception on daily-closing with started transactions. | 1.3.1 |
| 0x0000000100000000 | Implicit Transaction. No Start-Transaction call to ´Sign´ 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 behaviour. | 1.3- |