MBossiniB
commented
1 year ago Buongiorno, oltre al dubbio esposto nel primo commento ne è sopraggiunto un altro a seguito dell'aggiornamento della documentazione. La proprietà codice_beneficiario non è più una proprietà della entry dell'array. Ciò significa che ad ogni entry possono essere associati molteplici beneficiari? Grazie in anticipo
Buongiorno,
mi riaggancio alla issue riportata qua sotto perchè non mi è chiara la risposta alla domanda 1.e).
Nel file PS_PSA_SINA201812.xsd è riportata la seguente dicitura: "tramite cooperazione applicativa è consentito l'invio di una sola prestaizone per ogni XML, nel caso di invio tramite upload di file XML/CSV da applicazione web si possono inviare più prestazioni".
Quindi mi verrebbe da dire che tramite API non sia possibile inserire più di una prestazione per XML e quindi per ogni beneficiario. Vi chiederei una delucidazione perchè potrei aver male interpretato.
Grazie Cordiali saluti Martina Bossini
Domanda 1.a) Pa Digitale sta predisponendo le API di alimentazione del SSIUS dal nostro sistema URBI. Analizzando la sezione relativa alla Get/flussi ci siamo posti alcuni quesiti. Innanzitutto abbiamo interpretato che il parametro 'since' sia la data erogazione dell'ultima prestazione trasmessa; Risposta 1.a) Il parametro since non fa riferimento alla data di erogazione dell'ultima prestazione trasmessa. Si tratta invece di un riferimento alla data del flusso che assume valore esclusivamente internamente al dominio del Welfare Provider ed esclusivamente finalizzato a condividere tra INPS e Welfare Provider l'avanzamento dell'acquisizione da parte di INPS dei flussi prodotti dal Provider. INPS si limita quindi a memorizzare il timestamp dell'ultimo flusso acquisito (parametro ts_flusso della risposta dell'Ente), che sarà poi utilizzato come valore del parametro since nella successiva richiesta.
Domanda 1.b) se ciò è corretto allora vi sottoponiamo i seguenti punti: • in caso di prima chiamata (since=-1) quali prestazioni l'ente dovrebbe restituire? Molti nostri clienti trasmettevano già con URBI i flussi di prestazioni Risposta 1.b) I diversi sistemi di acquisizione di INPS sono tra loro integrati, l'Ente può quindi limitarsi a trasferire le prestazioni non ancora trasmesse su altri canali.
Domanda 1.c) una volta a regime, se l'ultima chiamata è stata fatta con since='data X', e se in urbi sono state create prestazioni con data erogazione pregressa, ovvero minore di 'data X', queste non verrebbero restituite: si potranno continuare a trasmettere con la vecchia modalità? Risposta 1.c) Saranno acquisite regolarmente, l'importante è che il timestamp nel parametro 'ts_flusso', nel JSON della risposta dell'Ente, sia successivo al parametro 'since', indipendentemente dalla data erogazione delle prestazioni inserite nel flusso.
Domanda 1.d) 3.l'operatore abilitato continuerà a generare in URBI i flussi che resteranno in attesa della chiamata Get/flussi? Risposta 1.d) La domanda non è chiara, potete precisare meglio?
Domanda 1.e) 4.se la chiamata viene fatta con la limit=10 e since=dataX, URBI estae tutte le prestazioni erogate dopo la dataX e ne mette in risposta le prime 10 ; se il beneficiario ROSSI MIRKO ha una prestazione in data 1 e un'altra in data 2 noi estraevamo un xml in cui ,all'interno del tag beneficiario, era presente sia la prestazione 1 che la prestazione2, come di seguito riportato: la struttura che segue può considerarsi ancora valida?
dunque si continua a trasmettere sia la prestazione1 che la prestazione 2 ? Risposta 1.e) Come indicato in premessa, il contenuto dei flussi può essere liberamente organizzato dall'Ente, fermo restando che abbiano un timestamp incrementale che permetta a INPS di acquisire per ogni nuova rihiesta dati non ancora acquisiti.
Domanda 1.f)
Risposta 1.f) Fermo restando che i dati degli esempi non sono dati significativi, per i motivi già riportati, il prametro since è relativo al timestamp che identifica il flusso e non le singole prestazioni contenute nel flusso.
Originally posted by @andreacigliano in https://github.com/INPS-it/WaaS.Comuni/issues/10#issuecomment-1706048781