A cura di Assosoftware
Scelte tecniche interessanti, ma ancora da affinare, per le diverse tipologie di trasmissione telematica in ambito Iva che, per obbligo o per facoltà, ci attendono nel 2017.
Per inquadrare in modo schematico le diverse problematiche occorre distinguere:
■ l’invio trimestrale dei dati di riepilogo delle fatture attive e passive registrate sui registri Iva, da effettuarsi per obbligo ai sensi dell’articolo4, comma 1, del Dl 193/2016 o, in alternativa, per facoltà – ai sensi dell’articolo1, comma 3, del Dlgs 127/2015, in caso di opzione per il regime premiale (specifiche tecniche contenute nel provvedimento dell’agenzia delle Entrate 182070 del 28 ottobre 2016);
■l’invio trimestrale dei dati delle liquidazioni periodiche Iva, da effettuarsi per obbligo ai sensi dell’articolo4, comma 2, del Dl 193/2016 (specifiche tecniche ancora da definire);
■l’invio completo delle fatture attive emesse, ancorché non ancora registrate sui registri Iva, da effettuarsi per facoltà ai sensi dell’articolo1, comma 2, del decreto 127/2015, in caso di opzione per la fatturazione elettronica B2B nei confronti dei clienti che accolgono tale tipologia di fatture (specifiche tecniche FatturaPa, aggiornate alla versione 1.2, in vigore dal 9 gennaio 2017).
Sull’invio dei dati delle liquidazioni periodiche Iva, siamo in attesa di informazioni di dettaglio non ancora fornite dall’agenzia delle Entrate e l’adozione delle modalità FatturaPa/B2B rende l’invio delle fatture B2B già chiaro e con poche incognite. Le maggiori criticità si concentrano sull’invio trimestrale dei dati di riepilogo delle fatture.
Per i tecnici delle società associate ad AssoSoftware sono tre le problematiche da risolvere: per ognuna è stato richiesto un approfondimento all’agenzia delle Entrate e alla Sogei, suggerendo al contempo specifiche ipotesi di modifica.
1) Rendere il file Xml multi-fattura
Pur apprezzando la logica di derivazione dei dati fattura dal tracciato Xml della FatturaPa/B2B, che semplifica la costruzione del file, è innegabile che la gestione massiva di tanti file Xml quante sono le fatture attive e passive da trasmettere complica notevolmente tutte le fasi di costruzione, controllo, trasmissione dei dati, e soprattutto di elaborazione delle ricevute, che verrebbero prodotte una per ciascuna fattura (non sarebbe neppure immaginabile poi stamparle).
Sarebbe quindi opportuno rendere il file Xml multi-fattura (con più blocchi Dte e Dtf), con la possibilità di creare un unico file per l’intera azienda (più file solo nel caso di grandi quantitativi di fatture).
Chiaramente adottando questa nuova logica dovrebbe essere modificata l’impostazione del processo di rettifica/annullamento delle singole fatture, per poter identificare ciascun documento all’interno del file, tuttavia i benefici appaiono comunque evidenti.
2) Introdurre i dati dell’azienda, dell’intermediario e dell’impegno a trasmettere
L’attuale struttura Xml è contraddistinta dell’assenza del “contenitore” azienda (in qualità di soggetto obbligato), trattandosi di un invio indistinto di fatture, anche relative ad aziende diverse, in cui il soggetto obbligato viene desunto fattura per fattura esclusivamente dai dati anagrafici del cliente o fornitore contenuti all’interno della fattura stessa. Non sono neppure previsti i dati dell’Intermediario fiscale (generalmente i dati del commercialista) che invia il flusso per conto delle aziende, assumendosene la responsabilità con apposito impegno; infine mancano i dati del produttore di software che ha generato il file Xml. Con conseguenti difficoltà ad individuare le diverse responsabilità in caso di problemi di qualsiasi natura che dovessero sorgere.
Sarebbe quindi opportuno aggiungere nella struttura Xml i dati relativi all’azienda (il soggetto obbligato), il codice fiscale dell’Intermediario fiscale e la data dell’impegno a trasmettere, il codice fiscale del produttore di software.
3) Eliminare dalla struttura Xml alcune informazioni anagrafiche
L’aver derivato la struttura dei dati fattura dallo schema della FatturaPa/B2B ha generato la richiesta di alcune informazioni anagrafiche che se pur presenti sulle fatture non sono solitamente oggetto di registrazione contabile e rischiano di appesantire non solo i flussi Xml ma anche l’attività degli operatori contabili.
L’indicazione obbligatoria dei dati anagrafici dei clienti e dei fornitori, completi di indirizzo, costituisce infatti un pesante aggravio aggiuntivo, dal momento che gli articoli 23 e 25 del Dpr 633/1972 richiedono esclusivamente l’indicazione della «ditta, denominazione o ragione sociale del cessionario del bene o del committente del servizio» (articolo 23) e l’indicazione della «ditta, denominazione o ragione sociale del cedente del bene o prestatore del servizio, ovvero nome e cognome se non si tratta di imprese, società o enti» (articolo 25). La nuova comunicazione richiede obbligatoriamente molti più dati anagrafici di quelli normalmente rilevati per l’annotazione sui registri Iva, quali i dati anagrafici della stabile organizzazione o del rappresentante fiscale, spesso non registrati in modo completo; dati oltretutto sostanzialmente inutili, visto che l’unico elemento veramente significativo, almeno per gli operatori nazionali, può essere costituito dal codice fiscale e/o dalla partita Iva.