Probleme beim Einloggen

Registrierkassen - Kassensicherungsverordnung Deutschland

Ab 2020 kommt der Manipulationsschutz in Deutschland. In dieser Gruppe wollen wir in Zusammenarbeit mit Experten Infos liefern.

Frank Fröse t - 12 Monate: Warum ist es noch so ruhig im Markt?
Die Kassensicherungsverordnung ist eine Riesensache, die jedes Handelsunternehmen in Deutschland betrifft. Alle Kassensysteme müssen bis zum 1.1.2020 aktualisiert worden sein. In Hardware oder in Software.
Was ich nicht verstehe ist warum es im Markt noch so ruhig ist. Nach meinen Recherchen scheint es heute noch keine einzige zertifizierte TSE im Markt zu geben. Kaum ein Kassenhersteller spielt das Thema bislang groß in der Öffentlichkeit und auch die allgemeine Presse hat die KassenSichV für sich noch nicht als Thema entdeckt.
Wir sind Softwarehersteller eines großen Warenwirtschaftssystems und müssen unser System dieses Jahr KassenSichV-ready bekommen und an unsere Kunden ausrollen. So etwas braucht viele Monate. Damit können wir nicht erst in Q4 beginnen.
Warum hört und liest man so wenig von nervösen Handelsunternehmen die Angst vor den Kosten haben oder Kassensystemherstellern denen die Zeit knapp wird? Glaubt/hofft insgeheim jeder, dass der Termin 1.1.2020 noch fallen wird?
Gibt es irgendwo eine Liste der bereits zertifizierten TSE?
Gibt es zertifizierte Lösungen mit externem Datenspeicher?
Sind nur wir nervös?
+27 weitere Kommentare
Letzter Kommentar:
Nur für XING Mitglieder sichtbar
Eine reine Software-Lösung wird definitiv nicht möglich sein.
Die TSE muss nach CC (ISO15408) inkl. Schutzprofile für die jeweiligen Einzelteile zertifiziert sein. Das bedeutet, dass quasi "vom Prozessor bis zur Laufzeit" alles Zertifiziert sein muss. Die TSE wird also immer eine Hardwarekomponente beinhalten. Je nach Ausführung kann auf dieser Hardware bzw. der zertifizierten Architektur natürlich Software laufen.
Es wird am Markt vermutlich zwei Varianten geben:
- TSE als reines Hardware-"Kastl" zum Anhängen via USB oder ähnlicher Schnittstelle
- TSE im Netzwerk (Cloud) über eine API (REST, SOAP, o.ä.)
Je nach Ausprägung Ihres Aufzeichnungssystems kann entweder die reine Hardware-Variante oder auch die Netzwerkvariante sinnvoll(er) sein.
Thomas Schäfer Zertifizierung der TSE
Ist irgend jemand schon etwas bekannt, wer die Zertifizierung der TSE vornehmen darf und was sowas kosten wird, beziehungsweise ob jemand schon an einem solchen Modul arbeitet?
Udo Moser MBA Detlef Jäger Erich P. Freitag
+7 weitere Kommentare
Letzter Kommentar:
Eine Ergänzung betreff Zertifizierung: es ist eine zertifizierte TSE zu verwenden. Eine Zertifizierung des Aufzeichnungssystems selbst ist so oder so nicht vorgesehen. Die Aufzeichnungssysteme müssen sich korrekt einer zertifizierten TSE bedienen.
Auf Grund des Aufwands und der Kosten einer kompletten TSE-Zertifizierung fehlt mir die Phantasie, dass ein Kassenhersteller eine TSE "nur für sich" baut und zertifizieren lässt.
Nur für XING Mitglieder sichtbar Wann genau schickt die Kasse bei Beginn der Transaktion Daten an die TSE?
Dieser Inhalt ist nur für eingeloggte Mitglieder sichtbar.
Holger Matz Detlef Jäger Erich P. Freitag
+32 weitere Kommentare
Letzter Kommentar:
Wie verschieden man die Umsetzung sehen möchte hängt von der Metaebene der Sichtweise ab. Auf einer sehr hohen Ebene ändert sich nicht viel - Transaktionen sind zu protokollieren und Daten müssen exportiert werden können. Wenn sie aber ins Detail gehen, sind meiner Meinung nach die Unterschiede doch sehr groß.
Es gibt einige Unternehmen, die an zertifizierten TSEs arbeiten. Nachdem das ganze Thema vergleichsweise neu ist und die Vorgänge rund um die Zertifizierung komplex sind, wird es noch mindestens geschätzte 6...9 Monate dauern, bis konkrete und zertifizierte Implementierungen verfügbar sind. Meiner Meinung nach richtig ist, dass es nur Sinn macht, dass einige wenige Hersteller TSEs entwickeln und diese anbieten.
Das hindert aber meiner Meinung nach niemand daran, die Kassenseite bereits jetzt anzugehen. Die Anbindung einer TSE ist letzten Endes nur eine Schnittstelle. Der Funktionsumfang ist ziemlich klar, die Ausprägung noch nicht. Mit der Verfügbarkeit einer TSE ist das Thema der Kasse noch lange nicht erledigt - es sind dort gröbere Eingriffe zu tätigen.
Erich P. Freitag Kassensicherungsverordnung (3b) - Update und FinishTransaction
UpdateTransaction:
Ändern sich Daten in einem mit StartTransaction begonnenen Aufzeichnungsvorgang bevor dieser abgeschlossen wird, so ist UpdateTransaction spätestens 45 Sekunden (MAX_UPDATE_DELAY) nach einer Änderung aufzurufen. Dabei sind alle seit StartTransaction oder seit dem letzten UpdateTransaction erfolgten Änderungen an die TSE zu übergeben. Bei UpdateTransaction gibt es keine optionale Daten.
short updateTransaction (
in CONDITIONAL unsigned long clientID,
in REQUIRED unsigned long transactionNumber,
in REQUIRED octet processData [],
in OPTIONAL string <100> processType )
Die bei StartTransaction retournierte transactionNumber dient der TSE gemeinsam mit der clientID zur Referenzierung des begonnenen Vorgangs. Die TSE fügt die processData zu den zuvor erhaltenen Daten dazu und speichert diese. Der Wert von MAX_UPDATE_DELAY soll im Aufzeichnungssystem konfigurierbar sein.
short updateTransaction (
out CONDITIONAL DateTime logTime,
out CONDITIONAL unsigned long signatureCounter,
out CONDITIONAL octet signatureValue[] )
Die Rückgabewerte sind deshalb CONDITIONAL, weil die TSE die Daten entweder nur speichern oder gleich signieren und speichern kann. Wie bei StartTransaction werden der signatureCounter und der signatureValue nicht weiter behandelt. Ebenso hat logTime zu diesem Zeitpunkt keine weitere Verwendung.
Als Beispiel einer Änderung wird in der TR-03153 ein Kassiervorgang angeführt, aber auch dass parallel mehrere Vorgänge - zB bei einem Restaurantbesuch - aufgezeichnet werden können. Der beispielhafte Kassiervorgang dürfte für UpdateTransaction allerdings nur dann relevant werden, wenn der Geschäftsfall nicht innerhalb von MAX_UPDATE_DELAY auch tatsächlich abgeschlossen wird (wenn also beispielsweise eine Barzahlung angenommen wird, der Kunde kein Bargeld mit sich hat und auf EC-Zahlung gewechselt wird und dieser Vorgang bis zum Abschluss länger als 45 Sekunden dauert).
FinishTransaction:
Mit FinishTransaction wird ein Geschäftsfall abgeschlossen.
short finishTransaction (
in CONDITIONAL unsigned long clientID,
in REQUIRED unsigned long transactionNumber,
in REQUIRED octet processData [],
in OPTIONAL string <100> processType,
in OPTIONAL/RESERVED octet additionalData[] )
Neben den Signaturdaten wird nochmals eine logTime retourniert; diese stellt jetzt den Zeitpunkt der Vorgangsbeendigung dar.
short finisheTransaction (
out CONDITIONAL DateTime logTime,
out REQUIRED unsigned long signatureCounter,
out OPTIONAL octet signatureValue[] )
Gemäß KassenSichV sind - neben den üblichen Belegdaten wie Unternehmen oder Menge und Art der gelieferten Gegenstände - jetzt auch
• die Transaktionsnummer (erstmalig aus StartTransaction retourniert sowie bei UpdateTransaction und FinishTransaction übergeben)
• der Zeitpunkt des Vorgangsbeginns (logTime aus StartTransaction)
• der Zeitpunkt der Vorgangsbeendigung (logTime aus FinishTransaction)
• die Seriennummer des Aufzeichnungssystems ODER die Seriennummer des Sicherheitsmoduls (aus StartTransaction)
am Beleg anzubringen.
Unter anderem sind darüber hinaus Trainingsbuchungen explizit als solche zu kennzeichnen (siehe „Transaktionen“).
Nachdem die Zahlungsart beim Start einer Transaktion im Allgemeinen noch nicht feststeht (Ausnahme sind zB Trainingsbuchungen), gibt es derzeit zwei Möglichkeiten, damit umzugehen: es wird eine Zahlungsart bereits bei Beginn von StartTransaction angenommen und gegebenenfalls spätestens bei FinishTransaction auf die tatsächliche Zahlungsart angepasst. Oder die Zahlungsart wird zunächst offen gelassen und erst eingetragen, wenn die Zahlungsart endgültig feststeht.
Erich P. Freitag Kassensicherungsverordnung (3a) - StartTransaction
Im Zusammenhang mit Transaktionen sind folgende Funktionen zu verwenden:
• StartTransaction, um eine gesicherte Aufzeichnung zu starten
• UpdateTransaction, um zwischenzeitliche Änderungen zu speichern
• FinishTransaction, um eine abgeschlossene Transaktion abzusichern und zu speichern
Bei StartTransaction übergibt das Aufzeichnungssystem die Seriennummer des Aufzeichnungssystems, die Art des Vorgangs und die bereits erzeugten Daten des Vorgangs an die TSE.
short startTransaction (
in CONDITIONAL unsigned long clientID,
in REQUIRED octet processData [],
in OPTIONAL string <100> processType,
in OPTIONAL/RESERVED octet additionalData[] )
Gemäß KassenSichV kommt zu "Art des Vorgangs" (processType) und "Daten des Vorgangs" (processData) auch eine Zahlungsart hinzu, spätestens bei FinishTransaction. Für die Zahlungsart gibt es lediglich folgende Vorgaben:
• Bar oder unbar
• „keine“, wenn es sich um keinen Geschäftsfall, sondern zB um eine Trainingsbuchung gehandelt hat
Die „Taxonomie Kassendaten“ der DFKA listet weitere Zahlungsarten auf. „Unbar“ ist demnach eine Zusammenfassung für alle unbaren Zahlungsarten, wenn eine Kasse dies nicht weiter unterscheiden kann. Ansonsten stehen „EC-Karte“, „Kreditkarte“ oder „Guthabenkarte“ sowie „elektronische Zahlungsdienstleister“ zur Auswahl.
Die Zahlungsart ist Teil der processData. Warum processType als OPTIONAL definiert ist, lässt sich dahingehend erklären, dass die „Art des Vorgangs“ bei StartTransaction unter Umständen noch nicht bekannt ist.
Für die "Daten des Vorgangs" gibt es keine Vorgaben bezüglich Inhalt und Formatierung. Sie werden aber wohl auch Informationen wie die Menge und die Art der gelieferten Gegenstände oder den Umfang und die Art der sonstigen Leistung und dergleichen enthalten. Bei anderen Vorgängen sind die „Daten des Vorgangs“ sinngemäß zu befüllen.
Das Aufzeichnungssystem erhält auf den Aufruf von StartTransaction unter anderem eine Transaktionsnummer von der TSE. Mit dieser Transaktionsnummer sind alle weiteren zusammengehörigen UpdateTransactions sowie die FinishTransaction aufzurufen, um einen zusammengehörigen Vorgang kennzuzeichnen.
short startTransaction (
out REQUIRED unsigned long transactionNumber,
out REQUIRED DateTime logTime,
out REQUIRED octet serialNumber[],
out REQUIRED unsigned long signatureCounter,
out OPTIONAL octet signatureValue[] )
Die Kassensoftware muss daher auch die Transaktionsnummer zu einem Geschäftsfall, der über die TSE abgesichert wird, zusätzlich mitverwalten. Zusätzlich muss sie sich den Rückgabewert der logTime als Zeitpunkt des Vorgangsbeginns und optional die retournierte Seriennummer merken. Der signatureCounter wird von der Kasse nicht weiter behandelt, der signatureValue wird bei StartTransaction noch nicht benötigt.

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Registrierkassen - Kassensicherungsverordnung Deutschland"

  • Gegründet: 26.11.2015
  • Mitglieder: 341
  • Sichtbarkeit: offen
  • Beiträge: 53
  • Kommentare: 190
  • Marktplatz-Beiträge: 0