DsFinV-K -> Q&A

[bernau]

Zitat von Frickler:

Hierbei sind nur diejenigen Stammdaten gemeint, die im DSFinV-K Export auch "vorkommen", also was in die Tabellen "Stamm_Abschluss", "Stamm_Orte", "Stamm_Kassen", "Stamm_Terminals", "Stamm_Agenturen", "Stamm_Ust" und "Stamm_TSE" exportiert werden muss. Damit muss man dann z.B. vor dem Einspielen einer neuen Softwareversion der Kasse einen Abschluss machen.

Ah. Irgendwie logisch. Für dich und für mich. Ist das auch irgendwo dokumentiert? Steuerprüfer haben manchmal eine andere Logik.

Ich bin bei einer Steuerprüfung mal auf die Nase gefallen, weil die Änderung von Stammdaten nicht genügend protokolliert wurden. Hierbei handelte es sich um eine Änderung der Berechtigung des Mitarbeiters. Der Steuerprüfer wollte wissen, wann ein Mitarbeiter die Berechtigung zum Storno erhalten hat. Unglaublich.



Edit: hab's gefunden.

Zitat:

3.2

Stammdatenmodul der DSFinV-K

Zur Vermeidung von Redundanzen werden die Stammdaten für jeden Kassenabschluss nur einmal gespeichert. Werden Änderungen an den im Folgenden aufgeführten Stammdaten vorgenommen, ist zuvor automatisch ein Abschluss zu erstellen.
Die Stammdaten teilen sich auf folgende Dateien auf:

[Frickler]

Zitat von bernau:

Ich bin bei einer Steuerprüfung mal auf die Nase gefallen, weil die Änderung von Stammdaten nicht genügend protokolliert wurden. Hierbei handelte es sich um eine Änderung der Berechtigung des Mitarbeiters. Der Steuerprüfer wollte wissen, wann ein Mitarbeiter die Berechtigung zum Storno erhalten hat. Unglaublich.

Wenn dem Prüfer Deine Nase nicht gefällt, nutzt es auch nix, wenn Du das speicherst. Weil dann könnte er z.B. anzweifeln, dass die Speicherung manipulationssicher erfolgte - wie in diesem FG Münster Urteil, wo es hieß "Der Senat braucht nicht zu prüfen, ob der Kläger tatsächlich Manipulationen an seinem Kassensystem vorgenommen hat. [...] Es genügt vielmehr, dass das System Manipulationsmöglichkeiten eröffnet. Dies gilt unabhängig davon, welcher Aufwand hierfür betrieben werden muss."

[ISMIRSCHLECHT]

Hi,

wir haben zwei Sorten von Kassenabrechnungen: X und Z.
X-Abschlag ist nur ein Kassenstürz, um den alten "ich habe ihnen doch einen Hunderter" - Trick zu verhindern.
Beide Abschlagsarten müssen seit 2016 eine getrennte aufsteigende Nummerhaben.
Aber wie sich das zu den neuen Kassenabschlüssen der DSFin Verhält...

ism

[noisy_master]

Hi,

da die X-Abrechnung nichts an der Kasse ändert(also wirklich nur ein reiner Kassensturz ist) braucht dort keine Transaktion mit der TSE stattzufinden. Wenn deine Software allerdings so arbeitet, dass dabei auch evtl. auftretende Kassendifferenzen verbucht werden muss das schon über die TSE laufen, da sich ja dein (Soll)Kassenbestand ändert.
Im Fall 1 taucht damit auch nichts im DSFinV-K Export auf, im 2. Fall schon

[Neumann]

Denke der X-Bericht ist uninteressant. Der hat bei mir auch keine Nummer.

[bernau]

In der DSFinV-K-Doku ist am Ende der "Anhang G Mapping-Tabelle DFKA-Taxonomie / DSFinV-K" beschrieben.

Darin wird eine Datei index.xml erwähnt, die benötigt wird.

Zitat:

In der Datei „Anhang_G_Uebersicht.xlsx“ sind die Felder der DFKA-Taxonomie Kassendaten (json) schematisch aufgeführt. Bei der Konvertierung in das csv-Format für Zwecke der Außenprüfung bzw. Nachschau werden beliebig viele json-Dateien zusammengefasst und anschließend als csv-Dateien (DSFinV-K) exportiert. Bei der Konvertierung wird noch eine zusätzliche index.xml zum Import in IDEA beigefügt.

Hat jemand weitere Infos zu dieser Datei?

[Neumann]

Ich habe ein Beispiel dafür, kann ich dir per Mail schicken. Möchte hier nicht veröffentlichen.

[jaenicke]

Das ist ja die gleiche Struktur wie vorher bei den GDPdU / GoBD Exporten nehme ich an, oder?