Io avanzo una proposta: anziché aspettare che AgID legga questo intervento (perso in mezzo ad altre migliaia di post, dentro ad altre centiania di thread) perché non cominciamo a strutturare noi una proposta collettiva da presentare ad AgID? Qui ci sono amministrativi, tecnici, avvocati, dirigenti, insomma, una ricchezza di punti di vista diversi mica da poco.
@Andrea_Tironi1 che ne dici di aprire una pagina su GitHub dove ognuno può partecipare dando il proprio contributo? Interventi semplici e focalizzati (partendo dalle esigenze di oggi, dalla situazione as-is e to-be, dai vincoli), pensiamo dopo a strutturare meglio le cose.
Non saremo Wu-Ming ma val pure la pena tentare (anche solo per sintetizzare al meglio l’attuale situazione tra di noi).
Volentieri, proposta collettiva con che obiettivo?
Scrivere un documentino (proposta progettuale) da presentare ad AgID affinché ne tenga conto nella stesura delle prossime Linee Guida (indirizzate ai developer fornitori della PA). In altri termini: “bene quanto fatto ma c’è ancora parecchio da fare e questi sono i suggerimenti/punti di vista di PAL/enti locali da tenere in considerazione ai tavoli di discussione/concertazione, a fini di una maggiore standardizzazione (fuori dal perimetro pagamento), spinta al riuso, minimizzazione del rischio di lock-in”. Una proposita olistica, a tutto campo.
Giusto per passare da un approccio critico a un’azione costruttiva.
io ci sto con tutta la mia ignoranza tecnica (pur essendo un tecnico, non sono sviluppatore) e l’esperienza lavorativa, per quel briciolo che può servire
ciao @pperliti
ecco il repository
ho messo la domanda iniziale
se crei una trama (visto che non ho ancora ben capito cosa vogliamo fare) poi contribuisco volentieri
Andrea
Io credo che il punto sia rivedere il pagamento elettronico in tutto il suo percorso di vita, dalla nascita dell’esigenza alla regolarizzazione contabile.
Oggi, il sistema centrale interviene con regole tassative, di fatto, solo nel dialogo a tre PSP - Nodo - Banca dati dei pagamenti dell’EC, nel momento in cui si paga. Su tutto il resto vige un’autonomia più o meno accentuata.
Versione lunga:
Il focus e’ quindi sul momento del pagamento, ma abbiamo incognite su come gestire, per esempio: scadenza del pagamento, pagamenti rateali (*), rendicontazione(**), RT e RPT (***) ecc.
(*): il modello di avivso analogico ce lo hanno dato, ma nessuna indicazione sulla logica per gestire i pagamenti alternativi. Si fa a livello di PT? O a livello di software verticale dal quale origina l’esigenza del pagamento?
(**): i tag utili per veicolare i dati contabili in modo autocontenuto con il pagamento (che potrebbero facilitare rendicontazione e contabilizzazione, che non puo’ comunque prescindere dal flusso per la chiusura dei “provvisori di entrata”) non sono obbligatori e un PT non ha convenienza a implementarne la compilazione.
(***): per esempio, in una faq si dice di conservare a norma RT e RPT: evidentemente sono oggetti di interscambio ai quali si attribuisce rilevanza documentale e quindi obbligo di conservazione. RT e RPT dovrebbero in qualche modo passare dalla pancia del nodo dei paamenti al sistema di conservazione dell’EC. Capita invece che l’EC nemmeno ha accesso a questi XML. (Poi, altre questioni: prima RT e RPT erano firmati in XAdES, adesso la firma e’ deprecata; poiché per la conservazione la tendenza diffusa e’ ragionare per tipologia documentaria, quali metadati associare a RT e RPT?).
Potrebbero servire definizioni tassative di API per:
- dialogo fra software e PT: come comunicare un’esigenza di pagamento per creare un pagamento dovuto (in attesa), includendo gestione della scadenza (nell’avvisatura digitale, mai partita, si distingue fra la data stampigliata sull’avviso e la data di “spegnimento” del pagamento in attesa), collegamento fra pagamento intero e rate, richiesta di cancellazione di un pagamento in attesa ecc.
- apertura del nodo dei pagamenti per prelievo degli XML di interscambio anche ai sistemi di conservazione e contestuale definizione del set di metadati per la composizione del SIP (pacchetto di submission) e, magari, anche definzione della documentazione utile all’interpretazione dell’informazione (representation data) - del resto OAIS è citato nella legge…
ecc.
Io (concordando con @frantheman ) penso che non si possa prescindere dallo stabilimento di regole chiare e perentorie che disciplinino minuziosamente tutte le fasi dal momento dell’origine del pagamento (ragione fondante del debito e creazione della posizione debitoria) al momento finale della chiusura della posizione debitoria (riconciliazione contabile con emissione della reversale di incasso). Inoltre la coesistenza stessa di più partner tecnologici non comunicanti, la presenza di flussi di rendicontazione correlati ai bonifici cumulativi resi disponibili con giorni operativi dilazionati, la mancanza di un portale unico per l’EC che permetta lo scaricamento periodico di uno o più flussi di pagamenti da importare con semplicità nel software gestionale (equivalente ai flussi della struttura di gestione AdE per gli F24) porta a confusione e ritardi in sede di rendicontazione … i problemi sono sotto gli occhi di tutti gli uffici che si devono smazzare una rendicontazione manuale (e si vedono spesso i problemi anche su questo forum di pagamenti non risultanti all’EC a fronte di un avvenuto addebito operato all’utente dal PSP). Poiché se più sono le gestioni delle entrate (es. vari uffici e/o concessionari esterni) o più sono i software per la gestione delle stesse (programmi diversi non intercomunicanti) non si può comunque prescindere dall’esistenza di più stazioni emittenti degli avvisi di pagamento, si potrebbe però, tramite un portale unico messo a disposizione dell’EC (e, differenziato per codici di segregazione pertinenti, per i concessionari che trattano singole tipologie di entrata) scaricare in modo massivo i flussi xml dei pagamenti con il relativo IUV (o la stessa trasposizione xml della RT) per avere copia della stessa da mandare in conservazione (e oltretutto l’utente debitore abbinando RPT e RT, che dovrebbe poter acquisire in autonomia, potrebbe avere prova davvero liberatoria del pagamento). Oggi come oggi l’EC non vede alcuna RT men che meno la può immagazzinare e conservare, se ha più partner tecnologici i relativi “portali” mostrano gli elementi identificativi del pagamento solo per le entrate governate da loro, le altre sono del tutto incomprensibili… è evidente a chiunque che un sistema manuale di rendicontazione / riconciliazione contabile non può funzionare in presenza di migliaia di pagamenti…
Adoro quanto fai sintesi (così capisco se mi interessa) e poi espandi 
Come vedi ho letto anche il dopo:
- cosa intendi per “pagamenti alternativi”?
- a cosa ti riferisci con tag? intendi i campi tipo codice_bilancio?
- RT e RPT si sa per quanto tenerle?
Eh, lo so. Vedrai che col tempo diventero’ bravissimo e gestiro’ anche io le emergenze planetarie via slogan.
Ho dovuto rileggermi perche’ è passato troppo tempo:
la soluzione unica o le rate (paghi la soluzione unica in alternativa a una rata e viceversa).
Si’, i marcatori dell’XML, le etichette degli elementi, i codici ecc. ognuno li chiama come vuole…
Niente di ufficiale. In ambito archivistico le fatture vanno in scarto dopo dieci anni, periodo dopo il quale si prescrivono i diritti collegati ai pagamenti. Dieci anni sembrerebbe ragionevole anche per RT e RPT.
Quando arrivi a quel livello, ti mettono a capo dell’OMS o diventi un Avengers, scegli tu Tornando al serio, grazie per le risposte
Prego, in qualche altro argomento avevo messo anche un altro paio di aspetti da standardizzare. Uno di sicuro e’:
- generazione e avvio del pagamento da un servizio online senza uscire dal servizio online (es.: pago la tassa di concorso mentre mi iscrivo al concorso). Infatti:
a. non c’e’ una regola condivisa per come creare lo IUV e poi pagarlo;
b. generarlo già è fattibile perche’ piu’ o meno tutti i PT espongono delle API ragionevoli;
c. avviare il pagamento da un servizio online senza uscire dal servizio e’ piu’ dura, perché
d. occorre invocare lo WISP (anche anche fattibile, lo WISP è sempre lui, come Marlon Brando)
e. ma soprattutto occorre gestire il ritorno dallo WISP sul servizio online differenziato in base a pagamento OK, pagamento rifiutato, pagamento interrotto ecc., gestire i tempi per rendere nuovamente disponibile il pagamento.
Insomma, per i punti d. e e., soprattutto, si accavallano e possono andare in corto circuito le logiche del PT e le logiche del servizio online.
Mi pare che da qualche parte avessi proposto di standardizzare questo processo: ogni PT deve esporre una API standard per consentire creazione dello IUV, invocazione dello WISP, gestione del ritorno sul servizio in base agli esiti dello WISP (e, parallelamente, gestione della notifica al servizio online del pagamento avviato modello 3). Fare una verifica anche automatica su tutti i PT sarebbe anche fattibile per il controllore di turno.