Suap

Il nuovo Sistema SSU ha un'architettura distribuita con tre categorie di componenti: informatiche SUAP (Front-Office SUAP e Back-Office SUAP), informatiche Enti Terzi e la componente infrastrutturale Catalogo SSU.

A completare la struttura architetturale si evidenziano anche le interazioni con il Registro Imprese ed il sistema ComUnica, resi disponibile dal Sistema Camerale: al primo vanno inoltrati gli atti dei procedimenti SUAP; il secondo invece entra in gioco per la sola fattispecie di costituzione d’impresa e contemporaneo avvio delle attività.

Il Front-Office SUAP è il punto di contatto per gli imprenditori, permettendo a questi di avviare e seguire i procedimenti SUAP fino alla conclusione. Il Back-Office SUAP gestisce e coordina i procedimenti tra i vari componenti del sistema, assicurando coerenza e flusso informativo efficace. Gli Enti Terzi contribuiscono con istruttorie e controlli per garantire conformità alle normative. Il Catalogo SSU svolge il ruolo di fonte informativa condivisa di tutti i procedimenti ed i relativi stati di avanzamento, delle amministrazioni coinvolte e delle componenti informatiche da esse utilizzate, offrendo una visione completa e trasparente dei processi in corso.

Le componenti informatiche SUAP sono di due tipi e ricoprono due ruoli fondamentali nella gestione dei procedimenti SUAP.

Il Front-Office ha il compito di gestire tutte le interazioni con i Soggetti Presentatori per garantire loro la creazione di un nuovo procedimento e la ricezione delle conclusioni o di eventuali segnalazioni in merito. Il Back-Office gestisce la lavorazione dei procedimenti avviati, interagendo con gli Enti Terzi coinvolti e redigendo le conclusioni o eventuali segnalazioni che dovranno essere propagate al presentatore.

Andando ad analizzare più nel dettaglio, il Front-Office:

• - Assicura le interazioni con i soggetti presentatori delle istanze che avviano i procedimenti SUAP, tramite uno sportello telematico;
• - Permette al presentatore di selezionare un procedimento e procedere con la compilazione dello stesso;
• - Valida i dati forniti dal soggetto presentatore tramite una verifica automatizzata, come previsto dalle Regole di digitalizzazione dei moduli;
• - Permette al soggetto presentatore di integrare l'istanza per soddisfare le richieste delle amministrazioni coinvolte;
• - Assicura la ricezione delle comunicazioni in merito ai procedimenti SUAP avviati.

Invece per quanto riguarda il Back-Office:

• - Gestisce le istanze inoltrate dal Front-Office;
• - Effettua controlli automatizzato sui moduli digitali e un controllo sui documenti non strutturati per verificarne la procedibilità;
• - Coordina il Processo SUAP, garantendo l'interazione con gli Enti Terzi coinvolti per avviare le istruttorie e ricevere i pareri sulle istanze;
• - Recapita al presentatore le conclusioni o eventuali richieste di integrazione, nel rispetto dei tempi procedimentali previsti.

Gli Enti Terzi sono uffici comunali diversi dal SUAP o amministrazioni diverse dai Comuni, coinvolti nei procedimenti SUAP. Il loro ruolo è fondamentale per garantire una valutazione completa e corretta delle istanze presentate dai soggetti proponenti.

Nello specifico, le componenti informatiche degli Enti Terzi:

• - Avviano le istruttorie di loro competenza sulla base delle istanze ricevute dal Back-office SUAP;
• - Selezionano la documentazione dell'istanza di loro interesse per condurre le istruttorie;
• - Predispongono richieste di integrazione, nel caso in cui riscontrino, a seguito dei controlli di merito di propria competenza, la non completezza della documentazione inoltrata dal soggetto presentatore;
• - Predispongono, ove previsto dalla norma in forma esplicita, le conclusioni delle proprie istruttorie (parere favorevole, diniego motivato, richiesta di conformazione, divieto di prosecuzione dell’attività).

La componente infrastrutturale Catalogo SSU svolge il ruolo di catalogo centralizzato dei metadati dei procedimenti SUAP al fine di garantire standardizzazione dei moduli e il tracciamento degli stati di avanzamento. Definisce le regole di interoperabilità per le componenti strutturali accreditate ad operare all’interno del Sistema SSU, garantendo anche l’accesso alle anagrafiche di queste ultime. Inoltre, garantisce il supporto alle Amministrazioni competenti nella predisposizione dei contenuti per il popolamento iniziale e al successivo costante aggiornamento dei contenuti del Catalogo SSU. Nel dettaglio, si evidenziano le seguenti funzionalità del Catalogo:

• - Registrazione e gestione delle componenti informatiche: Il Catalogo SSU tiene traccia di tutte le componenti informatiche (Front-Office SUAP, Back-Office SUAP ed Enti Terzi) che partecipano al sistema, facilitando la loro identificazione e la comunicazione tra di esse
• - Gestione dei metadati: Il Catalogo SSU gestisce i metadati, ovvero le informazioni strutturate che descrivono i procedimenti SUAP, le regole di validazione, i moduli, gli allegati, gli enti coinvolti e i loro sistemi informatici, essenziali per garantire l'interoperabilità tra le diverse componenti del sistema.;
• - Generazione dei codici unici di istanza (CUI): Il Catalogo SSU assegna un codice univoco a ogni istanza presentata, consentendo di tracciare in modo univoco ogni procedimento;
• - Tracciatura dello stato delle istanze: Il Catalogo SSU registra tutti gli eventi che determinano un cambiamento di stato di un procedimento (presentazione, integrazione, conclusione, etc.), offrendo una visione completa e aggiornata dello stato di avanzamento di ogni pratica.

Le componenti architetturali del Sistema SSU includono Front-Office, Back-Office, Enti Terzi, Catalogo SSU, ComUnica e Registro Imprese.

Il Front-Office è il punto di accesso per il presentatore nel Sistema SSU, attraverso il quale un imprenditore può presentare un’istanza di procedimento ed i relativi documenti. Una volta immessa, invia i riferimenti dell’istanza al Back-Office SUAP per permettergli di avviare le proprie analisi.

Il Back-Office SUAP, col ruolo di orchestratore nella gestione dei procedimenti SUAP avvia le proprie analisi formali e, se previsto dalla norma, provvede ad inviare una richiesta di correzione al presentatore. Inoltre, coordina gli scambi con gli Enti Terzi per la trasmissione dei documenti presentati, per gestire eventuali richieste di integrazione o di convocazione della Conferenza dei Servizi Sincrona (CdSS) e per redigere le conclusioni dei procedimenti sulla base degli esiti ricevuti dagli Enti Terzi. Al fine di avviare le istruttorie di competenza in merito alle istanze dei procedimenti SUAP inoltra gli atti al Registro Imprese.

In caso di costituzione di impresa con contestuale richiesta di avvio dell'attività produttiva, il presentatore può accedere al sistema ComUnica per l’avvio di un procedimento. Tramite il ComUnica, l’imprenditore potrà essere ridirezionato verso il Front-Office SUAP di riferimento per il proprio processo SUAP.

Tutti i sistemi dell’SSU, quali Front-Office, Back-Office, ed Enti Terzi, recuperano l’Instance Descriptor dal Catalogo SSU per ottenere le informazioni necessarie alla lavorazione dei procedimenti. Infatti, da questo oggetto possono ottenere le informazioni in merito ai documenti delle istanze presentate, i riferimenti dei componenti da cui ottenerli e i soggetti con cui interagire per procedere con le lavorazioni.

Inoltre, devono notificare al Catalogo SSU le interazioni a cui l’istanza è sottoposta tramite messaggi di audit. Questi possono aggiornare lo stato amministrativo dell’istanza ed evidenziare gli avanzamenti ed eventuali latenze durante le fasi di lavorazione, per garantire una maggiore tracciabilità e trasparenza. Tutte le comunicazioni tra sistemi SUAP dovranno essere effettuate tramite API REST.

REST (REpresentation State Transfer), sviluppato dal W3C insieme a HTTP 1.1 nel 1999, definisce i vincoli architetturali per l'interazione tra componenti di un'architettura di sistema distribuita.

Un'API REST è un'interfaccia di programmazione che consente ai sistemi di comunicare tra loro utilizzando il protocollo HTTP. Le API REST, progettate per essere leggere, scalabili e facili da utilizzare, possono essere considerate come un contratto tra un fornitore di informazioni e l’utente destinatario di tali dati: l'API REST stabilisce il contenuto richiesto dal consumatore (la chiamata) e il contenuto richiesto dal produttore (la risposta).

L'API REST ricopre il ruolo di elemento di intermediazione tra gli utenti o i clienti e le risorse o servizi web che questi intendono ottenere. È anche un mezzo con il quale un'organizzazione può condividere risorse e informazioni assicurando al contempo sicurezza, controllo e autenticazione, poiché stabilisce i criteri di accesso.

Un'API (Application Programming Interface) è un insieme di definizioni e protocolli che permette a diverse applicazioni software di comunicare tra loro. Un OpenAPI Specification invece è una specifica per file di interfaccia leggibili dalle macchine per descrivere, produrre, consumare e visualizzare servizi web RESTful. La struttura di un OpenAPI generalmente include:

• - Path
• In termini di OpenAPI, i paths sono endpoints (risorse), come /users o /reports/summary, che una specifica API espone per accedere a una risorsa o eseguire un'operazione. Ogni path è definito all'interno della sezione globale paths delle specifiche dell’API e può avere uno o più metodi HTTP associati (come GET, POST, PUT, DELETE), ognuno dei quali definisce come interagire con quell'endpoint.

• - Endpoint
• Un URL specifico dove le risorse possono essere accessibili. Ogni endpoint rappresenta una funzione specifica.
•  
• Un esempio: https://api.example.com/users

• - Metodo HTTP
• Specifica il tipo di operazione da eseguire sull'endpoint. I metodi comuni sono:
• oGET: Recupera informazioni da un server.
• oPOST: Invia dati al server per creare una nuova risorsa.
• oPUT: Aggiorna una risorsa esistente.
• oDELETE: Elimina una risorsa.

• Un esempio: GET /users

• - Headers
• Contengono informazioni necessarie per l'autenticazione, il tipo di contenuto e altre direttive.
•  
• Un esempio: Content-Type: application/json, Authorization: Bearer <token>

• - Request Body
• Utilizzato principalmente con i metodi POST e PUT per inviare dati al server utilizzando un formato JSON, XML o altri formati.
•  
•  
• Un esempio in XML: <?xml version="1.0" encoding="UTF-8"?>
• <text>
• <para>hello world</para></text>

• - Response Body
• Contiene i dati restituiti dal server in risposta a una richiesta formato JSON, XML o altri formati.
•  
•  
• - Status Codes
• Codici numerici che indicano l'esito della richiesta HTTP.
•  
•  
• Esempi comuni:
• o 200 OK: La richiesta è stata eseguita con successo.
• o 201 Created: Una nuova risorsa è stata creata con successo.
• o 400 Bad Request: La richiesta non è valida.
• o 401 Unauthorized: La richiesta non è autorizzata.
• o 404 Not Found: La risorsa richiesta non è stata trovata.
• o 500 Internal Server Error: Errore interno del server.

• -Query Parameters
• Coppie chiave-valore aggiunte all'URL per filtrare o modificare la richiesta.
•  
• Un esempio: GET /users?age=25&status=active
•  
•  
• -Path Parameters
• Variabili all'interno del percorso URL che rappresentano risorse specifiche.
•  
• Un esempio: GET /users/{id} dove {id} è un parametro che verrà sostituito con un valore reale come GET /users/1.
•  
•  

Consultando la documentazione Swagger/OpenAPI è possibile avere una rappresentazione visuale e interattive delle API.

L'interoperabilità è la capacità dei sistemi informatici di comunicare e scambiare informazioni in modo efficace. Il nuovo Modello di Interoperabilità rende possibile la collaborazione tra Pubbliche amministrazioni e tra queste e soggetti terzi, per mezzo di soluzioni tecnologiche che assicurano l’interazione e lo scambio di informazioni senza vincoli sulle implementazioni, evitando integrazioni ad hoc. Svolge un ruolo portante nella definizione di regole comuni tra tutte le amministrazioni, le quali devono aderire agli standard tecnologici e dovrebbero utilizzare i pattern e i profili del nuovo Modello di interoperabilità, che consentirà di definire ed esporre Application Programming Interface (API) conformi agli standard consolidati anche in ambito EU.

Migliora l'efficienza operativa e la qualità dei servizi offerti, grazie a informazioni e documentazione più complete e aggiornate. Aumenta la trasparenza e la responsabilità delle operazioni, riduce la burocrazia e sostiene il principio "once-only", secondo cui cittadini e imprese devono fornire informazioni solo una volta, poiché queste vengono condivise tra le singole amministrazioni. In sintesi, rende il sistema PA più efficiente, trasparente e orientato alla trasformazione digitale.

L'interoperabilità viene garantita attraverso l'adozione di standard e protocolli comuni, declinati attraverso le API REST che i sistemi informatici devono implementare, nel rispetto delle normative nazionali, allegato tecnico del DPR 160/2010, che disciplinano lo scambio di dati tra le amministrazioni pubbliche coinvolte nei procedimenti SUAP.

Per garantire ciò, in applicazione del MoDI, il Sistema SSU individua la Piattaforma Digitale Nazionale Dati (PDND) quale l’infrastruttura tecnologica che svolge il ruolo di authentication & authorization server, rendendo possibile l’interoperabilità dei sistemi informativi, delle basi di dati delle pubbliche amministrazioni e dei gestori di servizi pubblici. PDND favorisce la conoscenza e l’utilizzo del patrimonio informativo detenuto, nonché la condivisione dei dati tra i soggetti che hanno diritto ad accedervi al fine di semplificazione degli adempimenti amministrativi dei cittadini e delle imprese.

Le indicazioni su come le PA danno seguito all'interoperabilità dei propri sistemi informatici sono oggetto delle Linee Guida Interoperabilità Tecnica.

La condivisione di dati e informazioni avviene attraverso la messa a disposizione e l’utilizzo, da parte dei soggetti accreditati in PDND, di interfacce di programmazione applicative (API). Le interfacce dei sistemi SSU, sviluppate dai soggetti abilitati, sono raccolte nel «Catalogo API» reso disponibile dalla piattaforma PDND ai soggetti accreditati. I soggetti coinvolti sono tenuti ad accreditarsi alla piattaforma, a sviluppare le interfacce e a renderle disponibili per garantire l’interoperabilità tra tutti i sistemi appartenenti all’SSU.

Il Modello di Interoperabilità delle Pubbliche Amministrazioni (MoDI) individua nelle Linee Guida sull’infrastruttura per l’interoperabilità della Piattaforma Digitale Nazionale Dati il Catalogo delle API quale componente, unica e centralizzata, della Piattaforma Digitale Nazionale Dati (PDND), che assicura alle parti coinvolte nel rapporto di erogazione e fruizione la consapevolezza sulle API disponibili.

Il Catalogo API è realizzato al fine di:

• - favorire l’uso degli e-service grazie alla loro pubblicazione e la messa a disposizione della relativa documentazione tecnica;
• - agevolare la gestione del ciclo di vita degli e-service;
• - mitigare la creazione di interfacce ridondanti e/o con semantica sovrapposta;

 Ogni e-service pubblicato sul Catalogo API si compone delle seguenti parti:

• - i descrittori dell’e-service, che definiscono le informazioni relative alla natura dell’e-service e le informazioni tecniche per usufruire dello stesso;
• - di una descrizione tecnica dell’interfaccia (IDL) per usufruire dell’e-service;
• - la documentazione accessoria e manualistica per l’utilizzo del e-service.

Per avere accesso alla PDND ogni ente, già accreditato sull’ indice IPA di cui all’art. 6-ter del CAD, dovrà seguire il processo di Onboarding, firmando l’accordo di adesione. L’Onboarding richiede l’inserimento dei dati dell’ente aderente e di un legale rappresentante, la nomina degli amministratori per la piattaforma PDND e la firma dell’accordo di adesione. Si ricorda che il processo di Onboarding è realizzato da un ente una sola volta indipendentemente dal sistema SSU.

Le persone indicate avranno la qualifica di Delegato all'interno di PDND Interoperabilità e avranno pieni poteri di amministrazione. Le figure operative (Operatore API e Operatore di Sicurezza) potranno essere aggiunte e gestite in un secondo momento.

L’accordo di adesione viene inviato via PEC al domicilio digitale dell'ente come è indicato sul Catalogo IPA. Deve essere firmato per nome e per conto del Legale Rappresentante e caricato al link fornito nella PEC.

Maggiori dettagli sono disponibili alla documentazione della PDND all’URL https://docs.pagopa.it/interoperabilita-1/manuale-operativo/guida-allad….

La gestione dell'autenticazione nella Piattaforma Digitale Nazionale Dati (PDND) è un elemento cruciale per garantire l’accesso ai servizi esposti tra le pubbliche amministrazioni italiane. Per l'autenticazione degli utenti, la PDND utilizza sistemi robusti come il Sistema Pubblico di Identità Digitale (SPID), la Carta d'Identità Elettronica (CIE) e la Carta Nazionale dei Servizi (CNS). Questi sistemi permettono ai soggetti incaricati di accedere ai servizi online tramite la loro identità digitale, garantendo un processo di autenticazione sicuro ed efficace.

Oltre agli utenti, anche le applicazioni e i servizi che richiedono l'accesso ai dati devono essere autenticati. Questo avviene attraverso l'uso di Client e certificati digitali, che permettono alle applicazioni di dimostrare la propria identità e stabilire connessioni sicure con la PDND. Un Client è un contenitore che raccoglie le relative chiavi pubbliche, ovvero un corredo crittografico di cui gli aderenti si dotano per ottenere un voucher da PDND Interoperabilità. Ogni client può essere associato a una o più finalità, definite con lo scopo di dettagliare le sue motivazioni di utilizzo e le modalità di accesso alle informazioni. Una volta associato, il materiale crittografico lì depositato sarà considerato valido per richiedere a PDND Interoperabilità un voucher per quella finalità.

Maggiori informazioni sono disponibili, nelle specifiche sezione della documentazione della PDND, all’URL https://docs.pagopa.it/interoperabilita-1.

I Front-Office SUAP devono assicurare che i documenti presentati per le istanze scambiate con i Back-Office siano completi rispetto alla previsione normativa. A tale scopo, è stato individuato un framework per definire le "Regole di digitalizzazione dei moduli" basato sulle tecnologie XML-Schema e Schematron, per garantire il rispetto dei vincoli definiti dalla normativa.

XML (eXtensible Markup Language) è un linguaggio di markup progettato per la memorizzazione e il trasporto di dati strutturati. Un documento con formato digitale XML è un documento che utilizza la sintassi XML per definire la struttura e il contenuto dei dati in modo standardizzato.

Uno dei principali vantaggi di XML è la loro capacità di favorire l'interoperabilità, consentendo lo scambio e l'interpretazione dei dati tra diversi sistemi e applicazioni. Questo standard comune promuove connettività e collaborazione tra organizzazioni e settori. La struttura flessibile di XML migliora i processi aziendali, aumentando l'automazione e l'efficienza. Inoltre, XML offre una gestione dei metadati avanzata e consente alle organizzazioni di incorporare informazioni aggiuntive all'interno dei loro documenti, facilitando così la ricerca, la gestione e la tracciabilità dei dati.

La verifica del "ben formato" è il processo di controllo per assicurare che le informazioni presenti nei moduli digitali rispettano i vincoli definiti nelle Regole di digitalizzazione dei moduli. Più nel dettaglio, questa verifica si concentra sulla conformità della documentazione alle regole e ai formati richiesti, garantendo che tutte le informazioni necessarie siano presenti e che siano inserite correttamente, andando a verificare che vengano rispettati i vincoli definiti.

Il framework per la definizione delle Regole di digitalizzazione dei moduli deve soddisfare i seguenti requisiti:

• - tipizzazione dei dati: definisce l’utilizzo di caratteri alfanumerici, numerici, espressioni booleane Vero/Falso o altri tipi;
• - restrizioni sul tipo dei dati: definisce la lunghezza dei testi o il rispetto di un'espressione regolare che limita l’utilizzazione dei caratteri secondo alcune regole predefinite;
• - cardinalità dei dati: definisce l’obbligatorietà di un campo o le occorrenze;
• - dipendenze incrociate tra dati.

I Front-Office SUAP devono assicurare che le istanze scambiate con i Back-Office siano complete rispetto alla previsione normativa. A tale scopo è stato definito il framework “regole di digitalizzazione dei moduli”, che attraverso l’utilizzo degli standard XML-Schema e Schematron, permette di definire i vincoli che gli XML devono assicurare in coerenza con la previsione normativa relativa alla documentazione necessaria all’avvio dei procedimenti SUAP.

L’organizzazione delle “regole di digitalizzazione dei moduli” prevede la creazione e manutenzione dei seguenti oggetti digitali:  

• - Vocabolari: rappresentano elenchi di valori ammissibili ed utilizzabili per condizionare la valorizzazione degli attributi;
• - Attributi: rappresentano uno specifico dato declinato con la tipologia, i vincoli, ed eventualmente il vocabolario a cui i valori dello stesso sono vincolati;
• - Entità: rappresenta l'astrazione di un oggetto della realtà quale aggregazione di attributi definiti;
• - Sezioni: rappresentano una porzione delle Regole di digitalizzazione dei moduli quale aggregazione di entità compresa la relativa contestualizzazione;
• - Moduli: rappresentano le Regole di digitalizzazione dei moduli quale aggregazione di sezioni definite

Questi oggetti sono legati tra loro secondo delle relazioni, in particolare:

• - Un Vocabolario tipizza gli Attributi delle Entità;
• - Un’Entità è raccolta in Sezioni;
• - Le Sezioni sono associate nei Moduli.

La validazione di questi oggetti richiede le seguenti condizioni:

• - Un singolo Vocabolario deve essere definito predisponendo un file XML caratterizzato da un unico CodeList element che deve includere gli elementi previsti da OASIS Code List Representation (genericode) Version 1.0

• - Una Entità deve essere implementata tramite:
• o uno XML Schema conforme a W3C XML Schema (XSD) che contiene la definizione di una singola entità e dei relativi attributi;
• o uno Schematron conforme a ISO/IEC-19757-3:2020 Information technology, includendo le necessarie assert per la verifica dei vocabolari e i controlli tra gli attributi dell’entità.

• - Una Sezione deve essere implementata tramite:
• o uno XML Schema conforme a W3C XML Schema (XSD) che contiene la definizione di una singola sezione quale raccolta di entità definite;
• o uno Schematron conforme a ISO/IEC-19757-3:2020 Information technology, includendo le caratteristiche delle entità utilizzate attraverso la specializzazione delle obbligatorietà e/o cardinalità degli attributi delle stesse.

• Un Modulo deve essere definito tramite un complextType element per definire le sezioni specifiche del modulo e, se queste sono condivise, definire le associazioni tra le stesse.

Per maggiori dettagli si rimanda al capitolo 5 delle specifiche tecniche di cui all’art. 5 dell’allegato al DPR 160/2010 (https://www.mimit.gov.it/images/stories/normativa/SPECIFICHE_TECNICHE_S…).

Relativamente alle Regole di digitalizzazione dei moduli, le Specifiche Tecniche individuano XSD e Schematron quali le tecnologie/standard che assicurano la validazione dei dati delle istanze presentate dal Soggetto Presentatore, per permettere lo scambio di messaggi tra Front-office SUAP, Back-office SUAP ed Enti Terzi.

XSD è un linguaggio utilizzato per definire la struttura e il contenuto dei documenti XML, specificando le regole che un documento XML deve seguire per essere considerato valido, tramite la definizione di elementi, attributi e gerarchie dei dati, che possono essere semplici o complessi. XSD definisce anche vincoli come lunghezza o valori massimi e minimi.

Schematron, invece, è un linguaggio basato su regole per la validazione di documenti XML ed esprimere regole di validazione complesse che non possono essere facilmente espresse con XSD. Schematron è utile per verificare condizioni logiche complesse, supporta la definizione di pattern e fasi per validazioni in più passaggi, e può fornire messaggi di errore personalizzati.

XSD e Schematron sono spesso usati insieme per una validazione completa dei documenti XML: XSD garantisce la correttezza della struttura e dei tipi di dati, mentre Schematron definisce regole di validazione complesse e specifiche. La loro combinazione offre una validazione robusta e dettagliata.

I sistemi aderenti alla PDND possono ricoprire due ruoli: Erogatore e Fruitore. Ogni Pubblica Amministrazione può essere contemporaneamente erogatore di alcuni e-service e fruitore di altri. La Pubblica Amministrazione aderente che ricopre il ruolo di Erogatore è colei che implementa nei propri sistemi informatici e pubblica gli e-service nella PDND, indicando le modalità di utilizzo, gli attributi richiesti ai potenziali fruitori, la durata del token di autorizzazione (Time to Live, TTL) e il limite di soglia delle chiamate giornaliere e, nondimeno, l’OpenAPI che descrive tecnicamente l’API REST che implementa l’e-service erogato. Gli erogatori sono responsabili della qualità, dell'accuratezza e della sicurezza dei dati che mettono a disposizione sulla piattaforma.

Il Fruitore, invece, è la Pubblica Amministrazione che accede ai dati sulla PDND:

• - richiedendo la fruizione di un e-service;
• - indicando le finalità per le quali utilizzerà l’e-service;
• - inserendo la stima di carico, il numero di chiamate, all’e-service.

Sulla base di quanto definito dal fruitore e accettato dall’erogatore, i fruitori potranno ottenere dalla PDND un token di autorizzazione per l’accesso all’API REST che implementa l’e-service. Si ricorda che il token ottenuto dalla PDND ha una durata limitata (TTL), così come definito dall’erogatore al momento della pubblicazione dell’e-service, entro cui l’erogatore può effettuare richieste (request). Maggiori informazioni sono disponibili, nelle specifiche sezione della documentazione della PDND, all’URL https://docs.pagopa.it/interoperabilita-1.

Per aderire al SUAP Camerale è possibile rivolgersi alla Camera di Commercio competente sul territorio, la quale seguirà il Comune per tutta la durata dell'iter di adesione. Alla luce degli adempimenti previsti dal nuovo Allegato Tecnico al DPR 160/2010, il Sistema Camerale si farà carico sia di adeguare le componenti che eroga, ovvero Front Office SUAP II1G e Back Office SUAP II1G, sia di richiedere al MIMIT la verifica tecnica di conformità delle stesse. Per questo motivo, i SUAP aderenti non dovranno effettuare alcun adempimento nei confronti della Piattaforma Digitale Nazionale Dati (PDND) e del Catalogo del Sistema Informatico degli Sportelli Unici (Catalogo SSU). Per quanto concerne i SUAP non aderenti a impresainungiorno, l’adeguamento delle piattaforme, la richiesta di verifica di conformità e l’accreditamento dei SUAP sarà a cura degli stessi.

Il supporto alle Regioni con piattaforma che erogano servizi SUAP, Unioncamere, Invitalia per conto dei Comuni, Enti Terzi e in-house regionali, viene fornito da AgID tramite il proprio servizio di help desk raggiungibile al seguente link: https://uniticket.agid.gov.it.

Le modalità di accesso e di gestione dei ticket sono dettagliate nel manuale disponibile al seguente link: https://www.agid.gov.it/sites/agid/files/2024-09/Supporto%20SUAP_Manuale%20utente.pdf

Per ulteriori informazioni, è possibile contattare il team SUAP all'indirizzo supportosuap@agid.gov.it.

Per recuperare i riferimenti delle componenti SUAP, associati alle istanze identificate univocamente tramite il “CUI”, è necessario seguire questi passaggi:

1. Recupero del Codice ISTAT del Comune

Il primo passo consiste nell'ottenere il Codice ISTAT a 6 cifre del Comune, reperibile dall'attributo “municipality” presente nel relativo “Instance Descriptor”. Questo dato può essere recuperato dal Catalogo SSU tramite il seguente endpoint: /catalogo-ssu_to_et/instance_descriptor/{cui_uuid}.

2. Recupero della componente informatica

Una volta ottenuto il Codice ISTAT, è possibile procedere, sempre tramite il Catalogo SSU, con il recupero delle componenti SUAP in base alle proprie esigenze:

• Componente informatica per un singolo comune:
• Endpoint: /catalogo-ssu_meta/suap/{municipality}.
• Versioni delle componenti per più comuni:
• Se si desidera ottenere le versioni delle componenti SUAP per uno o più comuni, è possibile utilizzare il seguente endpoint: /catalogo-ssu_meta/suaps-by-municipality/{municipality_list}.

3. Recupero del sistema della componente SUAP

Una volta ottenuta la componente, selezionare quella in state “Active” e utilizzare l'ID e la versione per recuperare, tramite il Catalogo SSU, il sistema della componente SUAP di proprio interesse:

• Front-office:
• Endpoint: /catalogo-ssu_meta/suap/{suap_id}/{suap_version}/frontoffice-system.
• Back-office:
• Endpoint: /catalogo-ssu_meta/suap/{suap_id}/{suap_version}/backoffice-system.

Il legame obbligatorio tra una Pubblica Amministrazione (PA) presente nell’Indice IPA e il sistema SSU è rappresentato dal Codice IPA (Codice_IPA), l’identificativo univoco, che consente di distinguere ogni amministrazione, utilizzato nel catalogo SSU.

Nel dettaglio, nel sistema SSU, l’anagrafica degli uffici delle PA coinvolti nei procedimenti SUAP è mantenuta nel catalogo SSU tramite l’oggetto AdministrationSchema. Tale oggetto, definito nelle Specifiche Tecniche, include i seguenti attributi:

   - ipacode

   - officecode

   - version

   - description

Per approfondire il significato degli attributi, si può chiarire quanto segue:

ipacode: registra il Codice IPA (Codice_IPA), associato alle PA direttamente nell'Indice IPA;

officecode: registra il codice dell'ufficio della PA coinvolto nei procedimenti SUAP. Le PA possono scegliere di adottare un proprio riferimento interno o utilizzare il codice UO (Codice_uni_uo), registrato dalle stesse nell'Indice IPA;

version: specifica la versione dell’oggetto AdministrationSchema, associato all’ufficio della PA;

description: fornisce una descrizione dell’ufficio della PA.

In seguito all’aggiornamento dei Pattern di Sicurezza delle Linee Guida sull’interoperabilità tecnica delle PA (determina n. 128/2023), il Dipartimento della Funzione Pubblica - in qualità di titolare dell’iniziativa PNRR (M1C1 | 2.2.3) per la digitalizzazione delle procedure SUAP - ha introdotto la necessità di adottare lo standard INTEGRITY_REST_02, evoluzione del precedente INTEGRITY_REST_01.

Rispetto alla versione precedente, questo standard semplifica significativamente il processo di verifica della firma digitale dei messaggi scambiati. La nuova modalità riduce la necessità di scambio dei certificati tra i vari Enti, accentrandone la gestione all’interno della PDND.

Questa evoluzione, in sintonia con le citate Linee Guida, permette integrazioni più rapide e meno onerose sotto il profilo operativo.

Per maggiori informazioni si rimanda alla comunicazione ufficiale del Dipartimento della Funzione Pubblica. 

Approved02 rappresenta il secondo ciclo di evoluzione delle Specifiche Tecniche di interoperabilità SUAP e costituisce un importante passo avanti nel percorso di digitalizzazione dei procedimenti amministrativi.

L'aggiornamento nasce dall'esperienza maturata durante le prime fasi di implementazione e sviluppo delle Specifiche Tecniche e dal confronto con amministrazioni, operatori del settore ed esperti amministrativi. L'obiettivo perseguito dal Gruppo Tecnico è stato quello di migliorare la coerenza tra i modelli di interoperabilità e la disciplina procedimentale prevista dall'ordinamento, estendendo al contempo la copertura funzionale delle Specifiche Tecniche.

Le principali aree di innovazione introdotte riguardano:

- l'adeguamento dei workflow esistenti al quadro normativo vigente;

- l'introduzione di nuovi workflow per specifici regimi amministrativi;

- il rafforzamento dei meccanismi di interoperabilità tra SUAP, Enti Terzi e ulteriori soggetti istituzionali;

- l'evoluzione dei servizi e delle API per supportare nuovi scenari procedimentali;

- il miglioramento della rappresentazione digitale delle attività istruttorie e delle comunicazioni tra amministrazioni.

Uno degli obiettivi principali perseguiti nell'ambito di Approved02 è stato quello di allineare in modo più puntuale i workflow delle Specifiche Tecniche al procedimento amministrativo disciplinato dalla normativa vigente.

Per raggiungere questo risultato, alle attività di analisi tecnica si è affiancato un approfondito confronto con esperti amministrativi e procedimentali, attraverso incontri dedicati che hanno consentito di approfondire le diverse casistiche applicative e di analizzare gli aspetti istruttori con un livello di dettaglio superiore rispetto alla precedente versione delle Specifiche.

Grazie a questo lavoro è stato possibile affinare la rappresentazione digitale dei procedimenti già presenti in Approved01 e di introdurre una modellazione più aderente alla realtà operativa delle amministrazioni.

In particolare, la revisione dei workflow esistenti ha consentito di rappresentare in maniera più puntuale:

- le attività istruttorie svolte dal SUAP;

- il coinvolgimento degli Enti Terzi nel corso del procedimento;

- le richieste di integrazione documentale;

- l'acquisizione di pareri, nulla osta e altri atti di assenso;

- le fasi di sospensione, ripresa e conclusione del procedimento;

- gli scambi informativi tra le amministrazioni coinvolte.

L'attività di approfondimento svolta ha inoltre evidenziato la necessità di disciplinare ulteriori fattispecie procedimentali all’interno delle Specifiche Tecniche.

Per questo motivo, oltre all'evoluzione dei procedimenti già esistenti, Approved02 introduce nuovi workflow dedicati a specifici regimi amministrativi, ampliando significativamente la copertura funzionale delle Specifiche Tecniche. In particolare, sono stati introdotti workflow dedicati a:

- SCIA Condizionata: una sola pratica che contiene sia fattispecie soggette a SCIA sia fattispecie autorizzatorie;

- Provvedimento Condizionato: riconoscimento condizionato degli stabilimenti da parte dell'Autorità Competente Locale;

- CERS: comunicazione di cessazione dell'impresa semplificata secondo il principio once-only;

- Autotutela: riapertura del procedimento per annullare un provvedimento o per emetterlo di nuovo.

La SCIA Condizionata è il workflow previsto per gestire i casi di concentrazione di regimi amministrativi. Si applica quando un’istanza può contemplare sia fattispecie soggette a SCIA sia fattispecie subordinate al rilascio di un'autorizzazione. In questi casi, ciascuna fattispecie viene istruita secondo il regime amministrativo di riferimento.

Il workflow utilizza le operazioni già previste per SCIA e Autorizzazione, attivandole in funzione del regime applicabile alla singola fattispecie.

Riferimento normativo: art. 19-bis, comma 3, L. 241/1990.

Il workflow riguarda il procedimento di riconoscimento degli stabilimenti nei settori degli alimenti, dei mangimi e dei sottoprodotti. L'Autorità Competente Locale (ASL/ATS) verifica i requisiti strutturali e le attrezzature dello stabilimento e rilascia un riconoscimento condizionato. Il riconoscimento diventa definitivo a seguito di un controllo svolto in loco. In caso di esito negativo, l'Autorità può vietare la prosecuzione dell'attività.

La definizione è stata curata dal Gruppo Tecnico, con il supporto di un sottogruppo tecnico-legale dedicato.

Riferimenti normativi: Reg. (UE) 2017/625; Reg. (CE) 852/2004, 853/2004, 183/2005, 1069/2009 e 210/2013.

Il CERS formalizza nelle Specifiche Tecniche il flusso già attivo in alcuni contesti territoriali e ha l’obiettivo di semplificare la comunicazione di cessazione dell'attività d'impresa.

Perché è stato introdotto: la D.G.R. Lombardia n. XI/6591 del 30/06/2022 attua l'art. 6 della L.R. 11/2014 e razionalizza gli adempimenti che le imprese devo presentare al Registro Imprese/REA e come tale documentazione viene inoltrata al SUAP. In particolare, il flusso elimina il doppio adempimento, secondo il principio once-only: l'impresa presenta la comunicazione una sola volta, tramite il front end della Camera di Commercio competente e utilizzando la modulistica del Registro Imprese (D.M. 18 ottobre 2013). Non è quindi necessario ripetere la stessa comunicazione anche al SUAP.

Come funziona:

- quando l'evento viene registrato nel Registro Imprese, quest'ultimo genera automaticamente la pratica SUAP, conforme alle Specifiche Tecniche, e la invia direttamente al Back-office SUAP competente;

- il Back-office SUAP inoltra la pratica agli Enti Terzi interessati, assolvendo così agli obblighi informativi verso le altre amministrazioni;

- la pratica è compilata da una fonte dati autorevole, per questo motivo non sono previste richieste di integrazione o di conformazione;

- il flusso si configura come una comunicazione unidirezionale e, pertanto, non prevede un esito finale.

Il processo alimenta anche il repertorio delle notizie economico-amministrative (REA) della Camera di Commercio, che confluisce nel fascicolo informatico d'impresa (art. 2, comma 1, lett. b, L. 580/1993).

Quando si applica: il CERS è un workflow previsto dalle Specifiche Tecniche, ma la sua attivazione dipende dalla disciplina vigente nel territorio di riferimento: le Specifiche, infatti, non ne rendono obbligatoria l’applicazione in modo automatico.

Pertanto:

- nei territori in cui una norma regionale prevede questo meccanismo, i SUAP devono essere in grado di ricevere e gestire le pratiche CERS generate dal Registro Imprese e di inoltrarle agli Enti Terzi interessati;

- nei territori in cui non esiste una specifica norma regionale, la comunicazione di cessazione può seguire le modalità ordinarie e non è obbligatoria l’applicazione del workflow CERS.

Le Specifiche Tecniche garantiscono quindi che, nei contesti in cui una Regione introduce questa semplificazione, il flusso sia gestito in modo standard e interoperabile. Il modello resta inoltre disponibile anche per le Regioni che in futuro decidano di adottare misure di semplificazione analoghe.

Riferimenti normativi: D.G.R. Lombardia n. XI/6591 del 30/06/2022; L.R. Lombardia 11/2014, art. 6.

Il workflow di Autotutela disciplina la riapertura di un procedimento già concluso. Può essere utilizzato per annullare un provvedimento oppure per adottarne uno nuovo, nei casi in cui il precedente sia stato annullato per vizi relativi ad atti endoprocedimentali.

Il procedimento è avviato dal Back-office SUAP e notificato all'impresa e agli Enti Terzi coinvolti. Si sviluppa come un procedimento di seconda istanza, nell’ambito del quale l'impresa può presentare integrazioni, spontaneamente oppure su richiesta. Al termine, il nuovo provvedimento viene trasmesso a tutti i soggetti coinvolti, compreso il Registro Imprese.

Riferimenti normativi: artt. 21-octies, 21-nonies e 21-decies L. 241/1990.

Oltre all'evoluzione dei workflow procedimentali, Approved02 amplia in modo significativo il modello di interoperabilità previsto dalle Specifiche Tecniche, introducendo nuovi strumenti di cooperazione applicativa e supportando ulteriori scenari amministrativi.

L'obiettivo è consentire una gestione più completa e strutturata delle comunicazioni tra i soggetti coinvolti nel procedimento, favorendo la digitalizzazione dell'intero ciclo di vita della pratica.

Le principali innovazioni riguardano:

- la Comunicazione Generica;

- il rafforzamento del coinvolgimento degli Enti Terzi;

- il supporto alla Conferenza dei Servizi;

- l'integrazione con lo Sportello Unico Digitale ZES.

La Comunicazione Generica è una funzionalità prevista in ambito di interoperabilità che consente ai soggetti coinvolti nel procedimento di scambiare informazioni di diversa natura, al fine di fornire maggiori dettagli che non sono codificati nelle Specifiche Tecniche.

L'introduzione di questo strumento aumenta la flessibilità operativa del sistema, consentendo di gestire comunicazioni rilevanti ai fini del procedimento senza dover prevedere workflow dedicati per ogni possibile casistica.

Approved02 consente all'Ente Competente la possibilità di coinvolgere nel procedimento altri Enti Terzi, definiti nelle Specifiche Tecniche come Enti Interessati. Questi enti supportano l'Ente Competente nella fase istruttoria, mettendo a disposizione le proprie competenze su specifici aspetti settoriali. Il loro contributo è finalizzato a raccogliere tutti gli elementi utili nella definizione dell'esito finale dell’istanza.

Perché è stato introdotto

Il confronto con i territori ha evidenziato che spesso non è possibile individuare e censire in anticipo tutte le amministrazioni che possono intervenire in un procedimento. Questo dipende sia dalla frammentazione delle competenze amministrative sia dalla complessità di alcuni procedimenti. Per questo motivo, si è resa necessaria una modalità che consentisse di coinvolgere ulteriori amministrazioni anche nel corso del procedimento, senza ricorrere a canali esterni.

Come funziona:

- l'Ente Competente coinvolge l'Ente Interessato e dialoga direttamente con lui attraverso il nuovo servizio di interoperabilità et_to_et, dedicato alla comunicazione tra Enti Terzi;

- l'Ente Interessato contribuisce alla fase istruttoria con le proprie valutazioni, mentre l'Ente Competente mantiene la responsabilità delle conclusioni da trasmettere al SUAP;

- il coinvolgimento dell'Ente Interessato viene tracciato nel Sistema Informatico degli Sportelli Unici (SSU): l'ente viene registrato nel descrittore dell'istanza tramite il Catalogo e il Back-office SUAP riceve una notifica.

Approved02 introduce specifici adeguamenti per consentire la gestione interoperabile delle attività connesse alla Conferenza dei Servizi.

Le nuove funzionalità consentono di rappresentare digitalmente le principali fasi del procedimento collegiale, favorendo lo scambio di informazioni tra le amministrazioni coinvolte e garantendo una maggiore tracciabilità delle determinazioni espresse nel corso della Conferenza.

Riferimento normativo: articoli 14 e seguenti della Legge 7 agosto 1990, n. 241.

Approved02 introduce gli elementi necessari a supportare l'interoperabilità con lo Sportello Unico Digitale delle Zone Economiche Speciali (S.U.D. ZES).

L'obiettivo è consentire una gestione coordinata dei procedimenti che ricadono nelle Zone Economiche Speciali, attraverso un modello di cooperazione coerente con l'ecosistema nazionale SUAP e con i principi di interoperabilità definiti dalle Specifiche Tecniche e dal MoDI.

Riferimento normativo: Decreto-Legge 19 settembre 2023, n. 124.

Successivamente all'approvazione di Approved02 sono emerse alcune criticità legate all'interpretazione delle Specifiche Tecniche e alla concreta implementazione dei flussi previsti.

L'attività di supporto, il confronto con i territori e le segnalazioni raccolte attraverso i canali ufficiali hanno evidenziato la presenza di alcuni aspetti che richiedevano chiarimenti o correzioni puntuali.

Per questo motivo, il Gruppo Tecnico ha predisposto un aggiornamento successivo, denominato Approved02.1, con l'obiettivo di:

- correggere anomalie emerse dopo la pubblicazione di Approved02;

- introdurre una soluzione alternativa per la gestione delle pratiche nei casi in cui i workflow esistenti presentino criticità applicative.

Approved02.1 deve quindi essere inteso come un affinamento dell'impianto già definito in Approved02.

Le novità introdotte con Approved02.1 si collocano in due ambiti distinti e complementari.

1. Interventi correttivi (Bug Fix)

Gli adeguamenti tecnici di Approved02.1 rientrano nella categoria dei Bug Fix, ossia interventi correttivi minimi finalizzati a risolvere anomalie marginali, senza modificare le funzionalità esistenti né il comportamento dei sistemi.

Le modifiche riguardano:

- l'aggiornamento degli State Diagram, per allinearli ai flussi e ai servizi esposti;

- l'adeguamento degli attributi dei servizi e degli eventi trasmessi, per garantire il corretto uso delle funzionalità e allineare la comunicazione tra Enti Terzi a quella già definita con i SUAP;

- l'introduzione di un parametro per la comunicazione degli errori con il sistema ComUnica;

- l'ottimizzazione dei servizi del Catalogo SSU, per migliorare il recupero dei metadati utili ai procedimenti.

La mancata applicazione di tali interventi potrebbe compromettere la corretta esecuzione dei flussi operativi, lo scambio di informazioni tra SUAP ed Enti Terzi e la piena tracciabilità degli eventi verso il Catalogo, incidendo sull'affidabilità complessiva del sistema.

2. Introduzione del Workflow Semplificato

La seconda novità introdotta con Approved02.1 è il Workflow Semplificato, un flusso di alto livello, alternativo e facoltativo rispetto ai workflow già definiti. Questo strumento è stato previsto per gestire i casi in cui l'applicazione dei flussi ordinari incontra criticità interpretative o implementative. Le FAQ successive ne descrivono caratteristiche, ambito di utilizzo e rapporto con i workflow esistenti.

Il Workflow Semplificato è un modello di gestione delle pratiche SUAP introdotto con Approved02.1 come 'alternativa ai workflow attualmente definiti nelle Specifiche Tecniche.

Perché è stato introdotto: il Gruppo Tecnico ha analizzato le segnalazioni arrivate tramite il sistema di ticketing e i canali di supporto. Dall’analisi sono emersi elementi che non permettono una corretta gestione dei flussi operativi:

- interpretazioni diverse del quadro normativo;

- specificità delle organizzazioni territoriali;

- scenari o complicazioni operative non previsti in fase di progettazione.

Per questo motivo, il Gruppo Tecnico ha proposto un modello semplificato, che consente ai soggetti coinvolti di sviluppare sistemi nel rispetto della normativa vigente e in coerenza con i propri modelli organizzativi.

Come è strutturato: il flusso si articola in tre momenti fondamentali del ciclo di vita della pratica SUAP (presentazione, istruttoria e conclusione), che possono ricorrere nei diversi regimi amministrativi. Per ciascuno di essi sono individuate le macro-attività necessarie alla gestione e alla conclusione della pratica.

Cosa lo distingue dai workflow ordinari: il modello non introduce una sequenza obbligatoria di passaggi né controlli procedurali obbligatori, in particolare nella fase istruttoria. Le amministrazioni possono quindi utilizzare in modo flessibile le operazioni già previste dalle Specifiche Tecniche, adattando la gestione della pratica alle diverse situazioni amministrative, territoriali e organizzative.

Strumenti a supporto: il Gruppo Tecnico ha predisposto una linea guida per facilitare la lettura e l’applicazione del Workflow Semplificato. La linea guida include anche una mappatura dei servizi che ciascun componente può implementare in relazione alle attività del procedimento. 

Quando posso utilizzarlo: Il Workflow Semplificato può essere adottato nei casi in cui ci sono criticità di ordine interpretativo o implementativo nell'applicazione dei workflow ordinari. Il Gruppo Tecnico, quindi, ne raccomanda l’applicazione esclusivamente in tali contesti e ne esclude il suo utilizzo nei casi dei workflow standardizzati e consolidati. 

No. Il Workflow Semplificato costituisce uno strumento aggiuntivo e transitorio e non va in conflitto con i workflow definiti nelle Specifiche Tecniche.

Il suo utilizzo è previsto nei casi in cui i workflow delle Specifiche Tecniche evidenzino comportamenti inattesi, consentendo di gestire eventuali esigenze derivanti da variazioni interpretative o organizzative. 

Il ricorso al Workflow Semplificato sarà possibile fino al consolidamento dei workflow previsti dalle Specifiche Tecniche, che saranno progressivamente evoluti con l’obiettivo di definire flussi standardizzati e uniformemente applicabili su tutto il territorio nazionale.