Kassensicherungsverordnung ab 2020 - die technische Seite

[TiGü]

Hallo Gemeinde,

ich weiß nicht so Recht, ob dieses Unterforum passt. Ggf. bitte korrigieren.

In absehbarer Zeit werden viele von uns von der Kassensicherungsverordnung ab 01.01.2020 betroffen sein (KassenSichV).
Ich möchte diesen Thread nutzen, um gemeinsam Informationen auszutauschen.

Wie bereitet ihr euch darauf vor?
Welche technischen Merkmale wird diese Fiskalisierung haben?
Welche Auswirkungen hat das für uns als Softwareentwickler?
Gibt es schon Unternehmen, die ein Großteil der Komplexität wegkapseln und z.B. einen Webservice anbieten? Ähnlich wie bspw. die Firma fiskaltrust für Österreich?
Wer oder was ist schon zertifiziert?

Zum weiterlesen:

https://www.bundesfinanzministerium....ierkassen.html

https://www.bundesfinanzministerium..../0-Gesetz.html

https://www.haufe.de/steuern/gesetzg...68_344414.html

https://www.bsi.bund.de/SharedDocs/D...cationFile&v=3

https://www.bsi.bund.de/SharedDocs/D...cationFile&v=4

https://dfka.net/fachwissen-wird-ign...linie-tr-3153/

[Hobbycoder]

Gibt es schon Informationen über die Kosten und Dauer einer solchen Zertifizierung?
Je nach Kosten und Aufwand werden damit kleine Entwicklungsunternehmen aus dem Geschäft gedrängt. Und das auf staatliche Anordnung. Ich habe zum Beispiele eine Kassenanwendung bei einem Kunden laufen, die ich aber niemals noch bei einem anderen Kunden einsetzen kann, da sie zu speziell ist. Im Falle einer notwendigen und zu teuren Zertifizierung, kann ich diese Wartungsgeschäft und die damit verbundenen einstampfen. Zwar könnte ich die Kosten weiterberechnen, aber wenn sie zu hoch sind (und meine Arbeitsleistung kommt ja noch on top), würde mein Kunde sicherlich auf die speziellen Vorteile meiner Anwendung verzichten, und was "von der Stange" nehmen, wo dann ein großes Unternehmen mit entsprechenden Möglichkeiten hintersteht.

[Frickler]

Soweit ich weiß, arbeitet fiskaltrust auch an einer Lösung für Deutschland. Auch der Anbieter "efsta.net" (der bereits außer Österreich auch die Fiskalisierungen für Tschechien, Frankreich, Kroatien, Italien und Slowenien abdeckt) wird eine Lösung anbieten.
Um unabhängig von diesen Anbietern immer auf dem Laufenden zu bleiben, ist vermutlich eine Mitgliedschaft im DFKA umumgänglich... (ist uns zu teuer).

[Frickler]

Zitat:

Zitat von Hobbycoder (Beitrag 1407510)

Gibt es schon Informationen über die Kosten und Dauer einer solchen Zertifizierung?

Zertifiziert wird nicht Deine Kasse! Sondern "nur" die Sicherheitseinheit. Diese wird man dann von einem der zertifizierten Anbieter einkaufen müssen.

[Hobbycoder]

Was genau ist die "Sicherheitseinheit"?
Meine Kasse funktioniert nach dem Prinzip: Login-Erfassung-Speichern
Kassenbenutzer müssen sich anmelden, und können nur Kassebuchungen hinzufügen. Storno kann nur der Admin, löschen geht gar nicht. Fortlaufender nicht veränderbarer Nummernkreis, mit täglicher Kassenabrechnung.
Speicherung in MySQL-DB, mit Prüfsumme unter Einberechnung der Prüfsumme der verhergehenden Kassenbuchung. Wo soll ich da was einbauen?

[TiGü]

Zitat:

Zitat von Frickler (Beitrag 1407511)

Soweit ich weiß, arbeitet fiskaltrust auch an einer Lösung für Deutschland. Auch der Anbieter "efsta.net" (der bereits außer Österreich auch die Fiskalisierungen für Tschechien, Frankreich, Kroatien, Italien und Slowenien abdeckt) wird eine Lösung anbieten.
Um unabhängig von diesen Anbietern immer auf dem Laufenden zu bleiben, ist vermutlich eine Mitgliedschaft im DFKA umumgänglich... (ist uns zu teuer).

Vielen Dank für das Aufzeigen eines weiteren Anbieters. Dessen Internetseite lautet aber http://efsta.org/ und macht einen eher halbfertigen Eindruck. Der Link zur Unterseite http://efsta-test.lets-go.technology...eitsloesungen/ ist tot.
Wie machen die das? Auf welcher technischer Basis läuft das bei denen? HTTP-REST, XML-SOAP, DLL...?

[TiGü]

Zitat:

Zitat von Hobbycoder (Beitrag 1407518)

Was genau ist die "Sicherheitseinheit"?

Ich habe mir die Mühe gemacht, diverse Quellen und Links im Eröffnungsbeitrag einzufügen.
Siehe bitte ab Seite 13 der PDF des vierten Links von oben.
Hier der Vollständigkeit halber nochmal:
https://www.bsi.bund.de/SharedDocs/D...cationFile&v=3

[Hobbycoder]

Hab ich gelesen. All diese Punkte erfüllt meine Kasse bereits eigenständig. Muss ich jetzt trotzdem ein externes, zertifiziertes Sicherheitssystem einbinden, oder verstehe ich das komplett falsch?

[jaenicke]

Zitat:

Zitat von Hobbycoder (Beitrag 1407522)

Hab ich gelesen. All diese Punkte erfüllt meine Kasse bereits eigenständig. Muss ich jetzt trotzdem ein externes, zertifiziertes Sicherheitssystem einbinden, oder verstehe ich das komplett falsch?

Nein, du kannst diesen Teil deiner Anwendung auch nach diesen Richtlinien als eine solche Einheit zertifizieren lassen. Wenn ich mir die Punkte aber so anschaue, bezweifle ich, dass diese rein softwareseitig umgesetzt werden kann. (Prüfsummen als Manipulationsschutz genügen für eine solche Zertifizierung z.B. nicht.) Aber davon abgesehen dürfte die Zertifizierung teurer als der Kauf solcher zertifizierten Einheiten werden.

[Neumann]

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.

Ein einfacher Vergleich der Daten auf dem Stick mit den Daten aus der Datenbank würde jede nachträgliche Manipulation zeigen.

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.

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