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.
@@ -29,7 +29,7 @@ We recommend to make the ZeroReceipt after a failure a manual operation, and not
:::tip
-We recomment 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).
:::
@@ -47,7 +47,7 @@ In this case, the following steps must be taken:
- The cash register or input station must automatically produce a receipt and its copy.
- The receipt must be marked with the identification "electronic recording system failed" and with the current failure counter.
- This copy needs to be kept until the failure is resolved. The creation and storing of the receipt copy can also be done electronically by the cash register or terminal.
- - After re-establishing the communication to fiskaltrust.Middleware, the cash register or the input station must send all receipts marked with the identification "receipt copy, electronic recording system failed" to fiskaltrust.Middleware. The ReceiptCase must be flagged with the code "failed receipt" in order to indicate the failure to fiskaltrust.Middleware, which will then issue a receipt response with the the ftState "Late Signing Mode".
+ - 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".
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 7823489..785efeb 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
@@ -88,7 +88,7 @@ The start receipt has to be sent before the security mechanism is used for the f
The stop receipt is required for scheduled decommissioning of security mechanisms and/or cash registers. The stop receipt is used to switch off: the receipt chaining, the counter up-counting, and the totalizer storing. It also concludes the data collection log.
-This receipt has a meaningful response from fiskaltrust.SecurityMechanism only the first time: in order to stop operative calculations and the operation of a queue. After receiving a stop receipt the queue will be closed. There will be no positive response from the cash register when a receipt is send to a closed queue.
+This receipt has a meaningful response from fiskaltrust.SecurityMechanism only the first time: in order to stop operative calculations and the operation of a queue. After receiving a stop receipt the queue will be closed. There will be no positive response from the cash register when a receipt is sent to a closed queue.
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.
diff --git a/poscreators/middleware-doc/general/cash-register-integration/voided-receipt-regular-workflow.md b/poscreators/middleware-doc/general/cash-register-integration/voided-receipt-regular-workflow.md
index 490c02b..4ea2105 100644
--- a/poscreators/middleware-doc/general/cash-register-integration/voided-receipt-regular-workflow.md
+++ b/poscreators/middleware-doc/general/cash-register-integration/voided-receipt-regular-workflow.md
@@ -5,7 +5,7 @@ title: Voided receipt regular workflow
## Voided receipt workflow
-As a reminder and for legal reason any data sent to the fiskaltrust.Middleware cannot be deleted afterwards. Based on this, all changes must done by sending a new receipt.
+As a reminder and for legal reason any data sent to the fiskaltrust.Middleware cannot be deleted afterwards. Based on this, all changes must be done by sending a new receipt.
To complete a voided or cancel receipt, the same ticket with negative values should be sent to the fiskaltrust.Middleware.
The main things that should be changed on the voided or cancelled receipt:
- The field ftReceiptCase stays the same as the original but the flag for voided ticket must be set. (The value 4 on position 12).
diff --git a/poscreators/middleware-doc/general/components/components-install-config.md b/poscreators/middleware-doc/general/components/components-install-config.md
index 9971503..e1865e8 100644
--- a/poscreators/middleware-doc/general/components/components-install-config.md
+++ b/poscreators/middleware-doc/general/components/components-install-config.md
@@ -147,7 +147,7 @@ Once successfully completed, the service will appear in the list of running serv
For Linux, the fiskaltrust.SecurityMechanism can be installed as Daemon.
-Mono is the prerequisite, and can be installed following the manual of the [mono-project](http://www.mono-project.com/download/#download-lin) (install complete). Also the `mono-service` utlility needs to be installed (On Ubuntu this can be done using the command `sudo apt update && sudo apt install mono-4.0-service`).
+Mono is the prerequisite, and can be installed following the manual of the [mono-project](http://www.mono-project.com/download/#download-lin) (install complete). Also the `mono-service` utility needs to be installed (On Ubuntu this can be done using the command `sudo apt update && sudo apt install mono-4.0-service`).
Once the installation is completed, a file named `fiskaltrust` with the following content has to be saved in the index `/etc/init.d`:
diff --git a/poscreators/middleware-doc/general/components/components.md b/poscreators/middleware-doc/general/components/components.md
index 8c40d70..71ffa76 100644
--- a/poscreators/middleware-doc/general/components/components.md
+++ b/poscreators/middleware-doc/general/components/components.md
@@ -70,7 +70,7 @@ For detailed information on supported platforms and its restrictions, please ref
### ARM Processor
-From version 1.3.39 it is now possible to run the the fiskaltrust.Middleware on ARM processors.
+From version 1.3.39 it is now possible to run the fiskaltrust.Middleware on ARM processors.
SCU | ARM 64 bit | ARM 32 bit |
| --------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
diff --git a/poscreators/middleware-doc/general/data-structures/data-structures.md b/poscreators/middleware-doc/general/data-structures/data-structures.md
index df88944..f804adc 100644
--- a/poscreators/middleware-doc/general/data-structures/data-structures.md
+++ b/poscreators/middleware-doc/general/data-structures/data-structures.md
@@ -16,7 +16,7 @@ The `ftReceiptCase` **fiskaltrust** field is of critical importance for the corr
| Field Name | Data Type | Default Value | Nullable | Description |
|-------------------------|---------------------------|-------------------|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|
| `cbTerminalID` | `String`
-In this example, a customer wants to pay and no more orders are expected. A ftReceiptCase `0x4445000000000001` (POS receipt) + ftReceiptCaseFlag `0x0000000100000000` (Implicit Flag) is beeing sent to the middleware. The call includes all collected charge- and payitems of the business action (in this example: Soda Zitrone and Kaffee Haag, including cash payment).
+In this example, a customer wants to pay and no more orders are expected. A ftReceiptCase `0x4445000000000001` (POS receipt) + ftReceiptCaseFlag `0x0000000100000000` (Implicit Flag) is being sent to the middleware. The call includes all collected charge- and payitems of the business action (in this example: Soda Zitrone and Kaffee Haag, including cash payment).
The response's signature block includes all information needed to be printed on the receipt (time of receipt creation - which is the returned value of cbReceiptMoment of the sign-request, start time of the action, and end time of the action).
@@ -286,9 +286,9 @@ The response's signature block includes all information needed to be printed on
-In this example, ongoing orders are expected over a longer period of time before a payment is made. Therefore, a ftReceiptCase `0x44450000000000010` (Info-order without pay-items) + ftReceiptCaseFlag `0x0000000100000000` (Implicit Flag) is beeing sent to the middleware to document the long-lasting business-action. This is beeing repeated for every new order, using 'cbReceiptReference' to connect the new order with the previous corresponding one.
+In this example, ongoing orders are expected over a longer period of time before a payment is made. Therefore, a ftReceiptCase `0x44450000000000010` (Info-order without pay-items) + ftReceiptCaseFlag `0x0000000100000000` (Implicit Flag) is being sent to the middleware to document the long-lasting business-action. This is being repeated for every new order, using 'cbReceiptReference' to connect the new order with the previous corresponding one.
-For the payment (which may include a last order as well), a ftReceiptCase `0x4445000000000001` (POS receipt) + ftReceiptCaseFlag `0x0000000100000000` (Implicit Flag) is beeing sent to the middleware like in the previous example above to close this business action. All in the previous sign-requests collected chargeItems have to be included in this POS receipt, including the pay-items.
+For the payment (which may include a last order as well), a ftReceiptCase `0x4445000000000001` (POS receipt) + ftReceiptCaseFlag `0x0000000100000000` (Implicit Flag) is being sent to the middleware like in the previous example above to close this business action. All in the previous sign-requests collected chargeItems have to be included in this POS receipt, including the pay-items.
The response's signature block of the POS receipt includes all information needed to be printed on the receipt (time of receipt creation - which is the returned value of cbReceiptMoment of the first sign-request of cbReceiptReference-connected orders, start time of the action, and end time of the action).
@@ -720,7 +720,7 @@ It is not mandatory to call 'Sign' using 'ReceiptCase' "Update-Transaction" befo
-The main functionality is the same as when calling the 'Sign' method using 'ReceiptCase' "Update-Transaction". The differences are the details used in 'ChargeItems' and 'PayItems'; they hey depict exactly the same delta that occurred since the last call using 'Start-Transaction' or the last call using 'Delta-Transaction'. There should be a system-wide decision for the implementation to use only one of the 'ReceiptCases' - 'Update-Transaction' or 'Delta-Transaction'.
+The main functionality is the same as when calling the 'Sign' method using 'ReceiptCase' "Update-Transaction". The differences are the details used in 'ChargeItems' and 'PayItems'; they depict exactly the same delta that occurred since the last call using 'Start-Transaction' or the last call using 'Delta-Transaction'. There should be a system-wide decision for the implementation to use only one of the 'ReceiptCases' - 'Update-Transaction' or 'Delta-Transaction'.
According to the German law and BSI TR-03153, a call to the 'Sign' method using the 'ReceiptCase' "Delta-Transaction" handles the updating of a transaction inside the TSE. The same transaction number as responded at the call of "Start-Transaction" is responded behind the hash-tag in the property 'ftReceiptIdentification' of 'ReceiptResponse', prefixed by "DT".
It is not mandatory to call 'Sign' using 'ReceiptCase' "Delta-Transaction" before finalising a transaction. It is also possible to call 'Sign' using 'ReceiptCase' "Delta-Transaction" multiple times for a single unique identifier/for a single transaction.
@@ -760,7 +760,7 @@ For a better understanding how to implement the explicit flow, we prepared a use
-In this example, a customer wants to pay in a retail store at a scanner cash register. A ftReceiptCase `0x4445000000000008` (Start Transaction) is beeing sent to the middleware. The chargeItems are collected (e.g. the products are scanned) and the business action is beeing closed by sending a sign-request using the ftReceiptCase '0x4445000000000001' (POS receipt) including all collected charge- and payitems of the business action (in this example: Feuerzeug BigRed and Kaffee Hag, including cash payment).
+In this example, a customer wants to pay in a retail store at a scanner cash register. A ftReceiptCase `0x4445000000000008` (Start Transaction) is being sent to the middleware. The chargeItems are collected (e.g. the products are scanned) and the business action is being closed by sending a sign-request using the ftReceiptCase '0x4445000000000001' (POS receipt) including all collected charge- and payitems of the business action (in this example: Feuerzeug BigRed and Kaffee Hag, including cash payment).
The response's signature block includes all information needed to be printed on the receipt (time of receipt creation, start time of the action, and end time of the action).
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/data-structures/data-structures.md b/poscreators/middleware-doc/middleware-de-kassensichv/data-structures/data-structures.md
index c953fe4..a80ff19 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/data-structures/data-structures.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/data-structures/data-structures.md
@@ -57,7 +57,7 @@ For some cases, it is needed to transmit data within the field `ftReceiptCaseDat
|----------------|---------------|-----------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|
| `UserId` | `string` | optional | Send via `ftReceiptCaseData` in JSON format. To send, please add the key value pair `UserId` e.g. `"ftReceiptCaseData":"{ ..., "UserId": "U192", ... }"`. If not sent, the fiskaltrust.Middleware will automatically generate a User-ID (hash) deducted from `cbUser` | 1.3 |
| `ReceiptNote` | `string` | optional | Additional information on the receipt header. Can be sent via `ftReceiptCaseData` in JSON format. To send, add the key value pair `ReceiptNote` e.g. `"ftReceiptCaseData":"{ ..., "ReceiptNote":"123, ich bin dabei!", ... }"` | 1.3 |
-| `ReceiptName` | `string` | Mandatory if your request mapps to the DSFinV-K BON_TYPE "AVSonstige" (see `ftReceiptCase`), otherwise optional | Can be sent via `ftReceiptCaseData` in JSON format. To send, add the key value pair `ReceiptName` e.g. `"ftReceiptCaseData":"{ ..., "ReceiptName":"Sonstige Sonderwurst", ... }"` | 1.3 |
+| `ReceiptName` | `string` | Mandatory if your request maps to the DSFinV-K BON_TYPE "AVSonstige" (see `ftReceiptCase`), otherwise optional | Can be sent via `ftReceiptCaseData` in JSON format. To send, add the key value pair `ReceiptName` e.g. `"ftReceiptCaseData":"{ ..., "ReceiptName":"Sonstige Sonderwurst", ... }"` | 1.3 |
If you need to provide a **reference** to another system or another cashpoint, you can add it via the field `ftReceiptCaseData` by providing its data as shown below:
@@ -121,7 +121,7 @@ For some cases, it is needed to transmit data within the field `ftPayItemCaseDat
|-------------------------|---------------|------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|
| `CurrencyCode` | `string (3)` | mandatory if foreign currency used | Mandatory if a foreign currency was used for the payment. To send, add the key value pair `CurrencyCode` e.g. `"ftPayItemCaseData":"{ ..., "CurrencyCode":"USD", ... }"`. Only ISO 4217 currency codes are allowed. | 1.3 |
| `ForeignCurrencyAmount` | `decimal (2)` | mandatory if foreign currency used | Mandatory if a foreign currency was used for the payment. To send, add the key value pair `ForeignCurrencyAmount` e.g. `"ftPayItemCaseData":"{ ..., "ForeignCurrencyAmount":23.00, ... }"`. | 1.3 |
-| `BaseCurrencyAmount` | `decimal (2)` | mandatory if foreign currency used | Mandatory if a foreign currency was used for the payment. Represents the converted value of the payed foreign currency amount into the base currency (EUR). To send, add the key value pair `BaseCurrencyAmount` e.g. `"ftPayItemCaseData":"{ ..., "BaseCurrencyAmount":20.00, ... }"`. | 1.3 |
+| `BaseCurrencyAmount` | `decimal (2)` | mandatory if foreign currency used | Mandatory if a foreign currency was used for the payment. Represents the converted value of the paid foreign currency amount into the base currency (EUR). To send, add the key value pair `BaseCurrencyAmount` e.g. `"ftPayItemCaseData":"{ ..., "BaseCurrencyAmount":20.00, ... }"`. | 1.3 |
| `VoucherNr` | `string` | mandatory if applicable | Send via `ftPayItemCaseData` in JSON format if the pay item represents the voucher. To send, please add the key value pair `VoucherNr` e.g. `"ftPayItemCaseData":"{ ..., "VoucherNr":"UAUA91829182HH", ... }"`. | 1.3 |
| `MoneyGroupId` | `string` | optional | Send via `ftPayItemCaseData` in JSON format. To send, please add the key value pair `MoneyGroupId` e.g. `"ftPayItemCaseData":"{ ..., "MoneyGroupId":192, ... }"`. If not sent, the fiskaltrust.Middleware will automatically generate an ID (CRC32 hash) deducted from `ftPayItem.MoneyGroup` | 1.3 |
| `AgencyId` | `integer` | mandatory if applicable | Mandatory if agency business (DE: Agenturgeschäft). Send via `ftPayItemCaseData` in JSON format. To send, please add the key value pair `AgencyId` e.g. `"ftPayItemCaseData":"{ ..., "AgencyId": "73c94a68-c329-4d82-a8e4-d48903791922", ... }"` (the ID can be taken from the Portal's _Agency management_ page). Should only be used in cases where PayItems will be transformed to `GV_TYP`es during DSFinV-K generation - otherwise, please use `ftChargeItemCaseData`. | 1.3 |
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-databases/entity-framework.md b/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-databases/entity-framework.md
index 6639a5f..264748e 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-databases/entity-framework.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-databases/entity-framework.md
@@ -19,4 +19,4 @@ This storage provider is particularly suitable for setting up fail-safe systems
| --------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
| _connectionstring_ | EF-compatible connection string to the database system | mandatory |
| _TarFileExportMode_ | `All` Enables the automatic TAR File export from the TSE on the Queue level. `None` Disables the automatic TAR File export from the TSE on the Queue level. `Erased` TAR files are only exported and saved when they could be deleted from the TSE. (Values: `All` / `None` / `Erased`) | optional (default: `All`) |
-| _StoreTemporaryExportFiles_ | Enables storage of temporaty export files in the `fiskaltrust/service/Exports` folder (Values: `true` / `false`) | `false`
Max 1023 | undefined | false | The unique identification of the input-station/terminal within a cash-register/pos-system identified by `ftCashBoxID`. |
-| `cbReceiptReference*` | `String`
Max 1023 | undefined | false | The reference number sent by the cash register. This value must be a unique string/receipt number related to the calling cash register. This string/receipt number is a a unique primary key for the cash register's dataset. |
+| `cbReceiptReference*` | `String`
Max 1023 | undefined | false | The reference number sent by the cash register. This value must be a unique string/receipt number related to the calling cash register. This string/receipt number is a unique primary key for the cash register's dataset. |
| `cbReceiptMoment*` | `string($date-time)` | now() | false | The moment at which the receipt was created by the cash register. It must be provided in UTC. Example: 2020-06-29T17:45:40.505Z. |
| `cbChargeItems*` | | | | List of line items related to services and products. |
| `cbPayItems*` | | | | List of line items related to payments. |
@@ -24,8 +24,8 @@ The `ftReceiptCase` **fiskaltrust** field is of critical importance for the corr
| `ftPosSystemID` | `string($uuid)` | 00000000-0000-0000-0000-000000000000 | false | Identification of the used software of the cash register. |
| `ftReceiptCase` | `integer($uint64)` | 0 | false | Type of business according to **fiskaltrust** reference. For more information, see [ftReceiptCase](../../general/reference-tables/reference-tables.md#type-of-receipt-ftreceiptcase). This field is relevant for **fiskaltrust.middleware** processing and represents a country-specific mapping. If not specified, the cash register’s business case at the point of sale is used as a fallback. |
| `ftReceiptCaseData` | | | false | This optional field provides additional details for the defined type of business, as referenced by **fiskaltrust**. |
-| `ftQueueID` | `string($uuid)` | null | true | Optional routing instruction used to identify a specific queue behind a load balancer or in other usecases. |
-| `cbPrevi-ousReceiptReference` | `String`
Max 1023 | null | true | Optional reference to `cbReceiptReference` of the previous receipt. This is used to connect multiple requests withing a single Business Case. |
+| `ftQueueID` | `string($uuid)` | null | true | Optional routing instruction used to identify a specific queue behind a load balancer or in other use cases. |
+| `cbPreviousReceiptReference` | `String`
Max 1023 | null | true | Optional reference to `cbReceiptReference` of the previous receipt. This is used to connect multiple requests within a single Business Case. |
| `cbReceiptAmount` | `integer($int64)`
`number($double)` | | true | Optional total receipt amount, including value added taxes (i.e., gross receipt amount). This field is provided to prevent calculation and rounding differences. Systems that use net amounts as the central calculation should always use this property. If not provided, the sum of amount in all provided `ftChargeItems` is used as total receipt amount. It uses `DecimalPresissionMultiplier` as discriminator between `int64` and `double` values. |
| `cbUser` | | | false | Optional Identification of the user who creates the receipt. |
| `cbArea` | | | false | Optional Identification of the area, section, or field in which the receipt is created. Examples include table number of a restaurant business, a department of a commercial establishment, or the vehicle of a taxi company. |
@@ -50,8 +50,8 @@ The `ftReceiptCase` **fiskaltrust** field is of critical importance for the corr
| `ftState*` | `integer($uint64)` | 0 | false | Indicates the status of the **fiskaltrust.Middleware** according to **fiskaltrust** reference. For more information, see [ftState](../../general/reference-tables/reference-tables.md#service-status-ftstate). |
| `ftStateData` | | | false | This optional field provides additional details for the status of **fiskaltrust.Middleware** defined type of business related to **fiskaltrust** reference. |
| `ftCashBoxID` | `string($uuid)` | 00000000-0000-0000-0000-000000000000 | false | Mirror from `ReceiptRequest` identification of the cash register. |
-| `cbTerminalID` | `String`
Max 1023 | undefined | false | Mirror from `ReceiptRequest`. Represents the unique identification of the input station or terminal within a cash-registeror POS system, as identified by `ftCashBoxID`. |
-| `cbReceiptReference*` | `String`
Max 1023 | undefined | false | Mirror from `ReceiptRequest`. Represents the reference number sent by the cash register. This value must be a unique string/receipt number related to the calling cash register and servers as a unique primary key within the cash register’s dataset. |
+| `cbTerminalID` | `String`
Max 1023 | undefined | false | Mirror from `ReceiptRequest`. Represents the unique identification of the input station or terminal within a cash-register or POS system, as identified by `ftCashBoxID`. |
+| `cbReceiptReference*` | `String`
Max 1023 | undefined | false | Mirror from `ReceiptRequest`. Represents the reference number sent by the cash register. This value must be a unique string/receipt number related to the calling cash register and serves as a unique primary key within the cash register’s dataset. |
| `ftReceiptHeader` | `String`
Max 1023 | | false | Additional header lines that must be printed on the receipt. |
| `ftChargeItems` | | | | List of line items added by **fiskaltrust.Middleware** during request processing, related to services and products. These items must be printed on the receipt. |
| `ftChargeLines` | `String`
Max 1023 | | false | Additional text for line items related to services and products. This must be printed on the receipt. |
@@ -68,7 +68,7 @@ Represents an item related to a service or a product that is taxable.
| `ftChargeItemID` | `string($uuid)` | null | true | Optional. This field is used as an identifier of a `chargeitem` when reading data. |
| `Quantity*` | | | | Defines the quantity of the line item. The line items with the same Description, VATRate, and `itemprice` (=Amount/Quantity) can be accumulated for better visualization. It uses `DecimalPresissionMultiplier` as discriminator between `int64` and `double` values. |
| `Description*` | `String`
Max 1023 | null | true | Defines the description of the line item. The line items with the same Description, VATRate, and `itemprice` (=Amount/Quantity) can be accumulated for better visualization. |
-| `Amount*` | | | | Defines the (total) amount of the line item. To obtain `itemprice`, the amount must be devided by quantity. It uses `DecimalPresissionMultiplier` as discriminator between `int64` and `double` values. |
+| `Amount*` | | | | Defines the (total) amount of the line item. To obtain `itemprice`, the amount must be divided by quantity. It uses `DecimalPresissionMultiplier` as discriminator between `int64` and `double` values. |
| `VATRate*` | | | | Defines the value added tax rate as a percentage of the line item. The line items with same Description, VATRate, and `itemprice` (=Amount/Quantity) can be accumulated for better visualization. It uses `DecimalPresissionMultiplier` as discriminator between `int64` and `double` values. |
| `ftChargeItemCase` | `integer($uint64)` | 0 | false | Optional. Defines the type of service or product related to **fiskaltrust** reference. For more information, see [ftChargeItemCase](../../general/reference-tables/reference-tables.md#type-of-service-ftchargeitemcase). This field is relevant for **fiskaltrust.middleware** processing and represents a country-specific mapping. If not specified, the service or product delivered at the point of sale with the defined VATRate is used as a fallback. |
| `ftChargeItemCaseData` | | | false | Optional. Provides additional details for defined type of service or product related to **fiskaltrust** reference. |
@@ -82,7 +82,7 @@ Represents an item related to a service or a product that is taxable.
| `ProductBarcode` | `String`
Max 1023 | null | true | Optional product barcode related to line item. |
| `Unit` | `String`
Max 1023 | null | true | Optional unit of measurement for the line item. For example, on one charging session of an electric vehicle, this would be Quantity 1 and the total amount of the session within amount. The unit of measurement could be kW for DC charging or minutes for AC charging. |
| `UnitQuantity` | | | true | Optional. The quantity related to the unit of measurement defined in `Unit`. It uses `DecimalPresissionMultiplier` as discriminator between `int64` and `double` values. For example, on one charging session of an electric vehicle, this would be Quantity 1 and the total amount of the session within amount. If the unit of measurement is kW for DC charging, the `UnitQuantity` could be 65.4, indicating that the line item represents a charging session with a total amount of power of 65.4 kW. |
-| `UnitPrice` | | | true | Optional. The price related to the unit of measurement defined in `Unit`. It uses `DecimalPresissionMultiplier` as discriminator between `int64` and `double` values. For example, on one charging session of an electric vehicle, this would be Quantity 1 and the total amount of 30.7 of the session within amount. If the unit of measurement is kW for DC charging, the `UnitQuantity` could be 65.4 as an example, and for the given total amount the `UnitPrice` would be 0.5., indicating that the the line item represents a charging session with a total amount of power of 65.4 kW with a price of 0.5 per kW. |
+| `UnitPrice` | | | true | Optional. The price related to the unit of measurement defined in `Unit`. It uses `DecimalPresissionMultiplier` as discriminator between `int64` and `double` values. For example, on one charging session of an electric vehicle, this would be Quantity 1 and the total amount of 30.7 of the session within amount. If the unit of measurement is kW for DC charging, the `UnitQuantity` could be 65.4 as an example, and for the given total amount the `UnitPrice` would be 0.5., indicating that the line item represents a charging session with a total amount of power of 65.4 kW with a price of 0.5 per kW. |
| `Currency` | `CurrencyEnumCurrencyEnumstring` | EUR | false | This field is used as currency code for money numbers along ISO 4217 (https://en.wikipedia.org/wiki/ISO_4217). Enum: [EUR, CHF, CZK, HUF, BAM, DKK, RON, NOK, PLN, RSD, SEK, UAH, USD, AED, AFN, ALL, AMD, ANG, AOA, ARS, AUD, AWG, AZN, BBD, BDT, BGN, BHD, BIF, BMD, BND, BOB, BOV, BRL, BSD, BTN, BWP, BYN, BZD, CAD, CDF, CHE, CHW, CLF, CLP, CNY, COP, COU, CRC, CUP, CVE, DJF, DOP, DZD, EGP, ERN, ETB, FJD, FKP, GBP, GEL, GHS, GIP, GMD, GNF, GTQ, GYD, HKD, HNL, HTG, IDR, ILS, INR, IQD, IRR, ISK, JMD, JOD, JPY, KES, KGS, KHR, KMF, KPW, KRW, KWD, KYD, KZT, LAK, LBP, LKR, LRD, LSL, LYD, MAD, MDL, MGA, MKD, MMK, MNT, MOP, MRU, MUR, MVR, MWK, MXN, MXV, MYR, MZN, NAD, NGN, NIO, NPR, NZD, OMR, PAB, PEN, PGK, PHP, PKR, PYG, QAR, RUB, RWF, SAR, SBD, SCR, SDG, SGD, SHP, SLE, SLL, SOS, SRD, SSP, STN, SVC, SYP, SZL, THB, TJS, TMT, TND, TOP, TRY, TTD, TWD, TZS, UGX, USN, UYI, UYU, UYW, UZS, VED, VES, VND, VUV, WST, XAF, XAG, XAU, XBA, XBB, XBC, XBD, XCD, XDR, XOF, XPD, XPF, XPT, XSU, XTS, XUA, XXX, YER, ZAR, ZMW, ZWL] |
| `DecimalPrecisionMultiplier` | `DecimalPrecisionMultiplierEnumDecimalPrecisionMulti-plierEnuminteger($int32)` | 1 | false | This field is used as a multiplier for decimal numbers. When the value is **1**, the relevant numbers are interpreted as floating-point numbers. For all other values, the relevant numbers are interpreted as integers and must be divided by the Multiplier to obtain the decimal representation. Enum: [1, 100, 10000, 1000000, 100000000] |
@@ -116,7 +116,7 @@ The signature entries can also be used to visualize hints and messages related t
| Field Name | Data Type | Default Value | Nullable | Description |
|-------------------------|---------------------------|-------------------|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `ftSignatureItemID` | `string($uuid)` | null | true | Optional. This field is used as an identifier of a `signautreitem` when reading data. |
+| `ftSignatureItemID` | `string($uuid)` | null | true | Optional. This field is used as an identifier of a `signatureitem` when reading data. |
| `ftSignatureFormat` | `integer($uint64)` | 0 | false | Format for displaying signature data according to **fiskaltrust** reference. For more information, see [ftSignatureFormat](../../general/reference-tables/reference-tables.md#format-of-signature-ftsignatureformat). |
| `ftSignatureType` | `integer($uint64)` | 0 | | Type of signature according to **fiskaltrust** reference. For more information, see [ftSignatureType](../../general/reference-tables/reference-tables.md#type-of-signature-ftsignaturetype). |
| `Caption` | `String`
Max 1023 | null | true | Optional heading displayed as text above the signature data. |
diff --git a/poscreators/middleware-doc/general/installation/installation.md b/poscreators/middleware-doc/general/installation/installation.md
index 8da8c3b..90b4327 100644
--- a/poscreators/middleware-doc/general/installation/installation.md
+++ b/poscreators/middleware-doc/general/installation/installation.md
@@ -149,7 +149,7 @@ Once successfully completed, the service will appear in the list of running serv
For Linux, the fiskaltrust.SecurityMechanism can be installed as Daemon.
-Mono is the prerequisite, and can be installed following the manual of the [mono-project](http://www.mono-project.com/download/#download-lin) (install complete). Also the `mono-service` utlility needs to be installed (On Ubuntu this can be done using the command `sudo apt update && sudo apt install mono-4.0-service`).
+Mono is the prerequisite, and can be installed following the manual of the [mono-project](http://www.mono-project.com/download/#download-lin) (install complete). Also the `mono-service` utility needs to be installed (On Ubuntu this can be done using the command `sudo apt update && sudo apt install mono-4.0-service`).
Once the installation is completed, a file named `fiskaltrust` with the following content has to be saved in the index `/etc/init.d`:
diff --git a/poscreators/middleware-doc/general/reference-tables/reference-tables-v1.md b/poscreators/middleware-doc/general/reference-tables/reference-tables-v1.md
index e75571d..9e379ae 100644
--- a/poscreators/middleware-doc/general/reference-tables/reference-tables-v1.md
+++ b/poscreators/middleware-doc/general/reference-tables/reference-tables-v1.md
@@ -56,7 +56,7 @@ Business transactions can result in combinations of receipt types, which would b
| `0x0000000000020000` | "training receipt"
Used to separate the normal usage of the cash register system from the training mode. This flag can be added to each Receipt Request when training/testing is performed. This receipt will not produce any tax relevant changes. | 1.0 |
| `0x0000000000040000` | "reverse receipt" or "voided receipt"
Used to separate regular receipts from the receipts which were voided by setting the negative values for **both** Amount **and** Quantity in Chargeitems and Payitems of the receipt. The cbPreviousReceiptReference should be set to the ReceiptReference of the Receipt which should be voided. | | 1.0 |
| `0x0000000000080000` | "handwritten receipt "
The transferred receipt contains data which has been collected in a handwritten receipt. There is no requirement for a precise time annotation on a handwritten receipt; we recommend using 12:00 for this purpose. | 1.0 |
-| `0x0000800000000000` | "receipt request".
Used to retrieve an already processed receipt from the fiskaltrust.Middleware using the cbReceiptReference field. The cbTerminalID can also be included in this request. Chargeitems and payitems have to be exactly the same as in the requested receipt. If a matching receipt is found, its content will be returned. If nothing is found a null value is returned. This can be nescessary if a communication problem occurs while fiskaltrust.Middleware processes a request. | 1.1 |
+| `0x0000800000000000` | "receipt request".
Used to retrieve an already processed receipt from the fiskaltrust.Middleware using the cbReceiptReference field. The cbTerminalID can also be included in this request. Chargeitems and payitems have to be exactly the same as in the requested receipt. If a matching receipt is found, its content will be returned. If nothing is found a null value is returned. This can be necessary if a communication problem occurs while fiskaltrust.Middleware processes a request. | 1.1 |
| | To prevent a duplication of requested receipt, the cash register terminal can place an additional parameter inside the queue to influence the behavior of this "receipt request" when no receipt is found.
Parameter name: "receiptrequestmode"
Parameter values:
0 (default) … null is returned
1 … request is handled in the same way as new request. If processing is successful, the created ReceiptResponse is returned. | 1.2 |
These flags are based on national laws and regulations, for further information please refer to the appropriate country specific appendix.
@@ -127,7 +127,7 @@ For definitions regarding national laws, please refer to the appropriate appendi
| `0x0000000000000000` | **Version information**
Version information informs which version of the fiskaltrust.Middleware is currently being used | 1.1 |
| `0x0000000000000001` | **[fiskaltrust.ActionJournal](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/general/cash-register-integration#fiskaltrustactionjournal)** in internal format
The fiskaltrust.ActionJournal collects all operational incidents. This can be the date and time of start or failure of the service, as well as any other information related to the fiskaltrust.Middleware and fiskaltrust.SecurityMechanism.| 1.1 |
| `0x0000000000000002` | **[ReceiptJournal](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/general/cash-register-integration#fiskaltrustreceiptjournal)** in internal format
The fiskaltrust.ReceiptJournal is used to record, hash, and chain all requests to the fiskaltrust.Middleware and the resulting responses. The first part of the returned ReceiptIdentification is an upcounting number generated by ReceiptJournal. | 1.1 |
-| `0x0000000000000003` | **QueueItemJournal in internal format**
QueueItemJournal shows every information related to to the fiskaltrust.Middleware and fiskaltrust.SecurityMechanism, as well as all receipts sent to the fiskaltrust.Middleware and all resulting responses. This is useful for archiving purposes. | 1.1 |
+| `0x0000000000000003` | **QueueItemJournal in internal format**
QueueItemJournal shows every information related to the fiskaltrust.Middleware and fiskaltrust.SecurityMechanism, as well as all receipts sent to the fiskaltrust.Middleware and all resulting responses. This is useful for archiving purposes. | 1.1 |
**Example** for version information :
diff --git a/poscreators/middleware-doc/general/reference-tables/reference-tables.md b/poscreators/middleware-doc/general/reference-tables/reference-tables.md
index d42c110..751213a 100644
--- a/poscreators/middleware-doc/general/reference-tables/reference-tables.md
+++ b/poscreators/middleware-doc/general/reference-tables/reference-tables.md
@@ -5,7 +5,7 @@ title: Reference Tables
# Reference Tables
-As the Middleware abstracts processes and data accross multiple markets and countries, there is a specific mapping for each market. This mapping is based on the overall tagging system, which provides the additional benefit of a semantical value to all receipts, charge items, and pay items. The following section briefly describes the overall format.
+As the Middleware abstracts processes and data across multiple markets and countries, there is a specific mapping for each market. This mapping is based on the overall tagging system, which provides the additional benefit of a semantical value to all receipts, charge items, and pay items. The following section briefly describes the overall format.
## Format
@@ -96,7 +96,7 @@ The fiskaltrust receipt case field (`ftReceiptCase`) is of utmost importance for
| `0008` | **Process as Handwritten Receipt**
During a power outage, the cash register will not work, and the merchant issues handwritten receipts. These receipts must be sent to the Security Mechanism using this flag. |
| `0010` | **IssuerIsSmallBusiness**
Businesses below a country-specific size in revenue do not need to declare VAT. With this marker, the receipt shows no VAT, all prices are gross, and a country-specific hint must be printed. |
| `0020` | **ReceiverIsBusiness**
Specific data must be included on the receipt. |
-| `0040` | **ReceiverIsKnown**
Characteristics related to UStG are provided. For example, Name, Adress, VAT-ID, other local details. |
+| `0040` | **ReceiverIsKnown**
Characteristics related to UStG are provided. For example, Name, Address, VAT-ID, other local details. |
| `0080` | **IsSaleInForeignCountry** | |
| `0100` | **IsReturn/IsRefund**
Marks the receipt as a return of goods or services. |
| `0200` | **InvoiceProcessingOnly/InvoiceDelivery**
Used when a `queueitemid` should be generated for later processing, e.g., issue. |
@@ -319,7 +319,7 @@ version 2
| `0000_0002` | SCU (Signature Creation Unit) temporarily out of service.
For at least one receipt, it was not possible to obtain a signature from an allocated SCU. Therefore, the security mechanism has been put into "signature creation device out of service" mode. Regardless of whether an allocated SCU becomes available again, this mode remains in effect until a ZeroReceipt clears the state and performs the required market-specific action. |
| `0000_0008` | Deferred Queue Mode/Late Signing Mode is active.
When the cash register doesn’t reach the queue, it queues up the receipt requests while continuing to do business. Also, with a major failure of the cash register or a power outage, handwritten paper receipts are queued up while continuing to do business. After returning to a fully functional state, these queued `ReceiptRequests` are sent to the queue, keeping the original `cbReceipt-Moment` of the business case `ReceiptCase` tagged/flagged with `0001` (Deferred Queue/Late Signing) or `0008` (Handwritten).
A result of this is a marker within the `ftState`, which can be resolved via `ZeroReceipt`. The reason for the marker is a mismatch between processed time along the receipt chain and a manual event to clean up the state, and maybe notify 3rd parties of an outage. |
| `0000_0040` | Message Pending.
Middleware/Queue is a headless background service, but there are situations where communication with the cashier/operator or the cash register is necessary. For example, if the last daily closing was missed or if a special condition related to the signature creation unit or service happened. This is when the message pending flag is set by the middleware and should be signaled to the cashier by the POS system. By executing a `ZeroReceipt`, the cashier can read the message or instruction on the printed or displayed receipt.
Related to local regulations, this receipt may be stored/archived for bookkeeping purposes; if so, this is also visualized.
-| `0000_0100` | `DailyClosing` due.
When the first `cbReceiptMoment` used since the last `DailyClosing` and the current/latest `cbReceiptMoment` in the `ReceiptRequest` have a date gap of more than two days (e.g., the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates a `DailyClosing` should be done.
`DailyClosing` is an essential part of the security mechanism and executes additional market-specific clean-up tasks. Therefore, each queue should perform a `DailyClsoing` to clear persistent changes in business data and updates in the business period. |
+| `0000_0100` | `DailyClosing` due.
When the first `cbReceiptMoment` used since the last `DailyClosing` and the current/latest `cbReceiptMoment` in the `ReceiptRequest` have a date gap of more than two days (e.g., the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates a `DailyClosing` should be done.
`DailyClosing` is an essential part of the security mechanism and executes additional market-specific clean-up tasks. Therefore, each queue should perform a `DailyClosing` to clear persistent changes in business data and updates in the business period. |
| `0000_0200` | `MonthlyClosing` due.
When the first `cbReceiptMoment` used since last `MonthlyClosing` and the current/latest `cbReceiptMoment` in the `ReceiptRequest` are different, this state indicates a `MonthlyClosing` should be done. |
| `0000_0400` | `YearlyClosing` due. |
| `EEEE_EEEE` | Error.
Something went wrong while processing the last request. `QueueItem` exists but didn’t reach the state of a `ReceiptItem` and didn’t consume a `ftReceiptNumber` within the chain. Error reason is shown within the responded `ftSignatureItems`. This happens, for example, if the `ReceiptCase` is not recognized or is wrong. |
@@ -442,7 +442,7 @@ version 2
|--------|------------------------|-----------------|
| `000` | Notification | |
| `001` | Primary market-related compliance signature | |
-| `010??` | Middleware version: the version of the middlware used to generate the given receipt | |
+| `010??` | Middleware version: the version of the middleware used to generate the given receipt | |
| `Exx??` | Related information to `EEEE_EEEE` `ftState`
Flag: do not print/visualize
Data: Base64 stack trace if debug/sandbox | Exception Number/Name |
| `Fxx??` | Related information to `FFFF_FFFF` `ftState`
Flag: do not print/visualize
Data: Base64 stack trace if debug/sandbox | Exception Number/Name |
diff --git a/poscreators/middleware-doc/instore-app/Setup-guide/setup.md b/poscreators/middleware-doc/instore-app/Setup-guide/setup.md
index 4e2d0d4..fc50683 100644
--- a/poscreators/middleware-doc/instore-app/Setup-guide/setup.md
+++ b/poscreators/middleware-doc/instore-app/Setup-guide/setup.md
@@ -9,9 +9,9 @@ To install the fiskaltrust InStore App and connect it to your cash register, com
## Step 1: Install the app
-Refer to the [installation guides](../installation-guides/installation-guides.md) for detailed intructions.
+Refer to the [installation guides](../installation-guides/installation-guides.md) for detailed instructions.
-## Step2: Start the app and grant permissions
+## Step 2: Start the app and grant permissions
* Once installed, launch the app.
* If prompted, enable the **Display over other apps** option (this allows the app to stay in the foreground while you work in other apps).
diff --git a/poscreators/middleware-doc/instore-app/installation-guides/installation-guides.md b/poscreators/middleware-doc/instore-app/installation-guides/installation-guides.md
index da92f32..9bc848b 100644
--- a/poscreators/middleware-doc/instore-app/installation-guides/installation-guides.md
+++ b/poscreators/middleware-doc/instore-app/installation-guides/installation-guides.md
@@ -18,7 +18,7 @@ Note: The Manual guide includes both the stable and preview download links.
## Also supported
-For the following protals please refer to the partners documentation and support on how to install the `fiskaltrust InStore App`:
+For the following portals please refer to the partners documentation and support on how to install the `fiskaltrust InStore App`:
- [PAX Viva Wallet](https://vivawallet.whatspos.com)
- [PAX Global Payments](https://www.whatspos.com)
diff --git a/poscreators/middleware-doc/instore-app/installation-guides/manual/manual-guide.md b/poscreators/middleware-doc/instore-app/installation-guides/manual/manual-guide.md
index d029c80..5afaf25 100644
--- a/poscreators/middleware-doc/instore-app/installation-guides/manual/manual-guide.md
+++ b/poscreators/middleware-doc/instore-app/installation-guides/manual/manual-guide.md
@@ -8,7 +8,7 @@ title: Manual Installation Guide
## Download the App
- Open **Web Explorer** or any other web browser on your device.
-- Visit the download page for the Fiskaltrust InStore App:
+- Visit the download page for the fiskaltrust InStore App:
- [Stable version](https://link.fiskaltrust.eu/downloads/instoreapp/stable) - use in production and for release testing.
- [Preview version](https://link.fiskaltrust.eu/downloads/instoreapp/preview) - use during development or to test new, upcoming features.
diff --git a/poscreators/middleware-doc/instore-app/introduction/introduction.md b/poscreators/middleware-doc/instore-app/introduction/introduction.md
index 7caf5c7..c6da480 100644
--- a/poscreators/middleware-doc/instore-app/introduction/introduction.md
+++ b/poscreators/middleware-doc/instore-app/introduction/introduction.md
@@ -40,7 +40,7 @@ The InStore App offers five options: scanning the QR code to receive the digital
In-store, the merchant collects items and processes the payment or checkout. The merchant then sends a sign message to fiskaltrust for fiscalization purposes.
-- **Scan QR code:** The InStore App continuously listens to the fiskaltrust receipt backend for incoming receipt push events. When an HTTPS receipt link is received, it displays a QR code on the device screen. The consumer scans the QR code with their mobile phone and receives the HTTPS receipt link. The InStore app sends a log to the fiskaltrust backend indicating that the receipt was scanned by the consumer. The fiskaltrust backend renders the receipt, and the QR code display on the InStore App device is closed. The consumer can now accesses the HTML receipt document and provide feedback regarding the receipt.
+- **Scan QR code:** The InStore App continuously listens to the fiskaltrust receipt backend for incoming receipt push events. When an HTTPS receipt link is received, it displays a QR code on the device screen. The consumer scans the QR code with their mobile phone and receives the HTTPS receipt link. The InStore app sends a log to the fiskaltrust backend indicating that the receipt was scanned by the consumer. The fiskaltrust backend renders the receipt, and the QR code display on the InStore App device is closed. The consumer can now access the HTML receipt document and provide feedback regarding the receipt.
- **Acknowledge:** The consumer manually acknowledges receipt by tapping the OK button in the InStore App. The InStore app sends a log to the fiskaltrust backend indicating that the receipt was acknowledged manually. The InStore app receives a response from the fiskaltrust backend to close the display.
diff --git a/poscreators/middleware-doc/middleware-at-rksv/cash-register-integration/cash-register-integration.md b/poscreators/middleware-doc/middleware-at-rksv/cash-register-integration/cash-register-integration.md
index 2ccf5e7..19683a6 100644
--- a/poscreators/middleware-doc/middleware-at-rksv/cash-register-integration/cash-register-integration.md
+++ b/poscreators/middleware-doc/middleware-at-rksv/cash-register-integration/cash-register-integration.md
@@ -103,7 +103,7 @@ Furthermore, you can find two fundamentally different types of failure distingui
### Signature Creation Device Failure
-A signature creation device failure must be assumed if fiskaltrust.SecuritymMechanisms cannot communicate with the signature creation device temporarily. This can happen when e.g. the chip-card reader is faulty.
+A signature creation device failure must be assumed if fiskaltrust.SecurityMechanisms cannot communicate with the signature creation device temporarily. This can happen when e.g. the chip-card reader is faulty.
In case of a signature creation device failure, the machine-readable code from fiskaltrust.SecurityMechanisms (following the RKSV) is processed and sent back to the cash register. The status of the fiskaltrust.SecurityMechanism is communicated to the cash register input station with every response. The failure status can only be terminated through a zero receipt. Requesting the zero receipt can be done automatically through the input station or manually by the user.
diff --git a/poscreators/middleware-doc/middleware-at-rksv/operation-modes/operation-modes.md b/poscreators/middleware-doc/middleware-at-rksv/operation-modes/operation-modes.md
index 46c8db1..bbc28a6 100644
--- a/poscreators/middleware-doc/middleware-at-rksv/operation-modes/operation-modes.md
+++ b/poscreators/middleware-doc/middleware-at-rksv/operation-modes/operation-modes.md
@@ -64,7 +64,7 @@ https://portal.fiskaltrust.at
Signature creation devices used in the Austrian market have various characteristics and requirements.
-SmartCard – it is the most simple form of a SSCD. It is connected directly via a USB connection to the hardware, which runs the fiskaltrust.SecurityMechanism. A PCSC driver, supported by the respective operating system is necessary for the chip-card reader to operate such local signature creation devices. Windows provides this for many chip-card readers. For Linux or Mac the [PCSC lite project](https://pcsclite.apdu.fr/) can be consulted.
+SmartCard – it is the most simple form of an SSCD. It is connected directly via a USB connection to the hardware, which runs the fiskaltrust.SecurityMechanism. A PCSC driver, supported by the respective operating system is necessary for the chip-card reader to operate such local signature creation devices. Windows provides this for many chip-card readers. For Linux or Mac the [PCSC lite project](https://pcsclite.apdu.fr/) can be consulted.
Online signature service - A SSCD can also be used as an online service, where it is unnecessary to access any local hardware to use it. However, for each signature an internet connection is required. An example of this type of SSCD module is the "atrustonline".
@@ -100,7 +100,7 @@ In the simplest scenario, a fiskaltrust.SecurityMechanism consists of a single s
To handle scenarios of higher complexity, a fiskaltrust.SecurityMechanism can also consist of several signature creation devices (SSCD) and several queues with data collection protocols (RKSV-DEP). If there are several queues in a fiskaltrust.SecurityMechanism, a load balancer can be used to maximize the performance, and also as a backup outage scenario. In a backup outage scenario, signature creation devices (SSCD) can also be used across services.
-The fiskaltrust.SecurityMechanism illustrated below hosts several queues. Each queue runs a RKSV-DEP and a E131-DEP. The queues can address a signature creation device available within a pool.
+The fiskaltrust.SecurityMechanism illustrated below hosts several queues. Each queue runs a RKSV-DEP and an E131-DEP. The queues can address a signature creation device available within a pool.
diff --git a/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md
index c769fae..4be167f 100644
--- a/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md
+++ b/poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md
@@ -9,7 +9,7 @@ This chapter expands on the reference tables covered in the Chapter [Reference t
## Service Status: ftState
-The table below describes it supported statuses for the ftState field following the Austrian law. The ftState from this reference table and the general part of this documentation can be combined through the logic operator "OR". For example `0x4154000000000010` (monthly report due) and `0x4154000000000008` combined through `OR` results in `0x4154000000000018`.
+The table below describes the supported statuses for the ftState field following the Austrian law. The ftState from this reference table and the general part of this documentation can be combined through the logic operator "OR". For example `0x4154000000000010` (monthly report due) and `0x4154000000000008` combined through `OR` results in `0x4154000000000018`.
The country-specific code is made of the country's code value following the ISO-3166-1-ALPHA-2 standard, converted from ASCII into hex. For Austria (AT) this is `0x4154`, which results in `0x4154000000000000` as the value for the "ready" status.
@@ -19,7 +19,7 @@ The country-specific code is made of the country's code value following the ISO-
| `0x4154000000000002` | "SSCD temporary out of service"
For at least one receipt, it was not possible to receive the signature from an allocated SSCD. Thus, the security mechanism has been put into "signature creation device out of service" mode. Regardless of whether an allocated SSCD is available again or not, the mode remains in place until, via zero receipt, all previous receipts can be signed. If this mode is activated, an out of service signature, in accordance with the RKSV, is generated and sent back. | 1.0 |
| `0x4154000000000004` | "SSCD permanently out of service"
The status "SSCD temporary out of service" was activated more than 48h ago. Thus a FinanzOnline notification has been generated.
For conduct and termination of this mode, see "SSCD temporary out of service". | 1.0 |
| `0x4154000000000008` | "subsequent entry activated"
At least one receipt has been transferred with a subsequent entry flag. In order to finalize the subsequent entry and leave the mode, it is necessary to generate a zero receipt. This zero receipt signs and secures the preliminary receipts accordingly to the RKSV. | 1.0 |
-| `0x4154000000000010` | "monthly report due"
If the latest monthly or annual report are is in the current month, the service will signal this. This status does not impact the signature conduct of the service; it is merely an indicative notification. | 1.0 |
+| `0x4154000000000010` | "monthly report due"
If the latest monthly or annual report is in the current month, the service will signal this. This status does not impact the signature conduct of the service; it is merely an indicative notification. | 1.0 |
| `0x4154000000000020` | "annual report due"
Same conduct as for "monthly report due" | 1.0 |
| `0x4154000000000040` | "message / notification pending"
A status message and/or FinanzOnline notification is ready for collection.
Using a zero receipt, the messages can be retrieved and archived or processed in bookkeeping. | 1.0 |
| `0x4154000000000080` | "backup SSCD in use"
The receipt was signed by a signature creation unit configured for backup use. | 1.1.17248 |
@@ -41,7 +41,7 @@ For Austria (AT) the country code is `0x4154`. Thus, the value for an unknown ft
| `0x4154000000000000` | "unknown type of receipt for AT"
This receipt is processed like a cash transaction with RKSV requirement. | 1.0 |
| `0x4154000000000001` | "Cash transaction with RKSV requirement for AT"
The fiskaltrust decision tree is being run through, and, if needed, the signature process is started and the cumulative counter adjusted respectively.
An example of a signature being needed is an "other service" paid for with a "credit card".
An example of a case where no signature is needed is a receipt with only "no own sales" on it which has been paid for by "credit card". | 1.0 |
| `0x4154000000000002` | "zero receipt"
Charge items block (ftChargeItems) as well as pay items block (ftPayItems) are empty.
The "zero receipt" can be used to test operability by collecting a service status notification, such as an out-of-service notification for FinanzOnline. | 1.0 |
-| `0x4154000000000003` | "initial operation receipt"
The request is only valid as a zero receipt. The initial operation procedure is started. When using fiskaltrust.SecuritymMechansimsPlus, the receipt will also be checked for correctness. | 1.0 |
+| `0x4154000000000003` | "initial operation receipt"
The request is only valid as a zero receipt. The initial operation procedure is started. When using fiskaltrust.SecurityMechanismsPlus, the receipt will also be checked for correctness. | 1.0 |
| `0x4154000000000004` | "out of operation receipt"
The procedure to take the service out of operation is started.
The request is only valid as a zero receipt. When using the fiskaltrust.Carefree package, the receipt will also be checked for correctness, and the notification to the "FinanzOnline" will be performed automatically in the background. | 1.0 |
| `0x4154000000000005` | "monthly receipt"
The procedure for the creation of the monthly receipt is started. The request is only valid as a zero receipt. | 1.0 |
| `0x4154000000000006` | "annual receipt"
The procedure for the creation of the annual receipt is started.
The request is only valid as a zero receipt. When using the fiskaltrust.Carefree package, the receipt will also be checked for correctness, and the notification to the "FinanzOnline" will be performed automatically in the background. | 1.0 |
@@ -54,7 +54,7 @@ For Austria (AT) the country code is `0x4154`. Thus, the value for an unknown ft
| `0x415400000000000D` | "protocol"
Simple protocol function. The data sets that need to be logged can be transferred in the field ftReceiptCaseData in manufacturer-specific JSON format. For example, opening the cash drawer or changing master data. | 1.0 |
| `0x415400000000000E` | "Internal / material consumption"
For example recording breakages or own consumption. | 1.0 |
| `0x415400000000000F` | "sales in an online shop, telephone-/fax orders"
Through the cash revenue law, sales from online shops and similar are exempted, even if these have been paid by credit card or comparable means of payments with RKSV requirement but not paid on business premises. As a cash transaction, the issued receipt comes with a recording requirement in accordance with §131 BAO and needs to be processed in bookkeeping. | 1.0 |
-| `0x4154000000000010` | "foreign sales"
Foreign sales do not have an RKSV-requirement. To be used when something sold in an other country. As a cash transaction, the issued receipt comes with a recording requirement in accordance with §131 BAO and need to be processed in bookkeeping. Foreign requirements, for example in connection with receipt generation or cash register requirements, have to be taken into account. | 1.0 |
+| `0x4154000000000010` | "foreign sales"
Foreign sales do not have an RKSV-requirement. To be used when something sold in another country. As a cash transaction, the issued receipt comes with a recording requirement in accordance with §131 BAO and need to be processed in bookkeeping. Foreign requirements, for example in connection with receipt generation or cash register requirements, have to be taken into account. | 1.0 |
@@ -191,7 +191,7 @@ This table expands on the values provided in the table ["Type of Signature: ftSi
|----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|
| `0x4154000000000000` | unknown | 1.0 |
| `0x4154000000000001` | signature according to RKSV | 1.0 |
-| `0x4154000000000002` | Archiving required according to RKSV or BAO §132.
E.g. notification of collective receipt after failure, initial receipt, monthly receipt, etc.. | 1.0 |
+| `0x4154000000000002` | Archiving required according to RKSV or BAO §132.
E.g. notification of collective receipt after failure, initial receipt, monthly receipt, etc. | 1.0 |
| `0x4154000000000003` | FinanzOnline notification | 1.0 |
diff --git a/poscreators/middleware-doc/middleware-at-rksv/terminology/terminology.md b/poscreators/middleware-doc/middleware-at-rksv/terminology/terminology.md
index 1fcc7ca..734c63f 100644
--- a/poscreators/middleware-doc/middleware-at-rksv/terminology/terminology.md
+++ b/poscreators/middleware-doc/middleware-at-rksv/terminology/terminology.md
@@ -24,4 +24,4 @@ This table expands on the descriptions of all general terms and abbreviations pr
| fiskaltrust.SignatureBox | The fiskaltrust.SignatureBox can be addressed with the uniform interface (fiskaltrust.iPOS) via SOAP, REST, TCP/IP and RS232 and is provided as an external hardware box. |
| fiskaltrust.SignatureCloud | The fiskaltrust.SignatureCloud can be addressed using the uniform interface(fiskaltrust.iPOS) via REST and is hosted in the cloud. |
-*Table 17. Defintion of Terms and Abbreviations (AT - RKSVO)*
+*Table 17. Definition of Terms and Abbreviations (AT - RKSVO)*
diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md
index 2e781f6..8f01302 100644
--- a/poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md
+++ b/poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md
@@ -11,7 +11,7 @@ As the Middleware abstracts processes and data over multiple markets/countries,
## Format
-Every case that is sent to the middleware, or every Item that is being returned from the middleware is based upon this tagging system. For the tagging system we are using hex based numbers since they make things like, flagging and having a consistend numbering scheme easier.
+Every case that is sent to the middleware, or every Item that is being returned from the middleware is based upon this tagging system. For the tagging system we are using hex based numbers since they make things like, flagging and having a consistent numbering scheme easier.
The overall format is built up of 4 sections:
@@ -23,5 +23,5 @@ _CCCC_vIII_gggg_xxxx
|----------------------|-----------------------------------------------------------------------------------------------------|
|CCCC|(e.g 4245): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. BE = 4245) |
|vIII|(e.g. 2000): This section is for versioning the tagging system (currently v2) and for future use |
-|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will live the overall semantical meaning of a type the same. (e.g. voiding of a receipt)|
+|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will leave the overall semantical meaning of a type the same. (e.g. voiding of a receipt)|
|xxxx|(e.g. 0001): The last category is usually case specific but always consists of 4 numbers |
\ No newline at end of file
diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/service-status-ftstate.md b/poscreators/middleware-doc/middleware-be/reference-tables/service-status-ftstate.md
index c6a5677..1742c12 100644
--- a/poscreators/middleware-doc/middleware-be/reference-tables/service-status-ftstate.md
+++ b/poscreators/middleware-doc/middleware-be/reference-tables/service-status-ftstate.md
@@ -15,11 +15,11 @@ version 2
#### gggg_gggg - global tagging/flag
| **Value** | **Description** | **Middleware Version** |
|----------------------|-----------------------------------------------------------------------------------------------------|---------------------|
-| `0000_0001 ` | **Security Mechanism is out Out of Operation**
Queue is not started or already stopped. | 1.3.45 |
+| `0000_0001 ` | **Security Mechanism is out of Operation**
Queue is not started or already stopped. | 1.3.45 |
| `0000_0002 ` | **SCU (Signature Creation Unit) temporary out of service**
For at least one receipt, it was not possible to receive the signature from an allocated SCU, therefore the security mechanism has been put into "signature creation device out of service" mode. Regardless of whether an allocated SCU is available again or not, the mode remains in place until a ZeroReceipt cleans up the state and takes the market specific action required.| 1.3.45 |
| `0000_0008 ` | **Deferred Queue Mode / Late Signing Mode is active**
When the cash register doesn’t reach the queue, it queues up the receipt requests while continuing to do business. Also, with a major failure of the cash register or a power outage, handwritten paper receipts are queued up while continuing to do business. After getting back to a full functional state, these queued-up ReceiptRequests are sent to the queue, having the original cbReceiptMoment of the business case and ReceiptCase tagged/flagged with 0001 (Deferred Queue / Late Signing) or 0008 (Handwritten).
A result of this is a marker within the ftState, which can be resolved via ZeroReceipt. The reason for the marker is a mismatch between processed time along the receipt chain and a manual event to clean up the state and maybe notify 3rd parties of an outage. | 1.3.45 |
| `0000_0040 ` | **Message Pending**
Middleware/Queue is a headless background service, but there are situations where communication with the cashier/operator or the cash register is necessary. For example, if the last daily closing was missed or if a special condition related to the signature creation unit or service happened. This is the moment when the message pending flag is set by the middleware, which should be signalled to the cashier by the POS system. By executing a ZeroReceipt, the cashier can read the message or instruction on the printed or displayed receipt.
Related to local regulations, this receipt may be stored/archived with/for bookkeeping purposes; if this is the case, this is also visualized. | 1.3.45 |
-| `0000_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClsoing to clear persistent changes in business data and also changes in the business period. | 1.3.45 |
+| `0000_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 1.3.45 |
| `EEEE_EEEE ` | **Error**
Something went wrong while processing the last request. QueueItem exists but didn’t reach the state of a ReceiptItem and didn’t consume a ftReceiptNumber within the chain. Error reason is shown within the responded ftSignatureItems.
This happens, for example, if the ReceiptCase is not recognized or is wrong. | 1.3.45 |
| `FFFF_FFFF ` | **Fail**
Something went wrong while processing the last request, and nothing persisted within the Queue. Fail reason is shown within the responded ftSignatureItems.
This happens, for example, when the flag ReceiptRequest is used after a communication outage, and no properly processed item is found. | 1.3.45 |
diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-receipt-ftreceiptcase.md
index 5473455..9dd0e43 100644
--- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-receipt-ftreceiptcase.md
+++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-receipt-ftreceiptcase.md
@@ -30,7 +30,7 @@ version 2
| `0` | Receipt | A basic receipt that is generated as part of a POS sale. A receipt usually serves as proof of payment. The receipt is used after the transaction is done (if goods are received). This is the usual process that is done at a POS. |
| `1` | Invoice | An invoice is generated for those cases where payment isn't handled immediately. |
| `2` | DailyOperations | This category contains receipt cases that the Middleware requires for various downstream processes (e.g. book keeping) |
-| `3` | Log | Logs can be used for storing / securing events that need are needed for additional processing or downstream processes. (e.g. log for cash drawer opened) |
+| `3` | Log | Logs can be used for storing / securing events that are needed for additional processing or downstream processes. (e.g. log for cash drawer opened) |
| `4` | Lifecycle | These operations are used for changing the overall state of the Middleware. Depending on the local regulations these receipts are handed over as part of a notification (e.g. FinanzOnline) |
@@ -41,7 +41,7 @@ version 2
| `0000` | **Unknown type for country-code "BE"**
This receipt case is handled like a "pos-receipt" (`0001 `). See below: | 1.3.45 |
| `0001` | **POS receipt**
Represents the main kind of receipt processed by a POS system. Creates a turnover and/or a change in the amount of cash in the till or similar operations.
Use the `ftChargeItems` and `ftPayItems` to hand over details about goods, services and payments for processing. The `ftChargeItems` and `ftPayItems` should contain the full final state of the receipt. | 1.3.45 |
| `0002` | **Payment transfer receipt type**
| 1.3.45 |
-| `0003` | **Point-Of-Sale receipt without fiscalization**
Obligation or with exeption on fiscalization regulation | 1.3.45 |
+| `0003` | **Point-Of-Sale receipt without fiscalization**
Obligation or with exception on fiscalization regulation | 1.3.45 |
| `0004` | **E-Commerce receipt type**
| 1.3.45 |
| `0005` | **Delivery Note**
| 1.3.45 |
| `1000` | **Unknown invoice type**
| 1.3.45 |
@@ -69,16 +69,16 @@ version 2
| **Value** | **Description** | **Middleware version** |
|-----------|-----------------|-------------------------|
-| `0001` | **Process as Late Signing Receipt**
The cash register lost connection to the queue and processed receipts without communicating with the queue. All processed receipts marked with the hint “Security mechanism not reachable” need to be sent to the queue with this maker. | 1.3.45 |
+| `0001` | **Process as Late Signing Receipt**
The cash register lost connection to the queue and processed receipts without communicating with the queue. All processed receipts marked with the hint “Security mechanism not reachable” need to be sent to the queue with this marker. | 1.3.45 |
| `0002` | **Training Receipt** | 1.3.45 |
| `0004` | **IsVoid**
Marks Receipt as Void to previous one. Mark lineitems also as IsVoid to signal clear data. | 1.3.45 |
| `0008` | **Process as Handwritten Receipt**
During a power outage, the Cash register will not work, and the merchant hands out handwritten receipts. These handwritten receipts need to be sent to the Security Mechanism by using this flag. | 1.3.45 |
| `0010` | **IssuerIsSmallBusiness**
Businesses below a country-specific size in revenue need not declare VAT.
With this marker, the receipt shows no VAT, all prices are gross, and a country-specific hint must be printed. | 1.3.45 |
-| `0020` | **ReceiverIsBusiness **
Specific data need to be placed onto the receipt. | 1.3.45 |
-| `0040` | **ReceiverIsKnown**
Characteristics related to VAT taxes are given. For example, Name, Adress, VAT-ID, other local info. | 1.3.45 |
+| `0020` | **ReceiverIsBusiness**
Specific data need to be placed onto the receipt. | 1.3.45 |
+| `0040` | **ReceiverIsKnown**
Characteristics related to VAT taxes are given. For example, Name, Address, VAT-ID, other local info. | 1.3.45 |
| `0080` | **IsSaleInForeignCountry**
| 1.3.45 |
| `0100` | **IsReturn/IsRefund**
Marks Receipt as Return of good or service. | 1.3.45 |
-| `0800` | **Group by Position-Number / 100**
100 = first position, 101 first subitem, 102 second subitem.
The sum of all chargeitems within a position must count toward the total receipt amount.
If the quantity and amount are 0,00, the quantity and amount will not be visualized for this line on the digital receipt. Independent if main our subitem. | 1.3.45 |
+| `0800` | **Group by Position-Number / 100**
100 = first position, 101 first subitem, 102 second subitem.
The sum of all chargeitems within a position must count toward the total receipt amount.
If the quantity and amount are 0,00, the quantity and amount will not be visualized for this line on the digital receipt. Independent if main or subitem. | 1.3.45 |
| `8000` | **ReceiptRequest**
If you don’t receive a response, try this flag first before taking any other action.
This will return a stored result for example in case of a timeout when cashregister calls queue. | 1.3.45 |
diff --git a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-service-ftchargeitemcase.md
index 4e09a77..db26d5c 100644
--- a/poscreators/middleware-doc/middleware-be/reference-tables/type-of-service-ftchargeitemcase.md
+++ b/poscreators/middleware-doc/middleware-be/reference-tables/type-of-service-ftchargeitemcase.md
@@ -36,13 +36,13 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm
| `0` | **Unknown type of service**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.45 |
| `1` | **Delivery (supply of goods)**
| 1.3.45 |
| `2` | **Other service (supply of service)**
| 1.3.45 |
-| `3` | **Tip**
For owner use V=0 to 7, related to total amount
For Employee use V=8, Not Taxable(as of 1.1.2022, this is calculated with 5%). | 1.3.45 |
+| `3` | **Tip**
For owner use V=0 to 7, related to total amount
For Employee use V=8, Not Taxable (as of 1.1.2022, this is calculated with 5%). | 1.3.45 |
| `4` | **Voucher**
For Single-Use-Voucher use V=0 to 7
For Multi-Use-Voucher use V=8, Not Taxable
Voucher Sale is a positive (+) amount.
Voucher Redeem is a negative (-) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this for Multi-Use-Voucher, use PayItem instead, with ShowInChargeItems flag. For Single-Use-Voucher, apply the ShowInPayItems flag to visualize it similar to payment and to keep the total amount unreduced. | 1.3.45 |
| `5` | **Catalog service**
| 1.3.45 |
| `6` | **Not own sales / Agency business**
| 1.3.45 |
| `7` | **Own Consumption**
| 1.3.45 |
| `8` | **Grant**
For Unreal Grant use V=0 to 7
For Real Grant use V=8 |1.3.45|
-| `9` | **Receivable**
Receiveable creation is negative (-) amount
Receiveable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.45|
+| `9` | **Receivable**
Receivable creation is negative (-) amount
Receivable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.45|
| `A` | **Cash Transfer**
Cash Transfer to till is positive (+) amount
Cash Transfer from till is negative (-) amount.
Only useable with V=8, Not Taxable.
IsVoid can be applied to reverse amounts|1.3.45|
#### NN - nature of VAT
@@ -54,13 +54,13 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm
| `20` | **Not Subject**
2x can be used to specify more country specific details.| *NS (N2) marker mandatory
[20] not subject to VAT pursuant to articles from 7 to 7-septies of Presidential Decree 633/72
[21] not subject, other cases| 1.3.45 |
| `30` | **Exempt**
3x| *BE (N4) marker mandatory
[30] exempt | 1.3.45 |
| `40` | **Margin scheme**
Do not print/show VAT rate and amount on receipt/invoice.
4x can be used to specify more country specific details. | *RM (N5) marker mandatory
[40] margin scheme / VAT not shown on the invoice | 1.3.45 |
-| `50` | **Reverse charge**
5x | *AL (N6) marker mandatory
[50] reverse charge - disposal of scrap and other salvage materials
[51] reverse charge - sale of gold and silver pursuant to law 7/2000 as well as used jewelery to OPO
[52] reverse charge - subcontracting in the construction sector
[53] reverse charge - sale of buildings
[54] reverse charge - supply of mobile phones
[55] reverse charge - supply of electronic products
[56] reverse charge - performance in the construction sector and related sectors
[57] reverse charge - energy sector transactions
[58] reverse charge - other cases | 1.3.45 |
+| `50` | **Reverse charge**
5x | *AL (N6) marker mandatory
[50] reverse charge - disposal of scrap and other salvage materials
[51] reverse charge - sale of gold and silver pursuant to law 7/2000 as well as used jewellery to OPO
[52] reverse charge - subcontracting in the construction sector
[53] reverse charge - sale of buildings
[54] reverse charge - supply of mobile phones
[55] reverse charge - supply of electronic products
[56] reverse charge - performance in the construction sector and related sectors
[57] reverse charge - energy sector transactions
[58] reverse charge - other cases | 1.3.45 |
| `60` | **VAT paid in other EU country**
6x| (N7) marker mandatory
[60] paid in another EU country (provision of telecommunications, broadcasting and electronic services pursuant to art. 7-octies, paragraph 1 letter a, b, art. 74-sexies of Presidential Decree 633/72) | 1.3.45 |
| `70` | **VAT distribution**
7x | *VI (VI) is a fiscal VAT (IVA) regime that certain retailers can adopt. It allows the global registration of the daily takings amount without distinguishing the individual VAT rates. It only ever applies to goods. | 1.3.45 |
| `80` | **Excluded**
8x| *EE (N1) marker mandatory
[80] excluded pursuant to art. 15 of Presidential Decree 633/72 | 1.3.45 |
-#### lll - local taggin/flag
+#### lll - local tagging/flag
TBD
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/cash-register-integration/cash-register-integration.md b/poscreators/middleware-doc/middleware-de-kassensichv/cash-register-integration/cash-register-integration.md
index 25e5313..f6271d7 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/cash-register-integration/cash-register-integration.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/cash-register-integration/cash-register-integration.md
@@ -13,12 +13,12 @@ Like in all other supported countries, the German Middleware returns all complia
We generally recommend using QR codes wherever possible to reduce the amount of required paper.
### Printing receipts with QR codes
-As the Middleware returns additional data in the `ftSignatures` field that is e.g. used by ourselves to create the DSFinV-K, we introduced a flag for the `ftSignatureFormat` field that signalizes if a signature needs to be printed or is optional. More details about this flag are describede [here](../reference-tables/type-of-signature-ftsignatureformat.md)
+As the Middleware returns additional data in the `ftSignatures` field that is e.g. used by ourselves to create the DSFinV-K, we introduced a flag for the `ftSignatureFormat` field that signalizes if a signature needs to be printed or is optional. More details about this flag are described [here](../reference-tables/type-of-signature-ftsignatureformat.md)
Hence, when printing QR codes, all returned signatures should be printed that **do not** have the _ftSignatureFormatFlag_ `0x0000000000010000` ("printing is optional").
### Printing receipts without QR codes
-For supporting cases where the used printer does not support QR codes, the Middleware's returened signatures also contain all required information in textual form. The following items from the response's `ftSignatures` property needs to be printed:
+For supporting cases where the used printer does not support QR codes, the Middleware's returned signatures also contain all required information in textual form. The following items from the response's `ftSignatures` property needs to be printed:
| **Description** | **Caption** | **ftSignatureType** |
| --------------------------------------- | ----------------------- | -------------------- |
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/cash-register-integration/receipt-sequences-creation.md b/poscreators/middleware-doc/middleware-de-kassensichv/cash-register-integration/receipt-sequences-creation.md
index cb0b5d3..b1a66c4 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/cash-register-integration/receipt-sequences-creation.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/cash-register-integration/receipt-sequences-creation.md
@@ -118,7 +118,7 @@ Multiple POS-Systems are involved in the business action and only one of them is
- Restaurant/Wellness/Hotel using different POS-Systems; one system is used for final invoice creation
- Membership cards/vouchers with multiple POS-Systems involved
-### Option A: ChargeItems collected via "internal" queue are payed at an external system or queue
+### Option A: ChargeItems collected via "internal" queue are paid at an external system or queue
#### How to use
@@ -130,9 +130,9 @@ ChargeItems are collected via ftReceiptCase 'Info-internal' or 'Info-order'. 'cb
([click to expand](media/chargeitem-internal-payment-external.svg))
-A couple checks-in in a hotel for one night. They have a beer at the hotel bar, which uses a different POS-System than at the reception. The couple wishes the consumption to be paid via accomodation invoice at checkout. Therefore, an 'info-internal' is used instead of a 'POS receipt'. 'cbArea' is used to provide the information about the connected business action using the room number as unique identifier.
+A couple checks in to a hotel for one night. They have a beer at the hotel bar, which uses a different POS-System than at the reception. The couple wishes the consumption to be paid via accommodation invoice at checkout. Therefore, an 'info-internal' is used instead of a 'POS receipt'. 'cbArea' is used to provide the information about the connected business action using the room number as unique identifier.
-### Option B: ChargeItems collected at an external system or queue are payed at the internal queue
+### Option B: ChargeItems collected at an external system or queue are paid at the internal queue
#### How to use
@@ -190,7 +190,7 @@ In this example, we are using the payitem option for managing the multi-purpose
After charging the bracelet, the customer redeems the voucher in several cases. A positive amount of 'ftPayItemCase' `0x444500000000000D` gets converted to a multi-purpose voucher redemption. The negative amount of payment indicates the credit available after the redemption.
-In the last business action, the customer wants to have his credit payed out. The positive amount of 'ftPayItemCase' `0x444500000000000D` is set to the actual credit value so that the payment amount is zero.
+In the last business action, the customer wants to have his credit paid out. The positive amount of 'ftPayItemCase' `0x444500000000000D` is set to the actual credit value so that the payment amount is zero.
#### Code examples
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/cash-register-integration/single-receipt-creation.md b/poscreators/middleware-doc/middleware-de-kassensichv/cash-register-integration/single-receipt-creation.md
index b5c602c..57bf6c2 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/cash-register-integration/single-receipt-creation.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/cash-register-integration/single-receipt-creation.md
@@ -42,7 +42,7 @@ The up-counting transaction number defined in TR-03153 is responded behind the h
**For the implicit flow, ADDITIONALLY the start time of the first transaction of the business-action (e.g. start time of the first order) has to be printed on the receipt as the start-time of the action.**
-This value is returned by the `Scenario description and graphical illustration (click to expand)
Scenario description and graphical illustration (click to expand)
Delta Transaction (click to expand)
Scenario description (click to expand)
optional |
+| _StoreTemporaryExportFiles_ | Enables storage of temporary export files in the `fiskaltrust/service/Exports` folder (Values: `true` / `false`) | `false`
optional |
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-databases/mysql.md b/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-databases/mysql.md
index 3242ae2..465bb82 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-databases/mysql.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-databases/mysql.md
@@ -19,4 +19,4 @@ This storage provider is particularly suitable for setting up fail-safe systems
| --------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
| _connectionstring_ | MySQL connection string to the database system | mandatory |
| _TarFileExportMode_ | `All` Enables the automatic TAR File export from the TSE on the Queue level. `None` Disables the automatic TAR File export from the TSE on the Queue level. `Erased` TAR files are only exported and saved when they could be deleted from the TSE. (Values: `All` / `None` / `Erased`) | optional (default: `All`) |
-| _StoreTemporaryExportFiles_ | Enables storage of temporaty export files in the `fiskaltrust/service/Exports` folder (Values: `true` / `false`) | `false`
optional |
+| _StoreTemporaryExportFiles_ | Enables storage of temporary export files in the `fiskaltrust/service/Exports` folder (Values: `true` / `false`) | `false`
optional |
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-databases/sqlite.md b/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-databases/sqlite.md
index 1763006..1c64c8b 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-databases/sqlite.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-databases/sqlite.md
@@ -17,4 +17,4 @@ This storage provider is particularly suitable for the simple construction of sm
| Name | Description | **Default Value**
**Mandatory Field** |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
| _TarFileExportMode_ | `All` Enables the automatic TAR File export from the TSE on the Queue level. `None` Disables the automatic TAR File export from the TSE on the Queue level. `Erased` TAR files are only exported and saved when they could be deleted from the TSE. (Values: `All` / `None` / `Erased`) | optional (default: `All`) |
-| _StoreTemporaryExportFiles_ | Enables storage of temporaty export files in the `fiskaltrust/service/Exports` folder (Values: `true` / `false`) | `false`
optional |
+| _StoreTemporaryExportFiles_ | Enables storage of temporary export files in the `fiskaltrust/service/Exports` folder (Values: `true` / `false`) | `false`
optional |
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-platforms/linux.md b/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-platforms/linux.md
index c9c11a3..e096b21 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-platforms/linux.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/on-premise-platforms/linux.md
@@ -58,7 +58,7 @@ If you haven't already decided for a communication technology, we strongly recom
### REST limitations
When using REST, the HTTP endpoint slightly differs from the Windows version, as the version prefix cannot be included because of the mentioned Mono issues. Hence, a REST endpoint on Linux must be called like this: `http://localhost:1500/a4c4e466-721a-4011-a9a5-a23827a21b45/sign`:
-- The `/json/v1` part needs to be omited
+- The `/json/v1` part needs to be omitted
- The URL must be written in lower case
- When calling the _journal_ endpoint, the `type`, `from` and `to` GET parameters must be included
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/scu/epson.md b/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/scu/epson.md
index a12bd8b..fede1e4 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/scu/epson.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/operation-modes/scu/epson.md
@@ -51,5 +51,5 @@ Please pay attention to the case-sensitive use of the parameters.
| Problem | Possible cause | Solution |
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| **The Developer TSE requests a self-test even though it has been unplugged and plugged in** | | Please perform a factory reset on the Developer TSE according to the manufacturer's instructions. |
-| **Connection with the USB Epson TSE directly plugged in into the cash register cannot be established** | | Please ensure that the Epson driver for the TSE has been installed. You can downlod the driver from the following URL: https://download.epson-biz.com/modules/pos/?page=prod&pcat=51&pid=6397.
This does not apply to the use of the USB Epson TSE in an Epson server. |
+| **Connection with the USB Epson TSE directly plugged into the cash register cannot be established** | | Please ensure that the Epson driver for the TSE has been installed. You can download the driver from the following URL: https://download.epson-biz.com/modules/pos/?page=prod&pcat=51&pid=6397.
This does not apply to the use of the USB Epson TSE in an Epson server. |
| **USB Epson TSE do not work on a printer.** | For use on the printer, Epson only supports MicroSD Epson TSE. | Please use MicroSD Epson TSE for the use on the printer. |
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/procedural-documentation/dsfinv-k-generation.md b/poscreators/middleware-doc/middleware-de-kassensichv/procedural-documentation/dsfinv-k-generation.md
index 0ff4f9e..c334b59 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/procedural-documentation/dsfinv-k-generation.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/procedural-documentation/dsfinv-k-generation.md
@@ -210,7 +210,7 @@ Each subitem is described in the table below:
| `Z_ERSTELLUNG` | Date of the cashpoint closing | ISO 8601 und RFC3339 date | Automatically filled by fiskaltrust from `cbReceiptMoment` of the daily closing receipt |
| `Z_NR` | Nr. of the cashpoint closing | Integer | Automatically created and filled by fiskaltrust |
| `BON_ID` | Action-ID | String (40) | Automatically created and filled by fiskaltrust (`ftReceiptIdentification`) |
-| `ABRECHNUNGSKREIS` | Connection criterion of the assignment | String (50) | Mandatory, filled by fiskaltrust. by using `cbReceiptReference` and `cPreviousReceiptReference` to determine the value. |
+| `ABRECHNUNGSKREIS` | Connection criterion of the assignment | String (50) | Mandatory, filled by fiskaltrust. by using `cbReceiptReference` and `cbPreviousReceiptReference` to determine the value. |
#### File: Bonkopf_Zahlarten (datapayment.csv)
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/procedural-documentation/receipt-validation.md b/poscreators/middleware-doc/middleware-de-kassensichv/procedural-documentation/receipt-validation.md
index 1471312..dbf43c4 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/procedural-documentation/receipt-validation.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/procedural-documentation/receipt-validation.md
@@ -7,7 +7,7 @@ title: DSFinV-K Receipt Validation (Release TBA)
## Receipt Validation
-The Fiskaltrust Receipt Validation provides the possibility to validate customer implementations based on queue data. The test cases are defined according to the DSFinV‑K specification. It provides customers with a tool to easily adjust their implementation to fully comply with the requirements set by the tax authorities.
+The fiskaltrust Receipt Validation provides the possibility to validate customer implementations based on queue data. The test cases are defined according to the DSFinV‑K specification. It provides customers with a tool to easily adjust their implementation to fully comply with the requirements set by the tax authorities.
Below you will find a list of all possible errors, including detailed descriptions of how to resolve them.
@@ -30,7 +30,7 @@ This error indicates that at least one receipt exists for the specified business
## Error-5010
-### Vat Cross Net Missmatch
+### Vat Cross Net Mismatch
#### Description
This error indicates an inconsistency between Net, VAT, and Gross amounts on a receipt line item.
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md
index 464ee9a..f8ead1f 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md
@@ -12,4 +12,4 @@ This table expands on the values provided in table of Chapter ["Type of Journal:
| `0x4445000000000000` | Status information for QueueDE | 1.3.1 |
| `0x4445000000000001` | .TAR-File from TSE device. Please note that the TSE's log messages are automatically exported during each daily closing receipt and deleted on the device afterwards for performance reasons. Hence, this export will only return the log files created since the last daily closing. To get the full TAR file, please use the type `0x4445000000000003`. | 1.3.1 |
| `0x4445000000000002` | DSFinV-K export as .ZIP file | 1.3.6 |
-| `0x4445000000000003` | .TAR-File from Middleware database. This export should be prefered over `0x4445000000000001` generally, as it's populated from the already exported data and therefore faster than the direct TSE export. | 1.3.11 |
+| `0x4445000000000003` | .TAR-File from Middleware database. This export should be preferred over `0x4445000000000001` generally, as it's populated from the already exported data and therefore faster than the direct TSE export. | 1.3.11 |
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md
index 5f8b3cd..8f7dbd3 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md
@@ -21,7 +21,7 @@ This table expands on the values provided in table [ftPayItemCase in General Par
| `0x4445000000000009` | Other Bank transfer | Unbar | 1.3- |
| `0x444500000000000A` | Internal / material consumption | Keine | 1.3- |
| `0x444500000000000B` | Change in national currency | Bar | 1.3- |
-| `0x444500000000000C` | Change in foreign curreny | Bar | 1.3- |
+| `0x444500000000000C` | Change in foreign currency | Bar | 1.3- |
| `0x444500000000000D` | Voucher
not taxable
DSFinV-K transformation required. UST_Schluessel=5. Negative amount gets converted to GV_TYP=MehrzweckgutscheinKauf. Positive amount gets converted to TYP_GV=MehrzweckgutscheinEinlösung. amount=-amount. In case of void-receipt everything is returned. | Keine | 1.3 |
| `0x444500000000000E` | Receivable
not taxable
DSFinV-K transformation required. UST_Schluessel=5. Negative amount gets converted to GV_TYP=Forderungsauflösung. Positive amount gets converted to GV_TYP=Forderungsentstehung. amount=-amount. In case of cancellation-receipt the +/- sign has to be returned. | Keine | 1.3- |
| `0x444500000000000F` | Down payment
not taxable
DSFinV-K transformation required. UST_Schluessel=5. Negative amount gets converted to GV_TYP=Anzahlungseinstellung. Positive amount gets converted to GV_TYP=Anzahlungsaufloesung. amount=-amount. In case of void-receipt everything is returned. Not valid for taxable down payments, where it is clearly defined what the service is for. | Keine | 1.3- |
diff --git a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md
index b322e51..a64cbf9 100644
--- a/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md
+++ b/poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md
@@ -13,16 +13,16 @@ For Germany (DE), the country code is `0x4445`. Thus, the value of an unknown `f
|-----------|-----------------|-----------------------------------------------------|-------------------------|
| `0x4445000000000000` | **Unknown type for country-code "DE"**
This receipt case is handled like a "pos-receipt" (`0x4445000000000001`). See below: | Beleg
Kassenbeleg-V1 | 1.3- |
| `0x4445000000000001` | **Pos-receipt**
Represents the main kind of receipt processed by a POS-System. Creates a turnover and/or change in the amount of cash in the till or similar operations.
Use the `ftChargeItems` and `ftPayItems` to hand over details for processing. The `ftChargeItems` and `ftPayItems` should contain the full final state of the receipt. Turnover and cash amount is increased by the final pos-receipt content, intermediate start-transaction, update-transaction and delta-transaction content doesn't influence turnover and cash amount. The pos-receipt case can be used with **implicit and explicit** flow.
The duration of the represented action is calculated using the minimum (start time) and maximum (end time) of datetimes over `ftReceiptRequest`/`ftChargeItems`/`ftPayItems`
The BON_TYP (Beleg) of DSFinV-K can be overwritten by an `ftReceiptCaseFlag`. | Beleg
Kassenbeleg-V1 | 1.3- |
-| `0x4445000000000002` | **Zero-receipt**
Used for communication test and functional test of the fiskaltrust.SecurityMechanism. In addition, the response also contains a detailed status information about the used TSE-Device. TSE data is herefore loaded and that may cause a long running request.
The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.
This receipt case works **only** with **implicit** flow. Using it without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception.
If you want to end an ongoing transaction without turnover (e.g. all items on a receipt are voided) then please use a regular `ftReceiptCase`.
Informations returned in the response are:
| [none]
SonstigerVorgang | 1.3- |
+| `0x4445000000000002` | **Zero-receipt**
Used for communication test and functional test of the fiskaltrust.SecurityMechanism. In addition, the response also contains a detailed status information about the used TSE-Device. TSE data is herefore loaded and that may cause a long running request.
The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.
This receipt case works **only** with **implicit** flow. Using it without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception.
If you want to end an ongoing transaction without turnover (e.g. all items on a receipt are voided) then please use a regular `ftReceiptCase`.
Informations returned in the response are:
| [none]
SonstigerVorgang | 1.3- |
| `0x4445000000000003` | **Initial operation receipt / start-receipt**
The request is only valid with the same property requirements as a zero-receipt. It initialises a new fiskaltrust.SecurityMechanism including the used TSE in the background. Depending on the TSE-Type used, this includes different actions.
On successful initialisation, a notification is created which includes the queue-id, scu-id, certificate/public-key, tse-serialnumber=hash(public-key). This notification needs to be reported to the tax administration.
The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.
This receipt case works **only** with **implicit flow**. calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3- |
| `0x4445000000000004` | **Out of operation receipt / stop-receipt**
The request is only valid with the same property requirements as a zero-receipt. It is disabling the fiskaltrust.SecurityMechanism including the deactivation of the client ID used in the TSE for the current queue.
**This request also permanently disables the connected TSE, which is an irreversible action on production TSEs**. Optionally, one can avoid deactivating the TSE using the ftReceiptCaseFlag `0x0000000001000000` (see below).
On successful deactivation, a notification is created which includes the queue-id, scu-id, certificate/public-key, tse-serialnumber=hash(public-key). This notification needs to be reported to tax administration.
The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.
This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3- |
| `0x4445000000000005` | **Monthly-closing**
This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. This is a zero-receipt. It is recommended to send this receipt at the end of each month to define the time of the accounting closure. | [none]
SonstigerVorgang | 1.3- |
| `0x4445000000000006` | **Yearly-closing**
This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
SonstigerVorgang | 1.3- |
| `0x4445000000000007` | **Daily-closing**
This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. This is a zero-receipt. It is required to send this receipt at the end of each day to define the time of the accounting closure. | [none]
SonstigerVorgang | 1.3- |
-| `0x4445000000000008` | **Start-transaction-receipt**
Starts a new, unfinished action. Use `ftChargeItems` and `ftPayItems` to hand over already known details for the final receipt. Using the same `cbReceiptReferece` in further calls connects the action items.
This receipt case works **only** with **explicit flow**. Calling with the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
[empty] | 1.3- |
-| `0x4445000000000009` | **Update-transaction-receipt**
Updates an ongoing action. Use `ftChargeItems` and `ftPayItems` to hand over all details for the final receipt. Using the same `cbReceiptReferece` in further calls connects the action items.
This receipt case works **only** with **explicit flow**. Calling with the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
[empty] | 1.3- |
-| `0x444500000000000A` | **Delta-transaction-receipt**
Updates an ongoing action. Use `ftChargeItems` and `ftPayItems` to hand over changes for the final receipt. Using the same `cbReceiptReferece` in further calls connects the action items.
This receipt case works **only** on **explicit flow**. Calling with the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
[empty] | 1.3- |
-| `0x444500000000000B` | **Fail-transaction-receipt**
Fails an ongoing transaction. It tries to finish either one or multiple open transaction (accepts fail, continue on fail) and clears the `cbReceiptReferece <-> Transaction-ID` relations.
To close **single open transactions**, an **explicit** fail-transaction receipt needs to be used. The open transaction needs to be referenced via `cbReceiptReference`. If this value is not provided or no open transaction exists, the fiskaltrust.Middleware will throw an exception and the call will fail.
To close **multiple open transactions**, an **implicit** fail-transaction receipt needs to be sent. This can also be used to close transactions that were not opened by the fiskaltrust.Middleware (e.g. manually during testing). The transaction numbers that should be closed need to be passed via JSON in `ftReceiptCaseData`, using the array property `CurrentStartedTransactionNumbers` (e.g.: `ftReceiptCaseData: "{\"CurrentStartedTransactionNumbers\": [1, 2, 3]}"`). `cbReceiptReference` must be empty in this case, otherwise the fiskaltrust.Middleware will throw an exception and return an error. | AVBelegabbruch
Kassenbeleg-V1 | 1.3- |
+| `0x4445000000000008` | **Start-transaction-receipt**
Starts a new, unfinished action. Use `ftChargeItems` and `ftPayItems` to hand over already known details for the final receipt. Using the same `cbReceiptReference` in further calls connects the action items.
This receipt case works **only** with **explicit flow**. Calling with the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
[empty] | 1.3- |
+| `0x4445000000000009` | **Update-transaction-receipt**
Updates an ongoing action. Use `ftChargeItems` and `ftPayItems` to hand over all details for the final receipt. Using the same `cbReceiptReference` in further calls connects the action items.
This receipt case works **only** with **explicit flow**. Calling with the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
[empty] | 1.3- |
+| `0x444500000000000A` | **Delta-transaction-receipt**
Updates an ongoing action. Use `ftChargeItems` and `ftPayItems` to hand over changes for the final receipt. Using the same `cbReceiptReference` in further calls connects the action items.
This receipt case works **only** on **explicit flow**. Calling with the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none]
[empty] | 1.3- |
+| `0x444500000000000B` | **Fail-transaction-receipt**
Fails an ongoing transaction. It tries to finish either one or multiple open transaction (accepts fail, continue on fail) and clears the `cbReceiptReference <-> Transaction-ID` relations.
To close **single open transactions**, an **explicit** fail-transaction receipt needs to be used. The open transaction needs to be referenced via `cbReceiptReference`. If this value is not provided or no open transaction exists, the fiskaltrust.Middleware will throw an exception and the call will fail.
To close **multiple open transactions**, an **implicit** fail-transaction receipt needs to be sent. This can also be used to close transactions that were not opened by the fiskaltrust.Middleware (e.g. manually during testing). The transaction numbers that should be closed need to be passed via JSON in `ftReceiptCaseData`, using the array property `CurrentStartedTransactionNumbers` (e.g.: `ftReceiptCaseData: "{\"CurrentStartedTransactionNumbers\": [1, 2, 3]}"`). `cbReceiptReference` must be empty in this case, otherwise the fiskaltrust.Middleware will throw an exception and return an error. | AVBelegabbruch
Kassenbeleg-V1 | 1.3- |
| `0x444500000000000C` | **B2B-invoice**
The BON_TYP (Beleg) of DSFinV-K can be overwritten by an `ftReceiptCaseFlag`. | Beleg
Kassenbeleg-V1 | 1.3- |
| `0x444500000000000D` | **B2C-invoice**
The BON_TYP (Beleg) of DSFinV-K can be overwritten by an `ftReceiptCaseFlag`. | Beleg
Kassenbeleg-V1 | 1.3- |
| `0x444500000000000E` | **Info-invoice**
| AVRechnung
Kassenbeleg-V1 | 1.3- |
@@ -64,5 +64,5 @@ This table expands on the values provided in table [ftReceiptCaseFlag in General
| 0x0000000020000000 | **Requests to close transactions that are marked open in the Middleware's database, but not open in the TSE.**
This flag applies to _daily-closing_ and _zero_ receipts (if in failed mode) only and can be used to unblock the closing in case of a power- or network failure that lead to an inconsistent state between Middleware and TSE (e.g. when the TSE finished a transaction, but the network failed and the Middleware could not read the result). It should not be used per default to avoid hiding recurring issues of this kind. | 1.3.16 (Support for zero receipts was added in version 1.3.23) |
| 0x0000000040000000 | **Requests to bypass TSEInfo-Call on initiate-SCU-switch**
This flag applies to _initiate-SCU-switch_ only and can be used to unblock the SCU-switch in case the Middleware is not able to recover from "SSCD failed" mode but the TSEInfo-Call is successful. It should not be used per default to avoid hiding recurring issues of this kind. | 1.3.47|
| 0x0000000100000000 | **Implicit Transaction.**
No Start-Transaction call to the `Sign` method is required, it is done implicitly. If the unique identifier set in property `cbReceiptReference` already started a transaction, this will throw an exception. | 1.3.0 |
-| 0x0000000200000000 | **Close transactions on daily closing**
This receiptCaseFlag for Daily-Closing will closes all open transactions on the TSE when a dailyclosing is done. This solves the problem of open transactions from other queues, in a setup where muultiple queues are used on one tse. | 1.3.75 |
+| 0x0000000200000000 | **Close transactions on daily closing**
This receiptCaseFlag for Daily-Closing will closes all open transactions on the TSE when a dailyclosing is done. This solves the problem of open transactions from other queues, in a setup where multiple queues are used on one tse. | 1.3.75 |
| 0x0000800000000000 | **Receipt request**
Used to retrieve an already processed receipt from the fiskaltrust.Middleware using the `cbReceiptReference` field. The `cbTerminalID` can also be included in this request. ChargeItems and PayItems must be exactly the same as in the requested receipt. If a matching receipt is found, its content will be returned. If no matching receipt is found, a null value is returned. This may be necessary if a communication problem occurs while the fiskaltrust.Middleware processes a request. | 1.3- |
diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-es/reference-tables/reference-tables.md
index 965178b..00e313a 100644
--- a/poscreators/middleware-doc/middleware-es/reference-tables/reference-tables.md
+++ b/poscreators/middleware-doc/middleware-es/reference-tables/reference-tables.md
@@ -11,7 +11,7 @@ As the Middleware abstracts processes and data over multiple markets/countries,
## Format
-Every case that is sent to the middleware, or every Item that is being returned from the middleware is based upon this tagging system. For the tagging system we are using hex based numbers since they make things like, flagging and having a consistend numbering scheme easier.
+Every case that is sent to the middleware, or every Item that is being returned from the middleware is based upon this tagging system. For the tagging system we are using hex based numbers since they make things like, flagging and having a consistent numbering scheme easier.
The overall format is built up of 4 sections:
@@ -23,5 +23,5 @@ _CCCC_vIII_gggg_xxxx
|----------------------|-----------------------------------------------------------------------------------------------------|
|CCCC|(e.g 4553): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. ES = 4553) |
|vIII|(e.g. 2000): This section is for versioning the tagging system (currently v2) and for future use |
-|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will live the overall semantical meaning of a type the same. (e.g. voiding of a receipt)|
+|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will leave the overall semantical meaning of a type the same. (e.g. voiding of a receipt)|
|xxxx|(e.g. 0001): The last category is usually case specific but always consists of 4 numbers |
\ No newline at end of file
diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/service-status-ftstate.md b/poscreators/middleware-doc/middleware-es/reference-tables/service-status-ftstate.md
index fcb3261..d8d2b6e 100644
--- a/poscreators/middleware-doc/middleware-es/reference-tables/service-status-ftstate.md
+++ b/poscreators/middleware-doc/middleware-es/reference-tables/service-status-ftstate.md
@@ -15,11 +15,11 @@ version 2
#### gggg_gggg - global tagging/flag
| **Value** | **Description** | **Middleware Version** |
|----------------------|-----------------------------------------------------------------------------------------------------|---------------------|
-| `0000_0001 ` | **Security Mechanism is out Out of Operation**
Queue is not started or already stopped. | 1.3.45 |
+| `0000_0001 ` | **Security Mechanism is out of Operation**
Queue is not started or already stopped. | 1.3.45 |
| `0000_0002 ` | **SCU (Signature Creation Unit) temporary out of service**
For at least one receipt, it was not possible to receive the signature from an allocated SCU, therefore the security mechanism has been put into "signature creation device out of service" mode. Regardless of whether an allocated SCU is available again or not, the mode remains in place until a ZeroReceipt cleans up the state and takes the market specific action required.| 1.3.45 |
| `0000_0008 ` | **Deferred Queue Mode / Late Signing Mode is active**
When the cash register doesn’t reach the queue, it queues up the receipt requests while continuing to do business. Also, with a major failure of the cash register or a power outage, handwritten paper receipts are queued up while continuing to do business. After getting back to a full functional state, these queued-up ReceiptRequests are sent to the queue, having the original cbReceiptMoment of the business case and ReceiptCase tagged/flagged with 0001 (Deferred Queue / Late Signing) or 0008 (Handwritten).
A result of this is a marker within the ftState, which can be resolved via ZeroReceipt. The reason for the marker is a mismatch between processed time along the receipt chain and a manual event to clean up the state and maybe notify 3rd parties of an outage. | 1.3.45 |
| `0000_0040 ` | **Message Pending**
Middleware/Queue is a headless background service, but there are situations where communication with the cashier/operator or the cash register is necessary. For example, if the last daily closing was missed or if a special condition related to the signature creation unit or service happened. This is the moment when the message pending flag is set by the middleware, which should be signalled to the cashier by the POS system. By executing a ZeroReceipt, the cashier can read the message or instruction on the printed or displayed receipt.
Related to local regulations, this receipt may be stored/archived with/for bookkeeping purposes; if this is the case, this is also visualized. | 1.3.45 |
-| `0000_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClsoing to clear persistent changes in business data and also changes in the business period. | 1.3.45 |
+| `0000_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 1.3.45 |
| `EEEE_EEEE ` | **Error**
Something went wrong while processing the last request. QueueItem exists but didn’t reach the state of a ReceiptItem and didn’t consume a ftReceiptNumber within the chain. Error reason is shown within the responded ftSignatureItems.
This happens, for example, if the ReceiptCase is not recognized or is wrong. | 1.3.45 |
| `FFFF_FFFF ` | **Fail**
Something went wrong while processing the last request, and nothing persisted within the Queue. Fail reason is shown within the responded ftSignatureItems.
This happens, for example, when the flag ReceiptRequest is used after a communication outage, and no properly processed item is found. | 1.3.45 |
diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-receipt-ftreceiptcase.md
index 1d75bf7..899a742 100644
--- a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-receipt-ftreceiptcase.md
+++ b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-receipt-ftreceiptcase.md
@@ -30,7 +30,7 @@ version 2
| `0` | Receipt | A basic receipt that is generated as part of a POS sale. A receipt usually serves as proof of payment. The receipt is used after the transaction is done (if goods are received). This is the usual process that is done at a POS. |
| `1` | Invoice | An invoice is generated for those cases where payment isn't handled immediately. |
| `2` | DailyOperations | This category contains receipt cases that the Middleware requires for various downstream processes (e.g. book keeping) |
-| `3` | Log | Logs can be used for storing / securing events that need are needed for additional processing or downstream processes. (e.g. log for cash drawer opened) |
+| `3` | Log | Logs can be used for storing / securing events that are needed for additional processing or downstream processes. (e.g. log for cash drawer opened) |
| `4` | Lifecycle | These operations are used for changing the overall state of the Middleware. Depending on the local regulations these receipts are handed over as part of a notification (e.g. FinanzOnline) |
@@ -41,7 +41,7 @@ version 2
| `0000` | **Unknown type for country-code "ES"**
This receipt case is handled like a "pos-receipt" (`0001 `). See below: | 1.3.45 |
| `0001` | **POS receipt**
Represents the main kind of receipt processed by a POS system. Creates a turnover and/or a change in the amount of cash in the till or similar operations.
Use the `ftChargeItems` and `ftPayItems` to hand over details about goods, services and payments for processing. The `ftChargeItems` and `ftPayItems` should contain the full final state of the receipt. | 1.3.45 |
| `0002` | **Payment transfer receipt type**
| 1.3.45 |
-| `0003` | **Point-Of-Sale receipt without fiscalization**
Obligation or with exeption on fiscalization regulation | 1.3.45 |
+| `0003` | **Point-Of-Sale receipt without fiscalization**
Obligation or with exception on fiscalization regulation | 1.3.45 |
| `0004` | **E-Commerce receipt type**
| 1.3.45 |
| `0005` | **Delivery Note**
| 1.3.45 |
| `1000` | **Unknown invoice type**
| 1.3.45 |
@@ -69,16 +69,16 @@ version 2
| **Value** | **Description** | **Middleware version** |
|-----------|-----------------|-------------------------|
-| `0001` | **Process as Late Signing Receipt**
The cash register lost connection to the queue and processed receipts without communicating with the queue. All processed receipts marked with the hint “Security mechanism not reachable” need to be sent to the queue with this maker. | 1.3.45 |
+| `0001` | **Process as Late Signing Receipt**
The cash register lost connection to the queue and processed receipts without communicating with the queue. All processed receipts marked with the hint “Security mechanism not reachable” need to be sent to the queue with this marker. | 1.3.45 |
| `0002` | **Training Receipt** | 1.3.45 |
| `0004` | **IsVoid**
Marks Receipt as Void to previous one. Mark lineitems also as IsVoid to signal clear data. | 1.3.45 |
| `0008` | **Process as Handwritten Receipt**
During a power outage, the Cash register will not work, and the merchant hands out handwritten receipts. These handwritten receipts need to be sent to the Security Mechanism by using this flag. | 1.3.45 |
| `0010` | **IssuerIsSmallBusiness**
Businesses below a country-specific size in revenue need not declare VAT.
With this marker, the receipt shows no VAT, all prices are gross, and a country-specific hint must be printed. | 1.3.45 |
-| `0020` | **ReceiverIsBusiness **
Specific data need to be placed onto the receipt. | 1.3.45 |
-| `0040` | **ReceiverIsKnown**
Characteristics related to VAT taxes are given. For example, Name, Adress, VAT-ID, other local info. | 1.3.45 |
+| `0020` | **ReceiverIsBusiness**
Specific data need to be placed onto the receipt. | 1.3.45 |
+| `0040` | **ReceiverIsKnown**
Characteristics related to VAT taxes are given. For example, Name, Address, VAT-ID, other local info. | 1.3.45 |
| `0080` | **IsSaleInForeignCountry**
| 1.3.45 |
| `0100` | **IsReturn/IsRefund**
Marks Receipt as Return of good or service. | 1.3.45 |
-| `0800` | **Group by Position-Number / 100**
100 = first position, 101 first subitem, 102 second subitem.
The sum of all chargeitems within a position must count toward the total receipt amount.
If the quantity and amount are 0,00, the quantity and amount will not be visualized for this line on the digital receipt. Independent if main our subitem. | 1.3.45 |
+| `0800` | **Group by Position-Number / 100**
100 = first position, 101 first subitem, 102 second subitem.
The sum of all chargeitems within a position must count toward the total receipt amount.
If the quantity and amount are 0,00, the quantity and amount will not be visualized for this line on the digital receipt. Independent if main or subitem. | 1.3.45 |
| `8000` | **ReceiptRequest**
If you don’t receive a response, try this flag first before taking any other action.
This will return a stored result for example in case of a timeout when cashregister calls queue. | 1.3.45 |
diff --git a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-service-ftchargeitemcase.md
index a3e3566..0e154da 100644
--- a/poscreators/middleware-doc/middleware-es/reference-tables/type-of-service-ftchargeitemcase.md
+++ b/poscreators/middleware-doc/middleware-es/reference-tables/type-of-service-ftchargeitemcase.md
@@ -36,13 +36,13 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm
| `0` | **Unknown type of service**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.67 |
| `1` | **Delivery (supply of goods)**
| 1.3.67 |
| `2` | **Other service (supply of service)**
| 1.3.67 |
-| `3` | **Tip**
For owner use V=0 to 7, related to total amount
For Employee use V=8, Not Taxable(as of 1.1.2022, this is calculated with 5%). | 1.3.67 |
+| `3` | **Tip**
For owner use V=0 to 7, related to total amount
For Employee use V=8, Not Taxable (as of 1.1.2022, this is calculated with 5%). | 1.3.67 |
| `4` | **Voucher**
For Single-Use-Voucher use V=0 to 7
For Multi-Use-Voucher use V=8, Not Taxable
Voucher Sale is a positive (+) amount.
Voucher Redeem is a negative (-) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this for Multi-Use-Voucher, use PayItem instead, with ShowInChargeItems flag. For Single-Use-Voucher, apply the ShowInPayItems flag to visualize it similar to payment and to keep the total amount unreduced. | 1.3.67 |
| `5` | **Catalog service**
| 1.3.67 |
| `6` | **Not own sales / Agency business**
| 1.3.67 |
| `7` | **Own Consumption**
| 1.3.67 |
| `8` | **Grant**
For Unreal Grant use V=0 to 7
For Real Grant use V=8 |1.3.67|
-| `9` | **Receivable**
Receiveable creation is negative (-) amount
Receiveable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.67|
+| `9` | **Receivable**
Receivable creation is negative (-) amount
Receivable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.67|
| `A` | **Cash Transfer**
Cash Transfer to till is positive (+) amount
Cash Transfer from till is negative (-) amount.
Only useable with V=8, Not Taxable.
IsVoid can be applied to reverse amounts|1.3.67|
#### NN - nature of VAT
@@ -50,12 +50,12 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm
| **Value** | **Description** | **Spec. for Spanish reg.** | **Middleware Version** |
| -------------------- | -------------- | -------------- | ---------------------- |
| `00` | **usual VAT applies**
| | 1.3.67 |
-| `20` | **Not Subject**
2x can be used to specify more country specific details.| *NS (N2) marker mandatory
[20] not subject by aticles 7 and 14
[21] not subject, location rules| 1.3.67 |
+| `20` | **Not Subject**
2x can be used to specify more country specific details.| *NS (N2) marker mandatory
[20] not subject by articles 7 and 14
[21] not subject, location rules| 1.3.67 |
| `30` | **Exempt**
3x| *ES (N4) marker mandatory
[30] Exempt by article 20
[31] Exempt by article 21
[32] Exempt by article 22
[33] Exempt by article 23 and 24
[34] Exempt by article 25
[35] Exempt, other cases | 1.3.67 |
| `50` | **Reverse charge**
5x | *AL (N6) marker mandatory
[50] reverse charge | 1.3.67 |
-#### lll - local taggin/flag
+#### lll - local tagging/flag
TBD
diff --git a/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/installation/installation.md b/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/installation/installation.md
index 948e1ac..1fe0339 100644
--- a/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/installation/installation.md
+++ b/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/installation/installation.md
@@ -8,7 +8,7 @@ This chapter expands on the installation documentation covered in [Installing an
## fiskaltrust.Middleware
-In case of technical issue, it is advised to use the debug launcher in the Download section of the Portal.
+In case of a technical issue, it is advised to use the debug launcher in the Download section of the Portal.
For PosSystem using Windows [fiskaltrust_fiskaltrust.launcher-debug-v1.2.zip](https://github.com/fiskaltrust/interface-doc/files/12484702/fiskaltrust_fiskaltrust.launcher-debug-v1.2.zip)
diff --git a/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/reference-tables/reference-tables.md
index 112730d..77edb6e 100644
--- a/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/reference-tables/reference-tables.md
+++ b/poscreators/middleware-doc/middleware-fr-boi-tva-decla-30-10-30/reference-tables/reference-tables.md
@@ -43,7 +43,7 @@ The country-specific code is made of the country's code value following the ISO-
| `0x465200000000000B` | **Cash pay-out**
Same handling as payment prove
Chain and national numbering: P | |
| `0x465200000000000C` | **Payment transfer**
Switch between payment method, e.g. from cash to credit card
Sign: Yes
Chain and national numbering: P | |
| `0x465200000000000D` | **Internal / Material**
Sign: No
Chain and national numbering: no | |
-| `0x465200000000000E` | **Foreign sales**
Same handling as bill. To be used when something sold in an other country.
Sign: Yes
Chain und national numbering: B | |
+| `0x465200000000000E` | **Foreign sales**
Same handling as bill. To be used when something sold in another country.
Sign: Yes
Chain and national numbering: B | |
| `0x465200000000000F` | **Zero-Receipt**
Sign: Yes
Chain and national numbering: G
Details: A receipt with empty charge items block `ftChargeItem` and empty payment block `ftPayItem` which amounts to a total of "0". | |
| `0x4652000000000010` | **Start-Receipt**
Sign: Yes
Chain and national numbering: G | |
| `0x4652000000000011` | **Stop-Receipt**
Sign: Yes
Chain and national numbering: G | |
diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-gr/reference-tables/reference-tables.md
index abaa26d..2599e1e 100644
--- a/poscreators/middleware-doc/middleware-gr/reference-tables/reference-tables.md
+++ b/poscreators/middleware-doc/middleware-gr/reference-tables/reference-tables.md
@@ -11,7 +11,7 @@ As the Middleware abstracts processes and data over multiple markets/countries,
## Format
-Every case that is sent to the middleware, or every Item that is being returned from the middleware is based upon this tagging system. For the tagging system we are using hex based numbers since they make things like, flagging and having a consistend numbering scheme easier.
+Every case that is sent to the middleware, or every Item that is being returned from the middleware is based upon this tagging system. For the tagging system we are using hex based numbers since they make things like, flagging and having a consistent numbering scheme easier.
The overall format is built up of 4 sections:
@@ -23,5 +23,5 @@ _CCCC_vIII_gggg_xxxx
|----------------------|-----------------------------------------------------------------------------------------------------|
|CCCC|(e.g 4752): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. GR = 4752) |
|vIII|(e.g. 2000): This section is for versioning the tagging system (currently v2) and for future use |
-|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will live the overall semantical meaning of a type the same. (e.g. voiding of a receipt)|
+|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will leave the overall semantical meaning of a type the same. (e.g. voiding of a receipt)|
|xxxx|(e.g. 0001): The last category is usually case specific but always consists of 4 numbers |
\ No newline at end of file
diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/service-status-ftstate.md b/poscreators/middleware-doc/middleware-gr/reference-tables/service-status-ftstate.md
index 236438d..b447f17 100644
--- a/poscreators/middleware-doc/middleware-gr/reference-tables/service-status-ftstate.md
+++ b/poscreators/middleware-doc/middleware-gr/reference-tables/service-status-ftstate.md
@@ -5,7 +5,7 @@ title: 'Service Status: ftState'
# Service Status: ftState
-The table below describes it supported statuses for the ftState field following the Greek implementation. The ftState from this reference table and the general part of this documentation can be combined through the logic operator "OR". For example 0x4752_2000_0000_0010 (monthly report due) and 0x4752_2000_0000_0008 combined through OR results in 0x4752_2000_0000_0018.
+The table below describes the supported statuses for the ftState field following the Greek implementation. The ftState from this reference table and the general part of this documentation can be combined through the logic operator "OR". For example 0x4752_2000_0000_0010 (monthly report due) and 0x4752_2000_0000_0008 combined through OR results in 0x4752_2000_0000_0018.
The country-specific code is made of the country's code value following the ISO-3166-1-ALPHA-2 standard, converted from ASCII into hex. For Greece (GR) this is 0x4752, which results in 0x4752_2000_0000_0000 as the value for the "ready" status.
@@ -20,11 +20,11 @@ version 2
| **Value** | **Description** | **Middleware Version** |
|----------------------|-----------------------------------------------------------------------------------------------------|---------------------|
| `0000_0000 ` | Ready status. | 1.3.45 |
-| `0000_0001 ` | **Security Mechanism is out Out of Operation**
Queue is not started or already stopped. | 1.3.45 |
+| `0000_0001 ` | **Security Mechanism is out of Operation**
Queue is not started or already stopped. | 1.3.45 |
| `0000_0002 ` | **SCU (Signature Creation Unit) temporary out of service**
For at least one receipt, it was not possible to receive the signature from an allocated SCU, therefore the security mechanism has been put into "signature creation device out of service" mode. Regardless of whether an allocated SCU is available again or not, the mode remains in place until a ZeroReceipt cleans up the state and takes the market specific action required.| 1.3.45 |
| `0000_0008 ` | **Deferred Queue Mode / Late Signing Mode is active**
When the cash register doesn’t reach the queue, it queues up the receipt requests while continuing to do business. Also, with a major failure of the cash register or a power outage, handwritten paper receipts are queued up while continuing to do business. After getting back to a full functional state, these queued-up ReceiptRequests are sent to the queue, having the original cbReceiptMoment of the business case and ReceiptCase tagged/flagged with 0001 (Deferred Queue / Late Signing) or 0008 (Handwritten).
A result of this is a marker within the ftState, which can be resolved via ZeroReceipt. The reason for the marker is a mismatch between processed time along the receipt chain and a manual event to clean up the state and maybe notify 3rd parties of an outage. | 1.3.45 |
| `0000_0040 ` | **Message Pending**
Middleware/Queue is a headless background service, but there are situations where communication with the cashier/operator or the cash register is necessary. For example, if the last daily closing was missed or if a special condition related to the signature creation unit or service happened. This is the moment when the message pending flag is set by the middleware, which should be signalled to the cashier by the POS system. By executing a ZeroReceipt, the cashier can read the message or instruction on the printed or displayed receipt.
Related to local regulations, this receipt may be stored/archived with/for bookkeeping purposes; if this is the case, this is also visualized. | 1.3.45 |
-| `0000_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClsoing to clear persistent changes in business data and also changes in the business period. | 1.3.45 |
+| `0000_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 1.3.45 |
| `EEEE_EEEE ` | **Error**
Something went wrong while processing the last request. QueueItem exists but didn’t reach the state of a ReceiptItem and didn’t consume a ftReceiptNumber within the chain. Error reason is shown within the responded ftSignatureItems.
This happens, for example, if the ReceiptCase is not recognized or is wrong. | 1.3.45 |
| `FFFF_FFFF ` | **Fail**
Something went wrong while processing the last request, and nothing persisted within the Queue. Fail reason is shown within the responded ftSignatureItems.
This happens, for example, when the flag ReceiptRequest is used after a communication outage, and no properly processed item is found. | 1.3.45 |
diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-receipt-ftreceiptcase.md
index b425d00..fa81d20 100644
--- a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-receipt-ftreceiptcase.md
+++ b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-receipt-ftreceiptcase.md
@@ -30,7 +30,7 @@ version 2
| `0` | Receipt | A basic receipt that is generated as part of a POS sale. A receipt usually serves as proof of payment. The receipt is used after the transaction is done (if goods are received). This is the usual process that is done at a POS. |
| `1` | Invoice | An invoice is generated for those cases where payment isn't handled immediately. |
| `2` | DailyOperations | This category contains receipt cases that the Middleware requires for various downstream processes (e.g. book keeping) |
-| `3` | Log | Logs can be used for storing / securing events that need are needed for additional processing or downstream processes. (e.g. log for cash drawer opened) |
+| `3` | Log | Logs can be used for storing / securing events that are needed for additional processing or downstream processes. (e.g. log for cash drawer opened) |
| `4` | Lifecycle | These operations are used for changing the overall state of the Middleware. Depending on the local regulations these receipts are handed over as part of a notification (e.g. FinanzOnline) |
@@ -41,7 +41,7 @@ version 2
| `0000` | **Unknown type for country-code "GR"**
This receipt case is handled like a "pos-receipt" (`0001 `). See below: | 1.3.45 |
| `0001` | **POS receipt**
Represents the main kind of receipt processed by a POS system. Creates a turnover and/or a change in the amount of cash in the till or similar operations.
Use the `ftChargeItems` and `ftPayItems` to hand over details about goods, services and payments for processing. The `ftChargeItems` and `ftPayItems` should contain the full final state of the receipt. | 1.3.45 |
| `0002` | **Payment transfer receipt type**
| 1.3.45 |
-| `0003` | **Point-Of-Sale receipt without fiscalization**
Obligation or with exeption on fiscalization regulation | 1.3.45 |
+| `0003` | **Point-Of-Sale receipt without fiscalization**
Obligation or with exception on fiscalization regulation | 1.3.45 |
| `0004` | **E-Commerce receipt type**
| 1.3.45 |
| `0005` | **Delivery Note**
| 1.3.45 |
| `1000` | **Unknown invoice type**
| 1.3.45 |
@@ -69,16 +69,16 @@ version 2
| **Value** | **Description** | **Middleware version** |
|-----------|-----------------|-------------------------|
-| `0001` | **Process as Late Signing Receipt**
The cash register lost connection to the queue and processed receipts without communicating with the queue. All processed receipts marked with the hint “Security mechanism not reachable” need to be sent to the queue with this maker. | 1.3.45 |
+| `0001` | **Process as Late Signing Receipt**
The cash register lost connection to the queue and processed receipts without communicating with the queue. All processed receipts marked with the hint “Security mechanism not reachable” need to be sent to the queue with this marker. | 1.3.45 |
| `0002` | **Training Receipt** | 1.3.45 |
| `0004` | **IsVoid**
Marks Receipt as Void to previous one. Mark lineitems also as IsVoid to signal clear data. | 1.3.45 |
| `0008` | **Process as Handwritten Receipt**
During a power outage, the Cash register will not work, and the merchant hands out handwritten receipts. These handwritten receipts need to be sent to the Security Mechanism by using this flag. | 1.3.45 |
| `0010` | **IssuerIsSmallBusiness**
Businesses below a country-specific size in revenue need not declare VAT.
With this marker, the receipt shows no VAT, all prices are gross, and a country-specific hint must be printed. | 1.3.45 |
-| `0020` | **ReceiverIsBusiness **
Specific data need to be placed onto the receipt. | 1.3.45 |
-| `0040` | **ReceiverIsKnown**
Characteristics related to VAT taxes are given. For example, Name, Adress, VAT-ID, other local info. | 1.3.45 |
+| `0020` | **ReceiverIsBusiness**
Specific data need to be placed onto the receipt. | 1.3.45 |
+| `0040` | **ReceiverIsKnown**
Characteristics related to VAT taxes are given. For example, Name, Address, VAT-ID, other local info. | 1.3.45 |
| `0080` | **IsSaleInForeignCountry**
| 1.3.45 |
| `0100` | **IsReturn/IsRefund**
Marks Receipt as Return of good or service. | 1.3.45 |
-| `0800` | **Group by Position-Number / 100**
100 = first position, 101 first subitem, 102 second subitem.
The sum of all chargeitems within a position must count toward the total receipt amount.
If the quantity and amount are 0,00, the quantity and amount will not be visualized for this line on the digital receipt. Independent if main our subitem. | 1.3.45 |
+| `0800` | **Group by Position-Number / 100**
100 = first position, 101 first subitem, 102 second subitem.
The sum of all chargeitems within a position must count toward the total receipt amount.
If the quantity and amount are 0,00, the quantity and amount will not be visualized for this line on the digital receipt. Independent if main or subitem. | 1.3.45 |
| `8000` | **ReceiptRequest**
If you don’t receive a response, try this flag first before taking any other action.
This will return a stored result for example in case of a timeout when cashregister calls queue. | 1.3.45 |
diff --git a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-service-ftchargeitemcase.md
index fe919ff..a046f8c 100644
--- a/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-service-ftchargeitemcase.md
+++ b/poscreators/middleware-doc/middleware-gr/reference-tables/type-of-service-ftchargeitemcase.md
@@ -42,14 +42,14 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm
| `6` | **Not own sales / Agency business**
|
| `7` | **Own Consumption**
|
| `8` | **Grant**
For Unreal Grant use V=0 to 7
For Real Grant use V=8 |
-| `9` | **Receivable**
Receiveable creation is negative (-) amount
Receiveable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.67|
+| `9` | **Receivable**
Receivable creation is negative (-) amount
Receivable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.67|
| `A` | **Cash Transfer**
Cash Transfer to till is positive (+) amount
Cash Transfer from till is negative (-) amount.
Only useable with V=8, Not Taxable.
IsVoid can be applied to reverse amounts|1.3.67|
#### NN - nature of VAT
TBD
-#### lll - local taggin/flag
+#### lll - local tagging/flag
TBD
diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/operation-modes/on-premise-platforms/linux.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/operation-modes/on-premise-platforms/linux.md
index 38c51da..76a44b8 100644
--- a/poscreators/middleware-doc/middleware-it-registratore-telematico/operation-modes/on-premise-platforms/linux.md
+++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/operation-modes/on-premise-platforms/linux.md
@@ -3,7 +3,7 @@ slug: /poscreators/middleware-doc/italy/platforms/linux
title: Linux
---
-# fiskaltrust.Middleware for Linux and macOs
+# fiskaltrust.Middleware for Linux and macOS
Starting with version 1.3.45, it's possible to run the Italian Middleware on Linux. Just configure a CashBox and download the Launcher via the respective button in the CashBox overview. Like on Windows, the downloaded zip file contains scripts to install and test the Middleware. Other than that, no specific software needs to be installed as the Italian Middleware is running on the Launcher 2.0 which is self-contained and has no external dependencies.
diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/operation-modes/scu/epsonprinter.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/operation-modes/scu/epsonprinter.md
index b7756b2..40ab62b 100644
--- a/poscreators/middleware-doc/middleware-it-registratore-telematico/operation-modes/scu/epsonprinter.md
+++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/operation-modes/scu/epsonprinter.md
@@ -11,7 +11,7 @@ title: Epson-Printer
**Stable from version:** 1.3.45
-The _fiskaltrust.Middleware.SCU.IT.EpsonRTPrinter_ package connects the middleware with a Epson-Printer.
+The _fiskaltrust.Middleware.SCU.IT.EpsonRTPrinter_ package connects the middleware with an Epson-Printer.
### Parameters
diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/reference-tables.md
index 6194c93..d038d06 100644
--- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/reference-tables.md
+++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/reference-tables.md
@@ -11,7 +11,7 @@ As the Middleware abstracts processes and data over multiple markets/countries,
## Format
-Every case that is sent to the middleware, or every Item that is being returned from the middleware is based upon this tagging system. For the tagging system we are using hex based numbers since they make things like, flagging and having a consistend numbering scheme easier.
+Every case that is sent to the middleware, or every Item that is being returned from the middleware is based upon this tagging system. For the tagging system we are using hex based numbers since they make things like, flagging and having a consistent numbering scheme easier.
The overall format is built up of 4 sections:
@@ -23,7 +23,7 @@ _CCCC_vIII_gggg_xxxx
|----------------------|-----------------------------------------------------------------------------------------------------|
|CCCC|(e.g 4954): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. IT = 4954) |
|vIII|(e.g. 2000): This section is for versioning the tagging system (currently v2) and for future use |
-|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will live the overall semantical meaning of a type the same. (e.g. voiding of a receipt)|
+|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will leave the overall semantical meaning of a type the same. (e.g. voiding of a receipt)|
|xxxx|(e.g. 0001): The last category is usually case specific but always consists of 4 numbers |
diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/service-status-ftstate.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/service-status-ftstate.md
index c30fb3f..1875231 100644
--- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/service-status-ftstate.md
+++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/service-status-ftstate.md
@@ -15,11 +15,11 @@ version 2
#### gggg_gggg - global tagging/flag
| **Value** | **Description** | **Middleware Version** |
|----------------------|-----------------------------------------------------------------------------------------------------|---------------------|
-| `0000_0001 ` | **Security Mechanism is out Out of Operation**
Queue is not started or already stopped. | 1.3.45 |
+| `0000_0001 ` | **Security Mechanism is out of Operation**
Queue is not started or already stopped. | 1.3.45 |
| `0000_0002 ` | **SCU (Signature Creation Unit) temporary out of service**
For at least one receipt, it was not possible to receive the signature from an allocated SCU, therefore the security mechanism has been put into "signature creation device out of service" mode. Regardless of whether an allocated SCU is available again or not, the mode remains in place until a ZeroReceipt cleans up the state and takes the market specific action required.| 1.3.45 |
| `0000_0008 ` | **Deferred Queue Mode / Late Signing Mode is active**
When the cash register doesn’t reach the queue, it queues up the receipt requests while continuing to do business. Also, with a major failure of the cash register or a power outage, handwritten paper receipts are queued up while continuing to do business. After getting back to a full functional state, these queued-up ReceiptRequests are sent to the queue, having the original cbReceiptMoment of the business case and ReceiptCase tagged/flagged with 0001 (Deferred Queue / Late Signing) or 0008 (Handwritten).
A result of this is a marker within the ftState, which can be resolved via ZeroReceipt. The reason for the marker is a mismatch between processed time along the receipt chain and a manual event to clean up the state and maybe notify 3rd parties of an outage. | 1.3.45 |
| `0000_0040 ` | **Message Pending**
Middleware/Queue is a headless background service, but there are situations where communication with the cashier/operator or the cash register is necessary. For example, if the last daily closing was missed or if a special condition related to the signature creation unit or service happened. This is the moment when the message pending flag is set by the middleware, which should be signalled to the cashier by the POS system. By executing a ZeroReceipt, the cashier can read the message or instruction on the printed or displayed receipt.
Related to local regulations, this receipt may be stored/archived with/for bookkeeping purposes; if this is the case, this is also visualized. | 1.3.45 |
-| `0000_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClsoing to clear persistent changes in business data and also changes in the business period. | 1.3.45 |
+| `0000_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 1.3.45 |
| `EEEE_EEEE ` | **Error**
Something went wrong while processing the last request. QueueItem exists but didn’t reach the state of a ReceiptItem and didn’t consume a ftReceiptNumber within the chain. Error reason is shown within the responded ftSignatureItems.
This happens, for example, if the ReceiptCase is not recognized or is wrong. | 1.3.45 |
| `FFFF_FFFF ` | **Fail**
Something went wrong while processing the last request, and nothing persisted within the Queue. Fail reason is shown within the responded ftSignatureItems.
This happens, for example, when the flag ReceiptRequest is used after a communication outage, and no properly processed item is found. | 1.3.45 |
diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-receipt-ftreceiptcase.md
index a8e1047..bce561d 100644
--- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-receipt-ftreceiptcase.md
+++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-receipt-ftreceiptcase.md
@@ -41,7 +41,7 @@ version 2
| `0000` | **Unknown type for country-code "IT"**
This receipt case is handled like a "pos-receipt" (`0001 `). See below: | 1.3.45 |
| `0001` | **POS receipt**
Represents the main kind of receipt processed by a POS system. Creates a turnover and/or a change in the amount of cash in the till or similar operations.
Use the `ftChargeItems` and `ftPayItems` to hand over details about goods, services and payments for processing. The `ftChargeItems` and `ftPayItems` should contain the full final state of the receipt. | 1.3.45 |
| `0002` | **Payment transfer receipt type**
| 1.3.45 |
-| `0003` | **Point-Of-Sale receipt without fiscalization**
Obligation or with exeption on fiscalization regulation | 1.3.45 |
+| `0003` | **Point-Of-Sale receipt without fiscalization**
Obligation or with exception on fiscalization regulation | 1.3.45 |
| `0004` | **E-Commerce receipt type**
| 1.3.45 |
| `0005` | **Delivery Note**
| 1.3.45 |
| `1000` | **Unknown invoice type**
| 1.3.45 |
@@ -74,8 +74,8 @@ version 2
| `0004` | **IsVoid**
Marks Receipt as Void to previous one. Mark lineitems also as IsVoid to signal clear data. | 1.3.45 |
| `0008` | **Process as Handwritten Receipt**
During a power outage, the Cash register will not work, and the merchant hands out handwritten receipts. These handwritten receipts need to be sent to the Security Mechanism by using this flag. | 1.3.45 |
| `0010` | **IssuerIsSmallBusiness**
Businesses below a country-specific size in revenue need not declare VAT.
With this marker, the receipt shows no VAT, all prices are gross, and a country-specific hint must be printed. | 1.3.45 |
-| `0020` | **ReceiverIsBusiness **
Specific data need to be placed onto the receipt. | 1.3.45 |
-| `0040` | **ReceiverIsKnown**
Characteristics related to VAT taxes are given. For example, Name, Adress, VAT-ID, other local info. | 1.3.45 |
+| `0020` | **ReceiverIsBusiness**
Specific data need to be placed onto the receipt. | 1.3.45 |
+| `0040` | **ReceiverIsKnown**
Characteristics related to VAT taxes are given. For example, Name, Address, VAT-ID, other local info. | 1.3.45 |
| `0080` | **IsSaleInForeignCountry**
| 1.3.45 |
| `0100` | **IsReturn/IsRefund**
Marks Receipt as Return of good or service. | 1.3.45 |
| `0800` | **Group by Position-Number / 100**
100 = first position, 101 first subitem, 102 second subitem.
The sum of all chargeitems within a position must count toward the total receipt amount.
If the quantity and amount are 0,00, the quantity and amount will not be visualized for this line on the digital receipt. Independent if main our subitem. | 1.3.45 |
@@ -87,5 +87,5 @@ version 2
| **Value** | **Description** | **Middleware version** |
|-----------|-----------------|-------------------------|
| `001` | **X Report**
(Only for RT Devices - only for Zero receipts) Prints the X report containing the snapshot of sales totals and activities | 1.3.45 |
-| `002` | **Print as non fiscal document**
(Only for RT Devices - only for Protocol receipts) Prints the protcol receipt | 1.3.67 |
+| `002` | **Print as non fiscal document**
(Only for RT Devices - only for Protocol receipts) Prints the protocol receipt | 1.3.67 |
diff --git a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-service-ftchargeitemcase.md
index 1f6ffff..a863228 100644
--- a/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-service-ftchargeitemcase.md
+++ b/poscreators/middleware-doc/middleware-it-registratore-telematico/reference-tables/type-of-service-ftchargeitemcase.md
@@ -42,8 +42,8 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm
| `6` | **Not own sales / Agency business**
| 1.3.45 |
| `7` | **Own Consumption**
| 1.3.45 |
| `8` | **Grant**
For Unreal Grant use V=0 to 7
For Real Grant use V=8 |1.3.45|
-| `9` | **Receivable**
Receiveable creation is negative (-) amount
Receiveable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.45|
-| `A` | **Cash Transfer**
Cash Transfer to till is positive (+) amount
Cash Transfer from till is negative (-) amount.
Only useable with V=8, Not Taxable.
IsVoid can be applied to reverse amounts|1.3.45|
+| `9` | **Receivable**
Receivable creation is negative (-) amount
Receivable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.45|
+| `A` | **Cash Transfer**
Cash Transfer to till is positive (+) amount
Cash Transfer from till is negative (-) amount.
Only usable with V=8, Not Taxable.
IsVoid can be applied to reverse amounts|1.3.45|
#### NN - nature of VAT
@@ -54,13 +54,13 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm
| `20` | **Not Subject**
2x can be used to specify more country specific details.| *NS (N2) marker mandatory
[20] not subject to VAT pursuant to articles from 7 to 7-septies of Presidential Decree 633/72
[21] not subject, other cases| 1.3.45 |
| `30` | **Exempt**
3x| *ES (N4) marker mandatory
[30] exempt | 1.3.45 |
| `40` | **Margin scheme**
Do not print/show VAT rate and amount on receipt/invoice.
4x can be used to specify more country specific details. | *RM (N5) marker mandatory
[40] margin scheme / VAT not shown on the invoice | 1.3.45 |
-| `50` | **Reverse charge**
5x | *AL (N6) marker mandatory
[50] reverse charge - disposal of scrap and other salvage materials
[51] reverse charge - sale of gold and silver pursuant to law 7/2000 as well as used jewelery to OPO
[52] reverse charge - subcontracting in the construction sector
[53] reverse charge - sale of buildings
[54] reverse charge - supply of mobile phones
[55] reverse charge - supply of electronic products
[56] reverse charge - performance in the construction sector and related sectors
[57] reverse charge - energy sector transactions
[58] reverse charge - other cases | 1.3.45 |
+| `50` | **Reverse charge**
5x | *AL (N6) marker mandatory
[50] reverse charge - disposal of scrap and other salvage materials
[51] reverse charge - sale of gold and silver pursuant to law 7/2000 as well as used jewellery to OPO
[52] reverse charge - subcontracting in the construction sector
[53] reverse charge - sale of buildings
[54] reverse charge - supply of mobile phones
[55] reverse charge - supply of electronic products
[56] reverse charge - performance in the construction sector and related sectors
[57] reverse charge - energy sector transactions
[58] reverse charge - other cases | 1.3.45 |
| `60` | **VAT paid in other EU country**
6x| (N7) marker mandatory
[60] paid in another EU country (provision of telecommunications, broadcasting and electronic services pursuant to art. 7-octies, paragraph 1 letter a, b, art. 74-sexies of Presidential Decree 633/72) | 1.3.45 |
| `70` | **VAT distribution**
7x | *VI (VI) is a fiscal VAT (IVA) regime that certain retailers can adopt. It allows the global registration of the daily takings amount without distinguishing the individual VAT rates. It only ever applies to goods. | 1.3.45 |
| `80` | **Excluded**
8x| *EE (N1) marker mandatory
[80] excluded pursuant to art. 15 of Presidential Decree 633/72 | 1.3.45 |
-#### lll - local taggin/flag
+#### lll - local tagging/flag
None
diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/reference-tables.md b/poscreators/middleware-doc/middleware-pt/reference-tables/reference-tables.md
index 5b5cc15..afefa6a 100644
--- a/poscreators/middleware-doc/middleware-pt/reference-tables/reference-tables.md
+++ b/poscreators/middleware-doc/middleware-pt/reference-tables/reference-tables.md
@@ -11,7 +11,7 @@ As the Middleware abstracts processes and data over multiple markets/countries,
## Format
-Every case that is sent to the middleware, or every Item that is being returned from the middleware is based upon this tagging system. For the tagging system we are using hex based numbers since they make things like, flagging and having a consistend numbering scheme easier.
+Every case that is sent to the middleware, or every Item that is being returned from the middleware is based upon this tagging system. For the tagging system we are using hex based numbers since they make things like, flagging and having a consistent numbering scheme easier.
The overall format is built up of 4 sections:
@@ -23,5 +23,5 @@ _CCCC_vIII_gggg_xxxx
|----------------------|-----------------------------------------------------------------------------------------------------|
|CCCC|(e.g 5054): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. PT = 5054) |
|vIII|(e.g. 2000): This section is for versioning the tagging system (currently v2) and for future use |
-|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will live the overall semantical meaning of a type the same. (e.g. voiding of a receipt)|
+|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will leave the overall semantical meaning of a type the same. (e.g. voiding of a receipt)|
|xxxx|(e.g. 0001): The last category is usually case specific but always consists of 4 numbers |
\ No newline at end of file
diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/service-status-ftstate.md b/poscreators/middleware-doc/middleware-pt/reference-tables/service-status-ftstate.md
index bb8d082..393fc68 100644
--- a/poscreators/middleware-doc/middleware-pt/reference-tables/service-status-ftstate.md
+++ b/poscreators/middleware-doc/middleware-pt/reference-tables/service-status-ftstate.md
@@ -15,11 +15,11 @@ version 2
#### gggg_gggg - global tagging/flag
| **Value** | **Description** | **Middleware Version** |
|----------------------|-----------------------------------------------------------------------------------------------------|---------------------|
-| `0000_0001 ` | **Security Mechanism is out Out of Operation**
Queue is not started or already stopped. | 1.3.45 |
+| `0000_0001 ` | **Security Mechanism is out of Operation**
Queue is not started or already stopped. | 1.3.45 |
| `0000_0002 ` | **SCU (Signature Creation Unit) temporary out of service**
For at least one receipt, it was not possible to receive the signature from an allocated SCU, therefore the security mechanism has been put into "signature creation device out of service" mode. Regardless of whether an allocated SCU is available again or not, the mode remains in place until a ZeroReceipt cleans up the state and takes the market specific action required.| 1.3.45 |
| `0000_0008 ` | **Deferred Queue Mode / Late Signing Mode is active**
When the cash register doesn’t reach the queue, it queues up the receipt requests while continuing to do business. Also, with a major failure of the cash register or a power outage, handwritten paper receipts are queued up while continuing to do business. After getting back to a full functional state, these queued-up ReceiptRequests are sent to the queue, having the original cbReceiptMoment of the business case and ReceiptCase tagged/flagged with 0001 (Deferred Queue / Late Signing) or 0008 (Handwritten).
A result of this is a marker within the ftState, which can be resolved via ZeroReceipt. The reason for the marker is a mismatch between processed time along the receipt chain and a manual event to clean up the state and maybe notify 3rd parties of an outage. | 1.3.45 |
| `0000_0040 ` | **Message Pending**
Middleware/Queue is a headless background service, but there are situations where communication with the cashier/operator or the cash register is necessary. For example, if the last daily closing was missed or if a special condition related to the signature creation unit or service happened. This is the moment when the message pending flag is set by the middleware, which should be signalled to the cashier by the POS system. By executing a ZeroReceipt, the cashier can read the message or instruction on the printed or displayed receipt.
Related to local regulations, this receipt may be stored/archived with/for bookkeeping purposes; if this is the case, this is also visualized. | 1.3.45 |
-| `0000_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClsoing to clear persistent changes in business data and also changes in the business period. | 1.3.45 |
+| `0000_0100 ` | **DailyClosing due**
When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.
DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 1.3.45 |
| `EEEE_EEEE ` | **Error**
Something went wrong while processing the last request. QueueItem exists but didn’t reach the state of a ReceiptItem and didn’t consume a ftReceiptNumber within the chain. Error reason is shown within the responded ftSignatureItems.
This happens, for example, if the ReceiptCase is not recognized or is wrong. | 1.3.45 |
| `FFFF_FFFF ` | **Fail**
Something went wrong while processing the last request, and nothing persisted within the Queue. Fail reason is shown within the responded ftSignatureItems.
This happens, for example, when the flag ReceiptRequest is used after a communication outage, and no properly processed item is found. | 1.3.45 |
diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-receipt-ftreceiptcase.md b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-receipt-ftreceiptcase.md
index a8c76cb..7d1aafc 100644
--- a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-receipt-ftreceiptcase.md
+++ b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-receipt-ftreceiptcase.md
@@ -30,7 +30,7 @@ version 2
| `0` | Receipt | A basic receipt that is generated as part of a POS sale. A receipt usually serves as proof of payment. The receipt is used after the transaction is done (if goods are received). This is the usual process that is done at a POS. |
| `1` | Invoice | An invoice is generated for those cases where payment isn't handled immediately. |
| `2` | DailyOperations | This category contains receipt cases that the Middleware requires for various downstream processes (e.g. book keeping) |
-| `3` | Log | Logs can be used for storing / securing events that need are needed for additional processing or downstream processes. (e.g. log for cash drawer opened) |
+| `3` | Log | Logs can be used for storing / securing events that are needed for additional processing or downstream processes. (e.g. log for cash drawer opened) |
| `4` | Lifecycle | These operations are used for changing the overall state of the Middleware. Depending on the local regulations these receipts are handed over as part of a notification (e.g. FinanzOnline) |
@@ -41,7 +41,7 @@ version 2
| `0000` | **Unknown type for country-code "PT"**
This receipt case is handled like a "pos-receipt" (`0001 `). See below: | 1.3.45 |
| `0001` | **POS receipt**
Represents the main kind of receipt processed by a POS system. Creates a turnover and/or a change in the amount of cash in the till or similar operations.
Use the `ftChargeItems` and `ftPayItems` to hand over details about goods, services and payments for processing. The `ftChargeItems` and `ftPayItems` should contain the full final state of the receipt. | 1.3.45 |
| `0002` | **Payment transfer receipt type**
| 1.3.45 |
-| `0003` | **Point-Of-Sale receipt without fiscalization**
Obligation or with exeption on fiscalization regulation | 1.3.45 |
+| `0003` | **Point-Of-Sale receipt without fiscalization**
Obligation or with exception on fiscalization regulation | 1.3.45 |
| `0004` | **E-Commerce receipt type**
| 1.3.45 |
| `0005` | **Delivery Note**
| 1.3.45 |
| `1000` | **Unknown invoice type**
| 1.3.45 |
@@ -69,16 +69,16 @@ version 2
| **Value** | **Description** | **Middleware version** |
|-----------|-----------------|-------------------------|
-| `0001` | **Process as Late Signing Receipt**
The cash register lost connection to the queue and processed receipts without communicating with the queue. All processed receipts marked with the hint “Security mechanism not reachable” need to be sent to the queue with this maker. | 1.3.45 |
+| `0001` | **Process as Late Signing Receipt**
The cash register lost connection to the queue and processed receipts without communicating with the queue. All processed receipts marked with the hint “Security mechanism not reachable” need to be sent to the queue with this marker. | 1.3.45 |
| `0002` | **Training Receipt** | 1.3.45 |
| `0004` | **IsVoid**
Marks Receipt as Void to previous one. Mark lineitems also as IsVoid to signal clear data. | 1.3.45 |
| `0008` | **Process as Handwritten Receipt**
During a power outage, the Cash register will not work, and the merchant hands out handwritten receipts. These handwritten receipts need to be sent to the Security Mechanism by using this flag. | 1.3.45 |
| `0010` | **IssuerIsSmallBusiness**
Businesses below a country-specific size in revenue need not declare VAT.
With this marker, the receipt shows no VAT, all prices are gross, and a country-specific hint must be printed. | 1.3.45 |
-| `0020` | **ReceiverIsBusiness **
Specific data need to be placed onto the receipt. | 1.3.45 |
-| `0040` | **ReceiverIsKnown**
Characteristics related to VAT taxes are given. For example, Name, Adress, VAT-ID, other local info. | 1.3.45 |
+| `0020` | **ReceiverIsBusiness**
Specific data need to be placed onto the receipt. | 1.3.45 |
+| `0040` | **ReceiverIsKnown**
Characteristics related to VAT taxes are given. For example, Name, Address, VAT-ID, other local info. | 1.3.45 |
| `0080` | **IsSaleInForeignCountry**
| 1.3.45 |
| `0100` | **IsReturn/IsRefund**
Marks Receipt as Return of good or service. | 1.3.45 |
-| `0800` | **Group by Position-Number / 100**
100 = first position, 101 first subitem, 102 second subitem.
The sum of all chargeitems within a position must count toward the total receipt amount.
If the quantity and amount are 0,00, the quantity and amount will not be visualized for this line on the digital receipt. Independent if main our subitem. | 1.3.45 |
+| `0800` | **Group by Position-Number / 100**
100 = first position, 101 first subitem, 102 second subitem.
The sum of all chargeitems within a position must count toward the total receipt amount.
If the quantity and amount are 0,00, the quantity and amount will not be visualized for this line on the digital receipt. Independent if main or subitem. | 1.3.45 |
| `8000` | **ReceiptRequest**
If you don’t receive a response, try this flag first before taking any other action.
This will return a stored result for example in case of a timeout when cashregister calls queue. | 1.3.45 |
diff --git a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-service-ftchargeitemcase.md b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-service-ftchargeitemcase.md
index 2c0caf3..a38aa1d 100644
--- a/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-service-ftchargeitemcase.md
+++ b/poscreators/middleware-doc/middleware-pt/reference-tables/type-of-service-ftchargeitemcase.md
@@ -36,13 +36,13 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm
| `0` | **Unknown type of service**
With the help of the VAT-rates table saved within fiskaltrust.SecurityMechanisms. | 1.3.45 |
| `1` | **Delivery (supply of goods)**
| 1.3.45 |
| `2` | **Other service (supply of service)**
| 1.3.45 |
-| `3` | **Tip**
For owner use V=0 to 7, related to total amount
For Employee use V=8, Not Taxable(as of 1.1.2022, this is calculated with 5%). | 1.3.45 |
+| `3` | **Tip**
For owner use V=0 to 7, related to total amount
For Employee use V=8, Not Taxable (as of 1.1.2022, this is calculated with 5%). | 1.3.45 |
| `4` | **Voucher**
For Single-Use-Voucher use V=0 to 7
For Multi-Use-Voucher use V=8, Not Taxable
Voucher Sale is a positive (+) amount.
Voucher Redeem is a negative (-) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this for Multi-Use-Voucher, use PayItem instead, with ShowInChargeItems flag. For Single-Use-Voucher, apply the ShowInPayItems flag to visualize it similar to payment and to keep the total amount unreduced. | 1.3.45 |
| `5` | **Catalog service**
| 1.3.45 |
| `6` | **Not own sales / Agency business**
| 1.3.45 |
| `7` | **Own Consumption**
| 1.3.45 |
| `8` | **Grant**
For Unreal Grant use V=0 to 7
For Real Grant use V=8 |1.3.45|
-| `9` | **Receivable**
Receiveable creation is negative (-) amount
Receiveable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.45|
+| `9` | **Receivable**
Receivable creation is negative (-) amount
Receivable reduction is positive (+) amount.
IsVoid can be applied to reverse amounts.
Avoid to use this, use PayItem instead. |1.3.45|
| `A` | **Cash Transfer**
Cash Transfer to till is positive (+) amount
Cash Transfer from till is negative (-) amount.
Only useable with V=8, Not Taxable.
IsVoid can be applied to reverse amounts|1.3.45|
#### NN - nature of VAT
@@ -54,13 +54,13 @@ https://europa.eu/youreurope/business/taxation/vat/vat-rules-rates/index_en.htm
| `20` | **Not Subject**
2x can be used to specify more country specific details.| *NS (N2) marker mandatory
[20] not subject to VAT pursuant to articles from 7 to 7-septies of Presidential Decree 633/72
[21] not subject, other cases| 1.3.45 |
| `30` | **Exempt**
3x| *ES (N4) marker mandatory
[30] exempt | 1.3.45 |
| `40` | **Margin scheme**
Do not print/show VAT rate and amount on receipt/invoice.
4x can be used to specify more country specific details. | *RM (N5) marker mandatory
[40] margin scheme / VAT not shown on the invoice | 1.3.45 |
-| `50` | **Reverse charge**
5x | *AL (N6) marker mandatory
[50] reverse charge - disposal of scrap and other salvage materials
[51] reverse charge - sale of gold and silver pursuant to law 7/2000 as well as used jewelery to OPO
[52] reverse charge - subcontracting in the construction sector
[53] reverse charge - sale of buildings
[54] reverse charge - supply of mobile phones
[55] reverse charge - supply of electronic products
[56] reverse charge - performance in the construction sector and related sectors
[57] reverse charge - energy sector transactions
[58] reverse charge - other cases | 1.3.45 |
+| `50` | **Reverse charge**
5x | *AL (N6) marker mandatory
[50] reverse charge - disposal of scrap and other salvage materials
[51] reverse charge - sale of gold and silver pursuant to law 7/2000 as well as used jewellery to OPO
[52] reverse charge - subcontracting in the construction sector
[53] reverse charge - sale of buildings
[54] reverse charge - supply of mobile phones
[55] reverse charge - supply of electronic products
[56] reverse charge - performance in the construction sector and related sectors
[57] reverse charge - energy sector transactions
[58] reverse charge - other cases | 1.3.45 |
| `60` | **VAT paid in other EU country**
6x| (N7) marker mandatory
[60] paid in another EU country (provision of telecommunications, broadcasting and electronic services pursuant to art. 7-octies, paragraph 1 letter a, b, art. 74-sexies of Presidential Decree 633/72) | 1.3.45 |
| `70` | **VAT distribution**
7x | *VI (VI) is a fiscal VAT (IVA) regime that certain retailers can adopt. It allows the global registration of the daily takings amount without distinguishing the individual VAT rates. It only ever applies to goods. | 1.3.45 |
| `80` | **Excluded**
8x| *EE (N1) marker mandatory
[80] excluded pursuant to art. 15 of Presidential Decree 633/72 | 1.3.45 |
-#### lll - local taggin/flag
+#### lll - local tagging/flag
TBD
diff --git a/poscreators/middleware-doc/signing-at-rksv/rksv-sign-api.md b/poscreators/middleware-doc/signing-at-rksv/rksv-sign-api.md
index 1a9f0c7..9bd7b48 100644
--- a/poscreators/middleware-doc/signing-at-rksv/rksv-sign-api.md
+++ b/poscreators/middleware-doc/signing-at-rksv/rksv-sign-api.md
@@ -5,7 +5,7 @@ title: RKSV.Sign API
# RKSV.Sign API
-At it's core, the _RKSV.Sign_ API uses the [IATSSCD](https://github.com/fiskaltrust/middleware-interface-dotnet/blob/master/src/fiskaltrust.ifPOS/v0/at/IATSSCD.cs) interface that is also internally used by the Middleware to communicate with Austrian signing devices and services.
+At its core, the _RKSV.Sign_ API uses the [IATSSCD](https://github.com/fiskaltrust/middleware-interface-dotnet/blob/master/src/fiskaltrust.ifPOS/v0/at/IATSSCD.cs) interface that is also internally used by the Middleware to communicate with Austrian signing devices and services.
The API is hosted with REST and WCF/SOAP endpoints, users can decide which one to use.
diff --git a/posdealers/_markets/at/getting-started/my-first-cashbox/_business.mdx b/posdealers/_markets/at/getting-started/my-first-cashbox/_business.mdx
index f161567..381b64b 100644
--- a/posdealers/_markets/at/getting-started/my-first-cashbox/_business.mdx
+++ b/posdealers/_markets/at/getting-started/my-first-cashbox/_business.mdx
@@ -2,7 +2,7 @@ For this setup, we choose a fiskaltrust.Carefree plan. The fiskaltrust.Carefree
To start the Business rollout, **log into your portal account** and proceed with the following steps.
-1. Open your the **rollout management page** from [`Rollout Management` / `Plan`](https://portal-sandbox.fiskaltrust.at/RolloutManagement/Plan) (*Sandbox link*) in the left-hand navigation menu.
+1. Open the **rollout management page** from [`Rollout Management` / `Plan`](https://portal-sandbox.fiskaltrust.at/RolloutManagement/Plan) (*Sandbox link*) in the left-hand navigation menu.
2. Select `Business Rollout - Rolling out products`.
3. **Filter** for `CloudCashbox`.
4. Select the plan **4154-0005**. This plan will create **a Carefree bundle** and a CloudCashbox for immediate use.
diff --git a/posdealers/_markets/at/getting-started/operator-onboarding/invitation-process/_fields-details.mdx b/posdealers/_markets/at/getting-started/operator-onboarding/invitation-process/_fields-details.mdx
index 45b7934..6d1fee9 100644
--- a/posdealers/_markets/at/getting-started/operator-onboarding/invitation-process/_fields-details.mdx
+++ b/posdealers/_markets/at/getting-started/operator-onboarding/invitation-process/_fields-details.mdx
@@ -11,7 +11,7 @@
| AccountWeb | URL of the company's website | no |
| AccountPhone | Company phone number | no |
| AccountIdVat | VAT number of the company, Example: ATU12345678 is important for the reports for Finanz Online!
**IMPORTANT!**
This is one of the identification criteria for legalization of the service. |no 2 |
-| AccountIdTax | Tax office tax number of the company - Please enter with 9 digits without special characters and without spaces (2 digits tax office number, 3 digits "/" 4 digits tax number)
**IMPORTANT!**
This is one of the identification criterias for legalization of the service. |no 2 |
+| AccountIdTax | Tax office tax number of the company - Please enter with 9 digits without special characters and without spaces (2 digits tax office number, 3 digits "/" 4 digits tax number)
**IMPORTANT!**
This is one of the identification criteria for legalization of the service. |no 2 |
| AccountIdGln | GLN (https://firmen.wko.at) of the company, Example: 1234567890123 |no |
| AccountIdFibu | AccountIdFibu; company register number (if available) |no |
| ContactFirstName | First name of the Primary Contact | yes |
diff --git a/posdealers/_markets/de/buy-resell/products/_signing.mdx b/posdealers/_markets/de/buy-resell/products/_signing.mdx
index 362640f..f64156c 100644
--- a/posdealers/_markets/de/buy-resell/products/_signing.mdx
+++ b/posdealers/_markets/de/buy-resell/products/_signing.mdx
@@ -34,7 +34,7 @@ You cannot purchase a _TSE-as-a-Service_ as an individual product, but only as p
### Individual TSE products
In addition to the [TSE subscription service](#tse-as-a-service), fiskaltrust also offers several different TSE devices and products for individual purchase in its shop.
-#### Coud TSSs
+#### Cloud TSSs
The following SaaS TSE platforms are currently available in the *fiskaltrust.Shop*:
- Swissbit Cloud
- fiskaly
@@ -46,7 +46,7 @@ The following TSE devices are currently available in the *fiskaltrust.Shop*:
:::caution
-Please note that a TSE obtained through a individual product can only be used with one queue. If you want to use more than one queue on the same TSE then we offer _TSE-as-a-Service_ as part of a *[fiskaltrust.Sorglos](product-bundles)* bundle.
+Please note that a TSE obtained through an individual product can only be used with one queue. If you want to use more than one queue on the same TSE then we offer _TSE-as-a-Service_ as part of a *[fiskaltrust.Sorglos](product-bundles)* bundle.
:::
diff --git a/posdealers/_markets/de/getting-started/my-first-cashbox/_business.mdx b/posdealers/_markets/de/getting-started/my-first-cashbox/_business.mdx
index 8ee7dd6..ee44acf 100644
--- a/posdealers/_markets/de/getting-started/my-first-cashbox/_business.mdx
+++ b/posdealers/_markets/de/getting-started/my-first-cashbox/_business.mdx
@@ -2,7 +2,7 @@ For this setup, we choose a fiskaltrust.Carefree plan. The fiskaltrust.Carefree
To start the Business rollout, **log into your portal account** and proceed with the following steps.
-1. Open your the **rollout management page** from [`Rollout Management` / `Plan`](https://portal-sandbox.fiskaltrust.de/RolloutManagement/Plan) (*Sandbox link*) in the left-hand navigation menu.
+1. Open the **rollout management page** from [`Rollout Management` / `Plan`](https://portal-sandbox.fiskaltrust.de/RolloutManagement/Plan) (*Sandbox link*) in the left-hand navigation menu.
2. Select `Business Rollout - Rolling out products`.
3. **Filter** for `CloudCashbox`.
4. Select the plan **4445-0019**. This plan will create **a Carefree bundle** and a CloudCashbox for immediate use.
diff --git a/posdealers/_markets/de/overview/legal-data-protection/fair-use-policy/fair-use-policy-german.md b/posdealers/_markets/de/overview/legal-data-protection/fair-use-policy/fair-use-policy-german.md
index 39b1c15..f307234 100644
--- a/posdealers/_markets/de/overview/legal-data-protection/fair-use-policy/fair-use-policy-german.md
+++ b/posdealers/_markets/de/overview/legal-data-protection/fair-use-policy/fair-use-policy-german.md
@@ -42,7 +42,7 @@ These fair use rules may be adjusted by **fiskaltrust** due to specific characte
### Recommendation for compliance with the fair use rule
-If a physical location cannot be covered by a single outlet due to higher requirements, you have the option to create additional virtual outlets for this physical location in thefiskaltrust.Portal. The virtual outlets must be created with the address of the physical location in thefiskaltrust.Portal so that they can be assigned to it.
+If a physical location cannot be covered by a single outlet due to higher requirements, you have the option to create additional virtual outlets for this physical location in the fiskaltrust.Portal. The virtual outlets must be created with the address of the physical location in the fiskaltrust.Portal so that they can be assigned to it.
The required location-specific _fiskaltrust_ products can then be purchased separately for each outlet created.
### Non-compliance with the Fair Use Policy
diff --git a/posdealers/_markets/fr/getting-started/my-first-cashbox/_business.mdx b/posdealers/_markets/fr/getting-started/my-first-cashbox/_business.mdx
index 9b54094..1b57976 100644
--- a/posdealers/_markets/fr/getting-started/my-first-cashbox/_business.mdx
+++ b/posdealers/_markets/fr/getting-started/my-first-cashbox/_business.mdx
@@ -10,7 +10,7 @@ Please ensure the outlet selected in step 6 has a **valid SIRET code** configure
:::
-1. Open your the **rollout management page** from [`Rollout Management` / `Plan`](https://portal-sandbox.fiskaltrust.fr/RolloutManagement/Plan) (*Sandbox link*) in the left-hand navigation menu.
+1. Open the **rollout management page** from [`Rollout Management` / `Plan`](https://portal-sandbox.fiskaltrust.fr/RolloutManagement/Plan) (*Sandbox link*) in the left-hand navigation menu.
2. Select `Business Rollout - Rolling out products`.
3. **Filter** for `ChaîneCloud`.
4. Select the plan **4652-0005**. This plan will create **a ChaîneCloud** for immediate use.
diff --git a/posdealers/buy-resell/products/3rd-party/datev-meinfiskal.md b/posdealers/buy-resell/products/3rd-party/datev-meinfiskal.md
index f78e418..f381ad7 100644
--- a/posdealers/buy-resell/products/3rd-party/datev-meinfiskal.md
+++ b/posdealers/buy-resell/products/3rd-party/datev-meinfiskal.md
@@ -265,11 +265,11 @@ Please note that the fiskaltrust.Portal supports up to 100 characters in the fie
- The **PosDealer** cannot complete the linking process between fiskaltrust and _DATEV MeinFiskal_ because the wrong user name (not the same E-Mail address as for the fiskaltrust.Portal) was entered at _DATEV MeinFiskal_ in step 6. Therefore, the PosDealer must contact fiskaltrust support to delete the incorrect link.
## Import troubleshooting
-There a common mistakes that prevent us from being able to upload the data to DATEV MeinFiskal or the data having errors in the MeinFiskal overview.
+There are common mistakes that prevent us from being able to upload the data to DATEV MeinFiskal or the data having errors in the MeinFiskal overview.
| Error | Solution |
|----------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| No Data visible in DATEV MeinFiskal | This is most of the time caused by the DFKA not being valid. Please see [HowTo: DFKA-Export & validation report](#howto-dfka-export--validation-report) for common errors and help. |
-| Data from one daily-closing is missing in DATEV MeinFiskal | This is most of the time caused by the DFKA not being valid. Please see [HowTo: DFKA-Export & validation report](#howto-dfka-export--validation-report) for common errors and help. If a single daily-clsoing is affected then a rarely occuring receiptCase might be responsible. |
+| Data from one daily-closing is missing in DATEV MeinFiskal | This is most of the time caused by the DFKA not being valid. Please see [HowTo: DFKA-Export & validation report](#howto-dfka-export--validation-report) for common errors and help. If a single daily-closing is affected then a rarely occurring receiptCase might be responsible. |
| Errors in the DATEV MeinFiskal overview regarding mismatches in the revenue sums | If the sums don't match then the error is most of the time caused by the ChargeItems and PayItems not matching in some receipts. Please verify that your ChargeItem sums match the PayItem sums in all receipts. The middleware throws errors if the sums don't match and the receipt validation in the fiskaltrust.Portal shows errors. You can use the receipt check button in the fiskaltrust.Portal to identify affected receipts. |
diff --git a/posdealers/buy-resell/products/3rd-party/finanzonline-management.md b/posdealers/buy-resell/products/3rd-party/finanzonline-management.md
index c6ca528..a7f5cf7 100644
--- a/posdealers/buy-resell/products/3rd-party/finanzonline-management.md
+++ b/posdealers/buy-resell/products/3rd-party/finanzonline-management.md
@@ -102,7 +102,7 @@ Please do not select it without further information, we recommend to read this s
| steps | description |
|----------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|  | If you still consider it necessary to completely synchronize the data in the fiskaltrust.portal with the data in finanzOnline, use the action `Execute FinanzOnline status update for all PosOperators`. |
-|  | We recommend to check the PosOperators status individually a first. Confirm your decision otherwise. |
+|  | We recommend to check the PosOperators status individually first. Confirm your decision otherwise. |
## Troubleshooting
diff --git a/posdealers/buy-resell/products/digital-receipt.md b/posdealers/buy-resell/products/digital-receipt.md
index 1aeb750..a44d292 100644
--- a/posdealers/buy-resell/products/digital-receipt.md
+++ b/posdealers/buy-resell/products/digital-receipt.md
@@ -119,7 +119,7 @@ import EditOutletDE from '../../_markets/de/getting-started/operator-onboarding/
## Evaluation of retrievals of digital receipts
-In an audit case for the tax authorities (or in general), you, as a PosDeler or PosOperator, can verify which documents were transmitted and retrieved or printed using an export via the fiskaltrust.Portal.
+In an audit case for the tax authorities (or in general), you, as a PosDealer or PosOperator, can verify which documents were transmitted and retrieved or printed using an export via the fiskaltrust.Portal.
Use `Configuration` / `Queue` and select the desired Queue. The button `Export` leads you to a page for creating new exports (Tools / Export / Create new). When using the digital receipt, an additional file is added to the `Full export (XML)` Export type. This file provides information about the status of the individual digital receipts. In addition, linking the data records is possible using the ftReceiptJournalID, which is contained both in the raw and in the print data records.
diff --git a/posdealers/buy-resell/products/revision-safe-archiving.md b/posdealers/buy-resell/products/revision-safe-archiving.md
index ccce36f..65e8c5b 100644
--- a/posdealers/buy-resell/products/revision-safe-archiving.md
+++ b/posdealers/buy-resell/products/revision-safe-archiving.md
@@ -8,7 +8,7 @@ In addition to basic fiscalization, we offer cloud-based add-ons for revision-sa
:::tip tip
-In this contect, **revision-safe** means that data is stored in a secure and immutable way that makes it impossible to be changed after it was saved once.
+In this context, **revision-safe** means that data is stored in a secure and immutable way that makes it impossible to be changed after it was saved once.
:::
diff --git a/posdealers/buy-resell/products/signing/rksv-sign.md b/posdealers/buy-resell/products/signing/rksv-sign.md
index 31f69f3..dae93f9 100644
--- a/posdealers/buy-resell/products/signing/rksv-sign.md
+++ b/posdealers/buy-resell/products/signing/rksv-sign.md
@@ -17,7 +17,7 @@ As RKSV.Sign is only available in Austria, this tutorial does not apply to Germa
:::
-RKSV.Sign is a _signing-only_ product for the Austrian market, and offers RKSV-compliant receipt signing. This product is primarily meant for users who have already implemented the Austrian fiscalization laws in their POS systems, and are looking for a cloud signing service they can use. RKSV.Sign can be easily embedded int POS systems with our [public API description](https://docs.fiskaltrust.cloud/docs/poscreators/signing/austria) and [samples](https://rksvsign-samples.docs.fiskaltrust.cloud/), and uses a simplified business flow when compared to our other products - which is described in the following sections.
+RKSV.Sign is a _signing-only_ product for the Austrian market, and offers RKSV-compliant receipt signing. This product is primarily meant for users who have already implemented the Austrian fiscalization laws in their POS systems, and are looking for a cloud signing service they can use. RKSV.Sign can be easily embedded into POS systems with our [public API description](https://docs.fiskaltrust.cloud/docs/poscreators/signing/austria) and [samples](https://rksvsign-samples.docs.fiskaltrust.cloud/), and uses a simplified business flow when compared to our other products - which is described in the following sections.
:::tip
diff --git a/posdealers/buy-resell/subscription-management.md b/posdealers/buy-resell/subscription-management.md
index ad36d0e..788950a 100644
--- a/posdealers/buy-resell/subscription-management.md
+++ b/posdealers/buy-resell/subscription-management.md
@@ -22,7 +22,7 @@ On this page, you can also manage subscriptions by opting for automatic renewals
[Subscription-management](./images/subscription-management.png)
## Renewals
-Renewing subscriptions is an annual process that can either be done manually, or automatically by the Portal. Both ways are described below; please not that the automatic renewal is an opt-in feature that needs to be activated.
+Renewing subscriptions is an annual process that can either be done manually, or automatically by the Portal. Both ways are described below; please note that the automatic renewal is an opt-in feature that needs to be activated.
### Automatic Renewals
To enable automatic renewals, you need to sign a side letter to the PosDealer contract, allowing fiskaltrust to do these otherwise manual interactions for you.
@@ -34,7 +34,7 @@ This feature ensures that your PosOperators' product subscriptions are automatic
The column _Renewal type_ allows you to choose between enabling or disabling the automatic renewal feature for one specific subscriptions.
### Manual Renewals
-You always have the option to manually renew specific outlets - either because this is the default flow you prefer, or because you disabled automatic renewals for speific subscriptions.
+You always have the option to manually renew specific outlets - either because this is the default flow you prefer, or because you disabled automatic renewals for specific subscriptions.
Subscriptions can either be renewed one-by-one by selecting _Renew subscriptions_ in the _Actions_ column, or in a bulk operation by selecting multiple rows and clicking on the _Renew subscriptions_ button at the end of the page. Both ways will trigger a popup window where you can select if you either want your Quote to include the required entitlements for the renewals, or if you already have existing entitlements you want to consume.
@@ -43,7 +43,7 @@ Subscriptions can either be renewed one-by-one by selecting _Renew subscriptions
Confirming this dialog will create a Quote and automatically load it into the basket, where it can then be checked out.
## Cancellation
-Cancelling subscriptions can either be done one-by-one by selecting _Cancel suscription_ in the _Actions_ column of each row, or y multi-selecting multiple suscriptions and using the _Cancel suscriptions_ button at the end of the page. You will be asked for confirmation in both cases ebfore the subscriptions are cancelled.
+Cancelling subscriptions can either be done one-by-one by selecting _Cancel subscription_ in the _Actions_ column of each row, or by multi-selecting multiple subscriptions and using the _Cancel subscriptions_ button at the end of the page. You will be asked for confirmation in both cases before the subscriptions are cancelled.
When subscriptions are cancelled within the billing period, the cancellation will become effective at the end of the runtime period - i.e. the product can be used until then as before.
diff --git a/posdealers/getting-started/operator-onboarding/invitation-process.md b/posdealers/getting-started/operator-onboarding/invitation-process.md
index 4bfd23e..1d8699c 100644
--- a/posdealers/getting-started/operator-onboarding/invitation-process.md
+++ b/posdealers/getting-started/operator-onboarding/invitation-process.md
@@ -112,7 +112,7 @@ Inviting PosOperators to a PosDealer account with an import file is especially i
| |Choose the fiskaltrust.Portal and `PosOperator` / `Invitation`|
| |Check the configurations of the invitations as previously described [_here_](#preparation-of-invitations) |
| |Use `Download demo CSV file`. |
-| |Open the the demo CSV file. |
+| |Open the demo CSV file. |
| |See the explanations [_below_](#fields-of-the-csv-file), add the requested data of the PosOperators and save the date as a CSV file. |
| |Change again to the fiskaltrust.Portal and choose `PosOperator` / `Invitation`.|
| |In the section named `PosOperators that should be invited` use `Choose file...` to set your CSV file. |
diff --git a/posdealers/getting-started/operator-onboarding/master-data.md b/posdealers/getting-started/operator-onboarding/master-data.md
index f18184f..495ff11 100644
--- a/posdealers/getting-started/operator-onboarding/master-data.md
+++ b/posdealers/getting-started/operator-onboarding/master-data.md
@@ -16,7 +16,7 @@ The **Master data** of a company are essential for various reasons in the fiskal
* To set up and use various [**signing devices and services**](../../buy-resell/products/signing/signing-overview.md) PosDealer and PosOperator need at least one of their tax identification numbers.
-* For **authentication** towards fiscal authorities or [third-party integrations](../../buy-resell/products/3rd-party/3rd-party-overview.md) Tax registration numbers are essential..
+* For **authentication** towards fiscal authorities or [third-party integrations](../../buy-resell/products/3rd-party/3rd-party-overview.md) Tax registration numbers are essential.
A company's **outlets** data is significant and should be checked:
diff --git a/posdealers/getting-started/registration.md b/posdealers/getting-started/registration.md
index f181e5a..c81c070 100644
--- a/posdealers/getting-started/registration.md
+++ b/posdealers/getting-started/registration.md
@@ -91,7 +91,7 @@ In addition, with his authorization, this user can invite other company employee
:::tip Error message
-If the E-Mail address entered in _E-Mail_ is already in use in the fiskaltrust.Portal, you will see a warning message. This message will show that a user with this E-Mailadress already exists. By clicking the link in this information, you can initiate the password reset for this user.
+If the E-Mail address entered in _E-Mail_ is already in use in the fiskaltrust.Portal, you will see a warning message. This message will show that a user with this E-Mail address already exists. By clicking the link in this information, you can initiate the password reset for this user.
:::
### Confirm registration
@@ -133,9 +133,9 @@ If the password for logging into the fiskaltrust.Portal is lost or forgotten; yo
| Steps | Description |
|:----------------------:|-------------------------------------------------------------------------------------------------------------------------------------|
| |Go to the login screen of the fiskaltrust.Portal and click on the link `If you have forgotten your password, please click here`. |
-| |Solve the CAPTCHA.. |
+| |Solve the CAPTCHA. |
| |Enter the E-Mail address you used when registering your account. |
-| | You will see a confirmation that the link for resetting the password has been sent to the entered E-Mail address. If not, check whether the E-Mail address in usage is the very same you used when you registered your account.. |
+| | You will see a confirmation that the link for resetting the password has been sent to the entered E-Mail address. If not, check whether the E-Mail address in usage is the very same you used when you registered your account. |
| |Check after a few minutes the inbox of this E-Mail address. When you click the link in the E-Mail, a browser window will open and show the password reset page of the fiskaltrust.Portal. |
| |Enter the E-Mail address of your _fiskaltrust_ account, the new password and confirm it by entering it a second time. Your click on `RESET` will save the new password; you see a confirmation page, and you can log in to the fiskaltrust.Portal again. |
diff --git a/posdealers/information-sources/documentation.md b/posdealers/information-sources/documentation.md
index 567163d..4e7da84 100644
--- a/posdealers/information-sources/documentation.md
+++ b/posdealers/information-sources/documentation.md
@@ -48,7 +48,7 @@ import ReactPlayer from "react-player"
:::tip Copying expressions made easy
-Fiskaltrust`s documentation, in particular the technical chapters, contains code blocks. These you can execute on your system's command line. When hovering with the mouse over such a code block, a copy button will appear in the top right. This button allows you to copy the whole code with one click to your clipboard. You can save time and avoid typos or spelling issues. Please note the respective explanatory text for notes on where to use the code and whether adjustments are necessary.
+Fiskaltrust's documentation, in particular the technical chapters, contains code blocks. These you can execute on your system's command line. When hovering with the mouse over such a code block, a copy button will appear in the top right. This button allows you to copy the whole code with one click to your clipboard. You can save time and avoid typos or spelling issues. Please note the respective explanatory text for notes on where to use the code and whether adjustments are necessary.
:::
diff --git a/posdealers/technical-operations/middleware/cashbox.md b/posdealers/technical-operations/middleware/cashbox.md
index 56ed13c..b039a84 100644
--- a/posdealers/technical-operations/middleware/cashbox.md
+++ b/posdealers/technical-operations/middleware/cashbox.md
@@ -98,7 +98,7 @@ The following sample is a trimmed-down CashBox skeleton outlining the overall st
## CashBox maintenance (fiskaltrust.Portal)
-The fiskaltrust.Portal is the starting point for each CashBox, where you create and maintain all your CashBoxes.There, you will find an overview of the CashBoxes of an account.
+The fiskaltrust.Portal is the starting point for each CashBox, where you create and maintain all your CashBoxes. There, you will find an overview of the CashBoxes of an account.
You log in as PosDealer and switch to the desired account (`PosOperators` / `Overview`).
diff --git a/posdealers/technical-operations/middleware/helper.md b/posdealers/technical-operations/middleware/helper.md
index 30ae441..2a7a17a 100644
--- a/posdealers/technical-operations/middleware/helper.md
+++ b/posdealers/technical-operations/middleware/helper.md
@@ -53,7 +53,7 @@ If you have further questions or need clarification, please contact your fiskalt
| |**For all countries**: Change port to the next free port (+1) and. |
|...|a. if **no suffix** exists after the port: add the suffix "/ _placeholder__queue" to the URL (_placeholder_ can be freely chosen)|
|...|b. b. if a suffix already exists: add the suffix "_queue" to the URL|
-| |**Germany & France only:** Change `grpc port` to the next free port and add the suffix "/I_queue" to the URL (_placeholder_ can be chosen freely). If the designated port is free there is no need to go up to the next free port.. |
+| |**Germany & France only:** Change `grpc port` to the next free port and add the suffix "/I_queue" to the URL (_placeholder_ can be chosen freely). If the designated port is free there is no need to go up to the next free port. |
| |`Save` your changes. |
###### Preparation Helper
diff --git a/posdealers/technical-operations/middleware/launchers/cloudcashbox.md b/posdealers/technical-operations/middleware/launchers/cloudcashbox.md
index 79b7754..8be84ff 100644
--- a/posdealers/technical-operations/middleware/launchers/cloudcashbox.md
+++ b/posdealers/technical-operations/middleware/launchers/cloudcashbox.md
@@ -19,7 +19,7 @@ The CloudCashbox is a fully hosted SaaS version of fiskaltrust's Middleware, off
### Key features include:
- Support for PosAPI and classic Middleware API: Ensures compatibility with various POS systems.
-- Centralized Management: Fiskaltrust manages the entire setup, offering more control and flexibility.
+- Centralized Management: fiskaltrust manages the entire setup, offering more control and flexibility.
- Easy Rollout: The product can be rolled out via the portal, and migration from existing Cashboxes is streamlined through a dedicated process.
@@ -40,7 +40,7 @@ On the next screen, choose the Business Rollout.
-Once the next screen is loaded, you can now search for _CloudCashbox_ products. In this case, we did the Rollout with a fiskaltrust. Carefree package. It is also possible to rollout an fiskaltrust.Carefree package with your already existing entitlements if you have some or to simply rollout the _CloudCashbox_ as a standalone product.
+Once the next screen is loaded, you can now search for _CloudCashbox_ products. In this case, we did the Rollout with a fiskaltrust. Carefree package. It is also possible to rollout a fiskaltrust.Carefree package with your already existing entitlements if you have some or to simply rollout the _CloudCashbox_ as a standalone product.
@@ -121,7 +121,7 @@ After this step, you will be asked to verify your selection. If everything is al
-Your request has then been sent and can take to up to 5 days to be validated.
+Your request has then been sent and can take up to 5 days to be validated.
diff --git a/posdealers/technical-operations/middleware/manual-configuration.md b/posdealers/technical-operations/middleware/manual-configuration.md
index ebcfc15..85290c6 100644
--- a/posdealers/technical-operations/middleware/manual-configuration.md
+++ b/posdealers/technical-operations/middleware/manual-configuration.md
@@ -41,7 +41,7 @@ A Queue is defined [here](../../business-basics/architecture.md#queue), find mor
|  | At `Timeout`, you can specify a millisecond value for the timeout of the Queue. |
|  | The `Country Code` depends on the chosen fiskaltrust.Portal and cannot be changed, see [reference tables](../../../poscreators/middleware-doc/middleware-de-kassensichv/reference-tables/service-status-ftstate.md) for details. |
|  | Enter the desired `CashBox Identification` but note that this value cannot be changed again after saving your Queue. |
-|  | At `Outlet`, you can choose the desired option but note that this value cannot be changed again afer saving your Queue. |
+|  | At `Outlet`, you can choose the desired option but note that this value cannot be changed again after saving your Queue. |
|  | |
### Assign the SCU to the Queue
@@ -56,7 +56,7 @@ The SCU must be assigned to the Queue. Therefore go to `Configuration` / `Queue`
|  | To expand your CashBoxes, please choose `+Add`. |
|  | You must add a `Description`. |
|  | At `IP Address`, you can enter a value (optional). |
-|  | At `Oulet`, you can choose the desired outlet but note that this value cannot be changed again afer saving your Queue. |
+|  | At `Outlet`, you can choose the desired outlet but note that this value cannot be changed again after saving your Queue. |
|  | |
|  | Click the button `edit by list` to add the Queue, SCU and optionally a helper. |
diff --git a/posdealers/technical-operations/rollout-automation/api-templating.md b/posdealers/technical-operations/rollout-automation/api-templating.md
index bb92c8d..d7edee3 100644
--- a/posdealers/technical-operations/rollout-automation/api-templating.md
+++ b/posdealers/technical-operations/rollout-automation/api-templating.md
@@ -147,7 +147,7 @@ For example, to specify a timeout value of 10,000 milliseconds for the **second*
-#### Market-specfic parameters
+#### Market-specific parameters
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
diff --git a/posdealers/technical-operations/rollout-automation/shop-templating.md b/posdealers/technical-operations/rollout-automation/shop-templating.md
index 591a282..5372b92 100644
--- a/posdealers/technical-operations/rollout-automation/shop-templating.md
+++ b/posdealers/technical-operations/rollout-automation/shop-templating.md
@@ -32,8 +32,8 @@ When you create or edit a template, you must fill out the following form.
| elements | description |
|:----------------------:|-------------------------------------------------------------------------------------------------------------------------------------|
-| |Meaningfull name for the template. |
-| |More detailed description to understand the purpose and content of the template. An image (e.g., product image) and link url for further information can be assinged. |
+| |Meaningful name for the template. |
+| |More detailed description to understand the purpose and content of the template. An image (e.g., product image) and link url for further information can be assigned. |
| |Mode sets the visibility of the template: Private (owner only), Deactivated (not visible in shop),Public for (your) PosOperators, Public for (your) PosDealers. |
| |The JSON content of the template. |
| |Save the template before leaving the page. |
diff --git a/posdealers/technical-operations/rollout-scenarios.md b/posdealers/technical-operations/rollout-scenarios.md
index af3a228..eca168f 100644
--- a/posdealers/technical-operations/rollout-scenarios.md
+++ b/posdealers/technical-operations/rollout-scenarios.md
@@ -16,7 +16,7 @@ Please check the country-specific notes for further details. Unfortunately, not
### Explanation of terms and graphics
-Please not our [terminology](https://docs.fiskaltrust.cloud/docs/faq/terms) for the terms used in our application and this documentation.
+Please note our [terminology](https://docs.fiskaltrust.cloud/docs/faq/terms) for the terms used in our application and this documentation.
Pros and cons describe the scenarios. The term _POS-System fails_ means that the Queue will switch into a failure mode but is still operational until you, as a PosDealer or PosOperator, restore the connection by a zero receipt.
@@ -100,7 +100,7 @@ You, as a PosDealer, can recommend this scenario for interconnected POS-Systems.
:::tip
-Our partners' experiences showed that in exceptional cases, terminals become defective and, e.g., repeatedly send a broken receipt. If this happens at a high frequency, this could block the shared Queue. You can achieve excellent reliability by creating a separate queue for each terminal and, e.g., hosting all of them in the same CasHbox, as shown in the following diagram.
+Our partners' experiences showed that in exceptional cases, terminals become defective and, e.g., repeatedly send a broken receipt. If this happens at a high frequency, this could block the shared Queue. You can achieve excellent reliability by creating a separate queue for each terminal and, e.g., hosting all of them in the same CashBox, as shown in the following diagram.
:::
diff --git a/posdealers/technical-operations/troubleshooting/network-troubleshooting.md b/posdealers/technical-operations/troubleshooting/network-troubleshooting.md
index d67d7cf..c6f97b8 100644
--- a/posdealers/technical-operations/troubleshooting/network-troubleshooting.md
+++ b/posdealers/technical-operations/troubleshooting/network-troubleshooting.md
@@ -84,7 +84,7 @@ https://packages.fiskaltrust.cloud/version ft download packages
https://dc.services.visualstudio.com/ ft error reporting okay COMPUTER-NAME
```
-The output's last table (with `Url`) is attractive, as it indicates which network connections succeeded.Analyzing the log
+The output's last table (with `Url`) is attractive, as it indicates which network connections succeeded. Analyzing the log
The first step in debugging connectivity issues is typically the Middleware's log. You could either start the Middleware in [test [mode](../middleware/launchers/desktop.md) and analyze its output directly in the console or configure a [log file](../middleware/logging.md). In either case, please ensure the log level is set to `debug`.