Il banco è pieno, il registratore telematico lavora, il farmacista passa un termometro digitale e il cliente, dopo avere già appoggiato la carta sul POS, chiede se può avere fattura. Dietro la scena normale, quella che nessuno fotografa perché non ha niente di eroico, il gestionale su IBM i deve cambiare binario: vendita al banco, richiesta nominativa, dati fiscali, documento da generare, corrispettivo da non duplicare.
Lo stesso termometro, qualche ora dopo, può essere ordinato dall’e-commerce, acquistato da un’azienda per l’infermeria interna o richiesto da un ente pubblico. Il prodotto resta identico. Cambia la natura dell’operazione. E su un AS/400 nato per reggere volumi, causali, archivi e controlli, la domanda va posta prima della generazione dell’XML: che documento nasce da questa vendita?
Le nuove specifiche spostano l’attenzione sul dato prima del tracciato
L’Agenzia delle Entrate, nell’area Fatturazione elettronica e corrispettivi, ha pubblicato l’aggiornamento delle specifiche tecniche della fatturazione elettronica, con una decorrenza precisa per l’adozione. Il dato è sobrio, quasi amministrativo. Però per chi mantiene un gestionale IBM i in una farmacia omnicanale significa una cosa molto concreta: il file XML deve rispettare un tracciato aggiornato, ma il tracciato arriva dopo la decisione commerciale e fiscale.
Il percorso dati dal gestionale al tracciato XML viene affrontato, con fuoco tecnico sulla generazione, su https://www.recordinformatica.it/it/xml-fattura-b2b-pa-as400.htm; nella farmacia omnicanale il ragionamento arretra di una casella: prima si decide che documento deve nascere. Se quella scelta è debole, l’XML sarà formalmente ordinato e concettualmente sbagliato. Una piccola meraviglia dell’informatica amministrativa: il file passa, il processo no.
Supponiamo che il gestionale mostri una maschera vendita con tre campi apparentemente innocui: canale, soggetto acquirente, richiesta documento. Banco, privato, nessuna richiesta: corrispettivo. Banco, privato, richiesta fattura: fattura B2C. E-commerce, privato senza richiesta: gestione coerente con la disciplina del commercio elettronico indiretto, che MigliorShop ricorda non prevede un obbligo generalizzato di emissione del documento fiscale per le farmacie online, salvo casi specifici o richiesta della fattura. Azienda: fattura B2B. Ente pubblico: tracciato PA.
La tentazione è far decidere tutto alla fine, in amministrazione, con un giro di causali e qualche correzione manuale. Questa prassi va lasciata fuori dalla porta. Non perché il personale amministrativo non sappia lavorare, anzi: proprio perché sa lavorare, non deve diventare il filtro umano di una classificazione che il sistema può chiedere all’origine. Se il canale e il soggetto sono noti al momento dell’ordine, rinviare la scelta produce solo controlli tardivi, telefonate e note di credito evitabili.
Quattro viaggi dello stesso prodotto, quattro decisioni documentali
Primo viaggio: vendita al banco. Il termometro viene battuto in cassa, il cliente paga e se ne va. Il gestionale registra il movimento, aggiorna la giacenza e alimenta il flusso dei corrispettivi. Qui la fattura non nasce per inerzia. Nasce solo se il cliente la chiede e fornisce i dati necessari. Il dialogo tipico è breve: serve fattura? Se la risposta arriva dopo la chiusura della vendita, il sistema deve impedire la soluzione creativa, quella in cui si forza un documento a valle e si spera che nessuno debba ricostruire la sequenza. Spoiler: qualcuno dovrà farlo, di solito nel giorno meno comodo.
Secondo viaggio: ordine online. Il cliente compra il termometro sul sito della farmacia, lo riceve a casa o lo ritira in negozio. Qui il canale inganna, perché la vendita sembra più moderna ma il tema fiscale resta antico: bisogna capire se l’operazione rientra nella gestione dei corrispettivi o se scatta la richiesta di fattura. Secondo MigliorShop, per il commercio elettronico indiretto delle farmacie online non c’è obbligo generalizzato di emissione del documento fiscale, salvo casi specifici o richiesta della fattura. Il gestionale, quindi, non dovrebbe generare fatture per zelo automatico. Dovrebbe conservare bene la prova della richiesta, quando c’è, e trattare diversamente l’ordine che nasce già con dati fiscali completi.
Terzo viaggio: acquisto da parte di un’azienda. Il termometro finisce nell’infermeria di un magazzino o sulla scrivania di un ufficio del personale. Qui il soggetto acquirente non è più il consumatore finale che chiede cortesia documentale: è un cliente con partita IVA, anagrafica, modalità di recapito della fattura elettronica, condizioni di pagamento. La decisione documentale deve essere presa prima della conferma ordine. Se l’anagrafica è incompleta, il gestionale deve fermare l’operazione o chiedere integrazione. Accettare un ordine B2B con dati fiscali approssimativi perché tanto poi si sistema significa mettere una mina sotto la spedizione, il pagamento e la riconciliazione.
Quarto viaggio: fornitura a un ente pubblico. Il termometro può essere parte di una piccola fornitura a una scuola, a un ambulatorio comunale, a una struttura pubblica. A parità di articolo venduto, il documento cambia ancora. Non basta dire fattura elettronica: serve il tracciato adatto alla PA e servono i dati richiesti dall’ente. La guida di Farmakom alla fatturazione elettronica per farmacie aiuta a ricordare che il tema non vive solo nel reparto amministrativo, perché la farmacia lavora con clienti molto diversi tra loro. In un gestionale AS/400 la differenza deve stare in causali, anagrafiche, controlli e profili documento, non nella memoria del singolo operatore.
La scena più interessante è quella che sembra banale. Il farmacista chiede al collega dell’amministrazione se l’ordine del Comune va trattato come una normale fattura. La risposta corretta non può dipendere da chi è di turno. Deve essere già suggerita dal sistema, con messaggi comprensibili e campi obbligatori solo dove servono. Un blocco inutile irrita il banco. Un controllo assente irrita chi deve emettere il documento. Tra i due fastidi, il secondo lascia più tracce.
Automatizzare sì, ma senza spegnere il giudizio operativo
Il compromesso sta tutto qui: quanta decisione deve prendere il software e quanta deve restare all’utente? In una farmacia omnicanale, l’automatismo puro è rassicurante finché i casi sono puliti. Canale banco e privato senza richiesta: corrispettivo. Cliente aziendale con dati completi: B2B. Ente pubblico riconosciuto in anagrafica: PA. Ma la giornata reale contiene ordini ibridi, ritiri in negozio di acquisti online, clienti che chiedono fattura dopo avere pagato, anagrafiche nate anni prima e mai bonificate.
Supponiamo che il termometro venga ordinato online da un privato che seleziona ritiro al banco e poi, davanti al farmacista, chieda fattura intestata alla propria attività. Il sistema deve capire se sta cambiando solo il destinatario del documento o l’intera natura dell’operazione. Non è una sfumatura accademica: cambia il flusso da inviare, cambiano i dati minimi, cambia il rapporto tra incasso, documento e magazzino. Se il gestionale consente la modifica senza lasciare traccia, l’errore diventa difficile da spiegare. Se blocca tutto senza alternativa, il banco si arrangia fuori procedura.
Le FAQ dell’Agenzia delle Entrate sulle Modalità di trasmissione delle fatture elettroniche chiariscono il rapporto tra data dell’operazione e data di invio allo SdI. Il chiarimento pesa nei casi di fine mese o fine anno, quando la farmacia chiude la giornata, spedisce merce, incassa, poi si accorge che la fattura richiesta deve rispettare una sequenza temporale precisa. Qui l’AS/400 non deve soltanto produrre XML: deve custodire date, eventi e causali in modo coerente. Una data compilata a mano, scelta per far tornare il mese contabile, è una richiesta di guai con un’interfaccia verde sopra.
La scelta più sana è separare tre livelli. Il primo è la classificazione dell’operazione: banco, online, B2B, PA. Il secondo è la disponibilità dei dati: codice fiscale, partita IVA, identificativi dell’ente, recapito della fattura, indirizzi, eventuali riferimenti d’ordine. Il terzo è la produzione del documento, con le regole del tracciato vigente. Se questi livelli vengono mescolati in una sola causale generica, il gestionale sembra semplice e diventa fragile. Se sono separati, l’operatore vede meno magia e più domande sensate.
Supponiamo che l’Agenzia delle Entrate aggiorni un controllo nel tracciato e che la versione 1.9.1 richieda un adeguamento tecnico dal 15 maggio 2026. Se la farmacia ha legato tutte le scelte a una generazione XML monolitica, ogni variazione tecnica rischia di toccare il modo in cui il banco lavora. Se invece la decisione documentale è modellata prima, l’aggiornamento del tracciato resta nel suo ambito: importante, certo, ma non invade la cassa, l’e-commerce e l’anagrafica clienti più del necessario.
Alla fine il termometro non sa nulla di corrispettivi, B2C, B2B o PA. Lo sa il processo. E lo sa, spesso prima di tutti, chi prepara il pacco in magazzino: se sull’etichetta vede un ente pubblico, un’azienda o un privato, capisce subito se il documento giusto è già nato oppure se qualcuno, più tardi, dovrà inseguirlo.
