Gastro-MIS GmbH

In diesem Artikel werden Fragen aufgearbeitet, die häufig beim Auswerten der DSFinV-K - Daten durch eine Betriebsprüfung gestellt werden. Alle Antworten enthalten Quellenangaben, meistens in Form von Zitaten aus der DSFinV-K, welche in der aktuellen Version hier verfügbar ist: DSFinV-K

In den Daten sind die Umsätze doppelt so hoch oder noch höher

Die DSFinV-K verlangt im Sinne der Erleichterungsregelung (DSFinV-K Anhang H), dass neben den eigentlichen Belegen auch jede Bestellung (in der Gastronomie "Kellner nimmt Bestellung am Tisch auf") abgesichert werden muss. Somit ist jeder Umsatz einmal als Bestellung (BON_TYP AVBestellung) und als Beleg (BON_TYP Beleg) abgesichert. Sofern bei der Auswertung der DSFinV-K nicht auf den BON_TYP Beleg gefiltert wird, erscheinen die Umsätze somit doppelt so hoch wie eigenltich ausgewiesen. 

Der Einsatz von "Zahlung löschen" (FUNC 212) kann ebenfalls zu schwerer auswertbaren Daten führen, da auch die Gutschriften wieder doppelt abgesichert werden (die Gesamte Gutschrift als Bestellung und als Beleg). 

Das Feld BON_ID weist Lücken auf

Die DSFinV-K schreibt im Anhang E zur BON_ID 

Die BON_ID ist die von der eingesetzten Kasse vergebene, stetig fortlaufende und eindeutige
Kennzeichnung aller Vorgänge.
Die BON_ID muss automatisiert und unveränderbar für jeden einzelnen Beleg in der
Kasse vergeben werden. Sie sollte in numerisch aufsteigender Form vergeben werden.

LINA POS vergibt in jeder Tabelle eine fortlaufende ID, so auch die hier genannte BON_ID. Dan in moderner Software viele Prozesse parallel ablaufen, können in seltenen Fällen (unter 3%) Lücken in der BON_ID auftreten. Die Eindeutigkeit der BON_ID steht hier über der lückenlosen Vergabe dieser (und jeder anderen) ID. Dieses Prinzip ist der zweite Satz des DSFinV-K - Zitats: Sie muss automatisiert und unveränderbar sein, sie soll numerisch aufsteigend sein. 

Ganz wichtig ist im Zusammenhang mit allen IDs und/oder fortlaufenden Nummern im System ist, dass keine dieser von LINA POS vergebenen IDs zur Überprüfung der Vollständigkeit der Daten herangezogen werden können. Die einzige sichere fortlaufende Nummer, die zur Vollständigkeitsprüfung herangezogen werden darf, ist der Transaktionszähler der TSE. Die TSE arbeitet aus diesem Grund sequenziell, in diesem Zähler darf es keine Lücken geben. 

Es gibt Transaktion mit "DUP" im Namen

In älteren Versionen konnte es vorkommen, dass Transaktionen doppelt auf der TSE abgesichert worden sind. Damit man diese als solche kennzeichnet, steht im Namen der BON_ID "DUP" drinnen, für Duplikat. 

Hier unterscheiden wir zwischen Belegs-Transaktion und SonstigerTransaktion.

Beleg

Falls es in dieser Transkation zu einem Fehler beim Nachbauen der TSE-Daten kommt ist das so erklärbar, dass die Duplikat-Transaktionen keine Daten enthalten, weil wir die Umsätze nicht doppelt exportieren. 

In aktuelleren Daten konnte das vorkommen, falls ein EBON mehrmals erstellt worden ist oder auch ein EBON nach einer normalen Rechnung (via Drucker) erstellt wurde.

SonstigerTransaktion

Es konnte passieren, dass die Logik zum Setzten der negativen Documentnummer mehrfach ausgeführt worden ist. Das führt dann auch zu einem mehrfachen Absichern auf der TSE. So ist es auch dazugekommen, dass ein Tisch als AVBelegabbruch abgesichert worden ist, der Tisch danach aber nochmals als "leer gesplittet" abesichert worden ist.
 

Es gibt Summenfehler

Falls es in einem Export zu Summenfehler kommt (vor allem auch im Kassenabschlussmodul), kann es an einer Aussenstandsdifferenz liegen.

Es gibt kleine Differenzen im Cent-Bereich

Bei älteren Daten (vor der TSE) wurden Rabatte nicht auf 2 Nachkommastellen gerundet. Das kann dazu führen, dass der komplette Tisch bei Umsätzen und Zahlungen mehr als 2 Nachkommastellen hat. Da die DSFinV-K aber für gewisse Felder nur 2 Nachkommastellen zulässt, kann es mit diesen Daten zu Rundungsdifferenzen im kleinen Cent-Bereich kommen. Vor allem wenn mehrer Zahlungswege auf einem Tisch sind.

In "transcations.csv" hat ein Tisch bei "BON_START", "BON_ENDE" den Wert "1970-01-01T01:00:00+01:00"

Es konnte vorkommen, dass es bei leeren Tischen einen Fehler beim Schließen des Tisches gab. Das trat auf, falls der Tisch erst beim Tagesabschluss als leer geschlossen wurde.
Dadurch wurde unter anderem der genaue Zeitpunkt des Schließens nicht gespeichert. In solch einem Fall würde der 1.1.1970 in den Feldern stehen, weil das ist Unixzeit 0 und wird von uns als Fallback verwendet.
Falls die TSE aktiv war, würde man für diesen Tisch die Transaktion "Schließen von verwaisten Transaktionen" auf der TSE haben. In dem Fall konnte die Transaktion zwar gestartet werden, aber nicht geschlossen. Und beim Tagesabschluss werden alle offenen Transaktionen auf der TSE geschlossen. 

Bar/Unbar stimmen auf der TSE-Absicherung nicht

Das konnte vorkommen, falls nicht die Finanzart "Bargeld" verwendet wurde, um Bargeldfinanzwege abzubilden. Das ist ein bekannter Bug, welcher gefixt wird. Die alten Daten werden trotzdem hier einen Fehler hervorrufen.

Eine andere Möglichkeit war ein Bug, dass nachdem Absichern auf der TSE der Finanzweg von Bar auf Unbar gewechselt wurde.

TSE-Absicherung, Umsätze/Zahlungen stimmen nicht mit errechneten Beträgen überein bzw. Umsätze stimmen nicht mit den Zahlungen auf der TSE überein.

Das sind äußerst seltene Fälle. Falls bei der Absicherung gewisse Daten nicht abgesichert worden sind, diese aber im Export enthalten sind. 

Generell sind hier zwei Arten zu unterscheiden.

AVBelegabbruch

Der AVBelegabbruch wird immer ohne Umsätze durchgeführt und ohne Zahlungen. Beim Export werden aber alle Umsatzeinträge exportiert. Falls es nun z.B. eine Aussenstandsdifferenz bei einem abgebrochenen Vorgang gibt (z.B. ein Storno hat einen anderen Wert als der stornierte Artikel), gibt es den Fehler.

Kassenbeleg

Das kann durch folgende Bugs passiert sein:

• Ein Storno hat Count 0 + einen Tenderstorno mit Preis. Dieser Tenderstorno wurde bei der Absicherung nicht miteinbezogen.
• Es wurden zweimal dieselben Tender gebucht, einmal mit Preis und einmal ohne Preis. Dann wurde der Tender mit Preis storniert. Bei entfernen der Stornos wurde nun der Tender ohne Preis entfernt. Dadurch fehlt dieser Betrag bei der Absicherung, beim Export ist der Storno jedoch enthalten.
• Während eine Zahlung lief, lief eine andere Zahlung. Die erste hat alles abgesichert und wurde gedruckt, die zweite hat einfach noch einen zusätzlichen Datensatz generiert.

Was bedeutet der Tischstatus (ACCOUNTING_TYPE) "empty"/ Leerer Tisch?

LINA POS legt entsprechend der Anforderung "jeden Tastendruck zu protokollieren" bereits beim öffnen eines Tisches einen Datensatz an. Dieser Datensatz erhält zunächst den Status "OPEN". Werden anschließend Artikel auf diesen Tisch boniert, bleibt er "OPEN", bis er bei Rechnungsabschluss zu "BILL" wird. Da wir keine Daten löschen, erhält ein Tisch-Datensatz den Status "EMPTY", wenn

• der Tisch nach dem öffnen sofort wieder geschlossen wird
• alle Artikel eines Tisches auf einen anderen Tisch transferiert werden.

Ein Tisch, welcher am Ende keine Buchungen mehr enthält und folglich auch nicht mit einem Rechnungsdruck abgeschlossen werden kann, wird mit dem Status "EMPTY" geschlossen. Alle Aktionen auf Tischen, sowie auch alle Splitvorgänge werden protokolliert und sofern vorgeschrieben auch über die TSE abgesichert. 

Aus der TSE werden diese Tische mit über den BON_TYP "AVSonstige" abgesichert. Da auf diesen Tische keine Buchungen stattgefunden haben oder alle Buchungen auf andere Tische transferiert wurde, stellen diese Tische keine "Belege" dar, es wird auch kein Beleg gedruckt. 

Wann kommt es zu AV-Belegabbruch

Falls Artikel auf einem Tisch boniert werden und diese werden komplett runterstorniert, wird dieser Tisch als AVBelegabbruch in der TSE abgesichert. Es wird danach sofort ein neuer Tisch geöffnet. Verlässt man diesen Tisch danach, kann es zu einem "Leeren Tisch" kommen.

Wie kann eine Anforderungsliste aussehen: 

Auf diese oder ähnliche Anforderungen einer Betriebsprüfung können wie folgt beantwortet werden: 

• Das eingesetzte Kassensystem ist LINA POS (bis Juni 2023 auch Amadeus360 genannt). Die Bedienungsanleitung findet sich hier: LINA POS
• Der Datenexport aus LINA POS erfolgt im seit dem 01.01.2020 geltenden Format "DSFinV-K". Eine Anleitung für den Export ist hier verfügbar: Finance - DSFinV-K Export
• Die Anforderung, Grundprogrammierungen, Änderungsprotokolle oder ähnliche Dokumentationen zu liefern ist über die Verfahrensdokumentation abgedeckt. Die Anforderung, dass jede Stammdatenänderung protokolliert werden muss ist bei LINA POS in sofern nicht relevant, da alle steuerlich relevanten Daten in den Bewegungsdaten (DSFInV-K - Export) enthalten sind und somit immer zum Zeitpunkt der Buchung festgehalten werden. 
• Programmieranleitung und Bedienungsanleitung finden sich hier: LINA POS 
• Die Verfahrensdokumentation muss durch den Betrieb erstellt werden und ständig aktualisiert werden. Beim erstellen der Verfahrensdokumentation ist in der Regel ein Steuerberater behilflich. Für den Teil der Verfahrensdokumentation, welcher sich mit der Kasse beschäftigt gibt es ein Vorlage für LINA POS: Vorlage Verfahrensdokumentation

Allgemeine Informationen zum Export

Falls es in Daten dazukommt, dass ein Sofortstorno einen anderen Steuersatz hat, als der stornierte Artikel (kann bei alten Daten (vor 2020) vorkommen), wird das im DSFinV-K/Taxonomie Export nicht weiterverarbeitet. Der Artikel wird als storniert geflaggt und vor der weiteren Verarbeitung (auf Transaktionseben und Kassenabschlussebene) ausgeschlossen.

Das kann zu Konflikten mit anderen Exporten führen, welche dieses Sofortstorno nicht entsprechend aus der Verarbeitung ausschließen.