1. Wie sind die Umsatzsteuersatzänderungen durch das Zweite Corona-Steuerhilfegesetz in der DSFinV-K abzubilden?
Über die ID 1 – 4 sind immer die jeweils geltenden Steuersätze abzubilden. Historische Steuersätze (z. B. 19 Prozent und 7 Prozent für den Zeitraum 1. Juli bis 31. Dezember 2020) sind über die ID 11 und 21 (allgemeiner Steuersatz) oder 12 und 22 (ermäßigter Steuersatz) abzubilden (vgl. Tz. 3.2.6 der DSFinV-K 2.2).
2. Muss jede Transaktion, die in der DSFinV-K aufgezeichnet wird, auch über die TSE gesichert werden?
Welche Vorgänge verpflichtend über die TSE abzusichern sind, ergibt sich aus Nr. 1.10 und 1.11 des AEAO zu § 146a. Ein darüberhinausgehender Umfang ist möglich.
3. Wie ist mit Geschäftsvorfällen zu verfahren, die länger als einen Tag andauern? Die DSFinV-K und auch die meisten Kassen basieren auf einem Tagesabschluss.
Nicht abgeschlossene Geschäftsvorfälle werden entweder als Bestellungen in eigenen Transaktionen oder als "andere Vorgänge" abgesichert, die in der DSFinV-K über den Abrechnungskreis oder eine Referenzierung miteinander verknüpft sind.
4. Die Abläufe bei "langanhaltenden Bestellvorgängen” (Nr. 2.2.3.6.2 des AEAO zu § 146a) bis zur Rechnung sind oft nicht linear, z. B. können in der Gastronomie zwischen Bestellung und Rechnung Tischspeicher gesplittet (aus einem werden mehrere) oder zusammengelegt (aus mehreren wird einer) werden. Welche Startzeit bekommt die Rechnung?
Sofern die langanhaltenden Bestellvorgänge mit der Transaktion "Bestellung" abgesichert wurden, bekommt jede Rechnung den Zeitpunkt als Startzeit zu dem die Transaktion "Kassenbeleg" begonnen wird. Werden z. B. mehrere Rechnungen für einen Tisch zu unterschiedlichen Zeitpunkten erstellt, so erhält die jeweilige Rechnung die Startzeit des Zeitpunkts zu dem die jeweilige Transaktion "Kassenbeleg" begonnen wird. Zusätzlich ist auf den Bon der Startzeitpunkt der ersten Bestellung in Klarschrift aufzudrucken (siehe Nr. 2.7 sowie Anlage H, Folie 5, der DSFinV-K).
5. Wie können verschiedene Preisebenen für Artikel / Kunden / Zeiten dargestellt werden, wenn es keinen "Standard-Preis“ gibt?
Es gibt mehrere Möglichkeiten der Darstellung der Preise:
- Nutzung verschiedener Artikel mit unterschiedlichen Preisen
- Darstellung eines Grundpreises in der Datei Bonkopf.csv und anschließender Rabattzeilen mit negativen Beträgen
- Darstellung des sich letztendlich ergebenden Preises in der Bonkopf.csv und eine Erläuterung der Berechnung des letztendlichen Preises über die Datei Bonkopf_Preisfindung.csv
6. Was genau sind "Guthabenkarten“ und wie sind diese im Vergleich zu Gutscheinen in der DSFinV-K abzubilden?
Jeder in der DSFinV-K zugelassene ZAHLART_TYP beschreibt entweder reales Geld oder E-Geld. Beim ZAHLART_TYP "Guthabenkarte" stellt die DSFinV-K auf die "RICHTLINIE 2009/110/EG DES EUROPÄISCHEN PARLAMENTS UND DES RATES" ab. Folgende Punkte sind Voraussetzung für die Nutzung des ZAHLART_Typs "Guthabenkarte":
- Die Guthabenkarte wird mit e-Geld an Kassen oder Automaten aufgewertet (aufgeladen).
- Die Guthabenkarte im Sinne der DSFinV-K muss von einem E-Geld-Emittenten im Sinne der E-Geld-Richtlinie (s. o.) herausgegeben werden.
- Die Guthabenkarte wird genutzt, um Zahlungsvorgänge durchzuführen.
- Die Guthabenkarte wird von weiteren natürlichen oder juristischen Personen als Zahlungsmittel akzeptiert.
Werden aufladbare Kundenkarten, mit denen keine E-Geldzahlungen möglich sind, lediglich vom Emittenten (herausgebenden Unternehmen) für den Zahlungsvorgang akzeptiert, so sind diese analog zu den DSFinV-K-Regeln für Gutscheine abzubilden. Sie stellen somit keinen ZAHLART_TYP dar, sondern sind im Rahmen von Geschäftsvorfall-Typen abzubilden. Möglich sind folgende GV_TYPen:
- MehrzweckgutscheinKauf,
- MehrzweckgutscheinEinloesung,
- EinzweckgutscheinKauf,
- EinzweckgutscheinEinloesung (vgl. Nr. 4.1.3 der DSFinV-K).
Personenbezogene Kundenkarten (z. B. Flottenkarten bei Tankstellen) hingegen können über Forderungsentstehung und -auflösung abzubilden sein.
7. Wie genau definiert sich der Begriff "EC-Karten“?
Der Begriff der "EC-Karte" in der DSFinV-K steht für "Debit-Karten", also z. B. girocard, Maestro, VPay.
8. Wie sind Systeme zu behandeln, bei denen "Warenkörbe“ über einen scannbaren Code an die Kasse übertragen werden (z. B. Shop im Shop)?
Erfolgt die Erfassung des "Warenkorbes" durch ein gesondertes System und das Aufzeichnungssystem übernimmt die Daten, z. B. über einen ScanCode, so müssen nur die Aufzeichnungen des Systems mit einer TSE geschützt werden, das die Bezahlung ermöglicht. In einem solchen Fall wäre das die jeweilige Kasse, an der die Bezahlung vorgenommen wird.
9. Ist die Reihenfolge der Datenfelder innerhalb einer CSV-Datei bindend festgelegt?
Die Reihenfolge der Felder ist nicht zwingend vorgeschrieben. Entscheidend ist, dass die index.xml den Aufbau der csv-Dateien richtig beschreibt. Für die spätere Auswertung in der Revisionssoftware der Finanzverwaltung (IDEA) wäre es wünschenswert, mindestens die Schlüsselfelder am Anfang der Dateien darzustellen. Maßgebend für die Musterdatei index.xml (Veröffentlichung auf der Internetseite des BZSt) sind die Reihenfolgen in der Tz. 3 der DSFinV-K. Der Anhang E zur DSFinV-K dient nur der Erläuterung.
10. Im Anhang H der DSFinV-K werden Ablaufbeispiele mit dem TSE-Befehl UpdateTransaction aufgeführt. In Anhang I wird gesagt, dass UpdateTransaction generell nicht verwendet wird. Was ist richtig?
Die Beispiele in Anhang H illustrieren lediglich die im Anwendungserlass definierten Vereinfachungen zu den unterschiedlichen Fallgestaltungen. Dabei werden Start-, Update- und FinishTransaction dargestellt, da jeder dieser Absicherungsschritte im schematischen Ablauf zu betrachten ist. Im Anhang I geht es ausschließlich um die Definition von processType und processData. Beim processType "Kassenbeleg" kann es kein UpdateTransaction geben, da sich die processData erst mit dem Abschluss des Kassenbeleges ergeben. Bei den processTypes "SonstigerVorgang" und "Bestellung" könnten auch UpdateTransaction möglich sein.