DsFinV-K -> Q&A

[Frickler]

Zitat von 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.

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

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

[jaenicke]

Zitat von Frickler:

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

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>

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