La fattura elettronica non nasce in XML. Nasce molto prima, dentro un ERP su IBM i, come somma di anagrafiche, codici IVA, condizioni di pagamento, righe d’ordine, arrotondamenti, eccezioni gestite anni fa e poi mai più rimesse in discussione. Quando arriva al tracciato da inviare allo SdI, quella fattura ha già cambiato pelle diverse volte. E ogni passaggio lascia un’impronta: chi ha valorizzato il dato, con quale regola, su quale tabella, in quale versione del programma.
Poi comincia la parte che tutti vedono: trasformazione nel file XML, controlli formali, invio, ritorno di notifiche, eventuale scarto, reinvio, conservazione. Ma l’autopsia seria non si ferma al file trasmesso. IBM, nella documentazione “Panoramica: e-Invoicing e conformità”, tratta l’e-invoicing come tema di compliance IVA e integrazione B2B, non come semplice dematerializzazione. Tradotto: il punto non è produrre un documento digitale, è tenere allineato un flusso di dati che attraversa sistemi diversi e responsabilità diverse.
L’autopsia comincia prima del file
Chi lavora su IBM i lo sa: il difetto raro è quello che nasce nell’ultima trasformazione. Molto più spesso il problema è nell’origine del dato, cioè in ciò che il gestionale considera buono prima ancora di generare il tracciato. La documentazione di www.recordinformatica.it conferma lo stesso nodo: stampa, conversioni e interscambio insistono sul medesimo patrimonio informativo.
Mettiamo il caso che l’anagrafica cliente abbia un indirizzo aggiornato nel modulo commerciale ma non nel contabile, oppure che il codice destinatario sia stato corretto a mano in una tabella di servizio perché “intanto dobbiamo far partire le fatture”. Il file può persino risultare formalmente corretto. Eppure la coerenza interna è già saltata. Se lo SdI scarta, il difetto emerge. Se accetta, peggio: l’errore resta in casa, passa alla conservazione e riappare mesi dopo in riconciliazione o in audit.
Qui sta il primo equivoco. Molte aziende trattano la fattura elettronica come un’uscita del gestionale, quasi fosse una stampa in più con un formato diverso. Non è così. È un oggetto che pretende tracciabilità: da quale documento interno deriva, con quali regole è stato trasformato, quale esito ha ricevuto, dove quel responso è stato registrato. Se manca questo filo, il reparto amministrativo vede una fattura, l’IT ne vede un’altra, la conservazione ne custodisce una terza rappresentazione. Stesso numero, storie diverse.
Aggiornamenti continui, mapping rigido: il guasto è lì
La scheda del software “Compilazione Fattura Elettronica” dell’Agenzia delle Entrate è istruttiva per un motivo semplice: il programma genera il file XML secondo il tracciato aggiornato e verifica automaticamente la presenza di nuove versioni. Non è un dettaglio cosmetico. Dice che l’adeguamento normativo non arriva una volta e poi si chiude. Arriva a ondate, per correzioni, revisioni, affinamenti. Chi ha costruito su IBM i estrazioni rigide, campi appoggiati a tabelle temporanee e conversioni scritte “una tantum” conosce già il conto da pagare.
Perché il rischio non è l’aggiornamento in sé. Il rischio è l’aggiornamento che tocca solo l’ultimo pezzo della catena. Se si modifica il programma che produce l’XML ma non si rivedono i controlli a monte, il sistema continua a spedire dati formalmente allineati al tracciato e sostanzialmente storti rispetto al gestionale. La versione del file cambia, la qualità del dato no. E allora partono i correttivi rapidi: una tabella ponte, un campo di appoggio, una forzatura applicata “solo per questi clienti”. Sono scorciatoie note a chi sta sul campo. E invecchiano malissimo.
La scena si ripete spesso. Prima si tampona per evitare lo scarto, poi si rimanda il riordino del patrimonio dati perché “adesso gira”. Ma una fattura che gira non è per forza una fattura governata. Se il numero documento presente in ERP, identificativo SdI, ricevuta e pacchetto di conservazione non sono legati da un audit trail leggibile, l’azienda resta dipendente dalla memoria di chi ha fatto la toppa. Finché quella persona c’è, tutto sembra sotto controllo. Quando cambia ruolo o esce, arriva il buio.
Il mercato corre, la maturità del gestionale molto meno
I numeri degli Osservatori Digital Innovation del Politecnico di Milano con AssoSoftware aiutano a mettere ordine. Nel 2021 il mercato di software e servizi correlati in Italia ha generato 51,3 miliardi di euro, con una crescita del 14% sul 2020. È un segnale di spesa, non di disciplina. Nello stesso quadro, solo il 9% delle PMI e il 7% della PA risultavano “avanzate” nella maturità d’uso dei gestionali. Ecco il punto: si compra, si integra, si stratifica. Governare davvero il dato è un’altra faccenda.
Su IBM i questo scarto si vede bene. La piattaforma regge carichi, storicizza, porta sulle spalle processi che in molte aziende tengono insieme amministrazione, logistica e produzione. Però il tempo lascia sedimenti: personalizzazioni fatte per cliente, routine nate da urgenze fiscali, campi duplicati per non toccare il cuore del gestionale, procedure manuali tramandate come ricette di reparto. La macchina è robusta. La mappa dei dati molto meno.
Più software non vuol dire più governo.
E non è nemmeno una questione di età del sistema. Un IBM i ben presidiato lavora meglio di molti ambienti più nuovi e molto più rumorosi. Il punto è un altro: chi è proprietario del dato, dove si validano le eccezioni, chi registra le versioni e chi controlla che il ritorno dallo SdI rientri davvero nel ciclo gestionale. Se la risposta è “dipende da chi c’è in ufficio”, la fatturazione elettronica sta solo facendo emergere un problema già presente.
Dove si rompe la catena di custodia del dato
La fattura elettronica su IBM i andrebbe trattata con una logica quasi forense. Una catena di custodia del dato, non un semplice flusso documentale. Primo passaggio: estrazione dal gestionale. Bisogna sapere quali tabelle alimentano i tag critici e con quali priorità. Secondo: trasformazione. Serve traccia della versione del programma e delle regole di mapping applicate. Terzo: trasmissione allo SdI. Va registrato l’identificativo univoco del file inviato. Quarto: notifiche di consegna, scarto, mancata consegna, esito. Quei ritorni devono rientrare nel sistema, non restare parcheggiati in una PEC o in un portale separato. Quinto: conservazione. Il documento conservato deve poter essere ricondotto senza ambiguità al movimento contabile che l’ha generato.
Quando questa catena si spezza, il sintomo arriva tardi. Un revisore chiede perché una fattura risulta emessa a gestionale ma non consegnata nei tempi attesi. L’amministrazione apre il registro IVA, l’IT cerca i log di trasmissione, il fornitore del conservatore mostra il pacchetto archiviato. Tutti hanno un pezzo di verità. Nessuno ha la storia completa. Eppure IBM, quando parla di e-invoicing, insiste proprio su compliance e integrazione tra processi B2B. Non è lessico da marketing: è il promemoria che il rischio reale nasce negli snodi tra sistemi.
5 domande che un IT manager IBM i dovrebbe farsi
- Ogni tag critico dell’XML ha una sorgente dati univoca e documentata, oppure viene riempito con priorità diverse a seconda del programma che lo genera?
- La versione del tracciato e la versione del modulo di generazione vengono registrate insieme alla fattura, in modo da ricostruire il contesto di emissione mesi dopo?
- Le notifiche dello SdI aggiornano davvero lo stato nel gestionale, oppure restano fuori dal perimetro IBM i e obbligano qualcuno a fare controlli manuali?
- È possibile risalire in pochi minuti dal documento conservato alla registrazione contabile originaria, con un collegamento chiaro tra numero interno, identificativo SdI ed esito?
- I controlli bloccano le incoerenze prima dell’invio – anagrafiche, codici IVA, indirizzi, riferimenti – oppure il sistema aspetta lo scarto per scoprire che il dato era sporco?
Se a una di queste domande la risposta è incerta, non c’è un problema di fattura elettronica. C’è un problema di governo del dato che la fattura elettronica sta rendendo visibile. Ed è proprio questo il banco di prova più duro per chi lavora su IBM i: non creare l’ennesimo file corretto, ma dimostrare che quel file è la fotografia affidabile di un processo sotto controllo.