SIRAP -
ALE
Scheda descrittiva del programma Sistema Regionale Accordo Pagamenti
- SIRAP -
ceduto in riuso
Regione Lazio
< Questo sistema verrà aggiornato non appena
le emanande norme sulla fatturazione elettronica saranno operative >
ALE
1 SEZIONE 1 – CONTESTO ORGANIZZATIVO
1.1 Generalità
1.1.1 Identificazione e classificazione dell’amministrazione cedente
🢂 Amministrazione cedente: Regione Lazio
🢂 Amministrazione cedente – Sigla: RL
🢂 Tipologia di Amministrazione cedente: Amministrazione regionale
1.1.2 Identificazione e classificazione dell’Oggetto
🢂 Oggetto offerto in riuso:
Sistema Regionale Accordo Pagamenti (SIRAP), piattaforma software a supporto degli “Accordi di Pagamento” che consente di gestire, secondo procedure uniformi, i crediti commerciali oggetto di fatturazione dei fornitori delle Aziende Sanitarie e Aziende Ospedaliere della Regione Lazio.
Le procedure informatiche implementate dal SIRAP, possono essere riassunte in: acquisizione fatture, acquisizione ed inoltro degli ordini, documenti di trasporto e carichi di magazzino, invio fatture ai gestionali delle Aziende Sanitarie/Ospedaliere per registrazione automatica in contabilità, acquisizione partitario (liquidazioni), riconciliazione fatture, gestione cessioni e pagamento fatture.
Le procedure suddette hanno abilitato, tra gli altri, il monitoraggio della spesa sanitaria e il monitoraggio e governo dei processi di liquidazione delle diverse Aziende Sanitarie e Ospedaliere, nonché trasparenza,puntualità ed omogeneità nel pagamento dei fornitori.
🢂 Oggetto offerto in riuso - Sigla: SIRAP
🢂 Tipologia di Oggetto offerto in riuso: Amministrativo/Contabile
🢂 Collocazione funzionale dell’Oggetto.
L’Oggetto realizza funzioni a livello di: Processo
🢂 Tipologia di licenza dell’Oggetto offerto: Open source
Note: Il software è stato realizzato utilizzando componenti software sviluppate “ad hoc” su indicazioni del gruppo di progetto della Regione Lazio. La Regione Lazio è il titolare del software denominato SIRAP.
🢂 Modalità di implementazione dell’Oggetto ceduto in riuso: Realizzazione ex-novo su specifiche dell’amministrazione
🢂 Oggetto/i di cessione in riuso: Oggetto o parte di esso
ALE
1.1.3 Referenti dell’amministrazione cedente
🢂 Responsabile dei sistemi informativi | Nome e cognome: Xxxxxxxxx: Tel/Cel: e-mail:: | Xxxxxxxx Xxxxxxxxx Xxx Xxxx Xxxxxxxx Xxxxxxxxx 0,00000 Xxxx 06.45200839 |
🢂 Referente/i di progetto | Nome e cognome: Xxxxxxxxx: Tel/Cel: e-mail:: | Xxxxxxxx Xxxxxxxxxxx Xxx Xxxx Xxxxxxxx Xxxxxxxxx 0,00000 Xxxx 00.00.00.00.00 |
🢂 Referente/i amministrativo | Nome e cognome: Xxxxxxxxx: Tel/Cel: e-mail:: | Xxxxx Xxxxxxxx Xxx Xxxx Xxxxxxxx Xxxxxxxxx 0,00000 Xxxx 00.00.00.00.00 |
ALE
1.2 Scenario di riuso
1.2.1 Ambito amministrativo interessato
Contabilità e patrimonio Dematerializzazione
Gestione di flussi documentali a supporto della cooperazione amministrativa Servizi alle Imprese
Altro : servizi ad altre PA
1.2.2 Utenti fruitori dell’Oggetto
Numero totale di Utenti che utilizzano l’Oggetto: 4.093
Note: Essendo un applicativo web-based, il numero degli utenti è stato calcolato sommando il numero di utenti registrati al portale + utenti Regione Lazio con funzionalità di Back-Office + utenti ASL/AO.
🢂 Contesto organizzativo
La piattaforma software SIRAP si colloca all’interno della Struttura Regionale di Supporto-Direzione Regionale Bilancio ed è trasversale rispetto alle seguenti strutture: “Ragioneria” , “Finanza e Tributi” e “Area Centrale Acquisti e Crediti Sanitari” , ed è finalizzata all’ottimizzazione dei processi di pagamento e alla razionalizzazione degli acquisti.
🢂 Obiettivi perseguiti
Formalizzazione degli “Accordi di Pagamento” da parte dei fornitori del SSR- Servizio Sanitario Regionale: ASL/AO;
Controllo dei tempi di liquidazione e ottimizzazione dei processi di pagamento ; Puntualità, trasparenza ed omogeneità nel pagamento dei fornitori del SSR; Riduzione del debito dei fornitori del SSR;
Digitalizzazione del processo e il monitoraggio dell’intero ciclo passivo: dall’emissione dell’ordine fino al pagamento delle relative fatture, integrato con i sistemi gestionali delle ASL/AO.
Realizzazione di un Sistema di Fatturazione Telematica basato su flussi standard XML e firma digitale, per la gestione del pagamento centralizzato dei fornitori di beni e servizi ed altre tipologie specifiche per il SSR (es: Case di Cura, liberi professionisti, Ospedali Classificati, Ex-.Art 26)
🢂 Aspetti dimensionali
Numero totale di FP dell’Oggetto: 880 Numero Classi java: 3.839
Numero di Moduli: 12
Numero totale linee di codice: 818.235
ALE
1.2.3 Descrizione dettagliata delle funzionalità e/o delle classi
Nome | Descrizione | Dati Input Output | |
Registrazione | Attraverso questa funzione il sistema permette di iscriversi al SIRAP e predisporre la documentazione per la sottoscrizione dell’Accordo Pagamenti | L’utente inserisce a sistema i propri dati anagrafici i riferimenti bancari e i dati per il referente del sistema. | Il sistema invia una mail di notifica di avvenuta registrazione contenente le credenziali di accesso e un link per l'attivazione dell'utenza. |
Gestione Accordo | Attraverso questa funzione il sistema permette di registrare un accordo regionale a cui deve essere valorizzata la data di firma al fine di permettere la fatturazione al fornitore. | L’utente dopo aver effettuato l’accesso al sistema può inserire i dati del nuovo Accordo. | Il sistema associa un nuovo accordo al fornitore, l’utente regionale lo abilita alla fatturazione valorizzando la data di firma |
Gestione Contratto | Questa funzione è riservata alle strutture sanitarie le quali inseriscono uno o più contratti legati ad un'azienda sanitaria | L’utente dopo aver effettuato l’accesso al sistema può inserire un nuovo Contratto | Il sistema associa il contratto tra il fornitore e l’azienda sanitaria permettendo così di emettere fatture verso quest’ultima |
Gestione Anagrafica | Il sistema consente di modificare l'anagrafica per la propria utenza compreso il cambio della password d'accesso al SIRAP, consente all'utente regionale di modificare l'anagrafica di tutti gli utenti a sistema compreso il reset della password e può registrare nuovi utenti. | Una volta effettuato l’accesso al sistema l’utente avrà modo di verificare e modificare i dati inseriti compilando il form presente nel SIRAP. | L'utente modifica l'anagrafica presente a sistema comprese le credenziali d'accesso. |
Gestione Fatture | Il sistema consente ai fornitori di inserire, modificare, eliminare e ricercare le fatture. La modifica può essere effettuata, fino a quando la fattura è in fase di | L’utente potrà effettuare l’Inserimento dei dati fattura tramite upload diretto del | Raccolta dei dati di fatturazione al fine di raccogliere le informazioni contabili. |
bozza. L'eliminazione, invece, è possibile fino a quando l'azienda sanitaria non preleva le fatture. Le fatture possono essere inserite singolarmente tramite sistema o massivamente tramite l’uso dei WebServices esposti dal SIRAP | file XML o tramite il form presente a sistema. | ||
Scelta Cessionario | Attraverso questa funzione il sistema permette al Fornitore di selezionare un Cessionario | Una volta effettuato l’accesso l’utente potrà associare alla propria anagrafica un Cessionario tra quelli proposti. | Il sistema verifica la correttezza delle informazioni, associa il Cessionario. |
Scelta Service | Attraverso questa funzione il sistema permette al Fornitore di selezionare un Service1. | Una volta effettuato l’accesso l’utente potrà associare alla propria anagrafica un Service tra quelli proposti. | Il sistema verifica la correttezza delle informazioni, associa il Service. |
Gestione Cessioni | Al fine di cedere una fattura ad un cessionario o ad un ente previdenziale, è necessario che il fornitore inserisca l'atto di cessione. Una volta inserito l'utente potrà associare all'atto una o più fatture che il cessionario a sua volta potrà verificare e accettarle o meno. | Il fornitore ha la possibilità di inserire a sistema i dati per attivare una nuova cessione di fatture, il cessionario invece potrà verificarne la correttezza. | Il sistema consente di verificare la documentazione caricata, sia atto che fatture per cedente e cessionario, compresa la possibilità di aggiungere o rimuovere fatture dalla cessione |
Gestione Ordini | Il sistema consente la gestione degli ordini che vengono caricati, modificati o eliminati tramite Web-Services. Il fornitore ha modo di verificare gli ordini assegnati direttamente sul SIRAP | L'azienda sanitaria inserisce un nuovo ordine utilizzando i WS come canale di trasmissione. | Il Sistema raccoglie i dati al fine di permettere l’evasione dell’ordine ai fornitori. |
Gestione DDT / Carichi di magazzino | Il sistema consente di inserire e ricercare di DDT e i carichi di magazzino | L'azienda sanitaria inserisce un nuovo DDT/Carico di | Il sistema inserisce o genera il report richiesto per DDT e Carichi di |
ALE
1 Un Service nel sistema SIRAP è un utente che si occupa di gestire l’iter delle fatture per conto di uno o più utenti di tipo Fornitore
magazzino utilizzando i WS come canale di trasmissione. | magazzino | ||
Report Stati Fattura | L'utente visualizza lo stato dei pagamenti relativo alle fatture inserite in base alla tipologia d'utenza, ha modo di verificare anche lo stato di liquidazione delle stesse | L’utente una volta effettuato l’accesso al sistema può verificare lo stato dei pagamenti compilando il form di richiesta. | L'utente ha modo di scaricare i report messi a disposizione. |
Gestione Pagamenti | L'utente di Back-Office ha modo di aggiornare lo stato dei pagamenti a sistema.Può effettuare il download dei pagamenti per lavorarli esternamente al sistema e il caricamento massivo con lo stato aggiornato. Nuove richieste di pagamenti posso essere inserite a sistema tramite Web-Services e sempre tramite questi posso essere prelevati ed è possibile confermare lo stato dei pagamenti stessi, l'utente regionale ha anche modo di eliminare i pagamenti a sistema. | L’utente richiede o carica il report dei pagamenti. | Il sistema riporta l'esito dei caricamenti, dei pagamenti relativi report e consente di eliminare pagamenti. |
Report Audit 2 | L'utente regionale con le funzionalità di Amministrazione interroga il sistema di Audit | L’utente compila il form per la verifica gli eventi registrati in Audit | Il sistema visualizza gli eventi richiesti. |
Assistenza Remota | L'utente richiede l’assistenza remota. L’assistenza remota consente all’amministratore di accedere al sistema sfruttando le credenziali del richiedente. L’amministratore in questo modo agisce sul sistema con le funzionalità proprie del richiedente ma senza avere le credenziali d’accesso di quest’ultimo. In questo modo l’amministratore può effettuare operazioni a sistema per conto del richiedente | L’utente accede al sistema richiedendo assistenza remota tramite l’apposita funzione | La richiesta d’assistenza viene presa in incarico dall’amministratore |
ALE
2 Audit è un modulo del SIRAP che consente di intercettare le azioni degli utenti e di presentare un “log” per le analisi lato Backoffice
Schedulazione Job | Il job è un'unità di lavoro che gestisce l'esecuzione dei processi batch dove il batch è un processo eseguito periodicamente, la cui periodicità viene gestita dall'applicazione stessa. Esempio di questi processi sono: il processo batch per caricare le fatture da parte dei fornitori che viene eseguito ogni 5 minuti, per l'invio della posta certificata eseguito ogni 10 secondi, per il caricamento degli stati fattura eseguito ogni 5 minuti, per l'invio delle fatture alle azienda sanitarie eseguito alla mezzanotte di ogni giorno. Attualmente il sistema ha un totale di 22 job e quindi 22 processi batch. L'utente di Back-Office gestisce le funzionalità batch del sistema. | L’utente inserisce, modifica, avvia o ferma le funzionalità batch del sistema | Il sistema verifica le informazioni inserite e provvede a schedulare un nuovo Job. |
Audit | Il SIRAP autonomamente effettua il tracciamento degli utenti, registrando accessi e attività svolte: la data dell'evento, l'indirizzo remoto associato alla richiesta che genera l'evento, il contesto applicativo che genera l'evento, lo stato dell'evento, l'eventuale utenza che genera l'evento (Utente del sistema o il sistema stesso), il tipo di evento, una descrizione dell'evento per semplificarne la comprensione all’utente e l'identificativo del dato acceduto dall'evento di Audit | L'utente interagisce con il sistema | Le Interazioni utente vengono registrate |
Gestione Riconciliazioni manuali | Il sistema permette di associare (riconciliare manualmente o inserire una stellina) la fattura ad una partita che contiene gli stati fattura, il processo è necessario quando il sistema non può effettuare l'associazione | L’utente verifica lo stato di riconciliazione delle fatture, associando manualmente gli stati fattura o | L’utente aggiorna la validità temporale della stellina selezionata. In fase di riconciliazione il sistema scarta le |
ALE
automatica per incongruenza del numero documento. Se si dovessero verificare altre anomalie sulla riconciliazione (ad esempio incongruenza dell'importo fattura), il sistema permette di inviare segnalazioni riportando l'anomalia tramite la funzione Bandierine. La riconciliazione tra la fattura e la partita può avere o meno validità nel tempo. Questa funzione è riservata all'utente di Back-Office. | segnalando incongruenze | informazioni di trascodifica presenti nelle riconciliazioni scadute. | |
Gestione Riconciliazioni Automatiche | Il sistema associa automaticamente le fatture alle partite 3 che contengono gli stati fattura. Il processo è possibile in automatico solo se tra fattura e partita corrisponde: partita IVA del fornitore, numero del documento, data importo e il tipo documento | Il fornitore inserisce fatture a sistema | Il sistema aggiorna le informazioni di stato fattura. |
Reportistica | L'utente visualizza l’elenco dei report in base alla propria tipologia di utenza | L’utente compila il form di richiesta report | Il sistema genera il report lo rende disponibile all’utente. |
ALE
1.2.4 Servizi o procedure implementati
Nome servizio | Descrizione sintetica | Destinatari del servizio |
Gestione Documenti per Accordo Pagamenti | Gli utenti (Fornitori) del SIRAP scaricano e firmano, anche con l’uso di firma digitale, il documento che rappresenta l’accordo di pagamento delle fatture che verranno inserite nel portale. L’accordo viene memorizzato, insieme ai poteri di firma nell’area dedicata del portale SIRAP ed è accessibile dagli utenti di Back-Office consultazione e verifiche. Il sistema accetta anche ulteriore documentazione di | ▪ Imprese ▪ Liberi Professionisti ▪ PA |
3 Una partita è un insieme di scadenze di una fattura, ogni scadenza è descritta da un importo e uno tra i possibili stati: Registrata, Liquidata, Bloccata, Chiusa. La somma degli importi delle scadenze non può superare l’importo della fattura associata.
autocertificazione eventualmente firmati digitalmente (es: variazione IBAN). | ||
Alimentazione Catalogo Ordini,Documenti di Trasporto, Carichi di Magazzino | Il flusso degli ordini viene inviato dall’ASL/AO verso il sistema centrale SIRAP alimentando un il database centralizzato. Il SIRAP a sua volta rende disponibili gli ordini al fornitore nell’area dedicata. Tale flusso consente di garantire la coerenza dei dati periferici rispetto al sistema centrale il flusso dei pagamenti. Funzionalità identiche sono implementate per i flussi che rappresentano i Documenti di Trasporto e i Carichi di Magazzino. | ▪ Imprese ▪ PA ▪ Altre PA |
Alimentazione Fatture Ciclo Passivo e Monitoraggio e Previsione del Debito | Il flusso delle fatture viene inviato dal fornitore al SIRAP alimentando il database centrale. Tramite le funzionalità di report sulle fatture immesse nel SIRAP è possibile determinare in anticipo il debito delle PA periferiche (ASL/AO). | ▪ Imprese ▪ PA ▪ Altre PA |
Riconciliazione Partitario Fatture e Monitoraggio e Previsione del Debito | Il flusso del partitario trasmesso dall’ASL/AO verso il sistema centrale SIRAP alimenta il database centrale, tale flusso è oggetto della riconciliazione con il ciclo passivo, per una fattura riconciliata vengono rese disponibili le informazioni di liquidazione al fornitore. Tale processo consente di garantire la coerenza dei dati periferici rispetto al sistema centrale. | ▪ Imprese ▪ PA ▪ Altre PA |
Pagamento Fatture | Le fatture riconciliate sono oggetto del processo di pagamento, che avviene extra- sistema utilizzando,ad oggi, alcuni report in formato CSV. Il pagamento viene pubblicato sul SIRAP, e reso disponibile agli utenti, attraverso il caricamento di file che rappresentano il pagamento delle fatture. | ▪ Imprese ▪ PA |
Integrazione con Sistema QUASIAS4 | Attraverso Web-Services tra il sistema SIRAP e il QUASIAS dell’Agenzia per la Sanità Pubblica, le prestazioni sanitarie delle strutture sanitarie specialistiche accreditate, vengono inserite nel database centrale; a queste vengono associate automaticamente le fatture pre-compilate che rientrano nei flussi del ciclo passivo | ▪ Imprese ▪ PA ▪ Altre PA |
ALE
4 Sistema Informativo per l'Assistenza Specialistica Ambulatoriale Quasias online: xxxx://xxx.xxxxxxxx.xx/ manuale: xxxx://xxx.xxxxxxxx.xx/xxx_xxxxxx/xxx_xxxxxxxxxxxx/xxxxx/xxxx/xxxxxxx/XxxxxxxXxxxxxxXxxxxxx0000.xxx
Prelievo/Invio pagamenti verso ASL/AO | I pagamenti inseriti nel sistema sono anche utilizzati per le chiusure contabili dei gestionali delle ASL/AO al fine di garantire la coerenza dei dati periferici rispetto al sistema centrale il flusso dei pagamenti. | ▪ PA ▪ Altre PA ▪ Imprese |
Integrazione con Consorzio DAFNE 5per flusso Ordini e flusso Fatture Ciclo Passivo | Il servizio di integrazione avviene tramite i Web-Services del SIRAP per gli aderenti al consorzio DAFNE | ▪ Imprese |
Gestione Cessioni | Il fornitore può associare gruppi di fatture a cessioni già in essere. I documenti della cessione sono memorizzati sul SIRAP. | ▪ Imprese |
Certificazione delle Liquidazioni | Il sistema fornisce il report delle fatture liquidate, utilizzabile dai fornitori per eventuali cessioni (per esempio cessioni pro-soluto) ed in generale per certificare un credito verso la PA | ▪ Imprese ▪ PA |
Certificazione dei Pagamenti | Il sistema fornisce il report dei pagamenti ai fornitori | ▪ Imprese |
ALE
1.2.5 Tipologia di contratto
La società LAit S.p.a, ha implementato il sistema SIRAP.
1.2.6 Tipologia di benefici economici ottenuti dall’amministrazione con l’uso dell’Oggetto
🢂 Diretti :
Controllo e omogeneizzazione dei processi amministrativo contabili Controllo puntuale delle cessioni di credito:
🢂 Indiretti :
Semplificazione amministrativa:
1.2.7 Amministrazioni che riutilizzano l’Oggetto
Nessuna
1.2.8 Amministrazioni interessate al riuso dell’Oggetto
Regione Piemonte
5 Consorzio DAFNE (Distribuzione Aziende Farmaceutiche Network Edi) è l'associazione che riunisce la quasi totalità delle aziende farmaceutiche,dei distributori intermedi e depositari, ha per tema principale migliorare e rendere più efficiente la filiera del farmaco. xxxx://xxx.xxxxxxxxxxxxxx.xxx/xxx-xxxxx/
ALE
1.2.9 Amministrazioni idonee al riuso dell’Oggetto
Comuni grandi Province Regioni
Enti
Amministrazioni centrali
1.2.10 Motivazioni che indussero l’amministrazione a implementare l’Oggetto
Necessità di ridurre il debito verso i Fornitori del SSR e di effettuare un monitoraggio dei tempi di liquidazione al fine di garantire trasparenza e omogeneità di trattamento nel pagamento.
1.2.11 Costi sostenuti per l’implementazione e la manutenzione dell’Oggetto 6
▪ Costo totale dell’Oggetto, (analisi e specifica requisiti, progettazione tecnica, codifica, test e integrazione, installazione, esercizio) € 1.184.696,07
▪ Costo esterno dell’Oggetto, (componenti proprietarie utilizzate dall’Oggetto ceduto in riuso, quali, ad esempio, RDBMS, Middleware, Componenti specializzati, etc) € 366.000
▪ Costo annuo della manutenzione di cui:
Costi Manutenzione Correttiva, € 30.000
Costi Manutenzione Evolutiva, € 100.000
1.2.12 Time line del progetto
🢂 | Durata dell’intero progetto: | 48 mesi |
🢂 | Data di primo rilascio: | 01 / 2009 |
🢂 | Data di rilascio ultima evolutiva: | 02 / 2013 |
🢂 | Data di rilascio ultima correttiva: | 01 / 2013 |
1.2.13 Link al sito dove è descritto l’intero progetto che ha prodotto l’Oggetto
Pagina di accordo pagamenti: xxxx://xxx.xxxxxxx.xxxxx.xx/xx_xxxxxxxx/?xxxxxxxxxxxxXxxxxx&xxx00
1.2.14 Competenze sistemistiche e applicative richieste per l’installazione dell’Oggetto.
Sono richieste competenze nelle seguenti tecnologie:
6 Con esclusione dei costi di eventuali licenze d’uso di prodotti proprietari necessari al funzionamento dell’Oggetto
ALE
Jboss Application Server:configurazione Web-Services, certificati digitali, load balancing, definizione di risorse JNDI, deploy pacchetti EAR, configurazione del ClassLoader, configurazione cluster nodi JBoss
Networking: Gestione dei Firewall e DMZ, conoscenza SPC e RUPAR
Database: competenze tipiche DBA (creazione utenti, permessi database, backup, risoluzione deadlock e lock tabelle etc)
Sistema operativo: gestione user quota e permessi su filesystem, gestione partizioni logiche e fisiche e disk array,esecuzione/ripristino di backup periodici
Web Server Apache: configurazione reverse proxy o connettori AJP, configurazione load balacing
1.2.15 Vincoli relativi all’installazione ed alla fruizione dell’Oggetto
L’applicativo è stato installato su RDBMS Oracle, pertanto, sebbene sviluppato con librerie tali da renderlo compatibile (hibernate ORM) anche con altri RDBMS, le attività di porting verso altri RDBMS potrebbero implicare l’intervento di DB Specialist e sviluppatori Java J2EE con conoscenza di hibernate.
Il software SIRAP è integrato con i sistemi contabili di tutte le Aziende Sanitarie Pubbliche della Regione Lazio. Per realizzare tali integrazioni sono stati necessarie attività di sviluppo software localmente agli applicativi gestionali periferici. Tali attività hanno comportato costi che l’amministrazione richiedente dovrà stimare in base alla propria struttura.
1.2.16 Elementi di criticità
L’applicativo è basato su Java J2EE versione >1.5 ed è sia CPU Bound sia che I/O Bound. E’ necessario stimare con largo anticipo rispetto all’installazione, i volumi dei dati gestiti dall’istanza del SIRAP in modo da predisporre sufficiente spazio disco per il database e il file system dedicato ad ospitare i files generati durante l’esercizio.
Il software SIRAP è installato su RDBMS Oracle 10g il cui utilizzo prevede l’acquisto di licenza software. Tuttavia, il porting verso altri RDBMS è possibile.
1.2.17 Punti di forza
Riduzione delle somme per interessi di ritardato pagamento: grazie alla regolarità e continuità nel flusso di cassa per il pagamento del dovuto, i fornitori, sono disponibili a rinunciare agli interessi anche fino al 180° giorno dall’immissione della loro fattura nel SIRAP Sistema Accordo Pagamenti
Riduzione del contenzioso: l’Accordo stipulato prevede l’impegno per i fornitori, a fronte di un pagamento a 180 giorni, a non attivare procedure legali per il recupero dei crediti. I fornitori, certi della corresponsione, non cedono a società finanziarie abituate ad acquistare i crediti e successivamente ad attivare contenziosi per poi incassare gli interessi. Inoltre, il processo di comunicazione più efficiente tra fornitore ed ASL/AO, rende immediata l’informazione sulle fatture liquidate ed eventuali problematiche emerse in fase di liquidazione, consente di prevenire possibili casi di contenzioso. In particolare l’applicazione del nuovo sistema di pagamenti ha consentito alla Regione Lazio di ottenere un risparmio grazie alla rinuncia agli interessi ed all’attivazione del contenzioso.
ALE
Rilevazione di una forte discesa del DSO7 :la riduzione dei tempi di pagamento, determina vantaggi per l’Amministrazione non solo in termini di diminuzione degli interessi dovuti ai fornitori ma anche di miglioramento dei prezzi di acquisto, attraverso l’opportunità di effettuare negoziazioni a condizioni di vendita più favorevoli. Il fornitore a cui sono garantiti tempi certi e regolari di pagamento non ha più necessità di cedere ovvero è in grado di vendere il proprio credito a condizioni migliori, questo determina la possibilità di ridurre i prezzi di vendita nella misura proporzionale all’abbattimento dei costi di cessione del credito (tra il 5% ed il 10%). Nell’esperienza della Regione Lazio, a seguito dell’attuazione del nuovo Accordo Pagamenti, si è passato da 700 giorni a 204 giorni con le conseguenti stime di abbattimenti dei prezzi.
1.2.18 Livello di conoscenze/competenze ICT del personale dell’amministrazione cedente
Medio.
1.2.19 Disponibilità dell’amministrazione cedente
Erogare formazione al personale dell’amministrazione utilizzatrice
1.2.20 Modalità di riuso consigliate
Cessione semplice
7Days of Sales Outstanding
ALE
2 SEZIONE 2 – CONTESTO APPLICATIVO
2.1 Qualità globale della documentazione di progetto
2.1.1 Documentazione disponibile
Manuale di Architettura MARC. Manuale Operativo MOPE.
Documento di specifica dei requisiti e documentazione tecnica per System Integration. Piano dei test di collaudo.
Manuali utente.
2.1.2 Livello di documentazione
Buono
2.2 Requisiti
2.2.1 Specifica dei requisiti funzionali
La specifica dei requisiti funzionali: è disponibile e contiene i capitoli indicati nella tabella seguente anche se ordinati in modo diverso;
Descrizione capitolo | % |
Glossario delle definizioni e acronimi utilizzati o riferimento al glossario del progetto | 50 |
Attori coinvolti, con la specificazione del numero e della tipologia degli utenti coinvolti | 100 |
Classificazione dei requisiti funzionali | 60 |
Codifica (attributi) dei requisiti funzionali | 50 |
Correlazione alle specifiche dei casi d’uso | 50 |
Eventi coinvolti nel requisito | 10 |
Componenti hardware e Oggetto dell’architettura complessiva del sistema che si intende realizzare | 80 |
Analisi dei dati - schema concettuale iniziale | 100 |
Analisi dei dati - stima iniziale dei volumi | 80 |
Evidenza e descrizione delle modifiche in corso d’opera | 10 |
Riferimenti a ulteriore documentazione di interesse prodotta o preesistente | 10 |
2.2.2 Specifica dei requisiti non funzionali
La specifica dei requisiti non funzionali: non è disponibile.
2.2.3 Specifica dei requisiti “inversi”
La specifica dei requisiti inversi: non è disponibile.
2.2.4 Casi d’uso
La specifica dei casi d’uso correlata ai requisiti funzionali: è disponibile e i casi d’uso sono descritti secondo lo standard di modellazione UML.
ALE
3 SEZIONE 3 – CONTESTO TECNOLOGICO
3.1 Progettazione
3.1.1 Studio di fattibilità
Lo studio di fattibilità: non è disponibile.
3.1.2 Architettura logico funzionale dell’Oggetto
L’architettura logico funzionale dell’Oggetto: è disponibile, è descritta in modo discorsivo e contiene i capitoli indicati nella tabella seguente anche se ordinati in modo diverso;
Descrizione capitolo | % |
Descrizione dei sottosistemi funzionali | 80 |
Descrizione, per ciascun sottosistema, del modello logico-funzionale del Oggetto: | |
o Sottosistemi applicativi, | 100 |
o Strutture di dati e relativi attributi | 0 |
Descrizione, per ciascun sottosistema, del modello delle responsabilità funzionali (comportamento statico del sw): | |
o Classi che lo compongono, con relativi metodi e attributi | 0 |
o Casi d’uso dell’applicazione | 0 |
Descrizione, per ciascun sottosistema, del modello dei processi eseguito dal sistema/Oggetto (comportamento dinamico dell’Oggetto): | |
o Interfacce verso altri sistemi/programmi | 100 |
o Esposizione di interfacce standard di interoperabilità | 100 |
o Indipendenza delle componenti applicative utilizzate, ovvero presenza di criticità | 80 |
o Impiego di interfacce utente aderenti agli standard di usabilità | 100 |
o Indipendenza delle classi di interfaccia dal browser utilizzato | 100 |
o Indipendenza delle classi di accesso dal RDBMS utilizzato | 100 |
Descrizione, per ciascun sottosistema, del modello comportamentale (diagramma degli stati) dove sono referenziati gli eventuali riferimenti normativi delle procedure amministrative informatizzate | 0 |
🢂 Descrizione dell’architettura software
Il SIRAP può essere sinteticamente descritto come una applicazione Web che rispetta il pattern MVC, cui si aggiunge una componente per la gestione di code per l’elaborazione asincrona di dati, tutti i dati sono memorizzati su un database relazionale, i documenti generati dal sistema o introdotti dagli utenti per scopi specifici inerenti l’utilizzo del sistema SIRAP sono memorizzati su file system.
ALE
3.1.3 Architettura hardware dell’Oggetto
L’architettura hardware dell’Oggetto: è disponibile e nella descrizione sono state applicate metodologie o best practices
3.1.4 Architettura TLC dell’Oggetto
L’architettura di telecomunicazione dell’Oggetto: è disponibile e nella descrizione sono state applicate metodologie o best practices
3.2 Realizzazione
3.2.1 Manualistica disponibile
Manuale di gestione
ALE
Manuale utente
3.2.2 Case – Computer aided software engineering
Eclipse: ambiente di sviluppo integrato multi-linguaggio e multipiattaforma
iReport: è lo strumento più popolare di progettazione visiva per la libreria JasperReports e JasperReports Server. Supporta tutti i formati di output più importanti e qualsiasi fonte di dati
vi editor: è un editor di testo creato originariamente per il sistema operativo Unix
UMLet: strumento open-source per la progettazione di diagrammi UML
DbVisualizer: strumento per sviluppatori, analisti e amministratori di database. Può essere utilizzato sui principali sistemi operativi.
3.2.3 Ciclo di sviluppo
Modello incrementale
3.2.4 Standard utilizzati
Oracle Java versione > 1.5, XML, Web Services WSDL, WS-Security, Sql, JSF v 1.2
3.2.5 Linguaggio di programmazione
Oracle Java versione > 1.5
3.3 Test e collaudo
3.3.1 Specifiche dei test funzionali e non funzionali
Le specifiche dei test dell’Oggetto: sono disponibili e lo standard di documentazione garantisce un livello di dettaglio delle informazioni sufficiente a garantire la ri-esecuzione e il riscontro oggettivo dell’esito degli stessi da parte di personale diverso da chi ha progettato il test iniziale o sviluppato l’Oggetto;
3.3.2 Livello di copertura dei test rispetto ai requisiti da valutare
Al fine di valutare quantitativamente il livello di copertura dei test rispetto ai requisiti da valutare, l’amministrazione cedente fornisce le seguenti coppie di valori in suo possesso:
Numero totale di requisiti funzionali: circa 60
Numero di requisiti funzionali sottoposti a test: circa 47
Numero totale di requisiti non funzionali: n/a
Numero di requisiti non funzionali sottoposti a test: n/a
3.3.3 Piano di test;
Il piano di test dell’Oggetto: è disponibile e nella descrizione sono state applicate metodologie
o best practices, secondo standard interno LAit
ALE
3.3.4 Specifiche di collaudo
Le specifiche di collaudo dell’Oggetto: sono disponibili e nella descrizione sono state applicate metodologie o best practices, secondo standard interno LAit
3.4 Installazione, uso e manutenzione
3.4.1 Procedure di installazione e configurazione
Le procedure di installazione e configurazione dell’Oggetto: sono disponibili e nella descrizione sono state applicate metodologie o best practices, secondo standard interno LAit
3.4.2 Manuale di gestione
Il manuale di gestione dell’Oggetto: è disponibile e nella descrizione sono state applicate metodologie o best practices, secondo standard interno LAit
3.4.3 Manuale utente
Il manuale utente fornisce una descrizione generale dell’applicazione e una guida operativa all’utilizzo delle singole funzionalità dell’Oggetto utilizzabili dall’utente.
Il manuale utente dell’Oggetto: è disponibile ed è descritto in modo strutturato;
🢂 Indice del manuale utente
▪ Descrizione Sistema Accordo Pagamenti
▪ Fornitori di Beni e Servizi
▪ Indice delle Figure 1 Premessa
1.1 Fasi dell’operazione Accordi di Pagamento
1.2 Organizzazione del documento
1.3 Nota metodologica 2 Registrazione al Sistema
2.1 Anagrafica fornitore 3 Gestione Anagrafica
3.1 Modifica dati anagrafici 4 Gestione Utenti
4.1 Modifica password
4.2 Gestione dati dell’utenza
5 Manifestazione di volontà e Gestione Accordo
5.1 Accordo
5.2 Manifestazione di volontà 6 Gestione Documenti Contabili
6.1 Intestazione documento
6.2 Fornitore / Cliente
6.3 Destinazione merce / Condizioni di Trasporto
6.4 Documento di riferimento
6.5 Dettaglio Fattura / Nota di Credito
6.6 Altri Costi
6.7 Riepilogo IVA
6.8 Riepilogo Importi
ALE
6.9 Anteprima Fattura / Nota di Credito
6.10 Elenco Fatture / Note di Credito
6.11 Elenco Ordini
ALE
4 SEZIONE 4 – QUALITÀ DELL’OGGETTO
4.1 Piano di qualità
4.1.1 Contenuti del piano
Il piano di qualità dell’Oggetto: è disponibile ed nella descrizione sono state applicate metodologie o best practices, secondo standard interno LAit
4.1.2 Descrizione della qualità
Non disponibile
4.2 Profilo di qualità dell’Oggetto
Al fine di valutare quantitativamente gli attributi per la valutazione della qualità dell’Oggetto, l’amministrazione cedente fornisce i seguenti valori in suo possesso:
4.2.1 Modularità
🢂 Numero di componenti auto consistenti dell’Oggetto: 6
🢂 Numero totale di componenti dell’Oggetto: 8
4.2.2 Funzionalità
4.2.2.1 Interoperabilità - Protocolli di comunicazione
🢂 Numero dei protocolli di comunicazione dei sistemi/programmi con i quali l’applicazione deve poter colloquiare: 4
🢂 Numero dei protocolli di comunicazione correttamente implementati (ovvero che hanno superato i relativi test) all’interno dell’Oggetto: 4
4.2.3 Maturità
Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari.
4.2.3.1 Densità dei guasti durante i test
🢂 Numero di guasti rilevati durante i test: 23
🢂 Numero di casi di test eseguiti: 283
4.2.3.2 Densità dei guasti
🢂 Numero di guasti rilevati durante il primo anno di esercizio dell’Oggetto: 79
🢂 Numero totale di FP dell’Oggetto: 880
4.2.4 Usabilità
Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari.
ALE
4.2.4.1 Comprensibilità – Completezza delle descrizioni
🢂 Numero di funzioni descritte nel manuale utente: 122
🢂 Numero totale di funzioni: 271
4.2.4.2 Apprendibilità - Esecuzione delle funzioni
🢂 Numero di funzioni che sono state eseguite correttamente dall’utente consultando la documentazione: 122
🢂 Numero di funzioni provate: 122
4.2.4.3 Apprendibilità- Help on-line
🢂 Numero di funzioni per le quali l’help on-line è correttamente posizionato: 12
🢂 Numero di funzioni provate: 12
4.2.4.4 Configurabilità
🢂 Numero totale di parametri di configurazione: 18
🢂 Numero totale di funzioni: 271
4.2.5 Manutenibilità
Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari.
4.2.5.1 Conformità allo standard di Progettazione
🢂 Numero di deviazioni dagli standard di progettazione: 0
🢂 Numero dei diagrammi progettuali realizzati: 0
4.2.5.2 Conformità agli standard di codifica
🢂 Numero di deviazioni dallo standard di codifica: 0
🢂 Numero di linee di codice esaminate: 818.235
4.2.5.3 Analizzabilità - Generale
🢂 Numero totale di commenti: 239.664
🢂 Numero totale di linee di codice: 818.235
4.2.5.4 Testabilità - Generale
🢂 Numero di funzioni con associato almeno un caso di test: 122
🢂 Numero totale di funzioni elementari: 124
4.2.5.5 Testabilità - Automatismi
🢂 Numero di casi di test automatizzati con opportune funzioni di test interne: 0
🢂 Numero totale di casi di test: 30
ALE
4.2.6 Portabilità
Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari.
4.2.6.1 Adattbilità– Strutture dei dati
🢂 Numero di strutture dati trasferibili tra DB commerciali senza modifiche: 0
🢂 Numero totale strutture dati: 277
4.2.6.2 Adattabilità – Funzioni e organizzazione
🢂 Numero di funzioni indipendenti dalla organizzazione dell’amministrazione: 162
🢂 Numero totale di funzioni: 271
4.2.6.3 Installabilità - Generale
🢂 Numero di step di installazione descritti nel manuale di installazione: 5
🢂 Numero totale di step di installazione: 5
4.2.6.4 Installabilità - Automatizione delle procedure
🢂 Numero di step automatizzati descritti nel manuale di installazione: 0
🢂 Numero totale di step di installazione: 0
4.2.6.5 Installabilità - Multiambiente
🢂 Numero totale degli ambienti operativi nel quale l’Oggetto può essere installato per i quali l’Oggetto dispone di funzioni di installazione: 0
🢂 Numero totale degli ambienti operativi su cui può essere installato: 2
ALE
5 SEZIONE 5 – FORMAZIONE
5.1 Costi sostenuti per la formazione
Costo totale della formazione: € 150.000,00
Costi esterni: € 150.000,00, di cui:
🢂 Costi per i docenti € 145.000,00
🢂 Costi per il materiale didattico € 5000,00
5.2 Dati quantitativi
Numero di giorni di formazione in aula per utente erogati: 1 Numero di giorni di “training on the job” per utente erogati,: 3 Numero totale di utenti formati 715
Numero totale di dipendenti dell’ufficio o sezione o area o direzione o dipartimento o ASL/AO utilizzatori dell’Oggetto descritto nella presente scheda 115
5.3 Descrizione dell’azione formativa
Il corso fornisce le informazioni utili alla comprensione ed utilizzo del SIRAP . I destinatari del corso sono:
▪ le Aziende Sanitarie;
▪ il Personale Regionale.
▪ I referenti delle singole imprese.
Per accedere a tale corso è necessario che l’utente disponga di un livello medio di conoscenze informatiche: utilizzo browser Internet (Internet Explorer o equivalente),utilizzo programma posta elettronica (MS-Outlook o equivalente), utilizzo programma per la visualizzazione di fogli di calcolo (MS-Excel o equivalente) .
Le aule dovranno essere attrezzate con almeno un PC, ed eventualmente un proiettore.
La formazione in aula comprensiva di materiale didattico si articolerà in due moduli di cui: un di corso di formazione e un corso di formazione “training on the job”.
L’obiettivo dei moduli è quello di fornire:
▪ le competenze necessarie all’utilizzo del SIRAP.
▪ la capacità di applicare le conoscenze apprese in modo da svolgere le proprie attività lavorative con un'adeguata professionalità.
▪ gli strumenti di base e concettuali per l’analisi delle problematiche operative di gestione e di amministrazione tipiche delle ASL/AO.
5.4 Materiale didattico
Per la predisposizione del materiale didattico:
▪ sono stati descritti i profili utente dell’applicativo;
ALE
▪ sono stati descritti i profili di competenza necessari;
▪ sono stati definiti gli elementi per stimare il gap di competenze esistente;
▪ sono stati forniti gli elementi per individuare gli utenti critici dal punto di vista delle necessità formative.