BNL Process Design Document 0007 - Pignoramenti PDF

Process Design Document 0007 - Pignoramenti Process Design Document - Pignoramenti 1 Classification : Internal Controllo versioni Versione Owner Descrizione d...

Process Design Document 0007 - Pignoramenti Process Design Document - Pignoramenti 1 Classification : Internal Controllo versioni Versione Owner Descrizione della versione Data Rifacimento totale del documento di analisi 1.0 EY 16/01/2022 funzionale 2.0 EY Aggiornamento documento per rilascio Sprint 2 12/06/2023 Modificati criteri per classificazione clienti/non 3.0 RPA Team 20/10/2023 clienti Process Design Document - Pignoramenti 2 Classification : Internal Sommario 1 Introduzione................................................................................................................................... 4 1.1 Scopo del documento........................................................................................................... 4 2 Overview di processo.................................................................................................................... 5 2.1 Descrizione generale del processo pre-automatizzazione................................................... 5 2.1.1 Caso NON Cliente......................................................................................................... 5 2.1.2 Caso Cliente................................................................................................................... 5 2.2 Descrizione generale del processo automatizzato............................................................... 6 2.2.1 Caso NON Cliente......................................................................................................... 6 2.2.2 Caso Cliente................................................................................................................... 6 2.3 Applicazioni coinvolte............................................................................................................ 6 3 High-level process overview......................................................................................................... 8 3.1 Stati principali del processo.................................................................................................. 8 3.2 Flusso di processo – Dettaglio procedure.......................................................................... 11 3.2.1 Scarico, lavorazione e chiusura ticket......................................................................... 11 3.2.2 Caricamento Atto (canale cartaceo)............................................................................ 18 3.2.3 Verifica scansione atto (stato Unità Standardizzazione)............................................. 18 3.2.4 Eccezione verifica Atto................................................................................................. 24 3.2.5 Recupero informazioni creditori/avvocati.................................................................... 26 3.2.6 Classificazione Clienti / Non Clienti............................................................................. 29 3.2.7 Valutazione Pignoramento e verifica dati per Creazione Dichiarazione di terzo pignorato31 3.2.8 Recupero Data Impegno.............................................................................................. 36 3.2.9 Inserimento terzo pignorato......................................................................................... 38 3.2.10 Invio mail gestore......................................................................................................... 52 3.2.11 Inserimento nota evento.............................................................................................. 53 3.2.12 Creazione dichiarazione di terzo pignorato................................................................. 57 3.2.13 Invio PEC..................................................................................................................... 52 4 Allegati......................................................................................................................................... 64 5 Eccezioni..................................................................................................................................... 66 5.1 Business Exception............................................................................................................. 66 Process Design Document - Pignoramenti 3 Classification : Internal 1 Introduzione 1.1 Scopo del documento L’obiettivo di questa analisi funzionale è documentare l’attuale procedura di esecuzione dei Pignoramenti e descrivere il processo automatizzato a seguito dell’introduzione di una soluzione di Robotic Process Automation (di seguito RPA). Il processo di gestione dei Pignoramenti prevede la lavorazione degli atti di pignoramento indirizzati a BNL in qualità di terzo pignorato. Nel documento saranno espressi: Il processo com’era prima degli interventi di automatizzazione Il processo automatizzato così come si presenta attualmente, con le attività svolte dal Robot e quelle che resteranno in capo all’operatore UP I sistemi/applicazioni coinvolti Le specifiche funzionali Process Design Document - Pignoramenti 4 Classification : Internal 2 Overview di processo 2.1 Descrizione generale del processo pre-automatizzazione Il robot scarica da Aurelia (Helpy) la coda di lavoro che consiste in un excel opportunamente filtrato e che deve contenere 3 informazioni base per avviare il processo (CF_P_Iva debitore, Stato=”Assegnato”, CategoriaLivello3 = “NOTIFICA ATTO”). L’excel verrà rielaborato eliminando alcune colonne non utili al processo di automatizzazione e aggiungendo altre colonne. Alcune colonne saranno compilate dal robot in automatico, altre dovranno essere compilate dall’addetto UP in fasi successive per consentire al robot di procedere in automatico con la lavorazione. Per ogni ticket il robot scarica gli allegati presenti, crea in una cartella condivisa una sottocartella con la seguente nomenclatura: aaaa-mm-gg_ ed inserisce nel campo “Link” il/i link al/agli allegato/i. Il robot verifica nell’excel la presenza del/dei link agli allegati. In caso di campo vuoto, compila il campo “Allegati” con il valore “Assenti” e chiude il ticket in Aurelia. Per ogni riga dell’excel (corrispondente ad un ticket), l’addetto UP valuta la completezza degli allegati, compila di conseguenza il campo “Allegati” (Completi, Incompleti) e chiude opportunamente il ticket in Aurelia. Il robot effettua la ricerca del debitore attraverso CF/P.IVA e definisce se il debitore è o meno un cliente BNL. 2.1.1 Caso NON Cliente L’addetto UP inserisce nell’excel a supporto del robot altre informazioni che consentono l’automatizzazione della fase di generazione della dichiarazione non cliente e invio/stampa delle PEC e relative ricevute a seguito dell’apposizione della firma digitale da parte del firmatario designato. 2.1.2 Caso Cliente Il robot produce tutte le inquiry necessarie alla valutazione della pratica e le salva nella sottocartella condivisa precedentemente creata. L’addetto UP visiona le inquiry prodotte e valuta il pignoramento (Positivo, Parzialmente Positivo, Negativo) definendo l’importo da impegnare e il relativo conto (può indicare più conti e più cifre); inserisce queste informazioni nell’excel a supporto del robot. Il robot prende l’impegno sul conto ed eventualmente appone il blocco (caso PP o N). L’addetto UP inserisce nel db a supporto del robot una serie di informazioni utili alle successive fasi di automatizzazione. Il robot effettua l’inserimento della pratica in Terzo Pignorato, genera la dichiarazione di terzo pignorato, inserisce l’evento di pignoramento in Anagrafe e invia/stampa le PEC e relative ricevute a seguito dell’apposizione della firma digitale da parte del firmatario designato. In caso di ordinanza di assegnazione (pervenuta a mezzo PEC o in cartaceo), l’addetto UP compila una macro excel per l’assegnazione delle somme ai vari creditori e salva il file nella cartella di lavorazione della pratica. Il robot apre il file, estrapola i dati utili e varia la pratica in terzo pignorato per assegnare le somme. La pratica viene così messa alla valutazione finale del responsabile. In caso di estinzione/rinuncia, l’addetto UP legge la richiesta (pervenuta a mezzo PEC o in cartaceo) e la valuta. In caso negativo invia comunicazione a mezzo PEC. In caso positivo il robot estingue il pignoramento in terzo pignorato. Process Design Document - Pignoramenti 5 Classification : Internal Il robot rimuove la nota evento di pignoramento. L’addetto UP in ultima analisi rimuove eventuali blocchi relativi al pignoramento estinto. 2.2 Descrizione generale del processo automatizzato Il robot scarica da Aurelia (Helpy) la coda di lavoro che consiste in un excel opportunamente filtrato e che deve contenere informazioni base per avviare il processo (CF_P_Iva debitore , TicketID, Stato=”Assegnato”, CategoriaLivello3 = “NOTIFICA ATTO”). I dati contenuti all’interno del file excel scaricato da Aurelia, con l’esclusione di alcune colonne non utili al processo di automatizzazione, verranno salvati sul DB che costituirà la base di tutta la lavorazione e saranno visibili dal front-end Appian. Alcune colonne della tabella DB inizialmente non saranno compilate con i soli dati provenienti dal file di input e verranno compilate dal robot durante la lavorazione oppure dall’addetto UP in fasi successive. Per ognuno dei ticket presenti all’interno del file excel, il robot scarica gli allegati presenti e li mette a disposizione dell’addetto UP sulla Fileboard. Il robot verifica la presenza del/dei link agli allegati. In caso di loro assenza, compila il campo “Allegati” con il valore “Assenti” e chiude il ticket in Aurelia. Per ogni item da lavorare (corrispondente ad un ticket), l’addetto UP valuta la completezza degli allegati e compila di conseguenza il campo “Allegati” (Completi, Non di competenza, Non standard). Il robot verifica il contenuto del campo “Allegati” e, in base al suo contenuto, inserisce il messaggio opportuno nel campo “Risoluzione” in Aurelia, procedendo poi alla chiusura del ticket. L’addetto UP inserisce alcune informazioni a supporto delle successive automatizzazioni. Appian effettua la ricerca del debitore su Anagrafe attraverso il CF/P.IVA e definisce se il debitore è o meno un cliente BNL. 2.2.1 Caso NON Cliente L’addetto UP inserisce da front-end Appian alcune informazioni che consentono l’automatizzazione delle successive fasi di generazione della dichiarazione non cliente e invio/stampa delle PEC e relative ricevute a seguito dell’apposizione della firma digitale da parte del firmatario designato. 2.2.2 Caso Cliente L’addetto UP effettua le inquiry e valuta il pignoramento (Positivo, Parzialmente Positivo, Negativo) definendo l’importo da impegnare e il relativo conto (l’addetto UP può indicare più conti e più cifre); una volta definite queste informazioni, l’addetto le inserisce nel front-end Appian. L’addetto UP prende l’impegno sul conto ed eventualmente appone il blocco (caso PP o N) e successivamente invia la mail al gestore della relazione per notificare esito del pignoramento ed eventuali impegni e blocchi. L’addetto UP effettua l’inserimento della pratica in Terzo Pignorato e l’evento di Pignoramento in Anagrafe. Il robot genera la dichiarazione di terzo pignorato da template Word e la mette a disposizione in Appian all’utente per la firma. Successivamente, il robot recupera la Dichiarazione firmata e la invia tramite PEC. 2.3 Applicazioni coinvolte Vengono di seguito elencate le applicazioni ed i tool coinvolti nel processo sia ad uso umano che dell’automa. Process Design Document - Pignoramenti 6 Classification : Internal  Nome applicativo Descrizione tipo AURELIA Scarico, lavorazione, chiusura ticket Recupero dati debitore, lista accordi, inserimento nota Anagrafe (JFWEB) evento Excel File di supporto al robot Word File di supporto al robot Outlook Invio mail Process Design Document - Pignoramenti 7 Classification : Internal 3 High-level process overview 3.1 Stati principali del processo Di seguito un’overview del processo automatizzato: Process Design Document - Pignoramenti 8 Classification : Internal  ID Descrizione operazioni 1.1 Il robot scarica da Aurelia (Helpy) il file excel che contiene le informazioni necessarie per avviare la lavorazione (CF_P_Iva debitore, TicketID, Stato=”Assegnato”, CategoriaLivello3 = “NOTIFICA ATTO”) e che sarà la base della coda di lavorazione. Il robot rielabora l’excel eliminando alcune colonne non utili al processo di automatizzazione e carica i dati contenuti all’interno del file nella tabella DB che fungerà da base dati per il front-end Appian. Per ogni ticket il robot scarica gli allegati presenti e li mette a disposizione degli utenti in Appian. 1.2 Il robot verifica per ognuno dei record provenienti dal file excel scaricato da Aurelia la presenza dei dati base necessari per la lavorazione e in caso di esito negativo della verifica, segnala l’eccezione a front-end Appian e procede alla lavorazione successiva. 1.3 Italarchivi/ ACN (Unità di Standardizzazione) crea in Appian i record relativi alle pratiche di Pignoramento di cui è presente un Atto,pervenuto tramite canale diverso dal Ticket, quindi carica l’atto in formato.pdf in Appian 1.4 Italarchivi (Unità di Standardizzazione) prende in carico l’atto, verifica la completezza degli allegati ed inserisce a front-end Appian nel campo “Esito verifica Allegati” l’esito della sua verifica. Appian verifica in tempo reale tramite i campi CF / PIVA debitore valorizzati se sono presenti nella tabella a DB relativa agli Enti Pubblici, e in caso positivo aggiorna il campo “Enti Pubblici” a DB. Italarchivi arricchisce i dati della pratica proposti dal sistema. 1.5 Il robot inserisce nel campo “Risoluzione” (in Aurelia) il messaggio previsto in caso di allegati assenti o incompleti e chiude il ticket, procedendo alla lavorazione successiva. 1.6 In caso di valore del campo “Esito verifica Allegati” pari a “Completi”, il robot inserisce nel campo “Risoluzione” (in Aurelia) il messaggio previsto in caso di allegati completi e chiude il ticket. 1.9 Appian effettua la classificazione in cliente o non cliente mentre l’addetto UP accede alla pratica. L’addetto UP visualizza tramite Appian la classificazione in cliente o non cliente 1.10 Se il debitore non è un cliente BNL, l’addetto UP verifica i dati a front-end Appian necessari alla predisposizione della Dichiarazione di terzo Pignorato ed effettua le eventuali modifiche/ integrazioni. 1.11 Il robot procede con la generazione della dichiarazione non cliente 1.13 Se il debitore è cliente BNL, l’addetto UP interroga i sistemi per raccogliere le informazioni necessarie a verificare la disponibilità del debitore. 1.14 L’addetto UP valuta le informazioni raccolte per verificare la disponibilità del debitore e inserisce nel front-end Appian le informazioni relative all’esito del pignoramento ed eventuale/i impegno/i da prendere sul conto/i. Inoltre, l’addetto verifica i dati a front-end Appian, necessari alla predisposizione della Dichiarazione di terzo Pignorato ed effettua le eventuali modifiche/ integrazioni. 1.15 L’addetto UP inserisce l’impegno sul/sui conto/i del debitore in funzione dell’esito del Pignoramento 1.16 Se la valutazione è parzialmente positiva o negativa, l’addetto UP inserisce il blocco sul/sui conto/i del debitore 1.17 L’addetto UP inserisce la pratica in Terzo Pignorato. 1.18 L’addetto UP invia l’email del pignoramento al gestore della relazione. 1.19 L’addetto UP inserisce in Anagrafe Web la nota relativa all’evento di pignoramento Process Design Document - Pignoramenti 9 Classification : Internal  1.20 Il robot genera la dichiarazione di terzo pignorato e le copertine delle pratiche e le salva in Appian in attesa della firma. 1.21 Il firmatario scarica la Dichiarazione da Appian e appone la firma digitale sulla dichiarazione, quindi carica in Appian la dichiarazione firmata per l’invio della PEC. 1.22 Il robot invia le dichiarazioni firmate via PEC e salva le ricevute dell’invio tramite PEC mettendole a disposizione dell’addetto UP in Appian. Process Design Document - Pignoramenti 10 Classification : Internal  3.2 Flusso di processo – Dettaglio procedure 3.2.1 Scarico, lavorazione e chiusura ticket I ticket recuperati verranno processati dal robot nella giornata di esecuzione e passeranno allo stato successivo del processo (Verifica scansione Atto) dove verranno lavorati dall’Unità di Standardizzazione. 3.2.1.1 Scarico lista ticket Excel e caricamento item in coda Di seguito le logiche e gli step operativi per l’accesso, scarico della lista ticket Excel e caricamento dell’item nella coda di lavorazione del robot. Il robot si collega al sistema Aurelia ed inserisce le credenziali di accesso. Clicca Accedi. Viene mostrata la schermata “IT HOME” Process Design Document - Pignoramenti 11 Classification : Internal Clicca su “Applicazioni → Gestione ticket Commerciale → Console Ticket Commerciale Viene mostrato l’elenco di tutti i ticket aperti precedentemente in Helpy in ordine crescente di data. Cliccando su “estrazione dati” è possibile produrre un excel che contiente le informazioni di tutti i ticket. Nel capitolo 4 Allegati è possibile vedere un esempio di estrazione excel (ID 1). Process Design Document - Pignoramenti 12 Classification : Internal Il robot verifica per ogni item (riga dell’excel) che i seguenti campi siano compilati: Ticket ID Stato CategoriaLivello3 Se uno o più non lo fossero, genera una eccezione, che sarà visibile all’addetto UP tramite front-end Appian, e passa all’item successivo. In caso di item con dati completi, alcune colonne dell’excel verranno trascurate: Data Risoluzione Data Chiusura Cliente Servizio CategoriaLivello1 CategoriaLivello2 Note Gruppo Assegnatario Assegnatario Priorità Origine Segnalazione Data prima Assegnazione Data prima presa in Carico Data ultima presa in Carico Unità Organizzativa Tipo Ticket Creatore Risoluzione Le restanti colonne del file verranno utilizzate per popolare la tabella DB che fungerà da base dati per il robot e il front-end Appian; rispetto alle colonne presenti all’interno del file nella tabella DB saranno presenti ulteriori colonne che dovranno essere compilate nelle fasi successive dall’addetto UP e/o dal robot. Process Design Document - Pignoramenti 13 Classification : Internal Il robot procederà con la presa in carico delle pratiche con campo “Stato” = “Assegnato” e campo “CategoriaLivello3” uguale a “NOTIFICA ATTO”. Il robot procederà a recuperare gli item da lavorare per il caricamento all’interno della coda di lavorazione effettuando una query SQL sulla tabella DB. 3.2.1.2 Download e chiusura ticket Il robot effettua la login su Aurelia, raggiunge la schermata di Console Ticket commerciale con le stesse modalità descritte nel paragrafo precedente. A questo punto cerca il ticket attraverso il campo “Ticket ID” ed entra nel dettaglio del ticket. Nella pagina di dettaglio del ticket verifica la presenza di voci di dettaglio e, se ne trova, verifica per ognuna quanti allegati sono presenti. Per ogni voce di dettaglio su singolo ticket possono essere presenti da 0 a 3 allegati, in seguito li scarica rendendoli disponibili agli addetti tramite Fileboard. In caso di assenza allegati, compila il campo “Allegati” con il valore “Assenti” e il campo “Stato” con il valore “Risolto”. Se il robot ritrova almeno un allegato, l’addetto UP dovrà effettuare gli step descritti nel paragrafo 3.2.3 Verifica Scansione Atto. Se non vengono trovate voci di dettaglio si prosegue con la risoluzione del ticket. Se il campo “Stato” contiene il valore “In corso”, seleziona tale valore nel menu a tendina “Stato” presente nella schermata di dettaglio ticket e clicca sul pulsante “Salva”. Process Design Document - Pignoramenti 14 Classification : Internal Se il campo “Stato” contiene il valore “Risolto”, il robot compila il campo “Risoluzione” a seconda del contenuto del campo “Esito verifica Allegati”: Valore “Assenti” → il robot inserisce il testo presente nel file ‘Notifica atto- ticket privo di allegato’ presente nel paragrafo 4 Allegati e memorizzerà la relativa eccezione (ID2). Valore “Non Standard” o “Non di competenza” → il robot inserisce il testo presente nel file ‘Notifica atto- ticket allegato incompleto’ presente nel paragrafo 4 Allegati e memorizzerà la relativa eccezione (ID3). Valore “Completi” → il robot inserirà il testo presente nel file ‘Notifica atto-Invia di ricezione’ presente nel paragrafo 4 Allegati (ID4). Process Design Document - Pignoramenti 15 Classification : Internal Il robot seleziona “Risolto” nel menu a tendina “Stato” presente nella schermata di dettaglio ticket e clicca su “Salva”. A questo punto apparirà un’altra schermata nella quale il robot cliccherà sul pulsante “Salva”. Process Design Document - Pignoramenti 16 Classification : Internal Il robot procede con la chiusura del ticket selezionando nel menu a tendina “Stato” la voce “Chiuso” e cliccando su “Salva”. Process Design Document - Pignoramenti 17 Classification : Internal  3.2.2 Caricamento Atto (canale cartaceo) L’addetto ACN o Italarchivi accede ad Appian per il caricamento dell’atto e degli altri documenti ricevuti via posta fisica. Dall’interfaccia di Cruscotto, cliccando sul pulsante “Nuovo Inserimento” l’utente carica nel Front – End Appian gli atti dematerializzati in formato pdf e inserisce il nome e cognome del debitore. Appian salverà in automatico il file rinominandolo con l’aggiunta del prefisso “ATTO N.A.” 3.2.3 Verifica scansione atto (stato Unità Standardizzazione) Gli item provenienti dall’estrazione dei Ticket Aurelia e dal canale cartaceo saranno a disposizione dell’Unità di Standardizzazione nel Cruscotto di Appian con lo stato “Da verificare Scansione atto”. Nel “Cruscotto” sono presenti i seguenti campi: Stato Documenti* Ticket ID Note CF/P.IVA Cognome Nome Debitore Cognome Nome Creditore Numero Pratica Data Notifica Data Udienza Importo PPT Tribunale Cognome Nome Avvocato Process Design Document - Pignoramenti 18 Classification : Internal  Causa Riferimento Data Caricamento Class. Cliente Cronologico Unep Ente Pubblico ID Stato Ticket Stato Allegati Priorità Data Modifica Autore Modifica Dettaglio Eccezione Flag Cartaceo (*) questo campo consente di implementare la gestione documentale cliccando apposito pulsante, consentendo di caricare le seguenti tipologie di documenti: Atto, Documentazione cliente/non cliente, Dichiarazione firmata, Lista ticket Aurelia, Altro, Rinunce/Estinzioni, Pagamenti. Come mostrato di seguito. Il “Cruscotto” è filtrabile utilizzando i rispettivi campi filtro: Stato Ticket ID Note CF e P.Iva Debitore Cognome Nome Debitore Numero Pratica Causa di riferimento Importo PPT Autore ultima modifica Documento cartaceo* Cronologico UNEP Enti Pubblici Data Notifica Data Udienza Data modifica Data caricamento Process Design Document - Pignoramenti 19 Classification : Internal (*) questo campo ha la funzione di tracciare le pratiche che derivano da documenti cartacei scansionati e non ha altre finalità che modificano l’operatività di processo. Dovrà essere editabile e visualizzabile in ogni stato, non sarà obbligatorio e conterrà esclusivamente i valori “SI” o “NO”. Il flag deve essere reso valorizzabile direttamente dall’item “prima di accedere alla singola pratica in modifica”, prevedendo possibilmente una Invia all’atto della valorizzazione (es. pop-up). L’utente cliccando sui singoli record nella tabella del Cruscotto accede al dettaglio della pratica (cd. riepilogo) e tramite il pulsante “Verifica Atto” accede all’interfaccia che segue per l’arricchimento dei dati. Nello specifico l’addetto può scaricare e aprire l’allegato (o gli allegati) per verificare la completezza e la presenza dei dati necessari per il successivo censimento e data entry. Una volta effettuata la verifica, l’utente inserisce l’esito nel campo “Esito verifica Allegati”. I possibili valori sono: Completo, se gli allegati e le parti essenziali sono presenti; Non di Competenza, se il ticket non è di competenza dell’APAC Pignoramenti; Non standard, se il CF/ P. IVA del debitore è mancante. ID Obbligatorio Regole di compilazione e Nome campo Note campo SI/NO data validation CF: 16 caratteri alfanumerici P.IVA: 11 caratteri solo C.F./ P.IVA numerici 1 DEBITORE SI In caso il CF/P.IVA inserito non sia corretto, dovrà comparire il seguente messaggio di errore: Process Design Document - Pignoramenti 20 Classification : Internal  “Valore inserito non corretto. Si prega di inserire un valore corretto.” Checkbox compilato in ENTE automatico da Appian in caso 2 NO PUBBLICO presenza del CF/P.IVA nel DB Enti Pubblici Menù a tendina con le opzioni: ESITO Completo 3 VERIFICA SI Non di ALLEGATI competenza Non standard Note esito Visibile se “Esito 4 verifica SI verifica allegati” allegati “Completo” Una volta inserito il CF/ P.IVA del debitore il sistema verificherà in automatico se il debitore è un Ente Pubblico confrontando CF/P.IVA con i valori presenti nella tabella a DB. Ente Pubblico Se il controllo automatico, trova il CF/ P.IVA del debitore nella tabella degli Enti Pubblici, si valorizza il checkbox “Ente Pubblico” (della tabella precedente) e l’addetto procederà alla compilazione dei seguenti campi: ID Obbligatorio Regole di compilazione e data Nome campo Note campo SI/NO validation 3 NOME DEBITORE SI - CAUSA DI 4 SI - RIFERIMENTO Formato data (gg/mm/aaaa) 5 DATA UDIENZA SI Non è possibile inserire caratteri speciali Data validation: solo valori numerici, 6 IMPORTO PPT SI fino al secondo decimale Formato data (gg/mm/aaaa) 7 DATA NOTIFICA SI Non è possibile inserire caratteri speciali L’utente compilerà inoltre la tabella dei Creditori che segue, cliccando su “Aggiungi Creditore” per aggiungere nuovi creditori: COGNOME E NOME 8 NO No data validation CREDITORE Se il campo CF: 16 caratteri alfanumerici non è P.IVA: 11 caratteri solo compilato è 9 C.F. / P.IVA SI numerici necessario compilare il campo Process Design Document - Pignoramenti 21 Classification : Internal  “Motivazione CF/ P.IVA vuoto” Data validation: solo 10 CODICE CREDITORE NO - valori numerici, massimo 7 caratteri Il campo è un menù a tendina con SI (*solo in due opzioni: Motivazione CF/P.IVA caso di blank 11 Creditore vuoto dell’ID11 + assente, ID12). CF/PIVA assente o errato Il campo è un 12 PERSONA FISICA NO Sì /No Data validation: menu a tendina con: società di capitali (il robot Il campo è un deve censire in uq come menù a P.G. “SI” da considerare tendina con le negli altri campi ragione opzioni: 13 RAGIONE SOCIALE NO sociale 2 e 3) Società di società di persone e altre capitali, tipologie (il robot deve società di censire in uq come P.G. persone e altre “NO” da considerare negli tipologie altri campi ragione sociale 2 e 3) Dopo aver inserito tutte le informazioni previste, l’utente procede cliccando sul pulsante “Invia” e l’item andrà all’APAC Enti Pubblici per la lavorazione con lo stato “Enti Pubblici”. Debitore Non Ente Pubblico In tutti i casi in cui il Debitore non è un Ente Pubblico, l’utente procede alla compilazione dei seguenti campi: 14 NOME DEBITORE SI - 15 TRIBUNALE SI Data validation: solo valori alfabetici (no numeri) CAUSA DI 16 SI - RIFERIMENTO 17 DATA UDIENZA SI Formato data (gg/mm/aaaa) Data validation: solo valori numerici, fino al secondo 18 IMPORTO PPT SI decimale 19 DATA NOTIFICA SI Formato data (gg/mm/aaaa). 20 COMMISSIONI SI Data validation: solo valori numerici, senza decimali Process Design Document - Pignoramenti 22 Classification : Internal  21 CRONOLOGICO UNEP SI Data validation: solo valori numerici, senza decimali L’utente compilerà inoltre la tabella dei Creditori che segue, cliccando su “Aggiungi Creditore” per aggiungere nuovi creditori: COGNOME E NOME 22 NO No data validation CREDITORE Se il campo non è CF: 16 caratteri alfanumerici compilato è necessario P.IVA: 11 caratteri solo 23 C.F. / P.IVA SI compilare il numerici campo “Motivazione CF/ P.IVA vuoto” Data validation: solo 24 CODICE CREDITORE NO - valori numerici, massimo 7 caratteri Il campo è un menù a SI (*se tendina con CF/PIVA o due opzioni: Motivazione CF/P.IVA 25 codice Creditore vuoto creditore assente, sono vuoti) CF/PIVA assente o errato Il campo è un 26 PERSONA FISICA NO Sì /No Data validation: menu a tendina con: società di capitali (il robot Il campo è un deve censire in uq come menù a P.G. “SI” da considerare tendina con le negli altri campi ragione opzioni: 27 RAGIONE SOCIALE NO sociale 2 e 3) Società di società di persone e altre capitali, tipologie (il robot deve società di censire in uq come P.G. persone e altre “NO” da considerare negli tipologie altri campi ragione sociale 2 e 3) Process Design Document - Pignoramenti 23 Classification : Internal L’utente compilerà inoltre la tabella degli Avvocati che segue, cliccando su “Aggiungi Avvocato” per aggiungere nuovi avvocati: COGNOME E 28 NO No data validation NOME Nel campo PEC deve essere sempre presente il carattere “@” (1 soltanto). Non devono essere ammesse le parole “gmail” o “virgilio” o i caratteri “,” “;” “/”. Inoltre, se nell’indirizzo email inserito nel campo PEC 29 SI NON sono presenti le parole CERT, PEC, AVVOCATO LEGALMAIL, GIUFFRE, PECAVVOCATI, allora al momento della Invia finale di tutti i campi compilati, apparirà un pop-up contenente il seguente messaggio: “Inviare che gli indirizzi email degli avvocati siano indirizzi PEC” ed il tasto INVIA. C.F. / P.IVA Replicare regole di data validation del campo C/F 30 SI AVVOCATO P.IVA DEBITORE (ID1). SI (*solo nel caso in cui il campo CODICE Data validation: solo valori numerici, massimo 7 31 CF/P.IVA sia blank, AVVOCATO caratteri altrimenti non obbligatorio) Infine, l’utente dovrà indicare l’oggetto del Pignoramento nei seguenti campi Checkbox: Pignoramento Titoli Pignoramento Cassette di Sicurezza Al termine del data entry, l’utente seleziona “Invia”. Dopo il salvataggio, la pratica avanza nello step successivo, dove il robot procede con la chiusura del ticket su Aurelia inserendo lo stato “Chiuso”. Per le pratiche con “Esito verifica Allegati” valorizzato con “Non di competenza” o “Non standard”, la pratica avanza nello step successivo in carico all’UP Pignoramenti “Eccezione Verifica atto” (cfr. paragrafo 3.2.4 Eccezione Verifica Atto) 3.2.4 Eccezione verifica Atto L’addetto UP verifica la pratica e raccoglie le informazioni necessarie per completare l’arricchimento dei dati. Nello specifico, l’utente tramite l’interfaccia di Appian ha la possibilità di: Caricare documenti; Modificare il campo “Esito verifica Allegati”; Indicare se far procedere Italarchivi con il completamento della compilazione dei dati; Compilare la checkbox per indicare eventuali errori da parte di Italarchivi (la compilazione della checkbox potrà essere effettuata dall’utente anche in ognuna delle altre fasi della lavorazione ed avrà unicamente scopo informativo, senza determinare differenze nella lavorazione dell’item); Compilare i campi previsti nello step “Da verificare scansione atto” in carico ad Italarchivi. Process Design Document - Pignoramenti 24 Classification : Internal Nel caso in cui il campo “Esito verifica Allegati” sia stato modificato in “Completi” e l’addetto abbia anche compilato tutti i dati, la pratica procede nello step del robot per la chiusura del ticket (se canale ticket) o per il recupero delle informazioni di credito e avvocati (se canale cartaceo). Qualora invece il campo “Esito verifica Allegati” sia stato modificato in “Completi”, ma l’utente abbia indicato il completamento della compilazione dei campi in carico ad Italarchivi, il processo prosegue come descritto nel paragrafo 3.2.3 Verifica Scansione Atto. Infine, se il campo “Esito verifica Allegati” è confermato “Non di competenza” o “Non standard”, il robot procede alla chiusura del ticket (se canale ticket) e lo stato della pratica in Appian termina in “Completato” (canale ticket e canale cartaceo). Process Design Document - Pignoramenti 25 Classification : Internal  3.2.5 Recupero informazioni creditori/avvocati Nell’applicativo CICS - Terzo Pignorato, il robot procede con le inquiry sui creditori forniti dall’U.S. nello stato di Verifica Scansione Atto, fino ad un massimo di 3 creditori e 3 avvocati. Qui recupera tutte le informazioni relative al creditore/avvocato (che verranno inserite nella tabella del DB): Accede a TERZO PIGNORATO UQOPERAT → ANAGRAFE Accede a INQUIRY, inserendo il numero relativo alla voce INQUIRY nel campo “Scelta” e il codice “1900” nel campo “Dati”: Process Design Document - Pignoramenti 26 Classification : Internal Inserisce il CODICE FISCALE e premere INVIO (Se il codice creditore è stato inserito in Appian dall’U.S. nello stato di VERIFICA SCANSIONE ATTO, allora il robot inserirà tale codice nel campo CODICE IDENTIFICATIVO DEL CREDITORE): Se per un codice fiscale risultano censiti due creditori/avvocati, il robot interrompe la ricerca, inserisce nelle note il seguente testo: “RETRY BSNS: Sono stati trovati risultati multipli per CF/PIVA su Terzo Pignorato” permettendo agli utenti di rimandare indietro la pratica alla fase di verifica scansione atto nella quale dovrà essere indicato lo specifico codice creditore da ricercare. Sulla schermata di atterraggio, se creditore/avvocato censito, recupera il codice IDENTIFICATIVO: Process Design Document - Pignoramenti 27 Classification : Internal In questa schermata, il robot recupera anche tutte le seguenti informazioni: Nome Cognome Codice Creditore Codice Fiscale/PIVA Indirizzo Loc. Residenza C.A.P. Provincia Sesso Data di nascita Loc. di nascita Persona Fisica Ragione sociale Se creditore/avvocato non censito, non sarà presente nell’applicativo il codice identificativo e comparirà la dicitura “Codice Fiscale Inesistente”: Process Design Document - Pignoramenti 28 Classification : Internal Ovviamente in questo caso il robot non può recuperare alcuna informazione, e sarà a cura dell’operatore APAC inserire le informazioni mancanti nel front-end Appian. Per quanto riguarda il front-end Appian vi è la funzionalità, attraverso specifico pulsante ‘Risottometti Pratica’, per gli item che presentano stato bot “Eccezione” e step “Recupero info creditori” di mandare indietro una pratica allo stato bot “In carico all’utente” e step “Da verificare scansione atto”. 3.2.6 Classificazione Clienti / Non Clienti La classificazione Clienti / Non Clienti viene effettuata automaticamente da Appian. Nello specifico Appian procede all’interrogazione di Anagrafe Web con i seguenti step: 1. Se il codice fiscale debitore è di 11 caratteri (in caso siano presenti meno di 11 caratteri, vengono aggiunti tanti zeri iniziali fino a 11 caratteri totali) e solo numerico, Appian effettua la ricerca dell’Unità Organizzata. Mentre, se il codice fiscale debitore è alfanumerico ed è di 16 caratteri, Appian ricerca la Persona Fisica. 2. In caso di Unità Organizzata, qualora non venga trovato il CF, la ricerca viene effettuata anche per “Partita IVA UE”. 3. Se la ricerca dà come risultato errore (es. codice fiscale non valido) il campo “Classificazione Cliente/ Non Cliente in Appian è valorizzato con “*Eccezione*” per l’opportuna verifica da parte dell’utente. Se invece la ricerca dà come esito “Nessun soggetto trovato”, Appian classifica il Codice Fiscale come “Non Cliente”. 4. Per tutti i “Soggetti trovati” Appian verifica la lista Accordi attivi 5. Se non è presente alcun accordo (o sono presenti solo accordi non pignorabili), Appian classifica il CF come “Non cliente”. Se sono presenti accordi pignorabili e il ruolo della persona indagata appartiene alla lista dei ruoli pignorabili, Appian classifica il CF come “Cliente” e conclude la ricerca. L’elenco completo delle tipologie di accordi pignorabili e dei ruoli pignorabili è presente nella sezione Allegati. Process Design Document - Pignoramenti 29 Classification : Internal I dati recuperati aggiornano i relativi campi del DB. Inoltre, Appian recupera dall’Anagrafe e salva a DB anche i seguenti dati per i Clienti con Accordi Attivi: NDG Gestore Principale (Nome gestore) Sportello principale (primi 4 caratteri rappresentano il dato “Sportello”) Nominativo ridotto (Debitore) Natura (Natura Giuridica: Persona Fisica, Ditta Individuale, ecc) Settore Principale COPE In caso di Non Cliente, Appian richiede all’utente di confermare i dati per la generazione della Dichiarazione per i Non Clienti. Nello specifico: Tabella Nome Avvocati e PEC Data Notifica Tabella creditori Debitore CF Debitore Importo PPT Tribunale Data Udienza Commissioni Una volta inviate le informazioni, il robot procederà con la creazione della Dichiarazione di Terzo Pignorato (cfr. paragrafo 3.2.8 Creazione Dichiarazione di Terzo Pignorato). In caso di Clienti, l’addetto APAC Pignoramenti procederà come descritto nel paragrafo 3.2.7 Valutazione Pignoramento e verifica dati per la dichiarazione di terzo pignorato. Process Design Document - Pignoramenti 30 Classification : Internal  3.2.7 Valutazione Pignoramento e verifica dati per Creazione Dichiarazione di terzo pignorato L’operatore APAC effettua gli inquiry nei diversi sistemi e determina gli importi da vincolare e/o gli accordi da bloccare per ogni pratica. Per la valutazione del Pignoramento Appian propone i seguenti campi, suddivisi per sezione: SEZIONE “DATI PRATICA DA U.S.” Obbligatorio Regole di compilazione e data ID Nome campo Note SI/NO validation campo Non 1 C/F P.IVA DEBITORE - modificabile Non 2 NOME DEBITORE - modificabile 3 TRIBUNALE - Modificabile CAUSA DI Modificabile 4 - RIFERIMENTO 5 DATA UDIENZA - Modificabile 6 IMPORTO PPT - Modificabile 7 DATA NOTIFICA - Modificabile - Il campo è prevalorizzato con Modificabile 8 COMMISSIONI 50 CRONOLOGICO - Modificabile 9 UNEP SEZIONE “DATI CREDITORI” Process Design Document - Pignoramenti 31 Classification : Internal  COGNOME E NOME SI Modificabile 10 CREDITORE 11 C.F. / P.IVA NO Modificabile CODICE NO Data validation: solo valori Modificabile 12 CREDITORE numerici, massimo 7 caratteri SI (*solo in caso Modificabile Motivazione di blank 13 CF/P.IVA vuoto dell’ID11 + ID12). 14 PERSONA FISICA NO Modificabile 15 RAGIONE SOCIALE NO Modificabile 16 Cognome - Modificabile 17 Nome - Modificabile 18 Indirizzo - Modificabile 19 Loc. Residenza - Modificabile 20 Data di nascita - Modificabile 21 Loc. di nascita - Modificabile 22 CAP - Modificabile 23 Provincia - Modificabile 24 Sesso - Modificabile SEZIONE “DATI AVVOCATI” 25 COGNOME E NOME SI Modificabile 26 PEC AVVOCATO SI Modificabile Process Design Document - Pignoramenti 32 Classification : Internal  C.F. / P.IVA Modificabile 27 NO AVVOCATO SI (*solo nel Modificabile caso in cui il campo CODICE Data validation: solo valori 28 CF/P.IVA sia CREDITORE numerici, massimo 7 caratteri blank, altrimenti non obbligatorio) Cognome Modificabile 29 - 30 Nome - Modificabile 31 Indirizzo - Modificabile 32 Residenza - Modificabile 33 Data di Nascita - Modificabile 34 Loc. di Nascita - Modificabile 35 CAP - Modificabile 36 Provincia - Modificabile 37 Sesso - Modificabile Process Design Document - Pignoramenti 33 Classification : Internal SEZIONE “DATI BLOCCHI E IMPEGNI” L’utente compila la tabella dei Blocchi che segue, cliccando su “Aggiungi Blocchi” per aggiungere nuovi blocchi: Il campo è prevalorizzato con Campo Sì/No 38 BLOCCO C/C SI “No” SPORTELLO Data validation: solo valori 39 SI DEBITORE numerici, massimo 4 caratteri Data validation: massimo 6 40 C/C DEBITORE SI caratteri Data validation: solo valori 41 IMPORTO IMPEGNO NO numerici Data validation: solo valori 42 NUMERO IMPEGNO NO numerici, massimo 3 caratteri Successivamente prosegue con la compilazione dei seguenti campi: PIGNORAMENTO - Modificabile 43 TITOLI PIGNORAMENTO - Modificabile 44 CASSETTE DI SICUREZZA Data validation: solo valori 46 CODICE DOMINIO SI numerici, massimo 4 numeri STIPENDIO/PENSIO Campo Sì/No 47 SI NE Campo Sì/No Se NO non SI visualizzare il 43 LDR/PADI/TITOLI campo Importo da LDR/PADI Process Design Document - Pignoramenti 34 Classification : Internal  SI solo se Data validation: solo valori IMPORTO DA 44 LDR/PADI/TITO numerici, con massimo due LDR/PADI LI = Sì decimali Il campo è pre-valorizzato Campo con P se Importo da opzione LDR/PADI + la somma degli singola: P, importi degli Impegni = PP, N. Importo PPT. Il campo è pre-valorizzato con PP se Importo da ESITO 45 SI LDR/PADI + la somma degli PIGNORAMENTO importi degli Impegni < Importo PPT (e al contempo Importo PPT > 0). Il campo è pre-valorizzato con N se i campi Importo LDR/PADI + gli altri campi importo impegno = 0. Successivamente, l’utente procede con la visualizzazione/modifica dei seguenti campi: Questo campo viene popolato automaticamente Non 46 TOTALE DA DICHIARARE - da Appian ed è la somma Modificabile dei campi Impegno, Importo da LDR/PADI Campo opzione singola: Ambra Marino, Anna Ferreri, Simona 47 FIRMATARIO SI Lunetta, Donato Prisco, Nicola Galante, Cosimo Puleo, Francesco Lo Duca 48 SCARTO ECCEZIONE NO Checkbox SI, visibile se Scarto 49 Nota scarto eccezione eccezione è true Se durante i controlli manuali e l’arricchimento dei dati della fase di Valutazione del Pignoramento, gli operatori verificano la presenza di eccezioni/errori/incompletezze, l’operatore APAC può flaggare Process Design Document - Pignoramenti 35 Classification : Internal il campo checkbox “Scarto Eccezione” per completare la pratica extra-flusso robot e indicare il motivo dello scarto nel campo note dedicato “Nota scarto Eccezione”. Infine, l’addetto APAC Pignoramenti verifica e valida le informazioni per la creazione della Lettera Dichiarazione di Terzo Pignorato. Nello specifico verifica: il campo “Tipo Lettera” se valorizzato correttamente. Il campo è una dropdown pre- valorizzata e modificabile con le seguenti opzioni: o Dichiarazione Terzo Pignorato negativa, se esito Pignoramento è uguale a “N” (negativo) o Dichiarazione Terzo Pignorato parzialmente positiva stipendio, se esito Pignoramento è uguale a “PP” (parzialmente positivo) e il campo “Stipendio/Pensione” è uguale a Sì o Dichiarazione Terzo Pignorato parzialmente-positiva, se esito Pignoramento è uguale a “PP” (parzialmente positivo) e il campo “Stipendio/Pensione” è uguale a No o Dichiarazione Terzo Pignorato positiva-stipendio, se esito Pignoramento è uguale a “P” (positivo) e il campo “Stipendio/Pensione” è uguale a Sì o Dichiarazione Terzo Pignorato positiva, se esito Pignoramento è uguale a “P” (positivo) e il campo “Stipendio/Pensione” è uguale a No. i campi presenti nel form e che verranno inseriti nella lettera. Dopo aver inserito, ed eventualmente modificato tutte le informazioni previste, l’utente procede cliccando sul pulsante “Invia”. 3.2.8 Recupero Data Impegno Il robot accede a CICSBNL e inserisce in “GRUPPO” il numero corrispondente all’opzione di menù “INQ TP/CO – C/C ORDINARI” e preme INVIO. Il robot inserisce in “SCELTA” il numero corrispondente all’opzione di menù “INQUIRY SUI CONTI CORRENTI” e preme INVIO. Process Design Document - Pignoramenti 36 Classification : Internal Il robot inserisce in “SCELTA” il numero corrispondente all’opzione di menù “ESTRATTI” e preme INVIO. Il robot inserisce in “SCELTA” il numero corrispondente all’opzione di menù “ESTRATTO IMPEGNI/AVVISI” e preme INVIO. Il robot inserisce i dati relativi allo “SPORTELLO”, al “CONTO” e in “DATA RIF.” inserisce la data odierna. Process Design Document - Pignoramenti 37 Classification : Internal Viene mostrato lo storico degli impegni relativi al conto inserito. Il Robot recupera il campo DT Impegno associato all’impegno inserito dall’utente a front-end Appian incrociando i valori Numero e Importo. A questo punto il robot verifica se la pratica è di tipo 492bis. In caso affermativo, se il decreto è arrivato (verifica valore di un campo specifico del DB Appian) la pratica viene posta in step “Verifica Pignoramenti” (paragrafo 3.2.10). Altrimenti si prosegue con il normale flusso (paragrafo 3.2.9) All’arrivo del decreto la pratica ritorna nello step “Blocchi e Impegni”. Dopo aver inserito, ed eventualmente modificato tutte le informazioni previste sui blocchi, l’utente procede cliccando sul pulsante “Invia”. La pratica passa quindi in stato “In carico al robot” e step “Recupero Data Impegno”. Viene quindi rieseguito tale step di Recupero Data Impegno. Per quanto riguarda il front-end Appian vi è la funzionalità, attraverso specifico pulsante ‘Risottometti Pratica’, per gli item che presentano stato bot “Eccezione” e step “Recupero Data Impegno” di mandare indietro una pratica allo stato bot “In carico all’utente” e step “Blocchi e Impegni”. 3.2.9 Inserimento Terzo Pignorato Il robot procede col censimento della pratica: Accede a CICS TERZO PIGNORATO – UQOPERAT Process Design Document - Pignoramenti 38 Classification : Internal Accede in ANAGRAFE: Process Design Document - Pignoramenti 39 Classification : Internal Accede in CENSIMENTO: Sulla schermata di atterraggio inserisce il dominio (recuperato dal relativo campo CODICE DOMINIO nel DB) e preme INVIO. Process Design Document - Pignoramenti 40 Classification : Internal Sulla schermata di atterraggio compila la maschera con i dati recuperati dai relativi campi della tabella a DB: Process Design Document - Pignoramenti 41 Classification : Internal  TRIBUNALE PROTOCOLLO CAUSA RIF → inserire CAUSA DI RIFERIMENTO/TITOLO PRECETTATO + COGNOME E NOME CREDITORI (inserire solo il 1° nome – quello prima della virgola nel campo SP – ed eventualmente tagliare fino a lunghezza massima consentita dall’applicativo) DATA UDIENZA DATA CONSEGNA = DATA NOTIFICA PRATICA CONTABILE → inserire SI (default). Nel caso in cui nello stato di BLOCCHI E IMPEGNI il campo “ldr/padi/titoli” = “SI”, allora inserire “NO”. IMPEGNO SU CC → inserire “SI” se uno tra IMPEGNO 1, IMPEGNO 2, IMPEGNO 3 della vista SP nello stato BLOCCHI E IMPEGNI risulta popolato, altrimenti “NO”. SPORTELLO / CONTO (debitore). Inoltre, se dalle regole del punto sopra risulta pratica contabile NO, allora il robot dovrà inserire solo lo sportello. PIGNORAMENTI inserire l’importo precettato aumentato della metà TOTALE E IMPEGNI ADDEBITI = (Trattasi di default del sistema) Premere F1 per concludere la procedura. Nel caso in cui i soggetti creditori siano già esistenti (ovvero nello stato BLOCCHI E IMPEGNI il campo CODICE CREDITORE risulta popolato), il robot non deve procedere con il censimento del relativo creditore / avvocato. Se CODICE CREDITORE non presente, in CICS il robot compila tutti i campi riportati di seguito e con le informazioni recuperate dallo stato di BLOCCHI E IMPEGNI. Di seguito gli step: Dopo aver completato la parte di censimento descritta precedentemente ed aver completato la compilazione della seguente schermata: Process Design Document - Pignoramenti 42 Classification : Internal Preme INVIO e preme F5 per accedere all’anagrafe della pratica per il censimento del creditore: In questa schermata compilare i campi come segue: CODICE FISCALE = C.F. CREDITORE NOMINATIVO = cognome nome DEBITORE INDIRIZZO LOC. RESIDENZA DATA DI NASCITA LOC. DI NASCITA CAP → utilizzare file di transcodifica per identificare il CAP con l’incrocio Provincia – CAP (*) Process Design Document - Pignoramenti 43 Classification : Internal  PROVINCIA (residenza) → si popola in automatico con l’inserimento della Loc. di residenza PROVINCIA (nascita) → si popola in automatico con l’inserimento della Loc. di nascita SESSO SOGGETTA A RITENUTA D’ACCONTO: SI (default). Inserire NO se Persona fisica NO (recuperato dai campi presenti nella schermata dello stato BLOCCHI E IMPEGNI). 2.CONTO INTERNO = 012608080000 PERSONA GIURIDICA S/N → se il campo di PERSONA FISICA = SI, allora il robot non compila questo campo. Se il campo RAGIONE SOCIALE = “SOCIETA’ DI CAPITALI” allora il robot inserisce “SI”. Se il campo RAGIONE SOCIALE = “SOCIETA’ DI PERSONE” allora il robot inserisce “NO”. AVVOCATO / RICORRENTE = A/R → “R” se è un creditore “A” se è avvocato Al termine dell’inserimento preme F12 e l’applicativo genererà il codice inserendolo in automatico nel campo CREDITORE. Per completare la pagina, nelle NOTE inserire “.” e nel campo “REG. CONT / PROGR.” Inserire “2”. Nel caso in cui siano più creditori/avvocati da censire, il robot preme F8 (e ripetere quanto sopra), altrimenti F12 per concludere l’operatività. (*) il file di transcodifica dei CAP deve essere fornito e aggiornato dal business. Dove aver completato la fase di CENSIMENTO il robot procede con la creazione della Dichiarazione. Per quanto riguarda il front-end Appian vi è la funzionalità, attraverso specifico pulsante ‘Risottometti Pratica’, per gli item che presentano stato bot “Eccezione” e step “Inserimento in Terzo Pignorato” di mandare indietro una pratica allo stato bot “In carico all’utente” e step “Blocchi e Impegni”. 3.2.10 Verifica Pignoramenti Il robot, per le pratiche 492bis dopo il secondo step di “Blocchi e Impegni” recupera per la pratica in oggetto le informazioni sui Blocchi presenti su Appian e quelle presenti su CICSBNL e le confronta tra loro per capire se ci sono state variazioni da parte dell’utente. Accede a CICS TERZO PIGNORATO – UQOPERAT SCELTA →133 Process Design Document - Pignoramenti 44 Classification : Internal SCELTA →2 DATI → 4700 Inserisce dominio, anno e numero pratica e clicca INVIO Process Design Document - Pignoramenti 45 Classification : Internal Nella seguente schermata il robot recupera i campi relativi agli impegni (C/C, ADDEBITO, IBAN, NUMERO, DATA, IMPORTO). Preme F1 per terminare. Esegue il confronto tra le informazioni recuperate dal DB e CICSBNL. Se esistono blocchi su Appian per cui il numero impegno è vuoto o per cui ci sono differenze rispetto al corrispondente blocco su CICS il robot prima di effettuare qualsiasi variazione deve eseguire la cancellazione quindi esegue gli step descritti nel paragrafo 3.2.11. Se su CICS non sono presenti impegni allora effettua direttamente l’inserimento come descritto nel paragrafo 3.2.12. Se non ci sono impegni da inserire passa direttamente allo step 3.2.13. Process Design Document - Pignoramenti 46 Classification : Internal  3.2.11 Cancellazione Pignoramenti Il robot procede con la cancellazione degli impegni della pratica: Accede a CICS TERZO PIGNORATO – UQOPERAT SCELTA →133 SCELTA →2 DATI → 4700 Process Design Document - Pignoramenti 47 Classification : Internal Inserisce dominio, anno e numero pratica e clicca INVIO Per cancellare inserisce: PRATICA CONTABILE → NO IMPEGNI SU C/C → NO Clicca INVIO (a volte bisogna premere F9 per forzare la variazione) Process Design Document - Pignoramenti 48 Classification : Internal A questo punto per confermare la cancellazione INVIO, INVIO, F12. La cancellazione effettiva avviene dopo 48 ore e solo a questo punto è possibile effettuare un nuovo inserimento (paragrafo 3.2.12). 3.2.12 Inserimento Terzo Pignorato (post Decreto) Il robot, in seguito all’arrivo del decreto e all’eventuale cancellazione degli impegni procede con il nuovo inserimento degli impegni della pratica: Accede a CICS TERZO PIGNORATO – UQOPERAT SCELTA →133 Process Design Document - Pignoramenti 49 Classification : Internal SCELTA →2 DATI → 4700 Inserisce dominio, anno e numero pratica e clicca INVIO Process Design Document - Pignoramenti 50 Classification : Internal Nella seguente schermata inserisce: RUOLO G.ESEC. → valore recuperato da DB DATA UDIENZA PRATICA CONTABILE → inserire “SI” IMPEGNI SU C/C → inserire “SI” DICH. AL GIUDICE → valore recuperato da DB Il robot compila i campi relativi agli impegni (NUMERO, DATA, IMPORTO) in base alle informazioni dei blocchi recuperate in BLOCCHI E IMPEGNI. Preme INVIO A volte bisogna premere F9 per forzare la variazione. Process Design Document - Pignoramenti 51 Classification : Internal Preme INVIO, INVIO, F12 per confermare. 3.2.13 Invio mail gestore Process Design Document - Pignoramenti 52 Classification : Internal Il robot recupera il template email associato all’esito del Pignoramento (Positivo, Parzialmente Positivo oppure Negativo) e lo compila con la seguente serie di informazioni: [TRIBUNALE] [CREDITORE] [DEBITORE] [IMPORTO] [DATA UDIENZA] [DATA NOTIFICA] [IMPEGNO 1] [SPORTELLO 1] [CONTO 1] [IMPORTO 1] [BLOCCO 1] [IMPEGNO 2] [IMPORTO 2] [BLOCCO 2] [SPORTELLO 2] [CONTO 2] [IMPEGNO 3] [SPORTELLO 3] [CONTO 3] [IMPORTO 3] [BLOCCO 3] In caso la checkbox LDR/PADI/TITOLI sia stata flaggata dall’utente nel corso della fase Blocchi / Impegni, il Robot non effettua l’invio della mail, ma rende disponibile all’utente una bozza che conterrà i campi [LDR] e [TITOLI] compilabili a cura dell’utente. Il robot invia la mail al gestore della relazione e al sostituto allegando il modulo di rinuncia in formato pdf. In caso di clienti con settore 41 oppure 49 il robot aggiunge tra i destinatari in cc l’indirizzo di gruppo della struttura che segue i clienti con questo settore. 3.2.13 Inserimento nota evento Se cliente BNL, il robot deve tracciare l’evento di pignoramento in Anagrafe Web. Il robot accede a JFWEB ed effettua il log-in specificando l’utente e la password. Clicca su “Login” Process Design Document - Pignoramenti 53 Classification : Internal Clicca su “Conferma” e in seguito su “Deciderò più tardi” Process Design Document - Pignoramenti 54 Classification : Internal Clicca su Anagrafe WEB. Poi clicca su Ricerca Puntuale. Il robot inserisce l’NDG del cliente e clicca su ricerca. Process Design Document - Pignoramenti 55 Classification : Internal Il robot clicca su “Gestione” → “Eventi”. Inserisce quanto segue: Tipo Evento → seleziona COMUNICAZIONI Categoria → seleziona INFORM. PREGIUDIZ. Sottocategoria → seleziona PIGNORATO Fonte Informazione → seleziona ESTERNO Data inizio → recupera da DB la data di notifica atto Testo → inserisce “PPT [Numero pratica] – [Importo Pignoramento] – [Data Notifica] – [Nomi/Cognomi Creditori]” Clicca su Conferma. Process Design Document - Pignoramenti 56 Classification : Internal  3.2.14 Creazione dichiarazione di terzo pignorato La dichiarazione viene creata a partire dai template Word presenti nella FileBoard. Di seguito la lista dei template (si riportano file word nel paragrafo 4 Allegati): dichiarazione non cliente.docx dichiarazione terzo pignorato_negativa.docx dichiarazione terzo pignorato_parzialmente-positiva-stipendio.docx dichiarazione terzo pignorato_parzialmente-positiva.docx dichiarazione terzo pignorato_positiva-stipendio.docx dichiarazione terzo pignorato_positiva.docx Il robot compila i template delle dichiarazioni in base al campo Tipo di Lettera presente a DB, confermato dal Business nella fase precedente di Valutazione Pignoramento e verifica dati per creazione dichiarazione di terzo pignorato. La compilazione dei template da parte del robot avviene sostituendo delle specifiche variabili all’interno dei file Word, in modo da avere in output una dichiarazione completa con tutte le informazioni. Di seguito la lista delle variabili che vengono inserite all’interno dei template: dichiarazione non cliente.docx o [DATA ODIERNA] o [NOME AVVOCATI] o [PEC AVVOCATI] o [DATA NOTIFICA] o [TRIBUNALE] o [NOME CREDITORE] o [DEBITORE] o [PIGNORATO] o [DATA UDIENZA] o [CF DEBITORE] o [COMMISS] o [ANNO] o [PROGRESSIVO] Process Design Document - Pignoramenti 57 Classification : Internal  dichiarazione terzo pignorato_negativa.docx o [NUM PRAT] o [DATA ODIERNA] o [PEC AVVOCATO 1] o [PEC AVVOCATO 2] o [PEC AVVOCATO 3] o [NOME AVVOCATO 1] o [NOME AVVOCATO 2] o [NOME AVVOCATO 3] o [DATA NOTIFICA] o [CREDITORE] o [DEBITORE] o [PIGNORATO] o [TRIBUNALE] o [DATA UDIENZA] o [COMMISS] dichiarazione terzo pignorato_parzialmente-positiva-stipendio.docx o [NUM PRAT] o [DATA ODIERNA] o [PEC AVVOCATO 1] o [PEC AVVOCATO 2] o [PEC AVVOCATO 3] o [NOME AVVOCATO 1] o [NOME AVVOCATO 2] o [NOME AVVOCATO 3] o [DATA NOTIFICA] o [CREDITORE] o [DEBITORE] o [PIGNORATO] o [TRIBUNALE] o [DATA UDIENZA] o [IMPEGNI] o [COMMISS] dichiarazione terzo pignorato_parzialmente-positiva.docx o [NUM PRAT] o [ODATA ODIERNA] o [PEC AVVOCATO 1] o [PEC AVVOCATO 2] o [PEC AVVOCATO 3] o [NOME AVVOCATO 1] o [NOME AVVOCATO 2] Process Design Document - Pignoramenti 58 Classification : Internal  o [NOME AVVOCATO 3] o [DATA NOTIFICA] o [CREDITORE] o [DEBITORE] o [PIGNORATO] o [TRIBUNALE] o [DATA UDIENZA] o [IMPEGNI] o [COMMISS] dichiarazione terzo pignorato_positiva-stipendio.docx o [NUM PRAT] o [DATA ODIERNA] o [PEC AVVOCATO 1] o [PEC AVVOCATO 2] o [PEC AVVOCATO 3] o [NOME AVVOCATO 1] o [NOME AVVOCATO 2] o [NOME AVVOCATO 3] o [DATA NOTIFICA] o [CREDITORE] o [DEBITORE] o [PIGNORATO] o [TRIBUNALE] o [DATA UDIENZA] o [IMPEGNI] o [COMMISS] dichiarazione terzo pignorato_positiva.docx o [NUM PRAT] o [DATA ODIERNA] o [PEC AVVOCATO 1] o [PEC AVVOCATO 2] o [PEC AVVOCATO 3] o [NOME AVVOCATO 1] o [NOME AVVOCATO 2] o [NOME AVVOCATO 3] o [DATA NOTIFICA] o [CREDITORE] o [DEBITORE] o [PIGNORATO] o [TRIBUNALE] o [DATA UDIENZA] o [IMPEGNI] Process Design Document - Pignoramenti 59 Classification : Internal  o [COMMISS] Il robot salva le dichiarazioni in formato.pdf, prevedendo l’ID della pratica nella prima parte del nome (eg: ID_nomeDocumento), e le carica in Appian. Le dichiarazioni generate sono visualizzabili per singola pratica accessibile da Cruscotto in Appian. 3.2.15 Scarico massivo dichiarazioni per la firma L’operatore ha a disposizione nel cruscotto la record action per il download massivo delle dichiarazioni. Il pulsante consente di effettuare il download massivo di tutte le dichiarazioni di terzo pignorato dall’interfaccia "Scarico massivo dichiarazioni". L’interfaccia si compone di: una prima sezione contenente i seguenti filtri: o CF/P.IVA debitore o Esito pignoramento o Data notifica o Data udienza Una seconda sezione contenente la tabella con la funzionalità checkbox per selezionare i documenti da scaricare e i seguenti campi: Process Design Document - Pignoramenti 60 Classification : Internal  o ID o Ticket ID o Stato o CF/P.IVA debitore o Esito pignoramento o Data notifica o Data udienza Una volta selezionate le pratiche per il download, l’operatore clicca sul pulsante "Predisponi Scarico". Quindi, al termine del recupero dei file dalla Fileboard, il pulsante sarà sostituito da "Completa Scarico" e verrà utilizzato per scaricare i documenti in locale per la firma. 3.2.16 Caricamento massivo dichiarazioni di terzo pignorato firmate Dopo aver effettuato la firma tramite ARUBA, l’operatore può procedere al caricamento massivo delle Dichiarazioni firmate tramite il pulsante "Caricamento massivo dichiarazioni" presente nel Cruscotto. È importante che l’utente NON modifichi il nome del file nella parte che individua l’ID della pratica affinché la procedura di caricamento massivo abbia successo. Tramite il pulsante, l’operatore accede all’interfaccia per l’upload delle dichiarazioni. Process Design Document - Pignoramenti 61 Classification : Internal L’interfaccia mostra i seguenti campi: Utente caricamento: è la risorsa che effettua il caricamento massivo dei documenti Matricola: è la matricola della risorsa che effettua il caricamento massivo dei documenti Data caricamento: è la data del caricamento massivo Carica: è il campo con cui effettuare il caricamento o trascinare i documenti da caricare Numero documenti inseriti: è il campo counter che conta i file caricati Cliccando sul pulsante "Avvia caricamento" il sistema effettua l’upload di ogni singolo documento in fileboard, individuando l’ID della pratica nel nome del documento e lo registra nella tabella "Allegati" campo PRATICA_ASSOCIATA, insieme al nome del documento nel campo NOME_DOCUMENTO. Ogni documento sarà visibile nell’interfaccia di gestione documentale della relativa pratica e accessibile da cruscotto tramite l’icona della cartella. 3.2.17 Invio PEC Il robot controlla la presenza dei file.pdf e.p7m in Appian. A questo punto procede con l’invio della PEC inserendo, tra le altre, le seguenti info: Destinatario: [PecAvvocato1] (se presenti anche [PecAvvocato2] e [PecAvvocato3]) Mittente: [email protected] Oggetto: “DTPR: Pratica [Num Pratica] – Debitore esecutato [NomeDebitore] – Udienza [DataUdienza] Inoltre, la ricevuta di invio della PEC e il file con formato “.mail” sono salvati in Appian. Infine, è necessario intercettare la ricevuta di consegna della PEC inviata (utilizzando DNCR / DTPR + codice pratica) e salvare l’output in formato “.pdf” e caricarlo in Appian. In caso di mancato invio o mancato recapito della dichiarazione a mezzo PEC, l’item sarà visualizzato nel “Cruscotto” con stato bot “Eccezione” e step “Invio PEC”. La relativa eccezione consente attraverso specifico pulsante ‘Risottometti Pratica' di risottomettere della pratica allo stato bot “In carico al robot” e step “Invio PEC”. Una volta inviata manualmente la PEC, l’utente accede al Riepilogo della specifica pratica presente nella tabella del Cruscotto di Appian e clicca sul pulsante “PEC inviata”. Process Design Document - Pignoramenti 62 Classification : Internal Process Design Document - Pignoramenti 63 Classification : Internal 4 Allegati ID Nome allegato Descrizione Allegato Excel che contiene Estrazione5fTicket5fRem. 1 l’estrazione dei ticket xls effettuata su Aurelia Notifica atto- ticket privo di Testo relativo a ticket privo 2 allegato.docx di allegato NOTIFICA ATTO - TICKET PRIVO DI ALLEGATO.docx Notifica atto- ticket Testo relativo a ticket 3 allegato incompleto.docx incompleto NOTIFICA ATTO - TICKET ALLEGATO INCOMPLETO.docx Notifica atto-Invia di Testo relativo a Invia 4 ricezione.docx ricezione NOTIFICA ATTO – CONFERMA DI RICEZIONE E PRESA IN CARICO.do Template della mail da Template Positivo.htm inviare al gestore (esito 5 Positivo) Template Positivo.htm Template della mail da Template Parzialmente inviare al gestore (esito 6 Positivo.htm Parzialmente Positivo) Template Parzialmente Positivo.htm Template della mail da Template Negativo.htm inviare al gestore (esito 7 Template Negativo) Negativo.htm Modello Dich di Modulo di rinuncia da INEFFICACIA per ppt allegare alla mail per il 8 Modello Dich di notificati a far data dall'11- gestore INEFFICACIA per ppt notificati a far data dall'11-12- 12-2014.pdf dichiarazione non Template della 9 dichiarazione non cliente cliente.docx dichiarazione non cliente.docx Template della dichiarazione terzo dichiarazione di terzo 10 dichiarazione terzo pignorato_negativa.docx pignorato negativa pignorato_negativa.docx Template della dichiarazione terzo dichiarazione di terzo 11 pignorato_parzialmente- pignorato parzialmente dichiarazione terzo positiva-stipendio.docx positiva stipendio pignorato_parzialmente-positiva-stipendio.docx Process Design Document - Pignoramenti 64 Classification : Internal  Template della dichiarazione terzo dichiarazione di terzo 12 pignorato_parzialmente- pignorato parzialmente dichiarazione terzo positiva.docx positiva pignorato_parzialmente-positiva.docx Template della dichiarazione terzo dichiarazione di terzo 13 pignorato_positiva- pignorato positiva dichiarazione terzo stipendio.docx stipendio pignorato_positiva-stipendio.docx Template della dichiarazione terzo dichiarazione di terzo 14 pignorato_positiva.docx pignorato positiva dichiarazione terzo pignorato_positiva.docx Lista completa di tutte le Codici accordi tipologie di accordi 15 pignorabili.txt pignorabili Codici accordi pignorabili.txt Lista ruoli per i quali un accordo presente nella Lista Accordi va 17 ListaRuoliClienti.xlsx considerato per ListaRuoliClienti.xlsx determinare se l’utente indagato è cliente o meno Process Design Document - Pignoramenti 65 Classification : Internal 5 Eccezioni Di seguito un elenco delle eccezioni che si possono verificare durante l’attività del robot. 5.2 Business Exception ID Fasi Causa Azione 01_Ticket non Stato 1 - Analisi Ticket Ticket non trovato su Item marcato com