Kassensicherungsverordnung ab 2020 - die technische Seite

[Schokohase]

Dieser Stick ist aber für das aktuelle Szenario - so wie ihr den einsetzen wollt - zwecklos. Denn damit kann man nur beweisen, dass man zum Zeitpunkt X bestimmte Daten gespeichert hat. Mehr nicht.

Ob diese Daten jetzt die echten Daten oder eben Fantasiedaten sind kann damit nicht belegt werden.

Für mich ergibt sich aktuell nur ein probates Mittel, wenn ich beweisen will, dass alles korrekt abläuft: Mit dem revisionssicher abgelegten Protokoll der Druckausgabe vom Bon-Drucker.

Siehe dazu auch Fiskalspeicher-Technik

Natürlich ist es ein Leichtes auch die Druckausgabe entsprechend zu manipulieren, aber denkt euch was passiert, wenn Egon Meier aus Klein-Machnow auf seinem Bon die falschen Preise oder nicht alle Artikel aufgelistet findet. Dagegen ist die Steuerfahndung der reinste Ponyhof.

[Neumann]

Sehe ich nicht so. Ich speichere ja zum Zeitpunkt der Bonausgabe die Werte parallel die relevanten Daten wie Bonnummer, Zahlart, Datum und Zeit sowie die Positionen Artikelname, Preis, Anzahl usw. Diese müssen dann mit den Werten in der Kassendatenbank übereinstimmen.

Warum sollte man Fantasiebons erzeugen? Um seine Steuerlast zu reduzieren müsste man Stornos und Retouren buchen, die ab einem bestimmten Umfang auch zu Misstrauen des Steuerprüfers führen. Der Fiskalspeicher würde diese übrigen genauso klaglos speichern.

Wir gehen noch einen Schritt weiter und speichern jeden Bon - ob er gedruckt wird oder nicht - als PDF ab. Leider sind dann die Datenmengen oft zu groß, um die PDF direkt auf den Stick zu schreiben, da dieser nur eine Kapazität von 4 GB hat. Man könnte sie aber z.B. tageweise komprimieren und dann schreiben.

[Frickler]

Zitat von Neumann:

Sehe ich nicht so. Ich speichere ja zum Zeitpunkt der Bonausgabe die Werte parallel die relevanten Daten wie Bonnummer, Zahlart, Datum und Zeit sowie die Positionen Artikelname, Preis, Anzahl usw. Diese müssen dann mit den Werten in der Kassendatenbank übereinstimmen.

Für das neue deutsche System ist der Zeitpunkt der Bonausgabe schon zu spät, denn es müssen auch die sogenannten "anderen Vorgänge"(*) mitgespeichert werden. Darunter fallen etwa alle Korrekturen am Bon vor der Speicherung, also z.B. die letzte Position löschen, weil man sich verschrieben hat. Außerdem müssen Beginn und Abschluss des Bons mit Uhrzeit gespeichert werden, wobei der Abschluss auch ein "Canceln" des ganzen Bons sein kann (wo man bisher gar keinen Bon gedruckt hätte).


(*) genauer: alle Tastendrücke, die einen Vorgang auslösen. Gibt es etwa eine Taste, die die Lade öffnet, dann muss das mitgespeichert werden!

[Neumann]

An Frickler:

Das halte ich zwar für übertrieben, aber wenn das gefordert wird dann mache ich das eben. Bestellstornos (Gastronomie) und Sofortstornos bei Handelskassen werden jetzt schon dokumentiert.

Bisher gab es bei Steuerprüfengen bei unseren Kunden aber wegen solchen Sachen keine Probleme. Die fallen wegen fehlenden Z-Berichten, fehlenden Geldzählprotokollen und schlecht oder gar nicht geführten Kassenbüchern auf die Nase.
Unser Programm bietet das alles; aber wenn es nicht genutzt wird ist das nicht mein Problem.