Alle 8:30 l’ufficio amministrativo ha già in mano il primo nodo della giornata. Dal gestionale su IBM i parte il ciclo attivo: ordine chiuso, merce uscita, fattura da emettere. Il documento contabile, però, non finisce più sulla stampante e basta. Deve diventare un XML conforme, portarsi dietro i dati giusti, uscire dal perimetro dell’ERP storico, arrivare allo SdI e poi tornare indietro con un esito che qualcuno dovrà leggere. Se il gestionale nasce in anni in cui bastava quadrasse il sezionale, questo passaggio non è un dettaglio. È un cambio di mestiere per il software.
Intanto entra il ciclo passivo. Arrivano le fatture dei fornitori, spesso in serie, tutte formalmente corrette eppure ancora lontane dalla registrazione. L’amministrazione apre il file, controlla il fornitore, cerca il riferimento ordine, prova a capire se il documento va a magazzino, a costo, a cespite, a commessa. E qui si vede la scena vera, quella che nei discorsi troppo puliti sparisce: la fattura elettronica su AS/400 non è un adempimento isolato, è un lavoro di incastro fra sistemi, stati del documento, regole che cambiano e persone che non possono ricopiare la stessa informazione tre volte.
Basta generare l’XML? No, è solo l’inizio
La prima aspettativa sbagliata è la più diffusa: se l’ERP produce il file XML, il problema è chiuso. In realtà generare il tracciato è solo il primo pezzo della catena. Il dato va mappato, validato, spedito, collegato alla fattura originaria, mantenuto coerente con anagrafiche, aliquote, riferimenti cliente e stati del documento. Su IBM i questo passaggio pesa ancora di più, perché spesso il gestionale storico funziona bene dove è nato – ordini, contabilità, magazzino – mentre il tracciato FatturaPA appartiene a un’altra grammatica, che cambia quando la documentazione cambia.
E la documentazione cambia davvero. Sul portale FatturaPA, la documentazione aggiornata riporta l’aggiornamento del 31 marzo 2025 con validità dal 1 aprile 2025. Non è un dettaglio editoriale. Vuol dire che i tracciati evolvono e che l’applicativo deve assorbire l’aggiornamento senza rompere il resto: emissione, controlli, archiviazione, riconciliazione. Chi pensa di fissare il formato una volta per tutte ha già preparato il prossimo collo di bottiglia. Anche la documentazione IBM dedicata ai processi di e-Invoicing e compliance ragiona in questa direzione: regole locali e flussi applicativi vanno gestiti come un sistema in movimento, non come una stampa un po’ più moderna.
Per questo, nel mondo IBM i continuano a circolare componenti costruiti per l’innesto e non per la rottamazione del gestionale: conversione XML, gestione degli esiti, raccordo con gli archivi, servizi di stampa e scambio documentale, tutti ambiti documentati nel catalogo di recordinformatica.it.
Chi lavora sul campo lo vede subito. Il problema non è se l’AS/400 sia vecchio oppure no. Il problema è se il flusso è stato montato con una logica da processo oppure con una logica da toppa. Sono due cose molto diverse. Nel primo caso il file XML nasce come estensione del documento ERP. Nel secondo caso diventa una copia laterale che, alla prima variazione del tracciato, costringe qualcuno a fare manutenzione a mano.
Lo SdI non risolve tutto, restituisce lavoro da gestire
La seconda aspettativa sbagliata è questa: una volta inviato il file, ci pensa lo SdI. No. Lo SdI inoltra, controlla e risponde. E quelle Risposte sono parte del processo, non un accessorio. La pagina XMLFatt di Record Informatica lo descrive in modo lineare: il Sistema di Interscambio non si limita a recapitare la fattura, ma restituisce messaggi di errore o di conferma. Tradotto in ufficio: ogni fattura emessa cambia stato più volte, e ogni stato deve essere ricondotto al documento giusto, alla data giusta, alla persona giusta.
Qui si apre il collo di bottiglia tipico. Se l’esito resta fuori dall’ERP, magari in una casella PEC, in un portale o in un visualizzatore separato, il personale amministrativo è costretto a fare il lavoro che il sistema non sta facendo. Cerca il documento, controlla se il file è stato scartato o accettato, avvisa chi deve riemettere, sospende un sollecito, riapre una pratica cliente, segnala al commerciale che quella fattura non è ancora transitata. Sembra poco? In un ufficio che emette tutti i giorni, non lo è affatto.
Lo SdI parla. Il gestionale deve ascoltare.
Su IBM i questa è la differenza fra semplice adempimento e orchestrazione. Il flusso ben montato conserva il legame fra registrazione interna, XML inviato, risposta ricevuta e conservazione finale. Quello montato male crea duplicazioni: il contabile guarda l’ERP, l’addetto alla fatturazione guarda un altro pannello, il responsabile amministrativo chiede un controllo manuale perché non si fida dello stato esposto a video. E quando arriva una modifica di tracciato o di controllo, la fragilità emerge subito. Non perché il sistema storico sia inadatto per natura, ma perché è stato lasciato solo a dialogare con un processo che storico non è.
Ricevere una fattura non equivale a contabilizzarla
La terza aspettativa sbagliata è quasi un riflesso condizionato: se la fattura del fornitore arriva in XML, allora sarà già pronta per la registrazione. In teoria suona bene. In pratica no. Un passaggio molto netto emerso in un documento di Gruppo Vela lo ricorda senza giri di parole: la fattura elettronica non è stata pensata, di per sé, per consentire automaticamente la contabilizzazione degli acquisti. Serve integrazione applicativa. Serve, detto in modo meno elegante, che qualcuno abbia deciso prima come collegare quel file ai processi interni.
Chi ha visto un ufficio fornitori in un’azienda manifatturiera lo sa. Il dato fiscale non basta. La registrazione acquisti richiede spesso l’ordine, il ricevimento merce, il centro di costo, la commessa, un’autorizzazione interna, talvolta un controllo sulle righe, talvolta un raccordo con il magazzino. E il file ricevuto non sempre porta quelle chiavi nel modo in cui il gestionale le aspetta. Così la fattura è arrivata, sì, ma non è ancora pronta a vivere nell’ERP. È solo atterrata.
Mettiamo il caso di un fornitore che compili bene i campi fiscali ma usi un riferimento ordine sintetico, diverso da quello registrato internamente. Oppure di un documento servizi che, per l’azienda ricevente, deve essere ripartito su più centri di costo. Oppure ancora di una fattura che formalmente passa i controlli ma richiede un blocco perché l’ordine non è stato chiuso. L’XML non risolve da solo nessuno di questi snodi. Se manca il ponte con l’applicativo, il risultato è sempre lo stesso: visualizzazione separata, verifica manuale, doppia digitazione, tempo perso e più margine per errori banali.
E poi c’è la conservazione. Che dovrebbe essere l’ultimo tratto del flusso, non una cantina dove buttare i file a fine mese. Se documento emesso, esito SdI, fattura ricevuta e registrazione contabile non restano collegati, l’archivio conserva oggetti corretti ma un processo zoppo. Quando arriva una verifica interna o una contestazione cliente, il problema non è trovare il file. Il problema è ricostruire la storia del documento senza aprire tre sistemi e due cartelle condivise. Chi fa amministrazione da anni lo riconosce subito: quando si cercano le pezze, il montaggio iniziale era sbagliato.
Checklist per aziende IBM i che non vogliono duplicare lavoro
Se il punto è far convivere ERP storico, tracciati XML, esiti SdI e conservazione, la domanda giusta non è se cambiare piattaforma. È se il ciclo attivo e passivo è stato costruito per restare coerente quando cambiano regole e volumi. Una verifica seria, di solito, passa da qui:
- l’XML nasce dai dati dell’ERP oppure da una copia esterna che poi va riallineata;
- gli aggiornamenti del tracciato vengono recepiti senza toccare la logica contabile già in produzione;
- gli esiti dello SdI rientrano nel gestionale come stati leggibili e azionabili, non come messaggi da cercare altrove;
- le fatture passive possono essere abbinate a ordini, magazzino e contabilità con chiavi applicative reali;
- la conservazione mantiene il legame con documento ed esito, invece di archiviare soltanto file;
- chi opera ogni giorno vede un flusso unico, non una sequenza di pannelli e controlli manuali.
Il paradosso è semplice: su IBM i il valore non sta nel cancellare ciò che funziona, ma nel togliere attrito fra ciò che funziona da anni e ciò che fuori cambia di continuo. L’adempimento, da solo, dura il tempo di un invio. L’orchestrazione fatta bene dura molto di più – e di solito costa meno della somma dei rattoppi che nessuno mette a budget, ma che l’ufficio amministrativo paga tutti i giorni.
Informazioni sull'autore
