fiskaltrust · volllly · Apr 10, 2026
@@ -15,6 +15,11 @@ The integration process is divided into discrete stages, each with specific obje
 
 ![integration phases](images/pos-creator-integration-phases.png)
 
+<!--
+I think this one is kind of correct... maybe step 4 comes before step 3.
+But I'm not sure this is still how we want to communicate it as we now have the accademy where most of that is tackled I think.
+-->
+
 Before proceeding with this guide, review the following resources:
 
 ### Video Tutorial

@@ -27,6 +27,12 @@ A so-called CashBox is a configuration container that connects (links) the confi
 
 ![cashbox](images/middleware.png)
 
+<!--
+This graphic is correct but "TSE" is a term that's specific to germany.
+The term that we use internally for those is "Secure Signature Creation Device" (SSCD).
+SSCD is used in some [other graphics](https://docs.fiskaltrust.eu/docs/poscreators/middleware-doc/general/cash-register-integration/failure-scenarios#failure-scenarios) aswell if I remember correctly but it's maybe not quite self explanatory.
+-->
+
 The steps for the creation and configuration of the CashBox are covered in the [further part of this document](#15-cashbox-creation).
 
 ### 1.3 Configuration of the SCU
@@ -37,6 +43,11 @@ To create an SCU configuration in the fiskaltrust.Portal, select the menu item `
 
 ![cashbox-config-scu-creation-01](images/cashbox-config-scu-creation-01.png)
 
+<!--
+The SCU that's shown here the "fiskaltrust.Middleware.SCU.DE.Fiskaly" has been deprecated replaced with the "fiskaltrust.Middleware.SCU.DE.FiskalyCertified".
+Also we should probably not show an `-rc` version but a normal one with out a prerelease prefix.
+-->
+
 Further configuration information is now required, and it may vary depending on the previously selected TSE package. In general, you specify here how the SCU can reach the TSE, and the endpoint via which the Queue will communicate with the SCU.
 
 In the upper section of this form you can specify how the SCU can reach the selected TSE (the fields depend on the selected TSE type):
@@ -65,6 +76,11 @@ Under the menu item ``Configuration -> Queue`` you will find the button for crea
 
 ![cashbox-config-queue-creation-01](images/cashbox-config-queue-creation-01.png)
 
+<!--
+We should also not show an `-rc` version here.
+-->
+
+
 After saving, a form appears in which you can specify the communication endpoint. We will use this later for the communication with the queue. For our example we can choose http(REST) by pressing the corresponding button.
 
 ![cashbox-config-queue-creation-02](images/cashbox-config-queue-creation-02.png)
@@ -105,6 +121,11 @@ After rebuild you can now download the launcher. The download of the launcher is
 
 ![icon-download-launcher](images/icon-download-launcher.png)
 
+<!--
+This button is still valid in FR and AT but in all of the other market's there's a download button with a popup.
+This download button and popup will also be enabled in AT and FR at some point in the maybe not so near future.
+-->
+
 ### 2.2 Enabling debug mode
 
 When the download is completed, you will receive a zip file containing the launcher, its corresponding configuration, and other required files. Now, unpack the zip file and in the newly unzipped folder locate a ``test.cmd`` file, which we will edit. Open it with an editor of your choice and add the argument `` -verbosity=Debug`` at the end of the second line (which starts with ``fiskaltrust.exe``). This will give us more detailed log output later. Now save and close the ``test.cmd`` file.

@@ -18,7 +18,13 @@ We are using the "circuit breaker" design pattern for our failed mode. As we are
 </p>
 
 ![no-scu-connection](./images/10-no-scu-connection.png)
-
+
+<!--
+In the graphic it says "TSE communication failure" but the TSE only exists in DE.
+Should maybe say "SSCD communication failure".
+Also what should be printed (last step) on the receipt depends on the market and is is returned by the queue in the response signatures.
+-->
+
 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 = `0xXXXX000000000000` (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.
 
 :::tip
@@ -35,13 +41,22 @@ We recomment to not manually print the text _SCU communication failed_, but to p
 
 ![reestablished-scu-connection](./images/11-reestablished-connection.png)
 
+<!--
+"TSE" is mentioned again.
+And I think the "list of requests that could not be signed by the TSE" is not applicable for all markets so we can probably remove it.
+-->
 
 ## Middleware not reachable or failing
 
 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)
 
+
+<!--
+What the POS has to do/print (last step) kind of depends on the market.
+-->
+
 In this case, the following steps must be taken:
 
   - The cash register or input station must automatically produce a receipt and its copy.
@@ -59,6 +74,8 @@ After fiskaltrust.Middleware has received an "end of failure receipt" (i.e. a ze
 
 We recommend to send re-send the first failed receipt with the _receipt request_ flag `0x0000800000000000`, which checks if a receipt was already sent and returns it in that case (to cover the case when the Middleware received and processed a receipt, but the answer was lost e.g. due to a network outage). More details about this flag can be found [here](../reference-tables/reference-tables.md#ftreceiptcaseflag)
 
+<!-- The receipt request flag presented here is the v1 flag. In v2 it's 0x0000000080000000. -->
+
 :::
 
 ## Cash register outage

@@ -26,6 +26,11 @@ This additional receipt data, generated by the fiskaltrust.SecurityMechanism, is
 
 ![](./images/01-security-mechanism.png)
 
+<!--
+This is still correct when not using the possystem api.
+But the workflow with the new v2 tagging does mostly go through the possystem api.
+-->
+
 In addition to the security mechanism workflow, the fiskaltrust.Middleware processes some of the most essential data fields on the receipt. The receipt number, serving as a unique identifier of a receipt transmitted by the cash register, is created by the fiskaltrust.Middleware to ensure that each receipt is properly processed.
 
 Compliance is achieved through a combination of several methods and components.
@@ -52,6 +57,8 @@ The following diagram illustrates the regular creation of a receipt with fiskalt
 
 ![](./images/02-regular-operation.png)
 
+<!--Also correct but in reality/the future the PosSystem api digital receipt etc. wil probably also be a player here. -->
+
 ### 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"](#receipt-for-special-functions) Chapter. For national laws on receipts, refer to the appropriate appendix.
@@ -66,6 +73,10 @@ The following diagram illustrates the workflow of a failure of fiskaltrust.Middl
 
 ![](./images/05-service-failure.png)
 
+<!--
+Those four workflow diagrams are I guess technically correct but I don't know how helpful they are to understand what's going on.
+ -->
+
 ## Receipt for special functions
 
 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.
@@ -102,6 +113,11 @@ This chapter describes the receipt structure.
 
 ![](./images/06-receipt-structure.png)
 
+<!--
+I think this one needs to be reworked for v2 and with the digital receipt.
+It's broadly correct but there's kind of more to it.
+-->
+
 <span id="_Toc527986807" class="anchor"></span>*Illustration* *6. Receipt Structure - general; cash register-receipt data (header, charge items, pay items, footer) and fiskaltrust-receipt data (header, charge items, pay items, signature, footer)*
 
 ### Receipt Header

@@ -18,6 +18,12 @@ For more detailed information, please visit the [PosCreators documentation](../.
 - depending on the market, set the chargeitem-, payitem- and receiptcases (not every operation may have an e.g. receiptcase in each market -> in that case, do nothing. example: order in AT and FR)
 ![](./images/12-multi-market-mapping.png)
 
+<!--
+With the possystem api the business case factory is not needed amymore.
+That's all handled by the possystem api and the v2 tagging.
+Also the mapping table below is obsolete when using the v2 tagging with the possystem api.
+-->
+
 ## Mapping Table
 The table below shows a comparison of common business cases (e.g. ftReceiptcases, ftChargeItemcases and ftPayItemcases) for every market.
 More details for ftReceiptcases, ftPayItemcases and ft ChargeItemcases can be found for each market on the appropriate country specific appendix.

@@ -11,6 +11,11 @@ The communication protocol is specified by setting the respective URL in the pac
 
 ![queue-configuration](./images/url-configuration.png)
 
+<!--
+Again an -rc version is shown.
+We should probably show a rest url as that's the most commonly used option.
+-->
+
 _Buttons for other URL options (like gRPC) may be available as well, depending on the country._
 
 :::info

@@ -35,6 +35,11 @@ After configuring the CashBox in the portal, following so-called "Launchers" are
 | ![launcher-mono](images/launcher-mono.png)       | Mono Launcher                           | **For starting the Middleware on Linux/macOS with Internet connection.**<br />The launcher loads the configuration file and its needed packages during the start from the fiskaltrust packages-server.                                                                                                         | supported | supported  | supported | supported  |
 | ![launcher-android](images/launcher-android.png) | Android Launcher                        | **For starting the Middleware on Android with Internet connection.**<br />The needed packages for operation are already included. The launcher loads the configuration file during the start from the fiskaltrust packages-server.<br />The configuration options are limited to keep the package sizes small. |           | supported* |           | supported* |
 
+<!--
+Now in most markets (all except AT and FR) there is one download button that opens a popup with those options.
+Actually, the whole content of this page is only correct for AT, FR and DE. As the new markets (will) also use the new launcher.
+-->
+
 *availability dependent on the CashBox configuration. For more details, see the [platform documentation for Android](../../middleware-de-kassensichv/operation-modes/on-premise-platforms/android.md).
 
 The received zip-compressed folders need to be unzipped and can be moved or renamed if necessary.

@@ -8,7 +8,9 @@ title: Operation Modes
 The fiskaltrust.Middleware can be operated in following operational environments:
 
 ![operational-environments](images/operational-environments.svg)
-([click to enlarge](images/operational-environments.svg))
+<!--
+I think we should mention the cloudcashbox here as well.
+-->
 
 Identification of the operational environment from the perspective of a POS operator: