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