Analisi dell'applicazione Asset Securitization per la gestione delle funzionalit di riciclo e delle esecuzioni in parallelo.

autore: E. Romano

Premessa L'utente ha la possibilit di lanciare una scheda Asset per testare e raffinare i criteri o per modificare le date (taglio e contabile), principalmente la seconda. Questo permesso a patto che, attualmente ancora in fase di sviluppo, le schede Asset siano schedulate sequenzialmente e non parallelamente. L'esecuzione parallela porterebbe una scheda lancio ad interferire con schede lanciate precedentemente ma non ancora terminate, andando a ricoprire l'ultimo file civetta con le nuove informazioni. A livello web questa gestione non viene controllata, permettendo all'utente di lanciare tante Asset quante egli desidera. La funzionalit di riciclo invece dovrebbe consentire all'utente, dopo aver lanciato la stessa Asset con i diversi criteri scelti in catalogo prodotti, di poter scegliere quale di queste sia realmente utile ai propri fini per la selezione del taglio del portafoglio. Attualmente, seguire una logica di questo tipo comporta, l'esecuzione di tante Asset sequenzialmente e la scelta della migliore e pi consona estrazione ripetendo nuovamente la scheda gi eseguita, in quanto ogni procedura lavora soltanto con l'ultimo, in ordine temporale, dataset prodotto dal passo che lo precede. Riciclo Il riciclo consiste nella reiterazione di un livello di filtro pi volte in base alle modifiche dei valori dei criteri o delle date. Un programma controlla se l'esecuzione attuale contiene lo stesso codice Asset della precedente, tramite il file civetta. Se lo stesso siamo nel caso di un riciclo. La richiesta di esecuzione di una scheda Asset lato web comporta una scrittura di un rigo nelle tabelle FAM8TA03\4 in cui sono contenute informazioni tra le quali : codice scheda data riferimento data contabile progressivo revolving stato esito fasi inizio/fine timestamp di ultimo aggiornamento Nel caso di riciclo il codice revolving viene incrementato quando la Asset ha terminato correttamente il giro batch quindi l'esito ok e lo stato blank. Esempio:

BCO4

000 001 002

L0 L0 L0

L0 L0 L0

2010-04-30 2010-04-30 2010-04-30

2010-05-10 2010-05-20 2010-05-20 ELA

OK OK

Alla prima esecuzione il web scrive il primo rigo in tabella. La procedura termina correttamente e viene valorizzato il campo Esito. Il FAM4BS41 aggiunge un nuovo rigo incrementando il codice revolving. Se siamo in riciclo la seconda esecuzione dell'asset avverr a partire dal progressivo 001, ipotizzando che l'utente aggiorni la data contabile e richieda una nuova esecuzione. Lo stato dell'operazione diventa ELA e l'esito Blank. Quando la procedura terminer correttamente, verr nuovamente scritto un nuovo rigo con codice incrementato, stato Blank ed Esito ok e cos via si avr uno storico delle esecuzioni. Le funzionalit di riciclo sono legate al progressivo revolving. Questo codice numerico di tre cifre che indica quante volte stata eseguita una scheda Asset. Ad ogni progressivo associata una specifica estrazione e quindi diversi file prodotti dalla stessa. In linea di massima ad ogni progressivo corrisponde un loan by loan parziale diverso. Per gestire correttamente la fase di riciclo occorre specificare nel nome di ciascun dataset il codice asset e il numero revolving. Queste informazioni sono sufficienti a individuare all'interno di una stessa Asset quale estrazione l'utente preferisca. Per esempio, a livello zero avremo tanti dataset prodotti per la Asset OBG4 con i finanziamenti estratti da diverse estrazioni corrispondenti a criteri di selezione diversa: C0.NAS.GX.********.L0.BCO4.000 C0.NAS.GX.********.L0.BCO4.001 C0.NAS.GX.********.L0.BCO4.002 ... oppure per una diversa OBG: C0.NAS.GX.********.L0.BCO5.000 C0.NAS.GX.********.L0.COR6.002 ... Il riciclo permette di lavorare sempre su una estrazione ben precisa senza dover rieseguire una Asset precedente. Il flusso procedurale ripartirebbe a livello uno dai dataset prodotti dal revolving selezionato. Esecuzione Parallela Distinguo l'esecuzione di una stessa Asset pi volte e l'esecuzione di Asset diverse contemporaneamente. La prima ipotesi ancora non fattibile a meno di eseguire la stessa Asset con data di riferimento o data contabili diverse. I criteri selezionati in catalogo prodotti sono univoci e statici. La loro modifica durante l'esecuzione di diverse Asset con lo stesso codice comporterebbe la perdita dei criteri della scheda precedente, poich ogni Asset collegata a determinate varianti commerciali. Se viene cambiata la data di riferimento ed maggiore strettamente di quella dell'estrazione

precedente, deve essere rifatto lo scarico dalla FIN0ST01, altrimenti si pu lavorare sullo scarico precedente. Per ovviare a questo inconveniente si dovrebbe agganciare il codice revolving di una scheda Asset con il codice revolving di una variante commerciale nel catalogo prodotti. In tal modo avremmo la garanzia che ogni variante commerciale con revolving diversi conterrebbero i valori scelti per ogni diversa estrazione in riferimento alla stessa OBG. Il revolving permetterebbe di unire le informazioni di una stessa scheda Asset con i diversi criteri selezionati nelle stesse varianti commerciali. Con un codice revolving all'interno del catalogo prodotti potremmo risalire ai criteri scelti per produrre quel particolare taglio. Senza di ci questo sarebbe impossibile a patto che l'estrazione scelta sia l'ultima eseguita. Un'altra maniera pi semplice sarebbe clonare le varianti commerciali e aggangiarle al precedente codice Asset per non perdere lo storico dei valori creati. La seconda ipotesi, invece, possibile tramite l'uso delle nomenclature per i file guida ipotizzate nel paragrafo precedente. Infatti, ogni file civetta nel proprio nome conterr l'informazione riguardo il codice Asset al quale esso appartiene. Questo consentir di lanciare in parallelo flussi procedurali provenienti da file guida diversi.