Kassen-Zertifizierung in Frankreich und agile Entwicklung schließen sich aus?

In Frankreich müssen Registrierkassen, POS-Systeme das Einhalten der Gesetze nachweisen. Dazu kann bei einer der beiden Organisationen, LNE oder Infocert, eine Zertifizierung beantragt werden. Oder der Kassenhersteller kann jedem Kassennutzer eine individuelle Bestätigung ausstellen.

Doch sobald der Quellcode der Fiskalisierung verändert wird, erlischt die Zertifizierung bzw. Bestätigung. Damit wird es aber schwierig das eigene POS-System, die eigene Registrierkasse weiterzuentwickeln.

Der „Fiscal Scope“

Bei der französischen Kassensicherheit ist dieser Teil des POS-Systems von zentraler Bedeutung. Es kann auch als der Teil, welcher sich um die Fiskalisierung kümmert bezeichnet werden. Und genau dieser Bereich verhindert die Weiterentwicklung, die Anpassung der Software.

Haupt- und Unterversion

Wir kenn alle die verschiedenen Möglichkeiten zur Versionierung einer Software. Und alle Varianten haben eines gemeinsam: ein Hauptversion und Unterversionen. Wenn wir grobe Änderungen oder sogar „Breaking Changes“ an einer Applikation vornehmen ändert sich üblicherweise die Hauptversionsnummer, beispielsweise von 1.0 auf 2.0. Auch wird hierbei die Unterversion üblicherweise zurückgesetzt, also von 1.14 auf 2.0. Sind es nur kleiner Änderungen, Patches und Bugfixes wird die Unterversion hochgezählt, wie bei 1.14 auf 1.15.

Nun haben die beiden Zertifizierungsstellen jedoch noch eine eigene Versionierung eingeführt: Sobald etwas im Bereich des „Fiscal Scopes“ geändert wird, muss die Hauptversion hochgezählt werden.

Denn das ausgestellte Zertifikat ist an den Namen der Software und auch an die Hauptversion gebunden. Es ist daher nur für jene Applikationen und Versionen gültig, welche auf dem Zertifikat angeführt sind. Wird beispielsweise „HappyPos > 1.4“ zertifiziert, dürfen die Versionen 1.40, 1.41, 1.5 und so fort eingesetzt werden. Jedoch muss für die Version 2.0 eine neue Zertifizierung durchgeführt werden.

Architektur der Software

Wir werden sehen, alles hängt von der internen Architekt ab, ob sie einen kompletten „Code Freeze“ anwenden müssen oder nur ein Teil des POS-System vor Änderungen geschützt werden muss.

Falls Sie nicht gerade mit der Entwicklung eines neuen POS-Systems begonnen haben, dann wird in ihrem gesamten Quellcode die Fiskalisierung verteilt sein. Und hier beginnt auch das Problem. Denn für jede Datei welche Fiskalisierungscode enthält wird am Ende des Audits ein Hash-Code ermittelt und damit vor Veränderungen geschützt. Meistens trifft dies dann jede Datei.

Besser wäre eine andere Variante!

Mit der Integration der fiskaltrust.Middleware erhalten Sie „Compliance-as-a-Service“ und sind größtenteils von den Regeln zur Kassensicherheit befreit. Dieser Teil wird extra zertifiziert und ist nicht direkter Teil des POS.

Nun müssen Sie nur noch die Fiskalisierung zusammenfassen. Schauen wir uns ein Diagramm der Module eines fiktiven POS-Systems an.

Wir sehen sofort die fiskaltrust.Middleware bildet einen unabhängigen Block von POS-System „HappyPos“ und innerhalb des POS selbst, gibt es ein Modul „Fiscalization“. Sozusagen der Idealzustand um den Entwicklern so wenig Einschränkungen als möglich aufzuerlegen. Denn wie wir im folgenden Bild sehen ist der „Fiscal Scope“ sehr klar festgelegt und verteilt sich nicht über das gesamte System.

Der Retter ist das Fiskalisierungs-Modul

Schauen wir jetzt im Detail auf dieses Modul:

Wie wir klar sehen werden die vom POS-System erfassten Daten (1) über eine Schnittstell an das Modul übergeben. In dem Modul werden die Daten für die fiskaltrust.Middleware aufbereitet, die Berechnung und weitere Schritte durchgeführt und das Datenset danach an die fiskaltrust.CashBox (2) übergeben. Die Middleware sichert, speichert, fiskalisiert nun die Daten und übergibt sie wieder an das Fiskalmodul. Mit einer Schnittstelle zum POS wird am Ende der vollständig fiskalisierte Beleg wieder an das POS-System übergeben.

Die perfekte Lösung

Kennen wir nicht, aber etwas was dem sehr nahe kommt. Die einfachste Lösung ist das Zusammenfassen des gesamten Codes innerhalb eines Moduls im POS-System. Dies kann entweder eine Datei mit allen Methoden sein oder auch beispielsweise eine Klasse welche die gesamte Fiskalisierung übernimmt.

Noch besser wäre jedoch das Anlegen eines eigenen Projekts, welches zum Beispiel eine eigene dll-Datei erzeugt. Damit hätten Sie mehrere Fliegen mit einer Klappe erschlagen:

• Der gesamte Code zur Fiskalisierung liegt außerhalb des POS-Systems.
• Die dll-Datei (das Projekt) kann je nach Land getauscht werden und damit wird das POS-System international einsetzbar.
• Das Projekt erhält eine eigene Logik bei der Versionierung, beispielsweise „HappyPos Fiscal 1.1 FR“.
• Nur das Projekt wird mit einem Hash-Wert gesichert.
• Das Fiskalisierungs-Modul wird zur Zertifizierung eingereicht und das POS-System kann jederzeit weiterentwickelt werden.

Resümee

Sie sehen die Zertifizierung ist kein Schreckgespenst! Mit ein wenig Planung vorab schließen sich agile Software-Entwicklung, eine SaaS und eine Zertifizierung nicht aus. Besonders die fiskaltrust.Middleware erleichtert hier den Einstieg und erweitert die Möglichkeiten. Ohne zusätzliche Kosten „Compliance-as-a-Service“ und eine Unterstützung bei der Integration sind nur ein kleiner Teil des Mehrwerts für Ihr POS-System.