From 3efebea2956fd5d5ae8a1f1c156ed1b327bcb4f3 Mon Sep 17 00:00:00 2001 From: Christian Rogobete Date: Tue, 5 May 2020 11:29:09 +0200 Subject: [PATCH 01/10] dsfinv-k fixes: BON_STORNO, ZI_WARENGR_ID, UserId --- .../procedural-documentation/dsfinv-k-generation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md b/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md index 85e1357c..525c72d5 100644 --- a/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md +++ b/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md @@ -145,7 +145,7 @@ Each subitem as described in the table below: | `ZI_ART_NR` | Article number | String (50) | To send, add the key value pair `ProductNumber` within the subitem. e.g. `"SubItems":"[{ "ProductNumber":"10292", ... }, ... ]` | | `ZI_GTIN` | GTIN | String | To send, add the key value pair `GTIN` within the subitem. e.g. `"SubItems":"[{ "ProductNumber":"10292", "GTIN":"4231234266622", ... }, ... ]` | | `ZI_NAME` | Article name | String (60) | To send, add the key value pair `Description` within the subitem. e.g. `"SubItems":"[{ "ProductNumber":"10292", "Description":"4231234266622", ... }, ... ]` | -| `ZI_WARENGR_ID` | Product group ID | String (40) | To send, add the key value pair `ProductGroup` within the subitem. It should be sent as a JSON composed of the key value pairs `ProductGroupId` and `ProductGroupName` e.g. `"SubItems":"[{ ..., "ProductGroup":"{ "ProductGroupId":"981981AA", "ProductGroupName":"Fleischwaren" }", ... }, ... ]` (tbd: does this match to our concept of automatically filling the WARENGR_ID by hasing the name?) | +| `ZI_WARENGR_ID` | Product group ID | String (40) | To send, add the key value pair `ProductGroup` within the subitem. It should be sent as a JSON composed of the key value pairs `ProductGroupId` and `ProductGroupName` e.g. `"SubItems":"[{ ..., "ProductGroup":"{ "ProductGroupId":"981981AA", "ProductGroupName":"Fleischwaren" }", ... }, ... ]`. If only `ProductGroupName` is filled, ft will automatically fill `ZI_WARENGR_ID` by creating a hash from `ProductGroupName`. | | `ZI_WARENGR` | Name of the product group | String (50) | Similar to `ZI_WARENGR_ID`, use `SubItem.ProductGroup.ProductGroupName` | | `ZI_MENGE` | Quantity | Decimal (3) | To send, add the key value pair `Quantity` within the subitem. e.g. `"SubItems":"[{..., "Quantity":2.543, ... }, ... ]` | | `ZI_FAKTOR` | factor, e.g. container sizes | Decimal (3) | To send, add the key value pair `UnitQuantity` within the subitem. e.g. `"SubItems":"[{ ..., "UnitQuantity":1.0, ... }, ... ]` | @@ -168,10 +168,10 @@ Each subitem as described in the table below: | `BON_TYP` | Receipt type / action type| String (30) | Deducted from `ftReceiptCase` | | `BON_NAME` | Additional description related to the `BON_TYP` | String (60) | Mandatory if `BON_TYPE` is "AVSonstige", otherwise optional, can be sent via `ftReceiptCaseData` in JSON format. To send, add the key value pair `ReceiptName ` e.g. `"ftReceiptCaseData":"{ ..., "ReceiptName":"Sonstige Sonderwurst", ... }"` | | `TERMINAL_ID` | Mandatory, ID of the terminal that was used to record this receipt | String (50) | `cbTerminalID` | -| `BON_STORNO` | Cancellation indicator | String | Mandatory if your receipt is a reverse receipt that voids another, previous receipt. In this case mark your receipt with the `ftReceiptCaseFlag` `0x0000000000040000` and reference the receipt to be voided via `cbPreviousReceiptReference`. Ft will then set the `BON_STORNO` flag in the DSFinV-K export and will also add a corresponding reference in the file "**Bon_Referenzen (references.csv)**" (see below). | +| `BON_STORNO` | Cancellation indicator | 0 or 1 | Mandatory if your receipt is a reverse receipt that voids another, previous receipt (DE: Nachträgliche Vorgangs-Stornierungen). The signs for the charge items and pay items must be reversed comparing to the receipt to be voided. Please reference the receipt to be voided via `cbPreviousReceiptReference` and set the field `VoidingReceipt` to the value ´1´ within `ftReceiptCaseData`. E.g. `"ftReceiptCaseData":"{ ..., "VoidingReceipt":1, ... }"`. Ft will then set the `BON_STORNO` flag in the DSFinV-K export and will also add a corresponding reference in the file "**Bon_Referenzen (references.csv)**" (see below). See also this [discussion](https://www.xing.com/communities/posts/dsfinv-k-2-punkt-1-bon-storno-1018938536).| | `BON_START` | Time of the action start | ISO 8601 and RFC3339 date | The action start can be within this cashpoint or outside of this cashpoint. If outside (e.g. by another system or another cashpoint) than it has to be provided in via `ftReceiptCaseData` in JSON format by adding the key value pair `ActionStartMoment`. E.g. `"ftReceiptCaseData":"{ ..., "ActionStartMoment":"2020-09-27T17:00:01", ... }"`. If not provided, ft tries to find the action start by following the `cbPreviousReceiptReference` path into the past until no more previous receipt references exist. ft will than fill this field with the value from `ftReceiptMoment` of the oldest receipt found in that chain. | | `BON_ENDE` | Time of the action end | String | `ftReceiptMoment` | -| `BEDIENER_ID` | User-ID | String (50) | Optional. To send, pls. add the key value pair `ProductGroupId` e.g. `"ftReceiptCaseData":"{ ..., "UserId":192, ... }"`. If not sent, the ft will automatically generate a User-ID (hash) deducted from `cbUser` | +| `BEDIENER_ID` | User-ID | String (50) | Optional. To send, pls. add the key value pair `UserId` e.g. `"ftReceiptCaseData":"{ ..., "UserId":192, ... }"`. If not sent, the ft will automatically generate a User-ID (hash) deducted from `cbUser` | | `BEDIENER_NAME` | User name | String (50) | Mandatory, please send via `cbUser` | | `UMS_BRUTTO` | Gross total turnover | Decimal (2) | Automatically filled by ft | | `KUNDE_NAME` | Name of beneficiary customer | String (50) | Mandatory if not exempted in relation to § 148 AO. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerName` e.g. `"cbCustomer":"{"CustomerName":"Max Wanne",...}"`| From 935430799d8e60a58c989964404071ef7e82eccd Mon Sep 17 00:00:00 2001 From: Tom Schmiedlechner Date: Fri, 8 May 2020 18:31:04 +0200 Subject: [PATCH 02/10] JournalResponse is a stream --- dist/protos/IPOS.proto | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dist/protos/IPOS.proto b/dist/protos/IPOS.proto index 8d380fe1..6272b3f3 100644 --- a/dist/protos/IPOS.proto +++ b/dist/protos/IPOS.proto @@ -7,7 +7,7 @@ import "bcl.proto"; service POS { rpc Echo(EchoRequest) returns (EchoResponse) {} - rpc Journal(JournalRequest) returns (JournalResponse) {} + rpc Journal(JournalRequest) returns (stream JournalResponse) {} rpc Sign(ReceiptRequest) returns (ReceiptResponse) {} } From 83bdb02616514ce37707c003b02b655bdd43a5ce Mon Sep 17 00:00:00 2001 From: Christian Rogobete Date: Mon, 11 May 2020 09:30:37 +0200 Subject: [PATCH 03/10] add version number of DSFinV-K specification --- .../procedural-documentation/dsfinv-k-generation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md b/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md index 525c72d5..d58b474c 100644 --- a/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md +++ b/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md @@ -5,7 +5,7 @@ You can download the current version of the DSFinV-K specification [here](https://www.bzst.de/DE/Unternehmen/Aussenpruefungen/DigitaleSchnittstelleFinV/digitaleschnittstellefinv_node.html). -Based on the the current version of the DSFinV-K specification, this chapter explains how the DSFinV-K export is structured, shows how the previously described input values are mapped by fisklatrust to the files and data of the DSFinV-K export and defines how additional, for the DSFInV-K required, values can be sent to the ft.Middleware. Furthermore, it describes how the marking of actions (DE: Vorgänge) can be made by connecting business actions (DE: Geschäftsvorfälle) and other procedures, occurrences and events (DE: Andere Vorgänge). +Based on the the version 2.1 of the DSFinV-K specification, this chapter explains how the DSFinV-K export is structured, shows how the previously described input values are mapped by fisklatrust to the files and data of the DSFinV-K export and defines how additional, for the DSFInV-K required, values can be sent to the ft.Middleware. Furthermore, it describes how the marking of actions (DE: Vorgänge) can be made by connecting business actions (DE: Geschäftsvorfälle) and other procedures, occurrences and events (DE: Andere Vorgänge). #### Structure From 9b663bcd092f14e9a101aeca084e9b3c936fd164 Mon Sep 17 00:00:00 2001 From: Christian Rogobete Date: Mon, 11 May 2020 09:42:06 +0200 Subject: [PATCH 04/10] remove master data requirements --- .../procedural-documentation/dsfinv-k-generation.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md b/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md index d58b474c..e3853e45 100644 --- a/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md +++ b/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md @@ -50,9 +50,6 @@ This chapter lists the data fields that are mandatory and must be provided by th | `ABRECHNUNGSKREIS` | Single recordings | Connection criterion of the assignment. | | `ZAHLWAEH_CODE` | Single recordings | Foreign currency code. Only mandatory if foreign currency was used for the payment. | | `ZAHLWAEH_BETRAG` | Single recordings | Amount in foreign currency. Only mandatory if foreign currency was used for the payment. | -| `Z_BUCHUNGSTAG` | Master data | Booking date different from closing date (`Z_ERSTELLUNG`). Only mandatory if the booking date is different to the date of the daily closing receipt. | -| Master data for the company, location, terminals, agencies as described in the chapter "Master data module" | Master data | Master data for this cashpoint closing and referenced by the single recordings| - The following chapters give you an overview of all DSFinV-K fields, provide you information on how they are filled by ft and how you can send additional data to fill mandatory (listed above) and optional fields that can not be filled by ft. From 2b613aa84380a78d97f5cade3752abccd4b62adf Mon Sep 17 00:00:00 2001 From: Christian Rogobete Date: Tue, 12 May 2020 09:01:50 +0200 Subject: [PATCH 05/10] fix for issue 52 https://github.com/fiskaltrust/interface-doc/issues/52 --- .../cash-register-integration/cash-register-integration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/appendix-de-kassensichv/cash-register-integration/cash-register-integration.md b/doc/appendix-de-kassensichv/cash-register-integration/cash-register-integration.md index b623f9ee..a65fa85d 100644 --- a/doc/appendix-de-kassensichv/cash-register-integration/cash-register-integration.md +++ b/doc/appendix-de-kassensichv/cash-register-integration/cash-register-integration.md @@ -35,7 +35,7 @@ The transaction number defined in TR-03153 is responded behind hash-tag in prope #### The fiskaltrust.SecurityMechanism implicit transaction The regular workflow of the fiskaltrust.SecurityMechanism in the German market for actions running immediately has the same requirements as long-running ones. In details, this means, according to BSI TR-03153, there has to be a "Start-Transaction" and a "Finish-Transaction" executed against the TSE. To speed up these two steps into one call to the ´Sign´ method there is a special ´ReceiptCaseFlag´ introduced. Each time this is used in combination with a usual ´ReceiptCase´ a "Start-Transaction" is done behind the scenes upfront to the final call using the given ´ReceiptCase´. -Using a unique identifier in `cbReceiptIdentification´ that was already used with a ´Sign´ call with ´ReceiptCase´ "Start-Transaction" will end up in an exception. +Using a unique identifier in `cbReceiptReference` that was already used with a ´Sign´ call with ´ReceiptCase´ "Start-Transaction" will end up in an exception. The up-counting transaction number defined in TR-03153 is responded behind hash-tag in property ´ftReceiptIdentification´ of ´ReceiptResponse´ prefixed by "IT". ### Receipt for special functions From fd9457955c83e8ae6122c77b1dd79af9cdd687b2 Mon Sep 17 00:00:00 2001 From: Tom Schmiedlechner Date: Tue, 12 May 2020 11:21:42 +0200 Subject: [PATCH 06/10] Fixed dead link --- doc/appendix-at-rksv/appendix-at-rksv.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/appendix-at-rksv/appendix-at-rksv.md b/doc/appendix-at-rksv/appendix-at-rksv.md index 34852c85..a2186488 100644 --- a/doc/appendix-at-rksv/appendix-at-rksv.md +++ b/doc/appendix-at-rksv/appendix-at-rksv.md @@ -8,6 +8,6 @@ The links to regulations and further information, can be found at: Further literature can be found at: - +https://www.lindeverlag.at/onlineprodukt/swk-spezial-registrierkassen-und-belegerteilungspflicht-1378 -Ritz/Koran/Kutschera, SWK-Spezial Registrierkassen- und Belegerteilungspflicht, 1. Auflage 2016, Linde Verlag Wien. ISBN: 9783707333763 \ No newline at end of file +Ritz/Koran/Kutschera, SWK-Spezial Registrierkassen- und Belegerteilungspflicht, 1. Auflage 2016, Linde Verlag Wien. ISBN: 9783707333763 From c2516ff271123a65b978c5c1e3f3fa8b13f6014f Mon Sep 17 00:00:00 2001 From: Tom Schmiedlechner Date: Tue, 12 May 2020 11:40:48 +0200 Subject: [PATCH 07/10] Publish logs before documentation --- azure-pipelines.yml | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/azure-pipelines.yml b/azure-pipelines.yml index c6fcfbe4..5b5eb2d7 100644 --- a/azure-pipelines.yml +++ b/azure-pipelines.yml @@ -57,14 +57,13 @@ steps: Start-Process docfx -Wait -RedirectStandardError $(Build.ArtifactStagingDirectory)/docfx-err.log -RedirectStandardOutput $(Build.ArtifactStagingDirectory)/docfx-out.log displayName: Run docfx -- task: PublishBuildArtifacts@1 - displayName: 'Publish Artifact: documentation' - inputs: - PathtoPublish: '_site_pdf/' - ArtifactName: documentation - - task: PublishBuildArtifacts@1 displayName: 'Publish Artifact: logs' inputs: ArtifactName: logs +- task: PublishBuildArtifacts@1 + displayName: 'Publish Artifact: documentation' + inputs: + PathtoPublish: '_site_pdf/' + ArtifactName: documentation From c975ac97f1a71bde54d1ee3327f01823565ccf9d Mon Sep 17 00:00:00 2001 From: Tom Schmiedlechner Date: Tue, 12 May 2020 11:57:43 +0200 Subject: [PATCH 08/10] Only run PDF build --- azure-pipelines.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/azure-pipelines.yml b/azure-pipelines.yml index 5b5eb2d7..267e296d 100644 --- a/azure-pipelines.yml +++ b/azure-pipelines.yml @@ -54,7 +54,7 @@ steps: filePath: 'set-chapter-numbers.ps1' - powershell: | - Start-Process docfx -Wait -RedirectStandardError $(Build.ArtifactStagingDirectory)/docfx-err.log -RedirectStandardOutput $(Build.ArtifactStagingDirectory)/docfx-out.log + Start-Process docfx -ArgumentList "pdf" -Wait -RedirectStandardError $(Build.ArtifactStagingDirectory)/docfx-err.log -RedirectStandardOutput $(Build.ArtifactStagingDirectory)/docfx-out.log displayName: Run docfx - task: PublishBuildArtifacts@1 From 35e7828675103e0f7202e5aa2c41e3c9d9da6fea Mon Sep 17 00:00:00 2001 From: Tom Schmiedlechner Date: Tue, 12 May 2020 12:16:36 +0200 Subject: [PATCH 09/10] Fix version of PlantUml plugin --- azure-pipelines.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/azure-pipelines.yml b/azure-pipelines.yml index 267e296d..a56d85dd 100644 --- a/azure-pipelines.yml +++ b/azure-pipelines.yml @@ -46,7 +46,7 @@ steps: # Specific version can be removed as soon as 0.12.6 is released choco install wkhtmltopdf --version 0.12.4.20170325 --allow-downgrade -y choco install docfx --version 2.41 -y - nuget install DocFx.Plugins.PlantUml -ExcludeVersion -OutputDirectory . + nuget install DocFx.Plugins.PlantUml -Version "1.1.19" -ExcludeVersion -OutputDirectory . displayName: 'Install prerequisites' - task: PowerShell@2 From 14c69f7857ce983caeb3997d86ecfa54cffa346d Mon Sep 17 00:00:00 2001 From: Christian Rogobete Date: Thu, 14 May 2020 10:45:29 +0200 Subject: [PATCH 10/10] update customer data to DSFinV-K --- .../dsfinv-k-generation.md | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md b/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md index e3853e45..4a9263ad 100644 --- a/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md +++ b/doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md @@ -39,14 +39,14 @@ This chapter lists the data fields that are mandatory and must be provided by th | `BON_START` | Single recordings | Mandatory if the action (DE: Vorgang) starts within another system. Otherwise the receipt request of an action must be connected in a way that ft can find the start of the action.| | `BEDIENER_NAME` | Single recordings | User name | | `AGENTUR_ID` | Single recordings | ID of the agency, only mandatory if agency business (DE: Agenturgeschäft) | -| `KUNDE_NAME` | Single recordings | Full name of the beneficiary customer. Not mandatory if exempted in relation to § 148 AO. | -| `KUNDE_ID` | Single recordings | ID of the beneficiary customer. Not mandatory if exempted in relation to § 148 AO.| -| `KUNDE_TYP` | Single recordings | Type of the beneficiary customer (e.g. employee). Not mandatory if exempted in relation to § 148 AO.| -| `KUNDE_STRASSE` | Single recordings | Street and house number of the beneficiary customer. Not mandatory if exempted in relation to § 148 AO. | -| `KUNDE_PLZ` | Single recordings | Zip of the beneficiary customer. Not mandatory if exempted in relation to § 148 AO. | -| `KUNDE_ORT` | Single recordings | City of the beneficiary customer. Not mandatory if exempted in relation to § 148 AO. | -| `KUNDE_LAND` | Single recordings | Country of the beneficiary customer. Not mandatory if exempted in relation to § 148 AO. | -| `KUNDE_USTID` | Single recordings | VAT-ID of the beneficiary customer. Not mandatory if exempted in relation to § 148 AO. | +| `KUNDE_NAME` | Single recordings | Full name of the beneficiary customer. Mandatory if available. See also AEAO to § 146 | +| `KUNDE_ID` | Single recordings | ID of the beneficiary customer. Mandatory if available. See also AEAO to § 146| +| `KUNDE_TYP` | Single recordings | Type of the beneficiary customer (e.g. employee). Mandatory if available. See also AEAO to § 146 | +| `KUNDE_STRASSE` | Single recordings | Street and house number of the beneficiary customer. Mandatory if available. See also AEAO to § 146 | +| `KUNDE_PLZ` | Single recordings | Zip of the beneficiary customer. Mandatory if available. See also AEAO to § 146 | +| `KUNDE_ORT` | Single recordings | City of the beneficiary customer. Mandatory if available. See also AEAO to § 146 | +| `KUNDE_LAND` | Single recordings | Country of the beneficiary customer. Mandatory if available. See also AEAO to § 146 | +| `KUNDE_USTID` | Single recordings | VAT-ID of the beneficiary customer. Mandatory if available. See also AEAO to § 146 | | `ABRECHNUNGSKREIS` | Single recordings | Connection criterion of the assignment. | | `ZAHLWAEH_CODE` | Single recordings | Foreign currency code. Only mandatory if foreign currency was used for the payment. | | `ZAHLWAEH_BETRAG` | Single recordings | Amount in foreign currency. Only mandatory if foreign currency was used for the payment. | @@ -171,14 +171,14 @@ Each subitem as described in the table below: | `BEDIENER_ID` | User-ID | String (50) | Optional. To send, pls. add the key value pair `UserId` e.g. `"ftReceiptCaseData":"{ ..., "UserId":192, ... }"`. If not sent, the ft will automatically generate a User-ID (hash) deducted from `cbUser` | | `BEDIENER_NAME` | User name | String (50) | Mandatory, please send via `cbUser` | | `UMS_BRUTTO` | Gross total turnover | Decimal (2) | Automatically filled by ft | -| `KUNDE_NAME` | Name of beneficiary customer | String (50) | Mandatory if not exempted in relation to § 148 AO. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerName` e.g. `"cbCustomer":"{"CustomerName":"Max Wanne",...}"`| -| `KUNDE_ID` | ID of the beneficiary customer| String (50) | Mandatory if not exempted in relation to § 148 AO. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerId` e.g. `"cbCustomer":"{"customerName":"Max Mustermann", "CustomerId":"PX9819822", ...}"`| -| `KUNDE_TYP` | Type of the beneficiary customer (e.g. employee) | String (50) | Mandatory if not exempted in relation to § 148 AO. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerType` e.g. `"cbCustomer":"{..., "CustomerId":"PX9819822", "CustomerType":"Mitarbeiter", ...}"`| -| `KUNDE_STRASSE` | Street and house number of the beneficiary customer | String (60) | Mandatory if not exempted in relation to § 148 AO. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerStreet` e.g. `"cbCustomer":"{..., "CustomerStreet":"Lindwurmstr. 98", ...}"` | -| `KUNDE_PLZ` | Zip of the beneficiary customer | String (10) | Mandatory if not exempted in relation to § 148 AO. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerZip` e.g. `"cbCustomer":"{..., "CustomerZip":"80337", ...}"` | -| `KUNDE_ORT` | City of the beneficiary customer | String (62) | Mandatory if not exempted in relation to § 148 AO. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerCity` e.g. `"cbCustomer":"{..., "CustomerCity":"München", ...}"` | -| `KUNDE_LAND` | Country of the beneficiary customer | ISO 3166 ALPHA-3 country code | Mandatory if not exempted in relation to § 148 AO. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerCountry` e.g. `"cbCustomer":"{..., "CustomerCountry":"DEU", ...}"` | -| `KUNDE_USTID` | VAT-ID of the beneficiary customer | String (15) | Mandatory if not exempted in relation to § 148 AO. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerVATId` e.g. `"cbCustomer":"{..., "CustomerVATId":"DE123456789", ...}"` | +| `KUNDE_NAME` | Name of beneficiary customer | String (50) | Mandatory if available. See also AEAO to § 146. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerName` e.g. `"cbCustomer":"{"CustomerName":"Max Wanne",...}"`| +| `KUNDE_ID` | ID of the beneficiary customer| String (50) | Mandatory if available. See also AEAO to § 146. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerId` e.g. `"cbCustomer":"{"customerName":"Max Mustermann", "CustomerId":"PX9819822", ...}"`| +| `KUNDE_TYP` | Type of the beneficiary customer (e.g. employee) | String (50) | Mandatory if available. See also AEAO to § 146. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerType` e.g. `"cbCustomer":"{..., "CustomerId":"PX9819822", "CustomerType":"Mitarbeiter", ...}"`| +| `KUNDE_STRASSE` | Street and house number of the beneficiary customer | String (60) | Mandatory if available. See also AEAO to § 146. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerStreet` e.g. `"cbCustomer":"{..., "CustomerStreet":"Lindwurmstr. 98", ...}"` | +| `KUNDE_PLZ` | Zip of the beneficiary customer | String (10) | Mandatory if available. See also AEAO to § 146. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerZip` e.g. `"cbCustomer":"{..., "CustomerZip":"80337", ...}"` | +| `KUNDE_ORT` | City of the beneficiary customer | String (62) | Mandatory if available. See also AEAO to § 146. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerCity` e.g. `"cbCustomer":"{..., "CustomerCity":"München", ...}"` | +| `KUNDE_LAND` | Country of the beneficiary customer | ISO 3166 ALPHA-3 country code | Mandatory if available. See also AEAO to § 146. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerCountry` e.g. `"cbCustomer":"{..., "CustomerCountry":"DEU", ...}"` | +| `KUNDE_USTID` | VAT-ID of the beneficiary customer | String (15) | Mandatory if available. See also AEAO to § 146. Send via `cbCustomer` in JSON format by adding the key value pair `CustomerVATId` e.g. `"cbCustomer":"{..., "CustomerVATId":"DE123456789", ...}"` | | `BON_NOTIZ` | Additional information on the receipt header | String (255) | Optional, can be sent via `ftReceiptCaseData` in JSON format. To send, add the key value pair `ReceiptNote ` e.g. `"ftReceiptCaseData":"{ ..., "ReceiptNote":"123, ich bin dabei!", ... }"` | ##### File: Bonkopf_USt (transactions_vat.csv)