> Bollettini Periodici 
OGGETTO: Novità 6.01.00 e 6.01.05 & Gestione dei debiti formativi
Bollettino inviato giovedì 03/07/2008 ore 15.30
Validità della comunicazione: ●●●●
argomenti: Debiti formativi, cache, spedizione interrotta, potenziale studenti, visualizzatore di spedizioni, Sondaggi
Un saluto a tutti!
In questo bollettino focalizzeremo l’attenzione su molteplici novità ed implementazioni introdotte.
CHIUSURA RILEVAZIONI ANNO SOLARE 2007: VALUTAZIONI
Come ben sapete, venerdì 30 Maggio si è conclusa la rilevazione “annuale 2007”, a seguito della quale sono stati ufficializzati a giugno I risultati ottenuti dai vari Atenei, in termini di punteggio ottenuto ed eventuale fascia di contribuzione elargita. Il sicuro sforzo che vi è stato richiesto è stato premiato da risultati di qualità davvero molto alta e tutto questo ci conforta.
Avrete sicuramente notato come I dati dell’Anagrafe continuino ad affermarsi sempre di più come sorgente di informazioni universitarie “certificate” sullo stato degli Atenei (si pensi al recentissimo ambito PRO3 sulla programmazione triennale 2007/2009).
Tutto questo a dimostrare non solo la vitalità del progetto Anagrafe ma anche il crescente e costante riferimento ai dati ANS da parte del Ministero e dei vari organismi preposti.
Il flusso di invii prosegue con continuità mensile, richiedendovi, fino al termine del corrente mese, l’invio minimo dei soli dati che riguardano le 7 spedizioni dell’anno accademico 2007/08.
RICHIAMO SULLA TIPOLOGIA DI RICONOSCIMENTO NELLE ATTIVITA’ DI INGRESSO
Ricordiamo che un’attività riconosciuta è di ingresso se la sua tipologia è d’ingresso, altrimenti è di carriera, cfr Bollettino Agosto 2006. Poiché da recenti controlli, il numero di CFU di ingresso sembra risultare inferiore di quanto atteso, vi invito ad effettuare verifiche che mirino ad evidenziare l’eventuale presenza di attività riconosciute SENZA tipologia di ricoscimento: queste situazioni vanno sanate, pena la non trasmissione di questi crediti.
La seguente select vi può aiutare nella loro individuazione
select *
from p11_ad_sce
where sta_sce_cod=’S’ –attività superata
and ric_id=2 –riconosciuta
and tipo_ric_cod is null –senza tipologia di riconoscimento
and p11_ad_sce.stu_id in (select stu_id from p01_stu_ans) –variate a piacimento gli studenti da analizzare
Come in precedenti occasioni, vi chiedo di provvedere con le opportune correzioni (nel caso siate autonomi nella gestione della base dati), altrimenti di rifarsi al Capo progetto, indicando chiaramente le modifiche da apportare.
Le versioni 6.01.00 e 6.01.05 del prodotto contengono anche dei nuovi controlli per intercettare e sanare attività che possano essere sfuggite poiché non gestite correttamente.
Siete invitati con le nuove versioni a riprendere i controlli delle schede 3 di tutti gli anni accademici; si consiglia la produzione di file di test e, previa verifica della bontà degli stessi, alla ritrasmissione completa dei dati, indicativamente a partire dalla versione 6.01.05-b01.
STUDENTI RIFIUTATI e STUDENTI INVIATI NON REALI
Pongo alla vostra attenzione casistiche di studenti sulle quali è bene soffermarsi:
– STUDENTI RIFIUTATI: indica gli studenti che non entrano in Anagrafe Nazionale Studenti. Ormai questo numero è nell’ordine delle UNITA’ anche per gli Atenei con decine di migliaia di studenti. È importante che manteniate costante il vostro impegno di far tendere a 0 (zero) gli studenti in questa situazione, sanando gli errori bloccanti segnalati dal file ERR o escludendoli dagli invii se sono studenti fittizi; ricordate che dal FARO la situazione ideale è quindi quella di avere 0 studenti rifiutati per ogni anno accademico.
– STUDENTI INVIATI NON REALI: vi debbo segnalare che continuano a verificarsi trasmissioni di carriere NON reali, che avvengono per una gestione errata delle stesse, magari a seguito di chiusure introdotte dall’Ateneo e quindi non riconoscibili dal sistema. Queste carriere vanno individuate ed escluse dalla trasmissione dei dati. Il motivo principale di errore è spiegabile per quanto segue: il motivo di chiusura ERRIM è quello ufficiale che indica una carriera nata per errore (il motivo indica l’errata immatricolazione) e questi studenti sono esclusi naturalmente dagli invii. Se però utilizzate motivazioni da voi inventate (ricordandovi che è bene NON creare motivi ad hoc per le vostre esigenze, quanto più utilizzare caratteristiche quali le note studente), la carriera viene ERRONEAMENTE trasmessa.
Utilizzate la seguente select per effettuare dei controlli sui motivi di chiusura: otterrete il numero di chiusure con la relativa codifica ANS MIUR.
select mot_stastu_cod, (select id_motivo from mot_stastu where mot_stastu.mot_stastu_cod=p01_stu.mot_stastu_cod)
as motivo_miur, count(1)
from p01_stu
where sta_stu_cod=’X’
and stu_id in (select stu_id from p01_stu_ans) –variare i criteri di ricerca a piacimento
group by mot_stastu_cod
Come nel caso precedente, vi invito a sanare le situazioni inerenti chiusure di carriere fittizie; ad esempio, per uno studente chiuso per errata immatricolazione con motivo che non sia ERRIM, è necessario l’adeguamento del motivo:
update p01_stu set mot_stastu_cod=’ERRIM’ where stu_id= XXXX –indicare lo studente da sanare
STUDENTI CHE NON ENTRANO NEL POTENZIALE & “SCONGELAMENTO” DEL POTENZIALE
Dalla versione 6.01.05 sono state estese le utilità che intercettano le violazioni della base dati (DEPOSITO), con la possibilità di intercettare in chiaro studenti che non vengono mai inviati a causa di situazioni non conformi; questi record vengono parcheggiati nel DEPOSITO, nella nuova sezione DA POTENZIALE; si rammenta che queste situazioni sono rarissime, è sufficiente controllarle una volta per tutte ai prossimi rinvii totali delle schede 1 in 6.01.05, ovviamente dopo aver rinfrescato totalmente i potenziali di tutti gli anni accademici (di fatti non c’è più ragione di tenerli “congelati” come avevamo consigliato nello scorso bollettino, per il solo mese di Maggio).
Inoltre, a partire dalla versione 6.01.00, è presente un’utilità che intercetta quegli studenti che effettuano degli INGRESSI MULTIPLI in Ateneo, ossia trasferiti in uscita che ritornano oppure chi è stato un trasferito in ingresso più volte in Ateneo, logicamente sempre nell’ambito della medesima carriera. Si richiede da parte vostra una collaborazione nell’ambito di queste casistiche peculiari, nel caso in cui gli eventi di carriera corrispondenti non passino le fasi di controllo degli err ed err2. Non esitate a contattarci nel caso in cui abbiate situazioni del genere, anche “pasticciate” (come simpaticamente definite da alcune di voi).
TRE NOVITÀ: SPEDIZIONE INTERROTTA, VISUALIZZATORE DI SPEDIZIONI E CACHE
Dalla versione 6.01.05 dovrete acquisire familiarità con il concetto di SPEDIZIONE INTERROTTA. Nel caso in cui un’elaborazione non dovesse terminare per un qualsiasi motivo (“caduta” della connessione al jaguar server oppure chiusura brusca dell’applicazione), i record fino a quel momento elaborati verranno SALVATI sulla base dati (con stato ‘Z’), permettendo di riprendere l’elaborazione successivamente. Una spedizione interrotta è quindi una spedizione che non ha terminato la sua prima fase, quella dell’elaborazione.
Crediamo che l’utilità di questa nuova caratteristica sia evidente e sarà tanto più efficiente nel caso in cui le spedizioni contengano un numero minimo di record da riferirsi a lotti di 501 studenti per volta, come può accadere per una spedizione corposa come la scheda 6.
Sempre dalla versione 6.01.05, viene reso disponibile un VISUALIZZATORE DI SPEDIZIONI che permette, data una spedizione, di scorrere tutte le righe inviate, utilizzando la stessa logica di presentazione tabulare del SIMULATORE DI SPEDIZIONI: è attualmente disponibile per le schede 1,4, 3 e 6. La funzione è richiamabile, per riga, anche dalla maschera CARICAMENTO FILE DI RIEPILOGO MIUR; gradualmente sarà resa disponibile per tutte le spedizioni.
Inoltre, in 6.01.05 viene rilasciato un nuovo servizio, di natura squisitamente tecnica, per la memorizzazione di tutte le combinazioni possibili di informazioni tradotte con le codifiche delle tabelle ministeriali. Il fine è permettere un notevole alleggerimento dei calcoli per l’invio delle spedizioni. Per esempio, se N studenti sono nati in un determinato comune A, solo 1 volta verrà invocata la tabella ministeriale per inviare la codifica del dato comune ed il risultato verrà depositato in una CACHE (esplicitata da un nuovo tab del PANNELLO DI CONTROLLO); per i rimanenti N-1 studenti non sarà più necessario invocare la tabella ministeriale, eliminando di fatto quindi N-1 richiami funzionali di codifica; ma la bontà di questa implementazione non finisce qui, poiché quanto detto fin’ora avverrà soltanto per il primo invio in assoluto; dall’invio successivo, poiché la cache è stata popolata, la tabella ministeriale non verrà più interrogata. Dal nuovo tab sopra menzionato potrete svuotare la cache a piacimento o decidere per quanto tempo mantenerla. L’attuale versione utilizza la cache per le codifiche dei COMUNI; mano a mano estenderemo il tutto ad altre funzioni di calcolo; il tutto è riportato in chiaro nel tasto informativo “i” del nuovo tab apposito.
[NOTA TECNICA: la gestione della CACHE è stata superata e resa obsoleta dal restyling tecnico del 2012: non è quindi più attiva]
ITER DELLA GESTIONE DEI DEBITI FORMATIVI
Si rende necessario convenire di nuovo tutti assieme sulla gestione dei debiti formativi.
L’iter corretto prevede l’introduzione dei debiti sui settori, operazione sempre consentita dal tasto DEBITO/3+2 da Gestione Studenti tab LIBRETTO, a immatricolazione perfezionata. In seguito, a debito colmato, ci si aspetta che esista una qualche attività didattica SUPERATA, con il flag di debito alzato, che contenga tra i suoi segmenti il settore di debito, con flag di segmento di debito alzato a livello di segmento.
Questo è l’iter corretto della gestione dei DEBITI FORMATIVI, come ribadito fin dal 2005.
Per venire incontro alla mancata gestione della prima parte (censimento preventivo dei debiti), dalla versione 6.01.00 si è deciso di superare il vincolo che imponeva la specifica dei debiti in fase iniziale all’iscrizione al Corso Off. F. (che concretamente si traduceva nel popolamento della tabella P11_RIC_SPEC).
Nello specifico, nella scheda 3 ora si recuperano le informazioni di debito leggendo dal libretto estrapolando gli ambiti univoci e i settori di segmenti di debito. La sorgente dei debiti formativi è diventata la vista V11_STU_DEBITO, che potrete interrogare per molteplici motivi (ad esempio per controllare la presenza di debiti per un dato studente).
A partire dalla versione 6.01.00, si invita quindi ad un reinvio completo delle schede 3 e 6 per tutti gli anni accademici.
ATTENZIONE! Si rammenta fortemente che gestioni che non siano quelle proposte e che non passino quindi per una dichiarazione di debito (o su libretto o su funzione debito/libretto) non sono da noi incoraggiate in alcun modo.
BLOG ANS: NASCONO I SONDAGGI
Sempre in un’ottica di trasparenza e miglioria delle comunicazioni, è stato lanciato sul BLOG il primo sondaggio per accogliere I vostri pareri su determinati argomenti, nell’ambito del FORUM; l’argomento è le carriere multiple.
D.M.270: ANCORA NULLA DI NUOVO LATO OFF.F. e ANS
Alla data del 3 luglio 2008, gli schemi Off.F. e ANS per la 270 non sono ancora noti; formalmente, i primi immatricolati a corsi 270 andranno inviati a partire dal mese di Agosto. Torneremo sull’argomento quindi nel prossimo bollettino ANS, con le versioni di ESSE3 di riferimento. Si tenga presente che la versione 6.01.05 contiene comunque un iter completo di creazione corsi 270 e relativa attivazione, gestione ed immatricolazione di studenti; si rimanda alle note di rilascio e alla comunicazione tecnica relativa, rilasciate con la versione nel corso del mese, per tutti gli approfondimenti sul D.M.270 in ESSE3; affidatevi alla consultazione del Diario di Bordo per le novità in merito al 270 in OFF.F. & ANS.
Un saluto e a presto,
Christian Marcone