La dura vita dell'ente creditore

Faccio riferimento a vari post degli ultimi giorni su questa sezione per lasciare alcune considerazioni dal punto di vista dell’ente creditore “piccolo”. Prego di cogliere sotto la fatica e l’amarezza anche l’intento costruttivo.
Ecco alcuni post a cui faccio riferimento:

Io ci terrei a essere ligio alle regole, convinto che se tutti lo fossero ci sarebbero meno particolarismi e tutto sarebbe piu’ liscio, si offrirebbero servizi migliori ai cittadini e si lavorerebbe meglio in ufficio.

Parto dalla specifica questione del conto corrente postale.
Il mio Comune ha dei conti correnti postali riservati a specifici pagamenti, come le multe per contravvenzioni al codice della strada (non escluderei che qualche norma di legge imponga di averne uno dedicato esclusivamente a ciascun servizio).
L’emissione di avvisi per le multe e’ in fase di realizzazione (non lo nascondo, siamo fuori regola un po’ come tutti, ma ahime’ sembra che ogni comune debba costruire tutto da zero).
I pagamenti attivi tramite emissione di avviso li abbiamo indirizzati sul conto di tesoreria, anche convinti che successivamente con tutti i pagamenti su pagoPA il conto di tesoreria sarebbe stato piu’ che sufficiente e i conti satellite dedicati, inclusi quelli postali, sarebbero andati a morire (esclusi quelli che - mi si dice - sono obbligatori per legge, tipo quelli aperti in caso di presenza di un incaricato o concessionario della riscossione di qualche tributo).
Scopro poi che un grande PSP come PosteItaliane fa pagare solo avvisi su conto postale (non ci vedo ragioni tecniche, ma tant’e’), quindi il conto di tesoreria non basta.

Con tutto l’affetto del mondo, io mi adeguo volentieri alle indicazioni, ma talvolta davvero mi sembrano difficili da comprendere o impossibili da applicare.
E, sempre con tutto l’affetto e lo spirito collaborativo del mondo, sembra che alla fine, fra tutti gli attori coinvolti, gli obblighi siano cogenti solo per le amministrazioni. Gli altri soggetti (PSP e PT), di fatto, scelgono se e a cosa conformarsi.
Che Posteitaliane accetti solo gli avvisi che vuole, l’ho gia’ detto, mi sembra poco conforme (mi viene da pensare che sia piu’ vantaggioso economicamente per loro riversare su conti propri). Per non parlare del fatto che aggiungere la striscia del bollettino sull’avviso prevede una trafila con Poste per “la stampa in proprio”, della quale sulla documentazione pagoPA mi pare non ci sia traccia (e poi si dice che pagoPA solleva gli EC dai rapporti coi PSP). Dopo di che, da quel che mi hanno raccontato, PosteItaliane periodicamente a richiesta sposta quanto incassato dal conto corrente postale al conto di tesoreria.

Proseguendo, qualche giorno fa ho scoperto che nonostante la piattaforma pagoPA preveda l’avvisatura digitale push e pull che, di fatto, consentirebbe per esempio a chi ha un conto in banca di vedere nell’home banking una sezione con tutti i pagamenti da fare vero la PA, i PSP non implementano questa opzione. Quindi, se vuole offrire un servizio un minimo usabile, ogni EC si deve costruire un portale dei pagamenti. Che lo faccia l’INPS, l’ACI, il MIUR per le sue 9000 scuole ci sta. Che ciascuno degli 8000 comuni italiani debba farlo in proprio inizia a essere un po’ meno funzionale.
Anche lo storico dei pagamenti fatti, che e’ informazione nota al nodo dei pagamenti, se si vuole mettere a disposizione è a carico dell’ente creditore.

C’è poi la questione carrello. Per le SANP è onere dell’EC creditore crearlo e farlo avere al PSP. Bene, questo e’ chiaro. E’ una scelta come altre; visto che è un’aggregazione di posizioni debitorie esistenti potrebbe farlo anche il PSP ma è stato scelto cosi’, lo fa l’EC. Ci adeguiamo.
Tuttavia, il Comune “medio” non è che poi abbia grandi competenze di sviluppo software. Fra l’altro ci hanno detto di cloud, di Saas, PaaS, IaaS evv., tutte cose che lo sviluppo sembrano spingerlo fuori dalle amministrazioni non grandi. Quindi il comune medio i software li compra fuori. Li compra fra quelli che ci sono, nemmeno li commissiona. Ma diciamolo, mica sempre ci si azzecca! Si possono anche fare selezioni ponderate e capitolati precisi, ma qualcosa sfugge. Ci sono poi novità normative successive a cui adeguarsi e ai quali il software puo’ non essere preparato.
Se il carrello fosse sfuggito? Nelle SANP c’è, ma non è certo obbligatorio che il PT o chi fornisce il software dei pagamenti lo preveda. Neppure è obbligatorio che il PT metta a disposizione gli XML scambiati col nodo, se trasferisce al sistema informativo comunale le informazioni di massima in un formato suo proprietario non viola nessuna legge o specifica tecnica. Sarebbe parecchio piu’ facile per il comune, che deve fare da sé, sapere che se compra una soluzione pagoPA certe funzioni le ha di default. Invece non è cosi’.

Nel frattempo i comuni che stanno cercando di virare su pagoPA, anzi, non voglio generalizzare, parlo di quello che capita qui: nel frattempo noi riceviamo le lamentele sulle commissioni, sul fatto che alle poste non si puo’ pagare, chi ha tre figli paga sei euro di commissioni al mese, che non si puo’ pagare con carta di credito, che una volta al mese non è possibile pagare gli avvisi da nessuna parte…
Sul portale dei pagamenti lo ammetto, noi ci stiamo provando, ma evidentemente le scelte precedentemente individuate rendono difficile farlo funzionare. Per adesso siamo bloccati all’avviso analogico. Non parliamo poi del fatto che il portale dei pagamenti avra’ accesso solo tramite SPID…

Ci sarebbe poi la questione del POS, che se pago i diritti di segreteria di un certificato in monetine lo faccio fuori da pagoPA se lo faccio via POS dovrei in teoria transitare da pagoPA (anche bypassando la scelta del PSP se mi faccio carico io EC delle commissioni), quando poi mediamente in un comune il POS è attaccato a una presa del telefono ed e’ del tutto indipendente dal sistema informativo…

In definitiva, sintetizzando quanto scritto sopra, a me piacerebbe avere e mi sentirei di chiedere:

  • delle indicazioni passo-passo chiare, che non lascino spazio a interpretazioni;
  • delle indicazioni cogenti anche per PT e PSP (e software house).

Non dico che ai comuni andrebbe dato un pacchetto software completo “plug ‘n’ play”, ma almeno strumenti efficaci per selezionare prodotti e soluzioni in modo uniforme e avere forza verso i fornitori.

6 Mi Piace

Buongiorno Francesco,

hai postato un messaggio veramente articolato e complesso che entra nel merito a molteplici questioni. Ti risponderò solo alle tue argomentazioni sintetiche, disponibile ad approfondire in seguito questioni maggiormente specifiche.

In linea generale le Pubbliche Amministrazioni sono obbligate ad utilizzare pagoPA, implementandone tutti i servizi. Per i soggetti privati PSP l’adesione invece è del tutto volontaria e hanno quindi il diritto di scegliere quali servizi di pagamento integrare. In questo ultimo caso tuttavia le indicazioni sono cogenti.

Le particolarità del caso d’uso pagamento con Poste Italiane sono dovute alla necessità di contemperare l’intero attuale quadro normativo. Mi sembra che la FAQ B6 (https://pagopa-docs-faq.readthedocs.io/it/latest/_docs/FAQ_sezioneC.html#c9-un-ente-creditore-e-obbligato-ad-allegare-allavviso-analogico-il-bollettino-postale) sia sufficientemente esauriente per indirizzare l’Ente Creditore. Ti invito inoltre a valutare il punto 9.1 Linee guida per quanto riguarda l’accredito delle somme incassate.

La piattaforma IO, a breve disponibile, potrà essere utilizzata dagli EC per la distribuzione di avvisi compresi quelli di pagamento digitali utilizziamo. Siamo fiduciosi che l’avvento di questo nuovo prodotto pagoPA favorisca la realizzazione da parte dei PSP dei servizi innovativi che hai auspicato.

3 Mi Piace

Condivido le chiose di Francesco sui diversi punti analizzati.
Quanto all’avviso analogico che deve prevedere l’apposita sezione postale (si ripete, funzionale al pagamento presso uno specifico prestatore), confermiamo che l’iter di autorizzazione alla stampa in proprio è a dir poco anacronistico.
In ogni caso, il punto nodale dell’avviso postale è quello di consentire a Poste di poter accreditare il conto corrente postale e non il conto della tesoreria e di qui, poter richiedere le commissioni anche a noi Enti e non solo ai cittadini pagatori. Nei fatti, è una semplice motivazione economica di Poste Italiane, già ampiamente trattata e discussa, e mai affrontata da Agid e ora pagoPA spa. Il tutto, a scapito degli enti, poiché la stessa Agid, attraverso le linee guida impone agli enti di attivare la riscossione con Poste (in presenza di un conto postale, anche se dedicato a un’altra entrata) e non consentirebbe agli enti di poter scegliere se attivarla o no o negoziare le spese.
Infatti, il post di @Mauro_Bracalari di pagoPA conferma il tutto: un privilegio concesso a Poste Italiane superando le originarie prerogative di pagoPA (nessuna convenzione con i PSP, uniformità di comportamento, minori costi per noi PA, un sistema più efficiente e così via). Uso il termine efficiente proprio per richiamare la necessità di dover ancora richiedere l’autorizzazione alla stampa in proprio … ed essere felici che, dall’alto, ti venga concessa la possibilità di stampare un’ulteriore sezione in un bollettino A4. Che efficienza e che modernità!
Sempre in tema di efficienza e modernità, per poter spostare i soldi in tesoreria e fare le reversali bisogna ancora fare l’assegno postale da portare in banca. Pertanto, quanto dice Bracalari al punto 9.1 delle Linee Guida non esiste o non funziona!
Quanto all’avvisatura digitale, le scelte maturate nel tempo sono a dir poco illogiche. PagoPA prevede infatti un’architettura distribuita degli archivi dei pagamenti in attesa (presso gli enti stessi o presso i propri partner tecnologici); tuttavia, al contrario, successivamente pagoPA chiede di “centralizzare” le informazioni chiave delle richieste di pagamento al fine di consentire l’avvisata push e pull a tutto vantaggio dei PSP. Queste scelte, come la continua modifica delle SANP non fa altro che incrementare i costi e la rincorsa di interventi informativi, a fronte di benefici poco significativi o addirittura assenti. Un sistema come pagoPA, e condivido quanto hai detto, ha bisogno di regole certe, stabili e rigorosamente applicate da tutti. Altrimenti non può funzionare.
Altrettanto irrazionale è la scelta di imporre SPID per l’accesso all’applicazione e per il pagamento sul WISP (prontamente rimosso). Ciò in quanto i numeri di diffusione di SPID non consentono simili scelte e, inoltre, molti account SPID sono rimasti inattivi o non più utilizzati.
Per quanto riguarda il POS di pagoPA, a parte poche eccezioni di cui ho sentito parlare, non ho evidenza di casi di successo e di concreta applicazione.

3 Mi Piace

Ciao.

  1. consiglio se fate temi cosi articolati di dividerli in punti, senno diventa un libro da leggere, sebbene devo dire che è un libro interessante. O almeno metteteci qualche grassetto vi prego :slight_smile:

  2. cerco di rispondere a quello che so per esperienza
    2.1 Poste
    2.1.1 è andata così per la normativa vigente e per fare in modo di fare l’onboarding di poste.
    2.1.2 Un peccato che il pagamento cada su un conto di poste perchè bisogna quindi prevedere una doppia riconciliazione finanziaria (tesoreria e conto poste) il che complica il tutto
    2.1.3 la procedura di attivazione del bollettino poste oltre che non documentata è anche tediosa perchè trovare i referenti poste non è sempre immediato e le risposte sono a volte lunghe e vaghe (con 50 comuni vi posso assicurare che va a fortuna)
    2.1.4 la normativa Obbliga ad attivare poste se si ha un conto poste, per dare ai cittadini massima scelta di pagare

  3. pos@pa: con nexi abbiamo sperimentato il pos@pa. Il pos parla con il software del partner tecnologico,che gli invia l’iuv e gli fa fare un pagamento su pagopa. Poi viene rendicontato il tutto mediante flusso pagopa normale etc etc Se volete dei riferimento per parlarne con nexi chiedete pure che vi mando un messaggio privato sul forum.

  4. il vero game changer,secondo me, all’introduzione di pagopa che vedo nei piccoli comuni è la riconciliazione. Ora viene risolta a diversi livelli:
    4.1 a mano
    4.2 dal PT mediante analisi OPI e poi a mano (ma un a mano meno complesso del punto 4.1)
    4.3 nel software di backoffice (es. ilsoftware che fa la tari parla con ilsoftware del PT e riceve le rendicontazioni, poi riceve da siope+ i giornali di cassa e riconcilia sia in tributi che in contabilità). Questo ha un costo per il collegamento del software di backoffice al PT 8che può anche essere multiplo se viene fatto pagare ogni modulo: es tari multe mensa …).Questo meccanismo non funziona se il software di backoffice è esterno al software contabilità (es. alcuni sw mensa).
    4.4 non hoancora capito come fare la riconciliazione se non ho l’opi
    4.4.1 conto bancario normale (es.multiutilities -> conestratto conto senza opi)
    4.4.2 conto poste (che alla fine somiglia molto a un estratto conto, senza opi)

Se qualcuno ha lumi sul punto 4, ben vengano.

Andrea

@Patrizia_Saggini

2 Mi Piace

Per supportare gli EC nella risoluzione dei problemi di riconciliazione Specifiche Attuative abbiamo schematizzato un motore di riconciliazione applicabile ai pagamenti pagoPA. (https://docs.italia.it/italia/pagopa/pagopa-specifichepagamenti-docs/it/stabile/_docs/SANP_2.2_Sez3_Cap12_Backoffice.html#motore-di-riconciliazione)
Avvalendosi di quanto previsto al citato punto 9.1 Linee guida, gli Enti Creditori possono ricondurre in tale schema anche i pagamenti incassati tramite bollettino ccp.

2 Mi Piace

Aggiungo una considerazione di sintesi.
L’estrema discrezionalità con cui gli EC progettano, implementano, gestiscono il proprio pezzo di banca dati di posizioni debitorie pagoPA rende difficoltosa la realizzazione di servizi online completi e usabili, proprio perche’ e’ difficile l’interoperabilità e l’armonizzazione dei vari componenti coinvolti.

Parte di “allungamento del brodo”: fin tanto che l’EC è un grande EC (es.: INPS) va anche bene la scelta discrezionale, i numero del servizio giustificano qualsiasi scelta progettuale. Ma un EC piccolo (Comune) che ha tot servizi da gestire con tot gestionali e poi sceglie un PT che a sua volta ha fatto delle scelte, ci si rende conto dello sforzo per adeguare i gestionali al PT?

Capisco anche che pagoPA spa, da parte sua, dira’ che quanto avviene dentro il sistema dell’EC è fuori dal suo perimetro d’azione, giustissimo, e che giustamente pagoPA spa è interessata ad avere interazioni e comunicazioni conformi attraverso il nodo con la speranza di vederle sempre aumentare per numero e volume di denaro scambiato.
Qualcuno pero’ si dovra’ anche interessare della sostenibilità delle piattaforme abilitanti. Chi?

1 Mi Piace

Ieri ho fatto un colloquio con i soggetti esterni (=software house coinvolte) per arrivare a dematerializzare completamente la TARI (nota: dematerializzare completamente a partire dal produrre l’avviso in originale informatico fino al pagamento online tramite pagopa).

Ora, i timori erano fondati espressi in linea teorica nel mio post precedente erano fondati. Fra software che gestisce la tari e psp ci sono 4 passaggi intermedi, in tutto 6 sistemi coinvolti:

  1. applicativo tributi
  2. gestore dei pagamenti della suite della software house dei tributi
  3. gestore dei pagamenti della suite di altra softwre house che e’ interfacciata col PT e che si occupa di rendicontare in contabilità
  4. sistema dei pagamenti del PT
  5. nodo dei pagamenti
  6. sistema del PSP (o WISP).

Poiché è normato solo cio’ che avviene in entrata e uscita dal punto 5, per il resto vige piena autonomia. Cosi’ ogni software house implementa, in modo del tutto legittimo, i suoi sistemi nel modo che ritiene piu’ opportuno (i criteri di opportunità dipendono poi dalle politiche e dalla Weltanschaung aziendali).

In questo caso c’e’ conflitto di attribuzioni sia per chi genera lo IUV sia per chi si occupa dell’obliterazione degli IUV non piu’ necessari (rate / intero).

Allo stesso modo, nel “percorso documentale” che accompagna il ciclo di vita della TARI ma che esula dagli scopi di questa sezione di forum, ci sono analoghi conflitti: chi firma digitalmente? chi si occupa di inviare? chi si occupa di tenere traccia della consegna dei messaggi?

Tornando a pagoPA: non sarebbe stato tanto piu’ razionale prevedere una banca dati centralizzata delle posizioni debitorie in attesa di pagamento? Un’unica interfaccia, un’unica logica di gestione del ciclo di vita del pagamento. Cosi’, qualsiasi software che genera esigenze di pagamento potrebbe nascere con il “connettore” verso la banca dati centrale di serie…

1 Mi Piace

Sono d’accordo, sarebbe stato interessante avere una piattaforma (nazionale o magari regionale, sulla base della Regione in cui è ubicata la sede dell’ente, per ridurre il carico su un sito unico) in cui caricare tutti flussi delle posizioni debitorie in attesa di pagamento, come anche una piattaforma centrale in cui mettere a disposizione dell’utente tutte le RT dei pagamenti effettuati da lui.

Io ragiono qualunquisticamente: una mesata di pagamenti verso la p.a. pesera’ quanto un paio d’ore di facebook come dati scambiati, accessi, banda: un sistema informativo unico ce la puo’ fare :wink: Poi si puo’ architettare distribuito, unico replicato, con la blockchain (qualunque cosa sia) ma sarebbe stato bello se fosse stato dal punto di vista logico una cosa sola…

1 Mi Piace

Così poi sarebbero anche più semplici i controlli sulle inadempienze dei contribuenti quando partecipano a gare di appalto. Adesso in teoria dovrei controllare presso ogni Comune d’Italia se il soggetto ha dei sospesi!

Link indicato da # 404 Not Found

Nel frattempo sono uscite le SANP ver. 3.0.0 https://docs.pagopa.it/sanp/specifiche-attuative-del-nodo-dei-pagamenti-spc/premessa