Der Beleg, den man nicht löschen kann

Die meiste Compliance-Arbeit ist Papier, das neben der Software liegt. Das deutsche Kassenrecht ist nicht so. Es greift ins Schema und ordnet es um.

Die Regel ist kurz. Jeder Vorgang an einer Kasse muss von einer zertifizierten technischen Sicherheitseinrichtung — einer TSE — signiert werden, und der signierte Datensatz muss zehn Jahre überdauern, jederzeit für die Finanzverwaltung in einem vorgeschriebenen Exportformat abrufbar.

Lesen Sie das noch einmal mit dem Blick eines Entwicklers. Es gibt kein Löschen.

Was „kein Löschen“ mit einem Entwurf macht

Nehmen Sie etwas Alltägliches: einen Testvorgang. Jedes System hat einen Testmodus, und jeder Entwickler hat irgendwann eine Testbestellung durchs Produktivsystem geschickt, um zu sehen, ob sie durchläuft.

Tun Sie das hier, und die Testbestellung steht ein Jahrzehnt im fiskalischen Datenbestand. Nicht unangenehm — dauerhaft. Sie lässt sich nicht entfernen, denn genau darum geht es bei dem Gerät: Es lässt sich nichts entfernen.

Damit hört „Test und Produktion sind getrennt“ auf, eine Übereinkunft zu sein, und wird zur Struktur. In diesem Bau erklärt ein Kassengerät seine Umgebung entweder als Test oder als Produktion, und ein CHECK-Constraint samt partiellem eindeutigem Index macht nur ein Produktivgerät gleichzeitig zu einer Zusicherung, die die Datenbank durchsetzt. Keine Regel in einem Handbuch. Keine Gewohnheit. Etwas, das die Datenbank Ihnen schlicht verweigert.

Das ist der Unterschied, den die zehn Jahre machen. Normalerweise schreiben Sie das Constraint, das den Fehler abfängt. Hier schreiben Sie das Constraint, das das Jahrzehnt abfängt.

Aus der Spezifikation bauen, nicht aus dem Gedächtnis

Die fiskalischen Daten haben ein Schema, und dieses Schema ist veröffentlicht. Der Client hier setzt sie aus der Spezifikation zusammen, die die Schnittstelle selbst ausliefert, statt aus jemandes Erinnerung daran, wie die Felder hießen.

Das klingt pedantisch, bis man die Alternative bemerkt: Ein Entwickler liest die Spezifikation einmal, schreibt auf, woran er sich erinnert, und liefert aus. Es besteht die Tests, weil die Tests aus derselben Erinnerung geschrieben wurden. Es scheitert in der Prüfung, Jahre später, auf eine Weise, die niemand mehr rekonstruieren kann.

Die Details, die einem nur der Produktivbetrieb beibringt

Eines davon ist den Eintritt wert.

Der Zeitstempel der Signatur kommt vom Gerät in dem Format zurück, das das Sicherheitsmodul angibt — und das ist eine Eigenschaft des Moduls, keine Konstante des Standards. Das in diesem Bau meldet unixTime: Epochensekunden, als Zahl. Ein anders konfiguriertes schickt womöglich eine ISO-Zeichenkette.

Also nimmt der Code beides an. So etwas entwirft niemand im Voraus. Man lernt es beim ersten Beleg, der auf 1970 datiert ist, und schreibt dann warum in die Datei, damit die nächste Person es nicht hilfsbereit wieder vereinfacht.

Für den Prüfer schreiben, nicht für die Testsuite

Der Export trägt das Zertifikat und den öffentlichen Schlüssel des Sicherheitsmoduls. Nicht weil das Format ein Feld gefüllt sehen will, sondern damit ein Prüfer die Signaturen offline gegen vertrauenswürdige Wurzeln verifizieren kann, ohne das geprüfte System um Selbstauskunft zu bitten.

Lassen Sie es weg, und eine Signatur zu prüfen heißt, genau dem zu vertrauen, was geprüft wird. Das Format erlaubt es. Der Sinn der Übung nicht.

Dieser Grundsatz prägt den Export insgesamt. Er ist ein Bündel aus sechzehn Tabellen in der Reihenfolge, die die Behörde vorgibt — Stammdaten, dann der Tagesabschluss, dann die Einzelaufzeichnungen — und wenn er sich nicht zusammensetzen lässt, sagt er warum. Ein nicht eingefrorener Steuersatz, ein nicht zugeordneter Steuerschlüssel, eine fehlende Steuernummer: Jedes wird zu einem festgehaltenen Problem am Ergebnis, statt zu einer Ausnahme irgendwo weiter oben. Aufgabe des Aufrufers ist es, den fehlgeschlagenen Versuch zu protokollieren, nicht daran abzustürzen. Ein Export, der still scheitert, ist schlimmer als einer, der scheitert.

Warum das nicht nur ein deutsches Problem ist

Wir machen dieselbe Arbeit für Ägyptens Fakturierung und für ZATCA in Saudi-Arabien. Die Formate unterscheiden sich, die Behörden unterscheiden sich, die Fristen unterscheiden sich.

Die Disziplin nicht. Überall dort, wo der Datensatz die Software überlebt, die ihn erzeugt hat, ist der Datensatz das Produkt — und der Code, der ihn schreibt, sollte für jemanden lesbar sein, der ihn in Jahren liest, in einer Auseinandersetzung, ohne Sie im Raum, der es erklärt.

Sprechen Sie mit uns über einen Bau, bei dem Compliance zählt