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.

figura 1

 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.

flusso_messaggi flusso_messaggi

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 esempio del file XML da produrre lo potete vedere nella figura esempio sottostante.

esempio_xmlFatturaPA: com'è fatta

menu

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>

  1. <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:

 cedente

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.

intestazione_fattura

righe_fattura

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.

help_popup

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

ricerca_PA

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.

blocchi_xml

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

  1.  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.

  1.  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 🙂

[box type="note" align="aligncenter" width="702" ]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[/box]

14 Commenti

  1. Ciao Giuseppe,
    riguardo al punto: "5. Costruire un sistema modulare che consenta all'utente finale di aggiornare dinamicamente il proprio sistema"..
    I cambiamenti che verranno introdotti con la versione 1.1 sono svariati e, per quel poco che ne capisco, mi sembra che richiedano una certa competenza tecnica per essere integrati nel db. Quindi mi chiedevo, che tipo di procedura avete adottato per consentire agli utenti (di qualsiasi livello) di aggiornare dinamicamente il sistema e per gestire gli errori che possono scaturire da tale intervento?
    Grazie

  2. La necessità di aggiornamenti dinamici ha creato inizialmente un qualche grattacapo, risolto mettendo a punto la tecnica che si trova nel file di iFatturaPA, creando quindi la procedura che <> senza che sia l'utente a doversi far carico di una serie complessa di modifiche

    In breve (ma seguirà una descrizione più articolata con tanto di tip files):
    I codici da usare per le codifiche e *** la logica di controllo *** su presenza e congruità dei dati sono stati messi in altrettante tabelle
    L'aggiornamento viene generato "avvolgendo" in un guscio XML tutti i dati di queste tabelle, messi poi in un file
    L'utente scarica il file, e lancia la procedura che legge i dati del file ed esegue uno script che sostituisce i vecchi dati con i nuovi nelle tabelle oggetto di aggiornamento

    • molto interessante..
      Perdona la curiosità ma mi scappa un'altra domanda:
      non so se può accadere, ma mettiamo caso che un aggiornamento richieda l'introduzione di un nuovo campo obbligatorio, c'è un modo per intervenire dinamicamente anche in questo caso?

      Grazie per la disponibilità.
      Mikhail

  3. sono interessato all'applicativo su base filemaker per la fatturazione elettronica.

    Non ho ben compreso se tale applicativo consente la redazione dei campi finalizzati al successivo invio della fattura elettronica ed al controllo dell medesima (scadenze incluse).

    In altre parole, sempre se ho bene inteso, bast tentare in file Maker compilare i campi richiesti ed al resto procede l'applicazione.

    E' corretto?

    Con i migliori saluti

    M Sala

  4. Un saluto,

    complimenti per l'articolo. Avrei piacere, come indicato nell'articolo, di conoscere il seguito della "storia" con particolare riferimento alla gestione delle comunicazioni. Posso avere qualche almeno qualche spunto? Ringrazio e saluto cordialmente.

  5. Ciao Carlo

    La gestione delle comunicazioni con FileMaker è possibile, ma dopo un iniziale "entusiasmo" ci siamo accorti che stavamo re-inventando la ruota
    In sostanza si trattava di inviare il file XML firmato digitalmente tramite un account PEC, e fin qui roba da poco ...

    Poi si trattava di ricevere le comunicazioni di ritorno, e da esse estrapolare il tipo di msg di ritorno e l'elenco di eventuali errori connessi alla fattura inviata
    Per ricevere le email ci vuole un plugin tipo Mailit o POP3itPro, roba nota, ma da aggiungere al pacchetto in quanto sono funzioni che FM non possiede nativamente
    Poi bisognava lanciarsi in un ampio parsing del contenuto delle email ed eventualmente degli allegati delle email nei quali sono contenuti i dati di ritorno

    Devo dire che ho intrapreso questa strada, stimolato dalla complessità del meccanismo, ma quasi alla fine ho tirato un sospiro e mi son detto "ma siamo sicuri che stiamo creando qualcosa di utile o stiamo complicando cose meglio gestibili con altri mezzi?"

    La risposta è stata "la seconda che hai detto"
    🙂

    ciao

    g.

    PS: fammi comunque sapere se ti interessa / ti è utile gestire anche la parte delle comunicazioni ... Si tratta "solo" di ripescare tabelle e procedure che da qualche parte devo avere

  6. Buongiorno,

    mi permetto di disturbare in riferimento alla Vs. soluzione presente sul web iFatturaPA per la trasformazione delle fatture create in FileMaker in file xml.

    Premetto che non sono un programmatore ma da parecchi anni lavoro con FileMaker nella ns. azienda sviluppando di volta in volta tutto quello che serve.

    Già dal 2015 ho provveduto a creare file xml per la fatture dirette alla P.A. semplicemente creando un file di testo che va ad incastrare tutti i dati estrapolati da FileMaker ed inserendoli nelle righe di comando prescritte e alla fine il file viene salvato semplicemente con l'estensione .xml . Lavoro iniziale certosino, certo, ma poi ha sempre funzionato senza per questo utilizzare plugin di terze parti come indicate voi in quanto il file supera tutte le prove ed è nel formato UTF-8

    Lo stesso metodo lo uso anche per creare i file xml bonifici da inviare alle banche e anche qui non ho mai avuto problemi.

    Quindi mi chiedo se è veramente necessario questo plugin come indicate Voi o sono io che sbaglio creando un semplice file di testo salvato con l'estensione .xml

  7. L'importante è che il file XML sia in formato utf-8
    Come ci arrivi non conta
    Dato che FileMaker non supporta nativamente l'esportazione in utf-8 *** quando utilizza la funzione ESPORTA CONTENUTO CAMPO *** sono ricorso ad un plugin, BaseElements, gratuito, per ovviare al problema

  8. Ciao Giuseppe, sono interessato al tuo lavoro da poter integrare su alcuni applicativi che ho realizzato per alcuni clienti.
    Avrei solo un paio di domande se posso, dovrei togliermi alcuni dubbi prima di procedere....
    -Quando leggo che è possibile creare un file XML che contenga un "lotto" di fatture ti riferisci alle fatture emesse relative ad un lasso di tempo (es.: un file XML da generare per le fatture emesse nel mese di gennaio)?
    -Ho alcuni clienti che emettono tante fatture giornalmente... per ognuna di queste va generato un file XML ed ognuno firmato digitalmente? E' possibile creare i file XML già firmati?
    Ti ringrazio anticipatamente per l'attenzione.
    Alessandro

  9. Caro Giuseppe
    se sei il Pupita che ho conosciuto all'Umberto I mentre lavoravo alla Clinica Neuro credo di poterti dare del tu!
    Ti ritrovo qui esperto di File Maker (ed ora che ci penso anche allora lo eri?) proprio quando ho un problema con questo programma ed inoltre quando il commercialista mi parla di obbligo di fattura elettronica dal 1 gennaio 2019. Potremmo incontrarci su questi due temi? Il mio indirizzo è giulineu (Giuliani Neurologo) cui segue il gmail.com. Ho provato a scaricare il file con il video sulla fatturazione elettronica ma senza successo!

    • Ciao Giorgio,
      verifica all'interno della tua area riservata, dovresti avere il video della Fatturazione elettronica già abilitato. In caso così non fosse scrivici che verifichiamo. Controlla anche a cartella SPAM purtroppo spesso la mail di conferma finisce lì.

      Giuseppe Pupita ti risponderà al più presto riguardo eventuali dubbi e domande. Puoi scrivergli direttamente qui: https://www.filemakerguru.it/gurucorner/categories/ifatturapa/ il forum dedicato proprio a iFatturaPA e alla Fatturazione Elettronica.

LASCIA UN COMMENTO

Please enter your comment!
Please enter your name here