menu di navigazione del network

Pagamenti telematici al SUAP

Un tipico caso d’uso dei pagamenti di uno sportello SUAP è quello di una SCIA per la quale siano dovuti:

  • Diritti di segreteria (destinati al SUAP)
  • Compensi per prestazioni erogate da ARPA (e a questa destinati)
  • Tariffe per prestazioni ASL (e a questa destinati)
  • Imposta di bollo (destinata a AdE)

Si chiede se questi importi possano essere inseriti in un’unica RPT come datiSingoloVersamento destinati a soggetti diversi e quindi da accreditare su diversi ibanAccredito

Naturalmente, se presente un SingoloVersamento per imposta di bollo, il Wisp presenterà solo i PSP che rendono disponibile il pagamento del bollo.

2 Likes

Buona sera Marco,
è come dici tu: i versamenti ad altri enti (ARPA e ASL) vanno inseriti come datiSingoloVersamento.
L’accoterzza è questi IBAN siano associati al CF del Comune che li incassa e poi li riversa all’ente interessato.

1 Like

Interessante.

Quindi materialmente dovrei avere la profilazione del comune che comprende nell’elenco IBAN anche gli IBAN degli altri enti.

es.
IBAN COMUNE
IBAN ARPA
IBAN ASL

Quando pago (es 100 euro) avrò un modo di dire lato applicativo (in maniera trasparente al cittadino) che dovrà pagare 100 euro, e sotto il sistema dirà al nodo: 10 all’ARPA 10 all’ASL e 80 al COMUNE. Quindi processato il giro (il cittadino paga tramite WISP 100 euro) , gli enti si troveranno 10 euro l’ARPA sul suo IBAN, 10 euro l’ASL sul suo IBAN e 80 euro il COMUNE sul suo IBAN.

Oppure gli IBAN degli enti sovracomunali potranno essere scelti da una combo come IBAN in creazione di pratica.

Ha senso quello che dico?

Andrea

Ciao Alberto,
ti chiederei una precisazione:
Gli IBAN inseriti devono necessariamente riferire a conti correnti intestati al Comune che li incassa e poi li riversa all’ente interessato o potrebbero essere direttamente gli IBAN di conti correnti intestati agli enti destinatari dei singoli versamenti?

Buon giorno Andrea, gli IBAN da accreditare devono essere del Comune che poi riversa agli altri enti.
Gli IBAN sono indicati dal Camune sulla RPT e devono essere preventivamente caricati dal Responsabile dei Pagamenti del comune sul Portale delle Adesioni ed è bene che siano ognuno dedicato ad un ente diverso (ASL,ARPA, ecc) in modo da facilitare le operazioni di riversamento.
Il cittadino non deve scegliere nulla, la composizione della RPT deve essere fatta in modo trasparente all’utente.

Credo di avere risposto alla tua domanda con la risposta ad Andrea.

Cerco di capire se ho capito.

Sono il comune.

Ho tre conti:

IBAN COMUNE
IBAN COMUNE per ARPA
IBAN COMUNE per ASL

Sul portale carico i 3 iban.

Sulla pratica inserisco di pagare 100 euro, di cui 10 su IBANCOMUNEARPA e 10 SU IBANCOMUNEASL e 80 su IBANCOMUNE.

Viene fatta l’RPT associata alla pratica che viene pagata dal cittadino in un’unico blocco.

Quindi sui 3 conti ho

10 euro su IBANCOMUNEARPA
10 euro su IBANCOMUNEASL
80 euro su IBANCOMUNE

quindi la ragioneria deve capire che i 3 sono collegati e mandarne 10 all’ARPA, 10 all’ASL e 80 se li tiene.

Corretto?

Esatto, suggerisco c/c separati in modo che i riversamenti possano essere fatti in maniera cumulativa con tempistiche prestabilite secondo gli accordi tra comune e ARPA/ASL…
Questa è la soluzione immediatamente fattibile, poi potrebbero esserci altre modoalità: ad esempio, coordinate tra gli enti del territorio.

Scusa @Alberto49, ma questa non mi pare una particolare semplificazione, costringe infatti il SUAP ad aprire e gestire tanti conti correnti quanti sono gli enti con cui deve relazionarsi e a gestire le attività dell’ufficio di ragioneria per la rendicontazione e il riversamento.
Se non è possibile versare le competenze degli altri enti direttamente sul loro conto corrente, tanto vale fare un unico pagamento sul conto del SUAP e gestire i riversamenti attraverso il backoffice.

Indubbiamente, è possibile utilizzare un unico conto e splittare i pagamenti a valle… Quella indicata è la soluzione più semplice.

Ho capito il meccanismo che rende probabilmente semplice la vita al cittadino, ma difficile la vita all’operatore comunale, che non avendo interesse ad applicare la questione, rimarrà ai vecchi metodi più che potrà.

Credo che nei servizi oltre al SecuritybyDesign, al CittadinoFirst, al MobileFirst vada previsto anche un PoveroOperatoreDelComuneEnabling altrimenti si rischia che questi servizi abbiano grossi problemi a partire.

Noi abbiamo degli operatori volenterosi che ci stanno provando, d’altra parte se mi metto nei loro panni un giro del genere diventa molto dispendioso a livello di gestione interna al comune invece di semplificare anche lato PA la vita.

Oltre che la semplificazione verso il cittadino, ribadisco, è importante anche la semplificazione del processo interno alla PA nel design delle funzionalità e dei processi. Senza questo aspetto, l’attuazione è sempre complessa. se invece si fa vedere al ragioniere (o chi altro possa trarre frutto dai servizi online nella pa) che il giorno dopo lavorerà meglio o meno, l’attuazione è sicura. La “vendita” va prevista sia lato cittadino che lato PA.

Il cambio di visione potrebbe addirittura rendere più accelerato il processo, perchè come stiamo vedendo sui primi servizi che stiamo attivando, se l’amministrazione PAL decide una direzione, il cittadino si adegua e spesso è entusiasta di poter pagare online quando gli pare o con bollettino dove gli pare e quando gli pare.

Andrea

1 Like

In effetti le attività di questo tipo andrebbero coordinate a a livello locale per fare in modo vengano sfruttate tutte le potenzialità del sistema che consente di comporre un carrello di RPT che il SUAP potrebbe utilizzare per far arrivare i fondi sui conti di competenza (Comune, ASL, ARPA).
Le RT del carrello arriverebbero però al Comune che ha immesso le RPT nel sistema e che dovrebbe poi metterle a disposizione degli altri enti (ARPA e ASL) per poter effettuare la riconciliazione.
Per questo motivo parlo di coordinamento a livello locale per fare in modo che tutti i soggetti interessati siano aderenti a pagaoPA.

Grazie delle risposte.

Se non ho capito male la direzione intrapresa a livello di sviluppo prevede la posibilità di specificare più iban anche non appartenenti al comune in modo da permettere ad un solo oggetto pratica di ottemperare a tutti i pagamenti necessari.

Questo permette al cittadino 1 solo pagamento e ad ogni ente (comune,asl, arpa …) la ricezione della propria parte di pagamento sul proprio conto, ovvero la soluzione ottimale per tutti, senza aggravare il comune di nessuna attività se non la propria riconciliazione.

:tada::tada::tada::confetti_ball::confetti_ball::confetti_ball::balloon::balloon::balloon:

Buongiorno,
per questi casi d’uso di pagamenti a soggetti diversi era previsto dalle SAMP 1.7 l’utilizzo del carrello multibeneficiario cioè sostanzialmente un array di RPT attraverso la primitiva nodoInviaCarrelloRPT.
Probabilmente l’ostacolo più significativo per questa opzione (a parte il suo limitato supporto da parte dei PSP) risiede nel fatto che i diversi Enti Creditori devono usare lo stesso intermediario tecnologico.

Preciso che con le SANP 2.0, già pubblicate sul sito AgID, l’utilizzo del carrello multibeneficiario sarà esteso nel corso del 2018 a tutti i PSP aderenti a pagoPA. Il fatto che diversi Enti Creditori debbano usare lo stesso intermediario tecnologico non costituisce nessun vincolo. PagoPA gestisce il caso di carrello predisposto da un unico intermediario perché, banalmente, è il soggetto che predispone il carrello e quindi quello a cui vengono restituite le Ricevute Telematiche. In linea di principio sarebbe stato possibile (forse) concepire e realizzare altre modalità di istradamento, ma fino ad oggi nessun caso concretamente prospettato ha richiesto tale requisito. La ragione probabilmente risiede nel fatto che se diversi Enti Creditori riescono a concertare la costituzione del carrello, normalmente non hanno nessuna difficoltà a individuare l’intermediario che deve farsi carico del dialogo tecnico con pagoPA.

Il fatto che il SUAP riscuota per numerosi enti creditori non deriva dal fatto che questi hanno concertato la costituzione del carrello, ma dal fatto che il Decreto del Presidente della Repubblica 7/9/2010, n. 160, art. 4 c. 13 e 14 pone in capo al responsabile del SUAP la riscossione

  1. In relazione ai procedimenti disciplinati nel presente regolamento, il responsabile del SUAP pone a carico dell’interessato il pagamento delle spese e dei diritti previsti da disposizioni di leggi statali e regionali vigenti, nelle misure ivi stabilite, compresi i diritti e le spese previsti a favore degli altri uffici comunali, secondo i regolamenti comunali, provvedendo alla loro riscossione e al loro trasferimento alle amministrazioni pubbliche coinvolte nel procedimento stesso.
  2. Il SUAP, espletate le procedure necessarie, trasferisce immediatamente, in via telematica, e in assenza di collegamento telematico non oltre il mese successivo al versamento, gli importi dei diritti di cui al comma 13 alle amministrazioni pubbliche competenti.

È pertanto possibile che le diverse amministrazioni abbiano scelto autonomamente intermediari diversi

Non riesco a capire se stiamo discutendo su come funziona pagoPA attualmente o su come dovrebbe funzionare (in questo caso non mi sarebbero del tutto chiari i requisiti funzionali). Attualmente pagoPA prevede che un soggetto possa inviare un carrello multibeneficiario, cioè contente RPT di diversi soggetti. Il fatto che questo soggetto sia un intermediario di tutti i soggetti le cui RPT sono a bordo del carrello è una tautologia, essendo l’intermediario proprio colui che invia RPT per conto di altri. Quindi benché sia possibile che soggetti diversi abbiano scelto intermediari diversi (anche in numeri superiori a uno) per inviare un carrello dovranno necessariamente averne uno in comune. Per rimuovere questo vincolo occorre modificare la definizione di intermediario, per questo le obiezioni mi risultano incomprensibili.
Suggerisco quindi di cambiare approccio: potreste dirmi quali requisiti dovrebbe avere pagoPA per risultare soddisfacente nel caso SUAP? Forse discutendo in positivo riusciamo a intenderci su cosa manca e porci eventualmente rimedio.

I requisiti sono elencati nel post che ha dato origine al thread:

Non mi è chiaro come questi requisiti siano realizzabili con una soluzione basata il carrello multibeneficiario. A regime, quando tutte le amministrazioni saranno attive su pagoPA dovrebbe essere semplice e normale. Se tu insisti per utilizzare un unica RPT come soluzione per gestire l’attuale transiente se ne può parlare. Occorre però valutare caso per caso costi e benefici di un progetto concreto perchè spesso il diavolo si annida nei dettagli. Non è tema da discutere in termini generali sul forum e quindi ti invito a continuare la discussione in privato.

Non insisto per usare un’unica RPT, ma mi aspetto che la user experience sia che lo sportello del SUAP calcoli gli importi relativi a ciascuna voce e faccia pagare all’utente l’importo totale, preoccupandosi poi di suddividere i singoli importi sui diversi beneficiari in modo trasparente all’utente.

Per fare un esempio, quando compero qualcosa su Amazon non pago separatamente il prezzo del prodotto, le spese di trasporto e l’IVA, anche se gli importi parziali sono destinati a soggetti diversi.