Die Kontrolle der DSFinv-K läuft so ab, dass als erstes die CSV-Daten eingelesen werden. Falls es hier irgendein Problem gibt (falsches Dezimalzeichen,....) wird das auch so ausgegeben. Danach werden Taxonomie-JSON-Files erstellt. Pro "großem" Key (bestehend aus Z_KASSE_ID, Z_ERSTELLUNG und Z_NR) wird ein JSON-File erstellt. 

Jedes dieser JSON-Files wird nochmals durch den Taxonomie-Validierer gejagt und Fehlermeldungen, falls vorhanden, werden ausgegeben. Pro Fehler wird nur eine Fehlermeldung ausgegeben (z.B. Zeit hat falsches Format), da es ja zig Transaktionen geben kann und derselbe Fehler nicht hunderte Male angezeigt werden soll.

Über den Anhang G in der DSFinV-K kann man das Taxonomie-Feld dem zugehörigen DSFinV-K-Feld zuordnen.

 



Allgemeine Checks


Stammdatenmodul

Fehler "Informationen zum Lesen der TSE-Modul-Daten fehlen."

Diese Felder befinden sich im Security-Bereich der Taxonomie bzw. im File "tse.csv" der DSFinV-K. Es wird nur kontrolliert ob genug Daten angegeben sind. Diese bestehen aus "id, serial_number, signature_algorithm, log_time_format und certificate". Fehlt einer diese Datensätze wird die Fehlermeldung ausgegeben. 

Fehler "Keine Steuersätze übergeben! Es werden nur die Standardsätze verwendet!"

Falls es keine Einträge in den vat_definitions (vat.csv) gibt, dann kommt folgende Fehlermeldung. Es werden dann die Standardsteuersätze verwendet.

Fehler "Ein Steuersatz hat keine Daten!" 

Falls die Daten in den vat_definitions (vat.csv) nicht vollständig sind.

Fehler Ein Steuersatz hat keinen gültigen Wert! Id: xxx Wert: xxx

Falls der angegebene Steuersatz keinen gültigen Wert enthält. Dieser muss auf einen der 5 erlaubten Sätze entfallen. 


Kassenabschlussmodul

Nun wird das cash_statment kontrolliert. In der DSFInV-K sind das die Files, welche das Kassenabschlussmodul bilden (businesscases.csv, payment.csv und cash_per_currency.csv)


Fehler "Summe der Cash-Beträge stimmt nicht mit Feld cash_amount im Bereich payment überein..."

Das Feld cash_amount (ZE_SE_BARZAHLUNGEN) muss mit den CASH-Zahlungen in den payments (payments.csv) übereinstimmen. 

Fehler  "Für die SteuerId: xxx wurde keine Definition hinterlegt!"

Diese Fehlermeldung kann auch in anderen Szenarien auftreten. Immer wenn Steuern übergeben werden, gibt es einen Key auf die vat_definitions. Falls darin kein zugehöriger Wert enthalten ist, wird diese Fehlermeldung ausgegeben.

Fehler "Summe der Steuern in den BusinessCases stimmt nicht mit Feld full_amount im Bereich payment überein...

Die Summe aller BusinessCases muss mit dem full_amount (ZE_SE_ZAHLUNGEN) übereinstimmen. 


Transaktionsspezifische Checks

 

Nun werden die einzelnen Transaktionen kontrolliert. Dabei steht die Nummer vorne für die Transaktionsnummer (im Security-Bereich der Transaktion) bzw. der Nummer im Head der Transaktion, falls das vorherige Feld fehlt. 


Allgemeine Checks der Transaktion

Fehler  "Summe der Steuern stimmt nicht mit Feld full_amount_incl_vat überein."

Die Steuern der Transaction (transactions_vat.csv) müssen mit dem full_amount_incl_vat (UMS_BRUTTO in transactions.csv) übereinstimmen.

Fehler "Summe der Zahlungen stimmt nicht mit Feld full_amount_incl_vat überein."

Die Zahlungen der Transaction (datapayment) müssen mit dem full_amount_incl_vat (UMS_BRUTTO in transactions.csv) übereinstimmen. Das ist aber nur der Fall für Transaktionen mit Typ "Beleg"


Check der Signatur

Fehler "ClientId konnte nicht gelesen werden. Es wurde kein zugehöriger Eintrag für xxx in den slaves gefunden!"

Die ClientId, welche für die TSE-Transaktion verwendet wurde ist die Seriennummer der Kasse. Diese kann entweder im "cashregister.csv" gefunden werden oder in den "slaves.csv". Falls bei einer Transaktion das Feld "TERMINAL_ID" befüllt ist, wird in den "slaves.csv" nachgeschaut. Im Anhang G kann man das Mapping erkennen, dass "TERMINAL_ID" mit "closing_cash_register_slave_id" gemappt wurde.

Fehler "ClientId konnte nicht gelesen werden. Es wurde kein Eintrag in CashPointClosing gefunden!"

In der Datei "cashregister.csv" konnte das Feld "KASSE_SERIENNR" nicht gelesen werden.

Fehler "Felder in security-Bereich der Transaktion sind null!"

Nun wird versucht die Signatur zu verifizieren, welche einer Transaktion zugeordnet ist. Es müssen folgende Daten im Security-Bereich (transactions_tse.csv) vorhanden sein: 

  1. module_id, transaction_number
  2. log_time der StartTransaction
  3. log_time, process_type, signature_counter,signature der FinishTransction
  4. Zusätzlich muss noch die clientId gelesen werden. 

Die clientId ist in der Taxonomie < 2.1 das Feld id im closing_cash_register im Head der Transaktion (Feld Z_KASSE_ID in der DSFinV-K) bzw. das Feld salve_id (Feld TERMINAL_ID in der transactions.csv).

In der Taxonomie 2.1 ist das ein bisschen anders, denn die clientId ist dann die Seriennummer der zugehörigen Id. Also die id bzw. slave_id gibt den Eintrag im "cash_register" (cashregister.csv) bzw. unter den "slaves" (slaves.csv) darin an

Fehler "Kein Tse-Module mit dieser Id hinterlegt!"

In einem Check weiter oben, wurden die TSE-Module eingelesen. Falls es für die angegebene Id kein Modul gibt bzw. dieses nicht eingelesen wurde, weil die Daten nicht vollständig waren, kommt diese Fehlermeldung. 

Fehler " ProcessData konnte nicht nachvollzogen werden!"

Die ProcessData ist optional. AmadeusVerify versucht immer, diese nachzubauen. Falls diese nicht nachvollzogen werden konnte, gibt es diese Fehlermeldung mit einer zusätzlichen Information, warum das der Fall ist. 

Fehler "ProcessData in Security-Teil stimmt nicht mit errechneter ProcessData überein!"

Falls das Feld process_data im Security-Bereich gesetzt ist, wird dieses mit der nachgebauten process_data verglichen. Falls es einen Unterschied gibt, wird diese Fehlermeldung ausgegeben. 

Fehler "Exception bei der Verifizierung der Signatur"

Falls es ein Problem beim Verifizieren gibt, wird es hier ausgegeben. Ein bekannter Fehler gibt an, dass ein Base64 nicht korrekt ist. Dabei kann es sich entweder um die Signatur handeln oder um das Zertifikat. In den meisten Fällen betrifft dies das Zertifikat, weil vorne/hinten eventuell Informationen abgeschnitten wurden.

Fehler "Signatur nicht valide. Formatierung stimmt aber"

AmadeusVerify kann leider nicht mehr machen, als die Formatierung der Daten bezüglich der TSE-Transaktion zu überprüfen. Denn schlussendlich muss AmadeusVerify die signierte LogMessage Bit für Bit nachbauen und danach mittels mathematischer Verfahren ermitteln, ob die Signatur valide ist. Falls die Zeit um 1 Sekunde falsch übergeben wurde, stimmen die Daten nicht mehr, aber formell ist noch alles korrekt. Man kann also nicht sagen, was an den Daten falsch ist, ohne die originale LogMessage (z.B. aus dem Tar-Export) zu haben und die LogMessage von AmadeusVerify mit der LogMessage aus dem Export (ohne Header und Signatur) zu vergleichen.


Check der Daten in den Lines

Nun kommt als Präfix der Fehlermeldungen noch die Line dazu. 

Fehler "im Item stimmen Summe von Steuern und PricePerUnit*Menge/Mengen-Faktor nicht überein!"

Die Summe der Steuern im Item muss natürlich mit PricePerUnit*Menge/Mengen-Faktor übereinstimmen. In der DSFinV-K sind diese Felder in "lines.csv". Die Steuern sind im File "lines_vat" enthalten.

Fehler "stimmen Summe von Steuern des BusinessCases und PricePerUnit*Menge/Mengen-Faktor von Item nicht überein!"

Jede Line hat Ihren eigenen BusinessCase. Die Steuern in diesem BusinessCase müssen auch mit PricePerUnit*Menge/Mengen-Faktor übereinstimmen. In der DSFinV-K  sind die Steuern des BusinessCases im File "lines_vat" enthalten.

Fehler "stimmen Summe von 19% von Lines und kompletter Transaktion nicht überein!"

Die aufgerechneten Steuern der einzelnen Lines müssen auch mit den Steuern der kompletten Transaction übereinstimmen. In der DSFinV-K sind das alle Einträge zu einer Transaktion im File "lines_vat", welche mit den Einträgen in "transactions_vat" zusammenpassen muss. 

Fehler "stimmen Summe von Steuern der Preisfindung und PricePerUnit nicht überein!"

Die Preisfindung erläutert nur die Entstehung des Wertes in "STK_BR". Aus der DSFinV-K(4.2.4):


Die sofortige Entgeltminderung muss direkt bei der Erfassung des Verkaufsvorganges
berücksichtigt werden. Das Entgelt der Ware muss somit vermindert werden. In dem Datenfeld
STK_BR in der Datei Bonpos wird entweder der verminderte Betrag sofort ausgewiesen
(und die Entstehung des Betrags in der Datei Bonpos_Preisfindung dargestellt)

oder die Entgeltminderung wird als gesonderte Positionszeile


Es geht also nur um den Wert in STK_BR, keine Mengenangaben werden miteinbezogen. Auch soll das Vorzeichen bei "discounts" wie bei eigene Zeileneinträge mit Typ "Rabatt" angegeben werden, also mit negativem Vorzeichen. Das steht so nicht direkt in der DSFinV-K aber es steht auch nirgendwo, dass auf Grund des Typen eine Annahme gemacht wird. 
Aus der DSFinV-K:


"..oder die Entgeltminderung wird als gesonderte Positionszeile mit Negativbeträgen dargestellt
(mit korrekter Steuerzuordnung; vgl. Datei Bonpos_USt). Für die gesonderte Zeile
steht der GV_TYP „Rabatt“ zur Verfügung
"



Checks Transaktionen mit Kassenabschlussmodul

Nun werden alle Transaktionen vom Typ Beleg aufgerechnet und mit den Daten im Kassenabschlussmodul verglichen. 


Fehler "Betrag vom Steuersatz xx% im CashStatment stimmen nicht mit den aufgerechneten Steuersatz der einzelnen Transaktionen zusammen!"

Die Steuersätze der einzelnen Transaktionen passen nicht zusammen. Dabei werden die BusinessCases im "cash_statment" verwendet. Das ist die Datei "businesscases.csv" in der DSFinV-K.

Fehler "Betrag vom Typ Bar im CashStatment stimmen nicht mit den aufgerechneten Betrag der einzelnen Transaktionen zusammen!"

Alle Zahlungen vom Typ Bar aufgerechnet passen nicht zu den Daten im CashStatement. Dabei werden die Payments im "cash_statment" verwendet. Das ist die Datei "payment.csv" in der DSFinV-K. 

Fehler "Beträge in cash_per_currency mit Fremdwährung im CashStatment stimmen nicht mit den aufgerechneten Betrag der einzelnen Transaktionen zusammen!"

Es werden auch die Fremdwährungen verglichen. Dabei werden die cash_amounts_by_currency im "cash_statment" verwendet. Das ist die Datei "cash_per_currency.csv" in der DSFinV-K.