Tra le grandi promesse della fatturazione elettronica, una in particolare ha contribuito alla sua recente entrata in vigore. Si tratta della possibilit\u00e0 di realizzare un\u2019automazione completa dei processi amministrativi e gestionali grazie al trasferimento tra cedente e cessionario dei dati elaborabili presenti nella fattura elettronica.<\/p>\n
In questo approfondimento voglio fare alcune considerazioni su quanto \u00e8 stato effettivamente finora realizzato e su quanto c\u2019\u00e8 ancora da fare affinch\u00e9 questa promessa possa davvero considerarsi concretamente e pienamente mantenuta.<\/p>\n
L\u2019automazione dei processi legati al ciclo attivo di fatturazione, che preveda non solo la contabilizzazione delle fatture emesse, ma anche la riconciliazione con gli ordini, i Ddt, il magazzino, eccetera, senza l\u2019intervento dell\u2019operatore \u00e8 una delle grandi promesse della fatturazione elettronica. Cui si collega inevitabilmente l\u2019automazione, lato ciclo passivo, dei processi di contabilizzazione delle fatture di acquisto, con tutti i risvolti gestionali connessi.<\/p>\n
Nella spinta all\u2019automazione, stanno giustamente entrando – forse in modo un po\u2019 dispotico – le imprese pi\u00f9 strutturate, in particolare quelle della grande distribuzione (Gdo) che, godendo della posizione privilegiata di \u201cgrandi clienti\u201d, stanno imponendo ai propri fornitori l\u2019inserimento di una serie di informazioni appositamente codificate nella struttura Xml, che rendono possibile l\u2019automazione dei processi gestionali.<\/p>\n
La domanda che quindi sorge spontanea \u00e8: a che punto siamo oggi – che siamo entrati pienamente nell\u2019era della fatturazione elettronica – con la digitalizzazione di tutti i processi amministrativi e gestionali? In altre parole, \u00e8 tutto gi\u00e0 pronto e perfettamente automatizzato, oppure c\u2019\u00e8 ancora qualcosa da fare? E quanto resta ancora da fare?<\/p>\n
Chiaramente molto \u00e8 stato fatto, ma evidentemente la risposta a questa domanda \u00e8 si pu\u00f2 fare ancora tanto. Risposta che porta sempre con s\u00e9 l\u2019obiezione che ci siamo tutti fatti cogliere impreparati su questi aspetti, che da anni sono decantati come vantaggi assoluti della fatturazione elettronica. In proposito ci sentiamo per\u00f2 in dovere di fare alcune utili riflessioni, anche di tipo tecnico. Suddividiamo l\u2019analisi per punti:
\n\u2022l\u2019attuale struttura della fattura elettronica non contempla, se non marginalmente, l\u2019indicazione strutturata di tutte le informazioni utili ad automatizzare tutti i processi gestionali;
\n\u2022l\u2019attuale struttura della fattura elettronica prevede per\u00f2 la possibilit\u00e0 di inserire in un formato non codificato, ma codificabile convenzionalmente tra le parti, ulteriori informazioni sia di corpo che di rigo.<\/p>\n
Ne conseguono alcune considerazioni. La prima riguarda il fatto che poter acquisire gi\u00e0 dal 1\u00b0 gennaio 2019 in modo automatico sui propri gestionali la maggior parte dei dati delle fatture di acquisto (importi, descrizioni di rigo, aliquote e nature Iva, eccetera) \u00e8 un primo passo molto importante, che rende la registrazione delle fatture pi\u00f9 rapida e sicura rispetto alla digitazione manuale dei dati, ancorch\u00e9 l\u2019operatore debba per il momento continuare a effettuare alcune operazioni manuali per completare la registrazione.<\/p>\n
La seconda \u00e8 che non \u00e8 del tutto vero che si siano fatti tutti cogliere tutti impreparati su questi aspetti. Il problema \u00e8 esclusivamente di comunicazione. Gli addetti ai lavori, che da anni conoscono l\u2019attuale tracciato, il medesimo che dal 2014 \u00e8 utilizzato per la fatturazione alla Pa, hanno ben chiaro da sempre che un\u2019automazione condivisa sar\u00e0 possibile e si potr\u00e0 raggiungere quando, all\u2019interno delle fatture emesse, i fornitori inseriranno tutte le informazioni necessarie, in modo strutturato ed elaborabile.<\/p>\n
Ma che cosa significa \u00abin modo strutturato ed elaborabile\u00bb? Si pu\u00f2 gi\u00e0 fare qualcosa? E se s\u00ec, perch\u00e9 non \u00e8 stato gi\u00e0 fatto? La risposta a questo legittimo interrogativo \u00e8 complessa e richiede un esame articolato dei fatti.<\/p>\n
La fattura elettronica \u00e8 nata come obbligo – com\u2019\u00e8 noto a tutti – per esigenze fiscali, in particolare di controllo delle frodi in ambito Iva. Per questo motivo tutta la sua gestione \u00e8 stata affidata dal nostro legislatore all\u2019agenzia delle Entrate, che si \u00e8 concentrata su tutti gli aspetti che riguardavano l\u2019ambito fiscale.<\/p>\n
Gli aspetti gestionali sono stati quindi lasciati alla libera impostazione degli stakeholders (tra cui le Gdo), che per\u00f2 sono molti e finora non si sono ancora organizzati per concordare soluzioni comuni.<\/p>\n
L\u2019unico soggetto che da subito ha proposto un tracciato codificato valido per tutti \u00e8 proprio AssoSoftware, che da quasi due anni ha ufficializzato una codifica comune che utilizza i campi dedicati agli aspetti gestionali contenuti all\u2019interno dell\u2019attuale schema Xml ufficiale dell\u2019agenzia delle Entrate. Si tratta di un tracciato pubblico e libero, visionabile sul sito istituzionale www.assosoftware.it<\/a> e utilizzabile da chiunque sia interessato, senza vincolo alcuno, cui hanno aderito i principali produttori di software associati che ne garantiscono l\u2019elaborabilit\u00e0.<\/p>\n AssoSoftware inoltre, in qualit\u00e0 di socio di Uninfo (Ente italiano di normazione sulle tecnologie informatiche federato all\u2019Uni), ha intrapreso un percorso di sviluppo e standardizzazione del suo arricchimento informativo che dovrebbe portare dapprima alla pubblicazione del documento tecnico come \u00abPrassi di riferimento Uni\u00bb e a seguire a proporre al Cen (Comitato Europeo di Normazione) tale prassi come estensione italiana del prossimo standard europeo sulla fatturazione elettronica.<\/p>\n Dunque, per rispondere al quesito, s\u00ec si pu\u00f2 gi\u00e0 fare, tuttavia ben pochi soggetti si sono fino a questo momento potuti dedicare e hanno potuto richiedere le necessarie implementazioni dei propri software (il che \u00e8 naturale, visto che il rischio di una proroga ci ha accompagnato fino al 1\u00b0 gennaio 2019), per cui ci aspettiamo nei prossimi mesi un\u2019evoluzione dei processi da parte di molti stakeholders che porteranno via via a un\u2019automazione sempre pi\u00f9 spinta dei processi.<\/p>\n Il nostro suggerimento, soprattutto nei confronti delle Gdo che hanno necessit\u00e0 particolari e specifiche, \u00e8 quello di non adottare soluzioni proprietarie la cui implementazione da parte dei produttori software che realizzano le procedure informatiche costituirebbe un costo addebitabile esclusivamente a un solo loro cliente (il fornitore della singola Gdo), ma \u00e8 invece di adottare il tracciato integrato AssoSoftware, che \u00e8 un tracciato nazionale. Leggendo le specifiche tecniche del tracciato AssoSoftware vediamo che \u00e8 previsto il codice \u00abAswCenCost\u00bb proprio per identificare il centro di costo da parte del mittente. A questo punto usando le indicazioni delle specifiche tecniche andremo a implementare il blocco [2.2.1.16] AltriDatiGestionali utilizzando i seguenti tipi dato convenzionali: In questo modo il software della Gdo potr\u00e0 elaborare le fatture in arrivo e smistarle\/contabilizzarle correttamente.<\/p>\n Nel caso in cui il tracciato AssoSoftware dovesse rivelarsi non idoneo a gestire determinate problematiche, l\u2019Associazione si rende disponibile – su richiesta che pervenga per il tramite dei propri associati o anche direttamente nel caso di Gdo di grande rilevanza – a integrare tale tracciato, senza costo alcuno per il richiedente. La soluzione proposta da AssoSoftware \u00e8 chiaramente una soluzione di mercato, nata per far fronte a esigenze gestionali, che – come dicevamo poc\u2019anzi – non essendo di interesse dell\u2019agenzia delle Entrate sono state implementate in modo non codificato nell\u2019attuale schema Xml.<\/p>\n L\u2019auspicio \u00e8 che, partendo dall\u2019iniziativa di AssoSoftware, si apra un confronto vivo con tutti gli stakeholders interessati che porti a condividere codifiche e convenzioni di carattere gestionale per giungere veramente a un\u2019unica \u00abestensione nazionale della fattura elettronica\u00bb.<\/p>\n Fonte “Il sole 24 ore”<\/p>\n","protected":false},"excerpt":{"rendered":" Tra le grandi promesse della fatturazione elettronica, una in particolare ha contribuito alla sua recente entrata in vigore. Si tratta della possibilit\u00e0 di realizzare un\u2019automazione completa dei processi amministrativi e gestionali grazie al trasferimento tra cedente e cessionario dei dati elaborabili presenti nella fattura elettronica. In questo approfondimento voglio fare alcune considerazioni su quanto \u00e8 … Continua la lettura di Fattura elettronica, da AssoSoftware un tracciato per la Gdo<\/span>
\nMa facciamo un caso specifico: supponiamo che la richiesta della Gdo al proprio fornitore sia di far inserire all\u2019interno del tracciato il \u00abCentro di Costo\/Punto Vendita\u00bb a cui destinare la merce acquistata, come si dovrebbe implementare il contenuto della fattura Xml?<\/p>\n
\n\u2022[2.2.1.16.1] TipoDato = \u201cAswCenCost\u201d nel caso di Centro di costo\/Punto Vendita
\n\u2022[2.2.1.16.2] riportare il valore del Centro di costo\/codice del punto vendita destinatario della merce.<\/p>\n