fiskaltrust · mijomilicevic · Sep 23, 2021 · Sep 22, 2021 · Sep 22, 2021 · Sep 22, 2021
@@ -5,7 +5,7 @@ title: Cash register integration
 
 ## Cash Register Integration
 
-This chapter describes the cash register integration following the Austrian law. The general rules for cash register integration are described in the Chapter ["Cash Register Integration"](../../general/cash-register-integration/cash-register-integration.md) of the general part.
+This chapter describes the cash register integration following the Austrian law. The general rules for cash register integration are described in the Chapter ["Cash Register Integration"](../../general/cash-register-integration/cash-register-integration-regular-workflow.md) of the general part.
 
 ### Receipt Creation Process
 
@@ -73,7 +73,7 @@ The following diagram illustrates the workflow of a failure of the fiskaltrust.S
 
 ### Receipt for special functions
 
-This section describes receipt types used for special functions on the Austrian market and expands on the descriptions from the Chapter ["Receipt for special functions"](../../general/cash-register-integration/cash-register-integration.md#c-receipt-for-special-functions-54) of the general part.
+This section describes receipt types used for special functions on the Austrian market and expands on the descriptions from the Chapter ["Receipt for special functions"](../../general/cash-register-integration/cash-register-integration-regular-workflow.md#c-receipt-for-special-functions-54) of the general part.
 
 In accordance with §131b para. 2 BAO and the RKSV, as per 1.1.2017 (now 1.4.2017), each transaction receipt needs to be cryptographically signed with a signature creation device assigned to the taxpayer, to guarantee the immutability of the recording. In addition to these receipts, several other requirements are stated by the RKSV which can be met by creating the following receipts with special functions.
 

@@ -5,7 +5,7 @@ title: Cash register integration
 
 ## Cash register integration
 
-This chapter describes the cash register integration in accordance with French law. The general rules for cash register integration are described in the Chapter ["Cash Register Integration"](../../general/cash-register-integration/cash-register-integration.md) of this document.
+This chapter describes the cash register integration in accordance with French law. The general rules for cash register integration are described in the Chapter ["Cash Register Integration"](../../general/cash-register-integration/cash-register-integration-regular-workflow.md) of this document.
 
 ### Receipt creation process
 
@@ -26,7 +26,7 @@ The regular workflow of the fiskaltrust.SecurityMechanism in the French market d
 
 ### Receipt for special functions
 
-This section expands on the descriptions from the Chapter ["Receipt for special functions"](../../general/cash-register-integration/cash-register-integration.md#c-receipt-for-special-functions-54) of the general part and describes the receipt types used for special functions on the French market.
+This section expands on the descriptions from the Chapter ["Receipt for special functions"](../../general/cash-register-integration/cash-register-integration-regular-workflow.md#c-receipt-for-special-functions-54) of the general part and describes the receipt types used for special functions on the French market.
 
 In accordance with the Official Bulletin BOI-CF-COM-10-80-20160803 from August 3, 2016, and paragraph 3 bis of Article 286 of the French Tax Code, the proof of payment of a non-taxable person to a taxable person for a sale or service must be signed electronically and chained to ensure unalterability. There are additional requirements specified by law, which can be fulfilled by creating the following special receipts.
 

@@ -0,0 +1,36 @@
+### Failure Scenarios
+This Chapter describes the different scenarios of failure when using the fiskaltrust.Middleware and how to handle them.
+
+#### Failure of the fiskaltrust.Middleware
+If a cash register cannot communicate with the fiskaltrust.Middleware it is most likely due to a failure of the network connection, the Middleware host, or the Middleware itself. Such a failure means that the electronic recording system is not operational and there is no access to the appropriate journal.
+
+![no-middleware-connection](./images/07-no-middleware-connection.png)
+
+In this case, the following steps must be taken:
+
+  - The cash register or input station must automatically produce a receipt and its copy.
+  - The receipt must be marked with the identification "electronic recording system failed" and with the current failure counter.
+  - This copy needs to be kept until the failure is resolved. The creation and storing of the receipt copy can also be done electronically by the cash register or terminal.
+  - After re-establishing the communication to fiskaltrust.Middleware, the cash register or the input station must send all receipts marked with the identification "receipt copy, electronic recording system failed" to fiskaltrust.Middleware. The ReceiptCase must be flagged with the code "failed receipt" in order to indicate the failure to fiskaltrust.Middleware, which will then issue a receipt response with the the ftState "Late Signing Mode".
+
+An alternative way of handling such situation is the generation of a handwritten receipt. A carbon copy (or another copy, e.g. electronic copy) must be created and archived. After re-establishing communication with fikaltrust.Middleware, these copies are subsequently to be recorded as receipts. The receipt code has to be combined with the "failed receipt" code in order to notify fiskaltrust.Middleware of the failure.
+
+![late-signing-mode](./images/08-late-signing-mode.png)
+
+After fiskaltrust.Middleware has received an "end of failure receipt", the status of failure is terminated by receiving a response with normal state code.
+
+![end-late-signing-mode](./images/09-end-late-signing-mode.png)
+
+#### Failure of the Signature Creation Unit
+If the communication to the SCU fails (e.g. when the secure Signature Creation Device is not reachable), the POS System can continue to operate until the SCU is accessible again. Receipts created in a state where no communication is possible with the SCU are protected by the security mechanism of fiskaltrust. The fiskaltrust.Middleware will respond with the ftState = `0x02` "SCU communication failed". The POS System receives the response and processes the data it contains. For following Requests no more communication attempts are done to avoid long waiting times for each Receipt request/Receipt response sequence.
+<p>
+We are using the "circuit breaker" design pattern for our failed mode. As we are not trying to communicate with the SCU once a Call failed, the logic is preventing the failure from constantly reccuring during a temporary failure. With this approach the POSOperators are not blocked in their daily business, as we are avoiding long timeouts which would occur for every request to the SCU.
+</p>
+
+![no-scu-connection](./images/10-no-scu-connection.png)
+
+When the SCU is reachable again, a Zero-Receipt must be sent, which forces a communication retry towards the SSCD. If the fiskaltrust.Middleware is able to connect to the SCU again, the ftState = 0x00 (ok) is returned to the POS system via the response and the fiskaltrust.Middleware is ready for normal operation again. Furthermore, the response contains a listing of the requests that were not signed by the SSCD. The requests affected by the failure of the communication with the SCU do not have to be sent to the Queue again after the problem has been resolved.
+<br>
+>We recommend to make the zero-receipt after a failure a manual operation, and not automatically send it it via the POS system as soon as a failure state is returned. In most scenarios, only Operators can determine if the connection to the SSCD can be re-established, e.g. when the internet or the device is reconnected. Automatically sending zero-receipts might lead to unnecessary wait times if the connection can't be established at this point in time.
+
+![reestablished-scu-connection](./images/11-reestablished-connection.png)
@@ -26,36 +26,26 @@ This additional receipt data, generated by fiskaltrust.SecurityMechanism, is sen
 
 ![](./images/01-security-mechanism.png)
 
-<span id="_Toc527986801" class="anchor"></span>*Illustration 1. Process of the cash register integration with fiskaltrust.SecurityMechanism*
-
 #### Workflow - regular operation
 
 The following diagram illustrates the regular creation of a receipt with fiskaltrust.Middleware. The implementation of a fiskaltrust.SecurityMechanism may differ between countries and derive from their national laws – for details please refer to the appropriate appendix.
 
 ![](./images/02-regular-operation.png)
 
-<span id="_Toc527986802" class="anchor"></span>*Illustration 2. Workflow - regular operation*
-
 #### Workflow - special receipts
 
 The following diagram illustrates the creation of a special receipt with fiskaltrust.Middleware. For a general description of special receipts, please refer to ["Receipt for special functions"](#c-receipt-for-special-functions-54) Chapter. For national laws on receipts, refer to the appropriate appendix.
 
 ![](./images/03-special-receipts.png)
 
-<span id="_1597121563" class="anchor"></span>*Illustration 3. Workflow - special receipts*
-
 #### Workflow - failure of communication or failure of the fiskaltrust.Middleware (timeout)
 
 The following diagram illustrates the workflow of a failure of fiskaltrust.Middleware. For a description of recovering, please refer to the appropriate appendix.
 
 ![](./images/04-service-failure-timeout.png)
 
-<span id="_Toc527986805" class="anchor"></span>*Illustration 4. Workflow - failure of the fiskaltrust.Middleware (timeout)*
-
 ![](./images/05-service-failure.png)
 
-<span id="_Toc527986806" class="anchor"></span>*Illustration 5. Workflow - failure of the fiskaltrust.Middleware*
-
 ### <span id="c-receipt-for-special-functions-54">Receipt for special functions</span>
 
 There are several receipt requirements fulfilled by the fiskaltrust.Middleware in addition to the usual receipts produced by business transactions. Those special receipts can support the process of collecting additional information.
@@ -83,16 +73,7 @@ This receipt has a meaningful response from fiskaltrust.SecurityMechanism only t
 A closed queue can’t be reopened with a start receipt. Instead, a new queue has to be generated and initialized with a start receipt.
 
 ##### End of Failure Receipt (Collective Failure Report)
-
-If the fiskaltrust.Middleware stopped responding, if the response does not comply with the interface description, or if a cash register cannot communicate with fiskaltrust.Middleware anymore, it is most likely due to a failure of fiskaltrust.Middleware. Such a failure means that the electronic recording system is not operational and there is no access to the appropriate journal. In such case, the following steps must be taken:
-
-  - The cash register or input station must automatically produce a receipt and its copy.
-  - The receipt must be marked with the identification "electronic recording system failed" and with the current failure counter.
-  - This copy needs to be kept until the failure is resolved. The creation and storing of the receipt copy can also be done electronically by the cash register or terminal.
-  - After re-establishing the communication to fiskaltrust.Middleware, the cash register or the input station must send all receipts marked with the identification "receipt copy, electronic recording system failed" to fiskaltrust.Middleware. The ReceiptCase must be flagged with the code "failed receipt" in order to indicate the failure to fiskaltrust.Middleware, which will then issue a receipt response with the identification "electronic recording system failed" for each receipt.
-
-An alternative way of handling such situation is the generation of a handwritten receipt. A carbon copy (or another copy, e.g. electronic copy) must be created and archived. After re-establishing communication with fikaltrust.Middleware, these copies are subsequently to be recorded as receipts. The receipt code has to be combined with the "failed receipt" code in order to notify fiskaltrust.Middleware of the failure.
-
+The End of failure Receipt is required to exit the late signing mode when the receipts created during a failure are transferred.
 After fiskaltrust.Middleware has received an "end of failure receipt", the status of failure is terminated by receiving a response with normal state code.
 
 ### Receipt structure
@@ -137,4 +118,4 @@ The fiskaltrust.ReceiptJournal is used to record, hash, and chain all requests t
 
 ### fiskaltrust.ActionJournal 
 
-  The fiskaltrust.ActionJournal collects all operational incidents. This can be the date and time of start or failure of the service, as well as any other information related to fiskaltrust.Middleware and fiskaltrust.SecurityMechanism.
+The fiskaltrust.ActionJournal collects all operational incidents. This can be the date and time of start or failure of the service, as well as any other information related to fiskaltrust.Middleware and fiskaltrust.SecurityMechanism.
@@ -59,7 +59,7 @@ Business transactions can result in combinations of receipt types, which would b
 
 | **Value**            | **Description**                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | **Middleware Version** |
 |----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------|
-| `0x0000000000010000` | "failed receipt"<br />Receipt was created and handed out in a moment when the communication between the fiskaltrust.Middleware and the cash register terminal was not possible.<br />The transferred receipt contains data, which has been created during an outage of the fiskaltrust.Middleware. The original receipts are available in handwritten or digital format and are to be transferred. The first ReceiptRequest including this flag sets the fiskaltrust.Middleware in a "late signing mode". In order to leave this mode, an "end of failure" Receipt Request has to be made by the cash register terminal using a Zero Receipt. This can be necessary e.g. after a power or server outage.<br />["Zero Receipt"](../cash-register-integration/cash-register-integration.md#c-zero-receipt-60) section. | 1.0                    |
+| `0x0000000000010000` | "failed receipt"<br />Receipt was created and handed out in a moment when the communication between the fiskaltrust.Middleware and the cash register terminal was not possible.<br />The transferred receipt contains data, which has been created during an outage of the fiskaltrust.Middleware. The original receipts are available in handwritten or digital format and are to be transferred. The first ReceiptRequest including this flag sets the fiskaltrust.Middleware in a "late signing mode". In order to leave this mode, an "end of failure" Receipt Request has to be made by the cash register terminal using a Zero Receipt. This can be necessary e.g. after a power or server outage.<br />["Zero Receipt"](../cash-register-integration/cash-register-integration-regular-workflow.md#c-zero-receipt-60) section. | 1.0                    |
 | `0x0000000000020000` | "training receipt"<br />Used to separate the normal usage of the cash register system from the training mode. This flag can be added to each Receipt Request when training/testing is performed. This receipt will not produce any tax relevant changes.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             | 1.0                    |
 | `0x0000000000040000` | "reverse receipt" or "voided receipt"<br />Used to separate regular receipts from the receipts which were voided by setting the negative values for Amount and Quantity in Chargeitems and Payitems of the receipt. The cbPreviousReceiptReference should be set to the ReceiptReference of the Receipt which should be voided.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | 1.0                    |
 | `0x0000000000080000` | "handwritten receipt "<br />The transferred receipt contains data which has been collected in a handwritten receipt. There is no requirement for a precise time annotation on a handwritten receipt; we recommend using 12:00 for this purpose.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | 1.0                    |

@@ -1,6 +1,7 @@
 # [General Part](general/general.md)
 ## [Terminology](general/terminology/terminology.md)
-## [Cash Register Integration](general/cash-register-integration/cash-register-integration.md)
+## [Cash Register Integration](general/cash-register-integration/cash-register-integration-regular-workflow.md)
+## [Cash Register Integration](general/cash-register-integration/cash-register-integration-failure-scenarios.md)
 ## [Data Structures](general/data-structures/data-structures.md)
 ## [Function structures](general/function-structures/function-structures.md)
 ## [Communication](general/communication/communication.md)