Nuove Funzionalità

Configuration

• [DWSIMULA-790] - E' stato creato il un nuovo cruscotto CARRIERE DOPPIE dentro alla gestione del caricamento dei dati sorgente.
  In questo nuovo cruscotto vengono esplicitate tutte le matricole che risultano avere carriere doppie in ateneo.
  Il caso di carriere doppie vede sempre una carriera in stato di aspettativa ed una carriera in stato in attività ma con una carriera a tempo determinato.
  Dall'interfaccia è possibile vedere entrambe le carriere, lo stato di validità della aspettativa, la data di cessazione della carriera a tempo determinato ed è possibile uniformare la fine della attività di aspettativa con la cessazione nel ruolo in cui si è attivi per avere una corretta simulazione della fine della carriera a tempo determinato e la successiva riapertura della carriera in aspettativa.
  La gestione funziona anche per carriere miste docenti e Tecnici Amministrativi.
  Impostando una nuova data di fine su una della attività di aspettativa (può anche essere inserito lo stesso valore esistente) verrà anche automaticamente inserita una eccezione alle cessazioni (prevalente su tutto) che uniformerà la fine dell'attività con la fine della carriera a tempo determinato.
  
  Le eccezioni che si possono impostare offrono anche la possibilità di configurare come verrà visualizzato l'importo del LORDO e del NON EROGATO PER ATTIVITA, andando a cambiare a livello di matricola il normale funzionamento del foglio di analisi (il LORDO viene sempre visualizzato anche se in attività di aspettativa a percentuale stipendio dello 0% ma con colonna NON EROGATO PER ATTIVITA valorizzata) con la possibilità di annullare direttamente il lordo di coloro che hanno carriere doppie e sono in attività di aspettativa a percentuale di stipendio dello 0%.

Database

• [DWSIMULA-568] - E' stata rivista la gestione del FLAG_CESSATO e del FLAG_IN_SERVIZIO nel seguente modo.
  Il FLAG_CESSATO viene imposto a 1 nel mese in cui avviene giuridicamente la cessazione (quindi deve essere utilizzato per tutti i report di analisi della situazione giuridica).
  Il FLAG_IN_SERVIZIO, che fino ad oggi poteva avere solo valori 0/1 è stato evoluto ed ora può contenere valori compresi tra 0 e 1. Il valore di questo flag sarà l'effettiva percentuale di servizio all'interno del mese e subirà l'influenza in questa valorizzazione solod egli eventi di CESSAZIONE.
  Avrà quindi valore:
  - 1 se la matricola sarà stata in servizio per la totalità del mese
  - 0 se la matricola sarà stata in servizio per la totalità del mese
  - un valore compreso tra 0 e 1 nel mese in cui la matricola ha l'evento di cessazione in base ai giorni lavorati
  Questo flag viene utilizzato come moltiplicatore per influenzare le voci che vanno a comporre il LORDO.
• [DWSIMULA-734] - .
• [DWSIMULA-753] - Questo sviluppo è stato propedeutico al requisito di gestione delle carriere doppie e della gestione del LORDO per coloro che sono in attività di aspettativa.
  
  La soluzione si è tradotta nella nuova interfaccia GESTIONE ATTIVITA che offre all'utente la possibilità di configurazione delle attività per le tre grandi macro-gestioni in cui le attività vengono usate per filtrare i dati.
  Queste 3 macro gestioni sono:
  - GESTIONE EVENTI SORGENTI: questa configurazione ha effetto sulla gestione degli eventi sorgente e quindi vanno considerate le attività che producono veri eventi di CESSAZIONE. L'indicazione è di escludere tutte le attività di cessazione dovute a passaggi di ruolo e di considerate tutte la altre.
  - GESTIONE ATTIVITA: questa configurazione ha effetto sulla gestione delle attività che producono le percentuali di stipendio in caso di attività che decurtano lo stipendio stesso. L'indicazione è di escludere le attività di cessazione per cambio ruolo e di cessazione perchè hanno gestioni proprie e quindi andrebbero a falsare le simulazioni. Le attività di cessazione per cambio ruolo infatti non devono azzerare il costo e sono sempre sostituite da attività con data di validazione sovrapposta per il ruolo attivo. Le attività di cessazione non devono essere gestite perchè l'azzeramento del costo viene demandato alla gestione delle cessazioni automatica e configurativa.
  - GESTIONE ATTIVITA ASPETTATIVA CARRIERE DOPPIE: questa configurazione ha effetto sulla gestione delle attività che producono le carriere doppie. L'indicazione è di configurare come "di aspettativa" solo quelle attività che producono l'apertura di una seconda carriera nell'ateneo (importante: solo le attività che producono carriere nell'ateneo e non in atenei diversi, Es. i comandati).
• [DWSIMULA-766] - .
• [DWSIMULA-785] - E' stato fatto un controllo approfondito di tutte le informazioni "di contorno" (dati non obbligatori) che vengono inserite quando si definiscono degli eventi manuali di entrata.
  E' stato riscontrato che i valori di default inseriti non seguivano la convenzione del "-1", ma alcuni, come nel caso del AFF_ID (id dell'afferenza organizzativa) inseriva il valore "0" che probabilmente era il valore "non definito" del sorgente e che fino ad ora non aveva mai dato problemi, perchè combaciava con il valore non definito caricato pure nel DWH del personale.
  
  E' stata quindi unifromata tutta la gestione di questi valori andando a inserire sempre il valore di default "-1" sicuramente presente in tutte le angrafiche del DWH ed inserite query di aggiornamento in fase di deploy che bonificano i valori esistenti nei set di eventi manuali.

Front End

• [DWSIMULA-768] - Inserito flag che permette di evincere se il pesonale è in convenzione ospedaliera
• [DWSIMULA-870] - Aggiunte le informazioni sul SSD, CAUSALE DI ASSUNZIONE, UNITA ORGANIZZATIVA, % FONTI ENTI, % FONTI MIUR su tutte le visualizzazioni di riepilogo degli eventi manuali docenti.
  Aggiunte le informazioni sul STRUTTURA, CAUSALE DI ASSUNZIONE, % FONTI ENTI, % FONTI MIUR su tutte le visualizzazioni di riepilogo degli eventi manuali TA.

Anomalie risolte

Database

• [DWSIMULA-772] - Il problema deriva dal fatto che il tool simulativo era stato pensato per massimizzare il costo a discapito dell'accuratezza della visione giuridica della simulazione e che risulta avere il dettaglio minimo mensile.
  Impostare il flag di cessazione imponeva quindi l'annullamento del costo per la totalità del mese e quindi, nel caso di cessazione successive al 15 del mese, il flag veniva impostato nel mese successivo andando quindi a considerare il costo totale nel mese dell'effettiva cessazione ma spostando giuridicamente la cessazione nel mese successivo. Nel caso di cessazione dopo il 15 dicembre quindi si aveva lo spostamento della cessazione giuridica nell'anno successivo.
  Questa tipologia di problema di verificava anche per i cambi di inquadramento con l'anticipazione del cambio per avere la massimizzazione del costo con la differenza che, avendo una gestione basata sul numero di mesi di permanenza e la perdita del mese di passaggio, in alcuni casi particolari si aveva l'anticipazione di un mese del passaggio e quindi, nel caso di gennaio, dell'anticipazione all'anno precedente.
  
  CESSAZIONI
  E' stata rivista la gestione del FLAG_CESSATO e del FLAG_IN_SERVIZIO nel seguente modo.
  Il FLAG_CESSATO viene imposto a 1 nel mese in cui avviene giuridicamente la cessazione (quindi deve essere utilizzato per tutti i report di analisi della situazione giuridica).
  Il FLAG_IN_SERVIZIO, che fino ad oggi poteva avere solo valori 0/1 è stato evoluto ed ora può contenere valori compresi tra 0 e 1. Il valore di questo flag sarà l'effettiva percentuale di servizio all'interno del mese e subirà l'influenza in questa valorizzazione solod egli eventi di CESSAZIONE.
  Avrà quindi valore:
  - 1 se la matricola sarà stata in servizio per la totalità del mese
  - 0 se la matricola sarà stata in servizio per la totalità del mese
  - un valore compreso tra 0 e 1 nel mese in cui la matricola ha l'evento di cessazione in base ai giorni lavorati
  Questo flag viene utilizzato come moltiplicatore per influenzare le voci che vanno a comporre il LORDO.
  
  PASSAGGI DI CLASSE
  questo sviluppo ha beneficiato dello sviluppo legato alla gestione delle anzianità di passaggio ed alla nuova gestione dei conguagli e arretrati demandando a questa gestione la correttezza dei dati relaivi alla anzianità di inquadramento e quindi dei casi particolari che potevano in passato creare problemi di anzianità di inquadramento.
  La gestione quindi è rimasta in linea generale uguale a come era nel passato, tenendo sempre in considerazione che il limite di dettaglio per l'inquadramento è il mese, si massimizza il costo impostando per tutto il mese inquadramento di arrivo per il mese di cambio.
• [DWSIMULA-795] - Modificate le variabili di calcolo degli oneri.
  Per i docenti è rimasto tutto uguale ma è stato già previsto il flag per la scelta tra TFR e TFS.
  
  Per quel che riguarda i TA invece è stata attivata la gestione automatica del regime TFR e TFS in base alla configurazione del ruolo che si trova in CSA (il ruolo può indicare chi è in regime di TFR) o, nel caso in cui sia un ruolo in regime di TFS, si controlla se è presente la voce personale relativa all'attivazione del TFR.
• [DWSIMULA-862] - Per risolvere questa siuazione è stata evoluta l'nterfaccia CONGUAGLI e ARRETRATI della parte di caricamento dei dati sorgente.
  
  In fase di deploy della nuova versione su tutti gli ambienti di produzione verrà inserita una query di configurazione degli eventi sorgente che va a controllare le voci personali per ogni matricola andando a salvare nella tabella dei dati degli eventi sorgenti tutti gli eventi di non valutazione o di valutazione negativa andando a controllare l'esistenza degli eventi (149, 159, 173, 171).
  Con il caricamento dati sorgente apparirà tra gli eventi sorgenti anche questa tipologia di eventi, oltre a quelli di cessazione e di cessazione nascosta.
  
  L'interfaccia CONGUAGLI e ARRETRATI presenterà le seguenti 5 nuove tipologie di eccezioni:
  - Aggiungi un evento di mancata valutazione a quelli esistenti
  - Aggiungi due eventi di mancata valutazione a quelli esistenti
  - Aggiungi tre eventi di mancata valutazione a quelli esistenti
  - Valutazione positiva alla prossima futura possibilità - NO conguaglio/arretrato - NO riconoscimento anzianità
  - Blocca ogni tipo di valutazione futura
  
  I dati visualizzati daranno immediatamente l'informazione della data di prossimo passaggio sia in caso di inserimento di eccezioni che in mancanza di eccezioni impostate, farà vedere l'ultimo passaggio effettuato, possibile anzianità riconosciuta al passaggio avvenuto e eventuali eventi di non valutazione o valutazione negativa presenti sul sorgente CSA riferiti al inquadramento attuale per ogni matricola.
  Verrà visualizzata la data di prossimo passaggio ed anche i mesi di anzianità riconosciuti nel caso in cui si tratti di anzianità che ha già superato il numero massimo di mesi di permanenza nell'inquadramento (caso di matricole in attesa della valutazione di passaggi di classe).
  
  La gestione delle eccezioni gestirà anche il blocco della creazione degli scenari nel caso di modifica dei dati sorgenti che rendono le eccezioni impostate obsolete. Offrirà quindi l'evidenza di questa tipologia di eccezioni e darà la possibilità di cambiare l'eccezione o di cancellarla.