KassaDEP

[norbert2]

Ich befürchte ein Kapazitätsproblem mit dem Kassa-DEP - dem RKSV-DEP um genau zu sein. Bei einer großen Firma werden in der Betriebskantine enorme Mengen an Belegen produziert. Da gehen so ca. 1000 Mitarbeiter täglich essen und Jause kaufen. Das RKSV-DEP wird in einer Tabelle eines SQL-Servers gespeichert. Von dort aus kann jederzeit über einen beliebigen Zeitraum das DEP exportiert werden. Ich fürchte aber, dass es früher oder später die Tabelle "sprengt". Ganz abgesehen von BackUp-Zeiten und Speicherplatz. Meine Frage: Wäre es zulässig, nach dem Export des DEP pro Quartal eine Löschung in der SQL-DB vorzunehmen? Das DEP im Json-Format läge dann eh je Quartal vor. Kann mir ehrlich gesagt nicht vorstellen, dass ein Prüftool ein DEP mit Millionen von Sätzen überhaupt prüfen kann. Ob da bedacht wurde, dass eben z.B. in Bertiebskantinen Millionen von Sätzen gespeichert werden müssen? Ich bitte um Ihre Meinungen.

[ErichFreitag]

Die DEP-Sicherung muss immer das komplette DEP vom Startbeleg weg enthalten, sprich keine Stückelung. Mit Löschen o.ä. geht da also nichts und die Basis des RKSV-DEPs - die Aufzeichnungen - dürfen sie ja sowieso nicht löschen.

Die zumindest quartalsweise DEP-Sicherung selbst können sie anderweitig ablegen. Ein Eintrag im RKSV-DEP hat etwa 300 Zeichen.

[asitplus-pteufl]

Danke für die Diskussion und die Antworten. Ich möchte dennoch auf den Standard-Text bezüglich org/technischen Themen hinweisen. Die Intention ist nicht, dass wir damit die Diskussion zu solchen Themen unterbinden wollen, aber wir möchten klar klarstellen, dass seitens A-SIT Plus hier keine Antworten kommen werden/können und somit hier keine falschen Erwartungshaltungen in die Beantwortung gesetzt werden.

Dieses Projekt dient der Behandlung technischer Sachverhalte der RKSV. Wir bitten daher um Verständnis, dass rechtliche/organisatorische Themen im Allgemeinen nicht beantwortet werden können. Für die Beantwortung solcher Fragen bitten wir Sie, die Informationen des BMFs heranzuziehen (siehe https://www.bmf.gv.at/top-themen/Registrierkassen.html). Sollte Ihr Anliegen dort nicht behandelt sein, bitten wir Sie, die am Ende dieses Dokuments genannten Kontaktpunkte bzw. Informationsquellen zu berücksichtigen.

Ein weiterer Hinweis bezüglich den “Issues” in diesem Projekt: Offizielle – mit dem BMF abgestimmte – Aussagen werden nur von den Benutzern der Organisation A-SIT Plus (pteufl, tzefferer, asitplus-pteufl) getätigt. Für die Korrektheit der Aussagen anderer Benutzerinnen und Benutzer kann keine Garantie übernommen werden.

[Phoniexk]

Für den RKSV-Export gibt es jetzt ja noch keine Erfahrungswerte, auch nicht wie die Prüfprogramme der Steuerprüfer aussehen werden.

In Bezug auf das Kassenjournal / Umsatzlisten sind unsere Erfahrungswerte:

Wir stellen die Daten in Form von CSV-Dateien zur Verfügung. Diese CSV-Daten werden von den Prüfern in Excel importiert (war auch noch vor einer Woche bei einem unserer Kunden so). Teilweise haben die Prüfer noch Excel 2003 im Einsatz. Bei Excel 2003 liegt die maximale Zeilenanzahl bei 65.536 Zeilen. Ab Excel 2007 sind es 1.048.576 Zeilen. Bei Unternehmen mit einer hohen Anzahl an Barumsätzen kommt man hier ganz schnell an Grenzen. Der Fall von Excel 2003 liegt erst wenige Jahre zurück, bei uns ging aber mit Excel 2013 alles normal auf. Nach ewiger Suche haben wir diesen "Fehler" gefunden und dem Prüfer die CSV-Datei aufgeteilt.

Meistens wird von den Prüfern zuerst der Jahres-/Monatsumsatz des Unternehmers kontrolliert. Wenn man das Beispiel von @norbert2 aufgreift und noch Menge und handelsübliche Bezeichnung berücksichtigt, werden die Grenzen von Excel ganz schnell ausgereizt. Ein anderes Problem ist auch die Kommastelle/Tausendertrennzeichen, jenachdem ob der Prüfer Komma oder Punkt in den Systemeinstellungen auf seinem Notebook hat. In diesem Fall rechnet Excel dann natürlich falsch.

Man würde sich jetzt denken "Das ist nicht ja nicht unser Problem als Hersteller", aber der Kunde kann das Problem nicht richten und nicht alle Prüfer sind Computerprofis. Folglich landet das Problem beim Hersteller und man muss dann relativ zügig eine Lösung für den Prüfer finden, weil dieser ja aktuell beim Unternehmer sitzt und prüfen möchte.

Beim Export könnte man natürlich dem Prüfer sagen, dass er einfach einen kleineren Zeitraum betrachten muss. Bei der quartalsweisen Sicherung wäre zum Überlegen ob man die Daten nicht auf mehrere Dateien aufteilt.

[AxelKutschera]

Wir haben über 15 Jahren mit den Prüfungen und den Prüfprogrammen der Finanz. Für die Prüfung der Belegverkettung (RKSV-DEP) wird sicher ein ähnliches Programm wie das Prüftool entwickelt.

Für die Prüfung der großen Datenmengen (E131-DEP) wird ACL verwendet. https://www.acl.com/ Damit gibt es keine Beschränkung auf Datensätze und auch keine Probleme mit fehlerhaften Datensätzen. Ich habe ACL in Verwendung. Dafür hat die Finanz auch Wizards, mit welchem auch ein Nicht-IT-Experte diverse Prüfungen machen kann.

Das Aufteilen der Daten auf mehrere Dateien ist nach der RKSV nicht zulässig.

[Phoniexk]

Ja das RKSV-DEP darf natürlich nicht aufgeteilt werden, aber was bleibt beim E131-Export über, wenn der Prüfer es aufgrund der Datenmenge nicht in Excel einlesen kann. Das Problem hatten wir mittlerweile schon mehrmals.

Also von allen Prüfern wird ACL defintiv nicht verwendet. Bei den Prüfungen - von denen wir mitbekommen haben - wurde meistens Excel eingesetzt. Letztes Monat hatten 2 Kunden eine Prüfung und da wurde defintiv Excel eingesetzt, weil es beim Prüfer eben Probleme mit Punkt/Komma für die Kommastelle gab, und wir das Problem suchen mussten.

[AxelKutschera]

Komisch - ich habe viele (große) Prüfungen als Steuerberater unterstützt und es wurde nie Excel zur Analyse verwendet. Mit den Datenmengen wäre Excel - wie beschrieben - auch nicht zurecht gekommen. Excel ist für sinnvolle Prüfungen auch nicht geeignet, da zu langsam und mit Formeln zu große Dateien.