DsFinV-K -> Q&A

[bernau]

Bin grade mit der DsFinV-K beschäftigt und dabei fallen mir immer wieder Dinge auf, die gefordert sind und die ich bisher auf andere Weise gehandhabt habe.

Da hier in der DP einige Leute sind, die sich mit Kassensoftware beschäftigen, habe ich mir gedacht hier einen Frage-Antwort-Thread zur DsFinV-K (und TSE) zu eröffnen.

Für den Anfang mal was zum Kassenabschluss:

Ein zentraler Bestandteil in der Doku ist der Kassenabschluss.

In allen Dateien, die erzeugt werden müssen, gibt es die Felder.

Z_KASSE_ID -> ID der (Abschluss-) Kasse
Z_ERSTELLUNG -> Zeitpunkt des Kassenabschlusses
Z_NR -> Nr. des Kassenabschlusses

Der Kassenabschluß ist also Zentraler Bestandteil des DsFinV-K-Export.


In meiner Kassensoftware wird automatisch um 0:00 Uhr der Kassenabschluss durchgeführt. Der Anwender muss nichts machen. Er "kann" zwischendurch einen Kassensturz machen, Geld entnehmen, einzahlen u.s.w. Aber zum 0:00 Uhr gibt es einen Schnitt, einen definieten Endbestand und für den nächsten Tag einen definierten Anfangsbestand. Er Abschluss wurde nicht durchnummeriert. Er ist einfach da. Es gibt genau einen Abschluss pro Tag. Damit hatte ich bisher auch bei Betriebsprüfungen meiner Kunden kein Problem.

Wie habt Ihr den Kassenabschluss bisher gehandhabt?


Auf Seite 14 Abschnitt 3, ist folgendes zu lesen:

Zitat:

Um zu gewährleisten, dass die Stammdaten eindeutig dem jeweiligen Kassenabschluss zugeordnet werden können, ist sicher zu stellen, dass vor einer Stammdaten-Änderung ein Kassenabschluss erfolgt und erst anschließend wieder neu gebucht wird.

Das bedeutet, dass mit jeder noch so kleinen Änderung (z.B. Berechtigung eines Kassierers ändern) ein Kassenabschluss gemacht werden muss. Was ist mit Änderung von Artikeln? Das sind doch auch Stammdaten? Wenn man das so weiter spinnt, dann kommen so einige Kassenabschlüsse am Tag zusammen.

Warum der ganze Mist.

Was gehört denn alles zum Kassenabschluss? Muss beim Kassenabschluss zwangsweise das Geld gezählt werden?



Hier etwas zum Feld Z_NR (Beschereibung Seite 57)

Zitat:

Z_NR

Feldtyp: Numerisch, 0 Dezimalstellen

Kurzbeschreibung: Der Kassenabschluss wird einmalig bzw. mehrmals am Tag oder auch kalendertagübergreifend für eine Kasse erstellt. Jede Kasse besitzt eine „Z_NR“, eine Kassenabschlussnummer. Diese ist aufsteigend, fortlaufend und nicht zurücksetzbar.

Gibt es eine gesetzliche Vorgabe, wann der Kassenabschluss gemacht werden muss (Ausser bei Änderung der Stammdaten)? Es wird ja von Kalendertagsübergreifend gesprochen. Also darf ich theoretisch 1 Mal die Woche einen "manuellen Kassenabschluss" durchführen. Oder 1 mal im Monat. Oder doch spätestens am nächsten Tag.


Fragen über Fragen.

[Frickler]

Zitat:

Zitat von bernau (Beitrag 1453173)

Bin grade mit der DsFinV-K beschäftigt und dabei fallen mir immer wieder Dinge auf, die gefordert sind und die ich bisher auf andere Weise gehandhabt habe.

Auf Seite 14 Abschnitt 3, ist folgendes zu lesen:

Zitat:

Um zu gewährleisten, dass die Stammdaten eindeutig dem jeweiligen Kassenabschluss zugeordnet werden können, ist sicher zu stellen, dass vor einer Stammdaten-Änderung ein Kassenabschluss erfolgt und erst anschließend wieder neu gebucht wird.

Das bedeutet, dass mit jeder noch so kleinen Änderung (z.B. Berechtigung eines Kassierers ändern) ein Kassenabschluss gemacht werden muss. Was ist mit Änderung von Artikeln? Das sind doch auch Stammdaten? Wenn man das so weiter spinnt, dann kommen so einige Kassenabschlüsse am Tag zusammen.

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.

[Frickler]

Was mich stört ist, dass es viel zu wenig Beispiele gibt. Etwa für "andere Vorgänge". Und die angegebenen Beispiele sind alle gekürzt um Felder, die die Autoren als unwichtig fürs Beispiel erachteten, z.B. das Feld "BON_NR". Laut Anlage G der DSFinV-K ist das Feld BON_NR ein Pflichtfeld, darf also niemals leer sein.
In den Erklärungen zu den einzelnen Tabellen unter Punkt 11 heißt es jedoch "Die Bonnummer (oder Belegnummer) ist die von der eingesetzten Kasse vergebene eindeutige Nummerierung innerhalb eines Kassenabschlusses und entspricht der auf dem Bon gedruckten Nummer."
Wenn ein Bon abgebrochen wird ("AVBelegabbruch") wird aber gerade kein Bon gedruckt. Was trägt man da jetzt in BON_NR ein, ohne dass es Lücken in den Bons gibt?

[Neumann]

Da der Bon abgebrochen wurde, gibt es auch keine Bonnummer. Also beendet man die Transaktion mit Bonabbruch und gut ist.

[Neumann]

Beispieldaten gibt es anscheinend nicht, auch nichts womit man seine Daten prüfen kann. Gehe mal davon aus dass sehr wenige es so schaffen fehlerfreie Exportdaten zu generieren. Das transakionshändlig sowie das Signieren kann man aber wohl schaffen.

Ich mache die Exportdaten erstmal so wie ich meine das sie richtig sind und werde wenn nötig nachbessern.

[TiGü]

Ganz interessante XING-Gruppen zu den Thema:

https://www.xing.com/communities/gro...-1099241/posts

https://www.xing.com/communities/gro...-1083790/posts

(Der Erste der sagt: "Äähm, ich habe kein XING-Account und kann die Links nicht ansehen", wird geteert und gefedert! Meld dich halt an!)

[Frickler]

Zitat:

Zitat von Neumann (Beitrag 1453201)

Beispieldaten gibt es anscheinend nicht, auch nichts womit man seine Daten prüfen kann. Gehe mal davon aus dass sehr wenige es so schaffen fehlerfreie Exportdaten zu generieren. Das transakionshändlig sowie das Signieren kann man aber wohl schaffen.

Ich mache die Exportdaten erstmal so wie ich meine das sie richtig sind und werde wenn nötig nachbessern.

Es gibt ein kommerzielles Prüftool. Kostet 499,- ...

https://tse.gastro-mis.de/tse/produkt/amadeusverify/

[Neumann]

Kann man zumindest 2 Wochen kostenlos testen, ist aber noch nicht ganz fertig

[bernau]

Zitat:

Zitat von Frickler (Beitrag 1453193)

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:

Zitat von bernau (Beitrag 1453269)

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."

[jaenicke]

Zitat:

Zitat von Frickler (Beitrag 1453258)

Es gibt ein kommerzielles Prüftool. Kostet 499,- ...

https://tse.gastro-mis.de/tse/produkt/amadeusverify/

Wobei das ja auch "nur" von einem Kassenhersteller stammt. Inwiefern hier die Wissensgrundlagen zum Prüfen besser vorhanden sind als bei anderen zum Erstellen der Daten ist für mich nicht ersichtlich.

Zitat:

Zitat von bernau (Beitrag 1453269)

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.

Das ist ja schon länger so, dass alle Konfigurationsänderungen protokolliert werden müssen. Die entsprechenden Datenmengen sind bei uns auch nicht klein...

[sh17]

<OT>Man man, wo soll das alles noch hinführen? Kein Wunder wenn keiner mehr Lust hat sich selbständig zu machen. Geschweige denn die Software dafür zu entwickeln.</OT>

[jaenicke]

Das Problem ist vor allem, dass viele komplexe Szenarien gar nicht vorgesehen sind. Das heißt man muss nun schauen, ob man damit überhaupt alles abbilden kann (da haben wir noch Probleme) oder ob man am Ende Funktionen entfernen muss.

[Frickler]

Zitat:

Zitat von jaenicke (Beitrag 1453351)

Das Problem ist vor allem, dass viele komplexe Szenarien gar nicht vorgesehen sind. Das heißt man muss nun schauen, ob man damit überhaupt alles abbilden kann (da haben wir noch Probleme) oder ob man am Ende Funktionen entfernen muss.

In der DSFinV-K steht unter Punkt 1.3, dass die angegebene Schnittstelle den Mindestumfang darstellt und man die Schnittstelle ggfs erweitern muss.

[Neumann]

Wie bekommt man den Public Key aus der Swissbit TSE? Kann das nicht finden.

[hhcm]

Zitat:

Zitat von Neumann (Beitrag 1453366)

Wie bekommt man den Public Key aus der Swissbit TSE? Kann das nicht finden.

Hat zwar mit der DsFinV-K überhaupt nichts zu tun, aber "worm_info_tsePublicKey"

[Neumann]

Das steht in meiner Dokumentation nicht drin, ist vielleicht zu alt. Werde mal aktualisieren.

Danke

[hhcm]

Meine Doku ist von der 5.2.3 Api.
Da finde ich das sogar 2x

Die WormInformation Class hat noch eine Funktion

WormInformation::tsePublicKey()

[Neumann]

Ja Danke, hab's gefunden. Hatte eine veraltete Doku offen.

[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?

[herbstrot]

Moin,

die index.xml ist unter https://www.bzst.de/DE/Unternehmen/A...finv_node.html downloadbar.

[bernau]

Danke für die Antworten. Ich glaube aber, ich habe mich falsch ausgedrückt.

Die index.xml habe ich. Ich hätte aber gerne eine Dokumentation zu dieser Datei. Gibt es so etwas?

[hhcm]

Zitat:

Zitat von bernau (Beitrag 1456244)

Ich hätte aber gerne eine Dokumentation zu dieser Datei. Gibt es so etwas?

Ähm. Die Datei IST die Dokumentation. Die Erklärungen der Spalten stehen in der DsFinV-K

[himitsu]

Zitat:

Zitat von hhcm (Beitrag 1456245)

Die Datei IST die Dokumentation. Die Erklärungen der Spalten stehen in der DsFinV-K

Name, Länge und Beschreibung der Spalten in den CSV
und der Name plus Beschreibung der CSV-Dateien, welche ins Archiv kommen.

Joar, und die Deteilbeschreibung nochmal in der DsFinV-K.



Du könntest das Ding sogar verwenden, um damit eine Datenbank aufzubauen, denn nicht umsonst heißen die Einheiten darin "Table".
Diese dann ganz nach belieben befüllen, als CSV exportieren, zusammen mit der XML in die ZIP und weg damit.

[bernau]

Zum Kassenabschluß habe ich folgendes vom BMF erhalten:

Zitat:

vielen Dank für Ihre Anfrage hinsichtlich der DSFinV-K.

Dem Bundesministerium der Finanzen obliegen in erster Linie die Vorbereitung und Mitwirkung bei gesetzgeberischen Maßnahmen, Rechtsverordnungen und allgemeinen Verwaltungsvorschriften. Diese Aufgabenstellung macht es vom Umfang her leider nicht möglich, detaillierte Auskunfts- und Beratungsersuchen zu steuerlichen Sachverhalten und Fragestellungen zu beantworten.

Im Übrigen ist es mir durch die Gemeinsame Geschäftsordnung der Bundesministerien ausdrücklich verwehrt, Auskünfte zu Rechtfragen zu erteilen, die in einem Einzelfall von Bedeutung sein können und zu deren Entscheidung eine andere Behörde berufen ist. Nach dem Grundgesetz (Artikel 108 Absatz 2 GG) sind die Landesfinanzbehörden für die Durchführung der Steuergesetze und damit für die Beurteilung des Einzelfalls zuständig.

Allgemein bemerke ich Folgendes:

Ein Kassenabschluss kann grundsätzlich auch automatisch durchgeführt werden. Es ist aber zu beachten, dass unter andrem vor einer Stammdaten-Änderung ein Kassenabschluss erfolgt.

Der Kassenabschluss wird einmalig bzw. mehrmals am Tag oder auch kalendertag-übergreifend für eine Kasse erstellt. Ein täglicher Kassenabschluss ist grundsätzlich nicht erforderlich. Allerdings muss das elektronische Aufzeichnungssystem jederzeit kassensturzfähig sein. Die GoBD ist zu beachten.

Das Stammdatenmodul der DSFinV-K und die Stammdaten sind unter der Nummer 3.2 der DSfFinV-K 2.0 beschrieben.

Ich hoffe, Ihnen damit geholfen zu haben.

[arnof]

Zitat:

Zitat von bernau (Beitrag 1456244)

Danke für die Antworten. Ich glaube aber, ich habe mich falsch ausgedrückt.

Die index.xml habe ich. Ich hätte aber gerne eine Dokumentation zu dieser Datei. Gibt es so etwas?

Das ist die Datei, die GDPDU Kassennachschau Export braucht, nur für die Dateiaufbau der DSFinV-K Felder:

http://support.audicon.net/index.php...sstandard.html

[noisy_master]

Hallo zusammen,

mir ist noch eine Frage eingefallen: wie müssen die "pre-DSFinV-K" Daten exportiert werden? Nach dem alten IDEA Schema, oder nach dem neuen DSFinV Schema?

Gruß
Dirk

[hhcm]

Zitat:

Zitat von noisy_master (Beitrag 1460493)

mir ist noch eine Frage eingefallen: wie müssen die "pre-DSFinV-K" Daten exportiert werden? Nach dem alten IDEA Schema, oder nach dem neuen DSFinV Schema?

Was sind denn pre-DSFInV-K Daten?

In der DSFinV-K steht doch drin wie die Daten zu exportieren sind. Wenn man im JSON Format exportieren möchte, muss eh wieder alles in CSV Dateien konvertiert werden.
Was macht also mehr Sinn?

[noisy_master]

Hi,

okay, war vielleicht ein bisschen schlecht formuliert.
ab spätestens 1.10.2020(voraussichtlich, wenn Corona uns nicht noch mehr Freiheit beschert :-D)
muss ja alles in DsFinV-K Format exportiert werden(dazu ist es aber meines Verständnis nach auch notwendig die Transaktionen über die TSE abgesichert zu haben).

Angenommen, die TSE ist wirklich erst am 1.10.2020 am Laufen und am 1.11.2020 kommen die "freundlichen Kollegen" und hätten gerne den Export seit seit dem 1.1.2020.... Müssen die Daten vom 1.1.bis 30.9.("pre-DSFinV-K") dann auch in DSFinV Format exportiert werden?

Gruß

[jaenicke]

Zitat:

Zitat von noisy_master (Beitrag 1460548)

ab spätestens 1.10.2020(voraussichtlich, wenn Corona uns nicht noch mehr Freiheit beschert :-D)

Softwareseitig sollte das zwar kein Problem sein, aber da die Lieferfristen für diverse Bauteile und Kassen sich deutlich erhöht haben, könnte das in der Tat für einige knapp werden. Außerdem ist die Frage wo die TSEs eigentlich produziert werden und ob da genügend da sein werden. Da gibt es ja nach wie vor noch Engpässe...

[noisy_master]

Hi,

ich befürchte deine Antwort beantwortet nicht meine Frage ;-) sorry....

Gruß

[hhcm]

Zitat:

Zitat von noisy_master (Beitrag 1460548)

Angenommen, die TSE ist wirklich erst am 1.10.2020 am Laufen und am 1.11.2020 kommen die "freundlichen Kollegen" und hätten gerne den Export seit seit dem 1.1.2020.... Müssen die Daten vom 1.1.bis 30.9.("pre-DSFinV-K") dann auch in DSFinV Format exportiert werden?

Wir werden das so tun. Daten die nicht da sind (TSE Signaturen etc.) werden einfach leer gelassen.

[cs.rumpelstilzchen]

Hallo Leute.

Wir haben das so geplant: Bei Installation der TSE und Update der Software wird vorab ein GoBD-Export durchgeführt und dem Kunden zu Verwahrung (Backup, etc.) ausgehändigt. Nach Umstellung gibts dann nur noch TSE-abgesicherte Daten als DSFinV-K-Export.
Spricht da was dagegen?

Noch n paar Fragen zum DSFinV-K Export:
Der Export ist ja ein Konglomerat aus mehreren Dateien.
Wie fasst man die zusammen? Als ZIP-Datei?
Und wie soll der Dateiname aussehen, damit der Prüfer damit klar kommt?
Wir finden in den Dokus zur DSFinV-K diesbezüglich nichts.
Wir wollen täglich beim Kassenschluss automatisch eine entsprechende Datei exportieren, damit wir unsere Datenbank nicht aufblasen.

[jaenicke]

Zitat:

Zitat von cs.rumpelstilzchen (Beitrag 1460868)

Bei Installation der TSE und Update der Software wird vorab ein GoBD-Export durchgeführt und dem Kunden zu Verwahrung (Backup, etc.) ausgehändigt. Nach Umstellung gibts dann nur noch TSE-abgesicherte Daten als DSFinV-K-Export.
Spricht da was dagegen?

Der GoBD Export sollte täglich beim Tagesabschluss in gesicherter Form stattfinden um Manipulationen zu vermeiden. Wenn man den nacherstellt, lässt sich kaum eine Manipulation verhindern.

Gegen die Vorgehensweise spricht, dass man den GoBD Export nach wie vor liefern muss. In ein Paket für den Tagesabschluss gehören nun der GoBD Export, der TSE Export und der DSFinVK Export. So war zumindest letztes Jahr noch die Aussage und anders lautende Aussagen habe ich bisher nicht gefunden.

[noisy_master]

Nun bin ich verwirrt: ich habe es bisher so verstanden, dass der GoBD Export für die Finanz"prüfung" da ist. Und nun soll für die Finanz"prüfung" der DSFinV-K Export da sein.
Wofür soll denn dann jetzt noch der GoBD Export nützlich sein?

Und warum soll denn das Ganze täglich erzeugt werden? So wie ich das verstanden habe ist das nur auf Verlangen auszuhändigen/erzeugen, oder? Manipulationsgeschützt ist das Ganze durch die TSE ja eh....

Gruß