SUAP_SUE_Richieste_di_Supporto_Open_Data.csv

ID Ticket AgID;Richiesta;Risposta;Note Integrative
n.a.;I servizi di monitoraggio descritti nel capitolo 9 delle ST, dove saranno esposti? e saranno disponibili anche per gli ET?;L'e-service per la consultazione dei dati di monitoraggio sarà esposto tramite PDND e sarà disponibile per il FO SUAP, il BO SUAP e per gli ET. La definizione di tale servizio, al fine di rendere più efficiente la sua gestione, è affidata al Fornitore del Catalogo SSU. L'attuale roadmap prevede la disponibilità della prima release entro dicembre 2024.;n.a.
n.a.;Come saranno identificabili i tipi di procedimento SUAP?;"Sarà presente un codice per capire quali procedimenti SUAP sono coinvolti. Saranno gli ET a caricare nel catalogo i procedimenti di loro competenza.
In Cruise, partendo dal nome, sarà possibile capire quali procedimenti sono di competenza da veterinaria e quali da prevenzione.";n.a.
n.a.;Casistiche in cui è applicato il silenzio assenso.;Tutti i processi hanno dei timer, se non si risponde nei tempi si applicherà il silenzio assenso;n.a.
n.a.;In un procedimento, nel primo step gli Enti Terzi inviano l'atto di ricevimento condizionato,  che viene notificato al presentatore di istanza. In secondo luogo, se tutto va bene, gli Enti Terzi inviano un secondo atto autorizzatorio definitivo, senza che il SUAP abbia espressamente chiesto loro qualcosa (nel mezzo di questo riconoscimento ci possono essere richieste di integrazione). Come viene gestita qyesta casistica nelle specifiche tecniche?;Questa fattispece non c'è nelle specifiche, perchè l'ultima azione è l'emissione della conclusione.;n.a.
n.a.;Una volta ottenuto il finanziamento, esiste un ambiente di test BBT intermedio da utilizzare durante gli sviluppi, prima di effettuare il test BBT finale?;Il fornitore del catalogo metterà a disposizione gli ambienti di test.;n.a.
n.a.;Quando sarà possibile l'avvio delle attività di test delle componenti?;Tutto deve essere funzionante entro 12 mesi dalla disponibilità del catalogo, e il catalogo sarà disponibile alla fine di luglio 2024.;n.a.
n.a.;Quali sono i tempi necessari all'abilitazione ai finanziamenti per gli ET?;Probabilmente si dovrà attendere il periodo Settembre/Ottobre 2024 (i finanziamenti sono a consuntivo);n.a.
n.a.;"Approfondimento su interfacce:
Servirebbe un approfondimento sulle interfacce descritte nel file https://github.com/AgID/specifiche-tecniche-DPR-160-2010/blob/main/openAPI/catalogo-ssu_meta.yaml, che espongono, tra gli altri, i metodi per recuperare i domini, gli elenchi di enti accreditati e gli schemi di validazione degli allegati, in particolare ci servirebbero degli esempi per questi scenari d’uso:
-	Recupero dei riferimenti dei backoffice SUAP
-	Recupero dell’elenco dei tipi di procedimento
-	Recupero dello schema xsd o dello schematron per la validazione del’mda di un allegato. A tal proposito sappiamo che l’onere della validazione (xsd e schematron) spetta al FO, ma vi chiediamo un parere anche rispetto all’implementazione di regole di chaching locale, dal momento che comunque utilizziamo gli schemi per recuperare i path relativi a dati di interesse. Es. la localizzazione. Ha senso implementare come ET anche i meccanismi di caching riportati del documento di architettura?";"1.	Recupero dei riferimenti dei backoffice SUAP
Al fine di recuperare i riferimenti dei Back-Office SUAP, associati alle istanze identificate univocamente dal cui, per prima cosa è necessario recuperare il riferimento del Comune, ovvero il suo Codice ISTAT a 6 cifre. Tale Codice ISTAT è identificato tramite l’attributo municipality presente nel relativo Instance Descriptor, recuperabile dal Catalogo SSU tramite il path catalogo-ssu_to_et/instance_descriptor/{cui_uuid}.
Una volta in possesso del riferimento comunale, è possibile invocare catalogo-ssu_meta/suaps-by-municipality/{municipality_list} per recuperare tutte le versioni dei componenti SUAP relativi al codice ISTAT del comune (municipality_list). Ottenuta la risposta, è necessario selezionare solamente la componente che ha lo state=Active. 
Si segnala che l’oggetto restituito in risposta a questa richiesta è soggetto ad un aggiornamento al fine di perfezionare la sua struttura, che verrà sostituita dall’attuale GenericEntity con una ComponentEntity. 
2.	Recupero dell’elenco dei tipi di procedimento
Al fine di recuperare l’elenco dei tipi di procedimento, è necessario recuperare il codice e la versione della singola fattispecie di procedimento (usecase_proceeding), selezionando quelli di proprio interesse, filtrando per l’attributo competent_administration che indica l’amministrazione responsabile. Il codice e la versione sono presenti nell’Instance Descriptor:
•	instance-descriptor-schema/usecase_proceedings[]/code
•	instance-descriptor-schema/usecase_proceedings[]/version
Una volta in possesso di queste informazioni, è possibile invocare il path catalogo-ssu_meta/usecase-proceedings/{usecase_proceedings_id}/{usecase_proceedings_version}/usecase-proceedings per recuperare l'anagrafica del procedimento.
3.	Recupero dello schema xsd o dello schematron per la validazione del’mda di un allegato
Al fine di recuperare i validatori dell’MDA di un allegato, è necessario, come indicato nel punto precedente, recuperare il code e la version degli usecase_proceedings di proprio interesse. 
Una volta in possesso di queste informazioni, si può procedere col recupero dei riferimenti del procedimento, proceeding_id e proceeding_version,  mediante l’invocazione del seguente path catalogo-ssu_meta/usecase-proceedings/{usecase_proceedings_id}/{usecase_proceedings_version}/usecase-proceedings. L’identificativo del procedimento e la sua versione possono essere utilizzati nella successiva richiesta, che verrà utilizzata per recuperare i riferimenti degli allegati, di tipo strutturato, e la loro relativa versione: catalogo-ssu_meta/proceeding/{proceeding_id}/{proceeding_version}/attachments. 
Ottenuti così i riferimenti dell’allegato che si vuole validare, è possibile recuperare il suo XSD e Schematron tramite i seguenti path:
•	catalogo-ssu_meta/attachment/{attachment_id}/{attachment_version}/xsd
•	catalogo-ssu_meta//attachment/{attachment_id}/{attachment_version}/schematron
Analogamente, in caso si volesse recuperare i validatori per i Form (moduli presentati per procedimento), è possibile ripetere gli step preliminari per ottenere i riferimenti del procedimento, proceeding_id e proceeding_version. Dopodiché, è necessario recuperare i riferimenti del form di proprio interesse, form_id (code) e form_version, utilizzando il path catalogo-ssu_meta/proceeding/{proceeding_id}/{proceeding_version}/form. I validatori possono essere così recuperati tramite i seguenti path:
•	catalogo-ssu_meta/form/{form_id}/{form_version}/xsd
•	catalogo-ssu_meta/form/{form_id}/{form_version}/schematron
In merito alla domanda riguardante l’implementazione di regole di caching locale, confermiamo che è possibile implementare tali logiche, suggeriamo inoltre di creare solamente il caching delle entità utilizzate.";n.a.
n.a.;"Approfondimento su tipologie documenti:
Nella documentazione fornita non siamo riusciti a trovare nelle interfacce, se sia disponibile un elenco delle tipologie di allegato per procedimento e se eventualmente esista un servizio per recuperare la relativa lista. Ad esempio, vorremmo capire come fare a distinguere i documenti della pratica suddivisi per tipologia (es. planimetria, doc di progetto, etc). Piuttosto eventuali documenti del procedimento. Es. integrazioni e pareri inviati da altri enti.
Vorremmo capire, inoltre, la differenza tra Attachments e Document; i documenti sono recuperati da BO SUAP utilizzando i dati contenuti nella send_instance (cui, resource_id).
Infine, vorremo avere dettagli sulla instance contenuta nell'instance_descriptor recuperata dal catalogo SSU, e capire, anche con qualche esempio, la differenza con l’instance inviata all'ente terzo dal BO.";"I documenti che sono nella disponibilità degli Enti Terzi sono indicati tramite i Form, ovvero i moduli e tramite Allegati, recuperabili tramite l’Instance Descriptor:
•	instance-descriptor-schema/usecase_proceedings/form 
•	instance-descriptor-schema/usecase_proceedings/attachments
Si evidenzia che tali documenti sono aggregati per singolo procedimento e che, attualmente, non è disponibile alcun metodo per recuperare la lista delle tipologie che identificano la natura di un documento (planimetria, doc di progetto, …). Tuttavia, recuperando tali oggetti, con la possibilità di filtrare solamente quelli di proprio interesse, è possibile analizzare l’attributo filename, che determina la semantica del documento, e description al fine di comprendere lo scopo di utilizzo di tale risorsa. Nelle prossime lavorazioni, è prevista una modifica che introdurrà nel descrittore anche i riferimenti univoci code e version, finalizzati al recupero dell'anagrafica presente nel Catalogo SSU.
Per quanto riguarda invece l’identificazione dei documenti scambiati durante le fasi del procedimento, come ad esempio le richieste di integrazione e i pareri inviati dagli Enti Terzi, questi saranno presenti nelle fasi di interazione tra Back-Office ed Ente Terzo. Durante questo scambio, ad esempio per il trasferimento dei pareri, tramite il path bo_to_et /send_conclusions, sarà possibile utilizzare i riferimenti trasmessi, cui e resource_id,  per poter richiedere successivamente il documento tramite il path et_to_bo/instance/{cui_uuid}/document/{resource_id}.
In merito ai pareri, si evidenzia che, a valle dell’invio di tutti i pareri degli Enti Terzi verso il Back-Office, quest’ultimo è incaricato di trasmettere ad ognuno di essi il parere conclusivo del procedimento, emesso dal SUAP, in funzione dei pareri pervenuti.
Per chiarire la differenza tra Attachments e Document, si precisa che, assunto il fatto che il Document è inteso come Form (moduli presentati per procedimento), considerato che tale riferimento è presente OpenAPI solamente nel path /instance/{cui_uuid}/document/{resource_id}, questo rappresenta il modulo digitale di uno specifico procedimento (vedi descrizione catalogo-ssu_meta//proceeding/{proceeding_id}/{proceeding_version}/form). Diversamente, gli Attachments rappresentano gli allegati associati ad un procedimento e sono consultabili tramite il path instance-descriptor-schema/usecase_proceedings/attachments.
Per concludere, in merito all’ultimo quesito, si vuole precisare che l’attributo instance, presente nell’Instance Descriptor, rappresenta la porzione di istanza relativa al procedimento, associata ad ogni specifica fattispecie (usecase_proceeding). Diversamente, l’instance inviata dal Back-Office all’Ente Terzo, tramite path et_to_bo/send_instance, riporta solo i riferimenti dell’istanza, ovvero:
•	cui e version, per permettere il recupero dell’Instance Descriptor
•	instance_index, contenente la mappatura dei riferimenti dei moduli e degli allegati con i relativi resource_id assegnati dal Back-Office:
o	instance-descriptor-schema/usecase_proceedings/instance/ref 
o	instance-descriptor-schema/usecase_proceedings/attachments/ref 
 ";n.a.
n.a.;"Ambienti di test o progetti di esempio:
Esistono ambienti di test per simulare un BO del SUAP ed il Catalogo SSU. E quindi progetti SoapUI, Postman o altro?
Di seguito alcuni esempi di chiamata che ci interesserebbe ricevere:
-	Esempio invio istanza Enti Terzi (send_instance)
-	Esempio instanceDescriptor (Catalago SSU); return GET /instance_descriptor/{cui_uuid} 
-	Esempio per il recupero degli Attachments contenuti nell'instanceDescriptor?";"Considerata la natura della domanda fuori dalle disponibilità di AgID non avendo attività di sviluppo, si riporta la risposta condivisa da InfoCamere:
Purtroppo, non c'è ancora un BackOffice SUAP da poter utilizzare. Entro ottobre dovrebbe esserci il Back Office del SUAP Camerale con il quale poter testare queste due integrazioni. 
Tuttavia, per rispondere al secondo punto, possiamo fornire degli esempi di CUI che possono essere utilizzati per i test:
•	78ee1b7d-0da6-4b31-80df-cfeddaa346c3
•	7a36d0f4-72c8-40f8-82be-86201e09def6

Per ogni approfondimento di merito si suggerisce di rivolgersi direttamente ai referenti di Infocamere.";n.a.
n.a.;"Repository xsd procedimenti SUAP:
Il repository di riferimento degli schemi XSD afferenti ai procedimenti del SUAP ci risulta essere: https://github.com/italia/moduli-pa/tree/master/Moduli_PA/SUAPAl. In questo repository gli schemi sono fermi a 5 anni fa. Ci confermate che il repository sia questo? In caso negativo ci indicate il repository corretto?
Oltre al repository degli schemi XSD, avete un repository dei facsimili delle modulistiche in formato compilatore oriented. In word, pdf o altro.";"Si evidenzia che il repository Moduli_PA/SUAPA è stato usato nell’ambito dell’Agenda per la Semplificazione 2020-2026 e 2020-2023 negli anni passati, e riporta gli XSD approvati negli Accordi della Conferenza Unificata per l'approvazione dei moduli unificati e standardizzati in materia di attività edilizia e commerciali e assimilate. Si evidenzia che gli stessi XSD sono stati utilizzati per il primo popolamento del Catalogo SSU.
Per ogni approfondimento in merito a dove recuperate i fac-simile della modulistica, si suggerisce di rivolgersi direttamente ai referenti del Dipartimento della Funzione Pubblica.";n.a.
n.a.;"Se fosse confermato il repository degli XSD al punto precedente, tra questi non compare l’AUA (Autorizzazione Unica Ambientale). Essendo questo tra i procedimenti di interesse di Arpa, ed è in capo al SUAP, vi chiediamo come si intende gestire questa tipologia di procedimento.
A tal proposito Arpa risulta interessata anche ad altre tipologie di procedimenti che non ritroviamo nella lista, come ad esempio le “SCIA stazione radiobase”. In generale con l’introduzione delle nuove modalità operativa e l’obbligo di trasferire le pratiche vi interoperabilità, e non più via PEC, come si intende gestire i procedimenti per i quali non è ancora definito uno schema XSD e non saranno censiti come procedimenti nell’SSU?";"Considerata la natura della domanda fuori dal perimetro tecnico gestionale di AgID, si riporta la risposta condivisa dal Dipartimento della Funzione Pubblica:
Confermiamo che nel repository nativamente verranno inseriti tutti i moduli strutturati nazionali o approvati in Conferenza Stato-Regioni. Tuttavia, si evidenzia che, per alcune specifiche modulistiche, potrebbero esserci delle personalizzazioni territoriali, le quali potranno comunque essere caricate sul Catalogo.
Per quanto riguarda l'Autorizzazione Unica Ambientale (AUA), invece, non esiste in effetti un modello strutturato a livello nazionale. Tuttavia, la Lombardia ha definito un XSD strutturato. Pertanto, Infocamere, in qualità di gestore, provvederà a caricare tali modelli sul Catalogo. Per qualsiasi ulteriore questione sul tema, si propone di fare un allineamento insieme, con la presenza di Infocamere.
Per ogni approfondimento di merito si suggerisce di rivolgersi direttamente ai referenti del Dipartimento della Funzione Pubblica.";n.a.
4796cc1496b24772965f7f7e37d3a341;"Nel sequence diagram che descrive il processo di Autorizzazione, il primo passo che compie il BO SUAP verso l'ET è una chiamata al servizio notify, ma solo se è stata indetta una CDSS dal SUAP.
L'ET da dove recupera i resource_id per richiedere poi al BO i vari documenti relativi alla pratica (SUAP.XML, MDA.XML e ricevuta.XML)?

Nel caso invece non sia stata indetta una CDSS dal SUAP, il BO SUAP non chiama la notify ma la send_instance passando i resource_id, e quindi l'ET ha poi modo di recupere i documenti XML.";"La CdSS è prevista in tre momenti distinti nel processo di Autorizzazione: 
  - A monte delle istruttorie degli ET, quando il BO analizza l'istanza presentata e riscontra la necessità immediata di convocare la conferenza;
  - Durante le istruttorie, quando un ET riscontra delle criticità e ha la necessità di richiedere la convocazione della CdSS al BO al fine di gestirle unitamente con esso e gli altri ET;
  - A valle delle istruttorie degli ET, quando il BO ha ricevuto tutti i pareri degli ET e non è in grado di redigere le conclusioni a causa di esiti contrastanti tra loro.

Il passo indicato nella richiesta riguarda il primo scenario, ossia il BO ha rilevato delle criticità nell'istanza e non ha ancora inviato a nessun ET i riferimenti alla relativa documentazione. In tale scenario, il BO ha ritenuto che gli ET non debbano ancora avviare le loro istruttorie e dovranno partecipare alla conferenza utilizzando i riferimenti riportati nell'attributo ""cdss_channel"" presente nell'oggetto ""CdssNotifyMessage"" riportato nella chiamata ""/notify"". Tramite le informazioni pervenute nella convocazione, o in alternativa durante la conferenza stessa, un ET potrà richiedere direttamente al BO i vari documenti relativi alla pratica (SUAP.XML, MDA.XML e ricevuta.XML) non dovendo quindi effettuare, in questo caso, una chiamata al path ""/instance/{cui_uuid}/document/{resource_id}"". ";n.a.
ecd6f4fd89544f2d9bb005de89d96cd2;"Nel sequence diagram che descrive il processo di Autorizzazione, i 3 passaggi consecutivi di chiamate dei servizi:
/instance_descriptor/{cui_uuid} esposto dal Catalogo,
/instance/{cui_uuid}/document/{resource_id} esposto dal BO SUAP
/audit esposto dal Catalogo
devono essere fatte da parte dell'ET a prescindere dell'indizione della CDSS da parte del SUAP?";I tre passaggi consecutivi di chiamate indicati nella richiesta sono identificati sul sequence diagram di Autorizzazione con id 13, 15 e 17 e avvengono solo quando il BO ha effettuato una send_instance agli ET coinvolti per inoltrare loro i riferimenti dell'istanza da analizzare. In tale scenario, il BO non ha indetto la CdSS a priori delle istruttorie degli ET e le chiamate indicate permettono ad essi di ottenere l'Instance Descriptor e tutta la documentazione necessaria per avviare le loro istruttorie.;n.a.
cc12256ca6c347e5bb865a6c451bb76b;"Nel sequence diagram che descrive il processo di Autorizzazione, è indicato, come opzionale, che se almeno un ET richiede la CDSS entro i tempi, allora deve inoltrare la richiesta al BO.
Ma se invece la richiesta della CDSS è oltre i tempi?
Inoltre, chi e come stabilisce il criterio per dire se si è nei tempi?";"I tempi procedimentali sono indicati nell'Instance Descriptor nella proprietà ""times"" (schema ""times-schema.yaml"") e riporta tutte le limitazioni temporali per gestire eventuali eventi di lavorazione. In particolare, il numero di giorni limite, a partire dalla data di avvio dell'istanza, entro cui un ET può richiedere la convocazione della CdSS è indicato nell'attributo ""max_gg_cdss_req"". 
Nel caso in cui un ET dovesse effettuare una richiesta di convocazione CdSS al BO superando i tempi previsti da tale attributo, tale richiesta non sarebbe presa in considerazione e il flusso proseguirebbe come indicato nel processo di Autorizzazione. ";n.a.
46878fee1c6047089d5dec4c52fe02c5;"Nel sequence diagram che descrive il processo di Autorizzazione, è indicato che il BO notifica agli ET la convocazione della CDSS col servizio notify (passaggi 27-28).
Quando poi termina la CDSS indetta da un ET, cosa succede?
Nella parte finale del diagramma sono descritti solo i casi di CDSS indetta da SUAP e CDSS non indetta, ma non il caso di CDSS indetta da un ET.";"L'ET non può mai indire la CdSS, ma può solo effettuare una richiesta di convocazione al BO. Il BO, infatti, è l'unica componente in grado di convocare la CdSS.
Il caso in cui l'ET richieda una CdSS per intermediazione del BO, è del tutto riconducibile al caso in cui è stato il BO stesso a richiederla. ";n.a.
5be07cbba5ba4c64b836bcab17215e03;"Nel sequence diagram che descrive il processo di Autorizzazione, dopo il passaggio 71, c'è una parte opzionale con l'indicazione ""se non si applica il silenzio assenso"".
Cosa si intende con ""silenzio assenso""?
Se invece non si dovesse applicare il silenzio assenso, che passaggi occorre seguire?";"Il silenzio assenso si verifica quando non viene comunicato alcun parere esplicito. Questo implica tacitamente la conferma della validità della pratica, permettendo la naturale prosecuzione del procedimento.

Nel processo di Autorizzazione, se non si applica il silenzio assenso, l'ET esprime un suo parere esplicito, sulla base delle proprie istruttorie, che può essere positivo (passaggio 72) o negativo (passaggio 78).
Quindi, al termine del periodo previsto per la ricezione dei pareri (nota alla riga 183), il processo prosegue secondo i due possibili sviluppi:
   • Il BO convoca la CdSS, in quanto non è in grado di formulare le sue conclusioni a causa dei pareri contrastanti degli ET ;
   • Il BO notifica le conclusioni (autorizzazione concessa o negata, rispettivamente righe 203 o 219) al FO in base agli esiti ricevuti dagli ET.";"Richiedente
Grazie per la risposta.
Non capisco però dove sia la nota alla riga 183 e le righe 203 e 219: il sequence diagram dell'Autorizzazione si ferma al passo 113.

Operatore
La nota presente nella riga 183 è la seguente: ""Note over B,E: concluso tempo ricezione pareri o tutti gli ET hanno inviato parere (compreso silenzio assenso)"".
Purtroppo le note e gli ""alt"" non possono essere identificati tramite un numero nel diagramma, come avviene invece per le chiamate effettuate dai componenti. Per ovviare al problema ho usato i riferimenti alle righe di codice del file mermaid."
340887f5a6074b4c88beda00d7ef140e;"Nel sequence diagram che descrive il processo di Autorizzazione, al passaggio 78-79, a fronte di un parere esplicito negativo c'è la chiamata dell'ET al servizio /send_conclusions esposto dal BO, in cui dallo Yaml si evince che il tag ""conclusions_type"" deve valere ""suspension_requested"".
Perchè ci deve essere una sospensione se il parere esplicito è NEGATIVO?
Quale deve essere il criterio di termine della sospensione e che azioni deve prendere l'ET?";"Confermiamo la sua assunzione in merito alla segnalazione posta e confermiamo che è attualmente in corso la riformulazione dell'attributo ""suspension_requested"" per mantenere una corretta concordanza con l'oggetto (NegativeOutcomeRequired) a cui è associato.
Tali aggiornamenti sono soggetti ad un processo di approvazione e la loro pubblicazione sarà realizzata nei modi previsti dalla norma.";n.a.
117a32873b4e4a7fb517294727e91dee;"Nel sequence diagram che descrive il processo di Autorizzazione, al passaggio 80-81, l'ET chiama il servizio /audit del Catalogo.
Manca l'indicazione dell'ET che fa la chiamata. E' corretto?";"Confermiamo la sua assunzione in merito alla segnalazione posta. 
Ci teniamo a precisare che le Specifiche Tecniche sono costantemente soggette a verifica e aggiornamento al fine di risolvere qualsiasi criticità riscontrata e tale segnalazione risulta essere già gestita nei vari cicli di revisione periodica.
Tali aggiornamenti sono soggetti ad un processo di approvazione e la loro pubblicazione sarà realizzati nei modi previsti dalla norma.";"Richiedente
Grazie. Quindi c'è una segnalazione in merito che presumibilmente porterà ad una nuova definizione del passo indicato, in cui verrà esplicitata l'indicazione dell'ET?
Lo yaml verrà poi aggiornato in una cartella ""approved03"" ?

Operatore
È attualmente in corso il secondo ciclo di aggiornamento delle Specifiche Tecniche e tali modifiche sono gestite nel branch ""mantaince002"". Una volta completato il suo ciclo di verifica, a valle di tutte le modifiche proposte, queste saranno disponibili nel branch ""approved02"" e solo a valle delle ultime approvazioni verranno riportate nel branch ""main"".
Approfittiamo per precisare che:
- il branch ""mantainceXXX"" è utilizzato per proporre le modifiche in corso di aggiornamento;
- Il branch ""approvedXXX"" riporta le Specifiche aggiornate in attesa dell'approvazione ufficiale;
- Il branch ""main"" riporta le Specifiche Tecniche approvate e pubblicate ufficialmente nei modi previsti dalla norma.

Richiedente
Grazie delle precisazioni. Quindi fa fede solo quanto pubblicato in ""main"", in quanto tratta specifiche approvate. Avevo erroneamente ritenuto di poter usare quanto presente in ""approved02"".
Ogni volta che viene aggiunta/modificata una specifica sul ""main"" viene data una qualche comunicazione o aggiunta una nota in qualche punto sulla piattaforma github che consenta di capire che c'è stata una variazione?
Dove trovo la norma cui fa riferimento?

Operatore
Le comunichiamo che può procedere con la consultazione delle variazioni presenti nel branch ""approved01"", considerato che, in data 02/05/2024, si è concluso il primo ciclo di aggiornamento delle Specifiche Tecniche. Tuttavia, la pubblicazione ufficiale necessaria per aggiornare tali variazioni nel branch ""main"" non è ancora avvenuta.

Tali aggiornamenti e modifiche sono regolamentate dall'art. 3 del Decreto Interministeriale del 26 settembre 2023 SUAP (pubblicato in Gazzetta ufficiale n.276 del 25 novembre 2023), che affida al Gruppo Tecnico il ruolo di mantenere costantemente aggiornate le Specifiche Tecniche, in risposta alle evoluzioni normative e tecnologiche, nonché alle variazioni per esigenze operative (comma 1).

Richiedente
Che modalità usa Agid per avvisare che c'è stata una variazione? Dobbiamo noi monitorare continuamente la piattaforma di Github per vedere se la cartella ""main"" ha data di aggiornamento recente, o c'è un qualche punto dove vengono pubblicati gli avvisi?

Operatore
Le comunichiamo che è stata pubblicata una notizia (https://www.suapsue.gov.it/news/?news_id=26) per condividere ufficialmente link GitHub (https://github.com/AgID/specifiche-tecniche-DPR-160-2010/tree/approved01) dove è possibile consultare la nuova versione delle Specifiche Tecniche di interoperabilità SUAP.
La invitiamo a monitorare la sezione News (https://www.suapsue.gov.it/news) del sito di progetto “Digitalizzazione delle procedure SUAP e SUE"" per verificare i prossimi aggiornamenti e novità in merito."
e50b438519ef45a4b260bea69fd44299;"Nel sequence diagram che descrive il processo di Autorizzazione, al passaggio 88-89, il BO comunica all'ET col servizio /notify l'indizione della CDSS.
Ma la notifica all'ET non era già stata fatta al passaggio 5-6?";"I due momenti indicati nella richiesta fanno parte di due scenari differenti che non si susseguono.
I passaggi 5 e 6 avvengono prima dell'avvio delle istruttorie degli ET, poichè il BO ha riscontrato delle criticità durante le sue analisi formali e quindi convoca prontamente la CdSS. 
Al contrario, i passaggi 88 e 89 avvengono a seguito delle istruttorie degli ET, Il BO ha raccolto tutti pareri, riscontrato delle discordanze nei loro esiti e necessita, quindi, di convocare la CdSS per identificare una conclusione comune.";n.a.
fb6600b7830747f795c8c8cc0d54c40a;"Sia nel caso di Autorizzazione che di SCIA, occorre sapere l'endpoint del BO da contattare.
Per ottenerlo è corretta la seguente procedura?
1) chiedo al catalogo l'ID del suap tramite il servizio /suap/{municipality}, passando il comune;
2) poi chiedo al catalogo l'endpoint tramite il servizio /suap/{suap_id}/{suap_version}/backoffice-system, con i dati ""ID, versione"" ottenuti al punto 1.
Come va fornito il comune al punto 1? Per nome esteso (es: Torino) o codificato in qualche modo?";"La procedura indicata nella richiesta è corretta. 
La chiamata indicata al punto 1 è necessaria per ottenere i riferimenti di un singolo BO SUAP associato ad un comune. Il riferimento comunale che deve essere passato al punto 1 è il suo codice ISTAT a 6 cifre. Tale Codice ISTAT è identificato tramite l’attributo municipality presente nel relativo Instance Descriptor, recuperabile dal Catalogo SSU tramite il path catalogo-ssu_to_et/instance_descriptor/{cui_uuid}.
Si segnala che l’oggetto restituito in risposta al path /suap/{municipality} è soggetto ad un aggiornamento al fine di perfezionare la sua struttura, che verrà sostituita dall’attuale GenericEntity con una ComponentEntity. Tuttavia, id e version sono comunque già disponibili anche nel GenericEntity.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
3586a49924cc41449773792d95ea861b;"Nel sequence diagram della SCIA, al passo 1 il BO chiama il servizio /send_instance dell'ET.
Nella request manca il nome del file MDA allegato alla pratica. E' corretto?
Nell'oggetto instance_index c'è un resource_id, ma anche nell'oggetto general_index c'è un resource_id in ogni allegato. Nel sequence diagram si dice di usare quello in istance_index. Il resource_id quindi è unico per tutta la pratica o ci sono più resource_id: uno generale e uno diverso per ciascun documento allegato?";"La send_instance prevede l'inoltro dell'oggetto ""SendInstanceRequest"" composto da:
 - cui
 - instance_descriptor_version
 - instance_index
 - general_index
Gli ultimi due oggetti, instance_index e general_index, contengono i documenti relativi alla pratica, identificati univocamente tra loro mediante l'utilizzo della chiave resource_id. Tale chiave di riferimento è univoca, per erogatore e CUI.UUID, pertanto non è possibile ritrovare due resource_id uguali in nessun caso.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";"Richiedente
A questo punto ho difficoltà a capire la differenza tra questi due oggetti:
1) InstanceIndex è dichiarato come ""indice istanza"" ed è un array;
2) GeneralIndex è dichiarato come ""indice allegati trasversali"" ed è un array.
Entrambi hanno i resource_id per ciascuna risorsa in essi contenuta.
L'erogatore, cioè FO, BO o ET, insieme al cui_uuid sono la coppia che rende univoca l'istanza, e all'interno dell'istanza ogni resource_id rende univoco ogni risorsa. In totale quindi la tripletta non potrà mai essere ripetuta. Corretto?
Ma allora perchè non avere un unico oggetto Index che contenga tutti gli allegati (SUAP.XML, MDA.XML, ricevuta.XML, PDF e quant'altro) ?

Operatore
IntanceIndex e GeneralIndex contengono una lista di documenti associati ad una istanza che sono identificati univocamente da un proprio resource_id.
Il GeneralIndex è stato introdotto durante le fasi di aggiornamento delle Specifiche Tecniche, quando il Gruppo Tecnico ha riscontrato la necessità di colmare un delta informativo, che talvolta non è immediatamente nelle disponibilità del SUAP. Tali dati, correttamente non presenti nell'Instance Descriptor anche per ragioni di privacy, sono stati definiti in questo nuovo indice di allegati trasversali.
Volendo fare un confronto tra il GeneralIndex e l'InstanceIndex, è possibile affermare che il GeneralIndex prescinde dalle fattispecie di procedimento, per tale motivo riporta una lista specifica di tipologie di documento che non vengono invece gestite nell'InstanceIndex."
d9bb0e2eb98241c5934bcbfbe6765bcb;"Nel sequence diagram della SCIA, il servizio /instance_descriptor/{cui_uuid} esposto dal Catalogo serve per ritornare all'ET il ""descrittore"".
il descrittore però NON torna i resource_id.
Quindi serve solo a recuperare dall'oggetto usecase_proceedings.instance.activity_model il filename dell'XML MDA, ipotizzando che la dicitura ""filename del modello distinta attivita"" nello yaml indichi l'MDA ?";"La chiamata ""/instance_descriptor/{cui_uuid}"" ritorna l'Instance Descriptor da cui, andando ad analizzare l'oggetto usecase_proceedings.instance.activity_model, sarà possibile recuperare il seguente set informativo legato al documento MDA di proprio interesse:
 - ref
 - filename
 - hash
 - alg_hash
 - mime_type
Per recuperare il resource_id, da utilizzare con la chiamata GET al BO ""/instance/{cui_uuid}/document/{resource_id}"", è necessario utilizzare l'Instance-index trasmesso dal BO tramite la chiamata ""/send_instance"", che riporterà una lista di oggetti con i seguenti attributi:
 - code: codice dello usecase_proceeding 
 - ref: il riferimento presente nell'Instance Descriptor da utilizzare per identificare l'MDA di proprio interesse
 - resource_id: l'id della risorsa da utilizzare per il recupero del documento dal BO
 - hash
 - alg_hash

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
80793c97d2194574b447d3b7a95404d1;"Nel sequence diagram della SCIA, appena prima del passo 7, c'è un loop con la nota ""per ogni procedimento di interesse parte dell'istanza"".
Ma una istanza non è una pratica? Una pratica non è composta da un solo procedimento?
Se nella chiamata al servizio /instance/{cui_uuid}/document/{resource_id} del BO uso (come indicato nella nota) il resource_id di instance_index, che è unico, come posso discriminare per recuperare i vari documenti della pratica (SUAP, MDA, ricevuta) ?";"Una pratica è riconducibile ad una Istanza di un Procedimento SUAP. Tale Istanza, identificata dal CUI e rappresentata dal suo Instance Decriptor, sarà composta da uno o più Fattispecie (usecase_proceedings) che avviano uno o più procedimenti amministrativi sulla base dei dati inseriti nel modulo d'istanza presentato.
Per recuperare un documento associato ad una istanza è necessario:
 - recuperare il suo resource_id dall'instance-index (un array di oggetti contenenti vari resouce_id, univoci, per ogni singolo documento) 
 - invocare il servizio ""/instance/{cui_uuid}/document/{resource_id}"", indicando il resource_id specifico.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
53fad824831e4987b0e0b5f7246327da;"Nel sequence diagram della SCIA, nel servizio /request_integration esposto dal BO, occorre valorizzare l'oggetto AdministrationSchema che contiene ipacode, officecode e version.
Come possiamo trovare gli ultimi 2?

Oltre all'oggetto integration_list, è opzionale l'oggetto integration_document_list, in cui è possibile indicare il resource_id.
Questo è perché si può chiedere una integrazione su un documento esistente?
Però nell'attributo title del resource_id è scritto: id della risorsa ""documento di richiesta integrazioni"", univoco per erogatore e CUI.UUID.
Non mi è chiara questa frase: cos'è l'erogatore? Se il resource_id è univoco allora è possibile richiedere integrazioni solo sulla pratica nel suo complesso e non su un singolo allegato?";"L'oggetto AdministrationSchema rappresenta l'Amministrazione competente censita nel Catalogo SSU e riporta gli attributi:
 - ipacode
 - officecode
 - version.
Per recuperare tale oggetto è possibile invocare il servizio ""catalogo-ssu_meta/proceeding/{proceeding_id}/{proceeding_version}/{municipality}/competent-administration"" che ritornerà proprio l'oggetto ""AdministrationSchema"" .
 
Nel sequence diagram SCIA, al passo 11, un ET può effettuare una richiesta di integrazione mediante il servizio ""/request_integration"" e può associare dentro tale richiesta uno o più documenti di richiesta integrazioni, identificati da un loro resource_id univoco. A seguito di tale richiesta il BO può procedere col recupero di tale documento di richiesta integrazioni mediante il servizio ""/instance/{cui_uuid}/document/{resource_id}"", riportato al passo 13.

Si vuole precisare che la dicitura ""univoco per erogatore e CUI.UUID"" intende dire che il resource_id è assolutamente univoco indistintamente dall'erogatore (FO, BO, ET) o dal cui ad esso associato.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
093b7407ea6c41cc854b54f8853b53c7;Nel sequence diagram della SCIA, nel passo 13, in caso l'ET abbia richiesto integrazioni a più di un documento già presente, il BO dovrà invocare per ognuno il servizio /instance/{cui_uuid}/document/{resource_id} di ET?;"Il servizio invocato dal BO al passo 13 è finalizzato al recupero dei documenti creati dall'ET a seguito di una sua richiesta di integrazione. L'integrazione richiesta dall'ET può riportare una o più motivazioni e uno o più documenti identificati dal resource_id, effettuando un'unica richiesta cumulativa. Pertanto, la chiamata al servizio ""/instance/{cui_uuid}/document/{resource_id}"" ritornerà il singolo documento associato al resource_id indicato nel path.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
389f2c6c586d4e538d066412e106ba42;Nel sequence diagram della SCIA, nel passo 15, nella chiamata al servizio /audit, come deve essere la nomenclatura di <ET> nel campo message ?;"La chiamata al passo 15 per l'audit riporta come identificativo dell'ET il suo id (caratterizzato dalla regex [0-9]{1,10}), recuperabile dall'oggetto ""GenericEntity"" restituito dal servizio ""catalogo-ssu_meta/proceedings-competent-administrations/{id_proceeding_list}"".

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";"Richiedente
Forse mi sono espresso male: ho visto che la codifica deve essere [0-9]{1,10}, ma volevo capire quale valore indicare. Deve essere una codifica dell'ET stabilita a livello nazionale o in altro modo? Chi lo stabilisce e dove recuperare l'elenco degli ET?

Operatore
La codifica dell'ET è definita dal suo ID che è gestito all'interno del Catalogo SSU ed è associato all'entità ""third-party-system"".
È possibile recuperare l'ET di proprio interesse a partire dall'elenco restituito dalla chiamata ""catalogo-ssu_meta/competent-administration/{competent_administration_ipacode}/{competent_administration_code}/{competent_administration_version}/third-party-system"".
Successivamente, sarà possibile utilizzare il suo ID come codifica dell'ET all'interno del messaggio di audit."
0f81e395d3a64447a708fc39f1945ac2;"Nel sequence diagram della SCIA, nel passo 17, il BO notifica all'ET il termine per fare richieste di integrazione ?
Chi valuta il tempo entro cui poter chiedere integrazioni?
Le tempistiche per le varie attività sono ritornate dal servizio /instance_descriptor/{cui_uuid} esposto dal Catalogo, nell'oggetto ""Times""? (Es: max_gg_int_req). Possiamo quindi far riferimento a quelle date per definire dei timer a beneficio degli operatori dell'ET?
La data ""start"" è la data di inserimento della pratica sul portale Impresa in un giorno? Contiene anche l'ora al secondo? (es: gg-mm-aaaa hh:mm:ss)
Se perviene al BO una richiesta di integrazione da parte di un ET oltre il termine, cosa succede?";"Nel passo 17 del sequence diagram della SCIA, il BO comunica all' ET che il termine per presentare eventuali richieste di integrazione è scaduto. Questo termine è stabilito in base al regime amministrativo che regola la specifica pratica in questione.
Se l'ET dovesse inviare una richiesta di integrazione dopo la scadenza di questo termine, tale richiesta non sarà presa in considerazione dal BO. In assenza di integrazioni richieste entro il termine stabilito, il BO procederà considerando il silenzio da parte dell'ET come un assenso implicito, permettendo così il proseguimento del processo amministrativo (silenzio-assenso).
Gli operatori dell'ET possono fare riferimento ai tempi indicati nell'oggetto ""Times"" fornito dal servizio ""/instance_descriptor/{cui_uuid}"" del Catalogo per gestire correttamente le scadenze. Ad esempio, il parametro ""max_gg_int_req"" dell'oggetto ""Times"" specifica il numero massimo di giorni che l'ET ha a disposizione per richiedere integrazioni a partire dalla data ""start"" (type DATE, pattern YYYY-MM-DD),  che corrisponde al momento in cui l'istanza è stata avviata. 

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";"Richiedente
Quindi non si tiene conto dell'ora ma solo del giorno.
Pertanto come dobbiamo considerare il seguente scenario?
Un'istanza è avviata in prossimità del termine di giornata, ad esempio alle 23.59, ma per problemi tecnici l'ET la riceve in ritardo e quindi tecnicamente il giorno dopo. In caso di sospensione/integrazione si perderebbe 1 giorno nel conteggio del numero di giorni massimo a disposizione dell'ET.
Stesso discorso nel caso opposto da ET verso BO.
In questi casi fa fede la data ""start"" comunicata dal Catalogo?

Operatore
La data di avvio del processo, indicata come ""start"", costituisce il punto di riferimento per il calcolo dei termini previsti per le procedure amministrative. Di conseguenza, qualora il Catalogo registri come data ""start"" il momento esatto in cui è stata inoltrata l'istanza (per esempio, alle 23:59 di un dato giorno X), tale data dovrebbe essere utilizzata per determinare i termini procedurali, a prescindere da eventuali ritardi tecnici che possano verificarsi in seguito."
c104b5f735404fb0bf1e08abb73692a5;"Nel sequence diagram della SCIA, nel passo 48, si dice di usare il resource_id in istance_index, ma se il documento da integrare era già esistente nella lista non dovremmo usare l'id specifico del documento?
Se invece il documento non era presente nella lista, oppure i documenti sono più di uno, come discriminare quale documento richiedere se si passa il resource_id generale presente in istance_index?";"Il servizio invocato al passo 48 del sequence diagram della SCIA, è finalizzato al recupero dei documenti di integrazione inviati dal presentatore. Ogni documento è identificato dal suo resource_id, riportato nell'instance_index trasmesso dal BO all'ET nell'oggetto SendInstanceRequest tramite il servizio ""send_instance"". 
E' importante chiarire che l'instance-index  è un array che contiene gli identificatori specifici di ciascun documento incluso nell'istanza. Pertanto, il resource_id a cui si fa riferimento è effettivamente specifico per ogni documento.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
ed65a398db504d36871e074cab2a6169;"Nel sequence diagram della SCIA, nel passo 56, il BO chiede all'ET il documento di richiesta sospensione. Al netto del fatto che non si capisce perchè ci debba essere una sospensione (si veda ticket aperto in precedenza),
come fa il BO a sapere che resource_id usare per avere il documento specifico della sospensione?";"
Nel passo 56 del sequence diagram della SCIA, il BO richiede all'ET il documento relativo alla richiesta di sospensione. Questa azione segue il passo 52, dove l'ET ha precedentemente inviato le sue conclusioni tramite la chiamata send_conclusions (NegativeOutcomeRequired). L'oggetto ""NegativeOutcomeRequired""  riporta il suo resource_id specifico per il recupero del documento generato per l'invio del parere. Il BO potrà recuperare tale documento, utilizzando il resource_id trasmesso dall'ET, utilizzando il servizio ""/instance/{cui_uuid}/document/{resource_id}"".

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
98afadefcbbb430eacb987f7182b31ce;Nel sequence diagram della SCIA, i passi 58, 60, 62 scattano a seguito di quale condizione?;"Nello scenario indicato  un ET, a seguito delle sue istruttorie, invia i suoi pareri al BO.  In particolare i passi 58, 60 e 62 ricadono nello scenario specifico dove un ET ha riscontrato una difformità normativa conformabile, pertanto non è intenzionato ad inviare un parere negativo (passo 52) ma invia al BO una richiesta di conformazione (passo 58), invia al Catalogo un audit per segnalare l'evento (passo 60) e il BO può recuperare il documento di richiesta di conformazione (passo 62).

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
935ad822726a4b4e94a685abda4ba4b4;"Nel sequence diagram della SCIA, non c'è l'evento di fine end_by_positive_outcome oppure end_by_negative_outcome.
Perchè?";"Nel regime SCIA i pareri espliciti trasmessi da un ET possono essere: 
 - parere negativo
 - richiesta di conformazione
Nel regime SCIA, dall’istante successivo all’invio della pratica, si è autorizzati a iniziare l’attività senza dover aspettare assensi o autorizzazioni da parte degli uffici pubblici.
Nel caso in cui l'istanza risulti essere conforme, è prevista l'archiviazione della pratica senza ulteriori comunicazioni e il presentatore recepisce un esito positivo implicito al termine dei tempi previsti dalla norma. Per il suddetto motivo, non è contemplato l'evento ""end_by_positive_outcome"" nel regime amministrativo SCIA bensì ""end_by_proceeding_time_expired"". 
Contrariamente, nel caso in cui si riscontrino dei pareri negativi che impediscono la prosecuzione dell'attività, è prevista la comunicazione di un provvedimento di divieto di prosecuzione dei lavori già avviati, trasmesso tramite l'evento ""end_by_suspension_requested"".

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
0f0bb8b789004f528af7123c2188a43a;"Nel sequence diagram della SCIA, se è stata richiesta una sospensione dall'ET, come procede poi l'iter della pratica?
Se invece è stata richiesta una conformazione dall'ET, come procede l'iter della pratica?

Nella pratica, in cosa differiscono i 3 eventi di sospensione, conformazione, integrazione?";"Nel sequence-diagram SCIA, a seguito di un parere negativo espresso dall'ET, trasmesso tramite il ""NegativeOutcomeRequired"" al passo 52, il BO potrà, opzionalmente, recuperare il documento trasmesso dall'ET (passo 56) e, ricadendo nella condizione ""concluso tempo istanza o tutti gli enti terzi hanno inoltrato conclusione, almeno una richiesta di sospensione"" (posta tra i passi 69 e 70), il BO procederà con l'invio delle conclusioni del procedimento tramite la chiamata al servizio ""/notify"" esposta dal FO, trasmettendo l'evento ""end_by_suspension_requested"". A seguito di tale invio, il BO notificherà il medesimo evento ad ogni ET interessato e si conclude il sequence-diagram con un evento di audit al Catalogo.

A seguito di una richiesta di conformazione inoltrata dell'ET (passo 58), il flusso di chiamate segue nel blocco ""concluso tempo istanza o tutti gli enti terzi hanno inoltrato conclusione, nessuna richiesta sospesione,almeno una richiesta conformazione"" dove, al passo il 77, il BO trasmette le conclusioni al FO e notificherà l'evento di conformazione agli ET interessati. Si evidenzia che è attualmente in corso l'aggiornamento del sequence-diagram SCIA per permettere al richiedente di comunicare l'avvenuta conformazione.
Tali aggiornamenti sono soggetti ad un processo di approvazione e la loro pubblicazione sarà realizzata nei modi previsti dalla norma.

Per chiarire il dubbio posto per i 3 eventi, riportiamo le seguenti descrizioni:
 - sospensione: la sospensione è una delle quattro conclusioni che un BO può comunicare al FO. A seguto della ricezione di motivi ostativi trasmessio da uno o più ET, in base alla normativa vigente, il BO trasmette una sospensione qualora ritenesse opportuno procedere con un divieto di prosecuzione.
 - conformazione: un Ente Terzo durante le istruttorie di propria competenza ha identificato degli aspetti non corretti ma conformabili e invia tale esito al BO indicando le sue segnalazioni di conformazione volte a sollecitare il presentatore a normalizzare ogni aspetto procedimentale;
 - integrazione: un ET coinvolto nelle istruttorie può identificare che determinate informazioni o documenti sono mancanti ma risultano essere necessari per procedere con l'istruttoria. Una richiesta di integrazione è volta a colmare tale mancanza e garantire quindi una corretta prosecuzione delle istruttorie.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
99cfe24694624b22b8b74c89b945ea07;"Nel file Yaml dei servizi esposti dal Catalogo per l'ET, nell'oggetto ""InstanceDescriptor"" c'è l'elemento non obbligatorio ""administrative_regime"" che contiene la tipologia di pratica (SCIA, AUTORIZZAZIONE, SILENZIO-ASSENSO, COMUNICAZIONE).
Perchè l'elemento non è obbligatorio, visto che contiene una informazione di base della pratica?
I seguence diagram che avete pubblicato riguardano solo le prime due tipologie di pratiche. Che iter dobbiamo seguire per le altre due?";"L'Instance Descriptor prevede come campi obbligatori solamente version, municipality e usecase_proceedings. Secondo quanto indicato dal ""modello-concettuale-catalogo-SSU.png"" (presente nella cartella ""image""), un procedimento ha cardinalità (0, n) con l'oggetto regime amministrativo. Nel rispetto di tale modello dati del Catalogo, l'attibuto ""administrative_regime"" non è stato segnato tra quelli ""required"" nella definizione dell'Instance Descriptor.

Alla base delle definizione e della stesura delle Specifiche Tecniche vi è stata un'analisi dettagliata sui procedimenti SUAP e nello specifico sui regimi amministrativi adottati dagli stessi. Sono state intraprese delle azioni di semplificazione, condivise con il Tavolo per la semlificazione amministrativa, volte a ottimizzare significativamente il percorso amministrativo per le imprese. Volendo ricondurre un regime amministrativo ad un sequence-diagram, è possibile tenere presente la seguente mappatura:
 - SCIA -> SCIA-001.mermaid
 - AUTORIZZAZIONE -> DomandaAutorizzazione-001.mermaid
 - SILENZIO-ASSENSO -> SCIA-001.mermaid
 - COMUNICAZIONE -> SCIA-001.mermaid

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
12945343dd934fa5a5de0b306a1ef94a;"Nel file Yaml dei servizi esposti dal Catalogo per l'ET, nell'oggetto ""InstanceDescriptor"" c'è l'elemento ""instance_status"" che contiene lo stato dell'istanza (started, presented, ecc.)
Perchè è un array e non un oggetto singolo?

Non tutti gli stati dell'istanza sono esplicitati nei due seguence diagram di Autorizzazione e SCIA. E' possibile avere uno schema/tabella della macchina a stati che li mostri tutti, esplicitando per ogni passaggio di stato le condizioni che lo determinano?";"L'""instance_status"" presente nell'Instance Descriptor è stato definito come un array di stati e timestamp, e non come un singolo record, con lo scopo di tenere traccia nello stesso tutte le lavorazioni svolte sull'istanza.  

In merito alla richiesta della macchina a stati per i regimi Autorizzazione e SCIA, si vuole far presente che al momento non è previsto tale oggetto  nelle Specifiche Tecniche o nel repository GitHub. Tuttavia, tutte le informazioni utili per ricreare tale oggetto sono disponibili negli artefatti già resi pubblici.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";"Richiedente
Chiedo scusa ma non ho trovato in nessun documento una descrizione degli scenari che fanno scattare i seguenti stati per l'istanza:
started
presented
correction_requested
corrected
refused
integrated

Operatore
Come indicato nel messaggio precedente, non è presente uno state-diagram nelle Specifiche Tecniche o nel repository GitHub. Al fine di comprendere gli scenari e gli eventi che fanno scattagli gli stati indicati nella richiesta, la invitiamo a consultare:
- la proprietà ""instance_status.state"" dell'Instance Descriptor per visualizzare tutti gli stati disponibili
- gli eventi gestiti nei messaggi di ""audit"" dei sequence-diagram"
6bcfa538d0bf4970ab03ac31f98e8faf;"Se l'ET vuole sapere in qualunque momento lo stato attuale di una istanza-pratica, deve richiamare il servizio ""/instance_descriptor/{cui_uuid}"" esposto dal Catalogo, dato che nell'oggetto ritornato ""InstanceDescriptor"" c'è l'elemento ""instance_status"" che contiene lo stato dell'istanza (started, presented, ecc.)
Non c'è altro modo, visto che il BO espone solo gli eventi (end_by_proceeding_time_expired, end_by_integration_times_expired, ecc.) e NON gli stati.
E' corretto?";"Confermiamo la sua assunzione in merito alla segnalazione posta. Ogni componente, per recuperare l'Instance Descriptor e i metadati ad esso associati, deve chiamare solo il Catalogo. Invocando il servizio ""/instance_descriptor/{cui_uuid}"", l'ET è in grado di recuperare l'Instance Descriptor alla sua ultima versione e verificare la lista degli stati gestisti nell'""instance_status"".

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
70a621766c0e49f8b47353194d5ad524;"Nel sequence diagram della SCIA e anche nello Yaml dei servizi esposti dal BO, come conclusione possibile che l'ET comunica al BO tramite il servizio /send_conclusions, manca la tipologia ""negative_outcome"".
Perchè?";"Confermiamo la sua assunzione in merito alla segnalazione posta e confermiamo che è attualmente in corso la riformulazione dell'attributo ""suspension_requested"" per mantenere una corretta concordanza con l'oggetto (NegativeOutcomeRequired) a cui è associato.
Tali aggiornamenti sono soggetti ad un processo di approvazione e la loro pubblicazione sarà realizzata nei modi previsti dalla norma.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
cc12c35768544d8da6cd1a96bf82ced5;"Vorrei alcuni chiarimenti sui significato dei parametri relativi ai giorni ritornati nell'oggetto ""times"" dal servizio ""/instance_descriptor/{cui_uuid}"" esposto dal Catalogo verso gli ET.

max_gg_proc:
indica il numero di giorni limite a partire da start entro cui l'istanza deve concludersi. Questo limite non è forse definito a monte dell'istruttoria, a partire dalla data di ""start""? Quindi il fatto che venga comunicato all'ET serve solo a informarlo del termine entro cui sicuramente l'istanza dovrà essere terminata rispetto a tutte le eventuali richieste da parte degli ET interessati a quell'istanza?
Infatti il termine di interesse per l'ET dovrebbe essere ""max_gg_concl_send"", o sbaglio?

max_gg_correction:
indica il numero di giorni limite a partire da start per la correzione a valle di un controllo formale. Chi è il soggetto che dovrebbe fare il controllo formale?

max_gg_admissibility:
indica il numero di giorni limite a partire da start per la verifica di ammissibilità. Questa verifica non viene svolta dal SUAP? In tal caso qual è il senso di comunicare questo limite all'ET?

max_gg_int_resp:
indica il numero di giorni limite a partire da start per integrazione del soggetto presentatore. Il ""soggetto presentatore"" è la persona che presenta l'istanza della pratica sul portale ""Impresa in un giorno"", corretto? Dunque perchè va comunicato questo limite all'ET, il quale scambia informazioni solo con il BO SUAP e non ha relazioni con il soggetto presentatore?

Infine, perchè l'oggetto ""times"" non è obbligatorio, visto che contiene i vincoli temporali cui l'ET deve attenersi?";"Di seguito riportiamo i chiarimenti in merito agli attributi ""times"" indicati nella richiesta.

max_gg_proc:
il presente attributo specifica la durata massima complessiva di tutto il procedimento SUAP avviato, espresso in giorni a partire dalla data di ""start"". Tali informazioni di scadenze procedimentali sono a disposizione nell'Instance Descriptor e solo ad avvenuta scadenza, determinati eventi, vengono notificati dal BO all'ET per gestire la corretta gestione e conclusione di un procedimento:
 - end_by_proceeding_time_expired
 - end_by_suspension_requested
 - end_by_conformation_requested
 - end_by_integration_times_expired
 - integration_request_time_expired
Sarà quindi interesse dell'ET essere a conoscenza dei termini massimi per la lavorazione del procedimento (max_gg_proc), per l'invio degli esiti (max_gg_concl_send), per la richiesta di integrazione (max_gg_int_req), per la richiesta di cdss (max_gg_cdss_req) e la sua data di convocazione (date_cdss).

max_gg_correction:
il presente attributo è di interesse del BO che è il soggetto incaricato ad effettuare i controlli formali.

max_gg_admissibility:
il presente attributo imposta il tempo massimo concesso al BO per effettuare le sue verifiche di procedibilità.

max_gg_int_resp:
il ""soggetto presentatore"" è il soggetto che presenta le istanze necessarie ad avviare i procedimenti amministrativi, corretto. 
Tale attributo è di interesse dell'ET quanto del BO, considerato il fatto che è l'ET che effettua tale richiesta al BO, per passarla al FO e quindi al presentatore. Una volta che è stata avviata tale richiesta, un ET rimarrà in attesa di un'integrazione e il BO avrà il compito di segnalare la sua scadenza sia al FO che agli ET interessati, svolgendo così il suo ruolo di coordinatore di un procedimento SUAP.

L'oggetto ""times"" non è impostato come obbligatorio perchè il BO imposta i tempi procedimentali in un secondo momento, solo a partire dalla data della ricevuta trasmessa al presentatore. Tale aggiornamento dell'oggetto ""times"" avverrà solo a seguito della chiamata ""/notify_receipt"" effettuata dal FO al BO per segnalare l'invio di tale ricevuta. 

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.



";n.a.
2da0462941b646bea1c416af00e75433;"Se l'ET, dopo il ricevimento di una pratica, ha necessità di rifiutarla poichè la valuta irricevibile per via dei controlli formali svolti internamente, con che modalità occorre comunicare l'evento al BO SUAP e con quali parametri?
Il conseguente provvedimento di irricevibilità risulta come prodotto dall'ET o dal BO SUAP?";"Un ET, se riscontra delle anomalie o difformità tali da rifiutare la pratica ricevuta, può comunicare al BO un suo esito negativo come risultato delle sue istruttorie.
Inoltre, si precisa che i controlli formali condotti su una pratica SUAP sono compito di un BO e, solo dopo che un'istanza viene ritenuta procedibile, questa può essere inviata agli ET.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
b6e12646eb9a49acb6bf4a42df69e540;"Buongiorno.
Avremmo necessità di sapere se esiste un repository aggiornato con tutte le modulistiche in formato xsd del SUAP. Nel caso anche degli schematron.
Al momento il nostro perimetro è quello dell'Ente Terzo ARPA ed ATS. E l'obiettivo e quello di avere sotto mano tutte i moduli del SUAP disponibili.
Per ora stiamo consultando il repository già comunicato tempo fa: https://github.com/AgID/specifiche-tecniche-DPR-160-2010
che però risulta aggiornato a 5 anni fa. Sia nel trunk, che nei vari branches.
Sappiamo per certo che nella conferenza delle regioni del 4 aprile sono stati approvati una serie di moduli:
1. Modulo SCIA Agenzie di viaggio
2. Modulo SCIA Strutture ricettive extra alberghiere
3. Modulo Variazioni in comunicazione per agenzie di viaggio
4. Modulo Variazioni in comunicazione per strutture ricettive
1. Modulo SCIA Strutture ricettive all'aria aperta
2. Modulo SCIA Strutture ricettive alberghiere
3. Modulo Scheda anagrafica
4. Modulo di Comunicazione variazioni
5. Modulo di Notifica sanitaria
Ma nel repository non c'è traccia. Quindi vi chiediamo come poter consultare tutte le modulistiche in modo smart. Nel caso anche uno zip completo ed aggiornato andrebbe bene. Anche se sappiamo bene che poi potrebbe essere soggetto ad aggiornamento.
Sempre sul tema 'moduli' vorremmo sapere se è stata aggiornata la modulistica (anche xsd) dell'AUA, rispetto a quella proposta qualche anno fa dalla Regione Lombardia.
Inoltre anche se sono presenti nel catalogo gli XSD delle seguenti modulistiche. E se non ci sono se le state prevedendo, o saranno da definire/proporre dei vari Enti:
- AUFER (autorizzazione unica energie rinnovabili)
- SCIA seguente ad AUA O ALTRE AUTORIZZAZIONI
- SCIA stazione radiobase
- Autorizzazioni emissioni in atmosfera ex art. 272 comma 2 dlgs 152/06
- SCIA bar (parte rumore)
In allegato inserisco quando ricevuto da XXX tramite Regione Lombardia, che non ritroviamo nel link github prima menzionato.

Cordialmente.
XXX (ARIA SPA - Regione Lombardia)";"Il link riportato nella richiesta (https://github.com/AgID/specifiche-tecniche-DPR-160-2010) risulta essere il repository GitHub dove è possibile consultare gli artefatti tecnici (BPMN, immagini, json-schema, openApi e sequence diagram) delle Specifiche Tecniche, utilizzato tuttora come area di lavoro del Gruppo Tecnico per le fasi di aggiornamento delle stesse.
Considerata la natura del suddetto repository e della richiesta stessa, la invitiamo a richiedere supporto ad Infocamere, tramite i suoi canali di assistenza, poichè, in qualità di gestore, provvederà a caricare tali moduli sul Catalogo SSU.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
6f6c5183e87548fb974dd9cb0146eca7;Se l'ET vuole richiedere nell'integrazione un documento non presente inizialmente nell'elenco dei documenti presentati, che modalità si deve usare per indicarlo al BO?;"Un ET può effettuare una richiesta di integrazione al BO riportando una o più motivazioni, identificate da un proprio resource_id, per segnalare quali documenti mancanti devono essere integrati. Tali motivazioni possono essere inviate effettuando un'unica richiesta cumulativa.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";"Richiedente
Quindi l'ET dovrà generare un resouce_id per ogni documento mancante e inserirli nell'oggetto integration_document_list nella chiamata al servizio /request_integration esposto dal BO?
Dovrà solo aver cura di indicare un valore differente dagli altri resouce_id collegati allo stesso CUI.UUID, per preservare l'univocità.
E' corretto?

Operatore
L'oggetto ""integration_document_list"" è un array di documenti di integrazione rilasciati da un ET.
Il ""resource_id"", come gli altri attributi ""requester_administration"", ""hash"" e ""alg_hash"", riportati all'interno di ogni record dell'array, forniscono le informazioni associate al documento di integrazione rilasciato dall'ET e non sui documenti per cui sta richiedendo effettuando tale richiesta.
Un ET deve fornire l'elenco delle integrazioni richieste utilizzando l'attributo ""integration_request"" (dichiarato come ""required"" nell'oggetto ""integration_list""), che risulta essere l'attributo creato per questo scopo, come indicato dalla sua descrizione nell'openAPI."
418edaf04895414dad127de2fb0c4892;"I processi di conformazione e integrazione sono sostanzialmente differenti, in quanto avete indicato che:
- per la conformazione: un Ente Terzo durante le istruttorie di propria competenza ha identificato degli aspetti non corretti ma conformabili e invia tale esito al BO indicando le sue segnalazioni di conformazione volte a sollecitare il presentatore a normalizzare ogni aspetto procedimentale.

Pertanto il processo si realizza con una chiamata di /send_conclusions da ET al BO con ConformationRequired e conclusions_type = conformation_requested.

- per l'integrazione: un ET coinvolto nelle istruttorie può identificare che determinate informazioni o documenti sono mancanti ma risultano essere necessari per procedere con l'istruttoria. Una richiesta di integrazione è volta a colmare tale mancanza e garantire quindi una corretta prosecuzione delle istruttorie.

Pertanto il processo si realizza con una chiamata di /request_integration da ET al BO.
Il tempo massimo consentito all'ET per fare richiesta di integrazione è: max_gg_int_req,
mentre il tempo massimo consentito al ""soggetto presentatore"" è: max_gg_int_resp.

Se tutto quanto scritto sopra è corretto, allora mancano due valori, analoghi al caso dell'integrazione, per indicare il numero massimo di giorni entro cui l'ET può trasmettere la conformazione ed entro cui il ""soggetto presentatore"" può conformare.
Anche questo aspetto fa parte delle modifiche in corso di lavorazione?";"Confermiamo le descrizioni riportate circa Integrazione e Conformazione.
Per quanto riguarda la richiesta di conformazione, un ET può indicare la data di scadenza concessa al presentatore utilizzando l'attributo ""date"" presente nell'oggetto ""ConformationRequired"". Diversamente,  il numero di giorni, a partire dallo start, entro cui un ET può richiedere una conformazione è definito nell'attributo ""max_gg_concl_send"", gestito nell'oggetto ""Times"" dell'Instance Descriptor, poichè tale richiesta risulta essere un esito degli ET elaborato a seguito delle loro istruttorie.
Invece, per quanto riguarda la richiesta di integrazione, il termine ultimo per inoltrare tale richiesta è espresso in numero di giorni ed è gestito all'interno dell'Instance Descriptor tramite l'attributo ""max_gg_int_resp"", definita nell'oggetto ""Times"".
 
Si segnala che sono attualmente in corso degli aggiornamenti in merito alla gestione delle conclusioni, tuttavia tali indicazioni risultano essere già disponibili nel branch ""approved01"".
 
Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.
 
 ";n.a.
e7ae640ccfad467b88d359d297e90c07;Se a valle di una istruttoria per una SCIA l'ET volesse fornire all'utente il codice autorizzazione che ha generato, attraverso una ricevuta (ad esempio un file PDF), poiché non possiamo inviare un esito positivo al BO, come lo potremmo comunicare?;"Come indicato nelle Specifiche Tecniche, nel paragrafo 6.1.1, per il regime amministrativo SCIA, un ET può adottare un motivato provvedimento di divieto di prosecuzione dell'attività, inviando quindi un parere negativo, o può invitare il soggetto presentatore a conformare l'attività entro un certo termine, con atto motivato, inviando qui una richiesta di conformazione.
Nel caso in cui un ET non riscontri difformità normative e, quindi, le sue istruttorie terminano con un esito positivo, le Specifiche Tecniche e i relativi workflow e sequence-diagram associati allo SCIA  non prevedono ulteriori azioni in carico all'ET e la pratica dovrà terminare con la conclusione dei tempi procedimentali (status: ended_by_proceeding_time_expired).

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
3ad374525e4e4947a77d20f051747ad9;"	
In caso l'operatore riscontri in fase di istruttoria che la pratica vada rigettata, quindi senza richieste di integrazione/conformazione, è possibile mandare subito un esito negativo chiamando il servizio /send_conclusions esposto dal BO?";"Un ET, valle delle proprie istruttorie, nel caso in cui accerti la carenza dei requisiti e dei presupposti richiesti, deve adottare un motivato provvedimento di divieto di prosecuzione dell'attività e di rimozione degli eventuali effetti dannosi della stessa, comunicando tale esito al BO tramite il path ""/send_conclusions"" inviando l'oggetto ""NegativeOutcomeRequired"" che prevede i seguenti attributi:
 - cui (codice unico dell'istanza)
 - conclusions_type: suspension_requested (tipologia di conclusione definita tramite un enum)
 - instance_descriptor_version (versione dell'Instance Descriptor)
 - negative_outcome_motivation (motivato provvedimento di divieto di prosecuzione dell'attività)
 - resource_id (id della risorsa per recuperare il documento associato alla richiesta di sospensione)
 - hash (hash della risorsa)
 - alg_hash (algoritmo applicato per generare l'hash)

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.

";n.a.
a30d3d982f1a4fe08f5928ae0c293a75;"Il nostro referente per l'ET ci ha espressamente detto che:
- la richiesta di conformare è utilizzata in caso di SCIA;
- la richiesta di integrazione è utilizzata per l'Autorizzazione e per la Comunicazione.

Tuttavia in una precedente mia richiesta (del 10/10/2024 ore 15:40) ci avete risposto che la Comunicazione e il Silenzio-assenso rientrano nella casistica SCIA.
Quindi vorremmo avere una risposta definitiva su quali tipologie di pratiche ammettano la conformazione e quali l'integrazione.";"Come indicato nelle Specifiche Tecniche, nel paragrafo 6.1.1, per il regime amministrativo SCIA, un ET può effettuare una richiesta di integrazione (send_integration) o può effettuare una richiesta di conformazione, in questo caso, gestendola tramite l'invio delle conclusioni (send_conclusions).
Analogamente, nel paragrago 6.1.2, per il regime amministrativo Autorizzazione/Domandand, un ET può inviare una richiesta di integrazione, tuttavia, non è previsto l'invio di una richiesta di conformazione.
Assunto quanto appena detto e tenuto in considerazione anche le normative legate ai regimi amministrativi, si afferma che:
 - per il regime amministrativo SCIA, un ET può inviare una richiesta di integrazione e una richiesta di conformazione;
 - per il regime amministrativo Comunicazione, che è riconducibile al workflow SCIA, un ET può effettuare richieste di integrazione e conformazione;
 - per il regime amministrativo Silenzio-assenso, che è riconducibile al workflow SCIA, un ET può effettuare  richieste di integrazione e conformazione;
 - per il regime amministrativo Autorizzazione, un ET può inviare solamente una richiesta di integrazione.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
d66947b2f2d04142b48e94af94f970fd;"Facendo riferimento all'openapi pubblicata su github branch approved_001
vorremmo un chiariemnto sulla risposta della api ""Recupero Sistema BackOffice di uno specifico Sportello SUAP""
/suap/{suap_id}/{suap_version}/backoffice-system
L'oggetto /components/schemas/BOSystemEntity che informazioni conterrà, per esempio cosa rappresenta e_service_to_fo?
Esiste una documentazione di dettaglio sulla semantica dei servizi CatalogoSSU_metadati?";"Il Catalogo SSU tramite il path ""/suap/{suap_id}/{suap_version}/backoffice-system"" permette il recupero della componente del BackOffice, riportando le informazioni associate ad esso e i riferimenti da utilizzare per contattarlo. 
Nel dettaglio, è possibile recuperare l'identificativo univoco della risorsa (id), la sua versione e la descrizione della componente BackOffice. Vengono riportare anche le informazioni in merito al suo stato di validità (state) e il periodo (start, end) e, infine, vengono forniti anche i punti di contatto tramite i quali è possibile richiamare i servizi esposti dalla componente (es. e_service_to_fo: riporta l'UUID del servizio sulla PDND esposto al FO dalla componente BO).

In merito all'ultimo quesito posto, si informa che attualmente non è disponibile alcuna documentazione di dettaglio sulla semantica dei servizi CatalogoSSU_metadati. Le openAPI pubblicate su GitHub e sulle Specifiche Tecniche rappresentano la documentazione tecnica dei servizi esposti dai componenti del sistema SSU. Tuttavia, si informa che il Gruppo Tecnico si è posto l'obiettivo di migliorare la comprensione degli artefatti tecnici e nel corso degli aggiornamenti verrano forniti maggiori dettagli sui servizi tramite descrizioni più parlanti ed esempi.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
964b43e122d34901b075999600615652;"Ticket aperto per conto di Starch s.r.l.:
""Buongiorno, tramite il nostro “Sponsor”, Comune di Prato, stiamo accedendo ai servizi SSU esposti su PDND, ambiente di test.
Per il momento stiamo accedendo ai servizi bulk per recuperare i metadata esposti dal sistema e capire, dati alla mano, le informazioni distribuite a livello centrale e le strutture dati con cui queste sono state organizzate. Vedendo i dati abbiamo diversi dubbi interpretativi su come questi sono organizzati, in particolare ci servirebbe capire bene le relazioni tra usecases-proceedings-endoprocedimenti.
Vorremmo anche capire se c'è un'organizzazione del dato che consenta di presentare all'utente le informazioni in maniera chiara, organizzata e strutturata. Attualmente abbiamo importato i dataset ritornati dalle bulk in un database relazionale, in modo da poterli interrogare e visionare in maniera semplice e veloce. Ci servirebbe però poterci confrontare, magari esaminando qualche caso specifico, sui dubbi che stiamo riscontrando e che le specifiche non chiariscono.""";"
Ai fini di una consultazione della struttura dei metadati gestiti dal Catalogo SSU, nella sezione 8.2 ""Metadati per istanziazione dei protocolli di comunicazione"" è presente  il modello E-R raffigurato nella Figura 13.
Nelle seguenti descrizioni, viene precisato che l'entità ""endoproceedings"" individua le fattispecie dei procedimenti amministrativi (usecase-proceedings) che possono (opzionale=false) o devono (opzionale=true) essere avviati in relazione alla fattispecie primaria.

Per eventuali dettagli più approfonditi in merito, la invitiamo a richiedere supporto ad Infocamere, tramite i suoi canali di assistenza, poichè, in qualità di gestore del Catalogo SSU.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
2cb003786a92451baea876a186f1fd80;"Nel nuovo sistema sarà possibile avere uno scenario in cui il BO comunica all'ET una pratica che contiene al suo interno più tipologie di iter da dover gestire?
Esempi:
subingresso + sospensione temporanea dell'attività;
trasferimento di sede + ampliamento dell'esercizio.";"Un procedimento amministrativo è caratterizzato da un attributo che determina l'evento della vita dell'attività (es. apertura), pertanto, può essere definito soltanto una delle tipologie menzionate nella richiesta.

Ai fini di una consultazione della struttura dei metadati gestiti dal Catalogo SSU, nella sezione 8.2 ""Metadati per istanziazione dei protocolli di comunicazione"" è presente  il modello E-R raffigurato nella Figura 13.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.
";n.a.
a6c4265c2c9e468babd06c1a2949257c;"Con riferimento al ticket ""Ente Terzo - SCIA con codice autorizzazione in ricevuta di output (PDF)"" del 30/10/2024 16:18,
ovvero:
""Se a valle di una istruttoria per una SCIA l'ET volesse fornire all'utente il codice autorizzazione che ha generato, attraverso una ricevuta (ad esempio un file PDF), poiché non possiamo inviare un esito positivo al BO, come lo potremmo comunicare?""

l'ET ci fa presente che per alcune casistiche ha assoluta necessità di inoltrare al cittadino che ha presentato la pratica il codice dell'autorizzazione collegata, poiché dovrà effettuare un pagamento utilizzando proprio quel codice.
In questi casi che prassi avete previsto?";"Le Specifiche Tecniche, come previsto dalle normative in caso di regime amministrativo SCIA, non prevedono l'invio di un esito positivo qualora non vengano riscontrate difformità.
Si suggerisce di gestire questa necessità specifica attraverso una comunicazione extra-sistema con il diretto interessato, al fine di comunicargli il codice da utilizzare per effettuare il pagamento. 

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
n.a.;Non essendoci ancora stata ufficialmente la firma degli Organi competenti per lo switch alla versione Approved 02 delle specifiche tecniche, le  Regioni temono di star dando un effort molto elevato su un qualcosa che potrebbe cambiare non essendo ancora stato approvato. Anche se il contenuto delle specifiche tecniche è già stato discusso e approvato in via ufficiosa nel mese di Aprile si sta lavorando ancora su una versione che ufficiale non è. In merito a ciò si è pensato si poter emettere una nota che approvi già in via preventiva che il contenuto delle specifiche tecniche non cambierà in corso di approvazione, nonostante manchino ancora le firme per l’ufficialità. Sempre in merito a questo tema, le Regione Friuli-Venezia Giulia fa notare che ci sono delle discrepanze tra la versione MAIN (attiva al momento) e la versione Approved_01: nonostante la versione MAIN delle ST non richieda come dati obbligatori lo “stato dell’istanza”, il “regime ammnistrativo” e i “tempi”, al momento dell’inserimento, il Sistema non permettere di procedere senza l’inserimento di questi dati, i quali, risultano essere obbligatori invece per la versione Approved_01. Data la mancanza di conformità evidenziata e la paura di star procedendo troppo per tentativi su una versione delle ST che non è quella ufficiale, è stata richiesta la possibilità di avere, o direttamente nelle specifiche tecniche o con un documento accessorio, un file che spieghi al meglio come funziona tutto il servizio;"Sulla base della news (https://www.suapsue.gov.it/news/?news_id=26) pubblicata dal DFP sul sito di progetto SUAP&SUE, si evidenzia che è da considerare come branch di riferimento ""approved01"".

Per quanto riguarda invece la richiesta di un documento accessorio, si precisa che le Specifiche Tecniche risultano essere l'unico documento tecnico ed è completo di ogni indicazione necessaria per l'interoperabilità tra le componenti del sistema SSU. Il repository GitHub (https://github.com/AgID/specifiche-tecniche-DPR-160-2010) ad esso associato permette una libera consultazione di tutti gli oggetti tecnici indicati nelle Specifiche. 
Cogliamo l'occasione per ricordare che AgID ha reso disponibile una piattaforma di Help Desk (https://www.agid.gov.it/it/notizie/e-online-il-servizio-di-help-desk-il-progetto-suap) dedicata alle Regioni e ai loro partner tecnologici al fine di dare risposte sugli eventuali dubbi delle Specifiche Tecniche. ";n.a.
n.a.;" Nel nuovo allegato tecnico DPR 160 c’è indicato uno schema che indica che il regime amministrativo (SCIA, ORDINARIO/AUTORIZZATIVO, Comunicazione) è in relazione uno a uno con un procedimento mentre nella funzionalità human oriented del catalogo SSU la relazione è tra il regime amministrativo e la fattispecie in relazione uno a uno.
Secondo noi la relazione corretta è quella indicata nel nuovo allegato tecnico. La relazione regime amministrativo <-vs-> fattispecie (caso d’uso) non è adeguata per tutti i casi in cui la domanda diventa una SCIA condizionata.
Facciamo un esempio:
Una fattispecie (caso d’uso) può prevedere procedimenti necessari e facoltativi e nel caso di un “Avvio esercizio di vicinato” la situazione potrebbe essere
a) i necessari saranno “Avvio esercizio di vicinato”;
b) i facoltativi (tutti quelli riportati nell’articolo 1.10 della TAB A del decreto 222/2016), nel nostro esempio prevediamo la necessità di attivare la “Vendita di oggetti preziosi”; L’ “avvio esercizio di vicinato” ha un regime amministrativo in SCIA e la “vendita di oggetti preziosi” ha un regime che è autorizzativo (come da allegato tecnico: corretta la relazione tra  rocedimento e regime) ma il regime del caso d’uso dipende da quali procedimenti facoltativi è necessario attivare quindi non è possibile prevedere un regime nel caso d’uso a meno che non si prevedano una molteplicità di casi d’uso nessuno dei quali deve prevedere procedimenti AUTORIZZATIVI facoltativi (bisognerebbe prevedere i casi: con con vendita oggetti preziosi e senza, con vendita alcolici e senza, con insegna e senza, vendita di oggetti preziosi con insegna e senza…).";"Durante le fasi di aggiornamento delle Specifiche Tecniche, il Gruppo Tecnico ha riscontrato la necessità di modificare la relazione associata ad un regime amministrativo, legando quest'ultimo alla fattispecie e non più al procedimento. La motivazione che ha spinto alla ridefinizione del modello ER del Catalogo è dovuta dal fatto che, come indicato nell'esempio posto nel quesito, gli endoprocedimenti attivati in un procedimento SUAP possono condizionare il regime amministrativo ad esso associato. Quindi, assumendo che vi siano più endoprocedimenti associati ad una fattispecie, il regime amministrativo del procedimento SUAP è determinato dalla fattispecie più condizionante, ovvero quella che richiede più azioni bloccanti per il presentatore. Interprentando di nuovo l'esempio riportato nella richiesta, applicando questa logica, considerato un procedimento che attiva la fattispecie ""Avvio esercizio di vicinato"", a cui sarà associato l'endoprocedimento (ovvero una fattispecie secondaria) ""Vendita di oggetti preziosi"", il regime amministrativo non sarà più SCIA (ovvero quello associato ad ""Avvio esercizio di vicinato"") ma diventerà Autorizzazione/Domanda. 

Si ricorda che le fattispecie sono utilizzate per: 
   - definire 1-a-1 i controlli Schematron da applicare per le verifiche automatiche, pertanto, il regime amministrativo deve essere associato a livello di fattispecie per garantire tali controlli;
   - registrare all'interno del Catalogo gli endoprocedimenti obbligatori per le stesse, ad esempio per ""Avvio esercizio di vicinato"", definendo la fattispecie ""Avvio esercizio di vicinato con vendita di oggetti preziosi"", si rende obbligatorio l'attivazione dell'endoprocedimento ""Vendita di oggetti preziosi"".

Per concludere, si coglie l'occasione di ringraziare per la segnalazione fornita poichè questa permetterà l'aggiornamento del diagramma ER del Catalogo SSU secondo quanto precisato precedentemente.";n.a.
n.a.;Relativamente al versionamento delle entità presenti nel catalogo come deve reagire una componente informatica alla pubblicazione di una nuova versione di una determinata entità? Esisterà un tempo per l’adeguamento e una data di kick-off per la messa in produzione da parte di tutti gli attori?;"Consultando il ""modello-concettuale-catalogo-SSU"" è possibile prendere visione di tutte le entità che vengono gestite dal Catalogo SSU. Queste possono essere suddivise in due categorie: Amministrative e Tecniche. Le entità Tecniche sono tutte quelle entità che hanno tra i suoi attributi il ""Riferimento Telematico"", ovvero tutte le entità che rappresentano i componenti informatici dei sistemi Enti Terzi, Front-Office e Back-Office. Le entità Amministrative sono le rimanenti, quindi tutte le entità che compongono i procedimenti amministrativi. In fondo,  viene riportata due liste di dettaglio per le due categorie descritte.

Per rispondere in merito alla strategia di pubblicazione/attuazione degli aggiornamenti delle suddette entità, si possono definire due strategie differenti:
 - Aggiornamento entità Amministrative: le entità che compongono i procedimenti amministrativi sono regolamentati dalle norme e i loro aggiornamenti non sono retroattivi, pertanto, tutti i procedimenti SUAP avviati prima di un certo aggiornamento, dovranno essere chiusi continuando ad utilizzare la versione adottata in fase di avvio. Differentemente, i nuovi procedimenti avviati a seguito di un rilascio dovranno seguire quanto indicato nel nuovo aggiornamento;
- Aggiornamento entità Tecniche: le  entità che rappresentano i componenti informatici, possono essere gestite liberamente secondo la libertà organizzativa delle amministrazioni, le quali dovranno definire le loro logiche di routing interno per reindirizzare le richieste ai componenti rilasciati, mantenendo unico il punto di contatto esposto alle altre amministrazioni.

Di seguito, la lista delle entità suddivise per categoria:
- Entità Amministrative:
   - Struttura Ente
   - Sportello SUAP
   - Procedimento
   - Fattispecie Procedimento
   - Endoprocedimento
   - Regime Amministrativo
   - Modulo
    - XSD
    - Schematron
    - Allegato

- Entità Tecniche:  
   - sistema FO
   - sistema BO
   - sistema ET
";n.a.
n.a.;"InstanceDescriptor – SUAP FO – dati obbligatori
Quali sono i dati obbligatori da popolare per eseguire la chiamata all’endpoint “request_cui” che la componente SUAP FO opera verso l’e-service dei metadati del Catalogo?";"Secondo quanto indicato nel branch ""approved01"" del repository GitHub (https://github.com/AgID/specifiche-tecniche-DPR-160-2010), il servizio ""/request_cui"" indicato nel ""catalogo-ssu_to_fo"" richiede come oggetto della richiesta l'""InstanceDescriptor"" che deve essere popolato con tre attributi obbligatori:
 - version
 - municipality
 - usecase_proceedings
Ad ogni modo, si raccomanda di valorizzare anche i seguenti campi che sono ritenuti essenziali per un procedimento:
 - times (vedi anche Quesito 5)
 - instance_status
 - administrative_regime
";n.a.
n.a.;"Dubbi sulle sezioni da popolare sull’instanceDescriptor relativamente alla chiamata all’endpoint “request_cui” che la componente SUAP FO opera verso l’e-service dei metadati del Catalogo :
a) Version: da chi deve essere popolata e come?
b) State: quale stato va specificato?
c) Times: vanno specificati in questa fase?
d) Administrative_regime: come deve essere calcolato?
e) Usecase_proceedings
i) Instance: cosa rappresenta ref?";"Di seguito si riportano le indicazioni in merito ai dubbi posti sugli attributi:
 - version: deve essere popolato dal FO, impostando una valore intero (Integer), peferibilmente 1, in fase di richiesta di associazione del CUI effettuato al Catalogo;
 - state: tale attributo risulta essere un sotto-attributo di ""instance_status"". Il  valore  da associare in questo momento ad un InstanceDescriptor è lo stato ""started"". Tutti gli stati possibili sono indicati all'interno di ""instance-descriptor-schema.yaml"" presente nel repository GitHub (https://github.com/AgID/specifiche-tecniche-DPR-160-2010);
 - times: malgrado non sia stato indicato attualmente come un attributo obbligatorio (required), si suggerisce di popolare tale attributo fin dall'inizio;
 - administrative_regime: tale attributo richiede un oggetto composto da due attributi obbligatori: id e version. L'id rappresenta l'identificativo univoco del regime amministrativo che può assumere quattro possibili valori (inidicati tramite enum): SCIA, AUTORIZZAZIONE, SILENZIO-ASSENSO, COMUNICAZIONE. La version invece è una stringa che deve rispettare un pattern specifico ([0-9]{2}.[0-9]{2}.[0-9]{2}), ovvero tre coppie di numeri separati da un punto, ad esempio: 00.00.00;
 - usecase_proceedings: tale attributo definisce una lista di fattispecie dei procedimenti avviati tramite il procedimento SUAP. All'interno dell'""instance-descriptor-schema"" è possibile prendere visione dei vari attributi che lo caratterizzano;
 - instance: l'attributo ""ref"" rappresenta il riferimento all'elemento dell'istanza relativo al procedimento. Tale valore deve essere utilizzato per ottenere il relativo ""resource_id"", presente all'interno dell'""instance-index (instance-index-schema), necessario per il recupero del documento di interesse tramite il servizio ""/instance/{cui_uuid}/document/{resource_id}"" (vedi anche Quesito 7).";n.a.
n.a.;"Nell’xsd del form scaricato dal catalogo la gestione dei pagamenti è presente solo come allegato. Come avete pensato di gestire la gestione dei pagamenti sia lato
SUAP FO che lato SUAP BO?";"Si precisa che la tematica non è trattata all'interno delle Specifiche, considerato che le stesse afferiscono alla sola interoperabilità tra i componenti, mentre il quesito posto è relativo al comportamento della UX della componente FO.
";n.a.
n.a.;"InstanceIndex – SUAP FO - popolamento
Dubbi sul popolamento dell’oggetto InstanceIndex relativamente alla chiamata all’endpoint send_instance che la componente SUAP FO opera verso l’e-service della componente SUAP BO.
La proprietà ref (riportata qui sotto) cosa rappresenta e come va popolata?
ref:
""$id"": ""#root/ref""
title: riferimento all'elemento dell'istanza relativo al procedimento
type: string
minLength: 1";"L'attributo ""ref"", indicato nell'InstanceDescriptor, rappresenta il riferimento all'elemento dell'istanza relativo al procedimento. Tale valore deve essere utilizzato per identificare il relativo ""resource_id"" presente all'interno dell'""instance-index (instance-index-schema), necessario per il recupero del documento di interesse tramite il servizio ""/instance/{cui_uuid}/document/{resource_id}"".

Vedi anche Quesito 5";n.a.
n.a.;"come trattare, in caso di procedimento autorizzatorio e SCIA, la disarmonia tra i termini del procedimento unico (definito all’avvio della pratica dal timer ""t_a finire"") con quelli dell’endo procedimento nei casi di richieste di integrazione da parte dell’ente terzo x che nelle specifiche non è definito ? Il tempo che passa, infatti, dal momento in cui l'OPS SUAP riceve la richiesta di integrazione della pratica da parte dell'ente terzo (questa azione interrompe i termini dell’endo) ed il momento in cui, invece, l’OPS sospende i termini del procedimento unico + il lasso di tempo che intercorre dal momento in cui l'OPS riceve l'integrazione dall'impresa fino al momento in cui questo notifica l'ente terzo di tale integrazione, crea appunto uno slittamento di tempistiche che non rende più coerente il tempo massimo di gestione dell'endoprocedimento (e quindi lo scattare del silenzio
assenso o di un riscontro nei termini massimi) con quello del macroprocedimento. Più in generale quale deve essere l’effetto di una sospensione dei tempi dell'endoprocedimento sulle tempistiche più generali del procedimento unico dato che nelle specifiche il timer del procedimento generale si interrompe solo su disposizione dello sportellista ? il caso limite (con conseguenze negative) che potrebbe capitare potrebbe essere quello in cui il silenzio assenso di un endoprocedimento arrivi allo sportellista quando il tempo massimo del procedimento unico è già scaduto (vedere immagine). 

Sempre nel caso di richieste di integrazioni da parte degli enti terzi, come trattare il caso il caso in cui i termini di decorrenza di una richiesta di parere (quindi parliamo di un endoprocedimento) scattano dal momento della trasmissione della richiesta di parere da parte del SUAP all'Ente Terzo (caso di molte leggi regionali della sismica o di prassi per i VVF) che prevedono che i termini relativi ai controlli o al rilascio delle autorizzazioni sismiche da parte del Genio Civile si avviano dal momento della ricezione della pratica al Servizio tecnico del genio Civile (e non dal momento della ricezione della pratica al SUAP) ? 

Come trattare il caso in cui i termini di decorrenza di una richiesta di parere (quindi parliamo di un endoprocedimento), invece che essere sospesi, si
interrompono (cioè il timer dell’endo procedimento riparte da zero) a seguito di una richiesta di integrazione di una pratica da parte dell’ente terzo (caso di alcune leggi regionali della sismica) ?";"Nel momento in cui un ET effettua una richiesta di integrazione della pratica, il BO inoltra tale richiesta al FO, con l'obiettivo di recapitarla al presentatore. Quanto descritto comporta una sospensione dei tempi procedimentali nel momento in cui il BO inoltra la richiesta di integrazione al FO. Pertanto, il BO effettua un aggiornamento dei tempi procedimentali al Catalogo SSU, aumentando tali tempi pari al numero di giorni concessi al presentatore per effettuare l'integrazione. La ricezione della documentazione di integrazione comporta una secondo aggiornamento dei tempi, rimuovendo i giorni non utilizzati dal presentatore per rispondere all'integrazione.

Facendo un esempio: dato un procedimento che ha un tempo T=30, al giorno 3 il BO riceve la richiesta di integrazione da parte dell'ET. Al giorno 14 viene inviata la richiesta di integrazione al FO, comportando una aggiornamento dei tempi pari a +15 giorni  (quindi T=45), ovvero il tempo massimo concesso per effettuare l'integrazione. Il FO inoltra la documentaizione integrata dopo 10 giorni, ovvero al giorno 24. Il presentatore, dei 15 giorni concessi, ha usufruito di 10 giorni per rispondere alla richiesta, pertanto, i 5 giorni extra verrano tolti dal tempo T che diventerà uguale a 40. 
Adottando questa strategia, durante il tempo di integrazione non vengono persi i giorni concessi al SUAP e agli ET per analizzare e lavorare un procedimento e tale informazione è sempre disponibile a tutti i componenti, dato che viene aggiornato l'attributo ""times"" dell'InstanceDescriptor gestito dal Catalogo SSU. 

All'interno dell'oggetto Times sono riportati diversi attributi che definiscono il massimo numero di giorni concessi per effettuare determinate azioni. In questo caso particolare, bisogna soffermarsi sull'attributo ""max_gg_concl_send"", che definisce il numero di giorni limite a partire dall'avvio del procedimento per l'inoltro delle conclusioni da parte degli enti terzi. Le Specifiche Tecniche non prevedono un timer dal momento in cui viene inviata l'instanza all'ET ma viene definito a monte il giorno limite entro il quale tutti gli ET devono inviare il loro parere al BO. 
Assumendo quanto indicato precedentemente, non è previsto un ""reset"" dei tempi concessi all'ET per inoltrare il nuovo esito a seguito di una ricezione di integrazione.";n.a.
56228c2a75bf487199bd44116a0e50ca;"In ambiente di Collaudo abbiamo provato a fare l'inserimento di un nuovo procedimento per Regione Toscana. Compilati tutti i campi obbligatori e agganciato un modulo già esistente, se clicchiamo su ""conferma procedimento"" appare un messaggio di errore che riporta ""Errore procedimento già presente con questa data"" e quindi non riusciamo a salvare.";"La presente richiesta chiede un supporto circa l'inserimento di un procedimento all'interno del Catalogo SSU. Data la natura della richiesta, la invitiamo a contattare InfoCamere per richiedere supporto in merito alle funzionalità ed eventuali bug del sistema del Catalogo SSU rilasciato in ambiente di Collaudo.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";n.a.
n.a.;"Metodo “sendinstance”: l’indice istanza è libero?
";"L'indice istanza (InstanceIndex) contine la lista di documenti associati ad una istanza resa disponibile da una componete (ad esempio Front-office SUAP a Back-office SUAP) che sono identificati univocamente da un proprio resource_id. Il resource_id è un identificativo univoco nel dominio della componente,  quindi è l'unica chiave che permette il recupero di un documento dell'istanza reso dispoponibile dai componenti SUAP ed ET. La resource_id è strettamente legato al ""ref"" della risporsa presente nel istance-description, ovvero il riferimento in relazione al CUI dell'istanza. Tale attributo ""ref"" presente sull'instance-index deve corrispondere presenti  nell'InstanceDescriptor:
 - ""activity_model"" (usecase_proceedings.instance.activity_model);
 - ""attachments"" (usecase_proceedings.attachments).

Così facendo, si crea un legame tra un documento e l'istanza a cui è associato tramite il quale viene garantito l'accesso a tale risorsa tramite il servizio ""/instance/{cui_uuid}/document/{resource_id}"".";n.a.
n.a.;E’ consentito avere nell'index-instance N file appartenenti allo stesso usecase?;"Si, l'instance-index contiene la lista di documenti associati ad una istanza, vedi risposta precedente.

Data una fattispecie (usecase_proceeding), ad essa sarà associato un unico modulo ""activity_model"" ma possono essere prefesenti più documenti ""attachment"". Ogni risorsa deve essere identificata associata ad un unico ""ref"", presente all'interno della istance-description, per garantire un recupero corretto delle risorse.

";n.a.
n.a.;Dalle specifiche si evince che la piattaforma SSU contempla procedimenti nazionali, regionali e comunali che dovranno essere caricati sulla piattaforma secondo le modalità previste dagli Enti autorizzati. Volevamo quindi capire se poi, interrogando le api per un dato Comune, otterremo il procedimento filtrato in maniera corretta. Ovvero se per tale Comune è stato caricato il procedimento specifico comunale, ci verrà ritornato quello. In caso contrario, se esistesse il procedimento a livello regionale il sistema ritornerà quello. Infine, se tale procedimento non esiste né a livello comunale, né a livello regionale, verrà ritornato quello nazionale. Comunque sia, dato un Comun, e dato un procedimento, ci verrà ritornato sempre e solo quello più “vicino” al Comune, non verranno ritornati più procedimenti (es. regionale e nazionale o, nel caso peggiore, comunale, regionale e nazionale). Corretto?;"Si conferma quanto specificato per la logica di recupero dei procedimenti legati ad un ambito territoriale. Il ""territorial_scope"" contenuto all'interno di un procedimento indica l'ambito territoriale dello stesso, identificato dal codice ISTAT a 6 cifre. Tale codice può assumere il valore ""000000"" per ricondurre un procedimento con inquadramento a livello Nazionale, alternativamente, i codici assumeranno le seguenti forme in relazione all'ambito territoriale in cui il procedimento si applica:
  - XX = codice istat 2 cifre regione = REGIONE;
  - XXX = codice istat 3 cifre provincia = PROVINCIA;
  - XXXXXX = codice istat 6 cifre comune = COMUNE.

Il codice identificativo dell'ambito territoriale viene utilizzato per la ricerca del procedimento più prossimo al Comune. In breve, dato un Comune, per la coppia evento della vita e tipologia procedimento, si selezionano:
- il procedimento se definito su base comunale;
- altrimenti, il procedimento se definito su base provinciale;
- altrimenti, il procedimento se definito su base regionale;
- altrimento, il procedimento definito su base nazionale.";n.a.
n.a.;La proprietà “Municipality” ritornata dell’API è quello che nello schema ER viene indicato come “ambito territoriale”? Tale proprietà indica il Comune a cui lo specifico procedimento si riferisce? Cioè la lista dei proceeding con Municipality=XYZ sono tutti i procedimenti presentabili per il Comune XYZ?;"La ""municipality"" rappresenta l'identificativo del comune ed è necessario a determinare l'ambito territoriale del procedimento. L'attributo ""municipality"" è utilizzato per recuperare il/i procedimento/i applicato nello specifico Comune (vedi in merito risposta precedente).

Per quanto riguarda l'ultima affermazione, ricorrendo sempre ad un esempio, è comunque possibile presentare un procedimento che ha territorital_scope=PROVINCIA SAVONA per il comune di Albenga e per tutti i Comuni della provincia.";n.a.
n.a.;"Abbiamo visto che ogni categoria di informazioni prevede l’attributo “version”. L’abbiamo notato sia nello schema ER che nei dati ritornati dalle bulk. Si chiede se tale versione è effettivamente poi usata per ogni entità e, quindi, si chiedono chiarimenti su come questa debba essere gestita\interpretata. Dobbiamo sempre far riferimento alla versione più recente? Facciamo un paio di esempi:
-	Sistema ente terzo: cosa significa la version? Che senso avrebbe far riferimento ad unna versione che non sia l’ultima?
-	Regime amministrativo. Che senso ha far riferimento ad una versione che non sia l’ultima?
L’impressione è che sia stata messa, in forma un po’ preventiva, la version su tutti gli elementi. Ma verrà poi effettivamente utilizzata? Questo è importante per capire come impostare le logiche applicative. Ovviamente il dover gestire un versioning su tutti gli elementi è abbastanza impattante.
Detto questo, facendo riferimento allo schema ER ed ai dati ritornati dalle bulk, sarebbe corretto pensare alla combinazione ID + Version come all’identificativo univoco dell’entità?";"L'attributo version è stato introdotto per tenere traccia di tutte le variazioni delle entità, tecniche o amministrative, gestite nel catalogo. Le entità Tecniche sono tutte quelle entità che hanno tra i suoi attributi il ""Riferimento Telematico"", ovvero tutte le entità che rappresentano i componenti informatici dei sistemi Enti Terzi, Front-Office e Back-Office. Le entità Amministrative sono le rimanenti, quindi tutte le entità che compongono i procedimenti amministrativi. In fondo,  viene riportata due liste di dettaglio per le due categorie descritte.
Provando a spiegare l'utilità di tale attributo in un caso pratico, assumendo che vi siano dei procedimenti SUAP già avviati e nel mentre si verifica un'aggiornamento normativo o tecnico (per le componenti) che non può essere retroattivo. Dato questo caso, tutti procedimenti già avviati dovranno essere chiusi con la versione adottata in fase di avvio, differentemente, i nuovi procedimenti avviati devono essere gestiti utilizzando le nuove versioni delle entità coinvolte.
Constatata l'importanza della versione, si conferma che questo attributo deve essere utilizzato come chiave secondaria insieme alla chiave primaria ID.

Volendo approfondire invece una possibile strategia di attuazione degli aggiornamenti delle entità, si possono definire i due seguenti approcci:
- Aggiornamento entità Amministrative: le entità che compongono i procedimenti amministrativi sono regolamentati dalle norme e i loro aggiornamenti non sono retroattivi, pertanto, tutti i procedimenti SUAP avviati prima di un certo aggiornamento, dovranno essere chiusi continuando ad utilizzare la versione adottata in fase di avvio. Differentemente, i nuovi procedimenti avviati a seguito di un rilascio dovranno seguire quanto indicato nel nuovo aggiornamento;
- Aggiornamento entità Tecniche: le  entità che rappresentano i componenti informatici, possono essere gestite liberamente secondo la libertà organizzativa delle amministrazioni, le quali dovranno definire le loro logiche di routing interno per reindirizzare le richieste ai componenti rilasciati, mantenendo unico il punto di contatto esposto alle altre amministrazioni.

Di seguito, la lista delle entità suddivise per categoria:
- Entità Amministrative:
   - Struttura Ente
   - Sportello SUAP
   - Procedimento
   - Fattispecie Procedimento
   - Endoprocedimento
   - Regime Amministrativo
   - Modulo
    - XSD
    - Schematron
    - Allegato

- Entità Tecniche:  
   - sistema FO
   - sistema BO
   - sistema ET";n.a.
n.a.;"
Interrogando le API che ritornano i sistemi di back-office e fornt-office (/suaps-fo-systems/{id_suap_list},
/suaps-bo-systems/{id_suap_list}) viene ritornato il riferimento telematico: telematic_ref. È il riferimento dell’eservice nella PDND?
È tramite tale riferimento che si dovrà creare la comunicazione con le API del relativo sistema, recuperando quindi tutte le informazioni (certificati, clientid, url, ecc)?";Nel branch approved01 i servizi citati (/suaps-fo-systems/{id_suap_list} e /suaps-bo-systems/{id_suap_list}) restituiscono rispettivamente i parametri e_service_to_bo, e_service_to_cu ed e_service_to_fo, e_service_to_et, e_service_to_ri che rappresentano  l'UUID del servizio sulla PDND esposto dalla componente FO al BO. Quindi, tramite questo attributo viene esposto il punto di contatto tramite il quale  è possibile richiamare i servizi esposti dalla componente FO. ;n.a.
n.a.;"
L’API /competent-administrations-systems/{id_competent_administrations_list} attualmente non ritorna alcun risultato. È corretto attendersi che, analogamente alle api per il recupero delle informazioni di sistema del back-office e del front-office ritornerà, ritornerà il riferimento telematico per agganciarsi ai servizi PDND degli enti terzi?

";"L’API /competent-administrations-systems/{id_competent_administrations_list} deve restituire l'elenco degli Enti Terzi che fanno riferimento alle amministrazioni competenti per cui è stato passato l'id in ingresso.
Telematic_ref è il riferimento telematico del sistema informatico Ente terzo, ovvero l'UUID del servizio sulla PDND esposto dalla componente informatica.

Se il servizio non ritorna alcun risultato, si consiglia di contattare direttamente InfoCamere in qualità di gestore del Catalogo SSU 
";n.a.
n.a.;"
Guardando lo schema ER, si evince che sulla relazione “Competenza procedimento” tra l’entità
“Procedimento” e “Struttura Ente” c’è la proprietà “Comune”. A cosa si riferisce, tenendo anche conto che nell’entità “procedimento” c’è la proprietà “Ambito territoriale” (che le API ci sembra implementino con la proprietà “Municipality”), da noi intesa come Comune di riferimento per lo specifico procedimento?";"L'ambito territoriale rappresenta il livello territoriale (nazionale, regionale, provinciale, comunale) in cui può essere applicato il procedimento, invece, l'attributo ""Comune"" della ""Struttura Ente"" rappresenta il Comune di competenza dell'amministrazione coinvolta nel procedimento.
La proprietà mucipality fa riferimento al codice istat a sei cifre del comune di riferimento.";n.a.
n.a.;"
Ogni procedimento ha una proprietà Comune\Municipality che indica il Comune ovvero il SUAP a cui il procedimento fa capo e, quindi, a cui dovrà essere presentata l’istanza. Corretto?
Chiamando la bulk /proceedings-competent-administrations/{id_proceeding_list}, e passando il codice del suddetto procedimento, vengono ritornate le (altre) Amministrazioni Competenti per lo specifico procedimento. Corretto?
Questo vuol dire che le Amministrazioni competenti, ovvero gli Enti Terzi, sono definiti in maniera statica dato il procedimento, a prescindere da quanto eventualmente dichiarato nel modulo di domanda? Chiediamo questo perché, spesso, in particolar modo nei procedimenti edilizi, il fatto che un procedimento debba essere (o non essere) mandato ad un Ente terzo lo si evince da quanto asseverato nella documentazione. In questo caso, non essendoci relazioni con altri elementi dello schema, significa che la competenza è stabilita a priori. Corretto?
La chiamata ritorna id e versione dell’amministrazione competente. Come deve essere gestita la versione?
Potremmo avere versioni differenti di uno stesso Ente terzo?";"L'ambito territoriale rappresenta il livello territoriale (nazionale, regionale, provinciale, comunale) in cui può essere applicato il procedimento, invece, l'attributo ""Comune"" della ""Struttura Ente"" rappresenta il Comune di competenza dell'amministrazione coinvolta nel procedimento.
La proprietà mucipality fa riferimento al codice istat a sei cifre del comune di riferimento.

Per quanto riguarda invece il quesito posto per il servizio ""/proceedings-competent-administrations/{id_proceeding_list}"", questo restituisce tutte le amministrazioni competenti coinvolte sui specifici procedimenti indicati tramite lista nella chiamata. Tutte le informazioni associate a livello di procedimento amminitrativo vengono fornite durante la fase di popolamento sul Catalogo, per mezzo dei Comuni tramite i servizi human-oriented offerti dal Catalogo stesso. Pertanto, si conferma che l'informazione dell'Ente Terzo coinvolto è stabilito a priori.
L'oggetto associato all'entità delle amministrazioni competenti prevede come attributo la versione, tramite il quale è possibile tracciare gli aggiornamenti di tale entità e rendere gli stessi sempre disponibili. 

Per quanto riguarda il chiarimento posto in merito alla gestione dei procedimenti di ambito edilizio, qualora vi fossero dei procedimenti di tale ambito presentati sullo sportello SUAP, verranno gestiti come endoprocedimenti da indirizzare verso gli uffici SUE di competenza.";n.a.
n.a.;"
La fattispecie (così chiamata nelle specifiche) è l’analogo dello usecase (così chiamato nelle API) che è l’analogo dell’endoprocedimento?";"Usecase e fattispecie rappresentano la stessa cosa.
L'endoprocedimento rappresenta la relazione tra una fattispecie primaria e una fattispecie secondaria dei procedimenti amministrativi. L'endoprocedimento riporta anche un terzo attributo, ovvero ""mandatory"", il quale definisce l'obbligatorietà di attivare o meno il procedimento secondario.";n.a.
n.a.;"
Da quanto emerso nel webinar del 28/11/2024 e, in parte, dalle specifiche tecniche, abbiamo inteso che la corretta interpretazione della “catena” delle informazioni (limitatamente a procedimenti, fattispecie, endoprocedimenti e amministrazioni competenti) è da intendersi secondo la seguente gerarchia:
-Dato il Comune, ottenere i procedimenti attivi (procedimenti per cui Municipality=[Comune])
-Dato il singolo procedimento ottenere l’elenco delle fattispecie
-Data la singola fattispecie ottenere:
     1) Le informazioni di tale fattispecie (primaria)
     2) L’elenco degli endoprocedimenti (ovvero fattispecie secondarie)
     3) L’elenco delle amministrazioni competenti, ovvero gli Enti terzi a cui il SUAP dovrà inoltrare l’istanza

Come prima cosa si chiede se la suddetta interpretazione è corretta. Se così fosse, concettualmente, sembrerebbe corretto partire dai procedimenti. Questo però non è in linea con l’esperienza dell’utente finale che, verosimilmente, dovrebbe partire dalle fattispecie, cioè da un’esigenza più specifica. Abbiamo però riscontrato che le fattispecie sono meno strutturate e organizzate dei procedimenti che, al contrario, sono classificati per tipology e lifeevent, anche se queste proprietà sono talvolta non coerenti con gli usecases associati.
E’ quindi da intendere che i dati forniti non contengono le informazioni necessarie per creare un processo di indirizzamento dell’utente verso il procedimento, lasciando quindi ogni soluzione libera di creare le infrastrutture proprie, purché queste, in ultima sintesi portino al codice procedimento e fattispecie previsti dal catalogo?
Se così fosse, se ne prende atto, ma si fa presente che sarebbe stato forse più coerente fornire anche una struttura per organizzare in maniera coerente ed uniforme per tutte le piattaforme l’accesso all’informazione. Questo a beneficio dell’utente finale.
";"Si conferma quanto definito per la catena delle informazioni associate a procedimenti, fattispecie, endoprocedimenti e amministrazioni competenti.
Di seguito si illustra una possibile sequenza di chiamate ai servizi metadati del Catalogo per accedere a tali informazioni, partendo da un procedimento fino ad ottenere il puntamento della componente ET coinvolta sullo stesso:

 - Recupero della ""tipology"" e ""life event"" partendo dalla ""municipality"" 
    /typologies-lifeevents

 - Recupero dei procedimenti utilizzando gli attributi ""municipality"", ""tipology e ""life event""
    /proceedings

 - Recupero delle fattispecie del procedimento tramite gli attributi ""proceeding_id"" e ""proceeding_version""
    /proceeding/{proceeding_id}/{proceeding_version}/usecase-proceedings

 - Recupero degli endoprocedimenti opzionali partendo dalla fattispecie primaria
    /usecase-proceedings/{usecase_proceedings_id}/{usecase_proceedings_version}/usecase-proceedings

 - Recupero dell'anagrafica dell'amministrazione coinvolta nel procedimento
    /proceeding/{proceeding_id}/{proceeding_version}/{municipality}/competent-administration

 - Recupero della componente informatica dell'amministrazione ET
  /competent-administration/{competent_administration_ipacode}/{competent_administration_code}/{competent_administration_version}/third-party-system

Al fine di migliorare gli artefatti tecnici esistenti, si evidenzia che è attualente in corso la creazione di una descrizione di maggiore dettaglio per garantire il recupero corretto delle informazioni del Catalogo SSU per la creazione di un procedimento SUAP (popolamento dell'instance-descriptor).";n.a.
n.a.;Vorremmo avere alcune indicazioni per quanto riguarda lo stato e l’impostazione che verrà data alla parte relativa agli Enti Terzi, in particolare per il SUE;"Relativamente all'adeguamento delle piattaforme degli Enti Terzi SUAP, sono previste due possibili soluzioni applicabili, overo l'adeguamento dei sistemi attualmente in uso, o in alternativa, l'adozione della soluzione sussidiaria.
Per quanto riguarda invece il SUE, è stata appena conclusa una prima fase di ricognizione con delle PPAA selezionate dal DFP finalizzata ad un valutazione delle piattaforme in esercizio. Seguiranno ulteriori aggiornamenti una volta terminata tale analisi.";n.a.
n.a.;Sempre per il SUE vorremmo capire se l’impianto tecnologico sarà simile a quello del SUAP;A conclusione dell'analisi, si individueranno gli interventi per l'adeguamento dei sistemi SUE, nell'intento di prevedere che gli stessi siano quanto più similari a quelli del SUAP. ;n.a.
n.a.;Sempre per la parte SUE ci servirebbero alcune informazioni circa l’impostazione che verrà data alla gestione degli oneri di urbanizzazione;"Si precisa che la tematica non è trattata all'interno delle Specifiche, considerato che le stesse afferiscono alla sola interoperabilità tra i componenti, mentre il quesito posto è relativo al comportamento della UX della componente FO.
";n.a.
229804b721cc4a93b196228ec713c620;"Ho visto che nell'e-service che l'ET espone al BO per la notifica di una CdSS, /notify, nello schema della Request, CdssNotifyMessage, ci sono solo il canale usato per la convocazione e la data.
Mancano i riferimenti ai CUI per i quali viene indetta la conferenza.
Coma fa dunque l'ET a sapere le motivazioni per cui viene indetta la conferenza e quindi di conseguenza ad agganciare la richiesta ai CUI (immagino possano essere uno o più) delle pratiche interessate per stoppare l'istruttoria collegata in attesa del risultato della conferenza?

Inoltre, come si può recuperare il file associato al campo ""cdss_admin_act_filename""?";"Confermiamo che nel CdssNotifyMessage risultano essere assenti gli attributi necessari per consentire il recupero dell'atto amministrativo allegato alla convocazione della Conferenza dei Servizi Sincrona.
Ci teniamo a precisare che le Specifiche Tecniche sono costantemente soggette a verifica e aggiornamento al fine di risolvere qualsiasi criticità riscontrata e tale segnalazione risulta essere già gestita nei vari cicli di revisione periodica. Nei prossimi aggiornamenti, verrà adeguata pertanto la struttura del messaggio riportando le informazioni utili per garantire il corretto recupero del documento tramite la chiamata al servizio ""/instance/{cui_uuid}/document/{resource_id}"". Al fine di ovviare al problema, allo stato attuale, è possibile gestire il trasferimento dell'atto tramite delle soluzioni extra-sistema.
Tali aggiornamenti sono soggetti ad un processo di approvazione e la loro pubblicazione sarà realizzata nei modi previsti dalla norma.

Per quanto riguarda invece il CUI e le motivazioni, ci teniamo a precisare che:
 - il CUI è presente nel messaggio poichè è un attributo dell'oggetto NotifyMessage che è la classe padre di CdssNotifyMessage;
 - le motivazioni invece vengono riportate nell'atto amministrativo allegato alla documentazione.

Qualora vi sia la necessità di ulteriori chiarimenti, la invitiamo a contattarci tramite il canale di messaggistica del ticket.
Le comunichiamo inoltre che, in assenza di ulteriori richieste, il presente ticket sarà chiuso automaticamente dal sistema entro 7 giorni lavorativi.";"Richiedente   
Dalla risposta deduco quindi che una CdSS è sempre relativa ad un solo CUI. Non è possibile avviare una CdSS per un gruppo di CUI.
E' corretto?

Operatore   
Si corretto, la convocazione è relativa ad un solo CUI"
n.a.;"Buongiorno,
vi inoltriamo la richiesta della software house Starch; come potrete notare, il testo che vi inoltriamo si aggancia ad altre 2 comunicazioni sulle quali il mittente è riuscito a fare chiarezza in autonomia:
“Buongiorno,
mi scuso ma ieri ho sbagliato a darvi l'indicazione dell'oggetto che ci veniva ritornato precedentemente (ho preso una struttura interna nostra).
Confermo comunque che ora ci viene ritornato un oggetto differente da quanto ritornato a inizio dicembre.
Prima l'oggetto aveva questa struttura:
 
{
      ""times"": {
 
??????""start"": Datetime,
 
??????""end"": Datetime,
 
??????""max_admissibility"": Datetime,
 
??????""max_integration_request"": Datetime,
 
??????""max_integration_response"": Datetime,
 
??????""max_conclusions_sending"": Datetime,
       },
      ""proceeding"": {
          ""id"": ""USEC-0000252"",
          ""version"": ""00.00.00"",
          ""description"": ""Segnalazione Certificata di ..."",          
       },
      ""adminstrative-regime"": {
          ""id"": ""SCIA"",
          ""version"": ""00.00.00"",
          ""description"": ""SCIA""
       }
   }
 
 
 
 
Adesso l'oggetto ritornato è questo (https://casa.catalogocl.impresainungiorno.it/catalogo/proceedings-administrative-regimes/PROC-0000516):
 
{
      ""times"": {
          ""max_gg_proc"": 60,
          ""max_gg_correction"": 5,
          ""max_gg_admissibility"": 5,
          ""max_gg_int_req"": 15,
          ""max_gg_int_resp"": 15,
          ""max_gg_concl_send"": 25,
          ""max_gg_cdss_req"": null
       },
      ""usecase-proceeding"": {
          ""id"": ""USEC-0000252"",
          ""version"": ""00.00.00"",
          ""description"": ""Segnalazione Certificata di ..."",
          ""proceeding_id"": ""PROC-0000516"",
          ""proceeding_version"": ""00.00.00"",
          ""schematron_phase"": null
       },
      ""adminstrative-regime"": {
          ""id"": ""SCIA"",
          ""version"": ""00.00.00"",
          ""description"": ""SCIA""
       }
   }
 
 
In merito ad altra nostra osservazione sull'impossibilità di raggiungere api.catalogocl.impresainungiorno.gov.it ci era stato detto che era stato rilasciato un aggiornamento generale del sistema. Può essere che la difformità ora riscontrata sulle API sia legata a tale rilascio? In tal caso, sarebbe utile avere un elenco delle modifiche apportate, quantomeno le modifiche che non garantiscono la backward compatibility, giusto per sapere cosa dover modificare del codice già sviluppato.
A tal proposito si chiede anche quale sia il branch che dobbiamo prendere per ufficiale. Noi ci basiamo su ""approved02"". E' corretto?
Nell'ultima call tecnica, ricordo che mi era stato detto che lo schema ER mostrato (https://raw.githubusercontent.com/AgID/specifiche-tecniche-DPR-160-2010/refs/heads/approved02/image/modello-concettuale-catalogo-SSU.svg) non era aggiornato all'ultima versione. Se ricordo bene, la modifica era relativa alla relazione ""procedimento regime"" che non era più agganciata al procedimento ma allo usecase. Cosa che riscontriamo anche nell'oggetto ritornato dall'api, ma non nello schema er.
 
Grazie mille
 
Saluti“
";"Sulla base della news (https://www.suapsue.gov.it/news/?news_id=26) pubblicata dal DFP sul sito di progetto SUAP&SUE, si evidenzia che è da considerare come branch di riferimento ""approved01"". Inoltre, come specificato da InfoCamere nell'ultimo incontro tecnico tenutosi il giorno 17/12/24, nel mese di dicembre erano in corso gli sviluppi e i test per garantire l'adeguamento del Catalogo alla versione ""approved01"".

Si precisa che non è previsto un documento di change log che riporti gli adeguamenti svolti sulle Specifiche Tecniche dal Gruppo Tecnico.
Si coglie l'occasione per evidenziare che la funzionalità ""compare"" della piattaforma GitHub permette di evidenziare le modifiche apportate tra due branch, come da documentazione ufficiale (https://docs.github.com/en/pull-requests/committing-changes-to-your-project/viewing-and-comparing-commits/comparing-commits). Riportiamo per facilitare la comparazione tra il branch ""main"" e il branch ""apporved01""  la sequenza di azioni da applicare:
   - Seleziona Tab ""Code"" in alto a sinistra
   - Seleziona il branch di interesse (""approved01"")
   - Clicca su ""Contribute"" - verrà aperta una tendina
   - Clicca su ""Compare""
   - Seleziona il branch con cui voglio effettuare una comparazione (di default viene fornito già il ""main"")
   - Tramite il tab ""Commits"" vengono mostrati i singoli commit di lavorazione
   - Tramite il tab ""Files Changed"" vengono mostrati i file aggiornati rispetto a tutti i commit effettuati sul branch
L'effetto della procedura indicata è il seguente URL ""https://github.com/AgID/specifiche-tecniche-DPR-160-2010/compare/main...approved01"".

Per quanto riguarda invece lo schema ER, si ricorda che durante le fasi di aggiornamento delle Specifiche Tecniche, il Gruppo Tecnico ha riscontrato la necessità di modificare la relazione associata ad un regime amministrativo, legando quest'ultimo alla fattispecie e non più al procedimento. La motivazione che ha spinto alla ridefinizione del modello ER del Catalogo è dovuta dal fatto che, come indicato nell'esempio posto nel quesito, gli endoprocedimenti attivati in un procedimento SUAP possono condizionare il regime amministrativo ad esso associato. Quindi, assumendo che vi siano più endoprocedimenti associati ad una fattispecie, il regime amministrativo del procedimento SUAP è determinato dalla fattispecie più condizionante, ovvero quella che richiede più azioni bloccanti per il presentatore. Interpretando di nuovo l'esempio riportato nella richiesta, applicando questa logica, considerato un procedimento che attiva la fattispecie ""Avvio esercizio di vicinato"", a cui sarà associato l'endoprocedimento (ovvero una fattispecie secondaria) ""Vendita di oggetti preziosi"", il regime amministrativo non sarà più SCIA (ovvero quello associato ad ""Avvio esercizio di vicinato"") ma diventerà Autorizzazione/Domanda. 

Si ricorda che le fattispecie sono utilizzate per: 
   - definire 1-a-1 i controlli Schematron da applicare per le verifiche automatiche, pertanto, il regime amministrativo deve essere associato a livello di fattispecie per garantire tali controlli;
   - registrare all'interno del Catalogo gli endoprocedimenti obbligatori per le stesse, ad esempio per ""Avvio esercizio di vicinato"", definendo la fattispecie ""Avvio esercizio di vicinato con vendita di oggetti preziosi"", si rende obbligatorio l'attivazione dell'endoprocedimento ""Vendita di oggetti preziosi"".

Si coglie l'occasione di segnale che sarà previsto l'aggiornamento del diagramma ER del Catalogo SSU secondo quanto precisato precedentemente.";n.a.