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

Gestione errori/modifiche, cancellazioni, inserimenti duplicati #9

Open
MBossiniB opened this issue Aug 2, 2023 · 8 comments
Open

Comments

@MBossiniB
Copy link

Buongiorno,
di seguito riporto alcuni dubbi/domande:

  1. Come verranno gestiti eventuali errori/modifiche a valle di ricalcoli sulle prestazioni?
  2. Come verranno gestite le cancellazioni?
  3. Come si gestiranno eventuali inserimenti di prestazioni già caricate su SIUSS? Per quanto riguarda le prestazioni periodiche, non ci sono problemi perché nel caso in cui vengano mandate doppie vengono scartate. Diversamente, se una prestazione straordinaria viene inviata all'istante t1 e poi nuovamente a t2, viene registrata due volte. Attualmente questo problema viene gestito con i file di cancellazione, per cui prima di caricare un file di inserimento che contiene anche prestazioni già caricate, si carica quello di cancellazione, così eventuali prestazioni straordinarie non verrebbero raddoppiate.
@MBossiniB
Copy link
Author

Buongiorno, vi chiederei un cortese riscontro in merito a questa issue.
Grazie in anticipo

@andreacigliano
Copy link
Contributor

andreacigliano commented Sep 6, 2023

A seguire le risposte alle issues:

• Come verranno gestiti eventuali errori/modifiche a valle di ricalcoli sulle prestazioni?
La prestazione già inserita va annullata e inserita nuovamente (vedi dettaglio sulla gestione dei campi chiave)

• Come verranno gestite le cancellazioni?
Si tratta di annullamenti. Stessi campi chiave con tipo inserimento “C”. (vedi dettaglio sulla gestione dei campi chiave)

• Come si gestiranno eventuali inserimenti di prestazioni già caricate su SIUSS? Per quanto riguarda le prestazioni periodiche, non ci sono problemi perché nel caso in cui vengano mandate doppie vengono scartate. Diversamente, se una prestazione straordinaria viene inviata all'istante t1 e poi nuovamente a t2, viene registrata due volte. Attualmente questo problema viene gestito con i file di cancellazione, per cui prima di caricare un file di inserimento che contiene anche prestazioni già caricate, si carica quello di cancellazione, così eventuali prestazioni straordinarie non verrebbero raddoppiate.
Il SIUSS identifica le prestazioni (tracciato PS-PSA-SINA) in base al valore dei seguenti campi (chiamati “campi chiave”):
• A100 - Codice Ente: Ente titolare dell’erogazione di prestazioni sociali). Ad esempio per i Comuni è il Codice Belfiore del Comune
• B001 - Codice fiscale del beneficiario: Codice fiscale della persona che viene inserita nel sistema come beneficiario della prestazione. Ad esempio in caso di prestazioni indirizzate a minori, sebbene il pagamento venga effettuato al genitore, il codice fiscale da inserire è quello del minore
• BX202 - Presenza Prova Mezzi: è necessario comunicare se la prestazione è soggetta a ISEE (1) o soggetta alla prova dei mezzi ma non attraverso ISEE (2) o la prestazione è in generale soggetta a ISEE, ma sottratta alla prova dei mezzi nel caso specifico (3) o la prestazione non è sottoposta ad alcuna prova dei mezzi (4)
• BX204 - Numero Protocollo DSU: Identificativo del protocollo DSU solo per prestazione soggetta ad ISEE
• BX207 - Codice Prestazione: Il codice della prestazione univoco e determinato dal Decreto Min. del 16 dicembre 2014 n. 206 (Tabella 1)
• BX209 - Protocollo domanda di prestazione: Il protocollo con cui l’Ente ha registrato la richiesta del beneficiario
• BX211 - Data Inizio Prestazione: Data effettiva di inizio prestazione (obbligatoria in caso di prestazione Periodica)
• BX213 - Data Erogazione Prestazione: Data effettiva di erogazione della prestazione (obbligatoria in caso di prestazione Occasionale)
• BX223 - Presa Carico: indica la presa in carico del beneficiario da parte dei servizi sociali
• BX224 - Area Utenza: Le 3 aree per le quali il beneficiario è stato preso in carico dai servizi sociali (1 - famiglia e minori, 2 - disabilità/non autosufficienza e povertà ed esclusione sociale) da indicare obbligatoriamente nel caso in cui sia comunicata a sistema la presa in carico.
Per quanto riguarda invece il tracciato SINBA i “campi chiave” sono due:
• A100 - Codice Ente: Ente titolare dell’erogazione di prestazioni sociali). Ad esempio per i Comuni è il Codice Belfiore del Comune
• C001 - ID Beneficiario: Identificativo univoco che individua il minore beneficiario della presa in carico.
L’utilizzo dei “campi chiave” consente sia di annullare prestazioni inviate sia di gestire eventuali errori/modifiche. Nello specifico:
• Annullamento prestazione: è sufficiente trasmettere una prestazione avente:
 i medesimi valori nei campi chiave di quella che si intende annullare
 il campo “Tipo Operazione” valorizzato con la lettera C
• Aggiornamento prestazione:
 qualora l’errore o la modifica riguarda in tutto o in parte un campo chiave è necessario annullare la prestazione (v. punto precedente) e ritrasmettere quella con i valori corretti;
 se gli errori/modifiche sono relativi esclusivamente a campi non chiave è sufficiente trasmettere una prestazione avente, oltre che il valore corretto nei campi oggetto di aggiornamento, i medesimi valori nei campi chiave della prestazione che si vuole aggiornare. Questo significa che se all’istante t1 viene inviata una prestazione p1 con importo pari 1000 €, mentre l’importo corretto è di 100 €, è sufficiente all’istante t2 (t2> t1) trasmettere una prestazione con i medesimi valori nei campi chiave della prestazione p1, ma con valore del campo importo uguale a 100.
In dettaglio “eventuali inserimenti di prestazioni già caricate su SIUSS”, indipendentemente dal carattere prestazione – periodico o occasionale, non provocano registrazioni multiple nel caso in cui i campi chiave hanno i medesimi valori, mentre se la nuova registrazione ha impatto su uno dei campi chiave al fine di evitare registrazioni multiple è necessario prima procedere all’annullamento della prestazione esistente e quindi alla trasmissione della nuova prestazione.

@MBossiniB
Copy link
Author

Buongiorno,
grazie per la risposta chiara!

Avrei un ulteriore dubbio in merito a gestione errori:
Nel caso in cui il flusso inviato dall'ente in risposta alla GET/flussi generasse ldegli errori lato Inps, ad esempio per un codice di cittaidnanza non riconosciuto, come vengono notificati gli errori all'ente?

@andreacigliano
Copy link
Contributor

Mentre su MODI sono gli enti che ci interrogano e quindi in sincrono hanno anche l’esito della trasmissione, su PDND dove è INPS ad interrogare e quindi la risposta sincrona è il file con le prestazioni, non c’è modo di restituire l’esito. Abbiamo pensato in maniera proattiva, ma la soluzione è ancora in "progress", di esporre un ulteriore servizio per gli enti per recuperare gli esiti delle trasmissioni. Chiaramente per gli EELL l'utilizzo di quest'ultima soluzione può costituire un sovraccarico di lavoro ma purtroppo queste sono le regole afferenti alla PDND. Altra verifica possibile, è interrogare il SIUSS e vedere se la prestazione è stata acquisita.

@MBossiniB
Copy link
Author

Ok, grazie per la risposta.
Eventualmente gli esiti delle trasmissioni saranno disponibili anche sul portale SIUSS nella sezione tramissione flussi - cruscotto verifica?

@refinfsiuss
Copy link

Buon pomeriggio.
Il cruscotto di verifica è relativo unicamente al canale "Trasmissione Flussi". Per quanto attiene la PDND sono in corso approfondimenti sulla modalità con cui l'Ente erogatore potrà interrogare INPS per ottenere l'elenco degli eventuali scarti. Per il momento, per verificare la corretta acquisizione delle prestazioni rese disponibili su PDND, è necessario interrogare i sistemi INPS tramite le operation di consultazione.
Restiamo a disposizione per eventuali chiarimenti o approfondimenti.

@MBossiniB
Copy link
Author

Vi sarei grata se riusciste a rispondere anche alle altre due issue che ho aperto, grazie mille in anticipo!

@matteo-camellini-dg
Copy link

Sempre in merito al problema di avere l'esito dei flussi messi a disposizione a INPS tramite la GET/flussi, è possibile ipotizzare un ulteriore path GET/esiti che INPS invoca comunicando, per ogni idflusso acquisito, l'esito?
E come risposta, il path GET/esiti potrebbe ritornare un ack da parte dell'ente erogatore, in modo da interrompere da parte di INPS la comunicazione dell'esito per quel determinato flusso...
Questa ipotesi avrebbe il vantaggio di far rimanere tutte le operazioni all'interno della PDND con l'ente come erogatore e INPS come fruitore...

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

4 participants