La Piattaforma Notifiche Digitali: ipotesi di implementazione nel sistema informativo (comunale) e flusso di notifica di un atto con riscossione di un pagamento

In due precedenti post ho dato conto delle prime impressioni a caldo dopo l’uscita dell’avviso PNRR che finanzia l’adesione dei comuni alla PND e condiviso alcune considerazioni più estese sulle corrette logiche per implementarla.

Per dare concretezza alle considerazioni condivise, propongo di seguito uno schema di integrazione con descrizione del flusso ipotetico che potrebbe seguire il processo di notifica di un atto con contestuale richiesta di un pagamento.

Si tratta di una proposta personale, frutto di ragionamenti ed esperienze altrettanto personali, che non ha alcun carattere di ufficialità. Fra l’altro, come specificato nell’illustrazione del flusso, sono possibili scelte diverse e altrettanto valide, fermo restando l’impianto complessivo della logica del flusso, che vede nel protocollo informatico dell’ente lo snodo principale e l’interlocutore principale (direi unico) con la Piattaforma Notifiche Digitali.

Qui si dà per scontato che ci sia conoscenza del funzionamento della PND (il manuale operativo lo descrive minuziosamente e con chiarezza) e delle possibilità che offrono le API (qui e qui) esposte dalla PND.

Il flusso è da considerarsi indicativo, perché non prende in considerazione alcuni aspetti:

• non considera alcune vicende del processo di notifica e riscossione quali contestazioni, mancate notifiche, trasferimento della posizione debitoria in caso di mancato pagamento ecc.;
• può essere modificato (v. paragrafo “Variazioni sul tema”) per quanto riguarda la logica delle chiamate alle API esposte dai software coinvolti (push/pull) e la frequenza di attivazione delle attività da reiterare (es.: informazioni su stato della notifica);
• è esposto per un invio singolo: invii massivi richiedono adeguati accorgimenti. Tuttavia, la logica complessiva non varia;
• si riferisce a un flusso privo di errori: le eccezioni nella chiamata delle API o esiti negativi delle operazioni sono quindi da gestire.

Gli attori (software e piattaforme) coinvolti nel flusso sono:

• software che genera esigenza di notifica e pagamento e relativo output documentale (di seguito “Software”);
• Protocollo informatico / Sistema di gestione documentale (di seguito “Protocollo”);
• Archivio dei pagamenti in attesa pagoPA e relativo software di controllo;
• Piattaforma delle notifiche digitali (di seguito “PND”);
• Piattaforma pagoPA (Nodo dei pagamenti-SPC, di seguito “NodoSPC”).

Descrizione del flusso

0. Il Software produce il documento da notificare.
   Lo fa secondo le regole individuate da CAD e linee guida, prevedendo anche l’apposizione della firma digitale. È possibile prevedere produzioni e notifiche massive di documenti serializzati.
1. Creazione del dovuto pagoPA:
   a. il Software crea il pagamento dovuto nell’Archivio dei pagamenti in attesa pagoPA;
   b. l’Archivio dei pagamenti conferma la creazione, comunica gli estremi (IUV e altro) ed eventualmente l’avviso analogico in formato PDF (se il Software non provvede in proprio alla sua creazione).
2. Protocollazione e fascicolazione del documento (passaggi variabili in base alle API esposte dal protocollo):
   a. il Software esegue l’upload sul Protocollo (sistema di gestione documentale) dei file che costituiscono il documento, inclusi allegati e avviso pagoPA, e dei metadati (inclusi dati del destinatario e fascicolo);
   b. il Protocollo conferma l’upload;
   c. il Software chiede la protocollazione e la fascicolazione di quanto caricato in precedenza;
   d. il Protocollo conferma la protocollazione e restituisce al Software il numero di protocollo.
3. Invio tramite PND:
   a. il Software chiede al Protocollo l’invio del documento precedentemente protocollato;
   b. il Protocollo esegue l’upload di file e metadati sulla PND, che conferma l’upload;
   c. il Protocollo richiede alla PND la notifica del documento precedentemente caricato;
   d. la PND restituisce i dati di notifica (IUN)
   e. l Protocollo restituisce al Software la conferma di notifica eseguita e lo IUN.
4. Controllo dello stato di notifica (qui si ipotizza su iniziativa del software – la frequenza dei controlli dipende anche dalla natura del procedimento amministrativo):
   a. l Software chiede al Protocollo lo stato di notifica;
   b. il Protocollo chiede alla PND lo stato di notifica ed eventuali attestazioni opponibili a terzi non ancora prelevate;
   c. la PND restituisce le informazioni sullo stato di notifica ed eventuali attestazioni;
   d. il Protocollo memorizza le informazioni sullo stato di notifica e associa eventuali attestazioni alla registrazione di protocollo;
   e. il Protocollo restituisce al Software le informazioni sullo stato di notifica;
   f. il Software acquisisce lo stato di notifica ed esegue eventuali azioni conseguenti.
5. Fra le eventuali azioni conseguenti, il Software attualizza (sulla base del tipo di notifica eseguita e del tempo trascorso dal momento della notifica) l’importo del pagamento dovuto:
   a. il Software comunica all’Archivio dei pagamenti l’importo attualizzato;
   b. l’Archivio dei pagamenti conferma l’aggiornamento dell’importo.

I passaggi 4 e 5 proseguono ripetutamente fino al pagamento, di cui ha notizia per primo l’Archivio dei pagamenti.

6. Riscossione del pagamento:
   a. l’Archivio dei pagamenti riceve dal NodoSPC la notizia di pagamento e la comunica al Software insieme alla ricevuta telematica;
   b. il Software registra il pagamento avvenuto e avvia le azioni procedimentali conseguenti (variabili in base al procedimento);
   c. il Software trasmette la ricevuta di pagamento al Protocollo;
   d. il Protocollo associa la ricevuta al protocollo precedentemente staccato (o, secondo le regole in uso nell’Amministrazione, crea una nuova registrazione e la inserisce nel fascicolo collegata al protocollo del documento notificato).

Osservazioni

I passaggi da 0 a 2 incluso dovrebbero già essere implementati e in uso nei casi in cui il Software esegua invii tramite PEC verso domicili digitali (generali o speciali).

I passaggi 4b e 4c potrebbero essere logicamente scomposti in 4 passaggi distinti: il Protocollo chiede lo stato di consegna; la PND risponde; se lo stato è variato, il Protocollo chiede le nuove attestazioni; la PND restituisce le attestazioni.

Variazioni sul tema

Passaggio 0: il documento può essere perfezionato dopo la creazione del pagamento dovuto pagoPA e del relativo avviso, se si vogliono integrare nel documento stesso riferimenti puntuali al pagamento pagoPA (es.: codice IUV).

Passaggio 4: l’iniziativa della verifica dello stato di consegna può essere del Protocollo. Ipotesi anche preferibile perché il Protocollo notifica per una pluralità di software e può eseguire controlli su stato della consegna e download degli attestati sfruttando gli “stream” previsti dalle API della PND. In tal caso il passaggio 4 si divide in due tronconi di attività che si svolgono indipendentemente (4a e 4e in sequenza su iniziativa del Software; 4b, 4c e 4d in sequenza su iniziativa del Protocollo). In questa configurazione si può prevedere che il Software comunichi al Protocollo la frequenza con la quale controllare lo stato di consegna, che dipende dalla natura del procedimento.

Passaggio 4: in aggiunta allo stato di notifica, il Software può richiedere al protocollo informatico, che le chiede a sua volta alla PND, l’importo delle spese di notifica.

Passaggio 5, variazione 1: in alternativa, al momento dell’attivazione del pagamento tramite il NodoSPC, l’Archivio dei pagamenti pagoPA richiede l’importo attualizzato al software che ha generato il pagamento dovuto e lo aggiorna prima di emettere la richiesta di pagamento e inoltrarla al NodoSPC.

Passaggio 5, variazione 2: l’Archivio dei pagamenti può interrogare autonomamente il Protocollo per conoscere lo stato della notifica e attualizzare l’importo del pagamento dovuto secondo logiche predefinite. In tal caso deve conoscere i dati identificativi della notifica (IUN ecc.).

In mancanza del Software

Ci sono casi in cui non esiste un software a supporto del procedimento amministrativo che genera esigenza di notifica e pagamento. La produzione documentale, quindi, viene eseguita esternamente a un software strutturato e i documenti prodotti sono protocollati e fascicolati manualmente dall’operatore. In questi casi, il Protocollo svolge alcune funzioni che nel flusso sono a carico del Software, in primo luogo l’iniziativa della verifica dello stato di notifica e di attualizzazione dell’importo.

Per facilitare la fruizione e la condivisione del flusso proposto, lascio a disposizione un PDF di sintesi di questo post, con descrizione del flusso di massimo e riproposizione del diagramma.

---