Modificare il campo "code" dell'Amministrazione competente in "officecode" per mantenere una coerenza sintattica con "ipacode".

[FCiminelliACN]

Issue Proposta: modificare il campo "code" dell'Amministrazione competente in "officecode" per mantenere una coerenza sintattica con "ipacode" ed evitare ambiguità con gli altri campi "code" delle altre strutture dati.

Occorrenze individuate:

• json-schema "administration-schema" https://github.com/AgID/specifiche-tecniche-DPR160-2010/blob/19e2bccd8eda0acf05f49a8ad4a0460359b4f322/json-schema/administration-schema.yaml#L17
• openAPI "Catalogo SSU" https://github.com/AgID/specifiche-tecniche-DPR160-2010/blob/19e2bccd8eda0acf05f49a8ad4a0460359b4f322/openAPI/catalogo-ssu_meta.yaml#L1764 https://github.com/AgID/specifiche-tecniche-DPR160-2010/blob/19e2bccd8eda0acf05f49a8ad4a0460359b4f322/openAPI/catalogo-ssu_to_bo.yaml#L267 https://github.com/AgID/specifiche-tecniche-DPR160-2010/blob/19e2bccd8eda0acf05f49a8ad4a0460359b4f322/openAPI/catalogo-ssu_to_cu.yaml#L183 https://github.com/AgID/specifiche-tecniche-DPR160-2010/blob/19e2bccd8eda0acf05f49a8ad4a0460359b4f322/openAPI/catalogo-ssu_to_et.yaml#L237 https://github.com/AgID/specifiche-tecniche-DPR160-2010/blob/19e2bccd8eda0acf05f49a8ad4a0460359b4f322/openAPI/catalogo-ssu_to_fo.yaml#L258 https://github.com/AgID/specifiche-tecniche-DPR160-2010/blob/19e2bccd8eda0acf05f49a8ad4a0460359b4f322/openAPI/catalogo-ssu_to_ri.yaml#L184
• openAPI "Front Office" https://github.com/AgID/specifiche-tecniche-DPR160-2010/blob/19e2bccd8eda0acf05f49a8ad4a0460359b4f322/openAPI/fo_to_bo.yaml#L304

[vintra73]

AgID propose solution

https://github.com/AgID/specifiche-tecniche-DPR160-2010/pull/49

[LeonardoBorselli]

Da un punto di vista meramente tecnologico la modifica è da approvare.

Da un punto di vista della valutazione dell’impatto la soluzione è strettamente connessa al #45. In altri termini qual’è l’uso che viene fatto dell’officecode che costituisce un’articolazione di un ente esposta all’esterno ? Ipacode appare essere un identicativo univoco dalla PA (come il CF o la partita IVA) in quanto una volta escluso ogni forma di comunicazione differente dalle specifiche tecniche si esclude il concetto di PEC presente in IPA e resta l’identificaizone univoca dell’Ente.

D’altra parte se la conoscenza del parametro officecode è necessaria per il corretto instradamento delle pratiche anche in questo caso come in #45 si sposta la complissità organizzativa del destinatario in campo al mittente che assumela responsabilità della scelta dell’ufficio di destinazione in quanto parte di un’organizzaizone complessa.

Ad esempio il SUAP comunica con I’ufficio Vigili del fuoco del Ministero dell’Interno o con l’ufficio di Firenze dei Vigili del fuoco?

Il primo caso è ovviamente moto diverso dal secondo in fase di interpretazione, nella modalità di censimento degli enti nel CatalogoSSU e nell’implementaizone del suo utilizzo.

Inoltre appaiono molto diversi gli effetti in base ad esempio al tipo di ente terzo coinvolto (comunale, regionale, territoriale nazionale) soprattutoto perché questi non dispongono di Front office ma solo di Back office.

Il responsabile del procedimento SUAP ha la responsabilità di inoltrare la pratica sulla base della competenza dei procedimenti attivati dall’Impresa/Cittadino, indipendentemente dall’organizzazione interna dell’Amministrazione competente e/o dal/dai sistemi informativi esposti dall’Amministrazione. L’organizzazione e i sistemi informativi potrebbero cambiare nel tempo ma senza influenzare la responsabilità del SUAP

Il CatalogoSSU contiene i metadati per l’istanziazione dei protocolli di comunicazione, per cui la responsabilità dell’instradamento deve essere in capo al CatalogoSSU.

Al momento ad esempio il BPMN indicano le tipologie di destinatario e non e chiara ma modalità di scelta del destinatario specifico.