Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invio di più prestazioni in un unico XML #11

Open
MBossiniB opened this issue Oct 3, 2023 · 1 comment
Open

Invio di più prestazioni in un unico XML #11

MBossiniB opened this issue Oct 3, 2023 · 1 comment

Comments

@MBossiniB
Copy link

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


 A seguire le risposte alle issues sottomesse:

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)
5. sempre relativamente alla chiamata gest flussi, nell'esempio si legge:
GET /flussi?max_entries=10&since=2017-07-21T17:32:28Z
quindi all'ente viene chiesto di rispondere con 10 prestazioni che abbiamo data erogazione successiva al 2017-07-21T17:32:28Z
nell'esempio di risposta però (di seguito decodificato) sono presenti delle date non coerenti con il since...
DataInizioPrestazione="2015-08-13" (in URBI si prendeva la data erogazione della prestazione)
DataEvento="2016-10-13" (in URBI si prendeva la data del protocollo principale)
DataFinePrestazione="2016-08-13"(in URBI si prendeva la data erogazione della prestazione)
A1.01 A1.02 1 2
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 #10 (comment)

@MBossiniB
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant