La validazione ID fiscale è la pratica di controllare un identificativo fiscale prima che venga memorizzato, fatturato o comunicato — ed è anche il campo in cui le aspettative vengono più spesso poste troppo in alto. Un controllo ben progettato impedirà a cifre trasposte di entrare nel vostro database. Non vi dirà se l’impresa esiste, se il numero è mai stato emesso o se la società che sta dietro ha diritto a qualcosa.
Questo articolo spiega che cos’è un identificativo fiscale, perché alcuni formati possono essere controllati aritmeticamente e altri no, come costruire la validazione a livelli affinché ogni livello risponda a una domanda a cui può davvero rispondere e perché un controllo fallito non deve mai essere segnalato come una società mancante.
Che cos’è un identificativo fiscale?
È l’identificativo che un’amministrazione fiscale assegna a un contribuente. Questa è tutta la definizione, ed è volutamente ampia, perché i paesi organizzano la registrazione fiscale in modi molto diversi.
Un paese può avere un unico numero fiscale nazionale usato per tutto. Un altro può avere numeri separati per imposte diverse, così un’impresa detiene un identificativo per le imposte dirette e uno diverso per l’imposta sul valore aggiunto. Un altro ancora può usare un numero che precede del tutto il sistema fiscale, essendo stato introdotto per uno scopo amministrativo diverso e poi adottato ai fini fiscali. Alcune giurisdizioni usano un unico identificativo che funge anche da numero di registrazione aziendale; altre li tengono rigorosamente separati.
Ne derivano immediatamente due conseguenze. In primo luogo, “numero fiscale” non è in realtà un campo unico; è una famiglia di campi la cui composizione dipende dal paese. In secondo luogo, qualsiasi affermazione del tipo “un numero fiscale contiene sempre x” è falsa da qualche parte, ed è per questo che la vostra validazione va scritta in modo difensivo.
Perché alcuni numeri fiscali portano una cifra di controllo?
Perché l’autorità emittente li ha progettati così. Una cifra di controllo è una ridondanza aritmetica: l’ultimo carattere, o uno incorporato nel mezzo, è calcolato dagli altri secondo una regola pubblicata, così un singolo carattere digitato male o trasposto produce di solito un valore che non supera la regola.
Dove un paese pubblica tale regola, implementarla è genuinamente utile. Coglie gli errori di inserimento più comuni al momento dell’immissione, senza chiamate di rete, senza dipendenze esterne e senza questioni di privacy. È economica, veloce e deterministica — ed è il controllo più forte che potete eseguire localmente.
Dove un paese non pubblica tale regola, l’identificativo è semplicemente un’assegnazione: l’autorità l’ha assegnato e registrato, e nessuna aritmetica può distinguere uno reale da uno inventato. Questo è più comune di quanto gli sviluppatori si aspettino. Alcune giurisdizioni molto grandi emettono numeri progressivi semplici del tutto privi di ridondanza.
L’istruzione che ne deriva è netta. Implementate un algoritmo di cifra di controllo solo per i paesi specifici di cui avete verificato che l’algoritmo è pubblicato e ancora attuale. Non indovinate un algoritmo dalla forma del numero e non presupponete che, poiché il formato di un paese sembra simile a quello di un altro, valga la stessa regola.
| Come appare il numero | Cosa potete controllare onestamente |
|---|---|
| Algoritmo pubblicato con cifra di controllo | Set di caratteri, lunghezza e regola aritmetica |
| Assegnazione semplice, nessuna regola pubblicata | Solo set di caratteri e un limite di lunghezza generoso |
| Formato con prefisso paese o autorità | Che il prefisso corrisponda al paese dichiarato |
| Formato che funge anche da numero di registrazione | Ciò che il registro stesso può confermare |
Superare la validazione significa che il numero è reale?
No. La validità del formato e l’esistenza sono proprietà diverse, e confonderle è l’errore di progettazione più comune in questo ambito.
Un numero sintatticamente perfetto può non appartenere a nessuno. Chiunque comprenda il modello può produrne uno che soddisfa ogni regola locale, compresa la cifra di controllo, perché la cifra di controllo è progettata per cogliere gli incidenti, non gli avversari. Un numero può anche essere del tutto reale e fallire la vostra regola locale, se la regola era stata scritta per un’impaginazione più vecchia, per un altro paese o per un documento che formattava il numero in modo insolito.
L’esistenza è stabilita solo dall’autorità che ha emesso l’identificativo. Dove un’amministrazione fiscale pubblica uno sportello ufficiale di consultazione, quello sportello è la risposta alla domanda sull’esistenza; dove non lo fa, l’esistenza può essere confermabile solo dai documenti forniti dall’impresa. Questa è una garanzia genuinamente più debole e va descritta come tale invece di essere camuffata da verifica.
C’è anche una sottigliezza che sorprende i team: persino una registrazione confermata è un fatto puntuale. Un numero può essere valido oggi e cancellato il mese prossimo, quindi una cache aggressiva di “questo numero è valido” finisce prima o poi con l’entrare in conflitto con la realtà. Memorizzate deliberatamente e preferite memorizzare la risposta con un timestamp invece di conservarla per sempre.
Come dovrebbe essere stratificata la validazione?
In tre passaggi, ordinati per costo, con il più economico e certo per primo.
Il primo passaggio è locale e strutturale: il campo è non vuoto, è entro una lunghezza massima generosa, contiene solo caratteri che compaiono in qualche formato e la dichiarazione di paese corrisponde a qualsiasi prefisso presente. Questo passaggio non dovrebbe quasi mai respingere un input plausibile; il suo compito è cogliere valori vuoti e palesemente danneggiati.
Il secondo passaggio è specifico per paese: applicate la regola pubblicata della cifra di controllo dove ne avete una, e solo lì. Segnalate l’esito come avviso di errore di battitura collegato al campo, formulato come “questo non sembra corretto, per favore verificalo”, perché è ciò che un fallimento della cifra di controllo significa realmente.
Il terzo passaggio è la ricerca autorevole, asincrona e mai bloccante per il modulo. Ha tre esiti che vale la pena di distinguere — confermato, non trovato e non disponibile — e dovrebbe essere in grado di dire quale dei tre si è verificato. Una ricerca che non sa distinguere “nessun numero del genere” da “il servizio è inattivo” finirà per respingere un cliente legittimo in una giornata di rete difficile.
Per gli sviluppatori: errori, cache e registri di controllo
Il lavoro di progettazione riguarda soprattutto l’onestà nella gestione degli errori. Ogni livello dovrebbe produrre un risultato distinguibile e il messaggio che l’utente vede dovrebbe nominare il livello che è fallito. “Non siamo riusciti a contattare l’autorità fiscale, i tuoi dati sono salvati e controlleremo di nuovo” è un messaggio utilizzabile. “Numero fiscale non valido” abbinato a un valore che l’utente ha copiato da un certificato ufficiale non lo è.
Considerate un tipo di risultato esplicito invece di un booleano. Quattro stati — non verificato, forma valida, ricerca confermata, ricerca non trovata — coprono il terreno senza forzare una distinzione che il sistema non può fare. Un booleano li collassa e garantisce che prima o poi un valore legittimo venga trattato come falso.
La cache dovrebbe essere asimmetrica. Un risultato confermato vale la pena di essere conservato per un periodo ragionevole; un risultato non trovato dovrebbe scadere rapidamente, perché le registrazioni cambiano e l’assenza di ieri è una scarsa ragione per respingere il cliente di oggi. Un risultato non disponibile non dovrebbe essere memorizzato affatto come negativo.
Verificate cosa avete controllato senza trasformare il log in una copia del database dei clienti. Registrate il fatto e l’ora di un controllo, il livello applicato e l’esito; evitate di duplicare l’identificativo grezzo in sistemi che non ne hanno bisogno. Dove l’identificativo deve essere conservato, trattatelo come dato aziendale con la stessa cura di qualsiasi altro — e tenete i valori generati chiaramente distinti da quelli reali, che è lo scopo dei campi dell’identificativo fiscale sintetici su questo sito. L’articolo sui formati del numero di partita IVA copre il membro più comune di questa famiglia, e dati aziendali di test mostra come appare il resto di un record aziendale sintetico.
Passi successivi
Inventariate ogni controllo del numero fiscale nel vostro prodotto ed etichettate ciascuno con il livello che implementa. Qualsiasi controllo che respinge un valore sulla base di un modello indovinato dovrebbe essere declassato ad avviso, e qualsiasi messaggio che dice “non esiste” in forza di un test aritmetico dovrebbe essere riscritto per dire cosa è stato effettivamente testato. Poi usate il generatore di dati aziendali per produrre record per diversi paesi e confermate che il vostro modulo gestisca un paese di cui non sa nulla senza rifiutare del tutto l’inserimento.