Neue Version: fiskaltrust.service Release v1.1

Diese Information ist speziell für Hersteller und Händler gedacht!

Heute wurde das Release v1.1 rund um den fiskaltrust.service zum Produktiveinsatz bereitgestellt.

In dieser News werden die Informationen zu den neuen Releases, welche ab sofort in der Production-Umgebung zur Verfügung gestellt.

In Bezug auf die Ansteuerung des fiskaltrust.Services gibt es keine Breaking-Changes. Es wird nach wie vor das fiskaltrust.interface v1.0.16322.1179 verwendet.

Die Informationen gehen ausschließlich an RegistrierkassenHERSTELLER.

Bitte informieren Sie als Hersteller Ihre RegistrierkassenHÄNDLER eigenständig über diese Neuerungen und auch die entsprechenden, für Ihr Kassensystem spezifischen Anpassungen.

Anbindung von RKSV-SmartCards: fiskaltrust.signing v1.1.17057.1770

Das Modul fiskaltrust.signing.atapdu wurde neu eingeführt und wird zukünftig für die Ansteuerung aller RKSV-SmartCards verwendet.

Das Modul fiskaltrust.signing.atrustapdu bleibt aus Kompatibilitätsgründen erhalten, nutzt jedoch im Hintergrund auch das neue Modul fiskaltrust.signing.atapdu.

Beginnend mit dieser Version ist es notwendig, entweder den Parameter „reader“ oder den Parameter „serialnumber“ oder auch beide zusammen in der Konfiguration der Signaturerstellungseinheit (SCU) anzugeben.

Bestehende Konfigurationen und auch Templates wurden bereits im Rahmen des fiskaltrust.Portal-Update 1.8 automatisch aktualisiert.

  • Wird nur der Parameter „reader“ angegeben, welcher die Leser-Nummer im System darstellt, so verwendet die SCU exakt diesen Leser. Bei der Initialisierung werden keine anderen Leser angesprochen.
  • Wird nur der Parameter „serialnumber“ angegeben (im Template mit „|[scu0_sn]|“ darstellbar), so werden alle am System verfügbaren Leser verwendet. Es wird versucht, das RKSV-Zertifikat von der jeweiligen SmartCard auszulesen und nur dann, wenn die Zertifikatseriennummer dem Parameter „serialnumber“ entspricht, wird dieser Leser mit der entsprechenden SmartCard zum signieren verwendet.
  • Werden beide Parameter „reader“ und „serialnumber“ angegeben, so wird ausschließlich am angegebenen Leser nach der angegebenen Seriennummer des Zertifikats gesucht.

Zur Seriennummer:

  • Der Parameter „serialnumber“ braucht nicht zwingend mit der Seriennummer der SCU selbst übereinstimmen, jedoch ist dies sinnvoll.
  • Wird eine neue SmartCard verwendet, ist es auch empfehlenswert, eine neue SCU anzulegen.
  • Ist der Parameter „serialnumber“ nicht gesetzt und die SCU selbst hat bereits eine Seriennummer, so wird dieser beim Öffnen der Parameter-Konfiguration als Vorgabewert eingetragen.

Die Angabe der Seriennummer in den SCU-Parametern ist generell empfehlenswert, und für folgende Szenarien unbedingt notwendig:

  • Weitere Leser sind am System angeschlossen und werden z.B. für andere Applikationen wie Login oder e-Card verwendet.
  • Falls die Möglichkeit besteht, dass sich die Reihenfolge der Leser bzw. die Systeminterne Leser-Nummer ändert. Z.B. beim Einsatz von Bluetooth-Lesern, BitLocker, integrierten TPM-Modulen, usw.
  • Wenn eine oder verschiedene SCU NACHEINANDER immer wieder an- und abgesteckt wird. Z.B. bei gemeinschaftlicher Verwendung einer Kassenhardware von mehreren Steuerpflichtigen (Ordinationsgemeinschaft, Bauernmarkt mehrerer Landwirte, …)
  • Wenn verschiedene Kassenbetreiber die gleiche Kassenhardware verwenden und mehrere SCU von verschiedenen Steuerpflichtigen GLEICHZEITIG am System angeschlossen sind.
  • Bei Bereitstellung von Netzwerk-SCUs

Beginnend mit dieser Version, verfügen die Module zur Ansteuerung von RKSV-SmartCards über einen Watchdog. Dieser Watchdog startet alle 30 Sekunden und versucht, falls der letzte Zugriff auf die SmartCard nicht erfolgreich war, entsprechend den Parametern „reader“ und „serialnumber“, eine neue Verbindung herzustellen.

  • Der Vorteil dieses Standard-Verhalten ist, dass es ohne zusätzliche Zugriffe auf die RKSV-SamrtCard (Belege aus der Registrierkasse) auskommt und somit auch keine Beeinflussung der Geschwindigkeit sowie keine Abnutzung der SmartCard hervorruft.
  • Der Nachteil liegt in der Tatsache, dass zuerst der Zugriff scheitern muss, um den Watchdog zum Eingriff zu bewegen. Ist keine Backup-SCU vorhanden, führt dies bereits zu einem Ausfall der Signaturerstellungseinheit.
  • Mit dem zusätzlichen Parameter „healthcheck“ kann mit dem Wert „true“ aktiviert werden, dass bei jedem Ablauf des Watchdog versucht wird, einen aktiven Zugriff auf den Leser und die Karte durchzuführen. Dieser Zugriff liefert den realen, aktuellen Status und bei Bedarf kann sofort mit der Herstellung einer neuen Verbindung begonnen werden. Zu bedenken ist, dass keine parallelen Operationen gegen die SmartCard ausgeführt werden können. Somit werden Signatur-Anfragen während dieses Watchdog-Zugriffs hinten angestellt. Es gibt zudem keine Angaben der SmartCard-Hersteller (VDA) wie sich ein dauerhafter Zugriff auf die Karte auf die Lebensdauer auswirkt.

Belegketten: fiskaltrust.service v1.1.17057.1771

Die Beleg-Ketten mit der Lokalisierung für Österreich stehen jetzt in folgenden Varianten zur Verfügung:

  • fiskaltrust.service.sqlite:
    Nutzt zur Speicherung der Daten eine integrierte Variante von SQLite und ist für den Einsatz unter .net4.0 unter Windows vorgesehen.
  • fiskaltrust.service.mono.sqlite:
    Nutzt zur Speicherung der Daten eine SQLite-Datenbankengine welche am System individuell installiert sein muss. Dies ist für den Einsatz unter mono4 für Linux und Mac vorgesehen und benötigt als Voraussetzung das Paket „mono-complete“.
  • fiskaltrust.service.ef:
    Nutzt zur Speicherung der Daten den EntityFramework 6 mit einem fix definierten DataProvider für MS-SQL. Es wird pro Queue ein eigenes Schema in der Datenbank angelegt, sodass Kollisionen mit bestehenden Daten in der Datenbank vermieden werden. Diese Variante ist auch mit den kostenfreien und sehr einfachen MS-SQL-Express-LocalDB kompatibel. Diese Variante ist für den Einsatz auf Windows-Servern bzw. in Verbindung mit MS-SQL vorgesehen.

Die wichtigsten Bug-Fixes im Vergleich zu 1.0:

  • Null-Belege werden ausschließlich als Null-Belege bearbeitet wenn diese ohne zusätzliche Flags angeliefert werden. Bisher wurde die Null-Beleg Operationslogik auch durchgeführt wenn dieser im Trainings-Modus oder mit dem Nacherfassungs-Flag gesendet wurde.
  • Verbesserung der Ausgaben bei Request-Timeouts und Queue-Collisions sowie Performancesteigerung beim Betrieb von mehreren Queues am gleichen System durch die Nutzung der Queue-ID zur Mutex-Bildung.
  • Zeitkonvertierung / Timezone-Berechnung, falls das System keine aktuelle Zeitzone bereitstellt.
  • Bei Nutzung des ChargeItemCase 0x4154000000000000 wird die Aufteilung nach den Hard-Coded-Werten 20%, 10% und 13% durchgeführt. Es ist nicht empfehlenswert dies als Standart-Vorgehensweise zu nutzen, denn im Fall einer gesetzlichen Änderung des MwSt-Satz wird dadurch ein Update des fiskaltrust.service erforderlich. In einem weiteren  Release ist eine Verbesserung der Methode geplant.
  • Die Nutzung des Windows-Event-Log wurde entfernt.
  • Es wird per Exception verhindert, dass Signaturdaten ohne Seriennummer des Zertifikats zusammengestellt werden.
  • Es wird per Exception verhindert dass die CashBoxId vom Request ungleich der betriebenen CashBoxId sind.
  • Beim Erstellen des Startbelegs wird die Monats-Abrechnungsnummer auf das aktuelle Monat gesetzt.
  • Beim Modus der Signaturerstellungseinheit kann zusätzlich ein Kommunikations-Timeout hinterlegt werden. Die Einstellungsmöglichkeit muss im fiskaltrust.Portal noch geschaffen werden. Zusätzlich kann mit dem Parameter „atsscdretry“ die Anzahl der Wiederholungsläufe verändert werden.

Durch diese Änderungen kann eine Abstimmung für die maximale Laufzeit eines Null-Belegs definiert bzw. berechnet werden.

Um in der Zukunft schneller auf Fehlermeldungen zu reagieren, ist geplant weitere Bug-Fix-Releases der Version 1.1. vorzuziehen.

Launcher: fiskaltrust.service.launcher v1.1.17057.1771

Der Launcher liegt ab Version 1.1 in zwei Varianten vor.

  • „.net“ für Windows
  • „mono“ für Linux und Mac.

Bei Windows XP, Linux und Mac ist es erforderlich, den „servicefolder“ zu setzen. Dieser Pfad soll keine zu langen Dateinamen ergeben (Beschränkung von Windows XP) und auch bei der Ausführung schreibende Zugriffe erlaubt (Linux, Mac). Der Launcher in der Version 1.1 kann problemlos die Module der Version 1.0 betreiben. Daher ist es auf jeden Fall empfehlenswert, diesen ab sofort bei allen Installationen zu verwenden und auch bestehende Installationen bei Gelegenheit zu aktualisieren. Wenn beabsichtigt ist, die Beleg-Ketten auf Version 1.1 zu aktualisieren, ist es empfehlenswert, den Launcher vorher zu aktualisieren! Die Launcher werden auch unter nuget.org veröffentlicht und können auch von dort direkt in den eigenen Setup- oder Deployment-Prozess eingebunden werden.

Die wichtigsten Bug-Fixes im Vergleich zu 1.0:

v1.1.17057.1771

Die Reihenfolge der Nutzung der Fall-Back-Konfiguration im Offline-Fall wurde von „1. Launcher-Verzeichnis und 2. Servicefolder“ auf „1. Servicefolder und 2. Launcher-Verzeichnis“ geändert.

Da von vielen Herstellern/Händlern das ZIP-File vom fiskaltrust.Portal direkt zum Deployment verwendet wird und in diesem Zip-File auch die „configuration.json“ zum Zeitpunkt des Downloads inkludiert ist, wird diese oft mit ausgeliefert (was nur für den Parameter -useoffline nötig ist). Während der Laufzeit werden alle Daten im „servicefolder“ geführt und aktualisiert, so auch die Online Konfigurationsänderungen. Kommt es nun zu einer Offline-Situation und es liegt im Launcher-Verzeichnis eine configutaion.json, so wurde diese in der Vergangenheit als erste Fall-Back-Konfiguration genutzt. Dies war nicht immer optimal.

Daher wird ab sofort immer als erste Fall-Back-Konfiguration diejenige im „servicefolder“ verwendet und als zweite die Fall-Back-Konfiguration aus dem File configuation.json im Launcher-Verzeichnis. (Diese ist für eine Offline-Installation in Verbindung mit dem Packages- oder Binaries-Verzeichnis notwendig.)

Es ist empfehlenswert, die configuration.json, das Packages-Verzeichnis und das Binaries-Verzeichnis nur zu verwenden, wenn man einen Offline-Installation plant.

Wenn eine Online-Verbindung besteht bei der Installation sollten diese Dateien nicht ausgeliefert werden.

v1.1.17040.1576

  • „Logging“ wurde implementiert, sodass auch beim Betrieb als Dienst die Log-Datei richtig geschrieben wird.
  • Die Injektion des Parameters -sslvalidation=false in die einzelnen AppDomains, in welchen die Module laufen, um falsche oder nicht vorhandene Root-Zertifikate zu ignorieren. Diese Einstellung ist für Windows XP und Linux meistens relevant. Mit dem Launcher 1.0 war ein Start möglich, jedoch konnten keine Online-SCU genutzt werden und auch der Daten-Upload und somit z.B. auch die automatische Startbelegprüfung waren nicht möglich.
  • Setzen der Launcher-Konfiguration mittels Parameter-Aufruf war teilweise nicht implementiert.
    Die Parametrisierung des Launchers kann mittels Aufrufparameter erfolgen, auch wenn der Launcher im Hintergrund bereit als Dienst am System läuft. Der Aufruf bewirkt lediglich die Aktualisierung der fiskaltrust.exe.config bzw. fiskaltrust.mono.exe.config, welche beim nächsten Start verwendet wird um die Grundparameter auszulesen.

Liste mit Aufrufparametern für Konfiguration (Nutzung durch „-Aufrufparameter=Wert“):

cashboxid Setzen des CashBoxId.
GUID im Format 00000000-0000-0000-0000-000000000000
accesstoken Setzen des AccessToken zur Online-Kommunikation
useoffline Setzen des Offline-Modus.
Boolean: true | false
servicefolder Setzt den Arbeitsordner des Dienst für Datenbank, Konfiguration und Assemblies
sslvalidation Setzt den Validierungs-Modus für SSL-Kommunikationszertifikate.
Boolean: true | false
sandbox Setzt die Online-Kommunikation in den Sandbox-Modus für Test- und Entwicklungszwecke.
Boolean: true | false
packagesurl Setzt eine alternative Adresse für packages-Services
logfile Setzt eine Datei zur Speicherung aller Dienst-Ausgaben

Helper und weitere Informationen:

Mit diesem Release wurden auch die Helper für REST-Zugriff, Balancer und Box in das Production-System übertragen.

Aus unserer Erfahrung besteht in mono4 ein Bug in Verbindung mit SOAP-Response im Stream-Format, welches wir für den Journal-Stream nutzen.
Betroffen ist nur, wer mittels mono (möglicherweise auch Xamarin) die Journal-Funktion abrufen möchte. Es betrifft nicht den Betrieb des fiskaltrust.service unter Linux oder Mac.
Einen Work-Around für den Zugriff, haben wir in den fiskaltrust.ifPOS.Utilities bereitgestellt unter dem Funktionsnamen „MonoJournalSOAP“.
Hier wird manuell ein SOAP-Aufruf erzeugt und das Ergebnis dann de-serialisiert.

Weiterleitung der Information

Die Informationen gehen ausschließlich an RegistrierkassenHERSTELLER.

Bitte informieren Sie als Hersteller Ihre RegistrierkassenHÄNDLER eigenständig über diese Neuerungen und auch die entsprechenden, für Ihr Kassensystem spezifischen Anpassungen.