LIPE (liquidazioni IVA periodiche), XML e sigillo

L’adempimento

L’adempimento relativo alla liquidazione IVA periodca (LIPE) richiede la predisposizione di un file in formato XML contenente i dati da trasmettere.

In questo articolo si vuole approfondire la composizione del file XML generato, e la sua trasformazione in file sigillato, secondo lo standard XAdES (vedi nostro precedente articolo).

Il file XML

Il file XML contiene i dati relativi al periodo comunicato racchiusi in appositi tag specifici. Ad esempio, un file potrebbe essere il seguente

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<iv:Fornitura xmlns:iv="urn:www.agenziaentrate.gov.it:specificheTecniche:sco:ivp" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
 <iv:Intestazione>
 <iv:CodiceFornitura>IVP17</iv:CodiceFornitura>
 </iv:Intestazione>
 <iv:Comunicazione identificativo="00001">
 <iv:Frontespizio>
 <iv:CodiceFiscale>XXXXXXXXXXXXXXXX</iv:CodiceFiscale>
 <iv:AnnoImposta>2017</iv:AnnoImposta>
 <iv:PartitaIVA>XXXXXXXXXXX</iv:PartitaIVA>
 <iv:FirmaDichiarazione>1</iv:FirmaDichiarazione>
 <iv:IdentificativoProdSoftware>XXXXXXXX</iv:IdentificativoProdSoftware>
 </iv:Frontespizio>
 <iv:DatiContabili>
 <iv:Modulo>
 <iv:Trimestre>5</iv:Trimestre>
 <iv:TotaleOperazioniAttive>XXXX,XX</iv:TotaleOperazioniAttive>
 <iv:TotaleOperazioniPassive>XXXX,XX</iv:TotaleOperazioniPassive>
 <iv:IvaEsigibile>XXXX,XX</iv:IvaEsigibile>
 <iv:IvaDetratta>XXX,XX</iv:IvaDetratta>
 <iv:IvaDovuta>XXXX,XX</iv:IvaDovuta>
 <iv:Acconto>XX,XX</iv:Acconto>
 </iv:Modulo>
 </iv:DatiContabili>
 </iv:Comunicazione>
</iv:Fornitura>

i dati reali sono stati offuscati con delle X.

Nei files XML i “tag” definiscono gli elementi di struttura. Sono delimitati da parentesi angolari, quello che inizia con / chiude l’elemento.

Nell’esempio si può notare che le direttive XML vengono precedute da “iv:”, che è il namespace xml definito nella seconda riga “xmlns:iv=”.

Così è facile capire che siamo in presenza di una Fornitura, composta da:

  • una <iv:Intestazione>
    • che contiene il <iv:CodiceFornitura>IPV17
  • una sola <iv:Comunicazione>, con identificativo 00001
    • composta da un <iv:Frontespizio>, che a sua volta contiene vari dati
    • una parte di <iv:DatiContabili>
      • per il <iv:Trimestre> 5
      • con un <iv:TotaleOperazioniAttive>
      • con un <iv:TotaleOperazioniPassive>
      • un importo di <iv:IvaEsigibile>
      • un importo di <iv:IvaDetratta>
      • un importo di <iv:IvaDovuta>
      • l'<iv:Acconto>

A prescindere dallo specifico contenuto, si nota che la struttura non contiene dati di firma.

La prima fase operativa, una volta collegati al sito dell’Agenzia delle Entrate, area Fatture e Corrispettivi, alla funzione di comunicazione dei dati delle liquidazioni periodiche IVA, consiste nel controllo della validità formale di questo file.

Il caricamento del file XML e la sua validazione non fa altro che verificare la conformità del file stesso al namespace XML come sopra definito.

Se la prima fase si conclude senza errori, si può passare alla successiva. Si fa notare che fino a questo punto NON sono ancora state effettuate modifiche al file XML generato dall’utente.

Passiamo alla fase successiva.

Apposizione del sigillo

Per inviare il file l’Agenzia delle Entrate offre il servizio di sigillo elettronico. Il sigillo è una versione di firma elettronica avanzata, impropriamente si può ad esso pensare come ad una sorta di firma digitale delle persone giuridiche.

E’ interessante notare che in questo caso l’Agenzia utilizza il formato XAdES, ovvero la firma digitale nativa del formato XML. Dopo aver caricato il file (controllato, ma è sempre lo stesso file, in questa situazione) si chiede l’elaborazione del file sigillato.

L’elaborazione produce un file con estensione .XML (e non .p7m, come per altre applicazioni) il cui nome viene leggermente modificato, acquisendo un progressivo di elaborazione, ma viene mantenuta l’estensione .XML.

(ad esempio, il file di partenza non sigillato potrebbe essere nominato in questo modo: CODICEFISCALE_LI_20175.XML mentre il file sigillato potrebbe diventare CODICEFISCALE_LI_X0004.XML).

Il file “sigillato” si distingue per l’apposizione, per l’appunto, del sigillo digitale, che va a modificare la struttura di partenza del file XML.

Aprendo il file medesimo, si nota la firma, apposta subito dopo il tag di chiusura della direttiva comunicazione (</iv:Comunicazione>):

<ds:Signature Id="Signature1"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference Id="reference-document" URI="">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
<XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2" Filter="subtract">/descendant::ds:Signature</XPath>
</ds:Transform></ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>uWi6V69pU5cawlp9g0ZX593GXqrZ+F0MNtGCXaS7hXM=</ds:DigestValue>
</ds:Reference><ds:Reference Id="reference-signedpropeties" Type="http://uri.etsi.org/01903#SignedProperties" URI="#SignedProperties_1">
 <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><ds:DigestValue>xxxxxxxxxxxxx=</ds:DigestValue>
</ds:Reference><ds:Reference Id="reference-keyinfo" URI="#KeyInfoId">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
 <ds:DigestValue>xxxxxxxxxxxxxxxxxxxxxxxx=</ds:DigestValue>
</ds:Reference></ds:SignedInfo><ds:SignatureValue Id="SignatureValue1">xxxxxxxxxxxxxxxxxxxxxxxxxxx=
</ds:SignatureValue><ds:KeyInfo Id="KeyInfoId"><ds:X509Data><ds:X509Certificate>xxxxxxxxxxxxxxxxxxxxxxxxxxxxx=</ds:X509Certificate>
</ds:X509Data></ds:KeyInfo><ds:Object><xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#Signature1">
<xades:SignedProperties Id="SignedProperties_1"><xades:SignedSignatureProperties><xades:SigningTime>2018-02-25T10:13:04Z</xades:SigningTime></xades:SignedSignatureProperties>
</xades:SignedProperties>
</xades:QualifyingProperties>
</ds:Object>
</ds:Signature>

i dati di cifratura sono stati sotituiti con delle x, ma si nota il tax <xades:…> che suggerisce il metodo di firma.

Il file con sigillo digitale è pertanto un file firmato a tutti gli effetti, che mantiene l’estensione .XML in quanto firmato direttamente al suo interno.

Questo è ovviamente il file che va inviato all’Amministrazione.

Contabilità analitica, in breve

di cosa si parla?

In questo post vorrei scrivere brevi(ssime) note per rispondere alla domanda: “cos’è la contabilità analitica“?

Se dovessi rispondere “in 20 parole o meno” (cit.) direi che è lo strumento contabile analitico utilizzabile per conoscere tempestivamente gli elementi economici carratterizzanti i vari sottosistemi dell’impresa.

differenze con la contabilità generale

A differenza della contabilità generale (COGE), che si basa sulla rilevazione dei fatti esterni di gestione secondo una logica numeraria (manifestazione dell’aspetto finanziario, e rigorosamente consuntiva), la contabilità analitica (COAN) si basa su un concetto di competenza economica delle singole operazioni, e può contenere tanto dati consuntivi, quanto valori programmati (definita contabilità analitica a costi standard).

Per fare un semplice esempio della differenza tra una rilevazione numeraria ed una economica si può pensare al ricevimento delle materie prime: in COGE la rilevazione viene effettuata al ricevimento della fattura, in COAN invece nel momento in cui fisicamente le MP arrivano in azienda (su questo si può poi disquisire e scegliere diversamente, ma il concetto di fondo è quello esposto).

Altre caratteristiche

Una ulteriore differenza è che la COGE lavora con registrazioni per natura (si fa riferimento all’origine del costo, ad esempio “energia elettrica”) e considera l’impresa da un punto di vista unitario, come fosse una unica entità, mentre la COAN opera con registrazioni per destinazione (ovvero si fa riferimento al centro di analisi che produce o consuma un determinato costo) oltre che per natura (questo dipende dall’implementazione del sistema di COAN) e considera l’azienda in termini di sottosistemi di cui analizzare e monitorare le caratteristiche. I sottosistemi potrebbero essere reparti, lavorazioni, business unit, etc.

Ancora, lo scopo è differente, perché la COGE è focalizzata alla redazione del bilancio d’esercizio, redatto secondo criteri civilistici, ed il destinatario tipico è sia interno che esterno all’azienda, mentre la COAN viene predisposta per identificare i centri di costo, determinare i costi di prodotto, supportare la valutazione delle rimanenze e dei rendimenti di prodotto, determinare i costi di lavorazione, e così via, e il destinatario è esclusivamente interno all’impresa stessa.

Precisione contro tempestività

La contabilità generale privilegia la precisione delle rilevazioni, a scapito della tempestività delle informazioni (si pensi al fatto che il bilancio viene redatto dopo alcuni mesi dalla chiusura dell’esercizio), ed è obbligatoria per legge, mentre la contabilità analitica privilegia la tempestività delle informazioni, mediata ovviamente dall’assenza di errori significativi, e la sua tenuta è facoltativa.

Infine, la contabilità generale si riferisce normalmente all’intero esercizio, mentre l’analitica normalmente analizza periodi infrannuali, privilegiando ove possibile periodi mensili, proprio per la tempestività dell’informazione che risulta fondamentale per l’analisi degli scostamenti con i parametri obiettivo necessari alla realizzazione di un efficace controllo di gestione.

Caso pratico: consolidare dati delle retribuzioni con excel

In questo articolo riporto alcuni passaggi di una casistica relativa ad un’esigenza manifestata da un’azienda in crescita, che a seguito di nuove assunzioni si ritrova a dover ottimizzare le procedure per gestire i dati che arrivano da varie fonti.

Il problema

La crescita ha comportato una maggior necessità di forza lavoro. Oltre al personale dipendente, l’azienda fa ricorso ai servizi di alcune agenzie interinali.

Fino ad ora, le varie agenzie comunicavano i dati riepilogativi periodici del personale con vari format, tra loro diversi. L’azienda aveva necessità di consolidare i dati, ma l’attività era svolta manualmente, almeno nella prima fase di “riduzione” dei dati, ovvero dell’omogeneizzazione dei formati stessi.

Questo metodo richiede tempo, e si sa che:

  • tempo=costo
  • tempo=inefficienza

La nuova via…

L’idea è semplice quanto efficace: standardizzare il format di trasmissione del dato, mantenendolo semplice, ed utilizzarlo per alimentare in modo semi-automatico una struttura organizzata come base dati.

La scelta, per comodità e diffusione, è quella di utilizzare il foglio di calcolo excel (ma i concetti potrebbero ben essere applicabili anche a Calc della suite OpenOffice/LibreOffice, o ad altri spreadsheet) strutturando i dati in modo tabellare, prendendo a prestito dalla teoria della gestione dei DBMS le strutture di base, mantenute il più semplici possibile, ed utilizzando fogli di visualizzazione per il reporting e l’analisi dei dati.

In sostanza, si può riepilogare il lavoro di progettazione nella separazione in questi 3 elementi:

  • un modello excel che rappresenta il format standard per la raccolta dati, da compilare mensilmente a cura dell’agenzia interinale. Di tale modello esisteranno più fogli, ciascuno dei quali raccoglierà i dati di una certa agenzia di un determinato periodo;
  • un foglio excel, che rappresenta lo strumento di lavoro, composto da:
    • delle tabelle che fungono da base dati, nelle quali vengono raccolti i dati ed aggregati in forma omogenea. Queste tabelle sono le uniche che possono contenere dati soggetti a inserimento e/o manutenzione. Il caricamento e la manutenzione dei dati è stata automatizzata tramite delle macro (eventualmente oggetto di altri articoli, se d’interesse)
    • delle tabelle che fungono da strumento di reporting ed analisi, ovvero il reale strumento di consultazione.

Per rendere maggiormente efficace la struttura, si è proceduto a costruire le tabelle dati in modo normalizzato (anche se non del tutto), ovvero non ridondando i dati e tenendoli separati nelle varie tabelle, collegati tramite relazioni chiave primaria/esterna. Vista la semplicità della struttura, e l’esistenza di una chiave univoca “naturale”, ovvero il codice fiscale del soggetto, si è scelto di usare come chiave primaria delle tabelle proprio questo dato. Univoca la compilazione, univoca la relazione.

Per le nostre tabelle quindi la chiave primaria è il codice fiscale del prestatore di lavoro.

Il format per la raccolta dati è pertanto molto semplice, e segue la seguente struttura (gli esempi sono ridotti e semplificati):

Codice Fiscale Nome/Cognome Anno Mese Costo Ore
Primo soggetto
Secondo soggetto

In realtà in questa tabella la normalizzazione non è del tutto corretta, il campo nome/cognome è ridondante, ma è stato lasciato per semplificare la compilazione esterna. Non verrà tuttavia utilizzato se non per dei controlli.

Sono state inizialmente create due semplici tabelle dati:

Tabella dati anagrafici

Decodifica i dati anagrafici sulla base del codice fiscale. Segue la seguente logica:

Codice Fiscale Nome/Cognome Qualifica Centro di analisi
CF1 Primo soggetto
CF2 Secondo soggetto

La tabella (lo “sheet” in excel) viene chiamata “anagrafica

Tabella dati periodici

Raccoglie i dati veri e propri, suddivisi per soggetto, mese, anno. Segue la seguente logica:

Lotto Codice Fiscale Anno Mese Costo Ore

La tabella (lo “sheet” in excel) viene chiamata “dati

Si noti che le tabelle qui indicate sono “esemplificative del concetto”, nel caso reale la quantità di informazioni è maggiore, tuttavia la logica qui descritta è quella effettivamente funzionante.

Il campo “Lotto” è stato inserito in quanto ad ogni importazione dati viene attribuito un codice progressivo numerico sequenziale, che ha lo scopo di identificare le righe della tabella che sono state importate congiuntamente. Questo allo scopo di individuarle facilmente in caso di necessità (ad esempio, cancellazione dati errati o altro).

Il codice fiscale è la chiave di ricerca per i quadri riassuntivi per soggetto, le ulteriori chiavi di ricerca saranno l’anno e il mese. I dati riportati nei prospetti di reporting saranno invece “costo” ed “ore”, eventualmente aggregate nel modo desiderato.

Il reporting

Il cerchio si chiude nei fogli di reporting ed analisi, che vanno a recuperare i dati presenti nei fogli “dati” ed “anagrafica”, secondo varie necessità.

Si riportano, per esemplificazione, alcune formule “classiche” utilizzate nei fogli di reporting, che recuperano le informazioni dai fogli “database” in modo automatizzato.

Recuperare i dati anagrafici

Recuperare i dati anagrafici è banale, con una formula di LOOKUP, che in excel in versione italiana ha questa forma:

=CERCA.VERT(B909;anagrafica!$A:$E;3;FALSO)

Si ipotizza di essere in un foglio alla riga 909, e che nella colonna B del foglio sia presente il codice fiscale del soggetto da decodificare. La cella contenente il codice fiscale (nell’esempio la B909) può essere inserita a mano o collegata direttamente alla corrispondente cella dello sheet “anagrafica”.

Il primo parametro è quindi la chiave di ricerca: il contenuto della cella B909.

Il secondo parametro (i parametri sono separati tra loro da punto e virgola “;”) anagrafica!$A:$E indica che la corrispondenza verrà cercata nel foglio anagrafica (una delle tabelle base dati), nelle colonne da A ad E. Si noti che in questo caso si è scelto di non inserire i numeri di riga nella definizione del range di ricerca, in questo modo non si è vincolati alla quantità di dati presenti, ed i dati potranno essere aggiunti a discrezione senza modificare la formula.

Il terzo parametro, il valore “3”, significa che stiamo decodificando il valore trovato, nella riga con il codice fiscale della cella B909, che si trova nella terza colonna. Se si va a guardare la tabella anagrafica, si vedrà che si sta decodificando il valore della “qualifica”.

Il quarto ed ultimo parametro (FALSO), pur se opzionale, indica che la ricerca sia puntuale, ovvero che il valore della chiave deve corrispondere esattamente a quanto scritto. Questo offre la garanzia di avere trovato il soggetto specifico.

Recuperare i dati quantitativi

I dati più interessanti per le analisi sono quelli quantitativi, che possono essere decodificati con la formula sotto riportata. Si fa notare che tale formula aggrega eventuali dati “spalmati” su più righe, nel caso esistano, aggregando il dato mensile (per semplicità omettiamo nell’esempio la chiave “anno”).

Ad esempio, in una tabella che riporta i totali mensili, si può scrivere per ciascuna cella del mese la formula:

=SOMMA.PIÙ.SE(dati!$F:$F;dati!$B:$B;B909;dati!$E:$E;E910)

Questa funzione consente di sommare i dati che si trovano in più righe, per essere selezionate le righe devono corrispondere a tutti i criteri indicati (regola booleana AND).

Il primo parametro indica la zona in cui sono presenti i dati numerici da sommare, SOLO SE corrispondono ai criteri di ricerca indicati nei successivi parametri.

I successivi parametri vanno letti 2 a 2, il primo della coppia indica l’area dati contenente le chiavi di ricerca da confrontare, il secondo della coppia contiene il valore della chiave da verificare.

In questo modo, i due parametri successivi vanno così letti:

  • dati!$B:$B cerchiamo corrispondenza del valore indicato nel prossimo parametro nell’area dati del foglio chiamato “dati” (una delle “tabelle” del nostro database) che si trovano in colonna B. Notare l’uso del range assoluto senza righe ($B:$B) che consente di non limitare le righe cercate, e quindi essere indipendenti dalla quantità di dati caricati;
  • B909 è la cella che contiene il valore corrispondente (in questo caso al Codice Fiscale) delle righe da selezionare nella somma.

Allo stesso modo vanno letti i due successivi parametri, in pratica dopo aver selezionato le sole righe del Codice Fiscale di interesse, la formula opererà una successiva, ulteriore selezione (clausola AND) di quelle righe che avranno anche la seconda corrispondenza (che in questo caso è il mese di interesse, ma potrebbe essere un ulteriore qualsiasi criterio).

Gran finale…

La magia finale viene invero effettuata da una macro apposita, che grazie a codice VBA specifico si occupa di raccogliere i dati dai fogli compilati dalle varie agenzie e li consolida, unificandoli, nel foglio “dati” che consente alle formule sopra descritte di funzionare.

Va detto che da un punto di vista concettuale comunque la macro non sarebbe indispensabile, basterebbe fare un “copia & incolla” dei dati recuperati man mano nel foglio dati, e il sistema continuerebbe a funzionare. Certo, la macro quasi azzera i tempi e le possibilità di errori, qusti ultimi confinati alla qualità dei dati inseriti.

Ad ogni modo, lo scopo di questo articolo era quello di dare le indicazioni di massima della metodologia e della logica seguite per raggiungere il risultato desiderato.

A meno di un anno dalla fatturazione obbligatoria per tutti…

Manca “poco” ad un passaggio epocale: la fatturazione elettronica dventerà obbligatoria per tutti i soggetti.

Il D. Lgs 127/2015 già prevedeva la possibilità, per opzione, di adottare il regime di fatturazione elettronica.
Il 28 ottobre l’Agenzia delle Entrate pubblicava il Provvedimento direttoriale n. 182070/2016, nel quale venivano delineate le regole tecniche, i termini e le modalità opzionali per l’attuazione della fatturazione elettronica tra soggetti privati (cosidetto “B2B“) e la trasmissione telematica dei dati fattura, contestualmente alle quali sussistevano semplificazioni ed incentivi per quei soggetti che, in via facoltativa, avessero deciso di operare secondo quanto previsto richiamato decreto.

Ora la Legge 205/2017, commi 909 e da 915 a 917 prevede l’obbligo generalizzato di fatturazione elettronica, a partire dal 1/1/2019 (ed una sorta di “integrazione” dei dati mancanti, ovvero le operazioni transfrontaliere, con una versione specifica di comunicazione dati fatture. Questo in quanto l’obbgo generalizzato si applicherà a tutti, ma solo, i soggetti IVA Italiani).

Anticipato l’avvio, a partire dal 1/7/2018, per le prestazioni in subappalto della filera dei lavori pubblici e per le cessioni di benzina e gasolio, situazione questa che porta con se’ l’abolizione della scheda carburante, l’obbligo di tracciare il pagamento dei medesimi, e la trasmissione telematica dei corrispettivi per la cessione di benzina e gasolio.

Obbligo generalizzato dunque, ad esclusione dei soli contribuenti minimi  e forfetari, per tutte le fatture e le variazioni.

La modalità di invio sfrutterà il canale già in uso per le fatture nei confronti della Pubblica Amministrazione (già obbligatorio) noto come SdI (Sistema di Interscambio), ed anche il formato sarà quello già sperimentato nell’ambito della fatturazione P. A. basato su un dialetto XML.

Interessante la possibilità di individuare ulteriori formati file (con apposito D. M.) basati su standard o norme riconosciute in ambito UE.

Va osservato che questa possibiltà non può che tendere ad una probabile estensione, magari guidata da criteri di opportunità, convenienza ed economicità, nei confronti di un sistema esteso di fatturazione elettronica anche all’ambito transfrontaliero, pur se questo su probabile base volontaria.

Il Sistema di Interscambio attualmente opera inviando la fattura al destinatario sulla base di un codice univoco, ottenuto a seguito di procedura di registrazione. E’ pensabile sia plausibile che il codice univoco, per il settore “privato” (virgolettato in quanto in questo contesto privato è usato in accezione di contrapposizione a pubblico) possa essere affiancato da altri metodi per raggiungere il destinatario che possano essere già adottati e funzionanti, quali il sistema delle PEC.

“Ovviamente” la fatturazione elettronica porterà con se’ la concomitante abrogazione dello “spesometro” per quelle operazioni già tracciate da fattura.

Che dire? Sicuramente una rivoluzione estesa, che non mancherà di creare dubbi e difficoltà.

Indubbiamente però anche importante fonte strategica di miglioramenti ed opportunità, la filiera della fatturazione basata su standard riconosciuti potrebbe finalmente portare all’adozione di quei sistemi EDI che tanto hanno faticato a decollare in passato proprio a causa della difficoltà di adozone di standard riconosciuti.

Di certo la fattura elettronica consentirà una rapida ed agevole contabilizzazione dei dati, pertanto sempre più sarà opportuno, se non necessario, dotarsi di sistemi informativi adeguati ed adeguatamente impostati, così da poter trasformare il “nuovo” (virgolettato in quanto nuovo non è affatto, di nuovo c’è solo l’obbligatorietà generale) in opportunità.

Di sicuro la direzione è presa, e la volontà di andre in tale direzione è molto forte, come si evince dalle sanzioni in caso di inottemperanza nell’utilizzo del formato: il comma 909 riscrive l’art. 1 c. 6 D. Lgs 127/2015 prevedendo che la sanzione in caso di violazioni sull’obbligo di emissione della fattura in formato elettronico (per capirci: emissione cartacea) sia la medesima dell’omessa fatturazione! (ad oggi, dal 90% al 180% dell’IVA con un minimo di Eur. 500 per fattura).
Non solo, ma viene previsto l’obbligo del cessionario/committente di adempiere all’eventuale inottemperanza del fornitore, sempre tramite il Sistema di Interscambio, agli obblighi ex art. 6 c. 8 D. Lgs. 471/1997, a pena di sanzione pari al 100% dell’IVA, con minimo di Eur. 250 (in sostanza, disciplina dell’autofattura-denuncia).

Non c’è che dire, la direzione è tracciata.

Standard di firma digitale

La Decisione di esecuzione (UE) 2015/1506 della Commissione, dell’8 settembre 2015, stabilisce le specifiche relative ai formati delle firme elettroniche avanzate e dei sigilli avanzati che gli organismi del settore pubblico devono riconoscere.

Se ne può prendere visione qui.

In sintesi, vengono definiti i seguenti standard:

CAdES

L’acronimo significa “Cryptographic Message Syntax Advanced Electronic Signature“. Si tratta del formato attualmente più diffuso, conosciuto e familiare. Il documento in chiaro è contenuto nella busta crittografica e necessita di un software apposito per essere estratto e visualizzato.

Il documento firmato è riconoscibile dall’estensione «.p7m»

PAdES

Si tratta del sistema di firma per i file basati sul formato PDF, l’acronimo infatti significa “PDF Advanced Electronic Signature“. Il riferimento è lo standard ISO 32000-1.
E’ pertanto applicabile solo ai documenti in formato PDF. La firma stessa è “inglobata” nel file PDF ed è possibile determinare l’esatta posizione e sequenza della stessa nel documento.

L’estensione del documento firmato, in questo caso, resta “PDF”, come per il file non firmato.

XAdES

Si tratta del sistema di firma per i files basato sul formato XML, l’acronimo infatti significa “XML Advanced Electronic Signature“. La firma in questo caso segue le specifiche dello standard XML.
Si sta diffondendo sempre più, ad esempio è il sistema che è stato adottato per formare le notifiche/ricevute dal SdI (Sistema di Interscambio) nell’ambito della fatturazione elettronica alla Pubblica Amministrazione