Fonte unica dei dati aziendali
Perché i dati societari (P.IVA, REA, sede, email) vanno tenuti in un unico punto del codice e iniettati ovunque servano, invece di essere riscritti a mano in ogni pagina.
Prima ancora di sapere quali dati esporre, conviene decidere come tenerli nel codice. È una scelta di architettura banale che previene un’intera categoria di errori.
Il problema
I dati societari compaiono in più punti dello stesso sito: footer di ogni pagina, note legali, pagina contatti, informativa privacy, eventualmente i documenti d’ordine di un e-commerce.
Se sono scritti a mano in ognuno di questi punti, prima o poi divergono. Il caso tipico: l’azienda cambia sede, qualcuno aggiorna il footer e le note legali, ma la vecchia sede resta nella privacy policy. Il sito ora dichiara due sedi legali diverse, ed è un dato pubblicato in ottemperanza a un obbligo di legge.
Lo stesso vale per un cambio di ragione sociale, di PEC, di capitale sociale dopo un aumento, o per il passaggio a socio unico.
La regola
Un dato legale esiste in un solo punto del codice. Ovunque serva, viene iniettato da lì.
// config/azienda.ts: l'unico posto dove questi valori sono scritti
export const AZIENDA = {
forma: "srl",
ragioneSociale: "Acme S.r.l.",
partitaIva: "01234567890",
sedeLegale: "Via Roma 1, 20121 Milano (MI)",
rea: "MI-1234567",
capitaleSociale: "€ 10.000 i.v.",
email: "info@acme.it",
pec: "acme@pec.it",
};E nei template, sempre per riferimento:
<p>P. IVA {AZIENDA.partitaIva}</p>Se la partita IVA cambia, si aggiorna una riga e il sito resta coerente ovunque.
Dove tenere la fonte
Dipende da chi deve poterla modificare:
| Fonte | Quando ha senso |
|---|---|
| File di configurazione nel repo | Sito gestito da sviluppatori, dati che cambiano di rado |
| CMS / database | Il cliente deve poterli modificare da solo |
| Variabili d’ambiente | Stesso codice, dati diversi per ambiente o per cliente |
Per la maggior parte dei siti vetrina il file di configurazione è la scelta più semplice e più robusta: sta nel version control, si vede chi l’ha cambiato e quando.
Renderlo difficile da sbagliare
Se il linguaggio lo permette, conviene tipizzare la struttura: i campi obbligatori diventano obbligatori davvero, e quelli che dipendono dalla forma giuridica restano opzionali in modo esplicito.
interface DatiAzienda {
forma: "ditta-individuale" | "snc" | "sas" | "srl" | "srls" | "spa" | /* … */;
ragioneSociale: string;
partitaIva: string;
sedeLegale: string;
email: string;
/** Solo società di capitali */
capitaleSociale?: string;
/** Solo se diverso dalla P.IVA */
codiceFiscale?: string;
rea?: string;
}Così un dato dimenticato è un errore di compilazione, non una scoperta durante un controllo.
Una nota sulla verificabilità
Tenere i dati in un unico punto rende anche possibile testarli. Un test che verifica che il footer renderizzato contenga la partita IVA è banale da scrivere e protegge da regressioni:
test("il footer espone la partita IVA su ogni pagina", async () => {
const html = await render("/");
expect(html).toContain(AZIENDA.partitaIva);
});È il tipo di controllo che vale la pena automatizzare, perché l’obbligo (P.IVA in homepage, art. 35 DPR 633/1972) è puntuale e la sua violazione è silenziosa: nessuno se ne accorge finché non arriva una contestazione.