Salve, avrei bisogno di un aiuto se possibile.
E’ possibile fare pagamenti PagoPA oltre la data di scadenza riportata nel documento dove è esposto il codice IUV/Codice Avviso IUV? Se la risposta è sì, vale anche per il bollettino analogico PagoPA che ha i bollettini TD 896 PA?
Uno degli aspetti cardine di PagoPa mi sembrava fosse il fatto che non era possibile pagare dopo la scadenza ma da alcuni PSP mi è arrivata l’informazione che la data di scadenza è indicativa …
Si è possibile ma Il problema non è del PSP o di pagoPA, dipende da come l’Ente Creditore che ti ha mandato l’avviso, gestisce la scadenza.
Ciao,
L’ente creditore usa come partner tecnologico Poste Italiane. Sono stati predisposti dei flussi dati come da specifiche di Poste e nelle specifiche veniva richiesta solo la data di scadenza del pagamento. E’ possibile avere dettagli maggiori su come può essere gestita la scadenza?
Per problematiche implementative e chiarimenti tecnici puoi scrivere ad attivazionepagopa@agid.gov.it
Buongiorno. Quindi l’Ente creditore può stabilire che il pagamento non può essere effettuato oltre la data di scadenza. O sbaglio?
Se l’Ente Creditore è una Pubblica Amministrazione il comportamento dopo la scadenza non dovrebbe essere discrezinale, ma determinato dalla normativa specifica connessa alla natura del pagamento.
Da un punto di vista tecnico, il protocollo realizzato da pagoPA per il pagamento ad iniziativa PSP (modello 3) prevede, prima dell’effettiva riscossione del dovuto, una comunicazione con la quale il PSP chiede all’Ente Creditore (tramite il suo partner/intermediario) una verifica del pagamento.
In questa sede l’EC ha l’opportunita’ di comunicare
solo nella prima eventualità il PSP procede con la riscossione del dovuto, altrimenti il processo di pagamento si interrompe.
Quindi, tirando le somme se ho capito bene, da un punto di vista tecnico la scadenza effettiva dell’avviso analogico dipende dal sistema informativo dell’ente creditore (= dal partner tecnologico se c’e’) che può implementare come preferisce la modalita’ per dare risposta al PSP. In definitiva l’avviso scade quando non è piu’ “disponibile” presso l’ente creditore.
Corretto?
Al contrario, per l’avviso digitale che pero’ non viene usato, esisterebbe un elemento “dataScadenzaAvviso” (data successiva a “dataScadenzaPagamento”) che decreta la fine della processabilità dell’avviso.
Esatto
Dipende da cosa si intende per scadenza e disponibilità dell’avviso. Come precisato da @Mauro_Bracalari, il ciclo di vita dell’avviso deve rispettare anche le normative inerenti il servizio oggetto del pagamento.
Se per servizio di avvisatura digitale intendi quello dell’App IO, e’ possibile indicare la data entro la quale l’avviso deve essere pagato, ma questo non preclude la possibilità di pagarlo successivamente. La data indicata e’ utilizzata al fine di popolare l’agenda inclusa nell’applicazione ed abilitare eventuali promemoria.
Il processo che realizza l’App IO e’ il medesimo del modello 3, pertanto l’avviso (digitale) viene sempre verificato in sede di pagamento comunicando con l’Ente Creditore.
Come giustamente sottolinea @nardil pagoPA modello 3 prevede l’interazione fra PSP e EC al momento del pagamento. Questo fornisce all’EC l’opportunità di gestire tecnicamente ogni possibile evento intervenuto successivamente all’emissione dell’avviso di pagamento, dandone tempestiva comunicazione al pagatore. Si tratta di una importante innovazione che consente di tutelare il pagatore evitando, per esempio, di incorrere in pagamenti incapienti, non dovuti o ripetuti.
Il processo di pagamento tuttavia non dipende da quale avviso (analogico o digitale) sia stato innescato. Le differenze che sussistono fra i due casi quindi, sono giustificate unicamente dalla gestione degli avvisi
Perdonatemi se insisto, ma ritengo necessario comprendere bene per poter interagire in modo corretto con fornitori, colleghi ecc.
In definitiva l’avviso analogico a spasso per il mondo è pagabile fin tanto che l’EC/PT non lo “toglie” dal suo sistema. “Togliere” non per forza nel senso di cancellarlo, anzi, preferbilmente nel senso di marcarlo come scaduto/pagato/annullato ecc. E come gestire l’aggiornamento delle posizioni debitorie sul proprio sistema è a discrezione di EC/PT.
Quindi anche con l’avviso digitale il raggiungimento della “dataScadenzaAvviso” non inibisce il pagamento?
Comprendo i benefici derivanti dall’interazione fra PSP e EC al momento del pagamento e la possibilità per l’EC di aggiornare in tempo reale la posizione debitoria a dati di avviso invariati. Intravvedo pero’ anche delle difficoltà logistiche nel mandare in scadenza gli avvisi se non c’è stata una attenta analisi e un’accurata progettazione/implementazione del dialogo col PT.
Forse, dico forse, far viaggiare la data di scadenza (reale) dell’avviso fra i dati obbligatori che l’EC invia al PSP al momento del pagamento solleverebbe EC e PT da implementare soluzioni che abbassano il livello di interoperabilità fra sistemi diversi (nel senso che piu’ cose avvengono a livelli di sistema informativo dell’EC piu’ diventa difficile far parlare i gestionali che producono esigenze di pagamento e il sistema dei pagamenti).
Spiego meglio: il PSP chiede “questo pagamento e’ dovuto?” e l’EC risponde, parafrasando @nardil:
Scusate ancora, ma il tema mi sta a cuore perché penso con preoccupazione a come faremo quando dovremo mandare alla riscossione coattiva gli avvisi non pagati per un dato servizio. Sarebbe fondamentale che in quel momento gli avvisi originari fossero non piu’ pagabili. Ahinoi il nostro PT, per sua scelta, mantiene in vita gli avvisi a tempo indeterminato. Se avesse dovuto comunicare al PSP, quando interrogato, una data di scadenza probabilmente avrebbe previsto di raccogliere il dato dai gestionali verticali che gli trasmettono i dati.
Ciao Francesco, devo dire che non riesco bene a capire la causa di tuoi timori. A differenza del passato (Mav o bollettino ccp) l’avviso di pagamento pagoPA è emesso dall’EC non dal PSP incaricato dell’incasso. In realtà non esiste più il concetto di PSP incaricato dell’incasso. Lo stesso avviso è utilizzabile presso tutti i POS che offrano servizi modello 3 (POS, ATM, internet banking). Inoltre qualunque sia il PSP scelto dall’utente il processo di pagamento sarà sempre il medesimo, purché innescato dal medesimo numero avviso.
Alla luce di ciò non riesco a comprendere la seguente frase:
Il pagamento ad iniziativa PSP ha sempre il ciclo di vita descritto dalle specifiche indipendentemente dalla modalita’ di avvisatura
Nel caso di avvisatura digitale, il software che riceve l’avviso potrebbe realizzare logiche che impediscono il pagamento degli avvisi scaduti, ma sono al di fuori del perimetro di pagoPA. Negli avvisi dell’App IO ad esempio c’e’ l’equivalente parametro due_date che, come detto, viene usato per schedulare il pagamento nel calendario, ma non lo impedisce.
Per discutere eventuali proposte migliorative dei processi o API pagoPA, credo che il luogo più adatto sia l’issue tracker dei progetti su GitHub (Developers Italia · GitHub)
Interpreto che il vostro PT implementi l’archivio dei pagamenti in attesa senza darvi modo di gestirne la scadenza o l’aggiornamento… Ahivoi…
Non voglio monopolizzare la discussione e portarla fuori tema, pero’:
Il mio timore e’ che purtroppo nessuno e’ in grado di parlare alle macchine e imporre loro sul momento di eseguire operazioni anche ragionevoli, occorre sempre un po’ di progettazione e programmazione, operazione quest’ultima che è prerogativa di pochi e, in un sistema avviato, e’ prerogativa di chi detiene il sistema. In questo caso direi il PT, l’EC ha ben poca voce in capitolo sui dettagli specie quando si parla delle caldeggiate soluzioni SaaS.
E’ parzialmente cosi’: la scadenza è un dato che il PT non chiede ai gestionali che dialogano con lui; i pagamenti, come dicevo, restano in vita a tempo indeterminato. Fino a poco tempo fa ci dava possibilità solo di cancellarli (o disabilitarli) da sua interfaccia web o da comando del gestionale. Dopo alcune interlocuzioni ha implementato dei meccanismi per consentire agli EC di modificare alcuni dati a IUV invariato (questo solo da comando del gestionale).
Tirando le somme, la disabilitazione/cancellazione/indisponibilità del pagamento dell’avviso dipende da più software che operano con logiche differenti. Nel nostro caso in realta’ i software sono 3: il gestionale del servizio, un “middleware” che raccoglie le esigenze di pagamento di tutti i gestionali e dialoga col PT, il software del PT che gestisce i pagamenti in attesa e il dialogo col nodo dei pagamenti. Visto che ciascun software, in assenza di standard, linee guida o indicazioni, ha implementato suoi metodi per gestire la scadenza, mi ritrovo in questa situazione:
Cosi’ quando decideremo (presto) di passare ala riscossione coattiva di qualche migliaia di avvisi, o accettiamo di mantenere gli avvisi iniziali attivi o cancelliamo le posizioni debitorie dai nostri sistemi rinunciando alle prove dei debiti insoluti. Oppure ancora estraiamo i dati degli avvisi da bloccare e chiediamo al PT di intervenire manualmente, cosa che non è particolarmente elegante.
A parole la soluzione è anche facile ma, a parte la programmazione prerogativa di chi programma e gestisce quei software, c’e’ anche da considerare che si tratta di software commercializzati verso la pluralità di amministrazioni e che in ogni amministrazione si trovano potenzialmente a interagire con altri software.
Si è capito che la gestione del database condiviso dei pagamenti pagoPA in attesa in tutta Italia è “fuori dal perimetro di pagoPA”, che si preoccupa solo del formato di scambio attraverso il nodo. Per il resto ogni EC (cioè ogni PT) si tiene il suo pezzo di database con la struttura dati e le logiche che preferisce.
Per quello proponevo, e posso farlo sul github se ritenete, che l’esplicitazione verso il nodo di una data di scadenza dell’avviso che viaggia sempre insieme ai dati scambiati fra gli attori di pagoPA potrebbe spingere i vari sistemi di pagamenti pagoPA degli EC/PT a uniformare le logiche di funzionamento.
Conclusione: servirebbe qualcuno che si preoccupi anche di cosa avviene fuori dal perimetro, altrimenti e’ la giungla.
Esattamente dove potrei lasciare il mio modesto contributo per dare un po’ di ordine ai processi pagoPA per la parte che si svolge nel perimetro EC/PT?
Il colloquio tra EC e PT non e’ coperto dalle specifiche pagoPA e non mi risultano ci siano progetti di standardizzazione dei processi e delle interfacce di integrazione a partner o intermediari.
Se invece vuoi suggerire modifiche alle api/processi pagoPA, proverei qua: https://github.com/pagopa/pagopa-specifichepagamenti-schemi/issues
Grazie.
Non mi riferivo comunque al dialogo fra EC e PT ma alle logiche con cui gestire i pagamenti in attesa nei sistemi informativi degli EC.
Ribadisco che non interessarsi di un minimo di standardizzazione nei processi interni ai vari pezzi di questa enorme banca dati distribuita di pagamenti in attesa, a mio avviso, rende il sistema complessivo un po’ zoppo e potrebbe impedirgli di decollare veramente nell’amministrazione periferica e locale.
Nel caso della scadenza degli avvisi si potrebbe ovviare trasferendone la gestione dentro il perimetro dei processi legati al nodo o comunque prevedendo nei flussi di dati attraverso il nodo un riferimento puntuale alla scadenza, in modo da obbligare i sistemi locali a gestire la scadenza in modo efficace e standardizzabile.
pagoPA standardizza i processi, ad esempio per il pagamento di avvisi: https://docs.italia.it/italia/pagopa/pagopa-specifichepagamenti-docs/it/stabile/_docs/SANP_2.2_Sez3_Cap10_PagamentoPressoPSP.html
Nel caso della scadenza e’ gia’ prevista la sua gestione nei flussi dati poiché in sede di verifica/attiva l’EC deve indicare se il pagamento e’ dovuto oppure scaduto/annullato/duplicato/etc… ( vedi spec
)
Come poi lo stato del pagamento (dovuto, scaduto, annullato, …) sia determinato dall’EC non viene specificato e ritengo sia corretto cosi. Ma questa e’ la mia opinione.
In effetti in Regione FVG, che fa da intermediario tecnologico per gli enti del territorio regionale, abbiamo scelto di uniformare la gestione degli avvisi analogici e digitali, portando la data di scadenza dell’avviso fra le informazioni che consentono di gestire la posizione debitoria. Ad un pagamento quindi associamo la data di scadenza che determina ad esempio da quando bisogna iniziare a contabilizzare gli interessi di mora, e la data di scadenza dell’avviso, che determina quando quel pagamento non può più essere pagato. Superata tale data infatti non sarà più pagabile ne online né presso i psp (paaVerificaRPT risponderà KO). Fino a tale data, anche dopo la scadenza prevista del pagamento, sarà pagabile. Eventuali interessi di mora o sanzioni collegate al superamento della scadenza del pagamento al momento vengono inserite in un pagamento separato, ma prevediamo in futuro di attivare una notifica al gestionale in modo che possa agire di conseguenza e/o di intercettare al volo un pagamento oltre il termine.
In effetti però sarebbe bene standardizzare tale comportamento a livello di specifiche, noi lo abbiamo dedotto dal fatto che nell’avvisatura digitale era prevista la data di scadenza dell’avviso, ma rimane una nostra interpretazione. Anche in considerazione del fatto che l’avvisatura digitale non è mai stata attivata e sembra che farà uso di io, cosa di cui peraltro sono venuto a conoscenza leggendo sul forum, le specifiche non sono mai state aggiornate (come per paaAllegaRPT peraltro…)