Peppol, piattaforme nazionali e sistemi di clearance convivono ancora nel mercato europeo della fatturazione B2B: EFSTA descrive un quadro in cui i modelli restano diversi da Paese a Paese, mentre l’armonizzazione intra-UE legata a ViDA ha come data il 1° luglio 2030, secondo Aruba e Il Sole 24 Ore. Questo dato dice una cosa semplice a chi lavora su IBM i: il formato corretto del documento non basta a dimostrare che tutta la catena commerciale abbia raccontato la stessa versione al cliente.
Immaginiamo un fascicolo ispettivo costruito dopo una contestazione. Dentro ci sono cinque documenti estratti dal sistema: il listino applicato, la conferma d’ordine, le condizioni stampate sul modulo, la fattura in formato elettronico, l’addebito SEPA collegato all’incasso. Tutti esistono. Tutti hanno una data. Tutti sembrano ordinati. Eppure possono non provare la promessa fatta al cliente, se fra offerta, clausole e comunicazioni commerciali è rimasto uno scarto.
- Listino attivo in anagrafica al momento dell’ordine.
- Conferma d’ordine prodotta dal gestionale.
- Condizioni commerciali stampate o allegate.
- Fattura elettronica inviata al sistema previsto.
- Mandato o addebito SEPA usato per l’incasso.
Il documento formalmente corretto non è la storia completa
Un vecchio AS/400, o un IBM i tenuto in ordine, spesso conserva meglio di tanti sistemi recenti la traccia delle operazioni. Codici cliente, date di validità, condizioni di pagamento, sconti, causali, numeratori, archivi storici: nei capannoni e negli uffici amministrativi questa solidità ha ancora un peso. Ma un archivio ordinato non è automaticamente un archivio probatorio completo.
La differenza sta nel verbo promettere. Il gestionale registra ciò che qualcuno gli ha fatto registrare. La stampa mostra ciò che il programma di output ha pescato da tabelle, testi fissi e variabili. L’XML porta ciò che il tracciato consente di portare. Il flusso SEPA incassa secondo una regola bancaria. Nessuno di questi passaggi, da solo, certifica che il messaggio commerciale iniziale fosse allineato a ciò che poi è stato fatturato e incassato.
Immaginiamo un’offerta al consumatore con un prezzo promozionale, una durata indicata nella comunicazione commerciale e una clausola di rinnovo scritta in un allegato standard. Il sistema può emettere una conferma d’ordine pulita, con imponibile corretto e condizioni tecnicamente presenti. Può poi generare una fattura senza errori formali. Però, se la comunicazione iniziale lasciava intendere altro, il fascicolo amministrativo non chiude la questione. La apre.
Qui l’errore tipico è confondere la tenuta del sistema con la tenuta del racconto aziendale. Sono due livelli diversi. Il primo dipende da programmi, archivi, autorizzazioni e flussi. Il secondo dipende dalla coerenza fra vendite, marketing, amministrazione, legale e assistenza clienti. Se questi reparti usano parole diverse per descrivere lo stesso prezzo, la stessa durata o la stessa penale, l’IBM i registrerà una parte della vicenda, non tutta.
Il controllo fatto solo a valle, quando la fattura è già uscita, è un controllo debole: arriva dopo che la promessa è stata consegnata al cliente e dopo che l’azienda ha già prodotto una prova contro se stessa, se quella promessa era ambigua.
Il formato europeo variabile non assolve il processo interno
EFSTA richiama un fatto che chi lavora con clienti esteri vede subito: in Europa non esiste ancora una sola grammatica operativa della fatturazione B2B. Peppol, piattaforme nazionali e sistemi di clearance non sono tre etichette intercambiabili. Cambiano i canali, cambiano i controlli, cambiano i tempi di accettazione, cambia il tipo di informazione che il sistema ricevente pretende o scarta.
Questo dato viene spesso letto come un tema tecnico. Lo è, ma non basta. Se un’azienda vende in più mercati e mantiene il cuore gestionale su IBM i, deve tradurre la stessa operazione commerciale in uscite documentali diverse. Una piattaforma può accettare un tracciato, un’altra può chiedere un campo ulteriore, un’altra ancora può lavorare con logiche di clearance. In mezzo resta la promessa fatta al cliente: prezzo, durata, opzioni, esclusioni, modalità di recesso, tempi di addebito.
Il rischio nasce quando l’adattamento al canale viene trattato come una semplice conversione. Da un archivio interno si produce una stampa. Dalla stessa base si genera un XML. Da un’altra tabella si alimenta l’incasso. Se la regola commerciale non è unica, ogni uscita può diventare una variante. Non una frode, non per forza un errore fiscale. Una variante documentale, cioè una frase diversa in un fascicolo che dovrebbe parlare con una voce sola.
Ipotizziamo una condizione di rinnovo automatico. La stampa consegnata al cliente la indica in coda, con un testo fisso. L’XML fattura non contiene quel testo perché il tracciato non lo richiede o perché l’informazione è stata mappata altrove. Il SEPA addebita la rata successiva secondo il mandato attivo. Il call center, però, aveva inviato una mail con una formulazione più morbida. Nel fascicolo interno tutto può risultare tecnicamente prodotto. Nella lettura esterna, la sequenza può apparire incoerente.
ViDA sposta in avanti una parte dell’armonizzazione, con obblighi intra-UE indicati dal 1° luglio 2030. La data non rende omogenei i sistemi aziendali per decreto. Prima e dopo quella data, chi parte da IBM i dovrà governare un fatto pratico: il dato commerciale nasce prima del formato di trasmissione, quindi va controllato prima che venga spezzato in stampe, file e incassi.
Quando l’AGCM guarda la pratica, il gestionale diventa una fonte fra altre
L’AGCM consente ai consumatori di segnalare online pratiche commerciali scorrette o pubblicità ingannevole. La stessa Autorità ricorda che, per le violazioni del Codice del Consumo, le imprese possono essere sanzionate fino a 10 milioni di euro. Fra le pratiche illecite rientrano anche quelle che inducono il consumatore a trascurare le normali regole di prudenza o vigilanza.
In un ufficio acquisti B2B puro il tema può sembrare lontano. Nel rapporto con il consumatore, invece, pesa il percorso completo: cosa è stato annunciato, cosa è stato confermato, cosa è stato scritto nelle condizioni, cosa è stato fatturato, cosa è stato incassato, cosa è stato risposto al reclamo. Il gestionale entra nel fascicolo, ma non lo esaurisce.
Immaginiamo una contestazione su un servizio rinnovato. Il cliente sostiene di aver capito che il prezzo fosse bloccato. L’azienda estrae la conferma d’ordine da IBM i, la fattura elettronica e l’addebito SEPA. Tutto torna, sul piano amministrativo. Poi però emerge una comunicazione promozionale con una frase meno precisa, oppure una condizione stampata in corpo ridotto su un modulo vecchio, oppure una mail automatica che parla di prova gratuita senza spiegare bene l’addebito successivo. Il problema non è il singolo campo sbagliato. È la distanza fra ciò che il cliente poteva capire e ciò che il sistema ha poi eseguito.
Nel fascicolo interno dovrebbe comparire una mappa dei passaggi applicativi: ordine, documento, file, incasso, invio al cliente. Una scheda in recordinformatica.it/it può stare nella cartella tecnica accanto a quella mappa quando il tema è la produzione documentale su IBM i, perché separa il livello applicativo dall’uscita consegnata al destinatario senza confonderlo con la validazione commerciale.
Questa separazione è scomoda, ma necessaria. Il programma che stampa una condizione non decide se quella condizione era stata spiegata prima. Il motore che genera il file non sa se il venditore ha usato una formula diversa. La procedura di incasso non valuta se il cliente aveva capito l’effetto economico della clausola. Sono automazioni, non giudici.
Però le automazioni lasciano tracce. E le tracce, quando finiscono in una contestazione, vengono lette in sequenza. Data dell’offerta, data dell’ordine, data della conferma, data della fattura, data dell’addebito, data del reclamo. Se l’azienda deve ricostruire a mano perché un testo commerciale non coincide con quello stampato dal sistema, parte già con una fatica documentale evitabile.
Il controllo utile è sulla coerenza, non sulla sola emissione
Il controllo classico chiede se la fattura è stata emessa, se il file è stato accettato, se il pagamento è passato, se il documento è stato archiviato. Domande legittime. Ma una contestazione sulla promessa commerciale ne porta altre, più fastidiose: il prezzo mostrato al cliente coincide con il listino valido? La condizione stampata era quella in vigore nel giorno dell’offerta? La conferma d’ordine riporta la stessa durata citata nella campagna? L’addebito SEPA segue la stessa periodicità comunicata?
Su IBM i queste verifiche non si fanno con un colpo d’occhio. Servono chiavi comuni, date di validità, testi versionati, legami fra ordine e documento, log sulle variazioni delle condizioni. Servono perché l’azienda non deve limitarsi a dire che il file era corretto: deve poter mostrare che la catena documentale non ha cambiato significato mentre passava da un formato all’altro.
Ipotizziamo un listino aggiornato il lunedì mattina, una campagna partita il venerdì precedente e una conferma d’ordine generata il martedì. Se la campagna citava il vecchio prezzo e l’ordine prende il nuovo, la fattura può essere perfetta e la contestazione restare aperta. Se il sistema non conserva la versione del listino esposta al cliente, l’azienda ricostruisce la vicenda con screenshot, mail, esportazioni e memoria dei reparti. È un lavoro fragile.
La parte più delicata riguarda i testi fissi. Nei sistemi storici, le condizioni stampate possono vivere in archivi separati, programmi di stampa, spool, modelli grafici, tabelle mantenute da persone diverse. Una modifica fatta per sistemare una frase può non arrivare al canale XML, oppure può arrivare alla stampa ma non alla mail automatica. Da fuori, questa distinzione tecnica interessa poco: il cliente vede parole diverse e le mette una contro l’altra.
Un controllo serio non deve trasformare ogni emissione in una pratica legale. Deve però bloccare le incoerenze più visibili prima che escano. Per farlo bastano alcune verifiche dure, poche e ripetute: stessa versione della condizione commerciale su offerta e conferma, stesso prezzo fra listino esposto e ordine, stessa periodicità fra contratto e incasso, stessa descrizione fra documento stampato e file trasmesso, stesso testo nelle comunicazioni automatiche legate al ciclo.
Il fascicolo ispettivo immaginato all’inizio, con cinque documenti in ordine, resta utile. Ma non va scambiato per una prova piena della promessa commerciale. Prova che l’azienda ha prodotto documenti. Non prova, da solo, che quei documenti siano coerenti con ciò che il cliente ha visto, capito e accettato. Da domani si può partire da una verifica semplice: scegliere una promozione attiva, prendere un ordine reale già emesso e confrontare, riga per riga, offerta, conferma, condizioni stampate, XML e addebito collegato.