Fix typos/misspellings

faq/roles.md

@@ -30,6 +30,6 @@ Our primary focus for this group is to simplify rollout processes by providing s
 ## PosOperator
 _PosOperators are the "end users" of Possystems, i.e. the businesses and persons who actually operate the Possystem in locations like shops. restaurants or hotels._
 
-Usually, PosOperator have not direct relationship with fiskaltrust, as their direct contact for sales and support topic is the PosDealer, and the fiskaltrust.Middleware is just running in the background, integrated into the Possoftware. Only at the request of tax authorities or auditors, with the help of PosDealer, provide the data that meets the requirements of the tax regulations.
+Usually, PosOperators have no direct relationship with fiskaltrust, as their direct contact for sales and support topic is the PosDealer, and the fiskaltrust.Middleware is just running in the background, integrated into the Possoftware. Only at the request of tax authorities or auditors, with the help of PosDealer, provide the data that meets the requirements of the tax regulations.
 
 As a service provider, fiskaltrust is therefore not offering direct support for PosOperators. If you belong to this group, please reach out to your PosDealer.

poscreators/getting-started/middleware-integration.md

@@ -135,7 +135,7 @@ After starting the launcher, the local middleware is available. Next, we will in
 
 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 Postmman for the variable ``base_url`` as ``CURRENT_VALUE``.
+- **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``.
 
 - **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.
 

poscreators/getting-started/onboarding-posdealers.md

@@ -9,14 +9,14 @@ Once you were able to test the integration and successfully establish a communic
 
 :::info Important
 
-Involve your PosDealers as early as possible, because they have to perform the following steps, among others, before they can roullout the fiskaltrust.Middleware to the PosOperators. For more details, open the drop-down window below.
+Involve your PosDealers as early as possible, because they have to perform the following steps, among others, before they can rollout the fiskaltrust.Middleware to the PosOperators. For more details, open the drop-down window below.
 
 :::
 
 <details>
   <summary>Registration steps for PosDealers</summary>
 
-1. Register in the fiskalttrust.Portal and there digitally sign a cooperation agreement with fiskaltrust.
+1. Register in the fiskaltrust.Portal and there digitally sign a cooperation agreement with fiskaltrust.
 2. Depending on the circumstances, request and sign framework agreements for the purchase of products with fiskaltrust.
 3. Invite the PosOperators to the fiskaltrust.Portal so that they can sign the usage agreement for the fiskaltrust.Middleware.
 4. Request access rights to the PosOperator`s fiskaltrust.Account so that the PosDealer can redeem and activate the product entitlements purchased from fiskaltrust
@@ -128,7 +128,7 @@ If the PosCreator accepts the assignment, the connection between the PosDealer`s
 
 As the approach to the rollout highly depends on the implementation, the components, and the capabilities of your POS-System, you should select the appropriate rollout scenario and discuss it with your POS Dealers, to ensure their sufficient levels of knowledge and understanding required for the successful execution of the rollout process.
 
-The rollout has 2 separate areas, the [buy- and resell part](https://docs.fiskaltrust.cloud/docs/posdealers/buy-resell/overview), and [the technical rollout](https://docs.fiskaltrust.cloud/docs/posdealers/buy-resell/rollout-plans), which are both covered in the the PosDealer area of this documentation.
+The rollout has 2 separate areas, the [buy- and resell part](https://docs.fiskaltrust.cloud/docs/posdealers/buy-resell/overview), and [the technical rollout](https://docs.fiskaltrust.cloud/docs/posdealers/buy-resell/rollout-plans), which are both covered in the PosDealer area of this documentation.
 
 The technical stage requires a close collaboration of the technical experts from both sides: yours and the POS Dealer`s. You will discuss the details of the implementation, agree on the approach for rollout automation and templating, and select the best strategy for the rollout based on the appropriate rollout scenario. We have documented examples of different [rollout scenarios](https://docs.fiskaltrust.cloud/docs/posdealers/technical-operations/rollout-scenarios) in our documentation portal.
 

poscreators/middleware-doc/digital-receipt/compliance.md

@@ -10,9 +10,9 @@ With our digital receipt solutions, we set the course to a successful and compli
 ## Austria requirements 
 
 In Austria there are multiple requirements around the receipts issued at the Point of Sale. 
-An digital receipt within the meaning of section "132a (1) BAO" is a receipt that is issued and received in an digital format or is immediately handed to the person making the cash payment. It can be issued, for example by web in an digital format (e.g. as a PDF or text file), but also in a structured file format (e.g. HTML). The receipt must be created and signed by the Point of Sale directly in connection with the cash payment, and then actually reach the disposal area of the receipt recipient. Technical delays such as e.g. uploading to a server are irrelevant because fiskaltrust stores the receipts immediately in the DEP and promptly in an audit-proof memory and for a verification by a financial management body is available. It is up to the issuer of the digital receipt whether this is to be done digitally (by using a smartphone, etc.) or in paper form. The transmission is an obligation of the merchant, a mere granting of the possibility of viewing and photographing the content of the receipt displayed on a screen does not fulfill the obligation to issue receipts. 
+A digital receipt within the meaning of section "132a (1) BAO" is a receipt that is issued and received in a digital format or is immediately handed to the person making the cash payment. It can be issued, for example by web in a digital format (e.g. as a PDF or text file), but also in a structured file format (e.g. HTML). The receipt must be created and signed by the Point of Sale directly in connection with the cash payment, and then actually reach the disposal area of the receipt recipient. Technical delays such as e.g. uploading to a server are irrelevant because fiskaltrust stores the receipts immediately in the DEP and promptly in an audit-proof memory and for a verification by a financial management body is available. It is up to the issuer of the digital receipt whether this is to be done digitally (by using a smartphone, etc.) or in paper form. The transmission is an obligation of the merchant, a mere granting of the possibility of viewing and photographing the content of the receipt displayed on a screen does not fulfill the obligation to issue receipts. 
 
-Receipt content needs to include quantity, item names, prices and VAT rates. In addition to human readable text, there is also a QR-Code required with fiscalization specific information including a signature created from a secure signature creation device. Fiscalization rules also require to have an identification of the pos-system (Kassenidentifikationsnummer) and receipt number and moment of receipt creation also in human readable text present on every issued receipt. The digital receipt from fiskaltrust covers all those requirements, when the Middleware and digital receipt integration into you Point of Sales software was done according to our documentation.
+Receipt content needs to include quantity, item names, prices and VAT rates. In addition to human readable text, there is also a QR-Code required with fiscalization specific information including a signature created from a secure signature creation device. Fiscalization rules also require to have an identification of the pos-system (Kassenidentifikationsnummer) and receipt number and moment of receipt creation also in human readable text present on every issued receipt. The digital receipt from fiskaltrust covers all those requirements, when the Middleware and digital receipt integration into your Point of Sales software was done according to our documentation.
 
 **Please note:** 
 For card payments there are additional requirements related to the acquirer and scheme of the card.
@@ -23,15 +23,15 @@ For consumers, there is an obligation to take the receipt with them (Belegmitnah
 
 ### Fulfilment
 
-Each receipt is related to a "Queue" identified via "QueueID", which identifies the specific POS system within an PosOperator/merchant. Also, this "Queue" is assigned to a single outlet within the PosOperator/merchant, which provides configuration elements like location and logo for the digital receipt header and other metadata for receipt generation.
+Each receipt is related to a "Queue" identified via "QueueID", which identifies the specific POS system within a PosOperator/merchant. Also, this "Queue" is assigned to a single outlet within the PosOperator/merchant, which provides configuration elements like location and logo for the digital receipt header and other metadata for receipt generation.
 
-Each receipt is identified via "QueueItemID", which is generated by the middleware driving the security mechanism within the pos-system. This is also the unique identifier within the temper proof fiskaltrust cloud storage for the receipt. Each receipt is processed and stored according to the fiskaltrust-security-mechanism, therefore it is temper proof and mirrored into fiskaltrust cloud. You can visit following link for further details: [fiskaltrust-security-mechanism](https://docs.fiskaltrust.cloud/docs/posdealers/buy-resell/products/middleware#security-mechanism).
+Each receipt is identified via "QueueItemID", which is generated by the middleware driving the security mechanism within the pos-system. This is also the unique identifier within the tamper-proof fiskaltrust cloud storage for the receipt. Each receipt is processed and stored according to the fiskaltrust-security-mechanism, therefore it is tamper-proof and mirrored into fiskaltrust cloud. You can visit following link for further details: [fiskaltrust-security-mechanism](https://docs.fiskaltrust.cloud/docs/posdealers/buy-resell/products/middleware#security-mechanism).
 
 fiskaltrust appointed Dr. Markus Knasmüller to create an external assessment about the conformity of the various methods of digital receipt creation correspond to the technical requirements of RKSV. The assessment can be requested here: https://forms.office.com/e/0PcMDYWC2B 
 
 It is required in Austria to implement the POS-API with the /print endpoint or use the InStore App to fulfill the compliance requirements mentioned above in Austria. More details about the integration in Austria can be found in the integration part of this document.
 
-### Evaluation of receipt retrivals for financial administration audits 
+### Evaluation of receipt retrievals for financial administration audits 
 
 For an evaluation of receipt retrieval, it is possible to verify in an audit case (or in general), which receipts were transmitted, retrieved, or printed through the fiskaltrust.Portal using the export function.