fiskaltrust/interface-doc

The technical specification of the data interface that describes how to integrate the fiskaltrust Middleware into POS systems.

fiskaltrust interface documentation

Welcome to the open-source documentation of the fiskaltrust interface!

This repository aims to provide a detailed technical specification of the fiskaltrust data interface used by POS-Systems to interact with the fiskaltrust.Middleware, so that PosCreators can integrate the fiskaltrust.Middleware into their systems without further support in most cases.

The technical specification of the data interface described in this document provides information regarding the following areas:

1. Access to the fiskaltrust.Middleware
2. Integration into the receipt based cash register workflow
3. The data structure
4. Function structure of the interface
5. Types of communication with fiskaltrust.Middleware
6. Operating categories Interface specification is provided by fiskaltrust.Interface NuGet package, which can be found at https://www.nuget.org/packages/fiskaltrust.interface

Official PDF documents that are built from the source in this repository can be found on the Releases page.

Contributions

By reviewing this README file in order to understand its structure and which tools are being used, you are contributing to improving this documentation.

Repository structure

The repository is built using docusaurus. All documentation files are stored within the /doc folder in this repository (markdown, images, other static content).

You need to add a slug and title in the yaml fromtmatter of your files and possibly adapt the toc.js file.

References

A reference to a markdown file can be created like this: [Reference Text](./path-to-file/filename.md).

Note that reference paths should be relative.

If you want to reference something specific inside a markdown file, you need to create an anchor to which you want your reference to point. Anchors can be created like this: <span id="anchor-name">Referenced Item</span>.

Tools

markdown-link-check

With markdown-link-ckeck you can check a markdown file for incorrect links. usage:

markdown-link-check ./general/general.md

Please note that this tool does not find dead references inside a file. Only dead references to nonexisting files / unreachable URLs.

Further public fiskaltrust repositories

The following list shows further fiskaltrust repositories that are important for our customers.

Github repo	Goal/Purpose	Content
fiskaltrust/productdescription-de-doc	Goal of this repository is to help our customers to get familiar with our products and services for the german market. It should also help our customers apply the products and services described here.	The repository contains descriptions of the offered products and services by fiskaltrust for the german market. It also contains accompanying materials such as how-to guides, price lists, concepts, and presentations that help our customers integrate the offered products and services into their products and services.
fiskaltrust/faq	The purpose of this repository is to provide information on our customers' frequent questions or concerns.	The repo contains unsorted but tagged question and answer sets. If the answer's content already exists in another public fiskaltrust repository, that content is linked in the solution. The content of this repo is also rendered and presented in the docs.fiskaltrust portal.

interface-doc's Issues

Extend german interface documentation

define ftState, exception handling not available or not detailed enough, explain http handling...

“35 Appendix: DE” Reference to DSFinV-K is missing

Extend source reference by DSFinV-K

Describe response better

Response and the data on how to get back better described.
Example Zero Receipt, Daily Closing, ...

When will the DieboldNixdorf TSE package be available in the live Portal?

The version list is currently empty

I think it's because of the RC state?

Non-existent values at ftReceiptCase

Nevertheless (like others) it is listed in the ftReceiptCase list. Even an experienced colleague from Vienna accidentally used this wrong value because the docu confuses / misleads at first glance.
A receipt request (ftReceiptCase) 0x4445000000000003 does not exist at all!

Calls such as 0x4445000000000003 (initial operation receipt) etc. may ONLY be called implicitly, that is 0x4445000100000003. Why are users confused by mentioning these values without the implicit flag.

FR Appendix - Reference tables

In the table 34.1.3 Type of Payment: ftPayItemCase the following items are treated in a different way.

• 0x4652000000000004 "debit card payment" noncash
• 0x4652000000000005 "credit card payment" cash
• 0x4652000000000009 "other debit card" noncash
• 0x465200000000000A "other credit card" cash

Why is there a difference in means of payment in debit & credit card?

Necessary attribute names for DsFinV-K are are not defined.

The middleware has to identify the necessary DsFinV-K field-names, but they are still not defined in interface doku and poscreator send strings or json-strings on their own. So it will be impossible for the programmes to extract the right DsFinV-K informations in produktion environment out of a string. JSON key-names have to be defined as early as possible.

AVBelegstorno can not be used

AVBelegstorno is used in the list of ftReceiptCaseFlags in the german appendix, but AVBelegstorno is not allowed for cash registers that are connected to a TSE.

From DFKA Taxonomie Kassendaten doc and from DSFinV-K doc:
Achtung! Sobald eine TSE an einer Kasse eingesetzt wird, ist es technisch nicht mehr möglich, den Transaktionstyp „AVBelegstorno“ korrekt zu verwenden, da jeder Beleg schon vor dem Setzen des Storno- Kennzeichens bereits durch die TSE signiert wurde. Insofern ist ein nachträgliches „Nullen“ eines Beleges nicht mehr möglich.

In my opinion, the flag 0x0000000000040000 should be removed.

No sample JSONS available

Add a few example JSONS or reference to the interface documentation

Please describe and implement Tagesabschluss

No introduction / instructions

Quick Start Guide (own doc)
Quick practical introduction for the developer (10 points)
Set up cashbox
Set up a queue
Set up TSE
Set up helper
Download demo examples (JSON)

Fiskaltrust Service + Queue requiered on each till?

Hi all. I wanted to install the FT Service including Queue and TSE on our POS Server and all tills of the shop have to call the webservice of the server. So there wont be any FT component at the till computer.

But now I saw this structure which describes a queue on each till + the TSE at the server.

https://github.com/fiskaltrust/productdescription-de-doc/blob/11b278cf6f4d3c9db916aec52445ea1237ffbefb/for-posdealers/02-pre-sales/rollout-scenarios.md

Please let me know how to do. In the shops we have a POS/DB Server + n-tills

How will the VAT be calculated in special cases?

doc/appendix-de-kassensichv/procedural-documentation/dsfinv-k-generation.md

For the DSFinV-K-Export, the VAT has to be indicate in the following fields.
POS_UST
ZI_BASISPREIS_UST
BON_UST
Z_UST

In some special cases (e.g. car spare part in the car repair shop) of taxation, the VAT ist not a percentage of the net-price (NETTO) or the gross-price.
The the VATAmount has to be used in the json-request to transmit the correct information.

rule:
when DSFinV-K Umsatzsteuer-ID = "7" & VATRate = "0", then POS_UST = VATAmount (mandatory)

What workflow do you recomend for till process?

We are running a standard trading cash register and processes are normaly handled quite fast.
A customer comes to the till with 1-n items, we scan them and the customer pays within a few minutes.
But sometimes items are scanned into an order and the order will be put "on hold".
Im some cases they stay on hold for a few, days, or weeks, before the get payd by the customer or sometimes there will be deleted and never get payed.

I think it's not a good idea to start a transaction on the first item scan, otherwise we will have many unfinished transactions.
I think this workflow will be the best for our cases. What du you think?

Or do you think it's possible to just send a pos-receipt without info-order right after the customer payed? I'm afraid that will not be in the sense of the KassenSichV ?

For development we are running the sandbox with online TSE and sending an info-order request takes about 1-3 seconds which will slow down the till. Maybe this will be faster on a more performant server with a lokal TSE!?

Many thanks!

DSFinV-K: UST_SCHLUESSEL 7 is only for receivable reduction (DE: Forderungsauflösungen)

Only the charge item case 0x444500000000007F is allowed to be mapped to UST_SCHLUESSEL 7. All others that map to UST_SCHLUESSEL 7 are not allowed to use 7 and should be deleted or changed. (AKU + CRO)

From DSFinV-K specification:

Die ID 7 dient der Kennzeichnung von Forderungsauflösungen, deren umsatzsteuerliche Zuordnung von der Kasse nicht dargestellt werden kann.

Which ReceiptCase for initial operation receipt / start-receipt ?

Hi all, which ReceiptCase should be used for an initial operation receipt?
The doc fiskaltrust-Business-Cases-in-JSON_deutsch_2020-03-03.pdf describes 0x4445000100000003, but the appendix describes 0x4445000000000003

The same for out of operation receipt:
Doc: 0x4445000100000004
Appendix: 0x4445000000000004

Thanks!

Could you please translate this page to 100% into English?

https://github.com/fiskaltrust/interface-doc/blob/master/doc/appendix-de-kassensichv/reference-tables/type-of-signature-ftsignaturetype.md/#L1

Thanks!

Describe and implement the DsFinV-K export

How to do manual Cash-In / -Out payments

I'm going to use the ReceiptCase 0x4445000000000011 (implicit) without ChargeItems. Instead of ChargeItems I'll use PayItemCase 0x4445000000000016 but I'm confused about the description:
negative amount gets converted to GV_TYP=Einzahlung.
positive amount gets converted to GV_TYP=Auszahlung. amount=-amount. in case of void-receipt everything turned

In my opinion a positive amount have to be converted to a "Einzahlung" !?

Service wording should be replaced with 'Middleware'

We're still using the term "fiskaltrust Service" at many places. It should be replaced with "fiskaltrust Middleware".

Search in the document problematic, error prone, because all markets in one document.

Separation for each target market (country) a document (in EN and in the national language).
or place the respective abbreviations AT, FR, DE on each page

It would be good, as long as the AT, FR, DE document is in a pdf, to provide each page in the header or footer area with the respective abbreviation (AT, FR, DE) so that you can see at a glance whether you are in the document moved in the right country.

Update System Requirements for the German service

P.34 .NET version 4.0 still up to date? Which operating systems from which version are supported?

For example: System Requirements
.NET 4.6.1 Minimum requirement for the German service

Extend hexadecimal values by decimal values

To improve our interface documentation. Write the decimal value below for the hexadecimal value (ReceiptCase, ChargeItemCase, PayItemCase...). So that no conversion is necessary

“35.3.3 Type of Service: ftChargeItemCase” => VAT concept

Customers repeatedly ask how different VAT rates are represented; Introduction for 35.3.3 would be useful to explain the concept (in advance): All 7 VAT keys are repeated for different ChargeItem groups (sales, deposit, etc.)

Difference explicit to implicit

Explain the difference explicitly to implicit more precisely

There is no description for getting the export file DsFinV-K

Some of the customers/poscreators want to finish work with our middleware, but the DsFinV-K export is neither described nor implemented.

"Partner-FAQ"

Hello.
In your FAQ is a small failure in the text of the button four in point 9 "Workflow zur Einrichtung einer neue CashBox". The text is "Signaturerstellungseinheit zuordnen" instead of "Gebrauchte deutsche Signaturerstellungseinheit“. It was a little bit confusing me.

With regards
Heiko Krueger

running a Diebold Nixdorf TSE in Sandbox

Hi, I'm trying to set up a Diebold Nixdorf TSE in the sandbox. It's connected to COM8.

But when I start the service I will get this warnings (errors?)
Whats wrong?

2020-08-11 10:31:30 [INF] Loading Queue Id 76f0e6aa-a411-4693-a1a2-90cbaba9774c from Package fiskaltrust.Middleware.Queue.SQLite, Version 1.3.4 2020-08-11 10:31:30 [INF] Create Queue 76f0e6aa-a411-4693-a1a2-90cbaba9774c 2020-08-11 10:31:31 [WRN] Sending -----> Command: SetAsb; RequestId: 380d7771-4462-4ff9-965a-f3b755bd8c8d; Body: 1B-90-30-30-33-1B-92-30-1B-99-33-38-30-64-37-37-37-31-2D-34-34-36-32-2D-34-66-66-39-2D-39-36-35-61-2D-66-33-62-37-35-35-62-64-38-63-38-64-1B-9D-1B-9F 2020-08-11 10:31:31 [WRN] Received -----> Command: SetAsb; RequestId: 380d7771-4462-4ff9-965a-f3b755bd8c8d; Body: 1B-91-30-30-33-1B-99-33-38-30-64-37-37-37-31-2D-34-34-36-32-2D-34-66-66-39-2D-39-36-35-61-2D-66-33-62-37-35-35-62-64-38-63-38-64-1B-9F 2020-08-11 10:31:31 [WRN] Sending -----> Command: ExportWeird_NoClueWhatThisIsUnDocumented1; RequestId: f2c992f8-c48e-41fb-9039-fef90e7f7935; Body: 1B-90-33-30-39-1B-92-31-1B-99-66-32-63-39-39-32-66-38-2D-63-34-38-65-2D-34-31-66-62-2D-39-30-33-39-2D-66-65-66-39-30-65-37-66-37-39-33-35-1B-9D-1B-9F 2020-08-11 10:31:33 [WRN] Failed to receive a response for ExportWeird_NoClueWhatThisIsUnDocumented1 2020-08-11 10:31:33 [WRN] Sending -----> Command: GetMfcStatus; RequestId: 79ac865e-a8b6-40f9-a08b-dc2bb6a07767; Body: 1B-90-30-30-31-1B-99-37-39-61-63-38-36-35-65-2D-61-38-62-36-2D-34-30-66-39-2D-61-30-38-62-2D-64-63-32-62-62-36-61-30-37-37-36-37-1B-9D-1B-9F 2020-08-11 10:31:33 [WRN] Received -----> Command: GetMfcStatus; RequestId: 79ac865e-a8b6-40f9-a08b-dc2bb6a07767; Body: 1B-91-30-30-31-1B-92-30-30-30-33-1B-92-30-30-1B-99-37-39-61-63-38-36-35-65-2D-61-38-62-36-2D-34-30-66-39-2D-61-30-38-62-2D-64-63-32-62-62-36-61-30-37-37-36-37-1B-9F 2020-08-11 10:31:33 [WRN] Sending -----> Command: GetMfcStatus; RequestId: 84fe6051-a1c9-44e0-b9fc-4cbeedfc134b; Body: 1B-90-30-30-31-1B-99-38-34-66-65-36-30-35-31-2D-61-31-63-39-2D-34-34-65-30-2D-62-39-66-63-2D-34-63-62-65-65-64-66-63-31-33-34-62-1B-9D-1B-9F 2020-08-11 10:31:33 [WRN] Received -----> Command: GetMfcStatus; RequestId: 84fe6051-a1c9-44e0-b9fc-4cbeedfc134b; Body: 1B-91-30-30-31-1B-92-30-30-30-30-1B-92-30-30-1B-99-38-34-66-65-36-30-35-31-2D-61-31-63-39-2D-34-34-65-30-2D-62-39-66-63-2D-34-63-62-65-65-64-66-63-31-33-34-62-1B-9F 2020-08-11 10:31:33 [WRN] Sending -----> Command: GetMfcStatus; RequestId: 9f160fca-999c-4548-9cd6-22354a1b256b; Body: 1B-90-30-30-31-1B-99-39-66-31-36-30-66-63-61-2D-39-39-39-63-2D-34-35-34-38-2D-39-63-64-36-2D-32-32-33-35-34-61-31-62-32-35-36-62-1B-9D-1B-9F 2020-08-11 10:31:33 [WRN] Received -----> Command: GetMfcStatus; RequestId: 9f160fca-999c-4548-9cd6-22354a1b256b; Body: 1B-91-30-30-31-1B-92-30-30-30-30-1B-92-30-30-1B-99-39-66-31-36-30-66-63-61-2D-39-39-39-63-2D-34-35-34-38-2D-39-63-64-36-2D-32-32-33-35-34-61-31-62-32-35-36-62-1B-9F 2020-08-11 10:31:33 [WRN] Sending -----> Command: SetAsb; RequestId: 51680ef5-cebe-4245-87e7-e70e53c9ea8c; Body: 1B-90-30-30-33-1B-92-30-1B-99-35-31-36-38-30-65-66-35-2D-63-65-62-65-2D-34-32-34-35-2D-38-37-65-37-2D-65-37-30-65-35-33-63-39-65-61-38-63-1B-9D-1B-9F 2020-08-11 10:31:33 [WRN] Received -----> Command: SetAsb; RequestId: 51680ef5-cebe-4245-87e7-e70e53c9ea8c; Body: 1B-91-30-30-33-1B-99-35-31-36-38-30-65-66-35-2D-63-65-62-65-2D-34-32-34-35-2D-38-37-65-37-2D-65-37-30-65-35-33-63-39-65-61-38-63-1B-9F 2020-08-11 10:31:33 [WRN] Sending -----> Command: SetClientId; RequestId: c144f5a4-f410-43cb-9769-ad32b60959a6; Body: 1B-90-35-30-39-1B-92-66-69-73-6B-61-6C-74-72-75-73-74-2E-4D-69-64-64-6C-65-77-61-72-65-1B-99-63-31-34-34-66-35-61-34-2D-66-34-31-30-2D-34-33-63-62-2D-39-37-36-39-2D-61-64-33-32-62-36-30-39-35-39-61-36-1B-9D-1B-9F 2020-08-11 10:31:33 [WRN] Received -----> Command: SetClientId; RequestId: c144f5a4-f410-43cb-9769-ad32b60959a6; Body: 1B-91-35-30-39-1B-99-63-31-34-34-66-35-61-34-2D-66-34-31-30-2D-34-33-63-62-2D-39-37-36-39-2D-61-64-33-32-62-36-30-39-35-39-61-36-1B-9F 2020-08-11 10:31:33 [WRN] Sending -----> Command: GetTimeUntilNextSelfTest; RequestId: a2fdf289-5157-496f-b023-8291e7c29641; Body: 1B-90-35-30-38-1B-99-61-32-66-64-66-32-38-39-2D-35-31-35-37-2D-34-39-36-66-2D-62-30-32-33-2D-38-32-39-31-65-37-63-32-39-36-34-31-1B-9D-1B-9F 2020-08-11 10:31:33 [WRN] Received -----> Command: GetTimeUntilNextSelfTest; RequestId: a2fdf289-5157-496f-b023-8291e7c29641; Body: 1B-91-35-30-38-1B-92-30-30-30-30-30-39-30-30-30-30-1B-99-61-32-66-64-66-32-38-39-2D-35-31-35-37-2D-34-39-36-66-2D-62-30-32-33-2D-38-32-39-31-65-37-63-32-39-36-34-31-1B-9F 2020-08-11 10:31:33 [WRN] Sending -----> Command: GetTimeUntilNextSelfTest; RequestId: a93afd28-7086-4cf3-b4e3-6de8ef7c58b4; Body: 1B-90-35-30-38-1B-99-61-39-33-61-66-64-32-38-2D-37-30-38-36-2D-34-63-66-33-2D-62-34-65-33-2D-36-64-65-38-65-66-37-63-35-38-62-34-1B-9D-1B-9F 2020-08-11 10:31:33 [WRN] Received -----> Command: GetTimeUntilNextSelfTest; RequestId: a93afd28-7086-4cf3-b4e3-6de8ef7c58b4; Body: 1B-91-35-30-38-1B-92-30-30-30-30-30-39-30-30-30-30-1B-99-61-39-33-61-66-64-32-38-2D-37-30-38-36-2D-34-63-66-33-2D-62-34-65-33-2D-36-64-65-38-65-66-37-63-35-38-62-34-1B-9F 2020-08-11 10:31:33 [WRN] Sending -----> Command: GetMfcStatus; RequestId: 5e745a1b-21fe-44f9-b9d8-43072e489d9d; Body: 1B-90-30-30-31-1B-99-35-65-37-34-35-61-31-62-2D-32-31-66-65-2D-34-34-66-39-2D-62-39-64-38-2D-34-33-30-37-32-65-34-38-39-64-39-64-1B-9D-1B-9F 2020-08-11 10:31:33 [WRN] Received -----> Command: GetMfcStatus; RequestId: 5e745a1b-21fe-44f9-b9d8-43072e489d9d; Body: 1B-91-30-30-31-1B-92-30-30-30-30-1B-92-30-30-1B-99-35-65-37-34-35-61-31-62-2D-32-31-66-65-2D-34-34-66-39-2D-62-39-64-38-2D-34-33-30-37-32-65-34-38-39-64-39-64-1B-9F 2020-08-11 10:31:33 [WRN] Sending -----> Command: GetMfcStatus; RequestId: fe8b3533-8f1e-4e0d-84d3-4b42ac078c0d; Body: 1B-90-30-30-31-1B-99-66-65-38-62-33-35-33-33-2D-38-66-31-65-2D-34-65-30-64-2D-38-34-64-33-2D-34-62-34-32-61-63-30-37-38-63-30-64-1B-9D-1B-9F 2020-08-11 10:31:33 [WRN] Received -----> Command: GetMfcStatus; RequestId: fe8b3533-8f1e-4e0d-84d3-4b42ac078c0d; Body: 1B-91-30-30-31-1B-92-30-30-30-30-1B-92-30-30-1B-99-66-65-38-62-33-35-33-33-2D-38-66-31-65-2D-34-65-30-64-2D-38-34-64-33-2D-34-62-34-32-61-63-30-37-38-63-30-64-1B-9F 2020-08-11 10:31:33 [WRN] Sending -----> Command: GetSlotInfo; RequestId: e81eccc8-c397-4aa7-b2ad-68ea312a3a1a; Body: 1B-90-31-30-39-1B-92-31-1B-99-65-38-31-65-63-63-63-38-2D-63-33-39-37-2D-34-61-61-37-2D-62-32-61-64-2D-36-38-65-61-33-31-32-61-33-61-31-61-1B-9D-1B-9F 2020-08-11 10:31:33 [WRN] Received -----> Command: GetSlotInfo; RequestId: e81eccc8-c397-4aa7-b2ad-68ea312a3a1a; Body: 1B-91-31-30-39-1B-92-30-33-1B-92-30-30-1B-92-30-1B-92-30-30-30-31-30-30-30-33-30-30-30-31-30-30-30-34-1B-92-30-30-36-39-37-39-33-32-31-38-35-36-1B-92-30-30-36-39-37-39-33-32-31-38-35-36-1B-92-32-30-2E-30-37-2E-32-30-32-37-20-32-33-3A-35-39-3A-35-39-1B-92-30-30-31-39-39-39-39-39-39-34-1B-92-65-63-64-73-61-2D-70-6C-61-69-6E-2D-53-48-41-33-38-34-1B-99-65-38-31-65-63-63-63-38-2D-63-33-39-37-2D-34-61-61-37-2D-62-32-61-64-2D-36-38-65-61-33-31-32-61-33-61-31-61-1B-9F 2020-08-11 10:31:38 [WRN] Sending -----> Command: GetMfcStatus; RequestId: fdac02e0-a9e1-4231-9263-737e86f69a01; Body: 1B-90-30-30-31-1B-99-66-64-61-63-30-32-65-30-2D-61-39-65-31-2D-34-32-33-31-2D-39-32-36-33-2D-37-33-37-65-38-36-66-36-39-61-30-31-1B-9D-1B-9F 2020-08-11 10:31:38 [WRN] Received -----> Command: GetMfcStatus; RequestId: fdac02e0-a9e1-4231-9263-737e86f69a01; Body: 1B-91-30-30-31-1B-92-30-30-30-30-1B-92-30-30-1B-99-66-64-61-63-30-32-65-30-2D-61-39-65-31-2D-34-32-33-31-2D-39-32-36-33-2D-37-33-37-65-38-36-66-36-39-61-30-31-1B-9F 2020-08-11 10:31:38 [WRN] Sending -----> Command: SetAsb; RequestId: c7b86852-7e88-4469-bd2e-56aa5d6db934; Body: 1B-90-30-30-33-1B-92-30-1B-99-63-37-62-38-36-38-35-32-2D-37-65-38-38-2D-34-34-36-39-2D-62-64-32-65-2D-35-36-61-61-35-64-36-64-62-39-33-34-1B-9D-1B-9F 2020-08-11 10:31:38 [WRN] Received -----> Command: SetAsb; RequestId: c7b86852-7e88-4469-bd2e-56aa5d6db934; Body: 1B-91-30-30-33-1B-99-63-37-62-38-36-38-35-32-2D-37-65-38-38-2D-34-34-36-39-2D-62-64-32-65-2D-35-36-61-61-35-64-36-64-62-39-33-34-1B-9F 2020-08-11 10:31:38 [WRN] Sending -----> Command: GetMfcStatus; RequestId: 45f1280f-597f-4162-9e35-8074ae56d2b2; Body: 1B-90-30-30-31-1B-99-34-35-66-31-32-38-30-66-2D-35-39-37-66-2D-34-31-36-32-2D-39-65-33-35-2D-38-30-37-34-61-65-35-36-64-32-62-32-1B-9D-1B-9F 2020-08-11 10:31:38 [WRN] Received -----> Command: GetMfcStatus; RequestId: 45f1280f-597f-4162-9e35-8074ae56d2b2; Body: 1B-91-30-30-31-1B-92-30-30-30-30-1B-92-30-30-1B-99-34-35-66-31-32-38-30-66-2D-35-39-37-66-2D-34-31-36-32-2D-39-65-33-35-2D-38-30-37-34-61-65-35-36-64-32-62-32-1B-9F 2020-08-11 10:31:38 [WRN] Sending -----> Command: GetSlotInfo; RequestId: a38ef6ec-5d42-41c5-8a85-29e06097dc06; Body: 1B-90-31-30-39-1B-92-31-1B-99-61-33-38-65-66-36-65-63-2D-35-64-34-32-2D-34-31-63-35-2D-38-61-38-35-2D-32-39-65-30-36-30-39-37-64-63-30-36-1B-9D-1B-9F 2020-08-11 10:31:38 [WRN] Received -----> Command: GetSlotInfo; RequestId: a38ef6ec-5d42-41c5-8a85-29e06097dc06; Body: 1B-91-31-30-39-1B-92-30-33-1B-92-30-30-1B-92-30-1B-92-30-30-30-31-30-30-30-33-30-30-30-31-30-30-30-34-1B-92-30-30-36-39-37-39-33-32-31-38-35-36-1B-92-30-30-36-39-37-39-33-32-31-38-35-36-1B-92-32-30-2E-30-37-2E-32-30-32-37-20-32-33-3A-35-39-3A-35-39-1B-92-30-30-31-39-39-39-39-39-39-34-1B-92-65-63-64-73-61-2D-70-6C-61-69-6E-2D-53-48-41-33-38-34-1B-99-61-33-38-65-66-36-65-63-2D-35-64-34-32-2D-34-31-63-35-2D-38-61-38-35-2D-32-39-65-30-36-30-39-37-64-63-30-36-1B-9F 2020-08-11 10:31:38 [WRN] Failed to updated status of SCU (Url: grpc://localhost:1401/, Id: e8abd928-674f-4ce4-bae1-e03467c429ed). Will try again later... Grpc.Core.RpcException: Status(StatusCode=Unknown, Detail="An exception occured in the fiskaltrust.Middleware.") bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) bei ProtoBuf.Grpc.Internal.Reshape.<UnaryTaskAsyncImpl>d__102.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei fiskaltrust.Middleware.Interface.Client.Common.RetryLogic.DESSCDRetryProxyClient.<>c.<b__8_0>d.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei fiskaltrust.Middleware.Interface.Client.Common.RetryLogic.RetryPolicyHandler1.<>c__DisplayClass3_01.<b__0>d.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei fiskaltrust.Middleware.Interface.Client.Common.RetryLogic.RetryPolicyHandler1.<RetryFuncAsync>d__31.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei fiskaltrust.Middleware.Interface.Client.Common.RetryLogic.DESSCDRetryProxyClient.d__8.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei fiskaltrust.Middleware.Queue.Bootstrapper.Localization.QueueDEBootstrapper.d__4.MoveNext()
2020-08-11 10:31:38 [INF] gRPC Service: fiskaltrust.Middleware.Queue.SQLite (1.3.4) - Endpoint: grpc://localhost:1400
2020-08-11 10:31:39 [INF] REST Service: fiskaltrust.Middleware.Queue.SQLite (1.3.4) - Endpoint: rest://localhost:1500/ftrest, rest://localhost:1500/ftrest/json, rest://localhost:1500/ftrest/xml
2020-08-11 10:31:39 [INF] Adding MEX-Endpoint http://localhost:1200/fiskaltrust/mex
2020-08-11 10:31:39 [INF] WCF Service: fiskaltrust.Middleware.Queue.SQLite (1.3.4) - Endpoint: http://localhost:1200/fiskaltrust
2020-08-11 10:31:39 [INF] StartEnd Helper c32204ee-63d9-48c2-b548-acfb389fa713
2020-08-11 10:31:39 [INF] fiskaltrust.Middleware started. Press a button to stop...`

ReceiptCase zero-receipt

Hi all,

the ReceiptCase of the zero-receipt should be (implicit) 0x4445000100000002 (4919338172267102210).
This works. I get a receipt but with less information as shown in the webinar of the 03.06.2020. e.g. I can't see the open transactions.

In the webinar they used 0x4445000100800002 (4919338172275490818) which I can't find in any doc from fiskaltrust!?
If I use this case, I will get the ftStateData as a response to see the open transactions.

ftPosSystemID - please allow to send with each receipt

Hi Fiskaltrust team,

We suggest to allow us sending the product information and software version in requests we pass on. It's tedious to do this manually in the portal. It's easier to manage and 100% correct this way.

when will a "receipt request" 0x0000800000000000 work on german version

The receipt request works perfect on austrian version, but not on german version. Will it work in the very near future?

Die Beleganfrage mit ReceiptCase 0x0000800000000000 funktioniert bestens in der österr. Version, aber noch nicht in der deutschen. Gibt es einen Zeitplan, bis wann das programmiert ist oder kommt die Beleganfrage nicht in die deutsche Version?

How to embed Sub JSON

Some of the interface fields are used as containers for subordinated JSON code; for example: cbUser, cbCustomer, cbArea, ftChargeItemCaseData and others. A period with an example would be helpful to convey the concept clearly (incl. \ ”For quotes with embedded JSONs) Receipt responses should be included

You can define own field names and values therein, embedded in subordinated JSON, e.g.:

“cbCustomer”: “{\”company\”: \”fiskaltrust\”, \”VAT-No\”: \”DE323821961\”, \”YourNumber\”: 123 }”

Backslashes are needed to insert subordinated quotes properly.
This writes the following script into cbCustomer (formatted):
{
“Company”: “fiskaltrust”,
“VAT-No”: “DE323821961”,
“YourNumber”: 123

It is not described for which ChargeItemcases whether and which values should be negated.

It must be described for which ChargeItemcases whether and which values should be negated. (For counter bookings, discounts, etc.)

cbUser field limits

hi, the way i understand the cbUser field describe in: https://docs.fiskaltrust.cloud/doc/interface-doc/doc/appendix-de-kassensichv/data-structures/data-structures.html?q=cbUser is that it is a mandatory String with 50 chars limit. Testing with the middleware i can send way more than 50 chars and also i can remove the field altogether ? How is that limit applied?

5.1.2.1 Zero Receipt (information about TSE) How is the information packed in the response.

Supported protocols grpc is missing

ftSignatureType - How does it work?

Hi everybody,

Could we please get more information on what to do with what is described here?
Samples?

https://github.com/fiskaltrust/interface-doc/blob/master/doc/appendix-de-kassensichv/reference-tables/type-of-signature-ftsignaturetype.md/#L1

ftPosSystemId mandatory for Germany

Shouldn't be this field in Germany mandatory? Because it is necessary to identify the software version the receipt is done.

B

Translate documentation to german

Our customers want German documentation, translate documentation to german

disclaimer doesn't match license

Can I void / redo a cash up? Kann ich einen Tagesabschluss wiederholen / korrigieren?

Is it possible to void a cash up receipt when a cash up is redone in the system the same day?

Germany API questions

1 - Regarding the fields in the API, can you confirm what you mean by “mandatory if applicable/if available? I assume if we don’t use these fields, they are not mandatory.

2 - Product barcode. If that our software’s product ID, or a universal product code (UPC)?

3 - How can we request a technical session with our developer?

No ftState for german market

cbReceiptIdentification - instead of cbReceiptReference

A wrong field Name "cbReceiptIdentification" instead of "cbReceiptReference" occurs twice, and has been used by clients already - seemingly (aka reportedly) without returning errors…
...apart from ruining their software's requests to the middleware when it comes to linking transactions of a process.

Which JSON-keywords are predefined?

FR Appendix duplicate

Two versions of the fr appendix exist ATM.

The version appendix-fr and appendix-fr-boi-tva-decl-30-10-30.

The version appendix-fr-boi-tva-decl-30-10-30 was created along the rest of the document. It follows the same formatting as the rest of the document.
This version has text references to old chapter numbers.

The version appendix-fr was created manually and has a different formatting for some parts.
This version has correct chapter links.

The content of both versions is the same as far as I can tell.

I propose removing the version appendix-fr.

Because is tax-relevant, no negative amount ist feasible for "down payment".

https://github.com/fiskaltrust/interface-doc/blob/master/doc/appendix-de-kassensichv/reference-tables/type-of-payment-ftpayitemcase.md

0x444500000000000F	down paymentnot taxableDSFinV-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 everyting turned. not valid for taxable down payments, where it is clearly defined what the service is for.

A negative amount is not feasible. - See DSFinV-K page 105 "04 Behandlung von Anzahlungen" and related example 4.

Flags unclear „35.3.2.1 ReceiptCaseFlag“

Flags unclear and without comment; Customers confused (e.g. “out of service”). More detailed explanation of how flags are used.

Please document German middleware error codes (ftState)

Please document German error code (ftState). In german section there is no error code of the middleware. In general there are three, so there are much missing (look at AT,FR documentation).