Der allgemeine Workflow(ab Version 1.0.2.0) sieht so aus:


DSFinV-K

  1. DSFinv-K wird eingelesen. Falls es Probleme im CSV gibt, wird das ausgegeben.
  2. Pro "großem Schlüssel" (bestehend aus "Z_KASSE_ID", "Z_ERSTELLUNG" und "Z_NR" wird ein AmadeusVerify-Objekt (Datenstruktur, welche der Taxonomie entspricht) gefüllt. Zusätzlich werden Daten kontrolliert, welche in der DSFinV-K restriktiver sind als in der Taxonomie (da diese ja nicht im Schema eine Fehlermeldung auslösen).
  3. AmadeusVerify-Objekt wird in ein JSON gewandelt und mit dem aktuellen Taxonomie-Schema validiert. Hier aufgepasst! Dadurch, dass sich Taxonomie und DSFinV-K minimal unterscheiden kann der Fehler manchmal ignoriert werden. Welche Fehler das genau sind, können Sie weiter unten nachlesen.
  4. Danach werden Sachen geprüft, welche über das Schema hinausgehen. Z.B. wenn eine Transaktion vom Typen "AVSonstige" ist, muss das Feld "BON_NAME" der Transaktion gefüllt sein.
  5. Annahmen von AmadeusVerify werden überprüft. Diese sind im Lösungsartikel "Annahmen von AmadeusVerify zur DSFinV-K" beschrieben
  6. Es wird der Inhalt kontrolliert, die Signaturen, ob die Daten im Abschluss zusammenpassen. Die Fehlermeldungen sind im Artikel "Fehlermeldungen AmadeusVerify DSFinV-K/Taxonomie" genauer beschrieben.

Taxonomie

  1. Das JSON wird mit dem Taxonomie-Schema validiert und dann in das AmadeusVerify-Objekt geparsed. Dabei treten nochmals Fehlermeldungen auf, wenn ungültige Daten nicht geparsed werden konnten. Z.B. die TaxonomieVersion wurde im falschen Format übergeben, AmadeusVerify liest diese dennoch ein. Aber wenn es einen Buchstaben in einem numerischen Feld gibt, kann AmadeusVerify das nicht einlesen.
  2. Danach werden Sachen geprüft, welche über das Schema hinausgehen. Z.B. wenn eine Transaktion vom Typen "AVSonstige" ist, muss das Feld "BON_NAME" der Transaktion gefüllt sein.
  3. Annahmen von AmadeusVerify werden überprüft. Diese sind im Lösungsartikel "Annahmen von AmadeusVerify zur DSFinV-K" beschrieben
  4. Es wird der Inhalt kontrolliert, die Signaturen, ob die Daten im Abschluss zusammenpassen. Die Fehlermeldungen sind im Artikel "Fehlermeldungen AmadeusVerify DSFinV-K/Taxonomie" genauer beschrieben.


Felder welche in der Taxonomie restriktiver sind


  • In "transactions_vats.csv": Beträge dürfen laut DSFinV-K 5 Nachkommastellen haben, laut Taxonomie aber nur 2 NK
  • in "cashpointclosing.csv": Taxonomie_Version hat kein Pattern in der DSFinV-K. Laut Taxonomie sollte es aber so sein: "^[0-9]+\\.[0-9]+\\.[0-9]+$"
  • USTID generell: DSFinV-K gibt kein Pattern vor, die Taxonomie aber folgendes: "^[A-Z]{2}.{1,13}$".
  • KUNDE_TYP. Laut DSFinV-K gibt es keine Einschränkungen, aber laut Taxonomie muss dieser entweder "Kunde" oder "Mitarbeiter" sein.
  • Die Meldung "currency_code im Pfad cash_point_closing.cash_statement.payment.payment_type" kann ignoriert werden, falls man die DSFinV-K validiert. Dieses Feld gibt es nur in der Taxonomie, das muss in Zukunft angepasst werden. Ab Version 1.0.3.0 wird das Feld mit der Basiswährung der Kasse gefüllt (bei Konvertierung DSFinv-K -> Taxonomie)
  • Der Typ "Guthabenkarte" bei den Zahlungstypen ist in der Taxonomie als "GuthabenKarte" anzugeben.
  • Das Feld "KASSE_MODELL" und "KASSE_BRAND" ist laut Anhang_G optional, wird aber von der Taxonomie zwingend verlangt.
  • BON_NR darf laut Taxonomie nicht negativ sein, wäre aber laut DSFinV-K erlaubt.
  • Laut DSFinV-K darf entweder die STNR oder USTID angegeben werden, die Taxonomie verlangt aber explizit die STNR. Das wird aber auch im Anhang_G so dargestellt.


Felder welche in der DSFinV-K restriktiver sind


  • In "transcations_tse.csv" sind die Zeiten im Format "YYYY-MM-DDThh:mm:ss.fffZ“ darzustellen, laut Taxonomie muss die Zeit wie in ISO 8601 und RFC3339 beschrieben (also wie andere Zeiten in der DSFinV-K) dargestellt werden.