Kassensicherungsverordnung ab 2020 - die technische Seite

[jaenicke]

Zitat:

Zitat von Neumann (Beitrag 1407594)

Eigentlich ist es ganz einfach, Daten manipulationssicher abzuspeichern. Man nimmt einfach einen Secumed-Stick und speichert dort die relevanten Werte parallel zu der Speicherung in die Datenbank in CSV-Dateien. Die sind dann weder löschbar noch veränderbar.

Damit wäre die erste Anforderung erfüllt.
(Deren Lösbarkeit ohne Hardwarelösung ich wie schon geschrieben bezweifle. Eine Sicherung mit inkrementellen Prüfsummen usw. genügt heute den Anforderungen, ab 2020 aber nicht mehr.)

Bleibt aber noch unter anderem die Anforderung nach einem Zeitgeber, der dafür sorgt, dass die Daten mit einer streng monoton steigenden Zeitangabe gespeichert werden, sprich man nicht einfach quasi z.B. einmal pro Tag Phantasiedaten auf eine solche Lösung schreiben kann.

Wenn das euer Stick auch könnte, wäre der auch heute schon durchaus interessant für ehrliche Betreiber, die gerne beweisen möchten, dass bei ihnen alles mit rechten Dingen zugeht.

Zitat:

Zitat von Neumann (Beitrag 1407594)

Einziger Nachteil der Sticks ist der Preis von 80 € netto, für den wir die Sticks verkaufen (geht leider nicht billiger), und dass man sie nur etwas mehr ein Jahr beschreiben kann. Lesen kann man sie garantiert 10 Jahre.

Die Sicherheitseinrichtung wird ziemlich sicher günstiger sein bzw. sein müssen, aber da es eine gesetzliche Anforderung ist, ist der Preis erst einmal zweitrangig solange es keine deutlich günstigere Lösung gibt. ;-)

Gibt es im Internet zu den Sticks eigentlich Informationen?

[Neumann]

War gestern Abend etwas spät - der Stick nennt sich Secumem. Der Zeitgeber ist eingebaut - es gibt ein Journal was alle Vorgänge automatisch protokolliert.

Was gut ist, dass der Stick erlaubt an einfache Dateien wie Textdateien (CSV) Daten anzufügen.

Problematisch ist manchmal, das Rechner je nach Bios-Einstellung versuchen von dem Stick zu booten, was natürlich schiefgeht. Für den Anwender mit einem Kassen-PC ohne Maus und Tastatur kann das schon ein großes Problem sein; dazu kommt noch das fehlende Wissen wie man die Bios-Einstellung ändert.

[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:

Zitat von Neumann (Beitrag 1407620)

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.