diff --git a/poscreators/getting-started/get-started.md b/poscreators/getting-started/get-started.md
index d6b0dc4..2b9a5a4 100644
--- a/poscreators/getting-started/get-started.md
+++ b/poscreators/getting-started/get-started.md
@@ -5,24 +5,34 @@ title: Introduction
# Introduction
-This guide provides a technical overview of the integration and onboarding workflow for PosCreators. It outlines the key stages required to successfully integrate **fiskaltrust.Middleware** into a POS system and to progress to pilot installations.
+This page provides an overview of the steps required to get started as a PosCreator with fiskaltrust.
-Successful completion of these stages ensures a reliable and compliant deployment of fiskaltrust solutions in your POS environment.
+It outlines the key stages from initial setup and onboarding to the technical integration of **fiskaltrust.Middleware** into your POS system and preparation for pilot installations.
+
+Following these stages ensures a reliable and compliant deployment of fiskaltrust solutions.
## Integration Workflow
-The integration process is divided into discrete stages, each with specific objectives and deliverables as follows:
+The integration workflow focuses on the technical implementation of **fiskaltrust.Middleware** and is divided into discrete stages, each with specific objectives and deliverables.
+
+
+
+:::info
+
+The [Onboarding Process](./onboarding-process.md) is described separately and is not part of the middleware integration itself.
+
+:::
-
+## Additional Resources
-Before proceeding with this guide, review the following resources:
+The following resources provide a high-level walkthrough of the overall process for PosCreators.
-### Video Tutorial
+### Tutorial video
-A technical walkthrough covering the complete PosCreator onboarding process can be viewed as follows:
+A technical introduction to fiskaltrust.Middleware, including onboarding concepts, integration phases, and rollout preparation:
### Presentation Slides
-Download the slides corresponding to the video tutorial [here](presentations/technical-onboarding-poscreators.pdf).
+Download the corresponding slides for a structured overview of the onboarding and integration process [here](presentations/technical-onboarding-poscreators.pdf).
diff --git a/poscreators/getting-started/images/cashbox-config-cashbox-creation-01.png b/poscreators/getting-started/images/cashbox-config-cashbox-creation-01.png
index 8983e09..741e106 100644
Binary files a/poscreators/getting-started/images/cashbox-config-cashbox-creation-01.png and b/poscreators/getting-started/images/cashbox-config-cashbox-creation-01.png differ
diff --git a/poscreators/getting-started/images/cashbox-config-queue-creation-01.png b/poscreators/getting-started/images/cashbox-config-queue-creation-01.png
index 4c979fa..7e9016b 100644
Binary files a/poscreators/getting-started/images/cashbox-config-queue-creation-01.png and b/poscreators/getting-started/images/cashbox-config-queue-creation-01.png differ
diff --git a/poscreators/getting-started/images/cashbox-config-scu-creation-01.png b/poscreators/getting-started/images/cashbox-config-scu-creation-01.png
index 000c959..bc86700 100644
Binary files a/poscreators/getting-started/images/cashbox-config-scu-creation-01.png and b/poscreators/getting-started/images/cashbox-config-scu-creation-01.png differ
diff --git a/poscreators/getting-started/images/icon-download-launcher.png b/poscreators/getting-started/images/icon-download-launcher.png
index b6e2602..44687d4 100644
Binary files a/poscreators/getting-started/images/icon-download-launcher.png and b/poscreators/getting-started/images/icon-download-launcher.png differ
diff --git a/poscreators/getting-started/images/middleware.svg b/poscreators/getting-started/images/middleware.svg
new file mode 100644
index 0000000..693668a
--- /dev/null
+++ b/poscreators/getting-started/images/middleware.svg
@@ -0,0 +1,3 @@
+
+
+
\ No newline at end of file
diff --git a/poscreators/getting-started/images/pos-creator-integration-phases.svg b/poscreators/getting-started/images/pos-creator-integration-phases.svg
new file mode 100644
index 0000000..5672007
--- /dev/null
+++ b/poscreators/getting-started/images/pos-creator-integration-phases.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/poscreators/getting-started/middleware-integration.md b/poscreators/getting-started/middleware-integration.md
index 11c0a5b..280ebdf 100644
--- a/poscreators/getting-started/middleware-integration.md
+++ b/poscreators/getting-started/middleware-integration.md
@@ -17,91 +17,99 @@ The following steps describe how to configure and test the integration of **ft.M
### 1.1 Overview
-As a POS creator, your first goal is to be able to send requests to our free ft.Middleware from your POS-System, and to be able to test your integration. The following sections summarize the configuration of a CashBox and its components, which are required to achieve this goal.
+As a POS creator, your first goal is to send requests from your POS system to our free ft.Middleware and test the integration. The following sections summarize the CashBox configuration and its components, which are required to achieve this goal.
-**Note:** All steps which are described in this document are for testing purposes, and, unless specifically stated otherwise, should be carried out in the Sandbox instance of the fiskaltrust.Portal.
+:::note
+
+All steps in this document are intended for testing purposes and should be performed in the Sandbox environment of the fiskaltrust Portal, unless otherwise specified.
+
+:::
### 1.2 CashBox
-A so-called CashBox is a configuration container that connects (links) the configurations of individual components of the fiskaltrust.Middleware which can be configured in the fiskaltrust.Portal. The fiskaltrust.Portal can contain the configurations of Queues, SCUs, and various Helpers - and a CashBox connects them with each other. Next, we will configure an SCU and a Queue needed for testing, and then connect them together in the CashBox.
+A CashBox is a configuration container that connects (links) the configurations of individual components of the fiskaltrust.Middleware which can be configured in the fiskaltrust.Portal. The fiskaltrust.Portal can contain the configurations of Queues, SCUs, and various Helpers. A CashBox links them together to form a complete Middleware configuration.
-
+In the next steps, an SCU and a Queue will be created for testing purposes and connected via a CashBox.
-The steps for the creation and configuration of the CashBox are covered in the [further part of this document](#15-cashbox-creation).
+
+
+The steps for the creation and configuration of the CashBox are described in the [1.5 CashBox creation](#15-cashbox-creation) section.
### 1.3 Configuration of the SCU
-The SCU (Signature Creation Unit) is a component of the ft.Middleware, which is responsible for the communication with the TSE. Depending on which TSE you plan to use, the SCU will have to be configured accordingly.
+The SCU (Signature Creation Unit) is a component of the ft.Middleware responsible for the communication with the TSE. The configuration of an SCU depends on the specific TSE you intend to use.
-To create an SCU configuration in the fiskaltrust.Portal, select the menu item ``Configuration -> Signature creation unit`` and press the button "Create". Enter a short description (name) and select the package for your TSE at "Package Name". Then select the latest version under "Package Version" and press the button "Save".
+To create an SCU configuration in the fiskaltrust.Portal, select the menu item `Configuration` / `Signature creation unit` and click "Create". Enter a short description (name) for the SCU, then select the package for your TSE under "Package Name". Next, choose the latest version under "Package Version" and select the appropriate "Outlet". Click "Save" to create the SCU configuration.
-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):
+After saving, additional configuration information are required. These depend on the selected TSE package. Typically, you define how the SCU connects to the TSE, as well as the endpoint through which the Queue communicates with the SCU.
-- **Cryptovision** - Enter the device path, the drive letter followed by the colon to which you have connected the TSE. For example ``E:``
+In the upper section of the form, you can configure how the SCU connects to the selected TSE. The available fields depend on the chosen TSE type:
-- **Swissbit** - Enter the device path, the drive letter followed by the colon to which you have connected the TSE. For example ``E:``
+- **Cryptovision** - Enter the device path (drive letter followed by a colon) where the TSE is connected, for example `E:`.
+- **Swissbit** - Enter the device path (drive letter followed by a colon) where the TSE is connected, for example `E:`.
+- **Diebold - Nixdorf** - Enter the COM port to which the TSE is connected, for example `COM6`.
+- **Epson** - Under revision.
+- **fiskaly Cloud-TSE** - Enter the TSS ID, API key and the "Secret" key. One can obtain them for testing purposes from the official fiskaly website and fiskaly dashboard. Alternatively, you can purchase a free trial fiskaly Cloud-TSE in the sandbox fiskaltrust.Portal shop. This will automatically create an SCU with the corresponding data.
-- **Diebold - Nixdorf** - Enter the com port to which you have connected the TSE. For example ``COM6``
+:::note
-- **Epson** - Under revision.
+Select the outlet in the shop before you add the fiskaly Cloud-TSE test to your shopping cart (via the outlet dropdown in the upper area).
-- **fiskaly Cloud-TSE** - Enter the TSS ID, API key and the "Secret" key. One can obtain them for testing purposes from the official fiskaly website and fiskaly dashboard. Alternatively, you can purchase a free trial fiskaly Cloud-TSE in our sandbox fiskaltrust.Portal shop. This will automatically create a SCU with the corresponding data for you. Note: Select the outlet in the shop before you add the test fiskaly Cloud-TSE to your shopping cart (outlet drop-down in the upper area).
+:::
-To specify the communication endpoint for reaching the SCU, select, for example, the "gRPC" by pressing the corresponding button in the lower part of the form . The input field is filled in automatically and can be edited further if necessary. For the goal of this document, the automatically filled gRPC endpoint is sufficient.
+To specify the communication endpoint for the SCU, select, for example, the "gRPC" by pressing the corresponding button in the lower part of the form . The input field is filled automatically and can be edited if necessary. For the purposes of this guide, the automatically filled gRPC endpoint is sufficient.
-Save the configuration of your SCU after entering the required data. In the next step we will configure the Queue.
+Save the configuration of your SCU after entering the required data. In the next step, we will configure the Queue.
### 1.4 Configuration of the Queue
-The Queue is a component of the fiskaltrust.Middleware which collects the received data from the POS-System and is responsible for creating the request chain. It is the component of the fiskaltrust.Middleware with which your POS-System communicates. You send your data to it and receive signatures (and other data) back.
+The Queue is a component of the fiskaltrust.Middleware that collects the received data from the POS system and is responsible for creating the request chain. It is the component of the fiskaltrust.Middleware with which your POS system communicates. You send your data to it and receive signatures (and other data) in return.
-Under the menu item ``Configuration -> Queue`` you will find the button for creating a new Queue. Press this button to get to the input form. Enter a short description (name) and the CashBoxIdentification. The CashBoxIdentification will later be used by the SCU as clientID for the TSE. It is therefore important to enter a ["printable string"](https://en.wikipedia.org/wiki/PrintableString) with a maximum of 20 characters and that the **used value is unique**.
+Under the menu item `Configuration` / `Queue`, click the "Add" button to create a new Queue. This opens the input form. Enter a short description (name) and the CashBoxIdentification. The CashBoxIdentification is later used by the SCU as clientID for the TSE. It must therefore be a **unique value**, formatted as a ["printable string"](https://en.wikipedia.org/wiki/PrintableString) with a maximum length of 20 characters.
-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.
+After saving, a form appears where you can specify the communication endpoint. This endpoint will later be used for communication with the Queue. For our example, we will choose http(REST) by clicking the corresponding button.
-After saving, we are done with the configuration of the Queue and can now create the CashBox (our configuration container) in the next step.
+Once saved, the Queue configuration is complete. In the next step, we will create the CashBox (our configuration container).
### 1.5 CashBox creation
-Under the menu item ``Configuration -> CashBox`` you will find the button to create a new CashBox. Press this button to get to the input form. After entering a short description (name) press the "Save" button. The CashBox has been created and now appears in the list.
+Under the menu item `Configuration` / `CashBox,`click the "Add" button to create a new CashBox. This opens the input form. After entering a short description (name), click "Save". The CashBox is now created and appears in the list.
#### 1.5.1 Connecting CashBox with Queue and SCU
-Next, we want to put the configuration of the Queue and SCU into the created CashBox and connect them to each other. To do this, press the button with list symbol assigned to the CashBox.
+Next, we will add the configuration of the Queue and SCU to the created CashBox and connect them. To do this, click the button with the list icon assigned to the CashBox.
-Here you can now select the previously created Queue and SCU using the corresponding checkboxes and then save your selection. In the following we will connect the Queue with the SCU. To do this, expand the list entry of the new CashBox in the overview of the CashBoxes. The detail area shows the contained configurations. Two buttons are assigned to the Queue configuration on the right. Press the first button (box and arrow symbol) to assign the new SCU to the Queue.
+Select the previously created Queue and SCU using the corresponding checkboxes, then click "Save". After saving, we will connect the Queue with the SCU. To do this, expand the list entry of the new CashBox in the overview of the CashBoxes. The detail area shows the contained configurations. Two buttons are assigned to the Queue configuration on the right side. Click the first button (box-and-arrow icon) to assign the new SCU to the Queue.
-A popup appears in which you can select the SCU. After assigning and saving we are done with the configuration of our CashBox.
+A popup appears where you can select the SCU. After assigning and saving, the CashBox configuration is complete.
## 2. Middleware Launcher
-The ft.Middleware Launcher starts the required services on the local machine, and exposes the endpoint configured for the Queue to the communication with your POS-System.
+The ft.Middleware Launcher starts the required services on the local machine and exposes the endpoint configured for the Queue for the communication with your POS system.
### 2.1 Downloading the launcher
-Before downloading the launcher **it is important that you "rebuild" the CashBox**. To do this, press the "Rebuild configuration" button (first grey button with reload symbol) in the CashBox line. **This action must be performed every time you change the configuration of the CashBox or one of its components**.
+Before downloading the launcher, **it is important to "rebuild" the CashBox**. To do this, click the "Rebuild configuration" button (first grey button with the reload icon) in the CashBox line. **This action must be repeated whenever the CashBox configuration or any of its components is changed.**.
-After rebuild you can now download the launcher. The download of the launcher is initiated by clicking the button "Download .NET Launcher" (globe symbol).
+After rebuild, you can now download the launcher by clicking the "Download" button.
@@ -109,48 +117,53 @@ After rebuild you can now download the launcher. The download of the launcher is
:::info Note
-The debug mode is not available for launcher version 1.2. When using AT queues, a [debug launcher](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/france/installation#fiskaltrustmiddleware) is available. However, it only provides additional logging for AT-specific scenarios.
+The debug mode is not available in launcher version 1.2. For AT queues, a [debug launcher](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/france/installation#fiskaltrustmiddleware) is available, but it only provides additional logging for AT-specific scenarios.
:::
-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.
+After the download is complete, you will receive a ZIP file containing the launcher, its corresponding configuration, and other required files. Extract the ZIP file and open the extracted folder. Locate the `test.cmd` fileand open it in a text editor of your choice. Add the argument `-verbosity=Debug` at the end of the second line (which starts with `fiskaltrust.exe`). This enables more detailed logging output.Save and close the `test.cmd` file.
### 2.3 Starting the launcher
-The launcher must be started in the Administrator mode. You can start the launcher by right-clicking on the ``test.cmd`` file, and selecting "Run as Administrator". A terminal will appear where you can follow the start of the local middleware via log messages. This window remains open and visualizes log messages for further progress. Do not click into the inner area of the window, because this will pause the service (Windows feature). If this happens to you by mistake, click again and press "Enter" to cancel the interruption.
+The launcher must be started in Administrator mode. To do this, right-click the `test.cmd` file and select "Run as Administrator". A terminal window will open where you can follow the start of the local middleware via log messages. This window remains open, as it displays log messages for further progress. Do not click inside the terminal window, as this may pause the service (Windows feature). If this happens accidentally, click the window again and press "Enter" to cancel the interruption.
**Known issues / recommendations:**
-- To prevent folder access issues during the start of the Launcher, it's best to extract the files to a "neutral" location, e.g. ``C:\Launcher\``. Starting the Launcher from one of the current user's folders may result in ``Access denied`` error.
-- To prevent system permission issues when starting the Launcher, it's best to start the command prompt as Administrator, navigate to the folder containing Launcher's files, and start it from there.
-- In case of a failed launch due to the port being used by another process, you may be required to change the port of the Queue's endpoint. In such case you'll have to rebuild the CashBox, download the Launcher again, and then retry the start it. If that fails a system restart may help.
+- To avoid folder access issues during startup, extract the files to a "neutral" directory, e.g. `C:\Launcher\`. Running it from user-specific folders may result in **Access denied** errors.
+- To avoid system permission issues when starting the Launcher, start a command prompt as Administrator, navigate to the folder containing Launcher's files, and start it from there.
+- If the launcher fails because the port is already in use, you may need to change the Queue endpoint port. In that case, rebuild the CashBox, download the launcher again, and retry. If the issue persists, a system restart may help.
## 3. Middleware Communication
### 3.1 Initialization with an initial operation receipt
-After starting the launcher, the local middleware is available. Next, we will initialize the launcher using an initial operation receipt. To help you understand this (and other) operations, we have prepared a Postman collection with several examples of simple requests and complex business cases. You can start our Postman collection directly from our fiskaltrust [middleware-demo-postman](https://github.com/fiskaltrust/middleware-demo-postman) github repo.
+After starting the launcher, the local middleware is available. The next step is to initialize it using an initial operation receipt. To help you understand this and other operations, we provide a Postman collection with several examples of simple requests and complex business cases. You can access and use the collection directly from the fiskaltrust [middleware-demo-postman](https://github.com/fiskaltrust/middleware-demo-postman) GitHub repository.
#### 3.1.1 Configuration of the Postman collection
-Once the Postman collection loads, it must still be configured to send requests to the previously started local middleware. To do this, select the "fiskaltrust Middleware" collection, go to "Edit", and select the "Variables" tab. Here we find the two variables that are important for us: ``base_url`` and ``cashbox_id``. We need to modify those values as follows:
-
-- **base_url** - here we specify the URL of the previously created http(REST) endpoint of the Queue. The required value can be found in the fiskaltrust.Portal under the menu item ``Configuration -> Queue`` . Expand the detail area of the list entry of our Queue and copy the URL from there. For example ``rest://localhost:1500/f84bf516-a17b-4432-afa6-8c1050e2854d`` . Now replace ``rest://`` with ``http://`` in the URL to get the value for the Postman ``base_url`` variable. Example ``http://localhost:1500/f84bf516-a17b-4432-afa6-8c1050e2854d``. Now enter this value in Postman for the variable ``base_url`` as ``CURRENT_VALUE``.
+After the Postman collection loads, it must still be configured to send requests to the previously started local Middleware. To do this, select the "fiskaltrust Middleware" collection, click "Edit", and select the "Variables" tab. Here you will find two relevant variables: `base_url` and `cashbox_id`. Configure them as follows:
-- **cashbox_id** - here we must specify the ID of our configuration container (not to be confused with the CashBoxIdentification). We can find the value for the ``cashbox_id`` in the fiskaltrust.Portal under the menu item ``Configuration -> CashBox``. To do so, expand the detail area of the list entry of our CashBox and copy the value of **CashBoxId**. For example ``90682627-f707-45ab-84df-f855118bba97``. Now enter this as the value of the variable ``cashbox_id`` under ``CURRENT_VALUE`` in the Postman collection.
+- **base_url** - Specifies the URL of the previously created http(REST) endpoint of the Queue. You can find the required value in the fiskaltrust.Portal under the menu item `Configuration` / `Queue`. Expand the detail area of the list entry of the Queue and copy the URL. For example, `rest://localhost:1500/f84bf516-a17b-4432-afa6-8c1050e2854d`. Replace `rest://` with `http://` in the URL to obtain the value for the Postman `base_url` variable. For example, `http://localhost:1500/f84bf516-a17b-4432-afa6-8c1050e2854d`. Now enter this value in Postman for the variable `base_url` as `CURRENT_VALUE`.
+- **cashbox_id** - Specifies the ID of the configuration container (not to be confused with the CashBoxIdentification). You can find this value for the `cashbox_id` in the fiskaltrust.Portal under the menu item `Configuration` / `CashBox`. Expand the detail area of the list entry of the CashBox and copy the value of **CashBoxId**. For example, `90682627-f707-45ab-84df-f855118bba97`. Now enter this value in Postman for the variable `cashbox_id` under `CURRENT_VALUE`.
-Press ``Update`` to save your changes.
+Once both variables are configured, click `Update` to save your changes.
#### 3.1.2 Send a request with the initial operation receipt
-In our Postman collection you will find an entry with the name ``Initial Operation Receipt``. Click on it and select the ``Body`` tab to view its contents. You can now send the request by pressing the ``Send`` button. The request will be sent to the local middleware and you will get the response of the middleware back, which is displayed in Postman. In the terminal you can view the corresponding log messages. The ft.SecurityMechanism of the middleware and the TSE are now initialized and wait for further requests.
+In our Postman collection, locate an entry with the name `Initial Operation Receipt`. Click on it and select the `Body` tab to view its contents. You can now send the request by clicking `Send`. The request will be sent to the local Middleware, and the response will be displayed in Postman. You can view the corresponding log messages in the terminal. The ft.SecurityMechanism of the Middleware and the TSE are now initialized and ready to process further requests.
### 3.2 Sending further requests
-### 3.2.1 Interface doc
+### 3.2.1 Compliance Middleware documentation
-The interface to the middleware is described in our [interface-doc](https://github.com/fiskaltrust/interface-doc/) Github repository. The fiskaltrust interface-doc repo contains important information and descriptions about the communication with the middleware. The [doc](https://github.com/fiskaltrust/interface-doc/tree/master/doc) folder contains a general part (directory ``general``) and country specific parts that specify the general part in more detail depending on the country. It is important that you read this interface description in order to be able to make further steps.
+The Compliance Middleware is described in our [Documentation](https://github.com/fiskaltrust/docs/tree/main/poscreators/middleware-doc) GitHub repository. This repository contains important information about communication with the Middleware.
+
+The [middleware-doc](https://github.com/fiskaltrust/docs/tree/main/poscreators/middleware-doc) folder includes a general section (directory `general`) and country-specific sections that extend the general specification with localized requirements.
+
+It is important to review this documentation before continuing with further steps.
### 3.2.2 Postman collection
-In the Postman collection mentioned above there are many more examples of requests that you can analyze and execute. After you have familiarized yourself with the interface description [interface-doc](https://github.com/fiskaltrust/interface-doc/) we recommend our [webinar video](https://www.youtube.com/watch?v=mq1hHL8ezOg&t=15s) on the middleware in which we explain the examples and have collected and demonstrated further important information for you.
+The Postman collection referenced above contains additional request examples that you can explore and execute.
+
+After familiarizing yourself with the Compliance Middleware documentation, we also recommend watching our [Middleware webinar video](https://www.youtube.com/watch?v=mq1hHL8ezOg&t=15s), which explains the examples in detail and provides additional context.
diff --git a/poscreators/middleware-doc/general/cash-register-integration/cash-register-integration-failure-scenarios.md b/poscreators/middleware-doc/general/cash-register-integration/cash-register-integration-failure-scenarios.md
index 90194c4..aa68b94 100644
--- a/poscreators/middleware-doc/general/cash-register-integration/cash-register-integration-failure-scenarios.md
+++ b/poscreators/middleware-doc/general/cash-register-integration/cash-register-integration-failure-scenarios.md
@@ -4,78 +4,81 @@ title: Failure Scenarios
---
# Failure Scenarios
-This Chapter describes the different scenarios of failure when using the fiskaltrust.Middleware and how to handle them.
+This section describes failure scenarios when using the fiskaltrust.Middleware and how to handle them.
-On a high level, there are three different failure scenarios that should be considered that are described in more detail in the following sections:
-1. **Signature Creation Unit not reachable or failing:** When the SCU is either not reachable or returns an error (e.g. because of an outage of the wrapped signing device or service), the Middleware switches to the _failed mode_, i.e. a circuit breaker mode that doesn't execute further calls towards the SCU, which _must_ be reset by sending a _zero receipt_.
-2. **Middleware not reachable or failing**: When the cash register doesn't receive any response from the Middleware (e.g. because of a network or server outage), receipts _must_ be re-sent as soon as the Middleware is reachable again, using the flag `0x0000000000010000` to switch to the _late-signing mode_. If required in the respective country, the Middleware will automatically take care of late-signing the receipts then. When the receipts have been successfully re-sent, failure-mode _must_ be left by sending a _zero receipt_.
-3. **Cash register outage**: When the whole cash register/POS system is not working anymore (e.g. because of a power outage or a system failure) and the local fiscalization laws require the tracking of handwritten receipts (like e.g. in Germany) in that case, receipts _may_ be re-sent to the Middleware after the systems are back online with the _handwritten ftReceiptCaseFlag_ `0x0000000000080000`.
+On a high level, three types of failure scenarios must be considered. These are described in detail in the following sections:
+
+1. **Signature Creation Unit not reachable or failing:** If the SCU is not reachable or returns an error (e.g. due to an outage of the wrapped signing device or service), the Middleware enters failed mode (circuit-breaker state). In this state, no further SCU calls are executed. Failed mode must be reset by sending a zero receipt.
+2. **Middleware not reachable or failing:** If the cash register does not receive a response from the Middleware (e.g. due to a network or server outage), receipts must be re-sent once the Middleware becomes reachable again. The flag `0x0000000000010000` must be used to activate late-signing mode. If required by local regulations, the Middleware will automatically perform late signing of receipts. After all receipts have been successfully re-sent, failure mode must be exited by sending a zero receipt.
+3. **Cash register outage:** If the entire cash register/POS system is unavailable (e.g. due to a power outage or system failure) and local fiscalization laws require tracking of handwritten receipts (e.g. in Germany), receipts may be re-sent to the Middleware after the system is restored. In this case, the handwritten `ftReceiptCaseFlag` `0x0000000000080000` must be used.
## Signature Creation Unit not reachable or failing
-If the communication between the Middleware and 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, and the Middleware will handle all legally required steps (e.g. re-signing receipts, if required in the respective market). Receipts created in a state where no communication is possible with the SCU are still secured by the security mechanism of fiskaltrust. The fiskaltrust.Middleware will respond with the ftState = `0xXXXX000000000002` "SCU communication failed" (with `XXXX` being the local market code, see the reference tables in the appendices for more details). 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.
-
-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 recurring during a temporary failure. With this approach the PosOperators are not blocked in their daily business, as the middleware is avoiding long timeouts which would occur for every request to the SCU.
-
-
+If the communication between the Middleware and 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, and the Middleware will handle all legally required steps (e.g. re-signing receipts, if required in the respective market). Receipts created in a state where no communication is possible with the SCU are still secured by the security mechanism of fiskaltrust. The fiskaltrust.Middleware will respond with the `ftState` = `0xXXXX000000000002` ("SCU communication failed"), where `XXXX` represents the local market code (see the reference tables in the appendices for more details). The POS system receives this response and processes the contained data. For subsequent Requests, no more communication attempts are done in order to avoid long waiting times for each Receipt request/Receipt response sequence.
+
+The Middleware uses a circuit breaker pattern for this failure mode. After a communication failure is detected, further SCU calls are suppressed until recovery. This prevents repeated failures during temporary outages and ensures that POS operations can continue without blocking due to SCU timeouts.
+
+
-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.
+When the SCU becomes reachable again, a Zero-Receipt must be sent. This triggers 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
-We recommend to make the ZeroReceipt after a failure a manual operation, and not automatically send 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.
+We recommend to make the Zero-Receipt after a failure a manual operation, and not automatically send 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 a Zero-Receipt may result in unnecessary delays if the connection is still unavailable at that point in time.
:::
:::tip
-We recommend to not manually print the text _SCU communication failed_, but to print the content of the SignatureItem returned in the Middleware's response when operating in failed mode (as the text in there will fulfill local requirements, e.g. for the language of the text).
+We recommend to not manually print the text "SCU communication failed", but to print the content of the SignatureItem returned in the Middleware's response when operating in failed mode (as the text in there will fulfill local requirements, e.g. for the language of the text).
:::
-
+
## 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.
+If a cash register cannot communicate with the fiskaltrust.Middleware, the cause is typically a failure of the network connection, the Middleware host, or the Middleware itself. In this state, the electronic recording system is not operational, and access to the journal is not available.
-
+
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 ftState "Late Signing Mode".
+ - The receipt must be marked with the identification "electronic recording system failed" and include the current failure counter.
+ - This copy needs to be kept until the failure is resolved. The creation and storage of the receipt copy can also be done electronically by the cash register or terminal.
+ - After communication with the fiskaltrust.Middleware is restored, 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" to indicate the failure state to fiskaltrust.Middleware, which will then issue a receipt response with the `ftState` "Late Signing Mode".
-
+
-After fiskaltrust.Middleware has received an "end of failure receipt" (i.e. a zero receipt), the status of failure is terminated by receiving a response with normal state code.
+After the fiskaltrust.Middleware has received an "end of failure receipt" (i.e. a Zero-Receipt), the failure status is terminated by receiving a response with normal state code.
-
+
:::tip
-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)
+We recommend resending the first failed receipt using the "receipt request" flag `0x0000000080000000`, 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)
:::
## Cash register outage
-In case of a complete outage of the cash register, most fiscalization laws require to track the data on handwritten receipts or specific notebooks. For POS Systems that support tracking these receipts after the cash register comes back online, we recommend sending them to the Middleware as well to ensure a consistent receipt trace (e.g. in exports).
+In case of a complete outage of the cash register, most fiscalization laws require to track the data on handwritten receipts or specific notebooks. For POS systems that support tracking these receipts after the cash register comes back online, we recommend sending them to the Middleware as well to ensure a consistent receipt trace (e.g. in exports).
In this case, the following steps _may_ be taken:
-- While the cash register is offline (e.g. due to a power outage, system failure, etc.) handwritten receipts should be created, and the receipts should be tracked (e.g. in a notebook) - depending on the local requirements.
-- When the cash register is operational again, the receipts may be tracked in the cash-register.
-- When this happens, the receipts should be sent to the Middleware as well, including the _ftReceiptCaseFlag_ `0x0000000000080000` to mark that this is a handwritten receipt.
+
+- While the cash register is offline (e.g. due to a power outage, system failure, etc.) handwritten receipts should be created, and the receipts should be tracked (e.g. in a notebook), depending on the local requirements.
+- Once the cash register is operational again, the receipts may be tracked in the cash register.
+- When this happens, the receipts should be sent to the Middleware as well, including the `ftReceiptCaseFlag` `0x0000000000080000` to mark that this is a handwritten receipt.
:::warning
-In case of re-signing failed receipts, these must be signed in the same order they were originally created in. Particularly this means that values sent under the **cbReceiptMoment** field in the individual sign requests must be sequential (ascending order).
+When re-signing failed receipts, they must be signed in the same order in which they were originally created. Particularly this means that values sent under the `cbReceiptMoment` field in the individual sign requests must be sequential (ascending order).
+
+Incorrect re-signing example:
-Wrong re-signing example:
1. Receipt Nr.1: cbReceiptMoment: "2026-01-01T12:00:05Z"
2. Receipt Nr.2: cbReceiptMoment: "2026-01-01T12:00:00Z"
-:::
\ No newline at end of file
+:::
diff --git a/poscreators/middleware-doc/general/cash-register-integration/cash-register-integration-regular-workflow.md b/poscreators/middleware-doc/general/cash-register-integration/cash-register-integration-regular-workflow.md
index 785efeb..34243e4 100644
--- a/poscreators/middleware-doc/general/cash-register-integration/cash-register-integration-regular-workflow.md
+++ b/poscreators/middleware-doc/general/cash-register-integration/cash-register-integration-regular-workflow.md
@@ -5,28 +5,30 @@ title: Cash Register Integration
# Cash Register Integration
-While designing the integration of fiskaltrust.Middleware into Cash Register Systems, our goal was to minimize the impact to the existing workflow as much as possible. With that in mind we've developed the following implementation suggestion.
+While designing the integration of fiskaltrust.Middleware into cash register systems, our goal was to minimize the impact on existing workflows as much as possible. With that in mind, we developed the following implementation suggestion.
-The best time for the integration is right after all services and payments have been gathered and the receipt has been created in the system, but before it is being printed (response created electronically). Right at that point the receipt data will be transferred to the fiskaltrust.SecurityMechanism via fiskaltrust.iPOS.
+The best time for the integration is right after all services and payments have been gathered and the receipt has been created in the system, but before it is printed (response created electronically). At this stage, the receipt data is transferred to fiskaltrust for fiscalization and compliance processing, either directly through the fiskaltrust Middleware (classic integration) or through the POS System API (V2 tagging workflow).
## Receipt creation process
-This chapter describes the general process and workflow of creating receipts with fiskaltrust.Middleware.
+This section describes the general process and workflow of creating receipts using fiskaltrust.Middleware and POS System API V2.
### The fiskaltrust.SecurityMechanism
The regular workflow of the fiskaltrust.SecurityMechanism defines the steps required to create a receipt as follows:
- - assign a sequential receipt number
- - increase sales counters
- - chain receipts
- - save all data
+- assign a sequential receipt number
+- increase sales counters
+- chain receipts
+- save all data
-This additional receipt data, generated by the fiskaltrust.SecurityMechanism, is sent back to the cash register and must be stored in the POS. Once storage is completed, the entire receipt - containing both the cash register and the fiskaltrust.SecurityMechanism data - can be issued either as a printed paper or as an electronic receipt.
+This additional receipt data, generated by the fiskaltrust.SecurityMechanism, is sent back to the cash register and must be stored in the POS. Depending on the integration approach, this data may be returned directly through the fiskaltrust.Middleware or through the POS System API. Once storage is completed, the entire receipt — containing both the cash register and the fiskaltrust.SecurityMechanism data — can be delivered as a printed receipt, a digital receipt, or both.
-
+The following diagram illustrates the recommended POS System API workflow used by V2 tagging implementations. The classic Middleware integration remains supported and follows the same fiscalization principles described in this section.
-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.
+
+
+In addition to the security mechanism workflow, the fiskaltrust.Middleware processes some of the most essential data fields on the receipt. Regardless of whether receipts are submitted directly through the Middleware or through the POS System API, the receipt number, serving as a unique identifier of a receipt processed by fiskaltrust, 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.
@@ -48,19 +50,21 @@ The configuration container - identified by the unique `CashboxId` - can be inte
### 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.
+The following diagram illustrates the regular creation and issuance of a receipt using the fiskaltrust ecosystem and the PosSystem API (v2). During the workflow, the POS system submits the transaction for fiscalization through the `/sign` endpoint, which is processed by fiskaltrust.Middleware and the configured fiskaltrust.SecurityMechanism. After a signed receipt has been returned, the receipt can be issued through the `/issue` endpoint, enabling both printable and digital receipt delivery scenarios.
+
+The implementation of a fiskaltrust.SecurityMechanism may differ between countries and derive from their national laws. For country-specific details, refer to the appropriate appendix.
-
+
### 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.
+The following diagram illustrates the creation of a special receipt with fiskaltrust.Middleware. For a general description of special receipts, see [Receipt for special functions](#receipt-for-special-functions). For national laws on receipts, refer to the appropriate appendix.
### 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.
+The following diagram illustrates the workflow of a failure of fiskaltrust.Middleware. For a description of recovering, refer to the appropriate appendix.
@@ -70,7 +74,7 @@ The following diagram illustrates the workflow of a failure of fiskaltrust.Middl
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.
-This section describes the receipt types used for those special functions. For further information on how to fulfil the requirements of national laws, please refer to the appropriate appendix.
+This section describes the receipt types used for those special functions. For further information on how to fulfil the requirements of national laws, refer to the appropriate appendix.
### Zero Receipt
@@ -93,16 +97,18 @@ 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)
+
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
-This chapter describes the receipt structure.
+This section describes the structure of a receipt, including the main blocks provided by the cash register and the additional data added by fiskaltrust.Middleware.
-
+
-*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)*
+
+*Figure 8. Receipt Structure – The POS receipt consists of header, charge items, pay items, and footer. fiskaltrust enriches the receipt during fiscalization by adding receipt number, tax-related data, signature, and fiscal metadata. The POSSystem API V2 further produces an issued receipt including digital receipt information.*
### Receipt Header
@@ -130,7 +136,7 @@ The receipt footer contains messages or announcements for the customer. It can b
## Data Collection Log
-The Data Collection Log is generally defined by national laws. For further, country-specific information, please refer to the appropriate appendix.
+The Data Collection Log is generally defined by national laws. For further, country-specific information, refer to the appropriate appendix.
## fiskaltrust.ReceiptJournal
diff --git a/poscreators/middleware-doc/general/cash-register-integration/images/01-security-mechanism.svg b/poscreators/middleware-doc/general/cash-register-integration/images/01-security-mechanism.svg
new file mode 100644
index 0000000..523a890
--- /dev/null
+++ b/poscreators/middleware-doc/general/cash-register-integration/images/01-security-mechanism.svg
@@ -0,0 +1,3 @@
+
+
+
\ No newline at end of file
diff --git a/poscreators/middleware-doc/general/cash-register-integration/images/02-regular-operation.svg b/poscreators/middleware-doc/general/cash-register-integration/images/02-regular-operation.svg
new file mode 100644
index 0000000..89ca085
--- /dev/null
+++ b/poscreators/middleware-doc/general/cash-register-integration/images/02-regular-operation.svg
@@ -0,0 +1,3 @@
+
+
+
\ No newline at end of file
diff --git a/poscreators/middleware-doc/general/cash-register-integration/images/06-receipt-structure.svg b/poscreators/middleware-doc/general/cash-register-integration/images/06-receipt-structure.svg
new file mode 100644
index 0000000..71d1b1a
--- /dev/null
+++ b/poscreators/middleware-doc/general/cash-register-integration/images/06-receipt-structure.svg
@@ -0,0 +1,616 @@
+
+
diff --git a/poscreators/middleware-doc/general/cash-register-integration/images/07-no-middleware-connection.png b/poscreators/middleware-doc/general/cash-register-integration/images/07-no-middleware-connection.png
deleted file mode 100644
index b2743d0..0000000
Binary files a/poscreators/middleware-doc/general/cash-register-integration/images/07-no-middleware-connection.png and /dev/null differ
diff --git a/poscreators/middleware-doc/general/cash-register-integration/images/07-no-middleware-connection.svg b/poscreators/middleware-doc/general/cash-register-integration/images/07-no-middleware-connection.svg
new file mode 100644
index 0000000..2554ab4
--- /dev/null
+++ b/poscreators/middleware-doc/general/cash-register-integration/images/07-no-middleware-connection.svg
@@ -0,0 +1,2522 @@
+
+
diff --git a/poscreators/middleware-doc/general/cash-register-integration/images/08-late-signing-mode.svg b/poscreators/middleware-doc/general/cash-register-integration/images/08-late-signing-mode.svg
new file mode 100644
index 0000000..f3dc5dc
--- /dev/null
+++ b/poscreators/middleware-doc/general/cash-register-integration/images/08-late-signing-mode.svg
@@ -0,0 +1,1874 @@
+
+
diff --git a/poscreators/middleware-doc/general/cash-register-integration/images/09-end-late-signing-mode.png b/poscreators/middleware-doc/general/cash-register-integration/images/09-end-late-signing-mode.png
deleted file mode 100644
index b6a8a21..0000000
Binary files a/poscreators/middleware-doc/general/cash-register-integration/images/09-end-late-signing-mode.png and /dev/null differ
diff --git a/poscreators/middleware-doc/general/cash-register-integration/images/09-end-late-signing-mode.svg b/poscreators/middleware-doc/general/cash-register-integration/images/09-end-late-signing-mode.svg
new file mode 100644
index 0000000..7f4f709
--- /dev/null
+++ b/poscreators/middleware-doc/general/cash-register-integration/images/09-end-late-signing-mode.svg
@@ -0,0 +1,2731 @@
+
+
diff --git a/poscreators/middleware-doc/general/cash-register-integration/images/10-no-scu-connection.png b/poscreators/middleware-doc/general/cash-register-integration/images/10-no-scu-connection.png
deleted file mode 100644
index fc8a19c..0000000
Binary files a/poscreators/middleware-doc/general/cash-register-integration/images/10-no-scu-connection.png and /dev/null differ
diff --git a/poscreators/middleware-doc/general/cash-register-integration/images/10-no-scu-connection.svg b/poscreators/middleware-doc/general/cash-register-integration/images/10-no-scu-connection.svg
new file mode 100644
index 0000000..f5b8f88
--- /dev/null
+++ b/poscreators/middleware-doc/general/cash-register-integration/images/10-no-scu-connection.svg
@@ -0,0 +1,2751 @@
+
+
diff --git a/poscreators/middleware-doc/general/cash-register-integration/images/11-reestablished-connection.png b/poscreators/middleware-doc/general/cash-register-integration/images/11-reestablished-connection.png
deleted file mode 100644
index 67c344f..0000000
Binary files a/poscreators/middleware-doc/general/cash-register-integration/images/11-reestablished-connection.png and /dev/null differ
diff --git a/poscreators/middleware-doc/general/cash-register-integration/images/11-reestablished-connection.svg b/poscreators/middleware-doc/general/cash-register-integration/images/11-reestablished-connection.svg
new file mode 100644
index 0000000..6e14586
--- /dev/null
+++ b/poscreators/middleware-doc/general/cash-register-integration/images/11-reestablished-connection.svg
@@ -0,0 +1,2786 @@
+
+
diff --git a/poscreators/middleware-doc/general/communication/communication.md b/poscreators/middleware-doc/general/communication/communication.md
index ab51961..3f6d377 100644
--- a/poscreators/middleware-doc/general/communication/communication.md
+++ b/poscreators/middleware-doc/general/communication/communication.md
@@ -11,27 +11,31 @@ The communication protocol is specified by setting the respective URL in the pac
-_Buttons for other URL options (like gRPC) may be available as well, depending on the country._
+:::note
+
+Buttons for other URL options (e.g. gRPC) may be available depending on the selected country or market.
+
+:::
:::info
-Depending on the version of the Middleware, different protocols are supported (for a summarized overview, please see the table at the end of this section). We're currently working on unifying the Middleware experience for all markets to provide the same communication protocols for all markets and operating system.
+Depending on the version of the Middleware, different protocols are supported. For a summarized overview, please see the table at the end of this section. We are continuously working on unifying the Middleware experience across all markets to provide the same communication protocols and operating system.
:::
## gRPC
-The gRPC protocol is currently only available in the Middleware for Germany, please see the [German appendix](../../middleware-de-kassensichv/communication/communication.md) for further information.
+The gRPC protocol is currently available only in the Middleware for Germany. For more information, see the [German appendix](../../middleware-de-kassensichv/communication/communication.md).
We recommend using gRPC for new implementations, as it has several advantages (including performance, reliability, asynchronous streams, and static message contracts) and is supported by most programming frameworks.
## REST web service
-When selecting REST (_Representational State Transfer_), the Middleware hosts a HTTP service that can be used like any commonly used web service. Messages can either be encoded with _JSON_ or _XML_, depending on the user's preference.
+When selecting REST (_Representational State Transfer_), the Middleware hosts a HTTP service that can be used like any commonly used web service. Messages can be encoded in either _JSON_ or _XML_, depending on the user's preference.
-The offered REST functions accept POST request, the URL is composed like this: `http://[specified-url]/[xml|json]/[v0|v1]/[echo|sign|journal]`.
+The offered REST functions accept POST request. The URL is composed as follows: `http://[specified-url]/[xml|json]/[v0|v1]/[echo|sign|journal]`.
-For sample requests of the most commonly used receipt cases and journals, please have a look at our [Postman Collection](https://github.com/fiskaltrust/middleware-demo-postman).
+For sample requests of the most commonly used receipt cases and journals, see the [Postman Collection](https://github.com/fiskaltrust/middleware-demo-postman).
XSD files which describe the REST interface of the fiskaltrust.Middleware are available at [dist/XSD](https://github.com/fiskaltrust/interface-doc/tree/master/dist/XSD).
@@ -39,23 +43,23 @@ We recommend using REST in case you're already familiar with its principles and
### Country specifics
-In Austria and France, REST can currently only be used by adding a _helper_ package provided by fiskaltrust. Please refer to the [Austrian appendix](../../middleware-at-rksv/communication/communication.md) for more details. In Germany, the Middleware natively supports REST without using a helper.
+In Austria and France, REST can currently only be used by adding a _helper_ package provided by fiskaltrust. For more information, see the [Austrian appendix](../../middleware-at-rksv/communication/communication.md). In Germany, the Middleware natively supports REST without using a helper.
## WCF Web Service
-The _Windows Communication Foundation_ (WCF) is used to access the fiskaltrust.Middleware with SOAP calls, either via a network or a pipes based communication approach. Further information on this subject can be found in the [official Microsoft docs](https://docs.microsoft.com/en-us/dotnet/framework/wcf/bindings).
+_Windows Communication Foundation_ (WCF) provides access to the fiskaltrust.Middleware with SOAP calls, either via a network or a pipes based communication approach. Further information about WCF can be found in the [official Microsoft documentation](https://docs.microsoft.com/en-us/dotnet/framework/wcf/bindings).
-WCF supports different underlying protocols: _http, https, net.tcp_ and _net.pipe_ (which is most interesting in cases where the system's configuration prevents opening TCP ports). For configuring a custom message size and a custom time out, it is possible to specify the parameter `messagesize` (in bytes) and the parameter `timeout` (in seconds) on the configuration page.
+WCF supports different underlying protocols, including _http, https, net.tcp_, and _net.pipe_ (which is most interesting in cases where the system's configuration prevents opening TCP ports). To configure a custom message size and a custom time out, it is possible to specify the parameter `messagesize` (in bytes) and the parameter `timeout` (in seconds) on the configuration page.
A WSDL file which describes the WCF interface of the fiskaltrust.Middleware is available at [dist/WSDL](https://github.com/fiskaltrust/interface-doc/tree/master/dist/WSDL).
## User specific protocols
-With the Middleware's _helper_ topology, it is possible to connect the Middleware to POS-Systems in every scenario, as it can be easily extended to support any other protocol as well. Please contact our support if you require assistance for a special case.
+With the Middleware's _helper_ topology, it is possible to connect the Middleware to POS systems in every scenario, as it can be easily extended to support any other protocol as well. Contact our support if you require assistance for a special case.
## Summary
-The following table displays which protocols are currently available in which country:
+The following table provides an overview of which communication protocols are currently available in each country.
| Communication service | AT | DE | FR | IT |
|-----------------------|----------------------------|---------------|----------------------------|---------------|
@@ -68,11 +72,10 @@ As mentioned above, the Middleware versions will be unified in the upcoming vers
## Sample implementations
-Our latest samples, which demonstrate the communication protocols we recommend for the respective languages, are available here:
+The latest sample implementations, demonstrating the recommended communication protocols for the respective programming languages, are available as follows:
-| C# | Java | Node.js | Android | Postman |
-|---------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|
-| :--: | :----: | :-------: | :-------: | :-------: |
+| C# | Java | Node.js | Android | Postman |
+|----|------|---------|---------|---------|
| [](https://github.com/fiskaltrust/middleware-demo-dotnet) | [](https://github.com/fiskaltrust/middleware-demo-java) | [](https://github.com/fiskaltrust/middleware-demo-node) | [](https://github.com/fiskaltrust/middleware-demo-android) | [](https://github.com/fiskaltrust/middleware-demo-postman) |
-Additionally, other samples (including legacy ones) can be found in our [demo repository](https://github.com/fiskaltrust/demo).
+Additional sample implementations, including legacy examples, are available in our [demo repository](https://github.com/fiskaltrust/demo).
diff --git a/poscreators/middleware-doc/general/communication/images/url-configuration.png b/poscreators/middleware-doc/general/communication/images/url-configuration.png
index c13bb6a..0aa76cc 100644
Binary files a/poscreators/middleware-doc/general/communication/images/url-configuration.png and b/poscreators/middleware-doc/general/communication/images/url-configuration.png differ
diff --git a/poscreators/middleware-doc/general/components/components-install-config.md b/poscreators/middleware-doc/general/components/components-install-config.md
index e1865e8..52cde71 100644
--- a/poscreators/middleware-doc/general/components/components-install-config.md
+++ b/poscreators/middleware-doc/general/components/components-install-config.md
@@ -5,43 +5,60 @@ title: Installing and Configuring Components
# Installing and Configuring Components
-For operating the fiskaltrust.Middleware on-premise or off-premise, the components of the fiskaltrust.Middleware need to be configured, downloaded, and installed/started:
+To operate the fiskaltrust.Middleware, whether on-premises or off-premises, you must first configure the required Middleware components in the fiskaltrust.Portal and then download and start the corresponding Launcher package.
-The components of the fiskaltrust.Middleware need to be configured in the fiskaltrust.Portal for the environment where the Middleware should be operated. The availability of components and its configuration options are dependent on the local market regulation.
+## Configuring Middleware Components
-For example, it must be configured at which endpoints the Middleware is listening on, in which database the processed data is to be stored, which Signature Creation Unit (SCU) is to be used for the signatures and how it can be reached by the Middleware.
+Before the fiskaltrust.Middleware can be installed and started, its components must be configured in the fiskaltrust.Portal for the target environment.
-The components of the Middleware which should be operated as an on-premise Middleware-instance are collected in a so-called "CashBox" configuration container.
+The available components and configuration options depend on the local fiscal regulations of the selected market.
-More information on the configuration options of the components can be found in the according market-appendices:
+Typical configuration tasks include:
+
+- Defining the endpoints on which the Middleware listens for requests.
+- Configuring the database used to store processed transaction data.
+- Selecting the Signature Creation Unit (SCU) used for signing operations.
+- Providing the connection settings required for the Middleware to communicate with the configured SCU and other services.
+
+All components that belong to an on-premises Middleware installation are grouped in a CashBox configuration container.
+
+Detailed information about market-specific configuration options can be found in the corresponding market appendices:
- Austria
- [Germany](https://docs.fiskaltrust.cloud/docs/posdealers/technical-operations/rollout-scenarios)
- France
- [Italy](https://docs.fiskaltrust.cloud/docs/posdealers/technical-operations/rollout-scenarios)
-At the end of this configuration process, a so-called "Launcher" including the CashBox-configuration needs to be downloaded.
+After completing the CashBox configuration, download the Launcher package for the configured CashBox. The Launcher contains the information required to start the fiskaltrust.Middleware with the selected configuration.
## Download of the Launcher
-After configuring the CashBox in the portal, following so-called "Launchers" are available for download:
+After configuring the CashBox in the portal, download the Launcher package before installing and starting the Middleware.
+
+In most markets, the Portal provides a single Download Launcher button. Clicking this button opens a dialog showing the launcher packages available for the selected CashBox configuration.
+
+:::info Important
+
+The launcher variants and platform availability described below currently apply only to Austria (AT), Germany (DE), and France (FR). Newer markets use the new launcher distribution model and may present different download options depending on the selected CashBox configuration.
+
+:::
-| Icon | Launcher | Description | AT | DE | FR | IT |
-| ------------------------------------------------ | --------------------------------------- | ------------------------------------------------------------ | --------- | ---------- | --------- | --------- |
-|  | .NET Launcher (*default launcher*) | **For starting the Middleware on Windows with Internet connection.** The launcher loads the configuration file and its needed packages during the start from the fiskaltrust packages-server. | supported | supported | supported | supported |
-|  | .NET Offline Launcher | **For starting the Middleware on Windows without Internet connection.** A static configuration and its needed packages for operation is included. The regular package update mechanisms are not supported with the offline launcher. | supported | supported | supported | supported |
-|  | Mono Launcher | **For starting the Middleware on Linux/macOS with Internet connection.** The launcher loads the configuration file and its needed packages during the start from the fiskaltrust packages-server. | supported | supported | supported | supported |
-|  | Android Launcher | **For starting the Middleware on Android with Internet connection.** The needed packages for operation are already included. The launcher loads the configuration file during the start from the fiskaltrust packages-server. The configuration options are limited to keep the package sizes small. | | supported* | | supported* |
+| Icon | Launcher | Description | AT | DE | FR | IT |
+| ---- | -------- | ----------- | -- | -- | -- | -- |
+|  | .NET Launcher (*default launcher*) | **For starting the Middleware on Windows with Internet connection.** The launcher loads the configuration file and required packages from the fiskaltrust package server during startup. | supported | supported | supported | supported |
+|  | .NET Offline Launcher | **For starting the Middleware on Windows without Internet connection.** A static configuration and required packages for operation is included. The regular package update mechanisms are not supported with the offline launcher. | supported | supported | supported | supported |
+|  | Mono Launcher | **For starting the Middleware on Linux/macOS with Internet connection.** The launcher loads the configuration file and required packages from the fiskaltrust package server during startup. | supported | supported | supported | supported |
+|  | Android Launcher | **For starting the Middleware on Android with Internet connection.** Required packages for operation are already included. The launcher loads the configuration file from the fiskaltrust package server during startup. The configuration options are limited to keep the package sizes small. | | supported* | | supported* |
-*availability dependent on the CashBox configuration. For more details, see the [platform documentation for Android](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/germany/platforms/android).
+*Availability depends on the selected CashBox configuration. For more information, see the [Android platform documentation](../../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.
+The downloaded launcher package is provided as a ZIP archive. Extract the archive before use. The extracted folder can be moved or renamed if required.
-The folder with the downloaded and unzipped launcher contains
+The folder with the downloaded and unzipped launcher contains:
-- the launcher `fiskaltrust.exe`,
-- three pre-configured `.cmd` command files,
-- a file for the static configuration of the service named `fiskaltrust.exe.config`, and
+- the launcher executable (`fiskaltrust.exe`),
+- three preconfigured `.cmd` command files,
+- a file for the static configuration of the service named `fiskaltrust.exe.config`,
- the fiskaltrust.Middleware service represented by the `.dll` files.
## Windows, Linux & MacOS
@@ -54,39 +71,40 @@ The downloaded Launcher can now be optionally adapted for the local machine; e.g
The following call parameters are available with the launcher `fiskaltrust.exe`:
-| **Parameter** | **Description** | Overwrites the values in the static configuration `fiskaltrust.exe.config` |
-| ------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
-| `-cashboxid` | Sets the CashBoxId. The value is a GUID in format `00000000-0000-0000-0000-000000000000`. | yes |
-| `-accesstoken` | Sets the AccessToken for online communication | yes |
-| `-useoffline` | Sets the offline mode. The value is a boolean: true \| false | yes |
-| `-test` | Executing as command line program. Basic information is provided in the console. Should be indicated as last parameter, if it is set in connection with others. | no |
-| `-i` | Install Windows service | no |
-| `-u` | Uninstall Windows service | no |
-| `-servicename=[myservicename]` | Sets the service name in connection with -i and -u | no |
-| `-displayname=[mydisplayname]` | Sets the service display name within the system control in connection with -i | no |
-| `-description=[mydescription]` | Sets the service description within the system control in connection with -i | no |
-| `-servicefolder` | Sets folder containing the service files. | yes |
-| `-sslvalidation` | Sets the certificate validation when connecting through SSL. The value is a boolean: true \| false | yes |
-| `-sandbox` | Sets the environment to be used. The value is a boolean: true (sandbox) \| false (production) | yes |
-| `-packagesurl` | Sets the url of the package server used to download the packages. | yes |
-| `-logfile` | Sets the file used to log the output messages. | yes |
-| `-connectiontimeout` | Sets the timeout (in seconds) for the HTTP/HTTPS call to download the configuration. | yes |
-| `-connectionretry` | Sets the number of trials to download the configuration. | yes |
-| `-proxy` | Sets the proxy server to be used to connect to the internet. The value can be used as follows: `"address=xxx.xxx.xxx.xxx;username=test;password=pwd123"`. `username` and `password` are optional values. See [Using a Proxy](https://link.fiskaltrust.cloud/rollout/proxy) | yes |
-| `-verbosity` | Sets the level of debug-information in the logfile. The value is a string. Possible values are: `Trace` \|`Debug` \|`Information` \|`Warning` \|`Error` \|`Critical` **Supported in the German market only!** | yes. Use in the static configuration the key `loglevel` |
-*Table 8. fiskaltrust.exe launch parameters*
+| **Parameter** | **Description** | Overwrites the values in the static configuration `fiskaltrust.exe.config` | | | | | |
+| ------------- | --------------- | --- | --- | --- | --- | --- | --- |
+| `-cashboxid` | Sets the CashBoxId. The value is a GUID in format `00000000-0000-0000-0000-000000000000`. | yes | | | | | |
+| `-accesstoken` | Sets the AccessToken for online communication | yes | | | | | |
+| `-useoffline` | Sets the offline mode. The value is a boolean: true \ | false | yes | | | | |
+| `-test` | Executing as command line program. Basic information is provided in the console. Should be indicated as last parameter, if it is set in connection with others. | no | | | | | |
+| `-i` | Install Windows service | no | | | | | |
+| `-u` | Uninstall Windows service | no | | | | | |
+| `-servicename=[myservicename]` | Sets the service name in connection with -i and -u | no | | | | | |
+| `-displayname=[mydisplayname]` | Sets the service display name within the system control in connection with -i | no | | | | | |
+| `-description=[mydescription]` | Sets the service description within the system control in connection with -i | no | | | | | |
+| `-servicefolder` | Sets folder containing the service files. | yes | | | | | |
+| `-sslvalidation` | Sets the certificate validation when connecting through SSL. The value is a boolean: true \ | false | yes | | | | |
+| `-sandbox` | Sets the environment to be used. The value is a boolean: true (sandbox) \ | false (production) | yes | | | | |
+| `-packagesurl` | Sets the url of the package server used to download the packages. | yes | | | | | |
+| `-logfile` | Sets the file used to log the output messages. | yes | | | | | |
+| `-connectiontimeout` | Sets the timeout (in seconds) for the HTTP/HTTPS call to download the configuration. | yes | | | | | |
+| `-connectionretry` | Sets the number of trials to download the configuration. | yes | | | | | |
+| `-proxy` | Sets the proxy server to be used to connect to the internet. The value can be used as follows: `"address=xxx.xxx.xxx.xxx;username=test;password=pwd123"`. `username` and `password` are optional values. See [Using a Proxy](https://link.fiskaltrust.cloud/rollout/proxy) | yes | | | | | |
+| `-verbosity` | Sets the level of debug-information in the logfile. The value is a string. Possible values are: `Trace` \ | `Debug` \ | `Information` \ | `Warning` \ | `Error` \ | `Critical` **Supported in the German market only!** | yes. Use in the static configuration the key `loglevel` |
+
+*Table 2. fiskaltrust.exe launch parameters*
### Starting the Launcher
Following options are available for executing the `fiskaltrust.exe`:
-| Option | Description | Windows | Linux |
-| ----------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
-| `fiskaltrust.exe` | Executing the launcher `fiskaltrust.exe` as a command line program using call parameters. | Run the command line `cmd.exe` as administrator.
Example: `fiskaltrust.exe -test` | Example: ```sudo mono fiskaltrust.exe -test``` |
-| `[pre-configured command file].cmd` | Command files can be used for executing the `fiskaltrust.exe` with pre-defined setups, e.g. for developing and debugging. Three pre-configured setups are already included with the downloaded launcher (see below). | | |
-| `install-service.cmd` | Pre-configured command file which executes `fiskaltrust.exe` using the parameter `-i` for installing the fiskaltrust.Middleware as a service under Windows, recommended for permanent on-premise operation. | Run the command file `install-service.cmd` as administrator. For details, see [Windows Service Installation](#windows-service-installation) | For installing the fiskaltrust.Middleware as a Daemon, see [Mono service installation](#mono-service-installation). |
-| `uninstall-service.cmd` | Pre-configured command file which executes `fiskaltrust.exe` using the parameter `-u` for un-installing the fiskaltrust.Middleware as a service under Windows. | Run the command file `uninstall-service.cmd` as administrator. | |
-| `test.cmd` | Pre-configured command file which executes `fiskaltrust.exe` using the parameter `-test` for starting the fiskaltrust.Middleware as a command line program under Windows, recommended for test and development purpose. | Run the command file `test.cmd` as administrator. For details, see [Test Environment](#test-environment) | |
+| Option | Description | Windows | Linux |
+| ------ | ----------- | ------- | ----- |
+| `fiskaltrust.exe` | Executing the launcher `fiskaltrust.exe` as a command line program using call parameters. | Run the command line `cmd.exe` as administrator.
Example: `fiskaltrust.exe -test` | Example: ```sudo mono fiskaltrust.exe -test``` |
+| `[pre-configured command file].cmd` | Command files can be used for executing the `fiskaltrust.exe` with pre-defined setups, e.g. for developing and debugging. Three pre-configured setups are already included with the downloaded launcher (see below). | | |
+| `install-service.cmd` | Pre-configured command file which executes `fiskaltrust.exe` using the parameter `-i` for installing the fiskaltrust.Middleware as a service under Windows, recommended for permanent on-premise operation. | Run the command file `install-service.cmd` as administrator. For details, see [Windows Service Installation](#windows-service-installation) | For installing the fiskaltrust.Middleware as a Daemon, see [Mono service installation](#mono-service-installation). |
+| `uninstall-service.cmd` | Pre-configured command file which executes `fiskaltrust.exe` using the parameter `-u` for un-installing the fiskaltrust.Middleware as a service under Windows. | Run the command file `uninstall-service.cmd` as administrator. | |
+| `test.cmd` | Pre-configured command file which executes `fiskaltrust.exe` using the parameter `-test` for starting the fiskaltrust.Middleware as a command line program under Windows, recommended for test and development purpose. | Run the command file `test.cmd` as administrator. For details, see [Test Environment](#test-environment) | |
### Applying the CashBox-configuration
@@ -98,10 +116,10 @@ For checking the configuration and downloading the needed packages the Launcher
**Outbound traffic**
-| Type | Protocol | Port | Source |
-| ----- | -------- | ---- | ---------------------------------- |
-| https | TCP | 443 | packages-sandbox.fiskaltrust.cloud |
-| https | TCP | 443 | packages.fiskaltrust.cloud |
+| Type | Protocol | Port | Source |
+| ---- | -------- | ---- | ------ |
+| https | TCP | 443 | packages-sandbox.fiskaltrust.cloud |
+| https | TCP | 443 | packages.fiskaltrust.cloud |
### Service folder
@@ -225,8 +243,8 @@ Once completed, the service should appear in the running daemon list.
## Android
-The fiskaltrust.Middleware for Android is currently available for the German market only. For details about the platform specific installation, please refer to the [platform documentation for Android](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/germany/platforms/android).
+The fiskaltrust.Middleware for Android is currently available for the German market only. For more information about the platform specific installation, see the see the [Android platform documentation](../../middleware-de-kassensichv/operation-modes/on-premise-platforms/android.md).
## Migration of the fiskaltrust.Middleware instance to a different hardware
-We do not recommend to migrate an active instance of the fiskaltrust.Middleware to another hardware. If possible, please set the queue [out of operation](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/germany/reference-tables/ftreceiptcase) and configure and install a new Middleware instance on the new machine.
+We do not recommend to migrate an active instance of the fiskaltrust.Middleware to another hardware. If possible, set the queue [out of operation](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/germany/reference-tables/ftreceiptcase), configure, and install a new Middleware instance on the new machine.