Skip to main content

Integration in das Kassensystem

info

this section will be revised and adapted for the certified version 2 of the the fiskaly Cloud-TSS!

Der Systemintegrator sollte das SDK auswĂ€hlen, das fĂŒr das Kassensystem geeignet ist. Zum Beispiel muss fĂŒr ein in Java implementiertes Kassensystem das Java-SDK ausgewĂ€hlt werden.

Technische Anforderungen#

KategorieAnforderung
Antwortzeiten50 - 250ms, abhÀngig von der Netzwerklatenz
ProzessablaufAsynchron. Start- und Update-Transaction verursachen somit keine Verzögerung im Aufzeichnungssystem. Nur fĂŒr Finish-Transaction muss auf die Antwort gewartet werden.
Service-FunktionenIdempotent. Ein Vorgang kann beliebig oft wiederholt werden. Der erwartete Seiteneffekt tritt jedoch nur ein einziges Mal ein.
Gleichzeitig geöffnete Transaktionen pro TSEunbegrenzt
UnterstĂŒtzte BetriebssystemeLinux, Windows, u.a. (plattformunabhĂ€ngig)

Datenvolumen fĂŒr eine Transaktion#

Das Datenvolumen fĂŒr eine Transaktion ist abhĂ€ngig vom zu signierenden Payload, jedoch pauschal sehr gering.

Geht man von einem absoluten Minimum an abzusichernden Daten aus, so betrĂ€gt das Datenvolumen pro Transaktion << 1 Kilobyte. Ist ein grĂ¶ĂŸeres Volumen an Daten abzusichern, zum Beispiel um POSLog Transaktionen vollstĂ€ndig zu erfassen, steigt auch das Datenvolumen. Das Maximum der abzusichernden Daten ist theoretisch unbegrenzt.

Die vollstÀndige Absicherung von POSLog Transaktionen bringt den Vorteil, dass weitere Servicedienste wie z.B. Archivierung oder Accounting die Transaktionsdaten weiter verarbeiten können.

Beispiel eines Payloads: Mindestdaten des Attributs processData fĂŒr einen processType “Kassenbeleg” lt. Feldspezifikation der DSFinV-K Beleg^123.45_67.89_0.00_0.00_0.00^111.11:Bar_80.23:Unbar Es ist anzunehmen, dass pro Transaktion 1 kB - 256 kB an zB. Daten ĂŒbermittelt werden. Je nachdem, ob es sich um einen Kassenbeleg, eine Bestellung (lang andauernder Vorgang) oder anderen Vorgang handelt.

Die Bandbreite kann aufgrund unserer asynchronen Architektur sehr gering sein, z.B. via ISDN. FĂŒr den Abschluss einer Transaktion muss jedoch auf die Antwort unseres Systems gewartet werden. Hier ist die Latenzzeit des Netzwerkes die einschrĂ€nkende Komponente, da die zu ĂŒbermittelnden Daten ein sehr geringes Volumen einnehmen.

Antwortzeiten#

Die Antwortzeiten der fiskaly cloud werden maßgeblich durch die Latenzzeiten der Netzwerkanbindung beeinflusst. Innerhalb der fiskaly cloud können wir in unserem Testsystem zur KassenSichV bereits Antwortzeiten von durchschnittlich 64 ms aufweisen. Zu beachten ist, dass das Testsystem noch nicht auf Durchsatz optimiert ist. Es können Antwortzeiten von unter 50 ms in unserem Produktivsystem erwartet werden.

Postman Worfklow and Performance (Screenshot eines fiskaly Cloud-TSE Testdurchlaufs)

Zu berĂŒcksichtigen ist die Latenzzeit der Netzwerkanbindung des Integrators an die Rechenzentren der fiskaly cloud. Aktueller Standort der fiskaly cloud Infrastruktur ist Frankfurt am Main (redundant), weitere Standorte können bei Bedarf zum Beispiel in DĂŒsseldorf und MĂŒnchen zur VerfĂŒgung gestellt werden.

Simultan geöffnete Transaktionen#

Die Anzahl der gleichzeitig geöffneten Transaktionen pro TSE ist in der fiskaly cloud nicht begrenzt. Es können beliebig viele Transaktionen offen gehalten werden.

Subscribe to the Dev-Newsletter