SUAP

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.

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

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.

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 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…).

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