nardil
commented
1 year ago Nell’elenco vengono restituiti oggetti di tipo Flow che contengono solo il nome del flusso (name) e l’identificativo del Psp (pspId), ma non la revision: è necessario quindi recuperare il dettaglio del flusso corrispondente con la:
Io avevo interpretato la coppia psp e fdr come univoca, pertanto sufficiente a sapere se il flusso e' stato o meno gia' acquisito. Vedendo pero' le API lato PSP mi sembra evidente che non sia cosi.
Se l'interpretazione di @lucagargiulo e' corretta, chiedo conferma che le risorse:
- GET /organizations/{ec}/flows
- GET /organizations/{ec}/flows/{fdr}/psps/{psp}/
- GET /organizations/{ec}/flows/{fdr}/psps/{psp}/payments
Ritornano sempre l'ultima revisione pubblicata del flusso identificato dalla tupla ec, fdr, psp
P.S. sarebbe molto utile poter indicare nella risorsa di ricerca dei flussi un filtro sulla data di pubblicazione, cosi da ricevere solo i nuovi flussi da acquisire evitando inutili interrogazioni.
lucagargiulo
marilenapaldino87
In attesa di chiarimenti sulle informazioni contenute in un flusso, provo a descrivere il processo di pubblicazione dei flussi da parte dei Psp e di recupero da parte degli enti Beneficiari, con riguardo ad alcune ricadute auspicate sulla qualità dei dati. Ovviamente sono solo ipotesi fatte in base alle informazioni disponibili, per cui chiedo conferma ai tecnici PagoPA della correttezza di quanto scrivo. POST /psps/{psp}/flows/{fdr} {CreateFlowRequest}
PUT /psps/{psp}/flows/{fdr}/payments/add {AddPaymentRequest}
PUT /psps/{psp}/flows/{fdr}/payments/del DeletePaymentRequest
POST /psps/{psp}/flows/{fdr}/publish
DELETE /psps/{psp}/flows/{fdr}
NOTA: Se le primitive si comportano come descritto sopra, il flusso dovrebbe essere sempre coerente in termini di numero pagamenti e importo totale rispetto ai suoi items, per cui agli enti non dovrebbero più arrivare flussi incoerenti. Dopo la pubblicazione sul nodo il Psp potrebbe accorgersi di aver fatto degli errori e correggere il flusso con ulteriori /add /del e ripubblicare il flusso con un’altra /publish. Come da SACI il nodo renderà disponibile ad un ente solo l’ultima versione del flusso. Ovviamente un ente potrebbe aver già scaricato il flusso con revision inferiore, in tal caso dovrà sostituirlo con la nuova versione. Mi domando se non avrebbe più senso se il nodo rilasciasse agli enti solo versioni stabili dei flussi, perché un ente per aver certezza di avere una versione stabile deve comunque attendere fino a D+4.
Allo stato attuale un ente beneficiario dovrebbe:
Recuperare l’elenco dei flussi pubblicati negli ultimi 30 giorni dai Psp:
Le informazioni vengono restituite una pagina per volta per cui è necessario eseguire un ciclo per ottenere tutte le pagine. Nell’elenco vengono restituiti oggetti di tipo Flow che contengono solo il nome del flusso (name) e l’identificativo del Psp (pspId), ma non la revision: è necessario quindi recuperare il dettaglio del flusso corrispondente con la:
A questo punto l’ente può verificare se:
Un’alternativa per il punto 1 può essere quella di inserire comunque tutte le revision, ma di interrogare il repository locale estraendo sempre solo l’ultima revision. Per i flussi per cui la data corrente risulta > regulationDate + 3 recupera, se non già fatto, i payments associati e li archivia nel repository locale associandoli all’ultima versione del flusso:
In questo modo i flussi con i Payments associati sono solo quelli stabili (non possono più esserci ulteriori versioni) ed è possibile iniziare per essi le attività di rendicontazione e riconciliazione.
NOTA: se le ipotesi fatte sulle modalità di salvataggio dei flussi da parte dei Psp sono corrette, la coerenza dei flussi dovrebbe essere garantita, più precisamente dovrebbero essere garantite le seguenti condizioni:
NOTA: se la struttura Flow restituita dalla GET /organizations/{ec}/flows riportasse anche la revision del flusso si potrebbero evitare un po' di chiamate alla GET /organizations/{ec}/flows/{fdr}/psps/{psp} per verificare se si tratta di una nuova versione del flusso.