RocKasseSpezifischeDSFinV-KInformationenzudenInhalten

TSE Prüfung

Mittlerweile wurde unsere roc-kasse mehrfach erfolgreich einer Finanzamt Prüfung unterzogen. Im folgenden wollen wir Informationen bereitstellen, die insbesondere auch von den Prüfern gefragt werden.

Zunächst der Prüfer wird in der Regel das bereitstellen der DSFinV-K Dateien und der zugehörigen TAR Datei für einen Prüfungszeitraum Anfragen.  

Das bereitstellen der DSFinV-K Daten kann bequem über den Zugang von MeinFiskal erfolgen. Voraussetzung The MeinFiskal wurde für den gesamten Prüfungszeitraum eingerichtet und genutzt. Alternativ könnte die Daten aus den archivierten Journalen über die roc-kasse ausgelesen und bereitgestellt werden.

Das bereitstellen der TAR Datei erfolgt über die tägliche Datensicherung des Epson TSE Chips. Wenn die Fiskaly TSE genutzt wurde genügt eine Anfrage über den roc-kasse Support. Dieser lässt die TAR Datei der Fiskaly TSE über den Fiskaly Support bereitstellen.

Zu den Inhalten der DSFinV-K:

Die DSFinV-K beisteht aus 22 bereitgestellte Dateien:

index.xml

Die index.xml ist eine Beschreibung der Nachfolgen Dateien

allocation_groups.csv

Der Eintrag abrKreis (Abrechnungskreis) im Bonkopf-Datensatz dient dazu, Abrechnungskreise innerhalb eines Kassensystems zu unterscheiden. Abrechnungskreise sind besonders relevant in folgenden Fällen:

1. Mehrere Betriebe oder Geschäftsbereiche:

Wenn ein Kassensystem Umsätze verschiedener Betriebe oder Geschäftsbereiche (z. B. verschiedene Filialen, Abteilungen oder organisatorische Einheiten) verwaltet, können diese über den Abrechnungskreis unterschieden werden.

2. Sondernutzung der Kasse:

• Für getrennte Abrechnungen innerhalb eines Systems (z. B. Catering und Barbereich in einem Restaurant).

• Bei filialübergreifenden Kassensystemen, um die Filialumsätze zu trennen.

3. Standardisierte Verwendung:

In Kassensystemen, die mehrere parallele Buchhaltungskreise verwalten.

Der Abrechnungskreis ist eine variable Einheit, mit der ein Vorgang einem bestimmten Kriterium zugeordnet werden kann. Insbesondere in der Gastronomie können über diese Zuordnung Geschäftsvorfälle von ihrer Bestellung bis zur Abwicklung inklusive Splittbuchungen und Tischverlegungen nachvollzogen werden. Der Abrechnungskreis kann sich aus ein oder mehreren Kriterien zusammensetzen. Wichtig ist dabei die Möglichkeit der eindeutigen Zuordnung zu einem Vorgang. Wird dabei zusätzlich von der Möglichkeit der Referenzierung des Geschäftsvorfalles Gebrauch gemacht, so ist es möglich, die Geschäftsvorfallhistorie einzelner Geschäftsvorfälle auch im Falle von Splittbuchungen bzw. veränderten Zuordnungen zu Abrechnungskreisen darzustellen.

Da es sich um ein Kann Information handelt, und alle benötigten Informationen von der roc.Kasse lückenlos abgelegt werden, wird dies Datei von der roc.Kasse innerhalb der DSFin-VK Schnittstelle nicht gefüllt. Szenarien wie Mehre Geschäftsbereiche werden in der roc.Kasse i.d.R. von separaten Kassen abgebildet. Diese separaten Kassen haben dann eigenständige DSFinV-K Schnittstellen.  Wenn oben genannten komplexen Szenarien trotzdem benötigt werden sollten, sprecht bitte den roc.Kase Support an.

businesscases.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt

cash_per_currency.csv

da die roc.Kasse keine Mehrwährungsfähigkeit unterstütz, entfällt das befallen dieser Datei.

cashpointclosing.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt

cashregister.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt

datapayment.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt

gdpdu-01-09-2004.dtd

Steuerdatei zur index.xml

itemamounts.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt

lines_vat.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt

lines.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt

pa.csv  Stamm_Agenturen

da die roc.Kasse nicht als Agenturensystem ausgelegt ist und.i.d.R. als einzelkassensystemgentz wird, wird diese Dati nicht befüllt

payment.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt

references.csv

Die Datei references.csv in der DSFinV-K enthält Referenzen zwischen verschiedenen Datensätzen und wird genutzt, um die Beziehungen zwischen Buchungsvorgängen, Belegen und Abrechnungskreisen transparent zu machen. Sie ist notwendig, wenn bestimmte Buchungsvorgänge aufeinander verweisen oder in Verbindung stehen.

Wann ist references.csv notwendig?

Die Datei references.csv ist verpflichtend, wenn dein Kassensystem Buchungsvorgänge, Belege oder andere Elemente erstellt, die aufeinander verweisen. Beispiele dafür sind:

Verknüpfung von Belegen:

1. Rückgaben oder Stornos, die sich auf einen vorherigen Beleg beziehen.
2. Beispiel: Ein Artikel wird zurückgegeben und die Rückgabe bezieht sich auf einen ursprünglichen Verkaufsbeleg.

1. Zusammenhängende Vorgänge:

1. Vorgänge wie Anzahlungen, Teilzahlungen oder Gutscheineinlösungen, die sich auf eine frühere Transaktion beziehen.

1. Filialübergreifende Abrechnungskreise:

• Wenn ein Abrechnungskreis (z. B. eine Filiale) Belege oder Transaktionen an einen anderen übergibt, z. B. bei filialübergreifenden Rückgaben.

4. Technische Sicherheitseinrichtung (TSE):

• Bei TSE-Vorgängen, die sich auf eine bestimmte Transaktion beziehen, ist eine Referenz erforderlich, um die Verbindung herzustellen.

Wann ist references.csv nicht notwendig?

Die Datei references.csv ist nicht erforderlich, wenn:

1. Kein Bezug zwischen Buchungsvorgängen existiert:

• Alle Belege und Buchungen stehen für sich und sind nicht miteinander verknüpft.

• Beispiel: Einfache Verkäufe ohne Rückgaben, Stornos, Anzahlungen oder Gutscheine.

2. Keine Teilzahlungen oder Vorlagen:

• Alle Transaktionen werden vollständig abgeschlossen, ohne spätere Bezugnahme.

3. Keine filialspezifischen Übergaben:

• Es gibt keine filialübergreifenden Vorgänge oder getrennte Abrechnungskreise.

Inhalte der references.csv

Die Datei enthält folgende typische Spalten (je nach System implementiert):

1. referenz_typ: Der Typ der Referenz, z. B. „Storno“, „Anzahlung“, „Filialübergabe“.

2. referenz_id: Eine eindeutige ID, die auf den ursprünglichen Datensatz verweist (z. B. die Belegnummer).

3. beleg_id: Die ID des aktuellen Belegs, der sich auf den vorherigen Datensatz bezieht.

4. abr_kreis: Der Abrechnungskreis, in dem die Referenz erstellt wurde.

Fazit:

• Notwendig: Wenn dein Kassensystem Rückgaben, Teilzahlungen, Stornos, Gutscheineinlösungen oder filialübergreifende Vorgänge verarbeitet.

• Nicht notwendig: Bei rein abgeschlossenen Einzeltransaktionen ohne Bezug zu anderen Buchungsvorgängen.

die roc.Kasse unterstütz i.d.R. die einfachen Vorgänge in diesem Sinne. Deshalb wird die references.csv nicht gefüllt.

slaves.csv

die roc.Kasse verwaltet keine Unterkassen. Jede roc.Kasse arbeitet eigenständig, ggf. mit mobilen Aufnahmegeräten. Die vollständigen Daten enes Mobilteiles werden in den Transaktionen der roc.Kasse verwaltet. Deshalb ist die Stabes Datei für eine roc.Kasse nicht notwenig.

subitems.csv

Was sind Subitems?

• Subitems sind Unterelemente, die eine detaillierte Beschreibung der einzelnen Positionen oder Vorgänge innerhalb eines Kassenbons oder Buchungsvorgangs enthalten.

• Sie sind insbesondere dann relevant, wenn Positionen in einem Beleg oder Bon in mehrere untergeordnete Bestandteile aufgeteilt werden (z. B. Rabatte, Zuschläge, Modifikationen).

Typische Subitems in der DSFinV-K

Subitems werden häufig in folgenden Fällen genutzt:

1. Rabatte und Zuschläge:

• Wenn ein einzelner Artikel auf dem Bon reduziert oder mit einem Zuschlag versehen wird, muss dies als Subitem dokumentiert werden.

• Beispiel: Ein Getränk mit einem Zuschlag für „Extra Sahne“.

2. Gutscheine oder Geschenkkarten:

• Ein Subitem kann den Wert eines eingelösten Gutscheins oder die Aufladung einer Geschenkkarte darstellen.

3. Zusatzleistungen oder Kombinationen:

• Wenn ein Artikel mit einer Zusatzleistung verkauft wird, z. B. ein Menü mit Hauptgericht, Beilage und Getränk.

4. Artikelmodifikationen:

• Wenn ein Artikel individuell angepasst wird (z. B. Pizza mit extra Käse oder ohne Zwiebeln), können Subitems dies darstellen.

5. Steuerliche Aufschlüsselung:

• Wenn eine Position steuerlich unterschiedlich behandelt wird, z. B. ein Artikel mit 7 % (Speise) und 19 % (Getränk) Umsatzsteuer.

Wann sind Subitems nicht notwendig?

Subitems sind nicht verpflichtend, wenn keine detaillierte Aufschlüsselung der Positionen erforderlich ist. Beispiele:

1. Einfache Artikelpositionen:

• Wenn ein Artikel keine Modifikationen, Rabatte, Zuschläge oder zusätzliche steuerliche Aufteilungen hat.

2. Standardabrechnung:

• In Geschäftsfällen, wo alle Positionen einfach und vollständig auf Bon-Ebene dokumentiert sind.

3. Keine komplexen Artikelstrukturen:

• Wenn deine Produkte oder Dienstleistungen keine Unterteilungen oder Modifikationen aufweisen.

Fazit zu Subitems:

• Notwendig: Wenn Vorgänge detailliert aufgeschlüsselt werden müssen (Rabatte, Zuschläge, Kombinationen, Modifikationen).

• Nicht notwendig: Bei einfachen Transaktionen ohne weitere Untergliederung der Artikelpositionen.

In der roc.Kasse werden Artikelbuchungen in diesem Sinne als einfache Artikelpositionen behandelt. Selbst Rabatt Informationen werden in den Lines abgebildet.

transactions_tse.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt

Enthält die Informationen die vom Chip kommen

transactions_vat.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt

transactions.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt

tse.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt

vat.csv

Wird nach den Vorgaben der DSFinV_K_2_4 gefüllt