La Fatturazione elettronica verso la Pubblica Amministrazione

A partire da marzo 2015 la fatturazione verso gli enti pubblici diventa elettronica: nasce la FatturaPA. Vediamo insieme di che cosa si tratta.

La FatturaPA: cos'è

La FatturaPA è una fattura elettronica ai sensi dell'articolo 21, comma 1, del DPR 633/72 ed è la sola tipologia di fattura accettata dalle Amministrazioni le quali, secondo le disposizioni di legge, sono tenute ad avvalersi del  Sistema di Interscambio (SdI).

La FatturaPA ha le seguenti caratteristiche:

• il contenuto è rappresentato, in un file XML, secondo il formato della FatturaPA. Questo formato è l'unico accettato dal Sistema di Interscambio;
• l'autenticità dell'origine e l'integrità del contenuto sono garantite tramite l'apposizione della firma elettronica qualificata di chi emette la fattura;
• la trasmissione è vincolata alla presenza del codice identificativo univoco dell'ufficio destinatario della fattura riportato nell'Indice delle Pubbliche Amministrazioni.

Il Sistema di Interscambio, gestito dall'Agenzia delle Entrate, è un sistema informatico in grado di:

• ricevere le fatture sotto forma di file con le caratteristiche della FatturaPA;
• effettuare controlli sui file ricevuti;
• inoltrare le fatture alle Amministrazioni destinatarie.

Il Sistema di Interscambio non ha alcun ruolo amministrativo e non assolve compiti relativi all’archiviazione e conservazione delle fatture.

Il Sistema di Interscambio distingue tre tipi di file:

• file FatturaPA: file XML firmato digitalmente conforme alle specifiche del formato della FatturaPA. Può contenere una fattura singola o un lotto di fatture;
• file archivio: file compresso (esclusivamente nel formato zip) contenente uno o più file FatturaPA;
• file messaggio: file XML che contiene un messaggio.

Abbiamo quindi 4 entità che partecipano al processo:

• il Trasmittente: l'ente che trasmette la fattura (la ditta stessa, il commercialista, la software house che fornisce il servizio);
• il Cedente/Prestatore: chi emette fattura e deve essere pagato;
• il Sistema di interscambio: ente che riceve la fattura, ne verifica la congruità e la inoltra a chi la deve pagare;
• il Cessionario/Committente: il destinatario della fattura, chi alla fine deve pagarla

Nella figura 1 si ha una rappresentazione del flusso di fatturazione elettronica attraverso il Sistema di Interscambio.

 Il processo di generazione e trasmissione è riasumibile in breve come segue:

1.  si genera il file XML;
2.  il Cedente/Prestatore vi appone la sua firma digitale;
3.  il Tramittente invia il file firmato al SdI (pec, via web, canale FTP);
4.  il SdI riceve il file, lo verifica e lo inoltra al Cessionario/Committente.

La parte che ci interessa - ed anche quella più complessa - è la generazione del file XML che contiene le informazioni richieste, strutturato secondo precise specifiche.

Le specifiche sono consultabili presso il sito della Pubblica Amministrazione, ed un [download id="1897"] da produrre lo potete vedere nella figura esempio sottostante.

FatturaPA: com'è fatta

Entriamo quindi nel merito delle specifiche e vediamo che tipo di struttura dei dati ci viene richiesta.

La fattura è divisa in 2 parti, header e body, all'interno delle quali troviamo varie sezioni:

1. <FatturaElettronicaHeader>

1.1   <DatiTrasmissione>

1.2   <CedentePrestatore>

1.3   <RappresentanteFiscale>

1.4   <CessionarioCommittente>

1.5   <TerzoIntermediarioOSoggettoEmittente>

1.6   <SoggettoEmittente>

2. <FatturaElettronicaBody>

2.1   <DatiGenerali>

2.2   <DatiBeniServizi>

2.3   <DatiVeicoli>

2.4  <DatiPagamento>

2.5   <Allegati>

Ogni sezione a sua volta si articola ulteriormente, a seconda del tipo di dati che deve contenere. Vediamo per es. l'anagrafica del Cedente/Prestatore:

1.2.1<DatiAnagrafici>

1.2.1.1   <IdFiscaleIVA>

1.2.1.1.1   <IdPaese>

1.2.1.1.2   <IdCodice>

1.2.1.2 <CodiceFiscale>

1.2.1.3   <Anagrafica>

1.2.1.3.1   <Denominazione>

1.2.1.3.2   <Nome>

1.2.1.3.3   <Cognome>

1.2.1.3.4   <Titolo>

1.2.1.3.5   <CodEORI>

Come si può notare i dati sono organizzati nella classica gerarchia dell'XML, una sorta di cascata che contiene N ramificazioni in base al tipo di dati da trattare. Un altro aspetto molto importante riportato nei documenti sono le specifiche riguardo a che cosa debba contenere il campo, alla sua obbligatorietà o meno ed alla sua lunghezza. Prendiamo ad esempio il campo

1.2.1.1.2   <IdCodice> codice identificativo fiscale formato alfanumerico <1.1> 1 … 28

<IDCodice> è il tag da utilizzare nel file XML. (Nota bene: l'XML dei tag è case sensitive!)

Ad esso segue la spiegazione di cosa va messo nel campo. Il successivo <1.1> è un codice che indica che il campo è obbligatorio e che solo un valore è ammesso. Altre codifiche possono essere:

<0.1> Non obbligatorio, solo un valore è ammesso

<0.N> Non obbligatorio, ammessi più valori

<1.N> Obbligatorio, ammessi più valori

1…28 indica i limiti dimensionali del campo, che quindi in questo esempio può contenere da 1 a 28 caratteri

Per le date il documento utilizza il formato ISO 8601:2004, con la precisione seguente: YYYY-MM-DD. Per i campi data/ ora documento utilizza il formato YYYY-MM-DDTHH:MM:SS. In vari campi i valori ammessi sono riportati in tabelle allegate ai documenti (regime fiscale, modalità pagamento, etc.), in cui si esplicitano quali codifiche usare.

Come procedere quindi ? Quali requisiti dobbiamo considerare nel creare il nostro file di FileMaker ?

1. Riprodurre l'articolazione relazionale prevista dalle specifiche

Le specifiche prevedono l'inserimento di dati relativi al documento (tipo documento, causale, numero, etc.), e la possibilità di specificare N dati accessori (ordini d'acquisto, contratti, pagamenti). Dovremo quindi avere una tabella master e una tabella correlata per ognuna dei dati accessori

2. Eseguire una procedura di verifica di congruità dei dati

Come abbiamo visto, la congruità riguarda sia la presenza di dati obbligatori che il formato dei vari campi e la lunghezza del contenuto (questo vale anche per i campi non obbligatori).

3. Creare un file XML che contenga le sezioni obbligatorie e quelle opzionali che contengono dati, omettendo le sezioni prive di dati

Il sistema non ammette il passaggio dell'XML relativo ad una sezione opzionale se questa non contiene dati: ne consegue che l'intero blocco, inclusi i tag, va omesso dal documento.

4. Utilizzo del formato UTF-8

Il formato UTF-8 è l'unico accettato dal SdI.

5. Costruire un sistema modulare che consenta all'utente finale di aggiornare dinamicamente il proprio sistema

Questo è un punto critico, e particolarmente delicato.

E' prevedibile che le specifiche riguardo al contenuto ed al formato dei files XML vengano aggiornate col passare del tempo. In effetti, al momento della scrittura di questo articolo (ottobre 2014) la specifiche sono già state aggiornate e si prevede una ulteriore modifica a far data dal 2 Febbraio 2015

Ne consegue che dovremo creare un sistema che per eseguire le verifiche e produrre l'XML non utilizzi dati hard coded, ma che si serva invece di tabelle d'appoggio in cui caricare i dati da utilizzare, pena la non aggiornabilità del sistema.

Nasce quindi iFatturaPA: andiamo a conoscerlo nelle sue caratteristiche fondamentali.

iFatturaPA: struttura e funzioni

Dal punto di vista strutturale il sistema comprende le tabelle fondamentali per la raccolta dei dati necessari, quindi una tabella master Fatture e varie tabelle ad essa correlate per assecondare l'assetto relazionale previsto dalla PA.

Tutte le sezioni di data entry sono corredate di help contestuale che riproduce i suggerimenti della Pubblica Amministrazione al riguardo.

È stata inoltre aggiunta una tabella che continene tutti i codici degli enti della Pubblica Amministrazione che possono essere destinatari di una fattura.

La tabella compare come popup quando si cerca un codice. Con una ricerca drill down consente di identificare l'ufficio desiderato, il cui codice viene riportato nella fattura. Anche questa tabella è sottoposta ad aggiornamento.

La parte fondamentale del sistema è sotto al cofano: due tabelle - nascoste all'utente finale - contengono il dati con i quali il codice XML verrà generato. In sostanza queste tabelle contengono tutte le informazioni necessarie prima a validare i dati inseriti e poi alla generazione dell'XML richiesto.

Nella tabella Blocchi un campo testo contiene lo scheletro XML con al suo interno segnaposto per campi e per eventuali sottoblocchi. Nella stessa tabella altri campi di FileMaker indicano le condizioni in base alle quali il blocco XML va incluso o meno nel documento e se il blocco può essere ripetuto N volte. Ogni blocco può avere N componenti e N sottoblocchi correlati.

Nella tabella Componenti abbiamo un record per ogni campo da scrivere nel blocco: per ogni record vengono immesse l'obbligatorietà, la lunghezza massima e minima del campo, il tag XML da utilizzare, il campo di FileMaker cui fare riferimento ed il tipo di campo, così da poter eventualmente utilizzare una CF per trasformare il dato immesso nel formato richiesto, come accade per i campi di tipo data.

I sottoblocchi non sono altro che record della tabella Blocchi correlati ad un blocco "padre".

Vediamo un esempio. Questo è il blocco Dati Trasmissione.

<DatiTrasmissione>

<IdTrasmittente>

[1]

[2]

</IdTrasmittente>

[3]

<FormatoTrasmissione>SDI10</FormatoTrasmissione>

[4]

{recapiti_trasmittente}

</DatiTrasmissione>

I numeri nelle parentesi quadre fungono da segnaposto e fanno riferimento a records della tabella Componenti identificati dallo stesso numero: in questo modo è possibile ricavare cosa scrivere nel segnaposto: in questo esempio al segnaposto [1] corrisponde un record che contiene il tag <IdPaese> e prende il suo valore dal campo Trasmittenti::TRM_id_paese. Il segnaposto in parentesi graffa {recapiti_trasmittente} fa invece riferimento al sottoblocco Contatti Trasmittente.

<ContattiTrasmittente>

[1]

[2]

</ContattiTrasmittente>

che a sua volta utilizza 2 segnaposto per ricavare tag XML e valori da scrivere

Il risultato finale - una volta sostituiti i segnaposto con i rispettivi valori - è una cosa del genere:

<DatiTrasmissione>

<IdTrasmittente>

<IdPaese>IT</IdPaese>

<IdCodice>01936550993</IdCodice>

</IdTrasmittente>

<ProgressivoInvio>2014/11</ProgressivoInvio>

<FormatoTrasmissione>SDI10</FormatoTrasmissione>

<CodiceDestinatario>UFC0OK</CodiceDestinatario>

<ContattiTrasmittente>

<Telefono>0721865429</Telefono>

<Email>gpupita@sestante.net</Email>

</ContattiTrasmittente>

</DatiTrasmissione>

Con questa separazione tra interfaccia, dati e logica possiamo gestire agevolmente tutte le problematiche relative all'aggiornamento. Quando la Pubblica Amministrazione rilascia una nuova versione non dovremo andare a modificare validazioni di campo o modificare la logica di qualche script ma ci sarà sufficiente caricare i records aggiornati delle tabelle Blocchi e Componenti di cui sopra per avere le nuove specifiche pronte all'uso. Questo naturalmente diventa una cosa insostituibile quando si abbiano già copie installate dell'applicativo, essendo improponibile modificarle una per una.

Vediamo ora come funziona il sistema nella pratica.

iFatturaPA in azione

La procedura di elaborazione della fattura inizia con alcune verifiche di base: presenza del trasmittente e del cedente/prestatore, e passa poi a verificare la presenza del plugin Base Elements.

Il plugin - gratuitamente scaricabile da http://www.goya.com.au/baseelements/plugin - serve a sopperire alla incapacità di FileMaker di esportare in formato UTF-8 (ovviamente anche altri plugins vanno bene, purchè esportino in formato UTF-8)."

Lo step successivo è verificare la congruità dei dati (presenza e lunghezza del dato) nei campi obbligatori: qua si inizia ad utilizzare la modularità del sistema, per cui invece di invocare validazioni a livello di campo o una lunga serie di If (EVuoto) si va alla tabella Componenti, si ricercano quali campi siano marcati come obbligatori, e poi si esegue un Loop che, utilizzando la funzione GetField () ci dice se il campo ha un valore e quanto è lungo.

Una cosa analoga viene successivamente eseguita per i campi non obbligatori, in cui la verifica riguarda solo la congruità sui parametri di lunghezza del campo

Si esegue infine una terza procedura di verifica su alcuni criteri condizionali: in vari casi il sistema prevede che se un dato è presente ne siano presenti anche altri, che cioè l'informazione sia completa, mentre in altri casi si controlla che non siano state inserire troppe informazioni (come ad esempio nel caso in cui l'utente inserisca SIA il nome della ditta che della persona fisica).

Anche questa procedura è stata realizzata in maniera del tutto modulare evitando quindi qualsiasi forma di codifica rigida (impiegando cioè campi o script), ma utilizzando invece una tabella d'appoggio contenente le verifiche da fare.

Si crea quindi una tabella Controlli, un record per ogni controllo che vogliamo eseguire, e si scrivono in ciascun record le formule da impiegare per eseguire la verifica ed il messaggio da mostrare in caso di verifica NON superata. Detta così sembra una cosa semplice, ma in effetti l'operazione è più "articolata", in quanto le verifiche possono riguardare:

1. presenza/assenza di dati in più campi.

Questa è facile: si mette in un campo una formula del tipo

EVuoto (tabella::campo) and EVuoto (altratabella::campo)

e nello script di verifica lo statement

If (Valuta (testo della formula) = 1)

ci dirà se la condizione è valida

2.  Presenza/assenza di dati in più campi se un altro campo è valorizzato.

Questa è meno semplice ma fattibile: si utilizzano due campi, realizzando quindi una gerarchia tra le 2 formule.

La funzione Valuta () viene quindi applicata prima al campo chiave e poi all'altro:

If (Valuta (testo della seconda formula) = 1)

If (Valuta (testo della prima formula) = 1)

ci dirà se la condizione è valida.

3.  Presenza/assenza di dati in campi di una tabella correlata.

Qui la cosa si fa complicata, anche perchè possiamo dinamicamente capire se una tabella correlata contiene valori MA non possiamo selezionare dinamicamente gli N record correlati su cui eseguire i controlli, visto che lo step Vai al record correlato non consente tale dinamicità.

Riusciamo però a cavarcela con 2 campi della tabella Controlli, in cui scriviamo il layout in cui eseguire la ricerca nella tabella correlata ed il campo su cui eseguire la ricerca. Una volta trovati i record correlati lo script è analogo a quello del punto 2. Lo script diventa quindi del tipo:

Vai al formato ($layout)

Passa al modo Trova

Definisci il campo con nome ($nomecamporicerca)

Esegui la ricerca

Loop

If (Valuta (testo della seconda formula) = 1)

If (Valuta (testo della prima formula) = 1)

Imposta variabile ($testo_errore ; $messaggio)

Dopo la fase della verifica, fondamentale in quanto un singolo errore comporterà il rifiuto della fattura da parte del SdI, si procede a macinare il codice.

Nota bene: per controllare i documenti XML la Pubblica Amministrazione ha messo a disposizione una pagina in cui è possibile mandare i nostri files di prova al SdI ed avere un controlo di congruità del documento.

Anche in questo caso la cosa avviene in maniera modulare, utilizzando i dati presenti nella tabella Blocchi. Caricando in sequenza i records della tabella Blocchi si scrive in una variabile il codice XML del blocco, dopo aver provveduto a sostituire i segnaposto con i dati provenienti dalle varie tabelle. Come visto in precedenza sia i tag XML da usare che il campo da cui prendere i dati sono scritti in campi della tabella Componenti, e quindi manteniamo a pieno la dinamicità del sistema.

In questa fase la procedura assume un certo grado di complessità perchè deve anche elaborare il codice relativo ai sottoblocchi, con l'aggravante che in alcuni casi i sottoblocchi possono essere multipli. Superate queste asperità la strada diventa in discesa: tutto il testo scritto nella variabile, utilizzando la funzione WriteToFile () di ScriptMaster, per essere scritto in un file, il cui nome viene calcolato come da istruzione del SdI.

Nome del file = codice paese trasmittente & codice IVA trasmittente  & "_" & progressivo invio & ".xml"

Il file viene generato sul desktop ed anche inserito in un campo contenitore in apposita tabella, la quale contiene anche un secondo campo contenitore per il successivo inserimento della versione del file firmata digitalmente. Quest'ultima versione è finalmente matura per essere inviata al SdI, cosa di cui si occupa il sistema, utilizzando le funzioni di invio mail native di FileMaker utilizzando le impostazioni immesse dall'utente.

Da qui in poi inizia il dialogo col SdI, che provvederà a tenerci aggiornati sul destino della fattura inviata. I messaggi possono essere una notifica di scarto, un file dei metadati, una ricevuta di consegna, una notifica di mancata consegna, una notifica di esito committente, una notifica di esito, uno scarto esito committente, una notifica di decorrenza termini, una attestazione di avvenuta trasmissione della fattura con impossibilità di recapito.

Come pensate che gestiremo queste comunicazioni?

Secondo me utilizzeremo FileMaker… Ma questa è un'altra storia 🙂

Clicca qui per scoprire iFatturaPA, di FileMaker Guru in collaborazione con Giuseppe Pupita, il gestionale sviluppato appositamente per la Fatturazione elettronica verso la Pubblica Amministrazione.