Lo scontrino che non si può cancellare

Quasi tutto il lavoro di conformità è scartoffie che stanno accanto al software. Il diritto tedesco sui sistemi di cassa non è così. Entra nello schema del database e lo riorganizza.

La regola è breve. Ogni transazione a una cassa dev'essere firmata da un dispositivo tecnico di sicurezza certificato — una TSE — e il record firmato deve sopravvivere dieci anni, a disposizione dell'amministrazione finanziaria in un formato di esportazione prescritto ogni volta che lo chiede.

La rilegga con l'occhio di chi sviluppa. Non esiste la cancellazione.

Che cosa fa a un progetto il «niente cancellazione»

Prenda una cosa qualunque: una transazione di prova. Ogni sistema ha una modalità di collaudo, e ogni sviluppatore ha, prima o poi, passato un ordine di prova in produzione per vedere se funziona.

Lo faccia qui e l'ordine di prova resta nel registro fiscale per un decennio. Non scomodo: permanente. Non può essere rimosso, perché il senso stesso del dispositivo è che nulla possa esserlo.

Così «prova e produzione sono separate» smette di essere una convenzione e diventa una struttura. In questo progetto un apparecchio di cassa dichiara il proprio ambiente, di prova o di produzione, e un vincolo CHECK più un indice univoco parziale fanno di un solo apparecchio in produzione alla volta una garanzia che il database impone. Non una regola in un manuale. Non un'abitudine. Una cosa che il database si rifiuterà di lasciarle fare.

È questa la differenza che fanno i dieci anni. Di solito si scrive il vincolo che intercetta il bug. Qui si scrive il vincolo che intercetta il decennio.

Comporre dalla specifica, non dalla memoria

Il payload fiscale ha uno schema, e quello schema è pubblicato. Il client, qui, lo compone a partire dalla specifica che l'API stessa serve, non dal ricordo di come si chiamassero i campi.

Sembra pedanteria finché non si nota l'alternativa: uno sviluppatore che legge la specifica una volta, scrive ciò che ricorda e pubblica. Passa i test, perché i test sono stati scritti dalla stessa memoria. Fallisce alla verifica, anni dopo, in un modo che ormai nessuno riesce a ricostruire.

I dettagli che insegna solo la produzione

Eccone uno che vale il prezzo del biglietto.

La marca temporale della firma torna dal dispositivo nel formato che il modulo di sicurezza dichiara — ed è una proprietà del modulo, non una costante dello standard. Quello di questo progetto riporta unixTime: secondi dall'epoca, come numero. Uno configurato diversamente può benissimo mandare una stringa ISO.

Perciò il codice accetta entrambi. Nessuno lo progetta in anticipo. Lo si impara la prima volta che uno scontrino esce con una data del 1970, e poi si annota perché nel file, così la persona successiva non lo semplifica di nuovo con le migliori intenzioni.

Scrivere per il verificatore, non per la suite di test

L'esportazione porta con sé il certificato e la chiave pubblica del modulo di sicurezza. Non perché il formato pretenda che un campo sia riempito, ma perché un verificatore possa controllare le firme fuori linea, contro radici di fiducia, senza chiedere al sistema sotto verifica di garantire per sé stesso.

Se lo si omette, controllare una firma significa fidarsi proprio della cosa che si sta controllando. Il formato lo consente. Il senso dell'esercizio no.

Quel principio dà forma all'esportazione nel suo insieme. È un pacchetto di sedici tabelle nell'ordine in cui l'amministrazione le elenca — dati anagrafici, poi la chiusura giornaliera, poi le singole registrazioni — e quando non si riesce a comporlo, dice perché. Un'aliquota IVA non congelata, un codice d'imposta non mappato, un numero fiscale mancante: ciascuno diventa un problema registrato sul risultato, non un'eccezione che risale lo stack. Il compito di chi chiama è annotare il tentativo fallito, non andare in crash. Un'esportazione che fallisce in silenzio è peggio di una che fallisce.

Perché non è solo un problema tedesco

Facciamo lo stesso lavoro per la fatturazione elettronica egiziana e per la ZATCA in Arabia Saudita. I formati differiscono, le autorità differiscono, le scadenze differiscono.

La disciplina no. Ovunque il record sopravviva al software che lo ha prodotto, il record è il prodotto — e il codice che lo scrive dovrebbe essere leggibile da qualcuno che lo leggerà fra anni, dentro una discussione, senza che lei sia nella stanza a spiegarlo.

Parliamo di un progetto dove la conformità è critica