Informazioni sul documento

Progetto

eDoc API

ID documento

UM 20150928 Manuale utente eDoc API

Tipo

Manuale utente

Data creazione

28/09/2015

Ultima revisione

11/12/2018

Versione

1.13.1

Autore

Stefano Travelli

Stato

Rilasciato

Classificazione

Confidenziale

Riproduzioni cartacee di questo documento sono da considerarsi copie di lavoro non censite dal SIG.

Revisioni

Data Versione Nome Azione

28/09/2015

0.0.1

Stefano Travelli

Creazione del documento.

15/10/2015

0.0.2

Stefano Travelli

Adeguamento del formato.

23/05/2016

1.0.16

Stefano Travelli

Documentazione API Archiviazione.

02/02/2017

1.6.7

Stefano Travelli

Aggiornamento per fattura B2B.

15/05/2017

1.7.2

Stefano Travelli

Aggiornamento per caricamento PDV.

27/06/2017

1.8.0

Alessia Soccio

Descrizione esempi PDV.

26/07/2017

1.9.0

Stefano Travelli

Aggiunte tabelle dei codici.

09/02/2018

1.10.0

Alessia Soccio

Revisione, aggiunta esempi PDV.

05/03/2018

1.10.1

Stefano Travelli

Aggiunti dettagli sul processo di gestione delle fatture.

05/03/2018

1.10.2

Alessia Soccio

Correzioni minori su esempi PDV.

19/04/2018

1.11.9

Alessia Soccio

Modifica esempio PDV "D85, Altri documenti", inserimento definizione di pacchetto F997.

06/06/2018

1.11.10

Stefano Travelli

Aggiunti alcuni esempi e chiarimenti sull’autenticazione.

26/11/2018

1.13.0

Luigi Ruocco

Documentazione codici.

11/12/2018

1.13.1

Alessia Soccio

Aggiustamenti su esempi PDV.


Approvazione del documento

Data Addetto Mansione Firma

11/12/2018

Stefano Travelli

DT


© 2018 Entaksi Solutions

Le informazioni contenute nel presente documento sono di proprietà di Entaksi Solutions, sono fornite ai destinatari in via riservata e confidenziale e non possono essere usate per fini produttivi, né comunicate a terzi o riprodotte, per intero o in parte, senza il consenso scritto di Entaksi Solutions.

1. Introduzione

eDoc API è una collezione di API REST che consente di accedere ai servizi del sistema di archiviazione elettronica Entaksi integrato con la gestione della fattura elettronica.

Le API contengono di operare su tutte le funzionalità per la trasmissione e la ricezione delle Fattura Elettronica, sia nella versione per la Pubblica Amministrazione (Fattura PA) che in quella per privati (Fattura B2B) e sulle funzionalità del sistema di conservazione, dal caricamento dei Pacchetti di Versamento, l’accesso e la ricerca nell’archivio dei documenti conservati e la produzione di Pacchetti di Distribuzione.

Il sistema di archiviazione Entaksi è accreditato presso l’Agenzia per l’Italia Digitale e rispetta quindi i requisiti per essere utilizzato dagli enti pubblici italiani, oltre che offrire lo stesso livello di garanzia a quelli privati.

La gestione delle fatture elettroniche comprende l’interfaccia con un canale di trasmissione e ricezione accreditato presso il Sistema di Interscambio, sistema con il quale le fatture possono essere inviate indirizzandole ad enti della Pubblica Amministrazione (tramite il codice destinatario pubblicato nell’Indice PA) oppure a privati (tramite codice destinatario, per i privati che ne dispongono, oppure tramite PEC).

Mediante il canale di ricezione, anch’essso accreditato presso il Sistema di Interscambio le aziende o gli enti della Pubblica Amministrazione possono ricevere le fatture elettroniche.

Per le aziende private registrate Entaksi assegna un codice destinatario allo scopo di ricevere le fatture elettronche tramite il sistema anziché tramite PEC. In questo modo è anche possibile, per un’applicazione gestionale opportunamente predisposta, scaricare le fatture ricevute e inserirle automaticamente nella contabilità senza interagire con il protocollo di trasferimento definito dal Sistema di Interscambio, ma utilizzando le API REST e i meccanismi di interazione definiti da eDoc API.

Nella parte relativa all’archiviazione elettronica, le API consentono all’utente di eseguire le tre operazioni principali connesse al processo di conservazione in base alla normativa e allo standard OAIS:

  • Trasmettere Pacchetti di Versamento contenenti documenti da mettere in archiviazione;

  • Ricercare i documenti archiviati nei Pacchetti di Archiviazione generati a fronte del versamento;

  • Ottenere una copia dei documenti archiviati mediante la formazione di un Pacchetto di Distribuzione.

Le API utilizzano uno schema di autenticazione basato sul protocollo OAuth2 per identificare l’utente.

Le possibilità operative dell’utente dipendono poi dalle autorizzazioni derivanti dalle entità gestite dal sistema a cui viene associato.

Queste entità sono:

  • il Produttore dei documenti, ovvero l’azienda o l’ente pubblico che utilizza il sistema;

  • il Contratto di servizio, ovvero l’entità che definisce quali servizi possono essere utilizzati nel sistema;

  • il Rivenditore, ovvero l’entità che, previo un accordo di rivendita con Entaksi Solutions, attiva contratti di erogazione dei servizi con i propri clienti.

Questo documento descrive il modello del servizio implementato dal sistema e illustra le modalità d’uso delle API per attivare, accedere e controllare i vari servizi e funzionalità del sistema.

Alcuni concetti relativi all’archiviazione a norma dei documenti sono descritti in maggiore dettaglio nel Manuale del sistema di archiviazione MAN eCON 20151222 Conservazione.

2. Autenticazione delle chiamate alle API

La procedura di autenticazione delle chiamate alle API eDoc segue il flusso descritto nel paragrafo 4.3 della specifica RFC6749 The OAuth 2.0 Authorization Framework:

  • Mediante un client accreditato nel sistema, l’utente fornisce le sue credenziali

  • Il client richiede un Access Token al server di autenticazione utilizzando il Token Endpoint trasmettendo le credenziali fornite dall’utente

  • Il server verifica le credenziali e restituisce l’Access Token

In particolare il flusso di autenticazione segue le specifiche definite in OpenID Connect Core 1.0 che è un protocollo aperto e diffuso, utilizzato tra l’altro da vari fornitori di API REST accessibili tramite Internet come Google, Facebook, Microsoft, ecc.

In questo schema il client che accede al servizio, sia esso un’applicazione o una pagina web, è identificato da un codice client_id e deve essere preventivamente censito nel sistema di autenticazione per poter utilizzare il protocollo.

I client si distinguono in pubblici e privati. I client pubblici (ad esempio le applicazioni web che girano sul browser mediante framwork Javascript come AngularJS, React, ecc) possono ottenere un token per l’accesso alle API esclusivamente attraverso il flusso standard di autenticazione OpenID Connect.

In questa modalità l’utente finale esegue l’autenticazione inserendo le credenziali in una pagina di login fornita dal sistema di autenticazione Entaksi e viene poi reindirizzato verso l’applicazione web. Durante il reindirizzamento il sistema di autenticazione fornisce il codice di autenticazione che l’applicazione gestirà per fornire le credenziali necessarie alle invocazioni delle API.

I clienti privati sono protetti da una password e i valori client_id/password costituiscono le credenziali con le quali l’applicazione può richiedere un token di accesso, sia utilizzando il meccanismo del reindirizzamento all’URL dell’applicazione, sia invocando direttamente un API del sistema di autenticazione, ovvero senza presentare all’utente finale la pagina web di login.

Questa modalità di autenticazione è definita come flusso implicito di autenticazione OpenID Connect.

I client privati sono quindi adatti all’autenticazione delle applicazioni standalone e dei software di integrazione che interagiscono con il sistema di archiviazione.

2.1. Esempio di autenticazione con flusso implicito e accesso diretto

L’autenticazione senza meccanismo di redirezione consiste nel chiamare direttamente il Token Endpoint per ottenere il token di accesso alle API.

L’URL da utilizzare per richiede il token è il seguente: https://entaksi.eu/auth/realms/edoc/protocol/openid-connect/token

Fino alla versione 1.0 delle API l’indirizzo per richiedere il token era https://entaksi.eu/auth/realms/edoc/protocol/openid-connect/grants/access.

Questo indirizzo rimane funzionante per compatibilità, tuttavia è consigliabile passare al nuovo indirizzo appena possibile.

La richiesta deve essere di tipo HTTP POST e contenere i seguenti parametri:

  • grant_type: il valore password

  • username: il nome utente (corrisponde all’email di registrazione)

  • password: la password dell’utente

  • totp: il valore generato dal dispositivo OTP, se abilitato sull’utente (opzionale, va incluso solo se l’utente ha abilitato l’autenticazione a due fattori)

La richiesta deve avere l’header per l’autenticazione HTTP Basic utilizzando il client_id come utente e la password assegnato al client:

POST /auth/realms/edoc/protocol/openid-connect/token
Authorization: Basic abcdefghilmnopqrstuvz
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=mario&password=XJp45pzH

In caso di successo la risposta ha una forma di questo tipo:

{
  "access_token": "eyJhbGciOiJSUzI1NiJ9.eyJqdG....",
  "expires_in": 1800,
  "refresh_expires_in": 3600,
  "refresh_token": "eyJhbGciOiJSUzI1NiJ9.eyJqdGk....",
  "token_type": "bearer",
  "id_token": "eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJmM.....",
  "not-before-policy": 0,
  "session_state": "1234fc49-ac72-4c09-a563-12340573004d"
}

Il valore della proprietà access_token va poi utilizzato per chiamare le API in un header Authorization:, ad esempio:

GET /api/edoc/v1/aziende
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA

Il valore expires_in indica il numero di secondi di validità dell’Access Token. Questo valore è abbastanza breve (decine di minuti) e prima che l’Access Token scada è necessario rinnovarlo.

Per consentire al software di continuare ad accedere alle API dopo la scadenza del token è necessario inserire un controllo prima di ogni chiamata che applichi la seguente logica:

  • se l’Access Token scade nei prossimi 5 secondi, prima di fare la chiamata eseguire il rinnovo del token,

  • altrimenti eseguire subito la chiamata.

Se l’Access Token è scaduto è ancora possibile fare il rinnovo entro il tempo definito in refresh_expires_in che di solito è considerevolmente più lungo. Se anche questo tempo è passato, allora la sessione è scaduta e occorre ripetere la richiesta di Access Token, ossia ripetere il login.

Il rinnovo dell’Access Token avviene tramite una chiamata POST all’URL: https://entaksi.eu/auth/realms/edoc/protocol/openid-connect/token

Fino alla versione 1.0 delle API l’indirizzo per rinnovare il token era https://entaksi.eu/auth/realms/edoc/protocol/openid-connect/refresh.

Questo indirizzo rimane funzionante per compatibilità, tuttavia è consigliabile passare al nuovo indirizzo appena possibile.

Anche questa chiamata deve usare l’autenticazione Basic con il client_id e la password assegnata al client, esattamente come la richiesta di Access Token. Nei parametri va indicato il valore del Refresh Token.

POST /auth/realms/edoc/protocol/openid-connect/token
Authorization: Basic abcdefghilmnopqrstuvz
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA&

La risposta ha la stessa struttura della richiesta di Access Token e da essa si ricavano i nuovi valori di Access Token e Refresh Token che sostituiscono i precedenti.

Il seguente codice bash riassume l’operazione di login e una chiamata alle API utilizzando il comando curl:

#!/bin/bash

TOKEN_SERVICE_DIRECT_GRANT_PATH="https://entaksi.eu/auth/realms/edoc/protocol/openid-connect/token"
TOKEN_SERVICE_REFRESH_PATH="https://entaksi.eu/auth/realms/edoc/protocol/openid-connect/refresh"

CLIENT_ID=<client id fornito>
CLIENT_SECRET=<password del client fornito>

USERNAME=<nome utente (corrisponde alla mail di registrazione)>
PASSWORD=<password dell'utente>
OTP=<codice OTP generato mediante un'applicazione compatibile TOTP> (opzionale)

# questa chiamata richiede un AccessToken per l'utente. Va fatta con autenticazione Basic
# usando come nome utente CLIENT_ID e come password CLIENT_SECRET
ACCESS_TOKEN_RESPONSE=$(curl --user $CLIENT_ID:$CLIENT_SECRET -X POST $TOKEN_SERVICE_DIRECT_GRANT_PATH \
         -H "Content-Type: application/x-www-form-urlencoded"  \
         -d grant_type=password \
         -d totp=$OTP \
         -d username=$USERNAME  \
         -d password=$PASSWORD )

# La risposta è un documento JSON dal quale possono essere estratti i vari valori tra i quali l'AccessToken
echo Response: $ACCESS_TOKEN_RESPONSE

# l'opzione -r evita che il valore sia racchiuso tra virgolette
ACCESS_TOKEN=$(echo $ACCESS_TOKEN_RESPONSE | jq -r .access_token)
EXPIRES_IN=$(echo $ACCESS_TOKEN_RESPONSE | jq -r .expires_in)
REFRESH_EXPIRES_IN=$(echo $ACCESS_TOKEN_RESPONSE | jq -r .refresh_expires_in)
REFRESH_TOKEN=$(echo $ACCESS_TOKEN_RESPONSE | jq -r .refresh_token)
TOKEN_TYPE=$(echo $ACCESS_TOKEN_RESPONSE | jq -r .token_type)
ID_TOKEN=$(echo $ACCESS_TOKEN_RESPONSE | jq -r .id_token)


echo Access token: $ACCESS_TOKEN
echo Expires in: $EXPIRES_IN
echo Refresh expires in: $REFRESH_EXPIRES_IN
echo Refresh token: $REFRESH_TOKEN
echo Token type: $TOKEN_TYPE
echo ID token: $ID_TOKEN

# esempio di chiamata alle API con il token recuperato dalla procedura di login. Elenco delle aziende:
curl -X GET https://test.entaksi.eu/api/edoc/v1/aziende \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer $ACCESS_TOKEN"

2.2. Documentazione delle API e ambiente di interazione on line

Le API REST del sistema sono documentate secondo lo standard OpenAPI (versione 2, nota anche come Swagger) che consiste in un file JSON contenente tutte le informazioni che descrivono le modalità di invocazione delle varie risorse.

La documentazione è sempre disponibile all’indirizzo https://entaksi.eu/api/edoc/v1/swagger.json. Esistono diversi strumenti di sviluppo che, a partire da queste informazioni, possono generare automaticamente i componenti client in vari ambienti di sviluppo, tra i quali Java, .NET, PHP, Ruby, ecc.

Un ambiente di interazione con le API è disponibile all’indirizzo https://entaksi.eu/api/edoc/v1-doc/ dove ciascuna risorsa è descritta in dettaglio ed è anche possibile invocare i servizi componendo manualmente i parametri necessari.

2.3. Ambiente di test

Per gli sviluppatori che intendono provare l’integrazione dei loro prodotti con i servizi eDoc API è disponibile un ambiente di test del tutto equivalente a quello di produzione e che risponde agli stessi indirizzi utilizzando test.entaksi.eu al posto di entaksi.eu.

Tabella 1. Ambienti di test e produzione
Servizio Test Produzione

Documentazione OpenAPI

https://test.entaksi.eu/api/edoc/v1/swagger.json

https://entaksi.eu/api/edoc/v1/swagger.json

Ambiente di interazione con le API

https://test.entaksi.eu/api/edoc/v1-doc/

https://entaksi.eu/api/edoc/v1-doc/

Console di gestione del servizio

https://test.entaksi.eu/a/

https://entaksi.eu/a/

L’accesso alla console di gestione di produzione avviene anche tramite il link http://console.entaksi.eu
L’ambiente di test e quello di produzione utilizano lo stesso sistema di autenticazione, perciò i link che iniziano con https://entaksi.eu/auth rimangono con l’host entaksi.eu anche durante l’accesso all’ambiente di test.

3. Modello generale del sistema

Il modello del servizio è organizzato nelle seguenti entità anagrafiche:

  • L'Utente: è l’utente che accede al servizio identificato dalle credenziali di accesso.

  • L'Azienda: è la persona fisica o giuridica che ha stipulato un contratto per l’accesso ai servizi del sistema. L'Azienda è associata ad uno o più utenti. Dal punto di vista archivistico l’azienda corrisponde al produttore dei ducumenti. Ogni Azienda è collegata a un Contratto che definisce i termini di accesso al servizio nell’ambito del periodo di validità.

  • Il Contratto: è l’entità che definisce i termini di accesso al servizio e comprende una o più aziende che condividono l’accesso al sistema. Il contratto ha uno o più utenti i quali supervisionano le aziende gestite dal contratto. Il contratto definisce gli intervalli di validità dei servizi erogati.

  • Il Rivenditore: è l’entità che stipula i contratti di accesso al servizio. Ha uno o più contratti e uno o più utenti.

Nella parte del sistema che si occupa della gestione della fattura elettronica sono previste le seguenti entità:

  • La Fattura: è l’entità che rappresenta la Fattura XML, trasmessa o ricevuta, ed è collegata ad una Azienda.

  • La Ricevuta: ogni fattura ha una o più ricevute che corrispondono ai messaggi ricevuti dal Sistema di Interscambio nell’ambito del ciclo di gestione della fattura.

Nella parte del sistema che si occupa dell’archiviazione elettronica si trovano le seguenti entità:

  • Il Pacchetto di versamento (PDV): rappresenta il contenitore con cui i documenti vengono versati nel sistema di archiviazione. Il PDV è definito formalmente nel Manuale della conservazione.

  • Il Rapporto di versamento (RDV): è il documento digitale in formato XML con cui il sistema di archiviazione attesta l’avvenuto versamento di un PDV.

  • Il Pacchetto di archiviazione (PDA): è il contenitore in cui i documenti vengono archiviati nel sistema per la conservazione a lungo termine.

  • L'Indice di conservazione (IdPda): è l’indice che, mediante firma digitale e marca temporale, rappresenta la prova di conservazione dei documenti contenuti nel PDA.

  • Il Pacchetto di distribuzione (PDD): è il contenitore in cui i documenti vengono raggruppati per essere distribuiti in seguito ad una richiesta di distribuzione. Insieme ai documenti sono distribuite anche le prove di conservazione con cui essi sono stati archiviati in modo dare piena validità fiscale e civile ai documenti recuperati dall’archivio.

Poiché la gestione della fattura elettronica è integrata nel sistema, al termine della fase di gestione le fatture formano automaticamente dei pacchetti di versamento tramite i quali ha luogo il processo di conservazione.

Per gli altri documenti e per le fatture elettroniche gestite al di fuori del sistema eDoc il caricamento nel sistema di conservazione avviene sempre Pacchetti di Versamento formati esternamente al sistema.

4. Attivazione di una azienda

L’utente che ha le credenziali associate ad un rivenditore può, tramite l’invocazione delle API oppure tramite la console di gestione del servizio, definire un’azienda e attivare i servizi che consentono di operare sul sistema.

Tuttavia normalmente risulta più pratico utilizzare un flusso operativo che consenta all’utente finale di registrare autonomamente le proprie credenziali e la propria azienda mediante un prodotto software gestito dal rivenditore e quindi ad esso riconducibile.

eDoc API implementa questa modalità di attivazione del servizio mediante l’uso del client_id utilizzato durante la chiamata alle API REST. Associando il client_id ad un rivenditore risulta possibile per il sistema riconoscere il software e associare quindi l’azienda a quel rivenditore.

Lo scenario si può riassumere nei seguenti passaggi:

  • Il rivenditore X dispone di un client del servizio eDoc API (ad esempio un’applicazione desktop o un servizio web per la gestione dei documenti). A questo client è associato un determinato client_id e (eventualmente) una password.

  • Il cliente finale registra le proprie credenziali sul sistema di autenticazione collegandosi all’indirizzo https://console.entaksi.eu/

  • Il cliente finale utilizza le credenziali con l’applicazione fornita dal rivenditore. L’applicazione, utilizzando l’API POST /aziende definisce una nuova azienda.

Tramite il valore client_id il sistema riconosce l’applicazione e associa l’azienda a quel Rivenditore tramite un Contratto creato al momento per quella azienda oppure associando l’azienda ad un contratto esistente, in base alla configurazione impostata dal rivenditore.

4.1. Associazione di un client_id al rivenditore

Il codice client_id generato da un amministratore del sistema può essere associato ad un rivenditore tramite le seguenti API:

  • GET /rivenditori/{idRivenditore}/clients: recupera l’elenco dei client_id associati al rivenditore.

  • PUT /rivenditori/{idRivenditore}/clients/{client_id}: associa il client_id al rivenditore.

  • DELETE /rivenditori/{idRivenditore}/clients/{client_id}: rimuove l’associazione del client_id al rivenditore.

5. Gestione delle fatture XML

eDoc API gestisce il ciclo completo della Fattura XML per la Pubblica Amministrazione (Fattura PA) e per i privati (Fattura B2B), in particolare:

  • Accetta il caricamento di una fattura ed esegue alcune verifiche preliminari.

  • Firma digitalmente la fattura.

  • Invia la fattura al Sistema di Interscambio.

  • Riceve le notifiche emesse dal Sistema di Interscambio rendendole disponibili all’utente.

  • A ciclo di gestione completato, inserisce la fattura e le notifiche in un Pacchetto di versamento per l’archiviazione a lungo termine.

5.1. Trasmissione della Fattura XML

Per caricare una Fattura XML è possibile utilizzare una delle seguenti API:

  1. POST /fatture/xml

  2. POST /aziende/{idAzienda}/fatture/xml

  3. POST /aziende/{idAzienda}/fatture/uploadXml

Le prime due API contengono nel corpo della richiesta il contenuto XML della fattura.

La terza API, invece, esegue un upload multipart del file XML contenente la fattura che deve essere in una parte di nome invoice.

Nella prima API il sistema ricava l’azienda dal contenuto XML della fattura stessa, tuttavia questo è possibile solo se l’azienda non è divisa in diverse unità organizzative oppure se la fattura è riferita all’unità organizzativa di default.

Nella seconda API il valore di idAzienda può contenere il codice di una unità organizzativa, in questo caso la fattura viene gestita e archiviata per quella specifica unità organizzativa.

La terza API è equivalente alla seconda e risulta più semplice da usare quando la fattura da trasmettere è già stata salvata in un file.

Dopo il caricamento è possibile seguire il ciclo di gestione della fattura mediante la seguente API:

  • GET /fatture/{idFattura}

{idFattura} può essere l’identificativo numerico assegnato durante il caricamento oppure il nome del file (senza estensione .xml), anch’esso assegnato durante il caricamento.

Nell’oggetto restituito è disponibile una proprietà status che può contenere uno dei valori riportati nel capitolo Stati della fattura,

5.2. Monitoraggio delle fatture trasmesse

Dopo la trasmissione di una fattura al sistema, essa viene elaborata secondo le seguenti fasi:

  • Firma del file

  • Trasmissione al Sistema di Interscambio

  • Attesa dei messaggi di notifica

  • Conclusione del processo di gestione

  • Archiviazione

Per ciascuna fattura è possibile rilevare lo stato con l’API GET /fatture/{idFattura}, oppure è possibile rilevare lo stato di tutte le fatture di una azienda con l’API GET /aziende/{idAzienda}/fatture. In quest’ultimo caso conviene utilizzate dei criteri di selezione per limitare l’elenco, ad esempio, ad un certo intervallo di date:

GET /aziende/{idAzienda}/fatture?data_inizio=2017-10-01&data_fine=2017-10-31

Il caso d’uso più comune è quello in cui, dopo la trasmissione della fattura, l’utente vuole verificare l’arrivo dei messaggi del Sistema di Interscambio che sono:

  • RC (ricevuta di consegna), che attesa la consegna della fattura al destinatario

  • NS (notifica di scarto), che indica un errore nella fattura

  • MC (mancata consegna), che attesta un problema temporaneo nella consegna della fattura al destinatario

  • NE (notifica di esito), che riporta l’accettazione o il rifiuto della fattura da parte del destinatario

  • DT (decorrenza termini), che attesta la scadenza del periodo a disposizione del destinatario per inviare un esito

  • AT (avvenuta trasmissione), che attesta un problema permanente nella consegna della fattura al destinatario

Per esaminare i messaggi ricevuti per ciascuna fattura è possibile usare la seguente API:

GET /fatture/{idFattura}/ricevute

Oppure, la seguente API riporta i messaggi ricevuti per tutte le fatture di un’azienda:

GET /aziende/{idAzienda}/ricevute

E' anche possibile ottenere i messaggi di tutte le fatture di tutte le aziende a cui l’utente ha accesso:

GET /ricevute

Le ultime due API possono sfruttare il flag di lettura per filtrare solo i messaggi che non sono stati letti in precedenza, seguendo questo flusso di lavoro:

Recuperare tutte i messaggi da leggere:

GET /aziende/{idAzienda}/ricevute?flag=true

Elaborare tutti messaggi (ad esempio notificando l’utente o aggiornando il database) e marcare la notifica come "già letta" con l’API:

POST /ricevute/{idRicevuta}/unflag

Dopo aver impostato la notifica come già letta, essa non verrà più restituita dall’API in cui è indicato flag=true.

5.3. Ricezione delle fatture

Il meccanismo del flag di lettura è applicabile anche alle fatture e può risultare utile per gestire le fatture ricevute mediante il codice destinatario associato al canale di ricezione.

La seguente API consente di ottenere tutte le fatture ricevute da leggere:

GET /aziende/{idAzienda}/fatture?flag=true&dir=R

Il contenuto XML delle singole fatture può essere recuperato con:

GET /fatture/{idFattura}.xml

Quindi la fattura può essere marcata come già letta con:

POST /fatture/{idFattura}/unflag

5.4. Trasmissione della notifica Esito Committente

Per le fatture ricevute, l’azienda destinataria può inviare una notifica Esito Committente con la quale comunica all’entte che ha emesso la fattura se essa è stata accettata o rifiutata.

Se l’operazione non viene fatta entro 15 giorni, il ciclo di gestione della fattura elettronica si intende comunque concluso e il sistema di interscambio emetterà un messaggio DT (Decorrenza Termini) per entrambi i soggetti. La fattura può essere accettata o rifiutata, ma questa comunicazione tra soggetto emittente e destinatario avverrà con altri mezzi e la fattura dovrò in ogni caso essere registrata nella contabilità di entrambi.

Per trasmettere la notifica di esito committente di una fattura va usata la seguente API:

POST /fatture/{idFattura}/ricevute

Il corpo della richiesta conterrà i dati della notifica. In JSON:

{
  "esito": "string", (1)
  "note": "string", (2)
  "riferimento": {
    "numero": "string",  (3)
    "anno": 0, (4)
    "posizione": 0 (5)
  },
  "codice": "string" (6)
}
  1. Esito da comunicare al mittente, EC01 per "Accettata", EC02 per "Rifiutata"

  2. Note da comunicare per giustificare l’esito

  3. Numero del documento

  4. Anno del documento

  5. Posizione del documento nel lotto (1 se il file conteneva una sola fattura)

  6. Codice identificativo del messaggio (opzionale)

6. Gestione delle strutture dell’azienda

Utilizzando il flusso di lavoro ordinario, dove le fatture vengono caricate sull’azienda tramite POST /fatture/xml o tramite POST /aziende/{idAzienda}/fatture, i documenti vengono considerati come versati da un prodotture identificato da una struttura di default dell’azienda.

Se l’azienda è organizzata in più strutture organizzative che richiedono di essere differenziate nell’archiviazione occorre identificare la struttura a cui associare i documenti.

Nelle API, per indirizzare un’azienda con una struttura organizzativa va aggiunto un codice alfanumerico alla partita IVA separato da un punto (.).

Il codice azienda è quindi definito in generale con le seguenti regole:

<suffisso-struttura> ::= "." <id-struttura>
<id-azienda> ::= <partita-iva> <suffisso-struttura> | ""

Se il codice azienda è formato dalla sola partita IVA, allora i documenti sono associati alla struttura di default dell’azienda.

Se il codice azienda è formato dalla partita IVA più il suffisso con il codice della struttura separato da un punto, allora i documenti sono associati alla struttura indicata.

6.1. Caricamento diretto della Fattura XML

La API POST /fatture/xml consente di caricare una Fattura elettronica direttamente tramite il file XML. Durante il caricamento la partita IVA viene ricavata dal contenuto del file XML per identificare l’azienda.

Questa API, quindi, può essere utilizzata solo se i documenti sono diretti alla struttura di default.

Se i documenti devono essere posizionati in una specifica struttura dell’azienda le informazioni contenute nell’XML non sono sufficienti ad indentificare la struttura, perciò questa API non può essere utilizzata e deve invece essere utilizzata la seguente API che comprende l’identificazione della struttura: POST /aziende/{idAzienda}/fatture/xml.

Il sistema prevede i seguenti controlli:

  1. La partita IVA indicata nell’XML deve corrispondere a quella in {idAzienda}

  2. Il sezionale indicato nel documento non deve essere usato in strutture diverse

6.2. Diritti di accesso degli utenti

La struttura di default individuata tramite la sola partita IVA dell’azienda e la struttura specifica individuata dalla partita IVA più il suffisso hanno una gestione degli accessi distinta per cui, ad esempio, gli utenti che hanno accesso alla struttura di default non ereditano l’accesso alle strutture specifiche, né viceversa.

7. Pacchetti di versamento

Il pacchetto di versamento è l’entità con cui i documenti vengono introdotti nel sistema di conservazione. eDoc API gestisce il caricamento dei pacchetti di versamento secondo vari formati definiti nel manuale della conservazione.

Il formato del pacchetto di versamento è definito da un codice che può assumere questi valori:

Codice Descrizione

F000

Fatture elettroniche inviate

F001

Fatture elettroniche inviate gestite dal sistema

F002

Fatture elettroniche ricevute

F003

Fatture elettroniche ricevute gestite dal sistema

F005

Pacchetto di versamento PEC eml

F998

Pacchetto di un precedente conservatore

F997

Pacchetto copia digitale documento analogico

F999

Pacchetto di versamento eDoc generico

I pacchetti con formato F999 (generici) devono essere dotati di un indice del contenuto in cui sono dichiarati i file contenuti nel pacchetto, il registro di archiviazione in cui devono essere versati e altre informazioni necessarie per l’archiviazione, tra le quali i metadati da associare ai documenti.

Per tutti gli altri formati, escluso F001 e F003, il pacchetto non contiene un indice del contenuto, ma solo i file da archiviare. Questi formati sono dedicati a quei documenti nativamente elettronici che, per le loro caratteristiche, consentono l’estrazione dei metadati in modo automatico. Mediante apposite convenzioni descritte nelle specifiche di questi formati, i documenti contenuti vengono elaborati dal sistema ricavando automaticamente le informazioni necessarie per l’archivazione.

I formati F001 e F003 (fatture elettroniche trasmesse e ricevute gestite dal sistema) sono del tutto analoghi ai formati F000 e F002 (fatture elettroniche trasmesse e ricevute gestite da altri sistemi). Questi pacchetti vengono generati internamente al sistema durante la gestione delle fatture elettroniche e non sono mai caricati direttamente dall’utente.

7.1. Stati del pacchetto di versamento

Il pacchetto di versamento può trovarsi in uno degli stati riportati nel paragrafo Tabella dei codici degli stati del PDV.

7.2. Formato F000 Fatture elettroniche inviate

F000 è un particolare formato del pacchetto di versamento che consiste in un file ZIP contenente le Fatture elettroniche in formato XML 1.0, 1.1 o 1.2 il cui invio è già stato gestito con altri sistemi. I file delle fatture devono essere corredati delle relative notifiche.

I file contenuti nell’archivio ZIP devono mantenere il nome file originale così come definito da chi ha emesso la fattura.

I file relativi alle fatture XML contenuti nello ZIP possono essere in formato XML con firma XADeS, oppure in formato P7M, secondo le specifiche definite dal Sistema di Interscambio.

I file delle notifiche sono sempre firmati in modalità XADeS dal Sistema di Interscambio.

Il processo di gestione di questo PDV prevede una fase di validazione in cui il pacchetto viene esaminato e viene prodotto un rapporto di versamento (RDV) e un esito dalla validazione.

In base all’esito il pacchetto può essere accettato o rifiutato dal sistema di conservazione.

Se il pacchetto viene rifiutato il Rapporto di Versamento contiene uno o più errori che spiegano il motivo del rifiuto.

7.2.1. Validazione del PDV F000

La validazione consiste nei seguenti controlli:

  • Il file ZIP deve contenere solo i file attesi, cioè le fatture XML e le relative notifiche. La presenza di altri file provoca il rifiuto del pacchetto.

  • La firma digitale dei file (fatture e notifiche) deve essere valida.

Durante la validazione la procedura predispone le unità documentali relative alle fatture contenute secondo i seguenti criteri:

  • I file delle fatture vengono aggregati con le rispettive notifiche e si determina se la fattura è stata scartata oppure ha completato il ciclo di gestione

  • Le fatture scartate per le quali esiste un’altra fattura che ha completato il ciclo di gestione vengono annesse (insieme alle relative notifiche) alla fattura con lo stesso numero che ha completato il ciclo di gestione

  • Le fatture scartate per le quali non esiste un’altra fattura che ha completato il ciclo di gestione vengono considerate come unità documentali indipendenti

  • Le fatture rifiutate per le quali esiste un’altra fattura che ha completato il ciclo di gestione vengono annesse (insieme alle relative notifiche) alla fattura che ha completato il ciclo di gestione con lo stesso numero

  • Le fatture rifiutate per le quali non esiste un’altra fattura che ha completato il ciclo di gestione rimangono come unità documentali indipendenti

Le fatture che non hanno le notifiche producono un messaggio di avvertimento nella ricevuta di versamento. Senza le notifiche non è possibile stabilire se la fattura è stata accettata, scartata, accettata, ecc e neanche se è stata spedita. Pertanto i metadati relativi a questa informazioni non vengono valorizzati.

7.3. Formato F001 Fattura XML gestite dal sistema

Il formato F001 si riferisce ai Pacchetti di Versamento tramite i quali le Fatture PA gestite dal sistema vengono messe in conservazione.

Il ciclo di gestione delle Fatture PA dura fino a 15 giorni, includendo la possibilità che il documento vada in decorrenza termini (DT) o in impossibilità di recapito (AT).

Volendo includere anche la possibilità di riemissione delle fatture dopo notifica di esito ( NE ) negativa (modalità non ammessa da questo sistema), i tempi possono allungarsi anche in modo non precisamente definito.

Questa eventualità dovrebbe essere considerata come un’eccezione da gestire a parte, tuttavia essa viene contemplata nell’algoritmo definito di seguito per la formazione dei PDV F001.

Nella norma una fattura datata alla fine del mese X dovrebbe essere trasmessa nei primi giorni del mese X + 1 e si può ritenere che alla fine del mese X + 1 il suo processo di gestione si sia concluso.

L’algoritmo descritto di seguito avvia la formazione del PDV delle fatture del mese X nel mese X + 1 e lo conclude appena possibile nel mese X + 2. Ad esempio, nel mese di Maggio 2015 si formano i PDV delle fatture con data nel mese di Aprile 2015.

Questi PDV si chiudono appena possibile nel mese di Giugno 2015.

L’algoritmo non consente di aprire un PDV F001 se prima non si è chiuso il precedente.

Con cadenza quotidiana, alle 18:00, esclusi i primi 10 giorni del mese, si esegue il seguente algoritmo per l’apertura e la formazione del PDV:

  • Per ogni struttura (leggi azienda)

    • Verifica se esiste un PDV con formato F001 in stato P01 (aperto) per la struttura.

    • Se sì, considera quel PDV, altrimenti crea un nuovo PDV intestato alla struttura registrando la data di creazione

    • Sia data-limite il primo giorno del mese in cui è stato creato il PDV

    • Per ogni fattura intestata alla struttura che rispetta tutte le seguenti condizioni:

      • la data-documento è precedente a data-limite

      • è priva del riferimento al pdv

      • si trova in uno dei seguenti stati: S06 (attesa notifiche), S07 (decorrenza termini), S08 (impossibilità di recapito), S09 (accettata), S10 (rifiutata)

        • Imposta il PDV nella fattura

Con cadenza quotidiana, alle 03:00, si esegue il seguente algoritmo per completare la formazione del PDV:

  • Per ogni PDV con formato F001 in stato P01 (aperto)

    • Per ogni fattura contenuta nel PDV

      • Se la fattura si trova in uno dei seguenti stati: S07 (decorrenza termini), S08 (impossibilità di recapito), S09 (accettata), S10 (rifiutata)

        • Allora esegue l’azione A12_ARCHIVE sulla fattura che porta lo stato a S16_PRONTA_PER_CONSERVAZIONE

    • Se tutte le fatture contenute nel PDV si trovano nello stato S16 e la data di creazione del PDV si trova nel mese precedente alla data attuale

      • Allora avanza il PDV allo stato S02 Elaborazione in corso

Il meccanismo consente di rispettare il seguente comportamento:

  • Finché c’è un PDV con formato F001 aperto non ne viene creato un altro

  • Nel PDV non possono entrare fatture successive alla fine del mese precedente alla sua formazione

  • Il PDV non viene chiuso prima del mese successivo alla sua formazione

  • Il PDV non viene chiuso se contiene fatture il cui processo non è ancora concluso

7.4. Formato F002 Fatture elettroniche ricevute

Utilizzando questo formato l’utente ha la possibilità di versare in conservazione le fatture elettroniche ricevute, sia per i soggetti privati che ricevono fatture B2B, sia per le fatture elettroniche ricevute dagli enti della pubblica amministrazione.

Il pacchetto F002 è un file ZIP che contiene le fatture elettroniche e le relative notifiche in modo analogo al formato F000.

7.5. Formato F003 Fatture elettroniche ricevute gestite dal sistema

Il pacchetto F003 viene generato internamente dal sistema il versamento delle fatture ricevute.

7.6. Formato F005 PEC eml

Il formato F005 si riferisce ad un pacchetto di versamento per l’archiviazione di messaggi di posta elettronica certificata (PEC).

Il formato consiste in un file ZIP contenente uno o più file *.eml.

Ciascun file *.eml è un messaggio email in formato RFC-822.

Il pacchetto deve contenere esclusivamente file *.eml raggruppati in una o più cartelle aventi come nome l’indirizzo della casella PEC che si sta archiviando. Ad esempio:

I file contenuti nella cartella di una casella devono essere messaggi trasmessi o ricevuti da quella casella. Un file .eml che si trova nella cartella di una casella senza essere né trasmesso né ricevuto da quella casella provoca un errore di validazione e lo scarto del PDV con errore E024.

All’interno delle cartelle relative alle caselle i file .eml possono essere organizzati in sotto cartelle, ma questo non influenza l’elaborazione. I file .eml di una cartella vengono considerati tutti insieme come se non ci fossero le sottocartelle.

Ognuno dei file di una casella PEC può essere:

  1. Un messaggio inviato, privo di firma S/MIME

  2. Un messaggio ricevuto da un’altra casella PEC, dotato di S/MIME

  3. Un messaggio ricevuto da un’altra casella non PEC, privo di firma S/MIME

  4. Un messaggio ricevuto dal gestore della casella PEC che si sta archiviando relativo all’accettazione di un messaggio inviato, dotato di firma S/MIME

  5. Un messaggio ricevuto dal gestore della casella PEC del destinatario relativo alla consegna di un messaggio inviato, dotato di firma S/MIME

7.7. Formato F997 Pacchetto copia digitale di documento analogico

Il formato F997 è riservato all’archiviazione di copie digitali di documenti analogici. Qualora il produttore abbia delegato Entaksi alla firma digitale per la conservazione sostitutiva di documenti analogici il caricamento di questo tipo di pacchetto viene abilitato sulla console.

Il metadato terms:format valorizzato come analogico definisce delle copie digitali di documenti analogici. In questo caso se i documenti non sono stati versati nel precedente anno solare, ma hanno una data antecedente, vengono validati con firma digitale e versati con questo tipo di pacchetto.

7.8. Formato F998 Pacchetto di precedente conservatore

Il formato F998 è dedicato all’archiviazione di documenti provenienti da un precedente conservatore.

Il passaggio dei documenti da un conservatore all’altro avviene mediante i Pacchetti di Distribuzione per interoperabilità con i quali il precedente conservatore rende disponibili i documenti archiviati.

Questi Pacchetti di Distribuzione possono essere caricati nel sistema di conservazione Entaksi come pacchetti di versamento F998 e archiviati come tali. In una fase successiva il contenuto di questi pacchetti può essere riorganizzato secondo la struttura del sistema di conservazione mantenendo traccia della prova di conservazione originale già generata dal precedente conservatore.

Prima di versare dei pacchetti F998 nel sistema è opportuno contattare l’assistenza all’indirizzo assistenza@entaksi.eu.

7.9. Formato F999 Pacchetto generico con indice

Il formato F999 definisce i pacchetti di versamento di documenti generici per i quali è necessario includere nel pacchetto anche un file indice dove sono riportate le informazioni necessarie per l’archiviazione.

Nel capitolo seguente sono illustrati alcuni esempi dell’indice dei pacchetti di versamento in formato F999 per varie tipologie documentali.

8. Esempi di Pacchetti di Versamento

8.1. Tipi documento

I tipi di documento presenti nel sistema sono:

Tabella 2. Tipi documento
Codice Descrizione

D01

Fattura attiva

D02

Fattura passiva

D03

Nota variazione aumento

D04

Nota variazione diminuzione

D05

Documento di trasporto

D06

Scontrino

D07

Ricevuta

D08

Bolla

D09

Libro giornale

D10

Libro inventari

D11

Libro mastro

D12

Registro cronologico

D13

Libro cespiti

D14

Registro Irpef

D15

Registro fatture acquisto

D16

Registro acquisti agenzie viaggio

D17

Registro fatture emesse

D18

Registro fatture in sospeso

D19

Registro corrispettivi

D20

Giornale fondo

D21

Registro corrispettivi agenzie viaggio

D22

Registro emergenza Iva

D23

Bollettario

D24

Registro prima nota

D25

Registro unico Iva

D26

Registro riepilogativo Iva

D27

Registro sezionale Iva acquisiti intra-UE

D28

Registro acquisti intra-UE non commerciali

D29

Registro trasferimenti intra-UE

D30

Registro dichiarazioni d’intenti emesse

D31

Registro dichiarazioni d’intenti ricevute

D32

Registro omaggi

D33

Registro memoria produzione contrassegno

D34

Registro lavorazione produzione contrassegno

D35

Registro carico produzione contrassegno

D36

Registro scarico produzione contrassegno

D37

Registro di beni in deposito

D38

Registro di beni in conto lavorazione

D39

Registro di beni in comodato

D40

Registro di beni in prova

D41

Registro sezionale Iva interno

D42

Registro carico stampati fiscali

D43

Registro società controllanti e controllate

D44

Registro carico scarico regime margine metodo analitico

D45

Registro acquisti regime margine metodo globale

D46

Registro vendite regime margine metodo globale

D47

Registro carico centri elaborazione dati

D48

Registro scarico centri elaborazione dati

D49

Registro somme ricevute in deposito

D50

Registro editori

D51

Libro soci

D52

Libro obbligazioni

D53

Libro adunanze e delibere di assemblee

D54

Libro adunanze e delibere del consiglio di amministrazione

D55

Libro adunanze e delibere del collegio sindacale

D56

Libro adunanze e delibere del comitato esecutivo

D57

Libro adunanze e delibere delle assemblee azionisti

D58

Altri registri

D5802

Determine

D5803

Nota variazione aumento ricevuta

D5804

Nota variazione diminuzione ricevuta

D59

Unico persone fisiche

D60

Unico società di persone

D61

Unico società di capitali

D62

Unico enti non commerciali

D63

Irap persone fisiche

D64

Irap Società persone

D65

Irap Società capitale

D66

Irap enti non commerciali ed equiparati

D67

Irap amministrazioni ed enti pubblici

D68

Modello730

D69

Modello consolidato nazionale e mondiale

D70

Modello Iva

D71

Modello Iva VR richiesta rimborso credito Iva

D72

Modello Iva 26LP/2006 prospetto liquidazioni periodiche

D73

Modello Iva 74 bis

D74

Comunicazione annuale dati Iva

D75

Modello richiesta rimborso credito Iva trimestrale

D76

Modello dati contenuti dichiarazione intento ricevute

D77

Modello 770 semplificato

D78

Modello 770 ordinario

D79

Modello certificazione CUD

D80

Modello F23

D81

Modello F24

D82

Modelli allegati alla Dichiarazione dei Redditi Modello Unico

D83

Modelli annotazione separata

D84

Ricevuta presentazione modelli dichiarazione

D85

Altri documenti

D8501

Contratti

D8502

Cedolini

D8503

Manuali

D85PEC

PEC

meta

Registro meta

8.2. Esempio pacchetto con documenti D01 Fatture emesse e D02 Fatture ricevute

Il pacchetto contiene un documento appartenente alla tipologia D01, Fatture emesse e un documento appartenente alla tipologia D02, Fatture ricevute.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<pdv xmlns:terms="http://purl.org/dc/terms/" xmlns="http://entaksi.eu/schemas/econ/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/">
    <formato>F999</formato> (1)
    <fileGroup> (2)
        <dc> (3)
            <terms:type>Fattura Emessa</terms:type> (4)
            <terms:subject>Fattura SEZ/33 del 01/04/2015 Cliente Srl</terms:subject> (5)
            <terms:format>analogico</terms:format> (6)
        </dc>
        <metadata key="produttore:ragionesociale">Acme Srl</metadata> (7)
        <metadata key="produttore:idfiscale">IT12345678904</metadata>

        <metadata key="destinatario:ragionesociale">Cliente Srl</metadata> (8)
        <metadata key="destinatario:idfiscale">IT01621900479</metadata>

        <metadata key="documento:data">2015-04-01</metadata> (9)
        <metadata key="documento:anno">2015</metadata>
        <metadata key=documento:tipo>D01</metadata>
        <metadata key="documento:sezionale">SEZ</metadata> (10)
        <metadata key="fattura:numero">SEZ/D33</metadata> (11)
        <registro>urn:entaksi:IT12345678904:_default:reg:2015:D01:SEZ</registro> (12)
        <file> (13)
            <dc>
                <terms:title>fattura_emessa.pdf</terms:title> (14)
                <terms:format>application/pdf</terms:format>
            </dc>
        </file>
    </fileGroup>
    <fileGroup> (15)
        <dc>
            <terms:type>Fattura Ricevuta</terms:type> (16)
            <terms:subject>Fattura XXX/12 del 10/05/2015 Fornitore Srl</terms:subject>
            <terms:format>analogico</terms:format>
        </dc>
        <metadata key="produttore:ragionesociale">Acme Srl</metadata> (17)
        <metadata key="produttore:idfiscale">IT12345678904</metadata>

        <metadata key="mittente:ragionesociale">Fornitore Srl</metadata> (18)
        <metadata key="mittente:idfiscale">IT01621900479</metadata>

        <metadata key="documento:data">2015-05-10</metadata>
        <metadata key="documento:anno">2015</metadata>
        <metadata key=documento:tipo>D02></metadata> (19)
        <metadata key="documento:sezionale">_default</metadata> (20)
        <metadata key="fattura:numero">XXX/12</metadata> (21)
        <registro>urn:entaksi:IT12345678904:_default:reg:2015:D02:_default</registro> (22)
        <file>
            <dc>
                <terms:title>fattura_ricevuta.pdf</terms:title>
                <terms:format>application/pdf</terms:format> (23)
            </dc>
        </file>
    </fileGroup>
</pdv>
Metadato Descrizione

1

Il formato F999 indica che si tratta di un pacchetto con indice.
Si tratta di una informazione interna che serve per la validazione del pacchetto.

2

Il file è composto da una sequenza di una o più tag fileGroup ognuna delle quali rappresenta una unità documentaria (ovvero un documento) inviato in conservazione. La tag si chiama fileGroup perché può contenere più di un file, dove il primo file è il file principale relativo al documento vero e proprio, mentre i file successivi sono annessi o allegati al file.
Nella maggior parte dei casi ci sarà un solo file, ma è possibile, ad esempio, archiviare la scansione della ricevuta di ritorno della raccomandata con cui è stata inviata la fattura. Questa scansione verrebbe archiviata come secondo file, cioè come annesso al documento e insieme ad esso costituisce un’unica unità documentaria.

3

I metadati dell’unità documentaria sono indicati mediante un gruppo di tag con namespace terms che si trovano all’interno della tag dc e una serie di tag metadata che hanno un attributo key e un valore.
I metadati dc sono i metadati Dublin Core, uno standard internazionale per la classificazione dei documenti in base a criteri archivistici. I metadati metadata sono altri metadati relativi ai criteri gestionali.

4

Il termine Dublin Core terms:type contiene una descrizione comprensibile per l’utente del tipo di documento archiviato. Per le fatture emesse (come in questo caso) deve essere uguale “Fatture Emesse”.

5

Il termine Dublin Core terms:subject contiene una descrizione del documento archiviato. Per le fatture può essere uguale a “Fattura numero-documento del data-documento cliente”. Il contenuto è arbitrario ma è importante che contenga il numero del documento così come riportato nella fattura.

6

Il termine Dublin Core terms:format a livello di fileGroup ovvero a livello di unità documentaria, indica se il documento è analogico o digitale. Se il documento è analogico (cioè se è una scansione di un documento cartaceo) il processo di versamento completa la digitalizzazione a norma del documento.
Il documento analogico va dichiarato inserendo questa tag con il valore “analogico” come nell’esempio.
In assenza di questa tag il documento è considerato digitale.
Il documento analogico deve essere un file PDF firmato digitalmente, quindi un file PDF con firma PaDES oppure un file PDF firmato nella vecchia modalità CaDES, ovvero con estensione .pdf.p7m.

7

Le tag metadata consentono di indicare una vasta varietà di metadati per l’archiviazione dei documenti. In questo esempio sono riportati solo quelli obbligatori a norma di legge. La prima coppia di metadati è quella che identifica il “produttore”. Il produttore è colui che versa il documento nel sistema di conservazione. Nel caso delle fatture emesse il produttore coincide con l’azienda a cui è intestata la fattura (il cedente di beni o prestatore di servizi in termini fiscali), anche nel caso in cui la fattura dovesse essere stata emessa da un intermediario.
Mediante la chiave produttore:ragionesociale va indicata la ragione sociale del produttore. Con la chiave produttore:idfiscale va indicato invece l’identificativo fiscale del produttore, composto dal codice paese (IT per Italia) e dalla partita IVA.

8

In modo del tutto analogo la coppia di tag metadata con chiavi uguali a destinatario:ragionesociale e destinatario:idfiscale indica i dati del destinatario della fattura, ovvero il cliente (in termini fiscali il cessionario di beni o il committente di servizi).

9

Le tag metadata con la chiave che ha come prefisso documento: definiscono i dati che servono per identificare e posizionare il documento nell’archivio.

  • documento:data definisce la data del documento che, per le fatture emesse, è la data della fattura.

  • documento:anno deve coincidere con l’anno indicato in documento:data.

  • documento:tipo è il codice del tipo di documento. Le fatture emesse vanno archiviate con il codice D01.

  • documento:sezionale è il numeratore utilizzato per la numerazione progressiva delle fatture. Se l’azienda non usa più di un numeratore, in questo dato può essere indicato il valore _default. Il numeratore e il progressivo costituiscono di norma il “numero del documento” che è riportato in terms:subject. Il modo in cui numeratore e progressivo sono combinati in un’unica stringa è a discrezione dell’azienda ed è stato oggetto nel tempo di alcune precisazione dell’Agenzia delle Entrate. Per semplificare il processo di digitalizzazione è utile suggerire alle aziende di adottare meccanismi semplici di combinazione, ad esempio separare il numeratore e il progressivo con una sbarra (SEZ/33) o con un trattino (SEZ-33)

  • documento:numero è il progressivo della fattura estratto dal numero della fattura senza il sezionale. Questo valore deve essere numerico e univoco all’interno del sezionale. Ovvero, il sistema non accetterà l’archiviazione di due documenti con lo stesso anno, tipo, sezionale e numero

10

Il metadato documento:sezionale corrisponde al sezionale delle fatture emesse, non è necessario indicarlo per le fatture ricevute.

11

Il metadato fattura:numero è il numero della fattura, che comprende sezionale e progressivo.

12

la tag registro specifica il registro di archiviazione del documento che si può ricavare dai metadati precedenti secondo questa sintassi:
urn:entaksi:<id-fiscale-produttore>:<unità-organizzativa>:reg:<anno>:<tipo-documento>:<sezionale>
Se l’azienda ha più unità organizzative (il che corrisponde anche alla registrazione di più entità azienda diverse nel sistema), il codice dell’unità organizzativa va indicato nel registro. Altrimenti in questa posizione verrà indicato _default.

13

Una o più tag file consentono di dichiarare i file che devono essere archiviati nell’unità documentaria. In questo esempio c’è un solo file.

14

Ciascun file va dichiarato con due o tre metadati Dublin Core che sono i seguenti:

  • terms:title deve contenere il nome del file così com’è all’interno del file zip del pacchetto di versamento

  • terms:format deve riportare il mime type del file. Per i documenti PDF il mime type è application/pdf.

Se il file è firmato in modalità CaDES e quindi ha estensione .pdf.p7m deve essere riportato anche il seguente termine:

  • <terms:medium>application/pkcs7-mime</terms:medium>.

Il termine terms:format rimane application/pdf.

15

Nel secondo fileGroup dell’esempio viene dichiarata una fattura ricevuta da un fornitore. Il Pacchetto di Versamento può contenere un numero arbitrario di fileGroup, nei limiti in cui il file pdv.xml e il file ZIP mantengono delle dimensioni ragionevoli per essere elaborati. Mediamente non dovrebbero esserci più di 100 documenti.

16

I metadati Dublin Core della fattura ricevuta sono analoghi a quelli della fattura emessa, ma in terms:type è indicato "Fattura Ricevuta”.

17

Il produttore è sempre l’azienda che sta versando il documento in conservazione. In questo caso coincide con il destinatario della fattura (in termini fiscali il cessionario di beni o committente di servizi).

18

L’azienda da cui proviene la fattura (in termini fiscali il cedente di beni o prestatore di servizi) è indicata con mittente.

19

il tipo documento per le fatture ricevute è D02.

20

Il sezionale o serie archivistica consente di archiviare i documenti dello stesso tipo in registri diversi. In questo caso il sezionale non ha niente a che fare con il sezionale della fattura, ma può essere usato per dividere le fatture secondo un criterio scelto dal produttore. Ad esempio potrebbe essere definito un sezionale per ogni cliente, oppure per categoria commerciale. Indicando _default le fatture vengono archiviate tutte nello stesso registro di default.
Notare che per le fatture ricevute non deve essere indicato il metadato documento:numero. Le fatture ricevute vengono numerate automaticamente dal sistema con un progressivo di archiviazione.

21

Il metadato fattura:numero è il numero della fattura, che comprende sezionale e progressivo.

22

Il registro di archiviazione si compone come nel caso delle fatture trasmesse.

23

In questo esempio la fattura in formato originario analogico è stata firmata in formato PaDES, e dunque i metadati si riferiscono a un file pdf "fattura_ricevuta.pdf", pertanto non è necessario apporre il metadato terms:medium.

8.3. Esempio pacchetto con documenti D15 Registro fatture acquisto

Il pacchetto contiene due documenti appartenenti alla tipologia D15, Registro fatture acquisto.

<?xml version="1.0" encoding="UTF-8"?>
<pdv xmlns="http://entaksi.eu/schemas/econ/1.0/" xmlns:terms="http://purl.org/dc/terms/">
  <formato>F999</formato> (1)
  <fileGroup> (2)
    <dc> (3)
      <terms:type>Registro fatture acquisto</terms:type> (4)
      <terms:subject>REGISTRO IVA ACQUISTI dal 01/01 al 31/12</terms:subject> (5)
    </dc>
    <metadata key="produttore:idfiscale">IT01234567890</metadata> (6)
    <metadata key="produttore:nome">Nome produttore</metadata>
    <metadata key="produttore:cognome">Cognome produttore</metadata>

    <metadata key="destinatario:idfiscale">IT01234567891</metadata> (7)
    <metadata key="destinatario:nome">Nome destinatario</metadata>
    <metadata key="destinatario:cognome">Cognome destinatario</metadata>

    <metadata key="documento:anno">2015</metadata> (8)
    <metadata key="documento:tipo">D15</metadata>
    <metadata key="documento:data">2015-12-31</metadata>
    <metadata key="documento:datainizio">2015-01-01</metadata>
    <metadata key="documento:datatermine">2015-12-31</metadata>
    <registro>urn:entaksi:IT01234567890:_default:reg:2015:D15:_default</registro> (9)
    <file> (10)
      <dc>
        <terms:title>d000000045_0001_0001.pdf</terms:title> (11)
        <terms:format>application/pdf</terms:format>
      </dc>
    </file>
  </fileGroup>
  <fileGroup> (12)
    <dc>
      <terms:type>Registro fatture acquisto</terms:type> (13)
      <terms:subject>DOCUMENTI NON PAGATI/INCASSATI</terms:subject>
    </dc>
    <metadata key="produttore:idfiscale">IT01234567890</metadata> (14)
    <metadata key="produttore:nome">Nome produttore</metadata>
    <metadata key="produttore:cognome">Cognome produttore</metadata>

    <metadata key="destinatario:idfiscale">IT01234567891</metadata> (15)
    <metadata key="destinatario:nome">Nome destinatario</metadata>
    <metadata key="destinatario:cognome">Cognome destinatario</metadata>

    <metadata key="documento:anno">2015</metadata> (16)
    <metadata key="documento:tipo">D15</metadata>
    <metadata key="documento:data">2015-12-31</metadata>
    <registro>urn:entaksi:IT01234567890:_default:reg:2015:D15:_default</registro> (17)
    <file> (18)
      <dc>
        <terms:title>d000000051_0001_0001.pdf</terms:title> (19)
        <terms:format>application/pdf</terms:format>
      </dc>
    </file>
  </fileGroup>
</pdv>
Metadato Descrizione

1

Il formato F999 indica che si tratta di un pacchetto con indice.
Si tratta di una informazione interna che serve per la validazione del pacchetto.

2

Il file è composto da una sequenza di una o più tag fileGroup ognuna delle quali rappresenta una unità documentaria (ovvero un documento) inviato in conservazione. La tag si chiama fileGroup perché può contenere più di un file, dove il primo file è il file principale relativo al documento vero e proprio, mentre i file successivi sono annessi o allegati al file.
Nella maggior parte dei casi ci sarà un solo file, ma è possibile, ad esempio, archiviare la scansione della ricevuta di ritorno della raccomandata con cui è stata inviata la fattura. Questa scansione verrebbe archiviata come secondo file, cioè come annesso al documento e insieme ad esso costituisce un’unica unità documentaria.

3

I metadati dell’unità documentaria sono indicati mediante un gruppo di tag con namespace terms che si trovano all’interno della tag dc e una serie di tag metadata che hanno un attributo key e un valore.
I metadati dc sono i metadati Dublin Core, uno standard internazionale per la classificazione dei documenti in base a criteri archivistici. I metadati metadata sono altri metadati relativi ai criteri gestionali.

4

Il termine Dublin Core terms:type contiene una descrizione comprensibile per l’utente del tipo di documento archiviato. In questo caso corrisponde a "Registro fatture acquisto".

5

Il termine Dublin Core terms:subject contiene una descrizione del documento archiviato. In questo caso si è indicato, dal momento che si tratta di un registro, come “Registro tipo-registro dal data-inizio al data-termine”. Il contenuto è arbitrario ma è importante che contenga il tipo di registro.

6

Le tag metadata consentono di indicare una vasta varietà di metadati per l’archiviazione dei documenti. In questo esempio sono riportati solo quelli obbligatori a norma di legge. I primi tre metadati identificano il produttore, dichiarando con la chiave produttore:idfiscale l’identificativo fiscale (composto dal codice paese, IT per Italia, e dalla partita IVA), e con produttore:nome e produttore:cognome il nome e il cognome di colui che versa il documento nel sistema di conservazione.

7

In modo del tutto analogo i tre tag metadata con chiavi uguali a destinatario:idfiscale, destinatario:nome e destinatario:cognome, indicano i dati del destinatario della fattura, ovvero il cliente (in termini fiscali il cessionario di beni o il committente di servizi).

8

Le tag metadata con la chiave che ha come prefisso documento: definiscono i dati che servono per identificare e posizionare il documento nell’archivio.

  • documento:anno deve coincidere con l’anno indicato in documento:data.

  • documento:tipo è il codice del tipo di documento. I registri fatture acquisto hanno codice D15.

  • documento:data definisce la data del documento che, per le fatture emesse, è la data della fattura.

  • documento:datainizio che in presenza di documenti che coprono un arco temporale come i registri indicano la data di inizio del documento.

  • documento:datatermine sempre per i documenti che coprono un arco temporale indica la data di termine del documento.

9

la tag registro specifica il registro di archiviazione del documento che si può ricavare dai metadati precedenti secondo questa sintassi:
urn:entaksi:<id-fiscale-produttore>:<unità-organizzativa>:reg:<anno>:<tipo-documento>:<sezionale>
Se l’azienda ha più unità organizzative (il che corrisponde anche alla registrazione di più entità azienda diverse nel sistema), il codice dell’unità organizzativa va indicato nel registro. Altrimenti in questa posizione verrà indicato _default.

10

Una o più tag file consentono di dichiarare i file che devono essere archiviati nell’unità documentaria. In questo esempio ci sono due file.

11

Ciascun file va dichiarato con due o tre metadati Dublin Core che sono i seguenti:

  • terms:title deve contenere il nome del file così com’è all’interno del file zip del pacchetto di versamento

  • terms:format deve riportare il mime type del file. Per i documenti PDF il mime type è application/pdf.

Se il file è firmato in modalità CaDES e quindi ha estensione .pdf.p7m deve essere riportato anche il seguente termine:

  • <terms:medium>application/pkcs7-mime</terms:medium>.

Il termine terms:format rimane application/pdf.

12

Nel secondo fileGroup dell’esempio viene dichiarato una secondo registro registro di fatture acquisto contenente la registrazione di documenti non pagati / incassati. Il Pacchetto di Versamento può contenere un numero arbitrario di fileGroup, nei limiti in cui il file pdv.xml e il file ZIP mantengono delle dimensioni ragionevoli per essere elaborati. Mediamente non dovrebbero esserci più di 100 documenti.

14

Come sopra è indicato come terms:type "Registro fatture acquisto", cambia la descrizione in "DPCUMENTI NON PAGATI/INCASSATI".

15

Il produttore è sempre l’azienda che sta versando i documenti in conservazione.

16

Destinatario del registro.

18

Il sezionale o serie archivistica consente di archiviare i documenti dello stesso tipo in registri diversi. In questo caso il sezionale non ha niente a che fare con il sezionale della fattura, ma può essere usato per dividere le fatture secondo un criterio scelto dal produttore. Ad esempio potrebbe essere definito un sezionale per ogni cliente, oppure per categoria commerciale. Indicando _default le fatture vengono archiviate tutte nello stesso registro di default.
Notare che per le fatture ricevute non deve essere indicato il metadato documento:numero. Le fatture ricevute vengono numerate automaticamente dal sistema con un progressivo di archiviazione.

19

Il registro di archiviazione si compone come nel caso delle fatture trasmesse.

8.4. Esempio pacchetto D17 Registro fatture emesse

Il pacchetto contiene un documento appartenente alla tipologia D17, Registro fatture emesse:

<?xml version="1.0" encoding="UTF-8"?>
<pdv xmlns="http://entaksi.eu/schemas/econ/1.0/" xmlns:terms="http://purl.org/dc/terms/">
  <formato>F999</formato> (1)
  <fileGroup> (2)
    <dc> (3)
      <terms:type>Registro fatture emesse</terms:type> (4)
      <terms:subject>REGISTRO IVA VENDITE dal 01/01 al 31/12</terms:subject> (5)
    </dc>
    <metadata key="produttore:idfiscale">IT01234567890</metadata> (6)
    <metadata key="produttore:nome">Nome produttore</metadata>
    <metadata key="produttore:cognome">Cognome produttore</metadata>

    <metadata key="destinatario:idfiscale">IT01234567890</metadata> (7)
    <metadata key="destinatario:nome">Nome destinatario</metadata>
    <metadata key="destinatario:cognome">Cognome destinatario</metadata>

    <metadata key="documento:anno">2015</metadata> (8)
    <metadata key="documento:tipo">D17</metadata>
    <metadata key="documento:data">2015-12-31</metadata>
    <metadata key="documento:datainizio">2015-01-01</metadata>
    <metadata key="documento:datatermine">2015-12-31</metadata>
    <registro>urn:entaksi:IT01234567890:_default:reg:2015:D17:_default</registro> (9)
    <file> (10)
      <dc>
        <terms:title>d000000046_0001_0001.pdf</terms:title> (11)
        <terms:format>application/pdf</terms:format>
      </dc>
    </file>
  </fileGroup>
</pdv>
Metadato Descrizione

1

Il formato F999 indica che si tratta di un pacchetto con indice.
Si tratta di una informazione interna che serve per la validazione del pacchetto.

2

Il file è composto da una sequenza di una o più tag fileGroup ognuna delle quali rappresenta una unità documentaria (ovvero un documento) inviato in conservazione. La tag si chiama fileGroup perché può contenere più di un file, dove il primo file è il file principale relativo al documento vero e proprio, mentre i file successivi sono annessi o allegati al file.
Nella maggior parte dei casi ci sarà un solo file, ma è possibile, ad esempio, archiviare la scansione della ricevuta di ritorno della raccomandata con cui è stata inviata la fattura. Questa scansione verrebbe archiviata come secondo file, cioè come annesso al documento e insieme ad esso costituisce un’unica unità documentaria.

3

I metadati dell’unità documentaria sono indicati mediante un gruppo di tag con namespace terms che si trovano all’interno della tag dc e una serie di tag metadata che hanno un attributo key e un valore.
I metadati dc sono i metadati Dublin Core, uno standard internazionale per la classificazione dei documenti in base a criteri archivistici. I metadati metadata sono altri metadati relativi ai criteri gestionali.

4

Il termine Dublin Core terms:type contiene una descrizione comprensibile per l’utente del tipo di documento archiviato. In questo caso corrisponde a "Registro fatture emesse".

5

Il termine Dublin Core terms:subject contiene una descrizione del documento archiviato. In questo caso si è indicato, dal momento che si tratta di un registro, come “Registro tipo-registro dal data-inizio al data-termine”. Il contenuto è arbitrario ma è importante che contenga il tipo di registro.

6

Le tag metadata consentono di indicare una vasta varietà di metadati per l’archiviazione dei documenti. In questo esempio sono riportati solo quelli obbligatori a norma di legge. I primi tre metadati identificano il produttore, dichiarando con la chiave produttore:idfiscale l’identificativo fiscale (composto dal codice paese, IT per Italia, e dalla partita IVA), e con produttore:nome e produttore:cognome il nome e il cognome di colui che versa il documento nel sistema di conservazione.

7

In modo del tutto analogo i tre tag metadata con chiavi uguali a destinatario:idfiscale, destinatario:nome e destinatario:cognome, indicano i dati del destinatario della fattura, ovvero il cliente (in termini fiscali il cessionario di beni o il committente di servizi).

8

Le tag metadata con la chiave che ha come prefisso documento: definiscono i dati che servono per identificare e posizionare il documento nell’archivio.

  • documento:anno deve coincidere con l’anno indicato in documento:data.

  • documento:tipo è il codice del tipo di documento. I registri fatture acquisto hanno codice D15.

  • documento:data definisce la data del documento che, per le fatture emesse, è la data della fattura.

  • documento:datainizio che in presenza di documenti che coprono un arco temporale come i registri indicano la data di inizio del documento.

  • documento:datatermine sempre per i documenti che coprono un arco temporale indica la data di termine del documento.

9

la tag registro specifica il registro di archiviazione del documento che si può ricavare dai metadati precedenti secondo questa sintassi:
urn:entaksi:<id-fiscale-produttore>:<unità-organizzativa>:reg:<anno>:<tipo-documento>:<sezionale>
Se l’azienda ha più unità organizzative (il che corrisponde anche alla registrazione di più entità azienda diverse nel sistema), il codice dell’unità organizzativa va indicato nel registro. Altrimenti in questa posizione verrà indicato _default.

10

Una o più tag file consentono di dichiarare i file che devono essere archiviati nell’unità documentaria. In questo esempio c’è un solo file.

11

Ciascun file va dichiarato con due o tre metadati Dublin Core che sono i seguenti:

  • terms:title deve contenere il nome del file così com’è all’interno del file zip del pacchetto di versamento

  • terms:format deve riportare il mime type del file. Per i documenti PDF il mime type è application/pdf.

Se il file è firmato in modalità CaDES e quindi ha estensione .pdf.p7m deve essere riportato anche il seguente termine:

  • <terms:medium>application/pkcs7-mime</terms:medium>.

Il termine terms:format rimane application/pdf.

8.5. Esempio pacchetto D26 Registro riepilogativo Iva

Il pacchetto contiene quattro documenti appartenenti alla tipologia D26, Registro riepilogativo IVA.

<?xml version="1.0" encoding="UTF-8"?>
<pdv xmlns="http://entaksi.eu/schemas/econ/1.0/" xmlns:terms="http://purl.org/dc/terms/">
  <formato>F999</formato> (1)
  <fileGroup> (2)
    <dc> (3)
      <terms:type>Registro riepilogativo Iva</terms:type> (4)
      <terms:subject>LIQUIDAZIONE IVA TIMESTRE 1</terms:subject> (5)
    </dc>
    <metadata key="produttore:idfiscale">IT01234567890</metadata> (6)
    <metadata key="produttore:ragionesociale">Ragione sociale produttore</metadata>

    <metadata key="destinatario:idfiscale">IT01234567890</metadata> (7)
    <metadata key="destinatario:ragionesociale">Ragione sociale destinatario</metadata>

    <metadata key="documento:anno">2015</metadata> (8)
    <metadata key="documento:tipo">D26</metadata>
    <metadata key="documento:data">2015-12-31</metadata>
    <metadata key="documento:datainizio">2015-01-01</metadata>
    <metadata key="documento:datatermine">2015-03-31</metadata>
    <registro>urn:entaksi:IT01234567890:_default:reg:2015:D26:_default</registro> (9)
    <file> (10)
      <dc>
        <terms:title>d000000047_0001_0001.pdf</terms:title> (11)
        <terms:format>application/pdf</terms:format>
      </dc>
    </file>
  </fileGroup>
  <fileGroup> (12)
    <dc>
      <terms:type>Registro riepilogativo Iva</terms:type> (13)
      <terms:subject>LIQUIDAZIONE IVA TIMESTRE 2</terms:subject>
    </dc>
    <metadata key="produttore:idfiscale">IT01234567890</metadata> (14)
    <metadata key="produttore:ragionesociale">Ragione sociale produttore</metadata>

    <metadata key="destinatario:idfiscale">IT01234567890</metadata> (15)
    <metadata key="destinatario:ragionesociale">Ragione sociale destinatario</metadata>

    <metadata key="documento:anno">2015</metadata> (16)
    <metadata key="documento:tipo">D26</metadata>
    <metadata key="documento:data">2015-12-31</metadata>
    <metadata key="documento:datainizio">2015-04-01</metadata>
    <metadata key="documento:datatermine">2015-06-30</metadata>
    <registro>urn:entaksi:IT01234567890:_default:reg:2015:D26:_default</registro> (17)
    <file> (18)
      <dc>
        <terms:title>d000000048_0001_0001.pdf</terms:title> (19)
        <terms:format>application/pdf</terms:format>
      </dc>
    </file>
  </fileGroup>
  <fileGroup>
    <dc>
      <terms:type>Registro riepilogativo Iva</terms:type> (20)
      <terms:subject>LIQUIDAZIONE IVA TIMESTRE 3</terms:subject>
    </dc>
    <metadata key="produttore:idfiscale">IT01234567890</metadata>
    <metadata key="produttore:ragionesociale">Ragione sociale produttore</metadata>

    <metadata key="destinatario:idfiscale">IT01234567890</metadata>
    <metadata key="destinatario:ragionesociale">Ragione sociale destinatario</metadata>

    <metadata key="documento:anno">2015</metadata>
    <metadata key="documento:tipo">D26</metadata>
    <metadata key="documento:data">2015-12-31</metadata>
    <metadata key="documento:datainizio">2015-07-01</metadata>
    <metadata key="documento:datatermine">2015-09-30</metadata>
    <registro>urn:entaksi:IT01234567890:_default:reg:2015:D26:_default</registro>
    <file>
      <dc>
        <terms:title>d000000049_0001_0001.pdf</terms:title>
        <terms:format>application/pdf</terms:format>
      </dc>
    </file>
  </fileGroup>
  <fileGroup>
    <dc>
      <terms:type>Registro riepilogativo Iva</terms:type>
      <terms:subject>LIQUIDAZIONE IVA TIMESTRE 4</terms:subject>
    </dc>
    <metadata key="produttore:idfiscale">IT01234567890</metadata>
    <metadata key="produttore:ragionesociale">Ragione sociale produttore</metadata>
    <metadata key="destinatario:idfiscale">IT01234567890</metadata>
    <metadata key="destinatario:ragionesociale">Ragione sociale destinatario</metadata>
    <metadata key="documento:anno">2015</metadata>
    <metadata key="documento:tipo">D26</metadata>
    <metadata key="documento:data">2015-12-31</metadata>
    <metadata key="documento:datainizio">2015-10-01</metadata>
    <metadata key="documento:datatermine">2015-12-31</metadata>
    <registro>urn:entaksi:IT01234567890:_default:reg:2015:D26:_default</registro>
    <file>
      <dc>
        <terms:title>d000000050_0001_0001.pdf</terms:title>
        <terms:format>application/pdf</terms:format>
      </dc>
    </file>
  </fileGroup>
</pdv>
Metadato Descrizione

1

Il formato F999 indica che si tratta di un pacchetto con indice.
Si tratta di una informazione interna che serve per la validazione del pacchetto.

2

Il file è composto da una sequenza di una o più tag fileGroup ognuna delle quali rappresenta una unità documentaria (ovvero un documento) inviato in conservazione. La tag si chiama fileGroup perché può contenere più di un file, dove il primo file è il file principale relativo al documento vero e proprio, mentre i file successivi sono annessi o allegati al file.
Nella maggior parte dei casi ci sarà un solo file, ma è possibile, ad esempio, archiviare la scansione della ricevuta di ritorno della raccomandata con cui è stata inviata la fattura. Questa scansione verrebbe archiviata come secondo file, cioè come annesso al documento e insieme ad esso costituisce un’unica unità documentaria.

3

I metadati dell’unità documentaria sono indicati mediante un gruppo di tag con namespace terms che si trovano all’interno della tag dc e una serie di tag metadata che hanno un attributo key e un valore.
I metadati dc sono i metadati Dublin Core, uno standard internazionale per la classificazione dei documenti in base a criteri archivistici. I metadati metadata sono altri metadati relativi ai criteri gestionali.

4

Il termine Dublin Core terms:type contiene una descrizione comprensibile per l’utente del tipo di documento archiviato. In questo caso corrisponde a "Registro riepilogativo IVA".

5

Il termine Dublin Core terms:subject contiene una descrizione del documento archiviato. In questo caso si è indicato semplicemente "LIQUIDAZIONE IVA TIMESTRE 1". Il pacchetto è composto da 5 file, con numerazione crescente nella descrizione.

6

Le tag metadata consentono di indicare una vasta varietà di metadati per l’archiviazione dei documenti. In questo esempio sono riportati solo quelli obbligatori a norma di legge. I primi tre metadati identificano il produttore, dichiarando con la chiave produttore:idfiscale l’identificativo fiscale (composto dal codice paese, IT per Italia, e dalla partita IVA), e con produttore:nome e produttore:cognome il nome e il cognome di colui che versa il documento nel sistema di conservazione.

7

In modo del tutto analogo i tre tag metadata con chiavi uguali a destinatario:idfiscale, destinatario:nome e destinatario:cognome, indicano i dati del destinatario della fattura, ovvero il cliente (in termini fiscali il cessionario di beni o il committente di servizi).

8

Le tag metadata con la chiave che ha come prefisso documento: definiscono i dati che servono per identificare e posizionare il documento nell’archivio.

  • documento:anno deve coincidere con l’anno indicato in documento:data.

  • documento:tipo è il codice del tipo di documento. I registri fatture acquisto hanno codice D15.

  • documento:data definisce la data del documento che, per le fatture emesse, è la data della fattura.

  • documento:datainizio che in presenza di documenti che coprono un arco temporale come i registri indicano la data di inizio del documento.

  • documento:datatermine sempre per i documenti che coprono un arco temporale indica la data di termine del documento.

9

la tag registro specifica il registro di archiviazione del documento che si può ricavare dai metadati precedenti secondo questa sintassi:
urn:entaksi:<id-fiscale-produttore>:<unità-organizzativa>:reg:<anno>:<tipo-documento>:<sezionale>
Se l’azienda ha più unità organizzative (il che corrisponde anche alla registrazione di più entità azienda diverse nel sistema), il codice dell’unità organizzativa va indicato nel registro. Altrimenti in questa posizione verrà indicato _default.

10

Una o più tag file consentono di dichiarare i file che devono essere archiviati nell’unità documentaria. In questo esempio ci sono cinque file.

11

Ciascun file va dichiarato con due o tre metadati Dublin Core che sono i seguenti:

  • terms:title deve contenere il nome del file così com’è all’interno del file zip del pacchetto di versamento

  • terms:format deve riportare il mime type del file. Per i documenti PDF il mime type è application/pdf.

Se il file è firmato in modalità CaDES e quindi ha estensione .pdf.p7m deve essere riportato anche il seguente termine:

  • <terms:medium>application/pkcs7-mime</terms:medium>.

Il termine terms:format rimane application/pdf.

12

Nel secondo fileGroup dell’esempio viene dichiarato una secondo registro registro riepilogativo IVA. Il Pacchetto di Versamento può contenere un numero arbitrario di fileGroup, nei limiti in cui il file pdv.xml e il file ZIP mantengono delle dimensioni ragionevoli per essere elaborati.
Mediamente non dovrebbero esserci più di 100 documenti.

14

Come sopra è indicato come terms:type "Registro riepilogativo IVA".

15

Il produttore è sempre l’azienda che sta versando i documenti in conservazione.

16

Destinatario del registro.

18

Il sezionale o serie archivistica consente di archiviare i documenti dello stesso tipo in registri diversi. In questo caso il sezionale non ha niente a che fare con il sezionale della fattura, ma può essere usato per dividere le fatture secondo un criterio scelto dal produttore. Ad esempio potrebbe essere definito un sezionale per ogni cliente, oppure per categoria commerciale. Indicando _default le fatture vengono archiviate tutte nello stesso registro di default.
Notare che per le fatture ricevute non deve essere indicato il metadato documento:numero. Le fatture ricevute vengono numerate automaticamente dal sistema con un progressivo di archiviazione.

19

Il registro di archiviazione si compone come nel caso delle fatture trasmesse.

8.6. Esempio pacchetto D58 Altri registri

Il pacchetto contiene un documento appartenente alla tipologia D58, Altri registri. Questa tipologia raggruppa altre tipologie di registro non censite (in questo caso un libro unico del lavoro). I metadati per questa tipologia, esclusi quelli obbligatori, sono concordati con il produttore.

<?xml version="1.0" encoding="UTF-8"?>
<pdv xmlns="http://entaksi.eu/schemas/econ/1.0/" xmlns:terms="http://purl.org/dc/terms/">
  <formato>F999</formato> (1)
  <fileGroup> (2)
    <dc> (3)
      <terms:type>Altri registri</terms:type> (4)
      <terms:subject>libro unico del lavoro agosto 2016</terms:subject> (5)
    </dc>
    <metadata key="produttore:idfiscale">IT01234567890</metadata> (6)
    <metadata key="produttore:ragionesociale">Ragione sociale produttore</metadata>
    <metadata key="destinatario:idfiscale">IT01234567891</metadata> (7)
    <metadata key="destinatario:ragionesociale">Ragione sociale destinatario</metadata>
    <metadata key="documento:anno">2016</metadata> (8)
    <metadata key="documento:tipo">D58</metadata>
    <metadata key="documento:data">2016-09-26</metadata>
    <registro>urn:entaksi:IT01234567890:_default:reg:2016:D58:_default</registro> (9)
    <file> (10)
      <dc> (11)
        <terms:title>d000000011_0001_0001.pdf</terms:title>
        <terms:format>application/pdf</terms:format>
      </dc>
    </file>
  </fileGroup>
</pdv>
Metadato Descrizione

1

Il formato F999 indica che si tratta di un pacchetto con indice.
Si tratta di una informazione interna che serve per la validazione del pacchetto.

2

Il file è composto da una sequenza di una o più tag fileGroup ognuna delle quali rappresenta una unità documentaria (ovvero un documento) inviato in conservazione. La tag si chiama fileGroup perché può contenere più di un file, dove il primo file è il file principale relativo al documento vero e proprio, mentre i file successivi sono annessi o allegati al file.
Nella maggior parte dei casi ci sarà un solo file, ma è possibile, ad esempio, archiviare la scansione della ricevuta di ritorno della raccomandata con cui è stata inviata la fattura. Questa scansione verrebbe archiviata come secondo file, cioè come annesso al documento e insieme ad esso costituisce un’unica unità documentaria.

3

I metadati dell’unità documentaria sono indicati mediante un gruppo di tag con namespace terms che si trovano all’interno della tag dc e una serie di tag metadata che hanno un attributo key e un valore.
I metadati dc sono i metadati Dublin Core, uno standard internazionale per la classificazione dei documenti in base a criteri archivistici. I metadati metadata sono altri metadati relativi ai criteri gestionali.

4

Il termine Dublin Core terms:type contiene una descrizione comprensibile per l’utente del tipo di documento archiviato. In questo caso corrisponde a "Altri registri".

5

Il termine Dublin Core terms:subject contiene una descrizione del documento archiviato. In questo caso è indicato "libro unico del lavoro agosto 2016", una tipologia di registro non censita altrimenti.

6

Le tag metadata consentono di indicare una vasta varietà di metadati per l’archiviazione dei documenti. In questo esempio sono riportati solo quelli obbligatori a norma di legge. I primi tre metadati identificano il produttore, dichiarando con la chiave produttore:idfiscale l’identificativo fiscale (composto dal codice paese, IT per Italia, e dalla partita IVA), e con produttore:nome e produttore:cognome il nome e il cognome di colui che versa il documento nel sistema di conservazione. Nel caso il produttore sia una persona giuridica, come in questo caso può essere indicato produttore:ragionesociale.

7

In modo del tutto analogo i tre tag metadata con chiavi uguali a destinatario:idfiscale, destinatario:nome e destinatario:cognome, indicano i dati del destinatario della fattura, ovvero il cliente (in termini fiscali il cessionario di beni o il committente di servizi). Nel caso il destinatario sia una persona giuridica, come in questo caso può essere indicato destinatario:ragionesociale.

8

Le tag metadata con la chiave che ha come prefisso documento: definiscono i dati che servono per identificare e posizionare il documento nell’archivio.

  • documento:anno deve coincidere con l’anno indicato in documento:data.

  • documento:tipo è il codice del tipo di documento. I registri fatture acquisto hanno codice D15.

  • documento:data definisce la data del documento che, per le fatture emesse, è la data della fattura.

  • documento:datainizio che in presenza di documenti che coprono un arco temporale come i registri indicano la data di inizio del documento.

  • documento:datatermine sempre per i documenti che coprono un arco temporale indica la data di termine del documento.

9

la tag registro specifica il registro di archiviazione del documento che si può ricavare dai metadati precedenti secondo questa sintassi:
urn:entaksi:<id-fiscale-produttore>:<unità-organizzativa>:reg:<anno>:<tipo-documento>:<sezionale>
Se l’azienda ha più unità organizzative (il che corrisponde anche alla registrazione di più entità azienda diverse nel sistema), il codice dell’unità organizzativa va indicato nel registro. Altrimenti in questa posizione verrà indicato _default.

10

Una o più tag file consentono di dichiarare i file che devono essere archiviati nell’unità documentaria. In questo esempio c’è un solo file.

11

Ciascun file va dichiarato con due o tre metadati Dublin Core che sono i seguenti:

  • terms:title deve contenere il nome del file così com’è all’interno del file zip del pacchetto di versamento

  • terms:format deve riportare il mime type del file. Per i documenti PDF il mime type è application/pdf.

Se il file è firmato in modalità CaDES e quindi ha estensione .pdf.p7m deve essere riportato anche il seguente termine:

  • <terms:medium>application/pkcs7-mime</terms:medium>.

Il termine terms:format rimane application/pdf.

8.7. Esempio pacchetto D85 Altri documenti

Il pacchetto contiene un documento appartenente alla tipologia D85, Altri documenti. Questa tipologia raggruppa altre tipologie di documento non censite (in questo caso un bilancio di verifica). I metadati per questa tipologia, esclusi quelli obbligatori, sono concordati con il produttore.

<?xml version="1.0" encoding="UTF-8"?>
<pdv xmlns="http://entaksi.eu/schemas/econ/1.0/" xmlns:terms="http://purl.org/dc/terms/">
  <formato>F997</formato> (1)
    <fileGroup> (2)
      <dc> (3)
        <terms:type>Altri documenti</terms:type> (4)
        <terms:subject>Bilancio di verifica dal 01/01/15 al 31/12/15</terms:subject> (5)
      </dc>
      <metadata key="produttore:idfiscale">IT01234567890</metadata> (6)
      <metadata key="produttore:nome">Nome produttore</metadata>
      <metadata key="produttore:cognome">Cognome produttore</metadata>

      <metadata key="destinatario:idfiscale">IT01234567891</metadata> (7)
      <metadata key="destinatario:nome">Nome destinatario</metadata>
      <metadata key="destinatario:cognome">Cognome destinatario</metadata>

      <metadata key="documento:anno">2015</metadata> (8)
      <metadata key="documento:tipo">D85</metadata>
      <metadata key="documento:data">2015-12-31</metadata>
      <registro>urn:entaksi:IT01234567890:_default:reg:2015:D85:_default</registro> (9)
      <terms:format>analogico</terms:format> (10)
      <file> (11)
        <dc>
          <terms:title>d000000052_0001_0001.pdf</terms:title> (12)
          <terms:format>application/pdf</terms:format>
        </dc>
      </file>
    </fileGroup>
</pdv>
Metadato Descrizione

1

Il formato F997 indica che si tratta di un pacchetto copia digitale di documento analogico.
Il documento è dichiarato analogico (v. punto 10), pertanto il sistema provvede alla conversione in PDF/A e alla successiva validazione con firma digitale in presenza di delega per il Responsabile della Conservazione.
Si tratta di una informazione interna che serve per la validazione del pacchetto.

2

Il file è composto da una sequenza di una o più tag fileGroup ognuna delle quali rappresenta una unità documentaria (ovvero un documento) inviato in conservazione. La tag si chiama fileGroup perché può contenere più di un file, dove il primo file è il file principale relativo al documento vero e proprio, mentre i file successivi sono annessi o allegati al file.
Nella maggior parte dei casi ci sarà un solo file, ma è possibile, ad esempio, archiviare la scansione della ricevuta di ritorno della raccomandata con cui è stata inviata la fattura. Questa scansione verrebbe archiviata come secondo file, cioè come annesso al documento e insieme ad esso costituisce un’unica unità documentaria.

3

I metadati dell’unità documentaria sono indicati mediante un gruppo di tag con namespace terms che si trovano all’interno della tag dc e una serie di tag metadata che hanno un attributo key e un valore.
I metadati dc sono i metadati Dublin Core, uno standard internazionale per la classificazione dei documenti in base a criteri archivistici. I metadati metadata sono altri metadati relativi ai criteri gestionali.

4

Il termine Dublin Core terms:type contiene una descrizione comprensibile per l’utente del tipo di documento archiviato. In questo caso corrisponde a "Altri documenti".

5

Il termine Dublin Core terms:subject contiene una descrizione del documento archiviato. In questo caso è indicato "Bilancio di verifica dal 01/01/15 al 31/12/15", una tipologia di registro non censita altrimenti.

6

Le tag metadata consentono di indicare una vasta varietà di metadati per l’archiviazione dei documenti. In questo esempio sono riportati solo quelli obbligatori a norma di legge. I primi tre metadati identificano il produttore, dichiarando con la chiave produttore:idfiscale l’identificativo fiscale (composto dal codice paese, IT per Italia, e dalla partita IVA), e con produttore:nome e produttore:cognome il nome e il cognome di colui che versa il documento nel sistema di conservazione.

7

In modo del tutto analogo i tre tag metadata con chiavi uguali a destinatario:idfiscale, destinatario:nome e destinatario:cognome, indicano i dati del destinatario della fattura, ovvero il cliente (in termini fiscali il cessionario di beni o il committente di servizi).

8

Le tag metadata con la chiave che ha come prefisso documento: definiscono i dati che servono per identificare e posizionare il documento nell’archivio.

  • documento:anno deve coincidere con l’anno indicato in documento:data.

  • documento:tipo è il codice del tipo di documento. I registri fatture acquisto hanno codice D15.

  • documento:data definisce la data del documento che, per le fatture emesse, è la data della fattura.

  • documento:datainizio che in presenza di documenti che coprono un arco temporale come i registri indicano la data di inizio del documento.

  • documento:datatermine sempre per i documenti che coprono un arco temporale indica la data di termine del documento.

9

la tag registro specifica il registro di archiviazione del documento che si può ricavare dai metadati precedenti secondo questa sintassi:
urn:entaksi:<id-fiscale-produttore>:<unità-organizzativa>:reg:<anno>:<tipo-documento>:<sezionale>
Se l’azienda ha più unità organizzative (il che corrisponde anche alla registrazione di più entità azienda diverse nel sistema), il codice dell’unità organizzativa va indicato nel registro. Altrimenti in questa posizione verrà indicato _default.

10

Il metadato a livello di fileGroup terms:format con valore "analogico" indica che il documento trattato era precedentemente analogico, ed è stata effettuata la sua conversione in PDF/A ed è stata apposta la firma digitale in fase di creazione del pacchetto.

11

Una o più tag file consentono di dichiarare i file che devono essere archiviati nell’unità documentaria. In questo esempio c’è un solo file.

12

Ciascun file va dichiarato con due o tre metadati Dublin Core che sono i seguenti:

  • terms:title deve contenere il nome del file così com’è all’interno del file zip del pacchetto di versamento

  • terms:format deve riportare il mime type del file. Per i documenti PDF il mime type è application/pdf.

8.8. Esempio pacchetto D58 Cedolini

Con il prefisso D58 possono essere individuate delle tipologie documentali particolari, non censite in altre categorie. In questo caso la tipologia comprende i cedolini.

<?xml version="1.0" encoding="UTF-8"?>
<pdv xmlns="http://entaksi.eu/schemas/econ/1.0/" xmlns:terms="http://purl.org/dc/terms/"> (1)
  <dataVersamento>2017-12-18T15:15:15+02:00</dataVersamento> (2)
  <formato>F999</formato> (3)
  <fileGroup> (4)
    <dc> (5)
      <terms:type>Cedolino</terms:type> (6)
      <terms:subject>Cedolino ottobre 2017 Mario Rossi</terms:subject> (7)
    </dc>

  <metadata key="produttore:idfiscale">IT01234567890</metadata> (8)
     <metadata key="produttore:nome">Nome produttore</metadata>

    <metadata key="destinatario:codicefiscale">RSSMRA87N70L113F</metadata> (9)
    <metadata key="destinatario:nome">Nome destinatario</metadata>

    <metadata key="documento:anno">2017</metadata> (10)
    <metadata key="documento:tipo">D58</metadata>
    <metadata key="documento:sezionale">lul</metadata>
    <metadata key="documento:data">2017-10-27</metadata>
    <metadata key="documento:datainizio">2017-10-01</metadata>
    <metadata key="documento:datatermine">2017-10-31</metadata>

    <metadata key="_extra:tipologia">Dipendente</metadata> (11)
    <metadata key="_extra:ccosto">1204040</metadata>
    <metadata key="_extra:matricola">6160056</metadata>
    <metadata key="_extra:livello">2</metadata>
    <metadata key="_extra:qualifica">6</metadata>
    <metadata key="_extra:stabilimento">11</metadata>

    <registro>urn:entaksi:IT01234567891:_default:reg:2017:D58:lul</registro> (12)

    <file>
      <dc>
        <terms:title>DATA/201710/IT01234567891.PDF</terms:title> (13)
        <terms:format>application/pdf</terms:format> (14)
      </dc>
    </file>
  </fileGroup>
  <fileGroup>
    ...
  </fileGroup>
</pdv>
Metadato Descrizione

1

Dichiarazioni dei namespace XML come indicato nel manuale

2

La data del versamento (opzionale, viene impostata dal sistema durante la validazione e riportata nel rapporto di versamento)

3

Formato del pacchetto di versamento. Impostare a F999.

4

Gruppo di file relativo al documento “Cedolino”. Il gruppo è composto da un solo file che è il PDF del cedolino

5

Gruppo di metadati Dublin Core relativo al documento Cedolino

6

Impostare terms:type a Cedolino

7

Contenuto del documento. Per i cedolini impostare a Cedolino <mese> <anno> <nome dipendente>. Se si tratta di una tredicesima, quattordicesima o altro indicare “tredicesima”, “quattordicesima”, ecc al posto di “mese”.

8

Il soggetto produttore è l’azienda datore di lavoro indicata con identificativo fiscale e ragione sociale.

9

Il soggetto destinatario è il dipendente indicato con codice fiscale e nome. Se il nome e cognome sono disponibili separatamente indicare il nome in destinatario:nome e il cognome in destinatario:cognome, altrimenti tutti insieme in destinatario:nome.

10

Dati del documento. Indicare l’anno di emissione del cedolino (cioè quello relativo alla mensilità) in documento:anno.
documento:tipo è sempre uguale a D58, documento:sezionale è sempre uguale a lul, documento:data contiene la data di emissione del cedolino in formato yyyy-MM-dd.
Il periodo va rappresentato mediante i due valori documento:datainizio e documento:datatermine che riportano, rispettivamente il primo e l’ultimo giorno del mese a cui si riferisce il cedolino.

11

Informazioni addizionali per la pubblicazione.

12

Registro di archiviazione. È un URI composto dalle seguenti parti tutte già descritte nelle tag precedenti: urn:entaksi:<idfiscale-produttore>:<unità organizzativa>:reg:<anno>:<tipo documento>:<sezionale>.

13

Nome del file (relativo alla posizione del file pdv.xml).

14

Mime type del file (application/pdf per i file PDF).

8.9. Esempio pacchetto D58 Cartellino presenze

Con il prefisso D58 possono essere individuate delle tipologie documentali particolari, non censite in altre categorie. In questo caso la tipologia comprende i cartellini presenze.

  <fileGroup> (1)
    <dc>
      <terms:type>Cartellino presenze</terms:type> (2)
      <terms:subject>Cartellino presenze ottobre 2017 Mario Rossi</terms:subject> (3)
    </dc>
    <metadata key="produttore:idfiscale">IT01234567891</metadata> (4)
    <metadata key="produttore:ragionesociale">Nome produttore</metadata>

    <metadata key="destinatario:codicefiscale">RSSMRA87N70L113F</metadata> (9)
    <metadata key="destinatario:nome">Nome destinatario</metadata>

    <metadata key="documento:anno">2017</metadata> (6)
    <metadata key="documento:tipo">D58</metadata>
    <metadata key="documento:sezionale">lul</metadata>
    <metadata key="documento:data">2017-10-27</metadata>
    <metadata key="documento:datainizio">2017-10-01</metadata>
    <metadata key="documento:datatermine">2017-10-31</metadata>

    <metadata key="_extra:tipologia">Dipendente</metadata> (7)
    <metadata key="_extra:ccosto">1204040</metadata>
    <metadata key="_extra:matricola">6160056</metadata>
    <metadata key="_extra:livello">2</metadata>
    <metadata key="_extra:qualifica">6</metadata>
    <metadata key="_extra:stabilimento">11</metadata>

    <registro>urn:entaksi:IT01234567891:_default:reg:2017:D58:lul</registro> (8)

    <file>
      <dc>
        <terms:title>DATA/201710PR/IT01234567891.PDF</terms:title> (9)
        <terms:format>application/pdf</terms:format>
      </dc>
    </file>
  </fileGroup>
Metadato Descrizione

1

Gruppo di file relativo al documento “Cartellino presenze”. Il gruppo è composto da un solo file che è il PDF del cartellino presenze.

2

Impostare terms:type a Cartellino presenze.

3

Contenuto del documento. Per i cedolini impostare a Cartellino presenze <mese> <anno> <nome dipendente>.

4

Il soggetto produttore è l’azienda datore di lavoro indicata con identificativo fiscale e ragione sociale.

5

Il soggetto destinatario è il dipendente indicato con codice fiscale e nome. Se il nome e cognome sono disponibili separatamente indicare il nome in destinatario:nome e il cognome in destinatario:cognome, altrimenti tutti insieme in destinatario:nome.

6

Dati del documento. Indicare l’anno di emissione del cartellino presenze (cioè quello relativo alla mensilità) in documento:anno.
documento:tipo è sempre uguale a D58, documento:sezionale è sempre uguale a lul, documento:data contiene la data di emissione del cedolino in formato yyyy-MM-dd.
Il periodo va rappresentato mediante i due valori documento:datainizio e documento:datatermine che riportano, rispettivamente il primo e l’ultimo giorno del mese a cui si riferisce il cartellino presenze.

7

Informazioni addizionali per la pubblicazione.

8

Registro di archiviazione. È un URI composto dalle seguenti parti tutte già descritte nelle tag precedenti: urn:entaksi:<idfiscale-produttore>:<unità organizzativa>:reg:<anno>:<tipo documento>:<sezionale>.

9

Nome del file (relativo alla posizione del file pdv.xml)

8.10. Esempio pacchetto D58 Elenco dipendenti

Con il prefisso D58 possono essere individuate delle tipologie documentali particolari, non censite in altre categorie. In questo caso la tipologia comprende l’elenco dipendenti.

  <fileGroup> (1)
    <dc>
      <terms:type>Elenco dipendenti</terms:type> (2)
      <terms:subject>Elenco dipendenti ottobre 2017</terms:subject> (3)
    </dc>
    <metadata key="produttore:idfiscale">IT01234567891</metadata> (4)
    <metadata key="produttore:ragionesociale">Ragione sociale produttore</metadata>

    <metadata key="destinatario:idfiscale">IT01234567891</metadata> (5)
    <metadata key="destinatario:ragionesociale">Ragione sociale produttore</metadata>

    <metadata key="documento:anno">2017</metadata> (6)
    <metadata key="documento:tipo">D58</metadata>
    <metadata key="documento:sezionale">lul</metadata>
    <metadata key="documento:data">2017-10-27</metadata>
    <metadata key="documento:datainizio">2017-10-01</metadata>
    <metadata key="documento:datatermine">2017-10-31</metadata>

    <registro>urn:entaksi:IT01234567891:_default:reg:2017:D58:lul</registro> (7)

    <file>
      <dc>
        <terms:title>DATA/STAMPE/Elenco_Dip_201710_INF.PDF</terms:title> (8)
        <terms:format>application/pdf</terms:format>
      </dc>
    </file>
  </fileGroup>
Metadato Descrizione

1

Gruppo di file relativo al documento “Elenco dipendenti”. Il gruppo è composto da un solo file che è il PDF contenente l’elenco dei dipendenti.

2

Impostare terms:type a Elenco dipendenti.

3

Contenuto del documento. Per i cedolini impostare a Elenco dipendenti <mese> <anno>.

4

Il soggetto produttore è l’azienda datore di lavoro indicata con identificativo fiscale e ragione sociale.

5

Utilizzare come soggetto destinatario le stesse informazioni del soggetto produttore.

6

Dati del documento. Indicare l’anno di emissione del cartellino presenze (cioè quello relativo alla mensilità) in documento:anno.
documento:tipo è sempre uguale a D58, documento:sezionale è sempre uguale a lul, documento:data contiene la data di emissione del cedolino in formato yyyy-MM-dd.
Il periodo va rappresentato mediante i due valori documento:datainizio e documento:datatermine che riportano, rispettivamente il primo e l’ultimo giorno del mese a cui si riferisce l’elenco dipendenti.

7

Registro di archiviazione. È un URI composto dalle seguenti parti tutte già descritte nelle tag precedenti: urn:entaksi:<idfiscale-produttore>:<unità organizzativa>:reg:<anno>:<tipo documento>:<sezionale>.

8

Nome del file (relativo alla posizione del file pdv.xml).

8.11. Esempio pacchetto D58 Riepilogo LUL

Con il prefisso D58 possono essere individuate delle tipologie documentali particolari, non censite in altre categorie. In questo caso la tipologia comprende il riepilogo LUL.

  <fileGroup> (1)
    <dc>
      <terms:type>Riepilogo LUL</terms:type> (2)
      <terms:subject>Riepilogo LUL ottobre 2017</terms:subject> (3)
    </dc>
    <metadata key="produttore:idfiscale">IT01234567891</metadata> (4)
    <metadata key="produttore:ragionesociale">Ragione sociale produttore</metadata>

    <metadata key="destinatario:idfiscale">IT01234567891</metadata> (5)
    <metadata key="destinatario:ragionesociale">Ragione sociale produttore</metadata>

    <metadata key="documento:anno">2017</metadata> (6)
    <metadata key="documento:tipo">D58</metadata>
    <metadata key="documento:sezionale">lul</metadata>
    <metadata key="documento:data">2017-10-27</metadata>
    <metadata key="documento:datainizio">2017-10-01</metadata>
    <metadata key="documento:datatermine">2017-10-31</metadata>

    <registro>urn:entaksi:IT01234567891:_default:reg:2017:D58:lul</registro> (7)

    <file>
      <dc>
        <terms:title>DATA/STAMPE/DatiLul_201710_INF.PDF</terms:title> (8)
        <terms:format>application/pdf</terms:format>
      </dc>
    </file>
  </fileGroup>
Metadato Descrizione

1

Gruppo di file relativo al documento “Riepilogo LUL”. Il gruppo è composto da un solo file che è il PDF contenente il riepilogo del LUL.

2

Impostare terms:type a Riepilogo LUL.

3

Contenuto del documento. Per i cedolini impostare a Riepilogo LUL <mese> <anno>.

4

Il soggetto produttore è l’azienda datore di lavoro indicata con identificativo fiscale e ragione sociale

5

Utilizzare come soggetto destinatario le stesse informazioni del soggetto produttore.

6

Dati del documento. Indicare l’anno di emissione del cartellino presenze (cioè quello relativo alla mensilità) in documento:anno.
documento:tipo è sempre uguale a D58, documento:sezionale è sempre uguale a lul, documento:data contiene la data di emissione del cedolino in formato yyyy-MM-dd.
Il periodo va rappresentato mediante i due valori documento:datainizio e documento:datatermine che riportano, rispettivamente il primo e l’ultimo giorno del mese a cui si riferisce l’elenco dipendenti.

8.12. Esempio pacchetto D58 Indice LUL

Con il prefisso D58 possono essere individuate delle tipologie documentali particolari, non censite in altre categorie. In questo caso la tipologia comprende l’indice LUL.

  <fileGroup> (1)
    <dc>
      <terms:type>Indice LUL</terms:type> (2)
      <terms:subject>Indice LUL ottobre 2017</terms:subject> (3)
      <terms:date>2017-11-22T15:15:15+02:00</terms:date> (4)
    </dc>
    <metadata key="produttore:idfiscale">IT01234567891</metadata> (5)
    <metadata key="produttore:ragionesociale">Ragione sociale produttore</metadata>

    <metadata key="destinatario:idfiscale">IT01234567891</metadata> (6)
    <metadata key="destinatario:ragionesociale">Ragione sociale produttore</metadata>

    <metadata key="documento:anno">2017</metadata> (7)
    <metadata key="documento:tipo">D58</metadata>
    <metadata key="documento:sezionale">lul</metadata>
    <metadata key="documento:data">2017-10-27</metadata>
    <metadata key="documento:datainizio">2017-10-01</metadata>
    <metadata key="documento:datatermine">2017-10-31</metadata>

    <registro>urn:entaksi:IT01234567891:_default:reg:2017:D58:lul</registro> (8)

    <file>
      <dc>
        <terms:title>DATA/MARCHE/Sincro_Indice_201710_Div1_INF.xml.p7m.m7m</terms:title> (9)
        <terms:medium>application/pkcs7-mime</terms:medium> (10)
        <terms:format>text/xml</terms:format> (11)
      </dc>
    </file>
    <file>
      <dc>
        <terms:title>DATA/MARCHE/Sincro_Indice_201710_Div1_INF.xml.p7m</terms:title> (12)
        <terms:medium>application/pkcs7-mime</terms:medium>
        <terms:format>text/xml</terms:format>
      </dc>
    </file>
    <file>
      <dc>
        <terms:title>DATA/MARCHE/Sincro_Indice_201710_Div1_INF.xml</terms:title> (13)
        <terms:format>text/xml</terms:format>
      </dc>
    </file>
  </fileGroup>
Metadato Descrizione

1

Gruppo di file relativo al documento “Indice LUL”. Il gruppo è composto da tre file, il primo dei quali è il file con firma e marca digitale (p7m.m7m). Gli altri due (opzionali) sono il file XML prima della firma e il file PDF contenente il riepilogo delle firme. I file successivi al primo sono archiviati come annessi.

2

Impostare terms:type a Indice LUL.

3

Contenuto del documento. Per i cedolini impostare a Indice LUL <mese> <anno>.

4

Se disponibile, indicare la data della marca temporale in terms:date (opzionale).

5

Il soggetto produttore è l’azienda datore di lavoro indicata con identificativo fiscale e ragione sociale

6

Utilizzare come soggetto destinatario le stesse informazioni del soggetto produttore.

7

Dati del documento. Indicare l’anno di emissione del cartellino presenze (cioè quello relativo alla mensilità) in documento:anno. documento:tipo è sempre uguale a D58, documento:sezionale è sempre uguale a lul, documento:data contiene la data di emissione del cedolino in formato yyyy-MM-dd.
Il periodo va rappresentato mediante i due valori documento:datainizio e documento:datatermine che riportano, rispettivamente il primo e l’ultimo giorno del mese a cui si riferisce l’elenco dipendenti.

8

Registro di archiviazione. È un URI composto dalle seguenti parti tutte già descritte nelle tag precedenti: urn:entaksi:<idfiscale-produttore>:<unità organizzativa>:reg:<anno>:<tipo documento>:<sezionale>.

9

Nome del file indice (relativo alla posizione del file pdv.xml) firmato e marcato. Il primo file è il file principale del documento.

10

Indicare in terms:medium il mime type del contenitore PCKS#7 application/pkcs7-mime.

11

Indicare in terms:format il mime type del file contenuto text/xml.

12

Nome del file indice firmato (relativo alla posizione del file pdv.xml) in formato P7M. Opzionale, è considerato un file annesso al file principale.

13

Nome del file indice (relativo alla posizione del file pdv.xml) in formato XML. Opzionale, è considerato un file annesso al file principale.

8.13. Esempio pacchetto D58 Riepilogo documenti firmati

Con il prefisso D58 possono essere individuate delle tipologie documentali particolari, non censite in altre categorie. In questo caso la tipologia comprende il riepilogo dei documenti firmati.

  <fileGroup> (1)
    <dc>
      <terms:type>Riepilogo firme LUL</terms:type> (2)
      <terms:subject>Riepilogo documenti firmati ottobre 2017</terms:subject> (3)
      <terms:date>2017-11-22T15:15:15+02:00</terms:date>
    </dc>
    <metadata key="produttore:idfiscale">IT01234567891</metadata> (4)
    <metadata key="produttore:ragionesociale">Ragione sociale produttore</metadata>

    <metadata key="destinatario:idfiscale">IT01234567891</metadata> (5)
    <metadata key="destinatario:ragionesociale">Ragione sociale produttore</metadata>

    <metadata key="documento:anno">2017</metadata> (6)
    <metadata key="documento:tipo">D58</metadata>
    <metadata key="documento:sezionale">lul</metadata>
    <metadata key="documento:data">2017-10-27</metadata>
    <metadata key="documento:datainizio">2017-10-01</metadata>
    <metadata key="documento:datatermine">2017-10-31</metadata>

    <registro>urn:entaksi:IT01234567891:_default:reg:2017:D58:lul</registro> (7)

    <file>
      <dc>
        <terms:title>DATA/STAMPE/Firma_201710_Marche_INF.PDF</terms:title> (8)
        <terms:format>application/pdf</terms:format>
      </dc>
    </file>
  </fileGroup>
Metadato Descrizione

1

Gruppo di file relativo al documento “Riepilogo firme LUL”. Il gruppo è composto da un file, che è il PDF con il riepilogo dei documenti firmati.

2

Impostare terms:type a Riepilogo firme LUL.

3

Contenuto del documento. Per i cedolini impostare a Riepilogo documenti firmati <mese> <anno>.

4

Il soggetto produttore è l’azienda datore di lavoro indicata con identificativo fiscale e ragione sociale

5

Utilizzare come soggetto destinatario le stesse informazioni del soggetto produttore.

6

Dati del documento. Indicare l’anno di emissione del cartellino presenze (cioè quello relativo alla mensilità) in documento:anno. documento:tipo è sempre uguale a D58, documento:sezionale è sempre uguale a lul, documento:data contiene la data di emissione del cedolino in formato yyyy-MM-dd.
Il periodo va rappresentato mediante i due valori documento:datainizio e documento:datatermine che riportano, rispettivamente il primo e l’ultimo giorno del mese a cui si riferisce l’elenco dipendenti.

7

Registro di archiviazione. È un URI composto dalle seguenti parti tutte già descritte nelle tag precedenti: urn:entaksi:<idfiscale-produttore>:<unità organizzativa>:reg:<anno>:<tipo documento>:<sezionale>.

8

Nome del file con il riepilogo delle firme (relativo alla posizione del file pdv.xml). Opzionale, è considerato un file annesso al file principale.

8.14. Esempio pacchetto D8503 Manuali

Con il prefisso D85 possono essere individuate delle tipologie documentali particolari, in questo caso la tipologia D8503 indica dei documenti interni generici di natura non fiscale.

Il pacchetto può contenere, ad esempio, dei manuali di procedure interne.

<?xml version="1.0" encoding="UTF-8"?>
<pdv xmlns="http://entaksi.eu/schemas/econ/1.0/" xmlns:terms="http://purl.org/dc/terms/">
  <formato>F999</formato> (1)
    <fileGroup> (2)
    <dc> (3)
      <terms:type>Documenti interni</terms:type> (4)
      <terms:subject>IO ISO 20140720 Regolamento interno 1.6.0</terms:subject> (5)
      <terms:format>application/pdf</terms:format> (6)
    </dc>
    <registro>urn:entaksi:IT01234567890:_default:reg:2017:D85DOC:_default</registro> (7)
    <file>
      <dc>
        <terms:title>IO ISO 20140720 Regolamento interno 1.6.0.pdf</terms:title> (8)
        <terms:creator>Entaksi Solutions Srl</terms:creator> (9)
        <terms:date>17/07/2017</terms:date> (10)
      </dc>
    </file>
  </fileGroup>
</pdv>
Metadato Descrizione

1

Il formato F999 indica che si tratta di un pacchetto generico con indice.
Si tratta di una informazione interna che serve per la validazione del pacchetto.

2

Il file è composto da una sequenza di una o più tag fileGroup ognuna delle quali rappresenta una unità documentaria (ovvero un documento) inviato in conservazione. La tag si chiama fileGroup perché può contenere più di un file, dove il primo file è il file principale relativo al documento vero e proprio, mentre i file successivi sono annessi o allegati al file.
Nella maggior parte dei casi ci sarà un solo file, ma è possibile, ad esempio, archiviare la scansione della ricevuta di ritorno della raccomandata con cui è stata inviata la fattura. Questa scansione verrebbe archiviata come secondo file, cioè come annesso al documento e insieme ad esso costituisce un’unica unità documentaria.`

3

I metadati dell’unità documentaria sono indicati mediante un gruppo di tag con namespace terms che si trovano all’interno della tag dc e una serie di tag metadata che hanno un attributo key e un valore. I metadati dc sono i metadati Dublin Core, uno standard internazionale per la classificazione dei documenti in base a criteri archivistici. I metadati metadata sono altri metadati relativi ai criteri gestionali. In questo caso i metadati utilizzati appartengono tutti al gruppo Dublin Core.

4

Il termine Dublin Core terms:type contiene una descrizione comprensibile per l’utente del tipo di documento archiviato. In questo caso indica che il file è di tipo "Documenti interni".

5

Il termine Dublin Core terms:subject contiene una descrizione comprensibile per l’utente del tipo di documento archiviato.
Nel caso dei documenti interni si è scelto di indicare il titolo del documento.

6

Il termine terms:format riporta il mime type del file. Per i documenti PDF il mime type è application/pdf.

7

La tag registro specifica il registro di archiviazione del documento che si può ricavare dai metadati precedenti secondo questa sintassi:
urn:entaksi:<id-fiscale-produttore>:<unità-organizzativa>:reg:<anno>:<tipodocumento>:<sezionale>.

8

Il termine Dublin Core terms:title contiene il nome del file del documento, comprensivo di estensione.

9

Il termine terms:creator indica l’entità che ha provveduto alla creazione del documento.

10

Il termine Dublin Core terms:date indica la data in cui il file è stato firmato digitalmente.

9. Pacchetti di distribuzione

Il Pacchetto di Distribuzione è l’entità con cui i documenti conservati possono essere estratti al fine della distribuzione degli stessi.

In base ai criteri di selezione dei documenti il Pacchetto di Distribuzione viene assemblato dal sistema di conservazione includendo:

  • le unità documentarie all’interno dell’archivio corrispondenti ai criteri di selezione;

  • l’insieme delle prove di conservazione delle unità documentarie selezionate, cioè gli indici firmati dei PDA in cui sono contenute.

Il Pacchetto di Distribuzione viene reso disponibile sotto forma di un file ZIP contenente:

  • un indice di distribuzione firmato digitalmente dal Responsabile del Servizio di Conservazione, che costituisce anche il rapporto di distribuzione

  • le unità documentarie corrispondenti ai criteri di selezione

  • l’insieme delle prove di conservazione

L’utente può effettuare sul sistema una ricerca in base ad un insieme di criteri di selezione. La ricerca produce come risultato un insieme di unità documentarie.

L’utente può poi richiedere la produzione di un Pacchetto di Distribuzione contenente il risultato di questa ricerca. Il risultato di questa operazione è in realtà costituto da uno o più Pacchetti di Distribuzione, nel caso in cui l’insieme dei documenti selezionato sia troppo ampio per rientrare in un solo pacchetto.

I Pacchetti di Distribuzione vengono messi a disposizione per il download esclusivamente da parte dell’utente che li ha richiesti o eventualmente veicolati tramite le modalità definite tra l’utente e il Responsabile del Servizio di Conservazione.

I Pacchetti di Distribuzione rimangono disponibili per il download per un periodo di tempo concordato tra l’utente e il Responsabile del Servizio di Conservazione, prima di essere scartati.

9.1. Stati della richiesta di PDD

Gli stati della richiesta di PDD sono riportati nel paragrafo Tabella dei codici degli stati di una richiesta di PDD.

10. Codice di errore

In caso di errore le API restituiscono un messaggio contenente alcune informazioni sul problema.

Il messaggio ha un formato di questo tipo in XML:

<errore>
  <esito>
    <codice>codice di errore</codice>
    <messaggio>messaggio di errore</messaggio>
  </esito>
</errore>

In JSON:

{
  "codice": "codice di errore",
  "messaggio": "messaggio di errore"
}

Il codice di errore è un numero di tre cifre che può assumere i seguenti valori:

Codice Descrizione

000

Nessun errore

001

Accesso negato

002

Entità non trovata

003

L’utente non ha accesso al rivenditore

004

L’utente non ha accesso al contratto

005

L’utente non ha accesso all’azienda

006

L’utente non ha accesso alla fattura

007

L’utente non ha accesso alla ricevuta

008

L’utente non ha accesso al volume di conservazione

009

L’utente non ha accesso all’utente

010

L’utente non ha accesso alla funzione

011

Valore obbligatorio mancante

012

Valore errato per il parametro

013

Azienda duplicata

014

Azienda disabilitata

015

Fattura duplicata

016

Errore nel formato XML

017

Transizione di stato non consentita

018

Creazione diretta dell’azienda non prevista

019

L’utente ha raggiunto il numero massimo di aziende

020

Nessun file caricato

021

Rapporto di versamento non disponibile

022

File del Pacchetto di Versamento non disponibile

023

Dati mancanti

024

Superata la dimensione massima del file XML

025

Documento con numerazione duplicata non ammesso

026

Modifica dell’identificativo fiscale non consentita

027

Modifica del codice unità organizzativa non consentita

028

Rivenditore duplicato

029

Client non disponibile

030

Modifica del PDD non consentita in questo stato

031

Rimozione dell’utente non consentita

032

Contenuto del PDD non disponibile

033

Formato obsoleto

034

Servizio sospeso

035

Servizio non ancora attivo

036

La fattura contiene errori di validazione

037

L’utente non ha accesso all’archivio dell’azienda

038

Modifica del codice fiscale non consentita

999

Errore interno

Il messaggio di riporta una descrizione più specifica dell’errore inclusi eventuali dati di contesto.

11. Codici

11.1. Stati della fattura

Tabella 3. Stati della fattura
Codice Descrizione Stato

S01

Nuova fattura

Deve essere caricato il contenuto XML

S01

Attesa del caricamento XML

Deve essere caricato il contenuto XML

S02

Attesa della conferma

La fattura è in stato di bozza e attende di essere confermata

S03

Attesa delega

La fattura è in attesa della delega sull’azienda

S04

Attesa firma

La fattura è pronta e in attesa di essere firmata digitalmente

S05

Attesa invio

La fattura è pronta e in attesa di essere inviata allo SDI

S06

Attesa risposta da SDI

La fattura è stata inviata allo SDI ed è in attesa di risposta

S07

Ricevuta notifica decorrenza termini

È stata ricevuta una notifica di decorrenza termini

S08

Ricevuta attestazione di impossibilità di recapito

È stata ricevuta una attestazione di impossibilità di recapito

S09

Fattura accettata

La fattura è stata accettata dal destinatario

S10

Fattura rifiutata

La fattura è stata rifiutata dal destinatario

S11

Fattura scartata

È stata ricevuta una notifica di scarto dallo SDI

S12

Fattura annullata

La fattura è stata annullata dall’utente

S13

In conservazione

La fattura è in conservazione

S14

Invio in corso

L’invio della fattura è in corso

S15

Attesa firma

La fattura è in attesa dalla firma digitale

S16

Pronta per la conservazione

La fattura è pronta per essere messa in conservazione

S17

Fattura ricevuta

La fattura è stata ricevuta dal canale ricezione

S18

Conferma notifica EC

L’invio della notifica EC è in attesa di conferma da parte dell’operatore

S19

Notifica EC confermata

La notifica EC è stata confermata dall’operatore

S20

Attesa firma notifica EC

Attesa firma notifica EC

S21

Notifica EC pronta per l’invio

Notifica EC pronta per l’invio

S22

Invio notifica EC in corso

Invio notifica EC in corso

S23

Notifica EC inviata

La notifica EC è stata inviata correttamente

S24

Notifica EC scartata

La notifica EC è stata scartata perchè non valida

S25

Errore interno

Errore interno durante il processo di avanzamento

S26

Fattura emessa

Valido per le fatture B2B, indica che la fattura è stata consegnata al destinatario o messa a disposizione nell’area riservata del sito dell’AdE

11.2. Esito fattura

Tabella 4. Esito della fattura
Codice Descrizione

E00

File fattura in elaborazione"

E01

File fattura inviato al Sistema di Interscambio.

E02

File fattura consegnato al destinatario (è stata ricevuta una notifica di consegna).

E03

File fattura scartato (è stata ricevuta una notifica di scarto).

E04

Fattura accettata (è stata ricevuta un notifica di esito con accettazione da parte del destinatario).

E05

Fattura rifiutata (è stata ricevuta una notifica di esito con rifiuto da parte del destinatario).

E06

Decorrenza termini (è stata ricevuta una notifica DT, decorrenza termini).

E07

Impossibilità di recapito (è stata ricevuta una notifica AT, attestato di trasmissione).

E08

L’elaborazione della fattura è stata annullata.

E09

Il file fattura è stato eliminato.

E10

Fattura ricevuta.

E11

File fattura non consegnato al destinatario. Valido per le fatture B2B, indica che per la fattura è presente una notifica di mancata consegna. La fattura è disponibile in consultazione nell’area riservata del sito AdE.

11.3. Tabella dei codici di validazione dei PDV

Tabella 5. Codici validazione PDV
Codice Descrizione

E000

Il pacchetto di versamento non contiene allegati.

E001

Il file allegato al pacchetto di versamento non è uno zip.

E002

Il pacchetto di versamento non contiene file.

E003

Impossibile creare le unità documentali.

E004

Impossibile estrarre i metadati sull''unità documentale.

E005

Il file contiene fatture non conformi.

E006

Il file non ha un nome valido.

E007

Il file non è valido.

E008

Il file non può essere verificato.

E009

Il file non è firmato.

E010

Il file non ha una firma valida.

E011

La fattura non contiene il numero di documento.

E012

Il nome del file {0} indicato nella notifica non corrisponde al nome del file del documento principale.

E013

Sono presenti delle notifiche senza la fattura.

E014

L’anno della fattura {0} deve essere uguale a quello delle altre fatture del pacchetto di versamento.

E015

Errore nell''estrazione del zip della notifica AT {0}.

E016

Il pacchetto di versamento non è conforme. {0}

E017

L’unità archivistica {0} non ha indicato il metadato {1}.

E018

Il registro dell''unità archivistica {0} non è corretto. {1}

E019

L''hash del file {0} non è valido.

E020

Il pacchetto di versamento contiene fatture con data successiva alla data di fine delega dell’azienda.

E021

Il metadato {0} dell''unità archivistica {1} non è valido.

E022

L''unità archivistica {0} non è valida. {1}

E023

Errore generico.

E024

Il file {0} non è trasmesso o ricevuto dalla casella PEC {1}.

E025

I messaggi dovrebbero essere tutti dell''anno {0}, ma il file {0} contiene un messaggio dell''anno {1}.

E026

Firma elettronica non valida sul file {0}. Errore: {1}

E027

Il file {0} non è dichiarato nell’indice.

E028

Il file {0} è dichiarato nell’indice ma non è presente nel pacchetto.

E029

I file eml devono essere posizionati in una cartella con il nome della casella PEC da archiviare.

A000

Messaggio informativo generico.

A001

La fattura {0} non ha le notifiche.

A002

Le notifiche della fattura {0} non sono complete.

A003

La fattura {0} non ha la notifica {1}.

A005

Il file della notifica AT {0} deve avere estensione .zip

A006

Il file {0} non è firmato.

A007

Il file {0} è una notifica di ACCETTAZIONE PEC, ma manca il messaggio inviato.

A008

Il file {0} non ha validità legale in quanto manca la notifica di ACCETTAZIONE PEC.

11.4. Tabella dei codici degli stati del PDV

Tabella 6. Codici degli stati del PDV
Codice Descrizione Azioni possibili

P00

Stato iniziale.
È lo stato in cui si trova il pacchetto dopo che è stato creato e prima che venga caricato il contenuto. I pacchetti creati con l’API POST /aziende/{idAzienda}/pdv/{pdvFormat} non passano da questo stato.

Caricamento del contenuto del pacchetto.

P01

Pacchetto aperto.
È uno stato valido solo per i pacchetti di tipo F001 e F003, cioè quelli relativi alle fatture elettroniche gestite dal sistema. Indica che il pacchetto è stato definito ed è in corso l’assegnazione delle fatture elettroniche destinate all’archiviazione.

Il sistema di gestione delle fatture elettroniche assegna le fatture che hanno completato il ciclo di gestione.

P02

Elaborazione in corso.
È lo stato in cui si trova il pacchetto dopo essere stato caricato quando sono in corso le procedure di verifica e validazione.

L’utente attende il completamento dell’operazione.

P03

Elaborato
È lo stato in ci si trova il pacchetto al termine delle operazioni di verifica e validazione. Il pacchetto verrà preso in carico per le operazioni successive in base all’esito della verifica e validazione.

L’utente attende il completamento dell’operazione.

P04

Firma in corso
È in corso la firma del rapporto di versamento.

L’utente attende il completamento dell’operazione.

P05

Archiviato
Il contenuto del pacchetto di versamento è stato caricato nell’archivio. Il pacchetto verrà preso in carico per le operazioni successive relative alla pubblicazione del rapporto di versamento.

L’utente attende il completamento dell’operazione.

P06

Accettato
Il pacchetto di versamento è stato accettato.

L’utente può scaricare il rapporto di versamento firmato.

P07

Rapporto archiviato
Il pacchetto di versamento è stato accettato e il rapporto di versamento è stato archiviato. I rapporti di versamento, in quanto documenti digitali, vengono automaticamente versati nel sistema di conservazione dopo l’accettazione del pacchetto.

L’utente può scaricare una duplicato del rapporto di versamento firmato.

P08

Rifiutato
Il pacchetto di versamento è stato rifiutato a causa di errori bloccanti nel processo di verifica e validazione.

L’utente può scaricare il rapporto di versamento in cui si trovano i messaggi di errore che hanno determinato il rifiuto.

P09

Verifica PDD
Valido solo per i pacchetti di tipo F998 (pacchetti contenente pacchetti di distribuzione provenienti da un altro conservatore), significa che è in corso la verifica sulla leggibilità del pacchetto proveniente da un precedente conservatore.

L’utente attende il completamento dell’operazione. In alcuni casi la verifica del PDD di un precedente conservatore richiede l’intervento manuale degli operatori di backend. In questo caso l’operazione ha una durata maggiore.

11.5. Tabella dei codici delle azioni sui PDV

Tabella 7. Codici delle azioni sui PDV
Codice Descrizione

A00

Non usato.

A01

Definizione del PDV.

A02

Caricamento del PDV.

A03

Conferma del PDV.

A04

Archiviazione del PDV.

A05

Validazione completata con successo.

A06

Invio alla firma del rapporto di versamento.

A07

Firma del rapporto di versamento.

A08

Archiviazione del PDV.

A09

Scarto del PDV.

A10

Validazione completata con errori.

A11

Rimozione dei file non rilevanti.

A12

Prepara il rapporto di versamento per l’invio alla firma.

11.6. Tabella dei codici degli stati del PDA

Tabella 8. Codici degli stati del PDA
Codice Descrizione

T00

Stato iniziale.

T01

Elaborato.

T02

Incompleto.

T03

Da firmare.

T04

Firma in corso.

T05

Firmato.

T06

Non usato.

T07

Chiuso.

T08

Scartato.

11.7. Tabella dei codici delle azioni sui PDA

Tabella 9. Codici delle azioni sui PDA
Codice Descrizione

A00

Non usato.

A01

Creazione del PDA.

A02

Validazione completata con successo.

A03

Validazione completata con errori.

A04

Invio alla firma dell’indice del PDA.

A05

Inizio del processo di firma.

A06

Conclusione del processo di firma.

A07

Chiusura del PDA

A08

Invio per nuova validazione.

11.8. Tabella dei codici degli stati di una richiesta di PDD

Tabella 10. Codici degli stati del PDD
Codice Descrizione Stato

R00

Richiesta in bozza

La ricerca è in bozza e può essere modificata dall’utente.

R01

Richiesta salvata

La ricerca è stata salvata come definitiva. Non può più essere modificata dall’utente e verrà eseguita dal primo processo disponibile. L’utente può riportare la ricerca in stato di bozza.

R02

Ricerca in corso

La ricerca è in corso. Non può essere modificata dall’utente.

R03

Risultati disponibili

I risultati della ricerca sono disponibili. Dopo un determinato periodo di tempo passa direttamente in stato R07 oppure l’utente richiede la formazione di un PDD portando lo stato in R04.

R04

PDD richiesto

È stato richiesto che i risultati della richiesta siano assemblati in un PDD. L’utente può annullare questa richiesta riportando lo stato in R03.

R05

PDD in costruzione

Il processo di assemblaggio del PDD è in corso. L’utente non può modificare.

R06

PDD pronto

Il PDD è pronto per essere scaricato. Dopo un determinato periodo di tempo la richiesta passa nello stato R07.

R07

PDD da eliminare

La richiesta è destinata ad essere eliminata automaticamente. Dopo un determinato periodo di tempo lo stato passa a R08.

R08

PDD eliminato

La richiesta è stata cancellata per cui l’eventuale PDD generato non è più disponibile per il download.

R09

PDD pronto per la firma

L’indice del PDD è stato assemblato ed è pronto per essere firmato.

R10

Firma del PDD in corso

Il processo di firma del PDD è in corso.

R11

PDD firmato

Il processo di firma del PDD è stato concluso.

R12

Raccolta firmata

La raccolta di documenti è stata firmata.

11.9. Tabella dei codici delle azioni sulle richieste di PDD

Tabella 11. Codici delle azioni sulle richieste di PDD
Codice Descrizione

PDD01

Creazione della richiesta di documenti.

PDD02

Azione eseguita dall’utente con la quale viene finalizzata la richiesta di documenti

PDD03

Azione eseguita dal sistema che indica che è stato programmato il lavoro di ricerca.

PDD04

Azione eseguita dal lavoro di ricerca al termine dell’esecuzione per indicare che la ricerca è stata completata e i risultati sono disponibili.

PDD05

Azione eseguita dall’utente con cui viene chiesto di formare un PDD in base ai risultati della ricerca.

PDD06

Azione eseguita dal sistema che indica che è stato programmato il lavoro di formazione del PDD.

PDD07

Azione eseguita dal lavoro di formazione del PDD al termine dell’esecuzione per indicare che il PDD è disponibile.

PDD08

Azione eseguita dall’utente che indica il download del PDD.

PDD09

Azione eseguita dal sistema, che avvia il lavoro di rimozione del PDD dopo che è stato reso disponibile per un certo periodo di tempo.

PDD10

Azione eseguita dal lavoro di rimozione del PDD che indica il completamento delle operazioni di rimozione del PDD.

PDD11

Azione eseguita dal lavoro di formazione del PDD al termine dell’esecuzione dell’operazione di creazione dell’indice del PDD.

PDD12

Azione eseguita dal sistema che indica che è stato avviato il processo di firma del PDD.

PDD13

Azione eseguita dal lavoro di formazione del PDD al termine dell’esecuzione dell’operazione di firma.

PDD14

Azione eseguita dall’utente con la quale viene creata una nuova raccolta di documenti.

11.10. Tabella dei codici delle operazioni tracciate nell’audit log

Tabella 12. Codici delle operazioni tracciate nell’audit log
Codice Descrizione

V000

Azione generica non specificata.

V001

(READ) Accesso in lettura dell’entità.

V002

(UPDATE) Accesso in aggiornamento dell’entità.

V003

(DELETE) Cancellazione dell’entità.

V004

(READ_LOG) Lettura del log dell’entità.