Merge pull request #130 from fiskaltrust/patch-1

fixed typos

doc/appendix-de-kassensichv/reference-tables/type-of-receipt-ftreceiptcase.md

@@ -9,8 +9,8 @@ For Germany (DE) the country code is `0x4445`. Thus, the value of an unknown `ft
 | `0x4445000000000000` | **unknown type for country-code "DE"**<br /><br />This receipt case is handled like a "pos-receipt" (`0x4445000000000001`). See below: | Beleg <br /> Kassenbeleg-V1 | 1.3- |
 | `0x4445000000000001` | **pos-receipt**<br /><br />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. <br /><br />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. <br /><br />The duration of the represented action is calculated using the minimum (start time) and maximum (end time) of datetimes over `ftReceiptRequest`/`ftChargeItems`/`ftPayItems` <br /><br />The BON_TYP (Beleg) of DSFinV-K can be overwritten by an `ftReceiptCaseFlag`.  | Beleg <br /> Kassenbeleg-V1 | 1.3- |
 | `0x4445000000000002` | **zero-receipt**<br /><br />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. <br /><br />The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays. <br /><br />This receipt case works **only** with **implicit** flow. Using it without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception.<br /><br />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`.<br /><br /> Informations returned in the response are:<ul><li>List of `cbReceiptReferece <-> Transaction-ID` relations.</li><li>Statusdata of TSE, serialnumber, available/free memory, available number of signatures left, ...</li></ul>| [none] <br /> SonstigerVorgang  | 1.3- |
-| `0x4445000000000003` | **initial operation receipt / start-receipt**<br /><br />The request is only valid with the same property requirements as a zero-receipt. It initializes a new fiskaltrust.SecurityMachanism including also the initialization of the used TSE in the background. Depending on the TSE-Type used, this includes different actions.<br /><br />On successful initialization, 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.<br /><br />The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays. <br /><br />This receipt case works **only** with **implicit flow**. calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception.| [none] <br /> SonstigerVorgang | 1.3- |
-| `0x4445000000000004` | **out of operation receipt / stop-receipt**<br /><br />The request is only valid with the same property requirements as a zero-receipt. It is desabling the fiskaltrust.SecurityMachanism including the deactivation of the client ID used in the TSE for the current queue. Optionally one can also deactivate the complete TSE used in background. This option will be avalable by a using a special flag soon.<br /><br />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. <br /><br />The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.<br /><br />This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception.| AVSonstige <br /> SonstigerVorgang | 1.3- |
+| `0x4445000000000003` | **initial operation receipt / start-receipt**<br /><br />The request is only valid with the same property requirements as a zero-receipt. It initializes a new fiskaltrust.SecurityMechanism including also the initialization of the used TSE in the background. Depending on the TSE-Type used, this includes different actions.<br /><br />On successful initialization, 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.<br /><br />The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays. <br /><br />This receipt case works **only** with **implicit flow**. calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception.| [none] <br /> SonstigerVorgang | 1.3- |
+| `0x4445000000000004` | **out of operation receipt / stop-receipt**<br /><br />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. Optionally one can also deactivate the complete TSE used in background. This option will be available by a using a special flag soon.<br /><br />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. <br /><br />The request is only valid when the charge items block (`ftChargeItems`) and the pay items block (`ftPayItems`) in the `ftReceiptRequest` are empty arrays.<br /><br />This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | AVSonstige <br /> SonstigerVorgang | 1.3- |
 | `0x4445000000000005` | **monthly-closing**<br /><br />TBD: close all open cbReceiptReference <-> Transaction-ID  <br /> <br />This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none] <br> SonstigerVorgang | 1.3- |
 | `0x4445000000000006` | **yearly-closing**<br /><br />TBD: close all open cbReceiptReference <-> Transaction-ID  <br /> <br />This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none] <br> SonstigerVorgang | 1.3- |
 | `0x4445000000000007` | **daily-closing**<br /><br />TBD: close all open cbReceiptReference <-> Transaction-ID  <br /> <br />This receipt case works **only** with **implicit flow**. Calling without the `ftReceiptCaseFlag` `0x0000000100000000` ends up in an exception. | [none] <br> SonstigerVorgang | 1.3- |