Gastro-MIS GmbH

Dieser Artikel dient dazu, genau darauf einzugehen, wie AmadeusVerify die Daten bei der DSFinV-K kontrolliert. Auch wir können die DSFinV-K nur interpretieren. Die folgenden Annahmen stellen diese Interpretation dar, sie erheben keinen Anspruch auf Rechtssicherheit. Dieser Artikel ist relevant für DSFinV-K bis Version 2.2. Aber Version 2.3 der DSFinV-K sind dieser Interpretationen in der DSFinV-K selbst konkre

Zum einen wandelt AmadeusVerify intern die DSFinV-K in 1-n Taxonomie Dateien um. Pro Hauptschlüssel (Z_KASSE_ID, Z_ERSTELLUNG und Z_NR) wird ein JSON-File erstellt. Dieses JSON-File wird danach auf Vollständigkeit überprüft. 

Welche Felder „Mussfelder“ sind, kann man aus dem Anhang_G entnehmen. Was man aber nicht direkt erkennt ist, ob eine Datei zwingend einen zugehörigen Eintrag in einer anderen Datei braucht.

AmadeusVerify geht wie folgt vor:

Pro Kassenabschluss sind folgende Dateien aus dem Stammdatenmodul zwingend (also mindestens ein Eintrag in der Datei):

• cashpointclosing.csv
• location.csv
• cashregister.csv
• vat.csv

Folgende Dateien müssen nicht befüllt sein:

• slaves.csv
• pa.csv
• tse.csv

Sofern es einen Datensatz beim Kassenabschlussmodul gibt müssen alle Dateien befüllt werden:

• businesscases.csv
• payment.csv
• cash_per_currency.csv

Es kann aber auch vorkommen, dass ein leerer Export gemacht wird und es einfach keine Daten für das Kassenabschlussmodul gibt. Das ist auch möglich, ist aber eher selten. 

Nun das Einzelaufzeichnungsmodul:

Transaktionen müssen nur übergeben werden, wenn es auch welche gibt. Wenn die Datei „transactions.csv“ gefüllt ist, muss nicht zwangsläufig eine andere Datei einen zugehörigen Eintrag haben.

Man kann theoretisch das Schließen eines Tisches als TSE-Transaktion abbilden, hat aber keine Einträge in den „lines.csv“ dazu. Daher schaut man sich den Transaktionstypen (BON_TYP) an.

Ist dieser ein Beleg folgt daraus, dass es Einträge in den „lines.csv“ geben muss, der Beleg musste bezahlt werden -> muss es auch Einträge in „datapayment.csv“ geben. Da es Einträge in den „lines.csv“ gibt muss es auch Einträge in den „lines_vat.csv“ geben und deshalb muss es auch Einträge in „transaction_vat.csv“ geben. Andere Dateien, wie

• allocation_groups.csv
• itemamounts.csv
• subitems.csv
• references.csv
• transactions_tse.csv

sind optional. Nur Transaktionen vom Typ „Beleg“ fließen in das Kassenabschlussmodul und werden weiterverarbeitet. Aber wie sollen die restlichen Transaktionen dargestellt werden. Hier ist die DSFinV-K nicht ganz eindeutig.

AmadeusVerify unterscheidet zwischen „Beleg“ und „anderen Vorgängen“. So sind Zahlungsarten („datapayments.csv“) nur für Einträge vom Typ „Beleg“ erlaubt. Denn alles was die Vermögenszusammensetzung des Unternehmens verändert ist vom Typ „Beleg“.

Die „anderen Vorgänge“ dienen der Dokumentation, verändern die Vermögenszusammensetzung nicht und haben daher auch keine Einträge in „datapayment.csv“. Mit Ausnahme von "AVTraining".

Alle anderen Dateien können Einträge von Transaktionen vom einem der „anderen Vorgänge“ enthalten. Wichtig hierbei ist folgendes:

• Hat eine Transaktion Einträge in „lines.csv“ muss es Einträge in „lines_vat.csv“ geben.
• Gibt es Einträge in „lines_vat.csv“ muss es Einträge in „transactions_vat.csv“ geben.
• Hat eine Transaktion eine TSE-Transaktion und ist diese vom ProcessType „Bestellung-V1“, dann muss es Einträge in den „lines.csv“ geben.

Daraus ergibt sich ein Konstrukt, sobald man gewisse Daten angibt, müssen andere Daten auch angegeben werden.

TSE-Signatur Verifizierung

Die Client-ID wird wie folgt ausgelesen:

Wird in der "transactions.csv" das Feld "TERMINAL_ID" gefüllt, wird in der "slaves.csv" nach dem passenden Eintrag gesucht. Die dort angegebene Seriennummer wird dann als "ClientId" der TSE-Transaktion verwendet. 

Falls das Feld nicht gefüllt ist, wird die Seriennummer in "cashregister.csv" verwendet.

Hintergrund ist, dass die Hauptkassen-ID ja sowieso im File angegeben ist ("Z_KASSE_ID"). Das Feld "TERMINAL_ID" ist auch optional und im Anhang_G erkennt man, dass es auf das Feld "closing_cash_register_slave_id" der Taxonomie gemappt wird. Zusätzlich haben wir die Annahme getroffen, dass die Kasse/Terminal, welche die Transaktion abschließt, auch mit der TSE kommuniziert.

Das Zertifikat sollte als komplette Kette übergeben werden. Es geht nicht klar hervor, was in die Felder geschrieben werden soll (da immer nur von Zertifikat die Rede ist). Da aber neue Felder hinzugekommen sind, gehen wir davon aus, dass die komplette Kette Base64-encoded übergeben werden soll. AmadeusVerify ist es aber egal, da nur das oberste Zertifikat gebraucht wird um die Signatur zu überprüfen. Und im Falle des Zweifels sollten einfach mehr Daten übergeben werden.