PROCEDURA APERTA PER L’ACQUISIZIONE DI UNA PIATTAFORMA APPLICATIVA SOFTWARE E DI SERVIZI CORRELATI PER LA GESTIONE INFORMATIZZATA DELL’AREA AMMINISTRATIVA CONTABILE DELLE AZIENDE SANITARIE DELLA REGIONE EMILIA ROMAGNA

PROCEDURA APERTA PER L’ACQUISIZIONE DI UNA PIATTAFORMA APPLICATIVA SOFTWARE E DI SERVIZI CORRELATI PER LA GESTIONE INFORMATIZZATA DELL’AREA AMMINISTRATIVA CONTABILE DELLE AZIENDE SANITARIE DELLA REGIONE XXXXXX XXXXXXX

ALLEGATO 4 CAPITOLATO TECNICO

INDICE

1. PREMESSA 4

2. CONTESTO ATTUALE DI RIFERIMENTO 4

3. OGGETTO DELL'APPALTO 5

4. CARATTERISTICHE DELLA FORNITURA 7

4.1 Requisiti della piattaforma applicativa software e dell’impianto tecnologico 7

4.2 Requisiti di competenza professionale per l’erogazione dei servizi 7

5. MODALITÁ DI ESECUZIONE DELLA FORNITURA 8

5.1 Configurazione e Installazione del sistema GAAC 9

5.2 Deployment e Attivazione del sistema GAAC 10

5.3 Gestione del sistema GAAC 11

5.4 Implementazione evolutiva del sistema GAAC 13

5.5 Modalità di rendicontazione e remunerazione della fornitura 15

6. PROPRIETÀ DEL CODICE SVILUPPATO NELLA FORNITURA 15

7. QUALITA’ E LIVELLI DEI SERVIZI 15

8. PENALI 17

9. GLOSSARIO 18

ALLEGATO A 20

Requisiti funzionali della piattaforma applicativa software GAAC per la gestione informatizzata dell’Area Amministrativo Contabile delle aziende sanitarie della Regione Xxxxxx – Romagna 20

a) Requisiti Funzionali 20

b) Infrastruttura Applicativa – Funzionalità di base - Integrazioni 23

1. GESTIONE ANAGRAFICA 24

2. CONTABILITA’ ANALITICA 30

3. GESTIONE CESPITI E INVENTARIO 32

4. CONTABILITA’ GENERALE 41

5. GESTIONE MAGAZZINI E SERVIZI 58

6. GESTIONE REGIONALE DEI DATI 66

7. INTEGRAZIONI 69

ALLEGATO B 72

Requisiti tecnologici dell’impianto HW/SW di base e di ambiente necessario per il corretto funzionamento del sistema GAAC a livello Regionale 72

1. Hardware necessario al funzionamento dell’applicazione 72

2. Distribuzione hardware 72

3. Gradualità della fornitura hardware 73

4. Business Continuity, Sistema di Backup e Disaster recovery 73

5. Sistema per la gestione di basi di dati 74

6. Livelli prestazionali 74

7. Monitoraggio 74

ALLEGATO C 76

Competenze e Figure professionali per l’erogazione dei servizi necessari all’implementazione e alla gestione del sistema GAAC 76

ALLEGATO D 79

INDICAZIONI PER CAPITOLATO GAAC - PARER 79

ALLEGATO E 83

Applicativi in uso presso le Aziende Sanitarie e principali integrazioni richieste a valenza aziendale 83

1. PREMESSA

La Regione per finalità di programmazione e controllo e le Aziende Sanitarie, compresa la Gestione Sanitaria Accentrata (GSA) per finalità gestionali operative, hanno evidenziato la necessità di poter disporre di un sistema unitario per la Gestione informatizzata dell’Area Amministrativa Contabile (in seguito anche solo GAAC), escluso l’ambito Risorse Umane, delle Aziende Sanitarie della Regione Xxxxxx Xxxxxxx, in linea con l’aggiornamento normativo e gli standard che le nuove tecnologie raccomandano. Il sistema dovrà garantire le necessarie autonomie aziendali e, al tempo stesso, consentire la realizzazione di sinergie gestionali, a livello sovra aziendale, assicurando, a livello regionale, i necessari strumenti di controllo e programmazione.

Inoltre, il sistema dovrà garantire la gestione dei processi amministrativi-contabili e supportare le Aziende nelle attività finalizzate alla certificabilità dei bilanci delle Aziende Sanitarie, compresa la Gestione Sanitaria Accentrata (GSA), così come previsto dal Percorso Attuativo della Certificabilità (PAC) approvato dalla Regione Xxxxxx Xxxxxxx con DGR 865/2013 e ss.mm.ii.

Ai sensi dell’art. 22 del D.Lgs. 118/2011 le Regioni che esercitano la scelta di gestire direttamente una quota del finanziamento del proprio servizio sanitario individuano nella propria struttura organizzativa uno specifico centro di responsabilità, denominato “Gestione Sanitaria Accentrata - GSA”, deputato all’implementazione ed alla tenuta di una contabilità di tipo economico- patrimoniale atta a rilevare, in maniera sistematica e continuativa, i rapporti economici, patrimoniali e finanziari intercorrenti fra la singola regione e lo Stato, le altre regioni, le aziende sanitarie, gli altri enti pubblici ed i terzi vari, inerenti le operazioni finanziate con risorse destinate ai rispettivi servizi sanitari regionali.

A tale fine la Regione Xxxxxx-Romagna con deliberazione della Giunta regionale n. 900/2012 ha individuato, in seno alla Direzione Generale Sanità e Politiche Sociali e per l’Integrazione uno specifico centro di responsabilità nell’ambito del Servizio “Programmazione Economico- Finanziaria” ora “Amministrazione del Servizio Sanitario Regionale, Sociale e Socio-Sanitario” per lo svolgimento della funzione denominata “Gestione Sanitaria Accentrata”(GSA).

2. CONTESTO ATTUALE DI RIFERIMENTO

Xxxxxx xx 00 Xxxxxxx xxxxxxxxx xxxxx Xxxxxxx Xxxxxx-Xxxxxxx attualmente sono in uso circa 15 applicativi, afferenti a circa 10 fornitori, per la gestione informatizzata dell’Area Amministrativa Contabile delle Aziende Sanitarie della Regione Xxxxxx Xxxxxxx.

I prodotti presentano una copertura diversificata in merito ai vari ambiti funzionali sviluppati nel corso degli anni dalle singole Aziende.

L’interazione dei sistemi di gestione dell’Area Amministrativa Contabile delle Aziende Sanitarie della Regione Xxxxxx Xxxxxxx con altri sistemi aziendali, nel loro complesso, avviene mediante l’utilizzo di moduli di integrazione e/o di cooperazione applicativa.

L’eterogeneità e il livello di personalizzazione degli attuali sistemi rende difficoltoso l’implementazione di regole operative omogenee ed il conseguente governo degli stessi.

Il numero di operatori che utilizzano il sistema informatizzato per la gestione dell’Area Amministrativa Contabile, a livello regionale, è pari a circa 700 unità. Tale numero configura l’utenza complessiva del sistema GAAC in tutti gli ambiti gestionali.

CONTESTO OPERATIVO AREA AMMINISTRATIVA CONTABILE
Dimensione operativa dei sistemi informatici aziendali – Esercizio 2015
AMBITO OPERATIVO	Q.tà
Contabilità fornitori e professionisti
Numero fatture passive	815.000
Numero medio di pagamenti	1.000.000
Contabilità clienti
Numero di incassi elaborati	160.000
Numero fatture attive	750.000
Acquisti
Numero ordini	530.000
Numero medio di bolle	700.000
Numero medio di righe per bolla	4
Magazzini
Numero di magazzini	300
Numero totale di articoli di magazzino	100.000
Cespiti
Numero di cespiti	1.500.000
Numero nuovi cespiti all’anno	50.000
Numero dismissioni	20.000
Contabilità analitica
Numero di centri di costo	20.000
Numero fattori produttivi	10.000
Dati storici
Numero di anni in linea	15

3. OGGETTO DELL'APPALTO

La presente procedura di gara ha per finalità l’acquisizione di prodotti software e servizi correlati per la realizzazione di un sistema unitario per la Gestione informatizzata dell’Area Amministrativa Contabile delle Aziende Sanitarie della Regione Xxxxxx Xxxxxxx.

Il sistema GAAC dovrà comprendere in modo esaustivo le componenti infrastrutturali della piattaforma applicativa, l’infrastruttura tecnologica Hardware e Software di base/ambiente necessaria per il suo funzionamento nonché i servizi di assistenza e supporto correlati.

La piattaforma applicativa dovrà consentire la gestione di tutta la normativa in essere e in divenire e dovrà comprendere le necessarie evoluzioni per l’adempimento alle linee di indirizzo nazionali e alle disposizioni regionali in materia.

L’oggetto della gara riguarda l’acquisizione di:

• un sistema software per il GAAC, completo di tutte le funzioni richieste nel capitolato, con il numero di licenze necessario per l’attivazione di un numero illimitato di postazioni operatore a copertura delle esigenze espresse, da tutte le Aziende Sanitarie della Regione Xxxxxx Xxxxxxx.

• un sistema nel formato “codici sorgenti” denominato GAAC in modo da garantire l’applicazione della formula del “riuso” secondo le indicazioni della normativa. Dopo il collaudo, pertanto, il fornitore deve depositare presso il committente l’intero codice sorgente del sistema incluse tutte le documentazioni e le specifiche tecniche, affinché possa essere garantita alle Aziende Sanitarie della Regione Xxxxxx Xxxxxxx la gestione autonoma e indipendente dal fornitore del sistema acquisito.

• sorgenti che rimarranno di proprietà del committente. Il fornitore rimane ovviamente a sua volta proprietario dei sorgenti e libero di commercializzare il prodotto finale autonomamente senza alcun vincolo.

• un impianto informatico Hardware e le licenze d’uso del relativo Software di base e di ambiente

• servizi di assistenza e consulenza informatica con requisiti di specifica competenza ed esperienza professionale maturata nell’ambito “gestione area amministrativa contabile” dei sistemi informativi delle aziende sanitarie pubbliche.

I servizi di assistenza, analisi e supporto informatici dovranno garantire le competenze e le risorse professionali per lo svolgimento delle seguenti attività:

Ø Configurazione del modello funzionale del sistema GAAC e della relativa banca dati a livello aziendale/sovraziendale/regionale/ministeriale

Ø Configurazione del modello tecnologico e architetturale dell’impianto informatico Hardware e software di base/ambiente

Ø Installazione e parametrizzazione del sistema

Ø Attivazione e Deployment Ø Formazione e avviamento Ø Assistenza e manutenzione Ø Implementazione evolutiva

L’articolazione e la modulazione dei servizi che il fornitore configurerà nella proposta tecnica ed economica dovranno garantire i termini di seguito riportati:

Entro un massimo di 6 mesi dall’avvio dei lavori: configurazione dell’architettura tecnologica/applicativa/banca dati del sistema “Gestione informatizzata dell’Area Amministrativa Contabile”, installazione e pre-collaudo del sistema su un ambiente di simulazione.

Entro il 31 dicembre 2017: configurazione del sistema, collaudi e attivazione del 1°gruppo di Aziende che dovranno entrare in esercizio il 1/1/2018 (vedi dettaglio aziende nel capitolo 5)

Entro il 30 giugno 2018: configurazione del sistema, collaudi e attivazione del 2°gruppo di Aziende che dovranno entrare in esercizio il 1/7/2018 (vedi dettaglio aziende nel capitolo 5)

Entro il 31 dicembre 2018: configurazione del sistema, collaudi e attivazione del 3° gruppo di Aziende e del GSA che dovranno entrare in esercizio il 1/1/2019 (vedi dettaglio aziende nel capitolo 5)

Dal 1 gennaio 2018: erogazione dei servizi di gestione del sistema per il 1° gruppo Dal 1 luglio 2018: erogazione dei servizi di gestione del sistema per il 1° e il 2° gruppo

Dal 1 gennaio 2019: erogazione dei servizi di gestione del sistema per il 1°, 2°, 3° gruppo e

GSA

Dal 1 gennaio 2019: erogazione dei servizi di implementazione evolutiva (tecnologica,strutturale e funzionale).

4. CARATTERISTICHE DELLA FORNITURA

La fornitura oggetto della procedura di gara dovrà garantire i seguenti requisiti minimi:

4.1 Requisiti della piattaforma applicativa software e dell’impianto tecnologico

L’infrastruttura applicativa e tecnologica del sistema GAAC dovrà essere realizzata in coerenza con i requisiti riportati nei documenti di seguito elencati:

- “Requisiti funzionali della piattaforma applicativa software GAAC per la gestione informatizzata dell’Area Amministrativa Contabile delle aziende sanitarie della Regione Xxxxxx-Romagna” (Allegato A del presente Capitolato Tecnico)

- “Requisiti tecnologici dell’impianto HW/SW di base e di ambiente necessario per il corretto funzionamento del sistema GAAC a livello Regionale” (Allegato B del presente Capitolato Tecnico)

4.2 Requisiti di competenza professionale per l’erogazione dei servizi

I servizi di assistenza analisi e supporto informatici necessari all’implementazione e alla gestione del sistema GAAC, dovranno rispondere a requisiti di specifica competenza ed esperienza professionale maturata nell’ambito “gestione dell’Area Amministrativa Contabile” dei sistemi informativi delle aziende sanitarie pubbliche, secondo un’articolazione di figure professionali così come definite nel documento “Competenze e Figure professionali per l’erogazione dei servizi necessari all’implementazione e alla gestione del sistema GAAC” (Allegato C del presente Capitolato Tecnico).

I servizi dovranno essere erogati coerentemente alle fasi attuative e gestionali del sistema GAAC caratterizzate da un’ampia articolazione di attività afferenti alla configurazione del

modello funzionale/dati, alla parametrizzazione del sistema, all’avviamento, alla formazione, alla manutenzione, all’assistenza agli utenti.

5. MODALITÁ DI ESECUZIONE DELLA FORNITURA

Il fornitore dovrà definire una Proposta di Piano Esecutivo (di seguito anche solo “P.E.”) articolato secondo le seguenti fasi di implementazione:

• Configurazione e Installazione del modello funzionale/dati e dell’impianto tecnologico del sistema GAAC

• Deployment e Attivazione delle singole aziende secondo il seguente ordine:

Collaudo e Messa in esercizio al 1 Gennaio 2018 del 1° Gruppo: AUSL di Bologna, AOSP di Bologna, IOR, AUSL Imola, AUSL di Ferrara e AOSP di Ferrara;

Collaudo e Messa in esercizio al 1 Luglio 2018 del 2° Gruppo: AUSL della Romagna;

Collaudo e Messa in esercizio al 1 Gennaio 2019 del 3° Gruppo: AUSL Piacenza, AUSL Parma, AOSP Parma, AUSL Reggio Xxxxxx, AOSP Reggio Xxxxxx, AUSL Modena, AOSP Modena, GSA.

• Gestione

• Implementazione evolutiva

Il P.E. dovrà comprendere la pianificazione, la dimensione di effort e le tempistiche delle macro attività riferite alle varie fasi di implementazione del sistema nonché la composizione del gruppo di lavoro impegnato nella singola fase. Il P.E. dovrà essere riportato nella proposta tecnico/economica che il Fornitore presenterà in risposta al presente capitolato e lo stesso costituirà riferimento per il Piano Esecutivo Validato che verrà definito congiuntamente con la Committenza sulla base degli impegni temporali e dimensionali riportati nel P.E.. Si precisa che la definizione del Piano Esecutivo Validato, in esito a valutazioni di carattere tecnico ed organizzativo mirate al perfezionamento del processo di deployment, potrà subire variazioni rispetto all’ordine di attivazione delle aziende sopra riportato.

L’attuazione del Piano Esecutivo Validato avrà inizio in esito alla approvazione del DEC, nominato dalla Committenza.

Le risorse che verranno impiegate nelle attività devono avere i requisiti di professionalità richiesti dalla Committenza che si riserva la facoltà di ricusare detto personale per giustificati motivi e di verificare in via preventiva le competenze tecnico-professionali del personale specialistico proposto.

La Committenza istituirà un Tavolo di Coordinamento e Governo GAAC (di seguito anche solo “Tavolo GAAC”) che avrà in carico il coordinamento e il governo dei lavori di implementazione e di gestione del sistema, con particolare riferimento a quanto indicato nei punti 5.1, 5.2, 5.3,

5.4 del presente Capitolato tecnico. Il Tavolo GAAC sarà composto da:

- DEC, che avrà, in particolare, il compito di supervisionare quanto progressivamente prodotto dal fornitore, verificandone la coerenza con i requisiti e le specifiche stabilite;

- referenti regionali (RER);

- referenti aziendali GAAC;

- referenti aziendali ICT.

Il Tavolo GAAC potrà convocare il fornitore in supporto all’espletamento delle attività di propria competenza, con particolare riferimento a:

- Il capo progetto;

- Il referente per la consulenza sui processi amministrativi;

- Il referente per la consulenza ICT;

- Le figure professionali competenti in funzione delle tematiche da approfondire.

La partecipazione del fornitore agli incontri del Tavolo GAAC dovrà essere, comunque, garantita ad ogni evenienza di emanazioni di nuove normative nazionali e regionali.

Di seguito si riporta l’articolazione delle fasi del P.E. con i relativi servizi richiesti.

5.1Configurazione e Installazione del sistema GAAC

Il Fornitore dovrà garantire i servizi di:

• Project management

• Analisi del contesto e dei bisogni relativamente alle singole aziende e alla regione

• Configurazione del modello architetturale del sistema applicativo della relativa struttura di banca dati a livello aziendale/sovraziendale/regionale (nel rispetto dei requisiti indicati negli Allegati A e B del presente Capitolato Tecnico)

• Configurazione del modello tecnologico e architetturale dell’impianto informatico HW/SW di base a livello aziendale/regionale (nel rispetto dei requisiti indicati nell’ Allegato B del presente Capitolato Tecnico)

• Definizione degli strumenti e delle modalità di migrazione dai sistemi attuali verso il nuovo sistema

• Installazione dell’impianto tecnologico HW/SW di base e di ambiente

• Installazione e Parametrizzazione della piattaforma applicativa software GAAC

• Test funzionale e prestazionale del sistema GAAC su un ambiente di simulazione aziendale e sovraziendale

La fase di configurazione e installazione, di cui sopra, sarà effettuata con la supervisione del Tavolo GAAC, del Project Manager e del Direttore Esecuzione del Contratto, la validazione del positivo completamento di tale fase sarà in esito al test funzionale e prestazionale del sistema in ambiente di simulazione e costituirà il Precollaudo del sistema GAAC. L’esito favorevole del precollaudo costituirà altresì prerequisito fondamentale per il rilascio del sistema in produzione ovvero per il collaudo del sistema in esercizio presso le singole aziende, come previsto nella

fase “Deployment e Attivazione del sistema GAAC”. Con il precollaudo sarà verificata la conformità tecnica, funzionale e prestazionale dell’impianto hardware, software di base/ambiente e applicativo del sistema GAAC nonché delle integrazioni previste verso altri sistemi. Il processo di precollaudo dovrà riscontrare piena rispondenza alle specifiche previste nel presente capitolato nonché nella proposta del fornitore aggiudicatario.

I servizi di gestione afferente all’impianto HW/SW, comprensivi di manutenzione, assistenza e supporto dovranno essere forniti a totale cura e spese del fornitore per tutto il periodo di garanzia stabilito in 24 mesi dalla data di precollaudo.

Con l’installazione del sistema dovrà essere rilasciata la documentazione tecnica di realizzazione, di installazione/parametrizzazione e della manualistica per l’utilizzo del sistema e per l’amministrazione dello stesso.

5.2Deployment e Attivazione del sistema GAAC

Il Fornitore dovrà garantire i servizi di:

- Project management

- Formazione all’utenza delle singole aziende

- Attivazione dell’impianto tecnologico HW/SW di base/ambiente afferente alle singole aziende

- Parametrizzazione e Attivazione del software applicativo GAAC afferente alle singole aziende

- Migrazione archivi pregressi

- Attivazione del sistema in contesto di produzione sulle singole aziende

- Assistenza e supporto

necessari a mettere in produzione il sistema GAAC e permetterne l’utilizzo da parte di tutte le Aziende a livello regionale garantendo le tempistiche di installazione e attivazione che verranno definite nel Piano Esecutivo Validato.

Per ogni attivazione e messa in esercizio del sistema nelle singole Aziende, sarà eseguito il relativo collaudo per verificarne il completo e il buon funzionamento attraverso il pieno utilizzo da parte dell’utenza per un periodo di osservazione comprendente la fase di formazione e avviamento.

I collaudi di cui sopra, afferenti alle singole aziende, pertanto costituiranno riferimento per la rendicontazione economica.

Il Fornitore dovrà garantire i servizi di formazione e assistenza all’avviamento all’utenza del sistema GAAC, sia a livello Aziendale che Regionale, e al personale tecnico/informatico delle Aziende. Dovrà essere predisposto un piano di formazione continuativo che permetta a tutto il personale coinvolto la completa conoscenza delle funzionalità offerte dal software e delle evoluzioni che lo stesso potrà subire.

Inoltre dovrà essere fornito il manuale operativo del sistema, continuamente aggiornato con tutte le evoluzioni, fruibile on line con la sequenza delle operazioni per i più importanti casi d’uso, comprensivo della guida interattiva e che permetta all’operatore di poter formulare e condividere le domande più frequenti.

In particolare il fornitore dovrà garantire l’attuazione di piani che prevedono le attivazioni contemporanee indicate nel capitolo 3, definendo per ogni Azienda un calendario delle attività e delle relative figure professionali assegnate tenendo conto dell’articolazione e della dimensione dell'organizzazione, nonché della minimizzazione di eventuali disservizi nelle singole Aziende.

In questa fase il fornitore dovrà garantire servizi per la migrazione, verso il nuovo sistema GAAC, degli archivi attualmente in uso da parte dei sistemi in esercizio presso le Aziende ed adeguate modalità di recupero dati.

I rapporti tecnico/economici, finalizzati alla migrazione del sistema, con gli attuali fornitori saranno in carico alla Committenza.

Al termine del contratto, la ditta fornitrice dovrà farsi carico di eseguire le eventuali operazioni atte a rendere disponibili tutti i dati e i documenti/immagini presenti negli archivi del sistema realizzato.

Inoltre, a completamento della fase di deployment e attivazione del sistema GAAC, l’aggiudicatario della gara dovrà fornire un documento in cui siano esplicitate le operazioni necessarie a consentire l’importazione dei dati in un diverso sistema ed una stima del tempo necessario ad eseguire tali operazioni allo scadere del contratto.

Si precisa che l’onere relativo a tale attività è incluso nei costi della fornitura e nessun altro costo od onere potrà essere richiesto o imputato alle Aziende e alla Regione.

La fase di deployment e attivazione sarà effettuata con la supervisione del Tavolo GAAC e del Direttore Esecuzione del Contratto (DEC).

5.3Gestione del sistema GAAC

Il Fornitore dovrà garantire i servizi di:

- Formazione e ripresa formativa all’utenza del sistema GAAC e al personale tecnico informatico delle aziende

- Manutenzione infrastruttura applicativa del sistema GAAC

- Manutenzione infrastruttura tecnologica del sistema GAAC

- Assistenza e supporto all’utenza del sistema GAAC e al personale tecnico informatico delle aziende

La gestione del sistema avrà inizio contestualmente al collaudo in produzione relativo alle singole aziende.

Il Fornitore dovrà garantire i servizi di formazione e ripresa formativa verso l’utenza del sistema GAAC e del personale tecnico/informatico sia a livello regionale che aziendale, a tal fine dovrà essere predisposto un piano di formazione che permetta a tutto il personale coinvolto il mantenimento di una adeguata e completa conoscenza delle funzionalità offerte dal sistema e delle evoluzioni che lo stesso potrà subire.

Il Fornitore dovrà assicurare, dalla data di precollaudo che attesta il positivo completamento della fase di “Configurazione e installazione del sistema GAAC”, i servizi di gestione relativi all’impianto HW/SW; in particolare dovrà garantire la manutenzione correttiva e perfettiva dell’infrastruttura tecnologica costituita da:

o Hardware (tutte le componenti oggetto di fornitura)

o Software di base

o Software di ambiente

Il Fornitore dovrà assicurare, dalla data di collaudo che attesta il positivo completamento dell’attivazione del sistema GAAC presso le singole aziende, i servizi di gestione relativi all’infrastruttura applicativa; in particolare dovrà garantire la manutenzione correttiva e perfettiva della piattaforma applicativa costituita da:

o Moduli applicativi

o Moduli di integrazione e di cooperazione applicativa

Per manutenzione correttiva si intende la diagnosi e la rimozione delle cause e degli effetti, sia sulle interfacce utente che sulle basi dati, dei malfunzionamenti delle procedure e dei programmi in esercizio, nonché di tutte le componenti hardware facenti parte del sistema oggetto di acquisizione.

La manutenzione correttiva è normalmente innescata da una segnalazione di impedimento all’esecuzione dell’applicazione/funzione o dal riscontro di differenze fra l’effettivo funzionamento del software applicativo e quello atteso, come previsto dalla relativa documentazione di configurazione e attivazione del sistema o comunque determinato dai controlli che vengono svolti durante l’attività dell’utente. La manutenzione correttiva è innescata altresì da segnalazioni di malfunzionamento relative al sistema hardware e al sistema software di base e di ambiente.

Sono parte del servizio le seguenti attività:

• la presa in carico delle segnalazioni ricevute da sistemi di rilevazione automatica segnalati dagli utenti;

• l’individuazione della componente in errore;

• l’attuazione di interventi di work around atti a minimizzare l’interruzione del servizio;

• lo sviluppo, la verifica e il rilascio della fix risolutiva, quest’ultimo nell’ambiente di esercizio;

• la predisposizione della documentazione necessaria per l’installazione;

• ripristino basi dati difettate dall’errore;

• modifica della documentazione di progetto qualora venisse riscontrata un’incoerenza con il software applicativo rilasciato.

Per manutenzione perfettiva si intende il perfezionamento del sistema rivolto a garantire le performance e la manutenibilità del sistema.

Il servizio dovrà comprendere inoltre la manutenzione adeguativa che dovrà garantire tutte le attività di adeguamento dell’infrastruttura applicativa ai cambiamenti normativi di livello ministeriale e regionale. La manutenzione adeguativa non varia la consistenza del parco applicativo del prodotto iniziale. Eventuali interventi di manutenzione adeguativa che dovessero

richiedere variazioni strutturali significative della banca dati potranno essere valutati come manutenzione evolutiva.

Il Fornitore dovrà garantire Assistenza e supporto all’utenza mediante un servizio di Help Desk.

Tale servizio viene attivato, indicativamente:

• dagli utenti, con particolare riferimento a richieste sul funzionamento del sistema e la segnalazione di malfunzionamenti dello stesso

• dal personale tecnico informatico delle aziende soprattutto per problematiche afferenti ad aspetti tecnici e/o particolarmente complessi

• dal personale aziendale referente del sistema GAAC per problematiche a valenza aziendale o sovra aziendale

Il servizio di Help Desk deve garantire la presa in carico delle chiamate, la loro gestione e risoluzione entro gli SLA (Service level agreement) previsti, sia che si tratti di interventi di manutenzione del software, sia che si tratti di interventi di supporto.

Gli operatori assegnati al Servizio devono gestire le chiamate e le relative problematiche intervenendo via remota sulle postazioni del chiamante con strumenti di tele-assistenza.

Il Servizio dovrà garantire una puntuale registrazione delle chiamate di assistenza per una tracciatura delle stesse e per una consuntivazione dell'attività svolta nonché la rilevazione dei livelli di servizio al fine del controllo degli SLA contrattualizzati, delle eventuali inadempienze e della relativa applicazione delle penali.

Al fine della valutazione dei livelli di servizio il fornitore deve presentare, su base mensile, una reportistica, con allegata una relazione sintetica sulle criticità riscontrate e sulle proposte di recupero delle stesse. Inoltre il fornitore dovrà garantire una reportistica più dettagliata a supporto dell'analisi delle criticità o dell'attività.

Il servizio dovrà essere garantito tutti i giorni feriali e prefestivi nelle seguenti fasce orarie:

Dal Lunedì al Venerdì 8,30 – 17,30 e il Sabato dalle 8,30 – 13,30 dovrà essere garantito l’accesso al call center telefonico, alla posta elettronica e al portale per la gestione del ticketing. Inoltre si richiede un servizio di pronta disponibilità telefonica da remoto per manutenzione tecnica per il modulo di gestione magazzini/logistica dal Lunedì al Venerdì dalle 6,00 alle 8,30 e dalle 17,30 alle 22,00 e il Sabato dalle 6,00 alle 8,30 e dalle 13,30 alle 22,00.

La Gestione del Sistema e il relativo monitoraggio dei livelli di servizio sarà effettuata con la supervisione del Tavolo GAAC e del Project Manager.

5.4 Implementazione evolutiva del sistema GAAC

Il Fornitore dovrà garantire i servizi di:

- Project management

- Analisi

- Progettazione

- Implementazione software

- Deployment

- Formazione all’utenza e al personale tecnico informatico

- Assistenza e Manutenzione

per la realizzazione e l’attivazione di implementazioni evolutive del sistema GAAC.

Il fornitore dovrà fornire i servizi garantendo adeguate tempistiche per la produzione dell’analisi e dell’offerta economica in relazione alle singole richieste.

Rientrano in tale servizio gli interventi volti ad arricchire il prodotto (di nuove funzionalità o di altre caratteristiche non funzionali, quali l’usabilità, livello prestazionale, ecc.) o comunque a modificare o integrare le funzionalità del prodotto. Tale manutenzione implica la scrittura di funzioni aggiuntive d’integrazione a sistemi informativi o applicazioni esistenti o parti di funzioni (anche in sostituzione di altre già esistenti) di dimensione significativa e di cui è possibile preventivamente definire i requisiti o quantomeno identificare le esigenze.

In pratica si tratta di implementazioni che modificano la consistenza del parco applicativo del prodotto iniziale.

I prodotti sviluppati dovranno essere manutenuti per l’intera durata del contratto e pertanto l’onere economico relativo alla manutenzione correttiva sarà compreso nei costi relativi all’intervento di implementazione evolutiva.

Le richieste di implementazione evolutiva saranno attivate secondo il seguente schema generale:

- richiesta di implementazione evolutiva da parte della Committenza;

- presentazione dell’offerta da parte del Fornitore contenente la precisazione della tempistica, la data di consegna concordata, le figure professionali e le modalità di impiego e la dimensione del lavoro necessario;

- accettazione dell’offerta da parte della Committenza;

- realizzazione dell’implementazione;

- collaudo;

- validazione collaudo.

Il fornitore dovrà garantire, entro 3 giorni lavorativi, la presa in carico della richiesta di implementazione evolutiva e far pervenire per iscritto, entro 10 giorni lavorativi dall’avvenuta richiesta, previo eventuale incontro tecnico di approfondimento ed analisi, la proposta tecnica e la relativa valutazione in giornate lavoro e/o esprimendo un valore forfettario per la realizzazione dell’implementazione richiesta.

Nella proposta tecnico/economica, il fornitore dovrà esplicitare la tempistica e la modalità di realizzazione degli interventi evolutivi e la relativa messa in esercizio.

Inoltre, il fornitore dovrà garantire un ambiente di test accessibile agli utenti, allo scopo di collaudare tutti i nuovi rilasci e aggiornato con periodicità mensile.

5.5Modalità di rendicontazione e remunerazione della fornitura

Il Fornitore dovrà rendicontare, secondo le modalità indicate nello schema di Convenzione, lo Stato di Avanzamento Lavori in rapporto al Piano Esecutivo Validato definito con la Committenza sia per quanto attiene alle attività svolte che per la componente economica.

La rendicontazione economica avverrà, trascorso il periodo di garanzia, secondo quanto indicato nello Schema di Convenzione.

La rendicontazione economica afferente all’Implementazione Evolutiva del sistema GAAC avverrà in esito al collaudo dei singoli interventi e secondo quanto indicato nello Schema di Convenzione.

La validazione della rendicontazione e la relativa fatturazione avverrà in esito alla approvazione del DEC.

6. PROPRIETÀ DEL CODICE SVILUPPATO NELLA FORNITURA

Il software sviluppato nell’ambito della presente fornitura, relativamente a componenti esterne e autonome dalla piattaforma applicativa, sarà di proprietà del committente che si riserva di avvalersene secondo quanto previsto dalla normativa relativa al “riuso di programmi informatici” del Codice sull’Amministrazione Digitale (CAD art. 68).

Qualora lo sviluppo in oggetto preveda componenti software disponibili in modalità open source, il fornitore dovrà attestare l’applicabilità della licenza open nell’ambito del sistema oggetto di realizzazione.

7. QUALITA’ E LIVELLI DEI SERVIZI

Il Fornitore dovrà presentare un Piano di Qualità con cui intende assicurare la qualità della fornitura.

Il Piano dovrà essere corredato da una proposta metodologica nella quale sia evidenziato l’approccio che si intende utilizzare per la fornitura, i servizi di avviamento e di manutenzione, integrazione, conversione dei dati e messa in esercizio.

Il Fornitore dovrà impegnarsi ad erogare i servizi nel rispetto degli indicatori sotto elencati, finalizzati a garantire la qualità di caratteristiche critiche della fornitura.

Il Fornitore si impegna a fornire alla Committenza, con la periodicità prevista dai diversi indicatori, opportuna reportistica atta ad individuare il rispetto degli SLA.

Affidabilità della esecuzione della fornitura – rispetto del Piano Esecutivo

In riferimento al Piano Esecutivo che il Fornitore presenterà nella proposta tecnica verrà misurato il ritardo di attuazione relativo alle fasi di Configurazione e Deployment.

Il valore dell’indicatore di tempo di ritardo della fase (TRF), sarà calcolato sulla base delle settimane di ritardo delle tempistiche effettive di completamento rispetto a quelle previste nel Piano Esecutivo Validato. Quest’ultimo sarà congiuntamente definito con la

Committenza in coerenza con il Piano Esecutivo Proposto sulla base dei termini presentati in offerta dal Fornitore.

TRFc = N. settimane ritardo fase “Configurazione” TRFd = N. settimane ritardo fase “Deployment”

Efficienza del servizio di help desk - presa in carico della richiesta di assistenza

Verrà misurato il tempo che intercorre tra l’assegnazione della richiesta da parte degli utenti delle Aziende e la presa in carico da parte dell’help desk. Il valore soglia dell’indicatore di tempo di presa in carico della richiesta (TCR), nell’arco di un trimestre non dovrà essere inferiore ai valori riportati nella seguente tabella

Gravità dell’Errore	Tipologia Errore	Tempo max di presa in carico	Valore soglia di TCR
1	L’intero sistema è indisponibile agli utenti	30 minuti lavorativi	99%
	(anche di una singola azienda)	60 minuti lavorativi	100%
2	Almeno una delle funzionalità critiche del sistema sono indisponibili agli utenti (anche di una sola azienda)	1 ora lavorativa	95%
3	Le funzionalità non critiche del sistema sono indisponibili agli utenti (anche di una sola azienda)	6 ore lavorative	95%
4	Le funzionalità non critiche del sistema sono indisponibili, senza impatto sulla operatività degli utenti	8 ore lavorative	95%

Il valore dell’indicatore TCR è calcolato secondo la formula seguente:

TCR = RC/RRT*100

dove: RC = numero richieste prese in carico entro il tempo max nel periodo di osservazione

RRT = numero richieste ricevute nel periodo di osservazione.

Efficienza del sevizio di manutenzione – rimozione degli errori/malfunzionamenti

Il sistema software GAAC in esercizio verrà sottoposto al monitoraggio degli errori segnalati al fine di rilevare l’efficienza del Fornitore nella rimozione degli errori presi in carico.

Verrà misurato il tempo che intercorre tra la presa in carico del problema da parte del servizio di manutenzione e la risoluzione dello stesso. Il valore soglia dell’indicatore di

tempo di risoluzione dell’errore (TRE) nell’arco di un trimestre non dovrà essere inferiore ai valori riportati nella seguente tabella.

Gravità dell’ Errore	Tipologia Errore	Tempo max di risoluzione	Valore soglia di TRE
1	L’intero sistema è indisponibile agli utenti (anche di una singola azienda)	- 4h lavorative	95%
2	Almeno una delle funzionalità critiche del sistema sono indisponibili agli utenti (anche di una singola azienda)	- 8h lavorative - 4h lavorative per il modulo magazzini/logistica	95%
3	Le funzionalità non critiche del sistema sono indisponibili agli utenti (anche di una singola azienda)	2 giorni lavorativi	95%
4	Le funzionalità non critiche del sistema sono indisponibili, senza impatto sulla operatività degli utenti	5 giorni lavorativi	95%

Il valore dell’indicatore TRE è calcolato secondo la formula seguente:

TRE = RR/RSC*100

dove: RR = numero di richieste risolte entro il tempo max di risoluzione nel periodo di osservazione

RSC = numero delle richieste prese in carico nel periodo di osservazione.

Nel caso la risoluzione dell’errore preveda necessariamente il coinvolgimento di terze parti, il tempo di risoluzione si ferma dal momento dell’apertura del ticket nei confronti di queste e riprende dal momento in cui il problema viene da esse risolto. Resta compito del Fornitore effettuare gli opportuni solleciti nei confronti della terza parte, e mantenere aggiornate le informazioni relative sul sistema di ticketing.

8. PENALI

La Committenza effettuerà verifiche finalizzate a monitorare/controllare gli SLA previsti al capitolo precedente ed in generale le modalità di fornitura dei servizi. Qualora venissero riscontrate inadempienze rispetto al valore degli indicatori e dei livelli di servizio richiesto, la Committenza, nel rispetto delle norme vigenti e secondo le condizioni, le modalità, i termini e le prescrizioni contenute nel presente capitolato, potrà richiedere l’applicazione delle penali nelle modalità indicate allo schema di convenzione.

9. GLOSSARIO

ACRONIMO	DESCRIZIONE
AFO	Assistenza Farmaceutica Ospedaliera
AIC	Autorizzazione all'Immissione in Commercio
ARA	Anagrafe Regionale Assistiti
ASP	Aziende di Servizi alla Persona
ATC	Sistema di classificazione Anatomico Terapeutico e Chimico
AVEC	Area Xxxxx Xxxxxx Centro
AVEN	Area Vasta Xxxxxx Xxxx
CDC	Centro di Costo
CDR	Centro di Responsabilità
CE	Conto Economico
CIG	Codice Identificativo di Gara
CIVAB	Centro di Informazione e Valutazione delle Apparecchiature Biomediche
CMG	Consumo Medio Giornaliero
CND	Classificazione Nazionale Dispositivi medici
COA01	Modello Regionale Costi, Ricavi e FRNA
COAN	Contabilità Analitica
COGE	Contabilità Generale
Conti/Voci FR	Si tratta di conti specifici dedicati al Fondo Regionale della non Autosufficienza
Conti/Voci R	Si tratta di conti specifici dedicati agli scambi tra Aziende Sanitarie della Regione
Conti/Voci RR	Si tratta di conti specifici dedicati agli scambi tra Aziende Sanitarie e Regione
Conti/Voci S	Si tratta di conti specifici dedicati alla mobilità interregionale
CP	Costi Presidio
CUF	Commissione Unica del Farmaco
CUP	Codice Unico di Progetto
DDD	Defined Daily Dose - Dose Giornaliera Definita
DDT	Documento Di Trasporto
DEC	Direttore Esecuzione del Contratto
DIME	Dispositivi Medici
DURC	Documento Unico di Regolarità Contributiva
FED	Farmaci ad Erogazione Diretta
FEFO	First Expired, First Out (Il primo in scadenza è il primo a uscire)
FRNA	Fondo Regionale della Non Autosufficienza
GAAC	Gestione informatizzata dell'Area Amministrativa Contabile
GSA	Gestione Sanitaria Accentrata
GSA	Gestione Sanitaria Accentrata
LA	Modello Ministeriale Livelli di Assistenza di cui al DM 16/02/2001
LIFR	Line Item Fill Rate
MEF	Ministero Economia e Finanze
MINSAN	Ministeriale Sanitario
NSIS	Nuovo Sistema Informativo Sanitario
OFR	Order Fill Rate
OSCO	Ospedale di Comunità
PARIX	Piattaforma di Accesso al Registro Imprese in formato Xml
PCC	Piattaforma Certificazione dei Crediti
PE	Piano Esecutivo

RC	Richieste prese in Carico
RdA	Richiesta di Acquisto
RDM	Repertorio Dispositivi Medici
ROP	Reorder Point - Punto di Riordino
RR	Xxxxxxxxx Xxxxxxx
RRT	Richieste Ricevute nel periodo di osservazione
RSC	Richieste prese in carico nel periodo di osservazione
RUDI	Rete Unificate Di Incasso
RUF	Registro Unico Fatture
SIOPE	Sistema Informativo sulle Operazioni degli Enti Pubblici
SITAR	Servizio Informativo Telematico Appalti Regionale
SLA	Service Level Agreement
SM	Scorta Minima
SP	Stato Patrimoniale
TCR	Tempo presa in Carico della Richiesta
TRE	Tempo Risoluzione dell'Errore
TRF	Tempo di Ritardo della Fase

ALLEGATO A

Requisiti funzionali della piattaforma applicativa software GAAC per la gestione informatizzata dell’Area Amministrativo Contabile delle aziende sanitarie della Regione Xxxxxx – Romagna

a) Requisiti Funzionali

La fornitura deve prevedere la realizzazione di un sistema unitario per la gestione informatizzata dell’Area Amministrativa Contabile delle Aziende Sanitarie della Regione Xxxxxx Xxxxxxx. Il sistema proposto deve comprendere in modo esaustivo le componenti infrastrutturali della piattaforma applicativa, l’infrastruttura tecnologica Hardware/Software necessaria per il suo funzionamento nonché i servizi di assistenza e supporto correlati.

La piattaforma software applicativa deve prevedere soluzioni tali da garantire tutti gli aspetti funzionali caratteristici afferenti il dominio dell’Area Amministrativa Contabile.

Devono essere considerati inoltre come parte integrante della fornitura:

• l’integrazione software con le procedure in uso presso l’Azienda al fine della corretta gestione del completo patrimonio informativo dell’Area Amministrativa Contabile;

• l’interoperabilità con gli Enti esterni coinvolti;

• il piano di formazione continua del personale per l’utilizzo dell’applicativo;

• il servizio di assistenza all’esercizio del sistema;

• il sistema di reporting generalizzato e di export dei dati, anche attraverso l'utilizzo dei sw di query reporting già in uso nelle Aziende.

Per quanto riguarda il recupero dello storico, il sistema deve garantire l’avviamento della migrazione dello storico necessario per la gestione dei processi alla data di avvio.

A titolo esemplificativo, dovrà, quindi, essere garantita la migrazione dello storico come segue:

1. Contabilità analitica:

• Piano dei centri di costo;

• Piano dei fattori produttivi;

• Movimenti ultimo anno (almeno come saldi per mese, centro di costo e fattore produttivo).

2. Gestione cespiti e inventario:

Anagrafiche, movimenti e schede tecniche relative a cespiti in vita al 31/12 dell’esercizio precedente a quello di avvio, indipendentemente dalla loro natura (proprietà, di terzi) e anagrafiche attributi collegate.

3. Contabilità generale:

• Anagrafiche movimentate nell’ultimo anno e anagrafiche collegate;

• Saldi di chiusura anno precedente che consenta un’operazione di apertura corretta;

• Partite aperte con i relativi movimenti di chiusura e apertura di bilancio.

4. Gestione dei magazzini:

• Anagrafiche beni e servizi movimentati negli ultimi 2 anni;

• Bolle e relativi ordini non collegate a fattura;

• Contratti in essere con la disponibilità del magazzino;

• Consumi ultimo anno (per garantire il calcolo delle proposte di riordino);

• Rimanenze iniziali valorizzate a prezzo medio ponderato.

5. Gestione dati regionali:

• Anagrafiche dei piani di codifica ultimi 3 anni;

• Dati contabili per conto economico e patrimoniale regionale e aziendale ultimi 3 anni.

Con riferimento all’Azienda USL della Romagna, il cui avvio è previsto in corso d’anno, oltre agli elementi sopra descritti, il sistema dovrà garantire un recupero dello storico dei dati riferiti al primo semestre dell’anno necessari a garantire la gestione di tutti i processi nell’unico sistema amministrativo contabile GAAC con riferimento a tutto l’anno. A titolo esemplificativo e non esaustivo, il sistema dovrà consentire:

• le operazioni di chiusura del bilancio d’esercizio nell’unico sistema;

• l’elaborazione di report completi delle informazioni di tutto l’anno (per esempio crediti, debiti, saldo apertura all’01/01/2018, movimenti dell’anno);

• la corretta valorizzazione delle rimanenze al costo medio ponderato;

• le elaborazioni del COA e del modello LA;

• la corretta gestione dei sostituti d’imposta;

• il trasferimento delle partite aperte al 01/07/2018 e di quelle chiuse nel periodo dal 01/01/2018 al 30/06/2018.

In particolare, il sistema deve garantire, nel rispetto della normativa vigente, delle disposizioni contrattuali e delle linee di indirizzo della Regione Xxxxxx Xxxxxxx:

• la gestione dei processi amministrativi – contabili ritenuti necessari ai fini della certificabilità dei bilanci;

• la gestione di processi autorizzativi secondo le modalità ritenute necessarie dalla singola organizzazione.

• la gestione dell’autenticazione forte e della firma digitale nei casi ritenuti necessari dalla normativa vigente.

Il sistema deve rendere disponibili le informazioni gestite al fine di assicurare la loro integrazione con gli applicativi software di pertinenza di dominio regionale e di dominio aziendale.

E’ fondamentale che gli utenti di tale sistema possano operare in modo efficiente anche nell’ipotesi di aggregazione di aziende. La fornitura deve inoltre comprendere una costante attività di supporto alla Regione ed ai Servizi Gestione dell’Area Amministrativa Contabile delle Aziende Sanitarie per l’aggiornamento giuridico-normativo delle procedure automatizzate di Gestione dell’Area Amministrativa Contabile.

Il sistema deve, infine, rendere disponibile alla Regione Xxxxxx-Romagna i dati registrati dalle singole Aziende sanitarie, con ampia possibilità di effettuare elaborazioni e analisi propedeutiche ad azioni programmatorie e strategiche.

Il sistema proposto deve rispondere ai seguenti requisiti:

1) Multi istanza di applicazione che operi in un unico impianto anagrafico in cui siano uniformate tutte le informazioni.

2) Dovrà essere possibile introdurre appositi sistemi di validazione che permettano di gestire il processo di aggiornamento delle anagrafiche.

3) Dovrà essere previsto una funzionalità che permetta lo scambio di comunicazioni tra gli utenti registrati a sistema.

4) Standardizzazione a livello regionale delle informazioni raccolte e un’omogenea analisi e valutazione dei dati, tramite l’adozione di codifiche uniche per tutte le aziende sanitarie, su tutte le aree, con possibilità di esplosione in maggior dettaglio nella singola azienda sanitaria. Pertanto, le tabelle di configurazione del sistema devono essere gestite in modalità centralizzata.

5) Storicizzazione: le informazioni devono essere storicizzate per ciascuna registrazione con opportune date di validità; deve essere garantito il mantenimento in linea di tutti i dati storici relativi a tutte le aree previste e la loro fruibilità.

6) Impostazione web-based per il sistema della piattaforma informatizzata GAAC; in tale impostazione deve essere garantita la compatibilità ed il corretto funzionamento dell’applicazione con i più diffusi browser (Internet Explorer, Safari, Chrome, Firefox); saranno valutate positivamente soluzioni che prevedano anche l’utilizzo di tecnologie mobile e per le quali non è necessario installare componenti software nelle postazioni di lavoro.

7) Il fornitore dovrà farsi carico dell’infrastruttura di dominio, Active Directory / LDAP o similari, con relazioni di trust che consentano l’interoperabilità coi domini delle singole aziende. L'applicazione dovrà essere compatibile con il protocollo di autenticazione SAML 2.0, implementando le funzionalità di Service Provider secondo le specifiche definite dal progetto FedERa (xxxx://xxxxxx.xxxxxx.xx) e del progetto SPID (xxxx://xxx.xxxx.xxx.xx).

8) Multi sessione di lavoro disponibile per singolo accesso, operando eventualmente su aziende differenti con le necessarie abilitazioni.

9) Automatismi di sistema tali da guidare l’operatore nel corretto/completo inserimento dei dati. Il sistema dovrà, inoltre, prevedere blocchi logici e controlli automatici atti ad impedire l’inserimento di informazioni errate, non congruenti o non consistenti.

10) Garanzia, in fase di avviamento, della migrazione dei dati dai sistemi attuali verso il nuovo sistema.

11) Audit/log: il sistema deve essere altamente configurabile, prevedendo la possibilità di tracciare (chi ha fatto, che cosa e quando) in qualsiasi momento tutto ciò che riguarda ogni dato gestito e deve essere in grado di produrre warning specifici (al minimo con le seguenti modalità: con messaggistica interna all’applicativo, con report e via email) su operazioni ritenute critiche.

12) Il sistema, oltre a disporre di report operativi accessibili a tutti gli utenti per le attività di gestione corrente, deve essere dotato di uno strumento di reportistica standardizzata e dinamica in base alla quale sia possibile interrogare la banca dati ai vari livelli (aziendale, sovraziendale, regionale, ministeriale), mediante criteri di selezione multipla e scelta delle variabili da riprodurre sul report con possibilità di export su differenti formati (tra cui txt, ods, cvs, xlsx, xml, pdf); la produzione dei report deve avvenire in maniera semplice e selezionabile dall’operatore che deve poter definire la struttura del report. I report operativi previsti nell’offerta dovranno essere integrati secondo le esigenze manifestate entro la messa in produzione del 1° gruppo.

13) Il sistema deve prevedere la possibilità di caricare in formato digitale (es. pdf, jpg) qualsiasi documento utile all’Azienda e collegarlo a movimenti/documenti/anagrafiche ecc.. ad essi correlati (es. planimetrie, visure, foto, schede tecniche).

14) Il software applicativo deve prevedere adeguati sistemi di controllo degli accessi quali ad esempio l’implementazione di avanzati sistemi di profilatura degli utenti, con autorizzazione/abilitazione sulle funzionalità e sui dati da gestire.

15) Il sistema deve prevedere l’integrazione con software applicativi già esistenti presso le Aziende Sanitare che soddisfano esigenze amministrativo contabili come per esempio la gestione dei magazzini di reparto, conto deposito, WMS, gestione manutenzioni ecc…

16) Il sistema deve garantire l’elaborazione, la gestione, la produzione e la trasmissione (ove prevista) dei flussi definiti nei moduli seguenti prevedendo la gestione delle fasi di validazione e comunque tutti quelli previsti dalla normativa vigente.

17) Gli adeguamenti del software alla normativa vigente e ai regolamenti derivanti dai cambiamenti normativi dovranno essere garantiti e realizzati senza oneri aggiuntivi per le Aziende Contraenti, nel rispetto delle tempistiche utili alla operatività della Aziende Contraenti.

18) Il sistema oggetto di fornitura dovrà permettere la registrazione di tutte le informazioni necessarie per la pubblicazione sui portali aziendali (attraverso modalità interoperabili) dei dati previsti dalla normativa "amministrazione trasparente" (Dlgs 33/2013 e ss.mm.ii.).

19) Il sistema dovrà prevedere la possibilità di gestire workflow di approvazione (ad esempio per i processi di approvvigionamento: dalla creazione delle anagrafiche, alla richiesta informatizzata di reparto, dalla preparazione del materiale in magazzino alla predisposizione degli ordini a fornitore) configurabili anche con la possibilità di richiedere informazioni in sezioni specifiche.

20) Il sistema deve garantire gli strumenti necessari per l’invio in conservazione presso il ParER di tutti i documenti informatici prodotti e ricevuti.

b) Infrastruttura Applicativa – Funzionalità di base - Integrazioni

Il sistema GAAC deve prevedere la gestione dei seguenti moduli:

1. Gestione anagrafica

2. Contabilità analitica

3. Gestione cespiti e inventario

4. Contabilità generale

5. Gestione magazzini e servizi

6. Gestione regionale dei dati

7. Integrazioni

In particolare, l’inserimento di un dato deve avvenire una sola volta nel “modulo” di pertinenza e valere anche per gli altri, assicurando unicità e correttezza (es. in fase di gestione di una fattura deve essere possibile passare direttamente al modulo cespiti piuttosto che al modulo magazzino). Si riportano di seguito i contenuti informativi minimi e i requisiti che i diversi moduli funzionali debbono assicurare.

1. GESTIONE ANAGRAFICA

Il sistema deve prevedere la gestione delle anagrafiche a livello centralizzato, consentendo di gestire un’unica anagrafica a valenza regionale con possibilità di gestire ulteriori informazioni di dettaglio a valenza aziendale (es referente territoriale fornitore, modalità di pagamento, codice piano dei conti, fattori produttivi).

Tutte le anagrafiche devono prevedere la possibilità di una gestione parametrizzabile degli attributi, prevedendo eventuali obbligatorietà e/o controlli sulla valorizzazione delle informazioni presenti.

La gestione di profili di utenze (da master a successive autorizzazioni) dovrà essere effettuata per permettere la corretta gestione del processo di creazione ed aggiornamento dei codici.

Di seguito vengono elencate le principali anagrafiche gestite dal sistema.

1.1 PIANI DI CODIFICA CONTABILITA’ ANALITICA

Il sistema deve:

A. consentire la creazione e la gestione di un piano dei centri di costo/ricavo e dei fattori produttivi e di altre aggregazioni gerarchiche utili alle Aziende, non preimpostate e vincolanti;

B. consentire la definizione strutturata delle proprietà dei cdc (es classificazione dei cdc finale, intermedio, comune);

C. prevedere un piano dei centri di costo/ricavo unico a livello ministeriale e regionale, limitatamente ai centri costo/ricavo finali, con possibilità di gestire ulteriori livello di dettaglio a valenza aziendale riconducibili comunque all’unico livello regionale;

D. prevedere un piano dei fattori produttivi unico a livello regionale, con possibilità di gestire ulteriori livelli di dettaglio a valenza aziendale riconducibili comunque all’unico livello regionale, nonché il collegamento all’anagrafica dei conti economici aziendali, regionali, ministeriali (presente nel modulo di contabilità generale);

E. prevedere un iter di creazione, validazione, aggiornamento e comunicazione delle codifiche ai vari livelli ministeriale, regionale e aziendale secondo le modalità previste al paragrafo 1.8;

F. gestire le anagrafiche storicizzate dei centri di costo/ricavo e dei fattori produttivi aziendali, regionali e ministeriali ed eventuali ulteriori riclassificazioni;

G. garantire, per ogni fattore produttivo e centro di costo la registrazione della data di chiusura e l’individuazione dell’eventuale cdc erede;

H. gestire, in modo storicizzato, diversi sistemi di riclassificazione, tra cui obbligatoriamente:

• riclassificazione regionale dei centri di costo per modello COA01 e LA;

• riclassificazione regionale dei fattori produttivi.

I. prevedere l’aggregazione a diversi livelli di dettaglio per tutti i sistemi di codifica;

J. prevedere aggregazioni temporanee di fattori produttivi e centri di costo per valorizzare “temporanei” oggetti di costo;

K. prevedere altre “dimensioni” di specificazione analitica dei movimenti, diverse dal centro di costo e dal fattore produttivo, propedeutiche all’impostazione di un modello di controllo più raffinato (adatto al supporto ad esempio della riorganizzazione per intensità di cura, alle rilevazioni per i progetti di ricerca/commesse, ecc);

L. prevedere apposite modalità per la gestione delle anagrafiche dei fattori produttivi e dei centri di costo, e, in particolare, dei legami e delle correlazioni funzionali con altri sistemi di codifica e classificazione, ad esempio unità di prelievo di magazzino (vedi punto 1.7);

1.2 ANAGRAFICA DEL CESPITE

L’anagrafica del cespite deve consentire la completa identificazione del bene e la gestione completa della storia e delle modifiche avvenute a partire dalla data di acquisizione.

Il sistema deve:

A. prevedere che ad ogni cespite sia associato, fra gli altri:

• numero di inventario;

• descrizione del bene;

• codice “CIVAB” (classe regionale di tecnologia, produttore, modello) per riconoscimento della gran parte delle tecnologie biomediche presenti sul mercato nazionale utilizzabile in tutto il processo di acquisto e di gestione di tali beni e sottoclasse;

• codifica “CND” (Classificazione Nazionale Dispositivi medici)

• repertorio dispositivi medici

• tipo repertorio

• codice del centro di costo consegnatario e descrizione;

• consegnatario e sub consegnatario del bene;

• produttore (Ragione sociale, Codice Fiscale, Partita IVA, Sede Legale);

• modello;

• numero di matricola o telaio;

• tipo di bene (principale, accessorio o componente);

• bene principale (se si tratta di bene accessorio o componente o manutenzione);

• dati catastali delle singole unità immobiliari;

• identificazione beni dell’Azienda presso terzi: comodato, donazione, affitto/locazione, leasing, riscatto, service, noleggio;

• identificazione dei beni di terzi in godimento;

• quantità, ossia la consistenza numerica dei beni che costituiscono universalità;

• codice fiscale e ragione sociale fornitore;

• n. e data del documento di trasporto;

• n. e data dell’ordine di acquisto;

• data della fattura d'acquisto;

• numero della fattura d'acquisto;

• numero e data di protocollo della fattura;

• data della consegna;

• data di installazione;

• data di collaudo;

• data termine garanzia;

• data di inizio utilizzo del bene (data di avvio della procedura di ammortamento);

• valore originario o valore attribuito;

• fonti di finanziamento;

• aliquota di ammortamento (civile e fiscale);

• assoggettamento o meno all’ammortamento (per le donazioni – valore soggetto ad ammortamento - ed i beni non di proprietà - valore non soggetto ad ammortamento);

• stato di conservazione, con particolare riferimento alle tecnologie biomediche (es. buono, discreto, usurato, pessimo);

• causa e data fuori uso;

• stato del cespite (acquisito, produttivo, dismesso, alienato);

• scheda contabile (categoria fiscale, classificazione, conto patrimoniale, descrizione conto patrimoniale, costo storico, ammortamento, sterilizzazione, fondo ammortamento, valore netto contabile);

• tipo di bilancio: Sanitario, Sociale o Commerciale;

• luogo fisico della collocazione del bene (ubicazione o dislocazione);

• altre informazioni (campi per note specifiche);

B. permettere la duplicazione dell’anagrafica di un cespite e/o dell’anagrafica con documenti collegati (D.D.T. e Ordine di acquisto) da utilizzare come modello per altri inserimenti, oltre

a prevedere anche una funzione di rinomina/modifica singola o massiva dell’anagrafica cespite;

C. consentire - tramite la gestione di parametri e variabili da impostare sulle classi dei cespiti o sul singolo cespite - di evitare la duplicazione non necessaria dei dati anagrafici;

D. permettere la diversificazione dei beni per tipologie diverse, ad esempio: beni istituzionali e beni commerciali (a loro volta suddivisibili per registro di acquisto);

E. permettere la classificazione definita nel regolamento aziendale della gestione dei cespiti: attrezzature sanitarie, attrezzature informatiche, etc;

F. gestire l’anagrafica delle fonte di finanziamento per investimenti unica a livello regionale, con possibilità di dettaglio a valenza aziendale riconducibili comunque all’unico livello regionale (ogni Azienda sanitaria può descrivere le fonti autonomamente).

1.3 PIANO DEI CONTI CONTABILITA’ GENERALE

Il sistema deve:

A. prevedere un Piano dei Conti Aziendale unico a livello ministeriale, regionale, con possibilità di gestire ulteriori livelli di dettaglio a valenza aziendale riconducibili comunque all’unico livello regionale;

B. prevedere la possibilità di gestire il Piano dei Conti anche da parte di un solo utente master qualora i dati concernenti le codifiche siano condivise tra più Aziende Sanitarie che utilizzano l’applicativo; dovrà quindi essere opportunamente proceduralizzato l’iter per l’inserimento di nuove codifiche di conti per assicurare la sollecita compilazione di tutti i codici correlati;

C. prevedere la possibilità di identificare i conti del Piano dei Conti relativi ai rapporti di scambio tra Aziende Sanitarie della Regione (conti R); relativi al Fondo Regionale della Non Autosufficienza ecc.. a livello regionale automaticamente declinati sul livello aziendale;

D. prevedere un iter di creazione, validazione, aggiornamento e comunicazione delle codifiche ai vari livelli ministeriale, regionale e aziendale secondo le modalità previste al paragrafo 1.8;

E. prevedere il raccordo tra piano dei conti e piano dei fattori produttivi e di ricavo della CO-AN secondo un rapporto 1:1 o 1:n.;

F. garantire, mediante apposite tabelle di correlazione, la corretta alimentazione dei conti. In particolare la previsione di una tendenziale estensione della procedura ordini alla globalità dei fattori di produzione relativi a beni, servizi e immobilizzazioni, dovrà consentire di stabilire univoci legami fra articolo, gruppo o classe merceologica, fattore produttivo, conto economico o patrimoniale, centro di costo e, per i ricavi, fra attività o prodotto, gruppo o classe, fattore di ricavo, conto di ricavo e relativi centri di costo associati. Si chiede la seguente correlazione:

Prodotti/attività à Gruppo/classeà Fattore produttivoà Conto economico/Conto patrimoniale

che dovrà garantire l’attribuzione dei conti di Contabilità Generale (economici o patrimoniali) nella fase di immissione dell’ordine e/o del documento di ricevimento, successivamente, all’atto della registrazione della fattura. In particolare per le fatture con ordine, la correlazione fra articolo, conto economico o conto patrimoniale consentirà di automatizzare la registrazione di prima nota in quanto tutte le informazioni necessarie sono disponibili nel sistema;

G. prevedere la possibilità di gestire le tabelle di correlazione anche da parte di un solo utente master qualora i dati concernenti le codifiche siano condivise tra più Aziende Sanitarie che utilizzano l’applicativo; dovrà quindi essere opportunamente proceduralizzato l’iter per l’inserimento di nuove codifiche di articoli o attività/prodotti per assicurare la sollecita compilazione di tutti i codici correlati;

H. consentire l'abbinamento del Conto al Centro di Costo o ai Centri di Costo, su cui il costo o ricavo può essere ripartito.

1.4 ANAGRAFICA CLIENTI E FORNITORI

Il sistema deve:

A. gestire un’anagrafica unica centralizzata che contenga tutti i soggetti in modo univoco, considerando che il medesimo soggetto può essere sia fornitore che cliente, prevedendo la possibilità di alimentare le informazioni di dettaglio specifiche differenziando per le singole aziende (parametrizzazione delle informazioni utili);

B. prevedere il controllo bloccante per l’inserimento di una nuova anagrafica per un codice fiscale già presente;

C. prevedere l’acquisizione dei dati dei fornitori/clienti tramite l’integrazione con il sistema PARIX;

D. prevedere l’acquisizione dei dati degli assistiti tramite l’integrazione con l’ARA (Anagrafe Regionale Assistiti) per il popolamento dell’anagrafica fornitori/clienti;

E. prevedere una specifica funzionalità da attribuire ad utenti master che permetta di intervenire sulla gestione delle anagrafiche sia a livello centrale che aziendale;

F. garantire la gestione per singolo cliente e fornitore di differenti sedi, divisioni, ecc.. che consenta una gestione dell’emissione e trasmissione delle fatture attive, della registrazione e pagamento delle fatture passive;

G. garantire la gestione dei depositari e dei rappresentanti di zona/funzione;

H. gestire gli stati del fornitore (per esempio aperto, chiuso, bloccato …..);

I. prevedere parametri legati alla modalità di trasmissione e gli indirizzi prioritari per ogni tipo di comunicazione.

In particolare, per quanto riguarda i fornitori soggetti a ritenuta d’acconto, il sistema deve:

A. prevedere il controllo automatico del codice fiscale a partire dai dati fondamentali (data e luogo di nascita, ecc…);

B. gestire i campi per la compilazione del modello di Certificazione Unica e modello 770 ai sensi della normativa vigente quali a titolo esemplificativo e non esaustivo:

• dati del sostituto d’imposta;

• dati del percipiente;

• dati riservati ai percipienti esteri (es. "codice identificazione fiscale estero" e "codice stato estero")

• tipologia reddituale;

• dati fiscali (es. “somme soggette”, “somme non soggette”, “contributi previdenziali a carico percipiente”, “contributi previdenziali a carico del soggetto erogante ” ecc..);

C. gestire, per ciascun libero professionista, il tipo di regime fiscale scelto dal lavoratore (ordinario, agevolato, semplificato, contribuente minimo, prestazione occasionale superiore o inferiore ad euro 5.000.00, ecc.) e la data della relativa dichiarazione rilasciata dal soggetto;

D. gestire il calcolo dei contributi previdenziali a carico percipiente e dei contributi previdenziali a carico del soggetto erogante e dell’IRAP qualora dovuti;

1.5 ANAGRAFICA BENI E SERVIZI

Gli attribuiti associati all’anagrafica dei bene e servizi dovranno essere articolati e conformi a diverse tipologie tra cui farmaci, dispositivi medici, altri beni, servizi e prestazioni ed utilizzabili sia nell’ambito del ciclo attivo che passivo.

Il sistema proposto dovrà prevedere gli attributi necessari per la gestione dei beni e servizi e per la gestione dei relativi listini al fine di garantire un’adeguata operatività. Il sistema dovrà prevedere la possibilità di acquisire in modalità interoperabile i listini messi a disposizione dalla piattaforma di e- procurement di IntercentER con l’indicazione della validità temporale.

Inoltre, il sistema dovrà mettere a disposizione le funzionalità per la gestione di listini di vendita storicizzati che prevedano l’utilizzo di algoritmi differenti per il perfezionamento degli stessi.

Dovrà essere possibile anche gestire codici generici che rappresentano gerarchicamente i codici superiori ai codici di dettaglio prodotto. I singoli codici di dettaglio prodotto dovranno poter essere associati ai codici generici.

Ad es. dovrà poter essere creato il codice generico pannolone da 5 kg con elastico a cui verrà associato il codice specifico pannolone da 5 kg con elastico della marca XY. Tale associazione dovrà essere gestita dal software in modo coerente ad una corretta analisi dei fabbisogni di magazzino, sia in fase di picking e distribuzione di magazzino, così come in fase di richiesta da reparto.

L’anagrafica dei beni e servizi deve prevedere i seguenti attributi (a titolo esemplificativo e non esaustivo):

• descrizione anagrafica;

• codice prodotto;

• descrizione articolo;

• classificazione merceologica a mezzo codici alfanumerici;

• categoria;

• descrizione sintetica ed estesa;

• codice di collegamento fornitore;

• codice prodotto fornitore;

• produttore;

• codice prodotto produttore;

• unità di misura (conf. Pezzi n., eccetera);

• quantità di pezzi per confezione (per unità di misura);

• quantità di pezzi per imballo primario;

• quantità di pezzi per imballo secondario;

• quantità di pezzi per pallet;

• peso singola confezione;

• dimensioni singola confezione;

• peso imballo secondario;

• volume imballo secondario;

• temperatura di conservazione;

• indicazione fascia di alto costo;

• indicazione di prodotto emoderivato;

• indicazione di prodotto salvavita;

• indicazione di prodotto antiblastico;

• indicazione di sostanza tossica/velenosa;

• indicazione di stupefacente;

• classificazione fattore produttivo;

• classificazione conto economico;

• indicazione se bene inventariabile;

• prezzo anno in corso (ultimo acquisto indipendentemente dal magazzino);

• aliquota IVA;

• chiavi di ricerca o sinonimi;

• classificazione regionale;

• attributo barcode importabile da banca dati esterna;

• obsoleto (per i prodotti fuori produzione e/o ritirati);

• collegamento alle schede tecniche della banche dati esistenti.

• rilevanza ai fini IRES

Inoltre, considerando i farmaci devono essere previste anche le seguenti informazioni, eventualmente acquisibili da fonti dati esterne (per le quali potrebbe essere utile acquisire la chiave di raccordo):

• ATC

• AIC

• principio attivo

• forma farmaceutica

• riferimento legislativo per gli stupefacenti

• riferimento al Prontuario Terapeutico Regionale/Aziendale

• codice regionale (per esteri)

• note CUF (importabili da banca dati esterna)

• categoria di erogabilità (es. fascia A, fascia H, fascia C)

• via di somministrazione

• DDD.

mentre per i dispositivi medici le seguenti:

• CND

• CIVAB

• codice di repertorio (Numero di RDM) e distinzione DM1/DM2

• riferimento RADM Aziendale

• tipo dispositivo (Di classe, Assemblato o Nullo)

1.6 ANAGRAFICA SOGGETTI EROGATORI

Il sistema deve gestire le informazioni inerenti i soggetti erogatori per la corretta emissione delle fatture attive nel rispetto della normativa vigente, con particolare riferimento all’attività erogata in regime di libera professione.

1.7 ANAGRAFICHE UNITÀ DI PRELIEVO E LUOGO DI CONSEGNA

Per quanto attiene all’Anagrafica Unità di prelievo, ciascun codice dovrà disporre delle seguenti informazioni:

A. Codice identificativo univoco che deve essere collegato ad un centro di costo;

B. Descrizione;

C. Tipo di struttura;

D. Xxxxxx e descrizione Luogo di consegna (vedi anagrafica specifica).

Per quanto attiene, invece, all’Anagrafica Luogo di consegna, ciascun codice dovrà disporre delle seguenti informazioni:

A. Codice identificativo univoco;

B. Descrizione;

C. Indirizzo (via, Comune, Provincia, padiglione, piano, ecc…)

1.8 PIANI DI CODIFICA REGIONALI

Il sistema deve garantire la gestione centralizzata da parte del livello regionale delle seguenti codifiche:

• Piano dei conti;

• Piano dei fattori produttivi;

• Piano dei centri di costo.

Il sistema deve garantire:

A. la gestione dell’anagrafica dei piani di codifica unici a livello ministeriale, regionale e dell’ulteriore livello aziendale. Si riportano di seguito a titolo esemplificativo e non esaustivo alcuni elementi necessari per la gestione delle codifiche:

• codice ministeriale;

• codice regionale;

• codice aziendale;

• descrizione su tutti i livelli;

• raccordo tra i vari livelli secondo un rapporto tra livello ministeriale e regionale 1:1 o 1:n e secondo un ulteriore rapporto tra il livello regionale e aziendale 1:1 o 1:n.

• possibilità di identificare le codifiche con tipologie di interesse regionale e ministeriale quali per esempio: voci (R) e voci (RR) per scambi fra aziende e aziende sanitarie e GSA; voci

(S) per mobilità extra-regionale; voci (FR) per Fondo Regionale della non Autosufficienza ecc…

B. l’apertura dei nuovi codici unici;

C. l’acquisizione automatica, attraverso opportune operazioni di validazione, dei nuovi codici definiti a livello regionale nel sistema informativo da parte di tutte le Aziende Sanitarie;

D. l’acquisizione automatica, da parte del livello regionale, della richiesta di creazione o modifica degli ulteriori livelli di dettaglio a valenza aziendale;

E. la validazione informatizzata da parte del livello regionale delle operazioni di cui al punto D;

F. l’attribuzione di un codice provvisorio nel caso in cui le Aziende Sanitarie necessitano di un nuovo codice in tempo reale prevedendo l’aggiornamento su tutto il sistema a seguito della validazione Regionale e in particolare nel caso in cui l’esito della validazione non sia positivo, l’aggiornamento della nuova codifica deve essere garantito automaticamente.

2. CONTABILITA’ ANALITICA

2.1. PREMESSA

Il modulo di contabilità analitica deve consentire l’acquisizione, l’aggregazione, l’elaborazione e l’esposizione dei dati elementari di costo, ricavo e stato patrimoniale (in relazione alle Immobilizzazioni), organizzati per fattore produttivo e centro di costo, necessari per il governo dell’Azienda e per il soddisfacimento dei debiti informativi interni (macrostrutture, dipartimenti e unità operative) ed esterni (Ministero della Salute, Regione, Enti locali,…).

Il sistema dovrà mettere a disposizione i dati in forma analitica e di sintesi e garantire l’importazione dei dati dagli altri sistemi informativi aziendali e, viceversa, l’esportazione dei dati di COAN verso altri sistemi informativi aziendali.

2.2. ALIMENTAZIONE DELLA CONTABILITA’ ANALITICA

Il sistema deve:

A. garantire che il flusso di contabilità analitica, riguardante sia costi che ricavi contenga le seguenti informazioni ritenute minimali:

• centro di costo/ricavo;

• fattore produttivo;

• anno/mese di competenza;

• importo;

• fonte del dato;

• tipo di bilancio (per esempio sanitario/sociale/commerciale/frna);

B. garantire che il flusso di contabilità analitica sia alimentato almeno dalle seguenti fonti alternative:

• scarico della bolla nella procedura di magazzino (reale per i beni, fittizia per i servizi);

• scarico del buono di servizio attestante l’avvenuta erogazione del servizio con l’indicazione del periodo di competenza e/o del contesto specifico di somministrazione dello stesso o altra movimentazione alternativa prevista per la liquidazione dei servizi;

• registrazione del documento contabile nella procedura di contabilità generale;

• importazione dati da altri moduli del sistema informativo o da moduli esterni (es. cespiti o Personale);

C. garantire la quadratura COAN/COGE per conto economico e fattore produttivo attraverso le seguenti funzionalità:

• elaborazioni e stampe per la verifica della quadratura fra contabilità analitica e contabilità generale per singolo conto (es. dettaglio movimentazioni squadrate);

• in caso di squadratura con la COGE, deve essere garantita la possibilità di intervenire con ribaltamenti o rettifiche/correzioni, sia intervenendo in COAN che direttamente nel sottosistema di generazione del movimento;

D. garantire la storicizzazione puntuale del dato, con possibilità di consolidare gli stessi a scadenze periodiche;

E. garantire le ulteriori seguenti funzionalità:

• stretta integrazione col sistema di Contabilità Generale e con gli altri moduli del sistema contabile (magazzino, cespiti,…), in modo che le scritture nei diversi sottosistemi generino automaticamente la corrispondente rilevazione di contabilità analitica;

• funzionalità di drill-down per passare dal saldo ai dettagli; per ciascun movimento di contabilità analitica dovrà essere possibile risalire alla scrittura elementare di origine, generata dal sottosistema di alimentazione; in pratica, avere la possibilità di risalire in COAN al dettaglio dei singoli movimenti dei flussi di alimentazione. Es. Risalire ai singoli prodotti, unità di prelievo e fornitori per i movimenti del magazzino, dati fattura per i movimenti della COGE;

• gestione del costo del personale a effettivo e a standard.

2.3. SISTEMA DI RIBALTAMENTO DEI COSTI COMUNI E GENERALI

Il sistema deve:

A. consentire la definizione dei criteri di ribaltamento e modalità di riparto dei costi/ricavi;

B. consentire la definizione di sistemi di gerarchie e relazioni fra i centri di costo per realizzare la ripartizione dei costi (e dei ricavi) di specifici Cdc (di struttura, intermedi, comuni, generali) su specifici centri di costo finali;

C. consentire la reiterazione del processo per la determinazione delle varie configurazioni di costo, ed il consolidamento dei dati elaborati per il raffronto con esercizi precedenti;

D. garantire flessibilità nella determinazione delle configurazioni di costo (costi diretti o costi pieni);

E. garantire, con riferimento alla ripartizione di ricavi/costi ed ai conseguenti ribaltamenti la possibilità di:

• effettuarli a cascata, secondo sequenze definibili dagli operatori;

• utilizzare le tabelle di dati extracontabili quali driver per i ribaltamenti, tramite anche acquisizione automatica dei dati;

• utilizzare criteri determinati specificatamente;

• escludere, nel processo di ripartizione, specifici fattori e centri di costo e ricavo;

• dare evidenza separata dei costi direttamente imputati rispetto a quelli oggetto di ribaltamento.

2.4. MODELLI REGIONALI “COA01” E MODELLI MINISTERIALI “LA”

Il sistema deve prevedere la gestione dei modelli regionali COA01 e dei modelli regionali LA secondo le seguenti caratteristiche:

• acquisizione da parte delle Aziende Sanitarie del modello regionale COA01 secondo il formato definito e gestito dal livello regionale e del modello ministeriale LA e relativi allegati (si veda paragrafo 6.4);

• elaborazione/compilazione degli schemi modelli COA01 (tra cui ricavi, costi ed frna) e allegati modello LA;

• acquisizione del modello ministeriale LA come riclassificazione del modello COA01, avendo la possibilità di visualizzare tutti i passaggi intermedi di ribaltamento dal COA01 all’LA;

• validazione, degli schemi modelli COA01 e modelli LA e relativi allegati al fine di rendere disponibile i dati al livello regionale secondo quanto previsto al paragrafo 6.4;

• riprodurre i report con possibilità di export;

• generazione dei tracciati per l’alimentazione del Sito Ministeriale NSIS in relazione al modello LA e relativi allegati.

Modalità analoghe dovranno essere previste per la gestione dei modelli CP (Costi Presidio), tenuto conto delle modifiche di legge in corso di approvazione.

2.5. SISTEMA DI INTERROGAZIONE DATI E REPORTISTICA

Il sistema deve garantire la possibilità di elaborare e condividere i seguenti resoconti:

• Reportistica per aggregazione di Centro di Costo/Centri di Responsabilità e fattori produttivi/conti, aziendali;

• Reportistica per aggregazione di Centro di Costo/Centri di Responsabilità e fattori produttivi/conti, regionali/ministeriali;

• Reportistica del piano dei centri di costo e dei fattori produttivi/conti.

Prevedere la possibilità di esportare i dati in modalità strutturata:

• sintetici in linea e/o storicizzati della contabilità analitica contenenti le informazioni di minima già individuate al punto 2.2 lettera A;

• analitici relativi ai movimenti contabili alimentanti la CoAn e di minima già individuati al punto 2.2 lettera B;

• di dettaglio relativi alla specifica movimentazione nei diversi sottosistemi di alimentazione della CoAn (es. movimenti di magazzino, cespiti, pn/fatture, coge).

Deve essere prevista l’integrazione con gli strumenti di office automation open e di mercato diffusi presso le Aziende.

3. GESTIONE CESPITI E INVENTARIO

3.1. PREMESSA

Il sistema deve consentire la gestione analitica dei beni patrimoniali mobili e immobili, materiali e immateriali, di proprietà (acquisiti, donati o realizzati in economia) o di terzi (leasing, service, noleggio o in comodato d’uso…), nonché cespiti di proprietà presso terzi, nel rispetto della normativa civilistica, fiscale e regionale.

Il modulo "gestione cespiti" (GC) deve potere gestire le informazioni sui cespiti a partire dalla gestione progetti/programmi (progetto/programma inteso come obiettivo per raggiungere il quale occorre una molteplicità di azioni) e dalla gestione delle fonti di finanziamento mediante una logica di gestori/tipologia. Ai progetti/programmi possono essere collegate molteplici fonti di finanziamento.

Il sistema, inoltre, deve ricevere i dati dalla “gestione ordini” (collegata ai contratti e ai budget) e colloquiare con il gestionale dedicato alla gestione operativa delle tecnologie biomediche (GTB).

I cespiti devono essere suddivisi in Immobili e Mobili, Materiali e Immateriali.

Il sistema deve garantire un “blocco” su tutti i dati per gli esercizi chiusi e consolidarli.

3.2. ETICHETTE ED INVENTARIO FISICO

Il sistema deve essere in grado di generare, in modalità manuale e/o automatica, il numero di inventario e produrre etichette da apporre sui beni inventariati e sui luoghi fisici in cui i beni sono ubicati. L’etichetta dei beni deve contenere il codice identificativo del cespite, la descrizione e

qualsiasi eventuale ulteriore informazione che verrà richiesta in fase di esecuzione del contratto. L’etichetta del luogo fisico deve poter contenere tutte le informazioni inerenti lo stesso. Il sistema deve prevedere la stampa di etichette in formato barcode e/o Qrcode per la rilevazione ottica o a radiofrequenza; deve pertanto essere prevista anche la possibilità di utilizzare sistemi con Tag ‘RFID’ sia per le etichette dei cespiti che delle stanze. Dovranno essere utilizzati standard di tipo aperto garantendo il rispetto di quanto previsto dalle normative di settore vigenti. Il software deve quindi garantire la possibilità di interfacciarsi, leggere, scrivere ed utilizzare le informazioni provenienti dalle suddette etichette garantendo il funzionamento del sistema anche con tecnologia mista mediante dispositivi mobili.

Inoltre, deve essere possibile l'inserimento veloce dei dati di base e la realizzazione di periodiche revisioni dell'inventario esistente, così come l'alienazione per fuori uso di elevati quantitativi di beni inventariati.

3.3. LEGAMI FRA I CESPITI

I beni possono essere classificati in principali, accessori e componenti.

I beni accessori sono quei beni (es.: stampante per PC) che, pur inventariati con codice proprio, sono strettamente legati, per quanto riguarda l’utilizzo, ad un bene principale.

I beni componenti sono invece cespiti non suscettibili di autonomo utilizzo e che devono quindi essere inventariati con lo stesso codice del bene principale, incrementandone il valore.

Il sistema deve:

A. consentire di gestire la “ricongiunzione” fra il bene principale ed i suoi accessori o componenti;

B. permettere la gestione delle eventuali variazioni (cancellazioni, fuori uso, eccetera) dell'accessorio ma anche di quelle del bene primario cui l'accessorio è collegato: inoltre deve essere possibile gestire i vari componenti del bene in modo autonomo, anche se legati fra loro, perché facenti parte ad esempio di un unico strumento;

C. gestire l'eventualità in cui il bene accessorio abbia una propria fonte di finanziamento diversa da quella del bene principale ed anche la possibilità di abbinare i beni “padre-figli”;

D. gestire i beni per unità singola o per universalità di beni;

E. nel caso di beni singoli, gestire gli eventuali componenti, non dotati di vita autonoma ma legati al bene principale, come incrementi di valore;

F. garantire i requisiti di cui al punto A, B, C e E anche nel caso di manutenzioni straordinarie.

3.4. MOVIMENTAZIONE DEI BENI

Il sistema deve:

A. tracciare lo spostamento riguardante il trasferimento di beni da un centro di costo ad un altro, in particolare quando il bene risulti finanziato con fondi di tipo commerciale e la nuova dislocazione lo faccia uscire da tale ambito;

B. consentire ai CONSEGNATARI e/o SUB-CONSEGNATARI dei beni assoggettati ad inventariazione l’accesso ai beni assegnati ai centri di costo di riferimento (dell’Unità Operativa, del Servizio, dell’Ufficio, etc.) per poter verificare, in qualunque momento, la consistenza del patrimonio ed effettuare, poi la ricognizione fisica dei beni. La procedura software, quindi, deve permettere di effettuare la stampa dei beni presenti sul cdc da tutti i profili interessati (tra cui i Consegnatari). Inoltre, deve consentire la gestione informatizzata della verifica periodica fisica sui singoli centri di costo. I consegnatari potranno, quindi, rilevare:

• Conferma presenza;

• Non presente;

• Presenza nel CDC di cespiti non in elenco dei beni attribuiti; con la registrazione di eventuali annotazioni di rilievo;

C. prevedere la gestione informatizzata delle proposte di spostamento da un centro di costo ad un altro e delle relative autorizzazioni e prese in carico;

D. gestire le consegne di beni presso terzi e l'eventuale comodato d'uso presso terzi;

E. effettuare la storicizzazione dell'archivio relativo agli spostamenti di ciascun bene;

F. gestire trasferimenti massivi della totalità o di un sottoinsieme di beni assegnati ad un centro di costo/consegnatario ad un altro;

G. garantire la gestione del fuori uso e delle eventuali alienazioni;

H. prevedere, per il fuori uso, la possibilità di allegare il verbale e/o verbali relativi;

I. generare, se necessario, i documenti di accompagnamento.

3.5. AMMORTAMENTI E STERILIZZAZIONI

Il sistema deve:

A. gestire l'ammortamento fiscale e quello civilistico come previsto dal Codice Civile;

B. garantire che le quote di ammortamento dell’esercizio vengano calcolate applicando le aliquote determinate sulla base della vita utile, definita a livello nazionale, per ciascuna categoria di beni, dalla tabella che costituisce l’allegato 3 al Decreto Legislativo 118/2011;

C. consentire di applicare un’aliquota più elevata (o più bassa nei casi previsti dalla normativa) sul singolo bene;

D. consentire di definire autonomamente la data da cui far partire l'ammortamento sia essa la consegna del bene, la data della fattura, la data di protocollazione della fattura, la data di entrata in funzione o del collaudo;

E. prevedere che, nel primo esercizio, l’aliquota di ammortamento sia rapportata alla frazione d’anno di effettivo utilizzo del cespite o alternativamente applicando forfettariamente la metà dell’aliquota normale. Il sistema deve prevedere un parametro per rendere automatica l’operazione a seconda della scelta effettuata;

F. prevedere per i cespiti il cui valore risulti inferiore a 516,46 euro la possibilità di ammortizzarli integralmente nell’esercizio in cui vengono resi disponibili e pronti per l’uso, ad eccezione di quelli che fanno parte di universalità ai sensi dell’art. 816 del codice civile. Il sistema deve prevedere un parametro per rendere automatica l’operazione;

G. nel caso in cui sia effettuata la dismissione o alienazione di un cespite, prevedere che l’ammortamento possa essere operato per la frazione d’anno in cui il cespite è stato impiegato, oppure non essere effettuato. Il metodo prescelto deve essere applicato in modo uniforme a tutti i beni dismessi o ceduti in corso d’anno. Il sistema deve prevedere un parametro per rendere automatica l’operazione;

H. nel caso di manutenzione straordinaria, garantire che l’ammortamento venga calcolato nel seguente modo a seconda della tipologia di manutenzione:

• incrementativa della vita utile del bene, con applicazione dell'aliquota prevista per la classe merceologica del cespite manutenuto;

• non incrementativa della vita utile del bene, con utilizzo di un’aliquota che completi l’ammortamento della manutenzione contestualmente all'ammortamento del cespite manutenuto; nel caso in cui il cespite abbia già esaurito l'ammortamento, la relativa manutenzione andrà completamente ammortizzata nell'anno di acquisizione.

I. consentire la gestione della correlazione fra i singoli cespiti e le varie fonti di finanziamento utilizzate, dettagliatamente individuate, permettendo modalità di ammortamento specifiche, collegate alla tipologia di fonte di finanziamento, all’interno della stessa classe di cespite.

J. garantire la riconciliazione sistematica tra fonti di finanziamento e cespiti, nonché tra ammortamenti e sterilizzazioni che ne discendono;

K. garantire la riconciliazione sistematica tra contributi in conto esercizio stornati al conto capitale e cespiti, nonché tra ammortamenti e sterilizzazioni che ne discendono;

L. prevedere la possibilità d’inserimento sul medesimo cespite di una o più fonti di finanziamento; ciascuna fonte di finanziamento concorrerà autonomamente alla sterilizzazione degli ammortamenti.

3.6. PIANO DEGLI INVESTIMENTI

L’applicativo deve consentire la gestione della programmazione degli investimenti e la predisposizione del piano degli investimenti su un arco temporale di tre anni, secondo le modalità e gli schemi definiti a livello regionale, garantendone l'export.

Il sistema deve consentire un collegamento tra Piano degli Investimenti definito in sede di programmazione e gli investimenti realizzati, generando il piano degli investimenti a consuntivo per ciascun anno (stato di attuazione del piano investimenti) che sarà anche la base per la formulazione del nuovo piano triennale (nuova programmazione).

Deve essere possibile l'aggiornamento in corso d'anno del Piano Investimenti. La procedura deve tenere traccia delle modifiche, mantenendo traccia di ogni versione del piano e relativi dati di approvazione.

Per ogni intervento compreso nel piano investimenti dovrà essere possibile associare una o più fonti di finanziamento, appositamente codificate, le quali saranno attribuite ad uno o più soggetti gestori di risorse.

Ai soggetti gestori di risorse, quindi, sarà assegnata la disponibilità finanziaria suddivisa per fonti di finanziamento, da utilizzare per la realizzazione degli interventi ad essi attribuiti.

Nell'ambito di ciascun intervento deve essere possibile lo spostamento di somme tra gestori.

Gli interventi non finanziati non potranno essere associati ai processi di acquisto e, pertanto, non deve essere possibile emettere ordini. Se esiste un finanziamento parziale deve essere possibile utilizzarlo.

Nello schema regionale del piano investimenti gli interventi sono classificati attualmente per tipologie dette "macro unità": lavori, manutenzioni straordinarie, tecnologie biomediche, tecnologie informatiche e beni economali; l'intervento viene attribuito alla tipologia che ha la maggior incidenza sulla spesa complessiva dell’intervento.

L'importo di ciascun intervento dovrà risultare dalla somma degli importi delle tipologie d’investimento, che lo compongono, “aggregate” in un unico record.

Esempio: un progetto complessivo che ha un costo di 1.000 prevede le seguenti tipologie d’investimento: lavori per 500; tec. Biomediche per 300; tec. Informatiche per 50; beni economali per 150; nel piano investimenti risulterà aggregato su un unico record, per l’importo di 1000, sotto la macro unità “lavori” che è la tipologia d’investimento con la maggior incidenza sul costo complessivo.

Il sistema dovrà gestire i contratti e gli ordinativi relativi agli interventi del piano consentendo il collegamento con:

- la procedura magazzino (per gli ordini emessi e il carico delle bolle o dei certificati di pagamento);

- la procedura Contabilità Generale (per le fatture dei fornitori e il mandato di pagamento);

- la procedura inventario (per l’inventariazione delle attrezzature e delle opere). Il sistema dovrà consentire l'aggregazione di più contratti.

Per ogni intervento possono essere presenti più aggregazioni, ognuna attivata dal gestore di riferimento.

Inoltre, stante che un contratto può essere utilizzato per più interventi, il sistema deve garantire tale funzionalità e il relativo monitoraggio.

A titolo esemplificativo si riportano gli schemi 1 e 2.

Il sistema dovrà consentire il monitoraggio di ciascun intervento sia in modo complessivo, sia in maniera separata per tipologia d’investimento, per aggregazione o per contratto, permettendo anche l’export dei dati collegati (ordini, bolle, fatture, pagamenti) direttamente su foglio elettronico; questo anche ai fini della rendicontazione alla regione sulle spese sostenute.

A ciascun intervento finanziato presente nel piano investimenti potrà essere associato un codice CUP (se previsto) che verrà ereditato dal contratto.

Il sistema inoltre, per ciascun intervento classificato come opera/lavoro pubblico, dovrà disaggregare l'importo dell'intervento e di ogni contratto in sottocategorie, permettendo la gestione del Quadro economico dell'intervento secondo gli schemi in vigore: ad esempio, lavori, oneri sicurezza, spese tecniche, imprevisti, IVA (suddivisa per aliquote). Dovrà essere possibile desumere per ogni voce (lavori, spese tecniche, etc.) l’importo aggiornato e le relative fatture caricate.

3.7. FUNZIONI SPECIFICHE RELATIVE ALLA GESTIONE DEGLI IMMOBILI

Il sistema deve prevedere le seguenti ulteriori funzioni specifiche nella gestione degli immobili:

A. gli immobili (ospedali, ospedale di comunità, case della salute, poliambulatori,…) devono essere codificati secondo un nomenclatore definito a livello regionale;

B. ad ogni immobile deve essere possibile associare tutti gli interventi effettuati quali:

a. ampliamenti;

b. ristrutturazioni;

c. manutenzioni straordinarie.

attraverso le funzionalità dei legami tra i cespiti già illustrate al punto 3.3;

C. ad ogni intervento deve essere associata la/le relativa/e fonte/i di finanziamento;

D. ad ogni immobile deve essere possibile associare i cespiti presenti, le modalità di acquisto e le fonti di finanziamento.

Il sistema deve consentire inoltre il collegamento ai singoli immobili di costi correnti non capitalizzabili, quali:

A. manutenzioni ordinarie eseguite annualmente, definite a livello regionale attraverso l’univoca anagrafica dei prodotti;

B. utenze (energia elettrica, gas, acqua);

C. riscaldamento (energia termica, servizio energia, gas);

D. smaltimento rifiuti sanitari e non;

E. pulizie;

F. altri costi afferenti gli immobili;

G. tasse e tributi legati agli immobili.

Il sistema deve prevedere una reportistica che consenta di:

A. conoscere il valore dell’immobile, degli interventi effettuati, delle fonti di finanziamento utilizzate;

B. conoscere il valore dei cespiti presenti nell’immobile e le relative fonti di finanziamento, con particolare riferimento alle apparecchiature biomediche, con analisi di dettaglio per conto o per prodotto;

C. conoscere i costi correnti connessi all’utilizzo dell’immobile;

D. conoscere gli utilizzi dei finanziamenti assegnati.

In particolare, per quanto riguarda la realizzazione di fabbricati, deve essere possibile associare al cespite in via di realizzazione tutte le fatture relative alle varie tipologie di spese sostenute ed agli stati di avanzamento lavori, con possibilità di inserire nella scheda cespite, al termine della realizzazione dell’opera, la data di entrata in funzione/collaudo. La gestione cespiti assegna il numero d’inventario, eventualmente associato alla scheda principale (come da paragrafo legami tra cespiti).

3.8. RELAZIONI CON GLI ALTRI MODULI

La procedura per la gestione cespiti deve:

A. prevedere la correlazione fra classe merceologica del cespite, desumibile dall’ordine di acquisto, e gli specifici conti delle immobilizzazioni, dei fondi ammortamento, ammortamenti, per la generazione delle scrittura di prima nota e di assestamento;

B. prevedere il collegamento dei beni soggetti a collaudo al conto di bilancio delle “immobilizzazioni in corso” e di trasferire detti beni alle corrette classi di cespiti, solo ad avvenuto inserimento della data di collaudo;

C. gestire il blocco automatico (blocco collaudo) della fattura se un cespite (o un’universalità) è in attesa di collaudo. In questo caso la fattura deve rimanere bloccata fino a collaudo avvenuto e sbloccarsi automaticamente a seguito dell’inserimento dello stesso in procedura;

D. gestire l’alimentazione della contabilità analitica al fine di assicurare il calcolo della consistenza patrimoniale e delle quote di ammortamento di ogni singolo bene, sia annuali che infrannuali, e l’attribuzione, anche percentualizzata, ai centri di costo/attività utilizzatori/commesse;

E. prevedere nella scheda del bene e nelle successive movimentazioni (ammortamenti, variazioni valore, beni accessori, eccetera) un collegamento con l'ordine di acquisto (ove presente) ed eventuale codice di commessa, codice progetto e fonte di finanziamento;

F. il sistema dei cespiti ed inventariazione, per creare l’anagrafica del bene contestualmente alla registrazione del ddt o della fattura che diventano elementi della scheda cespite, nonché la relativa fonte di finanziamento dell’investimento, che nel caso di contributo in conto capitale o donazione dà luogo anche alle scritture di sterilizzazione oltreché di ammortamento; prevedere il set di dati necessario per poter trasferire in automatico alla contabilità generale le scritture di ammortamento e di sterilizzazione;

G. prevedere il trasferimento automatico alla contabilità analitica degli ammortamenti e delle eventuali relative sterilizzazioni diviso per Centro di Costo;

H. garantire la generazione automatica delle scritture contabili relative a fuori uso/alienazioni divise per fonte di finanziamento:

• storno fondo ammortamento;

• storno valore netto contabile con eventuale rilevazione di minusvalenza o plusvalenza;

• eventuale sterilizzazione della minusvalenza;

I. generare automaticamente le correlate scritture contabili per il bene principale ed i componenti nel caso di cessione del bene o messa fuori uso;

J. gestire l’acquisizione dei dati indispensabili all'emissione della fattura attiva, nel caso di alienazioni.

3.9. OPERE D’ARTE, BENI DI INTERESSE STORICO, ARTISTICO, CULTURALE, NATURALE

Il sistema deve prevedere un’apposita sezione della procedura cespiti che gestisca tali beni che vengono registrati in inventario al valore di stima. Detti beni non sono soggetti ad ammortamento ed eventuali manutenzioni a carattere conservativo si rilevano a costo d’esercizio.

3.10. REGISTRO DEI BENI AMMORTIZZABILI

Ai fini fiscali il sistema deve essere in grado di predisporre un apposito registro che utilizzi criteri di calcolo di ammortamento fiscale e che tenga conto di movimenti di trasferimento da commerciale a dislocazioni di tipo istituzionale fuori uso o cancellazioni e viceversa. In tal senso il registro deve essere alimentato con scritture di rettifica di acquisto, fondo e quota. La contabilità generale deve essere in grado di registrare le quote di ammortamento così calcolate per poter alimentare il bilancio commerciale.

Gli attributi da prevedere nel registro sono almeno i seguenti:

• numero inventario;

• descrizione bene;

• estremi fattura;

• codice e ragione sociale fornitore;

• costo di acquisto;

• percentuale di ammortamento;

• conto patrimoniale di acquisto;

• ammortamento annuo fiscale suddiviso per tipologia di attività;

• residuo ammortizzabile;

• quantità fuori uso;

• quantità cancellata;

• conto di fondo ammortamento;

• conto ammortamento;

Il sistema deve garantire la stampa del libro cespiti nel formato richiesto dalla normativa vigente.

3.11. REPORTISTICHE

A titolo esemplificativo e non esaustivo si riportano di seguito le interrogazioni dati e la reportistica che il sistema deve garantire:

• verbali di: consegna, installazione, collaudo, variazione valore, trasferimento, fuori uso, cancellazione;

• inventari: per categoria fiscale e classificazione, per servizio e stabilimento, per fornitore o conto d'uso, per combinazione di più criteri di scelta contemporaneamente e a scelta dell'utente;

• giornale movimenti: per categoria fiscale, per consegnatario, per fonte di finanziamento;

• registro beni ammortizzabili: analitico, per conto, solo a totali, commerciale;

• scheda del bene e relativi attributi collegati (es: scheda catastale);

• stampa riepilogativa per conto di stato patrimoniale che esponga l'elenco dei beni completamente ammortizzati ma ancora funzionanti;

• stampa riepilogativa per conto di stato patrimoniale che esponga l’elenco dei beni non ancora entrati in funzione (immobilizzazioni in corso) con valorizzazione degli importi totali;

• stampa riepilogativa degli ammortamenti per conto;

• stampa riepilogativa delle sterilizzazioni per conto e/o ammortamenti per fonte di finanziamento;

• stampa riepilogativa dei beni in comodato d'uso, locazione e altri beni di terzi con valorizzazione dell'importo totale e residuo;

• stampa riepilogativa dei beni di proprietà presso terzi con valorizzazione dell’importo totale e residuo;

• stampa riepilogativa fuori uso con possibilità di distinguere causali diverse (es. furti );

• stampa riepilogativa dei beni donati per esercizio, con valorizzazione dell'importo totale;

• stampe di natura statistica;

• stampe di natura gestionale (es. situazione beni per centro di costo);

• stampa di controllo distinta per conto di imputazione e singola fattura fra il valore dei beni iscritti in inventario e i valori iscritti a bilancio;

• stampe di simulazione degli ammortamenti e sterilizzazione in corso d’anno e per gli anni futuri, con possibilità di stabilire dei parametri con particolare riferimento alla data di entrata in funzione dei beni;

• stampa sulla base dei diversi parametri dell’anagrafica cespite.

4. CONTABILITA’ GENERALE

4.1. PREMESSA

Il sistema deve consentire, la redazione del Bilancio d’esercizio Aziendale, compresa la Gestione Sanitaria Accentrata del Bilancio delle Gestioni sanitaria, sociale e dell’attività commerciale, secondo quanto previsto dalle normative civilistiche e fiscali nonché dalle leggi e disposizioni regionali. Deve consentire la riclassificazione dei dati contabili per assolvere i debiti informativi verso il Ministero della Salute e verso l’Assessorato Regionale alla Sanità. Deve garantire l’emissione dei documenti attivi e la registrazione dei documenti passivi, l’emissione e la contabilizzazione degli incassi e dei pagamenti secondo le modalità definite dall’ente tesoriere e dalla normativa in materia.

Il Sistema di contabilità generale deve essere in grado di gestire efficacemente un’organizzazione amministrativa di tipo divisionale e multi aziendale (anche in vista di possibili unificazioni di servizi a livello provinciale, di area vasta o regionali). Le divisioni potranno essere gestite come bilanci sezionali all’interno della medesima contabilità generale e consentire la costruzione di bilanci consolidati quale aggregazione delle divisioni previa elisione delle poste compensative. Inoltre, il sistema deve prevedere la gestione della contabilità della Gestione Sanitaria Accentrata in raccordo con il sistema che gestisce il Bilancio regionale. Il sistema deve consentire di gestire le quote di finanziamento del SSR che rientrano nel perimetro della GSA attraverso la rilevazione di scritture di contabilità economico-patrimoniale e allo stesso tempo garantire il collegamento con il Bilancio Regionale che è gestito in contabilità finanziaria.

4.2. GESTIONE SANITARIA ACCENTRATA

Per quanto attiene la Gestione Sanitaria Accentrata si descrivono di seguito alcune caratteristiche essenziali.

La Gestione Sanitaria Accentrata è un soggetto privo di personalità giuridica autonoma. Si tratta di uno specifico centro di responsabilità istituito presso la Regione, tenuto alla registrazione in contabilità economico-patrimoniale dei rapporti economici, patrimoniali e finanziari, inerenti le operazioni finanziate con risorse destinate al Servizio Sanitario Regionale, così come previsto dalla casistica applicativa approvata con Decreto del Ministero della Salute del 17/09/2012.

Le entrate e le uscite del Bilancio regionale relative al finanziamento del Servizio Sanitario Regionale gestite direttamente dalla GSA sono determinate con deliberazione della Giunta regionale che individua l’elenco dei capitoli di entrata e di spesa ricompresi nella perimetrazione “sanità” del bilancio regionale (DGR n.352/2013). Qualora vengano istituiti nuovi capitoli afferenti alla sanità, l’elenco viene aggiornato in sede di approvazione del bilancio d’esercizio della Gestione Sanitaria Accentrata.

Il sistema deve pertanto garantire la regolare tenuta delle scritture contabili e prevedere la registrazione nel libro giornale dei fatti gestionali relativi al perimetro della GSA; rilevare i costi, i ricavi e le variazioni negli elementi attivi e passivi del patrimonio, in modo da darne rappresentazione nel bilancio di esercizio. Le rilevazioni contabili sono effettuate:

- con riferimento ai costi e alle passività, sulla base delle Deliberazioni di Giunta/Determinazioni Dirigenziali adottate nell’ambito del perimetro della GSA e sulla base delle rilevazioni di contabilità finanziaria relative agli impegni ed ai pagamenti poste in essere dal Servizio Gestione della spesa regionale della Direzione Generale Risorse Finanziarie e Patrimonio;

- con riferimento ai ricavi e alle attività, sulla base degli atti adottati nell’ambito del perimetro della GSA e sulla base delle rilevazioni di contabilità finanziaria relative agli accertamenti ed alle riscossioni poste in essere dal Servizio Bilancio e Finanze della Direzione Generale Risorse Finanziarie e Patrimonio;

La gestione economico patrimoniale della GSA deve pertanto garantire:

- l’importazione informatizzata periodica e continuativa, tramite interfaccia di supporto, delle uscite sanitarie (impegni di spesa) dalla contabilità finanziaria Regionale alla contabilità economico-patrimoniale della GSA;

- l’importazione informatizzata periodica e continuativa, tramite interfaccia di supporto, delle entrate sanitarie (accertamenti) dalla contabilità finanziaria Regionale alla contabilità economico-patrimoniale della GSA;

- la registrazione, in contabilità economico-patrimoniale, delle reversali di incasso e dei mandati di pagamento;

- la registrazione, in contabilità economico-patrimoniale, delle economie di entrata e di spesa;

- le elaborazioni necessarie per la redazione dei prospetti di cui all’art. 22, comma 3, lett. i) del D.Lgs. n. 118/2011:

- prospetto di Raccordo e Riconciliazione dell’Attivo e del Passivo tra la contabilità finanziaria del bilancio regionale e la contabilità economico-patrimoniale della GSA;

- prospetto di Riconciliazione dei dati di cassa della GSA con i movimenti finanziari del conto di Tesoreria regionale intestato alla Sanità.

A tal fine dovrà essere gestita a sistema la correlazione tra capitoli di spesa e di entrata e impegni e accertamenti della contabilità finanziaria Regionale e conti di contabilità economico-patrimoniale della GSA.

Le scritture contabili della GSA da effettuare in collegamento con il Bilancio Regionale sono principalmente le seguenti:

USCITE

Il sistema deve consentire la proposta automatica, parziale o totale, delle registrazioni contabili dei documenti, prelevando le informazioni d’interesse direttamente dal Bilancio Regionale gestito in contabilità finanziaria.

A titolo esemplificativo e non esaustivo si riportano le informazioni che devono essere proposte in automatico come riga di debito (avere) della scrittura contabile in uscita, partendo dall’informazione numero impegno e anno:

• Impegno;

• Capitolo;

• Anno;

• Protocollo Atto;

• Atto;

• Data Atto;

• Codice e descrizione fornitore;

• Conto di debito (proposto con possibilità di modifica);

• Descrizione dell’operazione (proposta con possibilità di modifica);

• Importo.

Potranno essere previsti ulteriori campi per gestire informazioni aggiuntive, come per esempio l’anno di formazione finalizzato alla predisposizione delle Tabelle di Nota Integrativa.

Deve essere prevista la gestione di tabelle di raccordo tra capitoli di spesa, impegni e conti economici e patrimoniali, laddove consentito, per generare la proposta del conto di contropartita economica e/o patrimoniale.

Inoltre, il sistema deve prevedere di visualizzare tutte le informazioni di dettaglio relative alle transazioni gestite e presenti in contabilità finanziaria sul bilancio regionale, partendo dal capitolo e dall’impegno.

ENTRATE

In analogia alle uscite, il sistema deve consentire la proposta automatica, parziale o totale, delle registrazioni contabili dei documenti, prelevando le informazioni d’interesse direttamente dal Bilancio Regionale gestito in contabilità finanziaria.

In particolare sulle Entrate è fondamentale la gestione di un parametro che consenta di effettuare differenti registrazioni contabili a seconda che alla data di registrazione sia intervenuta o meno l’Intesa Stato Regioni di individuazione del Fondo Sanitario Regionale definitivo e approvato, così come previsto dalla casistica applicativa approvata con Decreto del Ministero della Salute del 17/09/2012.

Si tratta, in particolare, di trasferimenti Erariali di IRAP, Addizionale Irpef e IVA la cui rilevazione viene effettuata in acconto fino a quando non è intervenuta l’Intesa Stato Regioni e sui conti specifici di Fondo Sanitario quando interviene l’Intesa.

A titolo esemplificativo e non esaustivo si riportano le informazioni che devono essere proposte in automatico come riga di credito (dare) della scrittura contabile in entrata, partendo dall’informazione del capitolo anno:

• Cliente;

• Conto di Credito;

• Descrizione dell’operazione (proposta con possibilità di modifica);

• Importo;

• Anno;

• Capitolo;

• Accertamento;

• Credito (si tratta di una porzione di accertamento presente ed ereditata dal Bilancio Regionale)

• N. documento

• Atto (qualora esistente)

• Data Atto (qualora esistente).

Deve essere prevista la gestione di tabelle di raccordo tra capitoli di entrata, accertamenti, crediti e conti economici e patrimoniali, laddove consentito, per generare anche la proposta del conto di contropartita economica e/o patrimoniale.

Inoltre il sistema deve prevedere di visualizzare tutte le informazioni di dettaglio relative alle transazioni gestite e presenti in contabilità finanziaria sul bilancio regionale, partendo dal capitolo, dall’accertamento e dal credito.

ECONOMIE

Il sistema deve consentire di registrare le economie di spesa e di entrata, con proposta automatica, prelevando le informazioni d’interesse direttamente dal Bilancio Regionale, gestito in contabilità finanziaria. A tal fine deve essere prevista la chiusura automatica delle partite aperte di credito e di debito registrate in contabilità economico-patrimoniale sulla GSA.

MANDATI E REVERSALI

Il sistema deve consentire di registrare i pagamenti e gli incassi, con proposta automatica, prelevando le informazioni d’interesse direttamente dal Bilancio Regionale, gestito in contabilità finanziaria. A tal fine deve essere prevista la chiusura automatica, parziale o totale delle partite aperte di credito e di debito registrate in contabilità economico-patrimoniale sulla GSA.

A titolo esemplificativo e non esaustivo si riportano le informazioni che devono essere proposte in automatico come riga di chiusura debito (dare) della scrittura contabile di pagamento:

• Mandato

• Data

• Impegno

• Anno Impegno

• Capitolo

• Fornitore

In conclusione, la GSA essendo un soggetto privo di personalità giuridica effettua registrazioni in contabilità economico-patrimoniale prelevandole dal Bilancio Regionale, gestito in contabilità finanziaria, oltre a registrazioni proprie necessarie per la chiusura e la redazione del bilancio d’esercizio della GSA. Le funzionalità richieste nei paragrafi successivi devono essere garantite anche per la GSA, ove necessarie (per esempio riclassificazione dei bilanci; predisposizione modelli CE e SP; alimentazione piattaforma matrice scambi). Sono da escludersi diverse funzionalità tra cui: gli adempimenti fiscali; la gestione degli incassi e pagamenti, nel senso che la GSA non può disporre direttamente i pagamenti al tesorerie, ma registra gli incassi e pagamenti disposti dal bilancio regionale; emissione di fatture; ricevimento e liquidazione di fatture; cassa economale; raccordo con la Piattaforma Certificazione dei Crediti (PCC); fornitori con ritenuta d’acconto.

4.3. CONTABILITA’ SEPARATA E BILANCI SEPARATI

Il sistema proposto deve:

A. prevedere funzioni specifiche per la gestione separata del bilancio sanitario e sociale e all’interno della medesima divisione delle contabilità separate relative a:

• fondo per la Non Autosufficienza;

• distretti e presidi ospedalieri;

• attività intramoenia;

• attività commerciali;

• altre attività.

B. prevedere apposite funzioni per la predisposizione automatica dei riclassificati richiesti dalla normativa e dalla prassi corrente; quindi, a titolo puramente esemplificativo, modelli regionali, modelli ministeriali CE ed SP e Rendiconto Finanziario (ex Decreto legislativo 118/2011 come modificato dal Decreto Interministeriale 20/03/2013);

C. ulteriori riclassificazioni dei dati necessari al fine di rispondere a esigenze informative ministeriali, regionali e aziendali (per esempio riclassificato relativo alle sole voci (FR) del Fondo Regionale della non Autosufficienza);

D. garantire la gestione della contabilità separata, oltreché alla parte economica, anche allo stato patrimoniale (Clienti, Fornitori, Banche, Immobilizzazioni, come nel caso del Bilancio Sociale);

E. permettere la redazione di bilanci per contabilità separata/divisionale, oltreché aggregata;

F. permettere la redazione del bilancio consolidato delle Aziende Sanitarie e della GSA;

G. permettere l’elaborazione automatica delle tabelle della Nota Integrativa ai sensi del D.Lgs. 118/2011 e xx.xx.

4.4. GESTIONE CLIENTI E FORNITORI

Il sistema deve prevedere, almeno, le seguenti funzionalità:

A. gestire diverse modalità di pagamento sullo stesso fornitore con data di fine validità (diversi conti correnti, e diverse modalità di pagamento, comprese le varie tipologie di cessione del credito ed i conti bancari dedicati ai fini della tracciabilità dei pagamenti);

B. cambiare la priorità di selezione di una modalità di pagamento;

C. agganciare al conto del beneficiario il conto del cessionario del credito e (già al momento del caricamento della partita sulla quietanza della cessione) generare il movimento di trasferimento delle partite ad altro beneficiario e cessionario;

D. prevedere un controllo sui pagamenti: mettere in stato di sospensione il fornitore a livello locale, bloccare i pagamenti che superano un certo ammontare monetario, ecc;

E. prevedere l’attribuzione di uno o più conti di debito o credito per consentire la separata evidenziazione dei debiti e crediti come per esempio per i beni, servizi o cespiti, forniture per FRNA, nonché la gestione automatica delle fatture da emettere e da ricevere con separata evidenziazione di cui al periodo precedente;

F. garantire la gestione dello split payment;

G. prevedere l’estrazione dei soli fornitori soggetti a ritenuta d’acconto;

H. prevedere la gestione del DURC: acquisizione automatica, memorizzazione delle richieste, gestione delle scadenze e possibilità di blocco automatico dei pagamenti in caso di irregolarità.

4.5. GESTIONE FORNITORI SOGGETTI A RITENUTA D’ACCONTO E ANAGRAFE DELLE PRESTAZIONI

Il sistema proposto deve:

A. garantire che le ritenute diventino liquidabili automaticamente al momento dell'emissione dell'ordinativo di pagamento. L'automatismo dovrà attivarsi in base alla data dell'ordinativo e non alla data di scarico dello stesso;

B. prevedere stampe dettagliate o riepilogative delle ritenute irpef, oltre che dei contributi previdenziali a carico percipiente, dei contributi previdenziali a carico del soggetto erogante e dell’IRAP qualora dovuti, da versare nel mese ed almeno una stampa da cui evincere lo scadenziario delle uscite per utenti, uffici o gruppo di utenti che hanno provveduto all'inserimento fatture;

C. garantire l’elaborazione dei tracciati secondo le specifiche tecniche previste dalla normativa vigente necessarie per la predisposizione del modello di Certificazione Unica e modello 770;

D. prevedere stampe e report di controllo su fogli di calcolo dei dati contenuti nel tracciato per l’invio e la predisposizione del modello di Certificazione Unica e modello 770;

E. garantire la gestione degli elementi necessari per ottemperare all'obbligo di comunicazione all’"Anagrafe delle Prestazioni” (art.53 DLGS.165/2001) degli incarichi di consulenza e collaborazione esterna pagati nel semestre attraverso una stampa completa (esportabile su fogli di calcolo) la quale, selezionando il periodo di pagamento delle fatture (mese-anno) riporti:

• i dati anagrafici completi del fornitore libero professionista;

• i riferimenti delle fatture pagate nel periodo;

• i dati contabili relativi al compenso (conto economico, eventuale riferimento all'ordine emesso dal Servizio responsabile della spesa) per ogni fattura pagata.

4.6. REGISTRAZIONI DEI DOCUMENTI E SCRITTURE CONTABILI

Le operazioni contabili afferenti alle diverse tipologie di divisioni e di contabilità separate dovranno essere effettuate sull’unico Piano dei Conti e collegate alle varie tipologie di attività.

Il sistema deve:

A. garantire la creazione automatica di scritture contabili periodiche (es. da altri moduli collegati quali i cespiti per ammortamenti e sterilizzazioni);

B. garantire la registrazione di dati contabili derivanti da altre applicazioni, anche mediante il riversamento da interfacce e procedure esterne (es. pagamenti multipli come farmacie per convenzionata esterna, assegni e sussidi ad utenti, personale, ricavi, ticket da centri di riscossione esterni, ecc.);

C. prevedere la gestione del legame fra note di credito e fatture per storni totali o parziali;

D. prevedere la gestione delle compensazioni fra clienti e fornitori tramite scrittura diretta di compensazione di partite e tramite l’emissione di mandato commutabile in quietanza d’entrata;

E. garantire la gestione del periodo di competenza e della data di caricamento di ogni singolo documento contabile;

F. prevedere la gestione dei ratei e dei risconti con proposta di generazione automatica delle scritture contabili di chiusura e riapertura dell’esercizio;

G. garantire la gestione automatica della chiusura e dell’apertura di esercizio;

H. prevedere la simulazione di chiusura e riapertura;

I. prevedere la gestione delle fatture e note di accredito da ricevere sul bilancio in chiusura, con proposta di generazione automatica delle fatture da ricevere sulla base dei movimenti di carico (di beni e servizi), ma non ancora fatturati e sulla base delle fatture rilevate nell’esercizio successivo con competenza anno precedente;

J. prevedere la gestione delle fatture e note di accredito da emettere con proposta di generazione automatica delle scritture contabili sulla base delle fatture emesse e rilevate nell’esercizio successivo con competenza anno precedente;

K. prevedere il calendario operativo contabile che permetta di operare sia sull’anno in chiusura che sull’esercizio nuovo. Le scritture contabili di chiusura esercizio quali: ratei e risconti, fatture e note di accredito da ricevere, fatture e note di addebito da emettere devono poter girare automaticamente, garantendone la quadratura, sul vecchio e sul nuovo esercizio contabile;

L. prevedere l'indicazione della competenza economica del costo o del ricavo con impossibilità di imputare un costo o un ricavo su un esercizio già chiuso, e proposizione del relativo conto collegato di sopravvenienza passiva o attiva;

M. consentire di effettuare operazioni multiple su più partite o documenti, nonché generare operazioni automatiche sulla base di determinati parametri reimpostati (ad es. abbuoni massivi su gruppi di partite con saldo di pochi centesimi);

N. garantire l’aggiornamento immediato degli archivi contabili con possibilità di variare o annullare le scritture inserite non ancora consolidate o stampate nei sezionali Iva e nel libro giornale bollato;

O. garantire, attraverso un sistema di abilitazione degli utenti alle diverse funzionalità e tipologia di scrittura contabile, la possibilità di variare o annullare le singole registrazioni;

P. prevedere in fase di inserimento dei movimenti tutti i controlli derivanti dal rispetto delle regole fiscali e dei principi contabili, tra i quali a titolo esemplificativo e non esaustivo:

• la verifica della quadratura;

• la coerenza delle date;

• la correttezza dei dati IVA (si rimanda al punto 4.11.1).

Q. prevedere che la modifica di un movimento contabile debba essere subordinata e limitata dallo stato del documento cui si riferisce. In particolare, possono essere consentite modifiche parziali limitate da definire in sede di esecuzione del contratto, laddove sia stato emesso ordinativo di incasso/pagamento, mentre non possono essere più consentite modifiche qualora siano stati elaborati in definitivo il libro giornale di contabilità e/o i registri IVA;

R. prevedere che i saldi degli esercizi precedenti già chiusi debbano restare disponibili per interrogazioni e report di confronto “anno su anno”;

4.7. MOVIMENTAZIONI EXTRA-CONTABILI

Il Sistema deve consentire la movimentazione di scritture extracontabili riguardanti sia i conti di Contabilità Generale che quelli di Contabilità Analitica. Tali registrazioni, devono integrare o rettificare, ma in ambiente separato, i dati certi ed immodificabili della contabilità generale, con scritture significative dal punto di vista operativo e gestionale per effettuare analisi periodiche

sull’andamento della gestione economica aziendale e propedeutiche all’invio dei modelli Ministeriali CE trimestrali.

I movimenti extracontabili possono essere mantenuti, variati, cancellati. Il sistema deve consentire, quindi, di elaborare:

A. bilanci di verifica infrannuali con dati di preconsuntivo di periodo o annuali alimentati da:

• contabilità generale;

• contabilità analitica;

• budget;

• caricamento da dati esterni (per es. previsione dei servizi);

• movimentazioni di scritture extracontabili;

• simulazioni delle scritture di chiusura di bilancio (ammortamenti, fondi rischi e oneri, valutazione rimanenze, etc) compresa la simulazione di ratei, risconti, fatture e note di credito da ricevere e da emettere a fine esercizio e in periodi intermedi;

B. bilanci di previsione con dati alimentati da:

• consuntivo anno precedente;

• contabilità generale;

• contabilità analitica;

• budget;

• caricamento da dati esterni (per es. previsione dei servizi);

• movimentazioni di scritture extracontabili;

• simulazioni delle scritture di chiusura di bilancio (ammortamenti…..)

C. modelli ministeriali CE trimestrali con le modalità previste per i bilanci di verifica infrannuali;

D. generazione dei tracciati per l’alimentazione del Sito Ministeriale NSIS in relazione ai CE preventivi, trimestrali, consuntivi e SP consuntivi;

E. report di confronto con variazioni assolute e percentuali (es. dati di consuntivo, preventivo, preconsuntivo);

F. riclassificazione dei bilanci secondo i modelli regionali e ministeriali (Decreto Ministeriale del 15/06/2012), e secondo gli schemi di cui al Decreto legislativo 118/2011 come modificato dal Decreto Interministeriale 20/03/2013;

Le funzioni di interrogazione e reporting, sia di dettaglio sui movimenti che aggregate sui saldi devono consentire di esaminare tanto i dati effettivi che quelli extracontabili.

Il sistema deve essere in grado di consolidare le elaborazioni di cui ai punti A, B e C, e storicizzarle in modo da consentire il confronto con analisi e verifiche effettuate in periodi successivi (per esempio in occasione di CE trimestrali, verifiche trimestrali, verifiche straordinarie ecc...).

Il sistema deve prevedere un iter di validazione e comunicazione dei dati (per esempio CE Ministeriali trimestrali, consuntivi, preventivi, SP Ministeriali consuntivi, dati per le verifiche straordinarie di bilancio) al livello regionale secondo le modalità previste al paragrafo 6.2.

4.8. MATRICE SCAMBI

Il sistema deve prevedere la gestione della matrice degli scambi economici e patrimoniali tra le Aziende Sanitarie della Regione Xxxxxx-Romagna compresa la GSA – Gestione Sanitaria Accentrata, al fine della elisione delle partite infragruppo per la redazione del bilancio consolidato sanitario a livello regionale. In particole deve:

A. gestire le informazioni contabili e extracontabili necessarie all’alimentazione della Piattaforma Regionale relativa agli scambi tra Aziende Sanitarie della Regione e la generazione dei relativi tracciati (flussi attivi) sia per i ricavi che per i crediti;

B. gestire le informazioni contabili e extracontabili necessarie per l’alimentazione della Piattaforma Regionale relativa agli scambi tra Aziende Sanitarie della Regione e la generazione dei relativi tracciati (flussi passivi) sia per i costi che per i debiti;

4.9. SISTEMA DI BUDGET

La procedura deve prevedere un sistema di budget suddiviso almeno per gestore delle risorse e fattori della produzione da acquisire (conto economico/patrimoniale).

Il caricamento dei dati di budget può avvenire mediante alimentazione manuale, mediante interoperabilità da procedure esterne e con generazione automatica partendo da consuntivi o “budget” precedenti moltiplicati per un fattore percentuale di incremento o diminuzione, anche frazionati rispetto all’importo annuo.

Il consumo del budget deve essere registrato ed alimentato dagli ordini, dai movimenti di carico e dalle fatture. Inoltre, il sistema deve prevedere delle misure di controllo che consentano di attivare warning/allert e/o blocchi parametrizzabili nel caso in cui vengano superati gli importi assegnati.

Il sistema deve garantire una reportistica che evidenzi l’andamento del consumo del budget, analisi di confronto di periodo nel medesimo esercizio o su più esercizi o rispetto a “proiezioni di consumo”, analisi di possibili criticità.

4.10. GESTIONE PROGETTI FINANZIATI

Il sistema di gestione dei progetti finanziati deve:

A. garantire per ogni singolo progetto la gestione almeno dei seguenti elementi:

• numerazione progetto;

• denominazione progetto;

• data apertura progetto;

• stato del progetto (aperto, chiuso);

• soggetto finanziatore;

• finanziamento erogato;

• atto di finanziamento;

• caratteristiche del finanziamento;

• centro di costo;

• costi diretti sostenuti nell’esercizio per conto economico e patrimoniale;

• costi generali aziendali da imputare, mediante opportuni coefficienti, ai singoli progetti;

B. garantire l’acquisizione delle informazioni dalla contabilità generale e dagli altri moduli;

C. prevedere la possibilità di effettuare imputazioni manuali di costi non automaticamente registrati;

D. consentire di qualificare il progetto come accantonabile, non accantonabile, riscontabile;

E. consentire la quantificazione della quota parte di finanziamento da accantonare a fondo per renderla disponibile negli esercizi successivi;

F. consentire la quantificazione della quota parte di finanziamento utilizzata per investimenti ai fini della determinazione delle scritture di rettifica dei contributi in conto esercizio;

G. prevedere, attraverso la gestione di appositi parametri, la generazione automatica delle seguenti scritture di fine esercizio:

• accantonamenti di quote inutilizzate dell’esercizio;

• risconti passivi;

• utilizzi di quote di contributi in conto esercizio inutilizzati di esercizi precedenti;

• rettifiche di contributi in conto esercizio per investimenti;

H. prevedere apposita reportistica per l’esposizione analitica e riepilogativa dei movimenti relativi a ciascun progetto, anche in funzione della stesura delle Tabelle della Nota Integrativa al bilancio d’esercizio.

4.11. CASSA ECONOMALE

Il sistema deve garantire la gestione delle casse economali di riscossione e pagamento con le seguenti caratteristiche:

A. garantire la gestione integrata con la contabilità generale e analitica delle casse economali di riscossione e pagamento, autonome e con propri registri contabili;

B. garantire che, relativamente alle entrate, siano assolte almeno le seguenti funzioni:

• registrazione e controllo dei movimenti di entrata e contestuale emissione del documento corrispondente all’incasso effettuato (fattura o ricevuta) debitamente quietanzato;

• blocco dei movimenti dopo la chiusura giornaliera della cassa;

• riepilogo dei movimenti di entrata;

• controllo in tempo reale sull’ammontare dell’incassato;

• redazione della distinta di versamento da effettuarsi al tesoriere, compresa la distinta degli assegni incassati;

• stampa del giornale di cassa;

• stampa rendiconto periodico con totali incassati ed elenco versamenti effettuati al tesoriere con l’indicazione degli importi e della data dei versamenti;

• generazione automatica delle relative scritture contabili per imputazione dei ricavi alla contabilità generale e analitica e l’alimentazione dei registri IVA.

C. garantire che, relativamente alle uscite, siano assolte almeno le seguenti funzioni:

• registrazioni e controllo movimenti di uscita delle casse economali;

• blocco dei movimenti dopo la chiusura giornaliera della cassa;

• controllo in tempo reale sulla disponibilità residua del fondo di cassa e segnalazione esigenza di reintegro;

• imputazione delle spese e controllo sulla disponibilità residua di budget;

• stampa del giornale di cassa;

• riepilogo dei movimenti di spesa, complessivo e per unità organizzativa richiedente;

• generazione automatica delle relative scritture contabili per imputazione dei costi alla contabilità generale e analitica;

D. elaborazioni per rispondere al debito informativo della resa del conto giudiziale.

4.12. ADEMPIMENTI FISCALI

4.11.1. Imposta sul valore aggiunto (IVA)

Il sistema deve garantire la gestione dell’imposta sul valore aggiunto (IVA) e, in particolare, deve:

A. consentire la gestione di più tipologie di attività IVA svolte dalle aziende sanitarie, articolate al loro interno, anche con più sezionali, in registri corrispettivi, IVA acquisti e IVA vendite; il riepilogo mensile IVA deve essere suddiviso anche per singola tipologia di attività IVA svolta;

B. gestire la liquidazione mensile complessiva ed il versamento dell'IVA a debito attraverso la compilazione del modello F24EP; inoltre, ai fini del versamento mensile, la procedura deve eseguire in automatico il calcolo del pro-rata (laddove esistente) e tenere conto degli adempimenti previsti in applicazione delle norme sullo Split Payment sia sull’attività istituzionale che commerciale;

C. gestire le informazioni necessarie per la predisposizione della dichiarazione IVA annuale, con l’eventuale adeguamento della quota di pro-rata;

D. gestire con contabilità separata l'attività commerciale svolta dall’Azienda al fine della detrazione IVA di cui all'art.19 ter D.P.R. 633/72. Di tale contabilità dovranno essere chiaramente individuabili le relative scritture contabili, non solo ai fini IVA, ma anche ai fini IRES;

E. prevedere automatismi di esigibilità IVA in relazione alla data di emissione dei relativi ordinativi di pagamento. Dovrà essere gestita in modo automatico la specificità relativa all'esigibilità dell'IVA in modo differito sia per le fatture passive che per quelle attive (ove previsto). L'inserimento nella liquidazione IVA mensile è infatti determinato non dalla data di

registrazione della fattura ma dalla data dell'ordinativo di pagamento/incasso. Una volta che la fattura in sospensione è divenuta esigibile al momento del suo pagamento, la procedura, automaticamente, dovrà trasferirla sull’apposito registro IVA esigibile, consentendo comunque l’individuazione delle fatture trasferite.

F. gestire l’IVA intra ed extra UE con apposite causali e sezionali IVA che ne consentano la rilevazione contabile sia mediante il metodo dell’integrazione su fattura che con il sistema dell’autofattura (laddove la normativa lo prevede); il sistema deve inoltre garantire che venga effettuata mensilmente la liquidazione dell’IVA da versare con apposito modello F24EP;

G. prevedere almeno i seguenti controlli:

• correttezza delle sequenze di numerazione sui registri;

• controllo dei “buchi di numerazione”;

• correttezza e preesistenza della Partita Iva sui Fornitori – Clienti;

• rapporto tra imponibile, % assoggettamento e imposta;

• imputazione a costo dell’Iva indetraibile.

H. permettere le seguenti stampe:

• registri IVA;

• registro riepilogativo sia complessivo che per singola tipologia di attività IVA;

• prospetto di liquidazione e i riepiloghi per la dichiarazione IVA annuale, suddivisi per tipologia IVA come da impostazione della Dichiarazione IVA annuale;

• prospetto di liquidazione dell’IVA dovuta in applicazione dello Split Payment.

I. consentire prima dell’esecuzione della stampa in definitivo dei registri IVA, apposite verifiche (anche con stampe provvisorie) per il controllo della numerazione delle fatture, dei codici Iva e della corretta liquidazione mensile sia per tipologia di attività che complessiva;

J. rendere le scritture contabili immodificabili a seguito della stampa definitiva dei registri.

4.11.2. Imposta sul reddito delle Società (IRES)

Il sistema deve garantire la completa gestione IRES e, in particolare, deve:

A. consentire la gestione di più tipologie di attività IRES;

B. gestire con contabilità separata l'attività commerciale svolta dall’Azienda ai sensi dell’art.144 comma 2, D.P.R.917/1986. Di tale contabilità dovranno essere chiaramente individuabili le relative scritture contabili;

C. gestire le informazioni necessarie per la predisposizione del bilancio commerciale;

D. prevedere la stampa di un libro giornale separato per l’attività commerciale ai fini IRES.

Il sistema può prevedere, inoltre, il calcolo dei costi promiscui e la generazione automatica delle relative scritture contabili.

4.11.3. Imposta di bollo

Il sistema deve garantire la gestione dell’imposta di bollo e, in particolare, deve:

A. garantire la regolarità nell’emissione dei documenti attivi;

B. prevedere automatismi di assoggettamento ed esclusione (es. assoggettare a bollo le fatture che riportano importi esenti/fuori campo IVA maggiori di Euro 77,47);

C. gestire separatamente le diverse modalità di assolvimento: Bollo virtuale e Xxxxx su documenti informatici;

D. prevedere strumenti di controllo e rendicontazione delle diverse modalità di assolvimento di cui al punto precedente;

E. gestire separatamente la liquidazione e il pagamento del bollo virtuale dal bollo su documenti informatici.

4.11.4. Imposta sul Reddito delle Persone Fisiche (IRPEF)

Il sistema deve garantire la completa gestione IRPEF.

La procedura di gestione del Sostituto d’imposta ha come obiettivi principali la gestione delle informazioni necessarie per la produzione delle Certificazioni Uniche e del modello 770, come previsto dalla normativa vigente.

A tal fine si rinvia a quanto specificato nel paragrafo 4.4 ”Fornitori soggetti a ritenuta d’acconto e anagrafe delle prestazioni”.

4.11.5. Imposta Regionale sulle Attività Produttive (IRAP)

Il sistema deve prevedere una completa gestione IRAP.

In particolare deve prevedere automatismi che semplificano la rilevazione e la gestione dei movimenti e della dichiarazione IRAP:

• rilevazione dell'imponibile IRAP e del debito IRAP attraverso l'integrazione del sistema regionale di Gestione delle Risorse Umane (GRU), per quel che attiene il lavoro dipendente e assimilato. Questo al fine di generare in automatico (o di acquisire le informazioni necessarie alla generazione) la dichiarazione annuale IRAP;

• rilevazione dell'imponibile e del debito IRAP, in fase di inserimento "manuale” di documenti che comportano anch'essi tale gestione.

Gli automatismi elencati dovranno garantire che il sistema, durante la fase di inserimento di detti documenti (es: rimborsi per personale comandato, fatture di agenzie per lavoro interinale, lavoro autonomo) effettui il caricamento dell'imponibile IRAP con contestuale scrittura automatica in contabilità del debito IRAP e predisponga tutti i dati necessari ai fini della compilazione della dichiarazione IRAP.

Inoltre, il sistema deve consentire sia la gestione dell’IRAP sull’attività istituzionale che commerciale.

4.13. CICLO ATTIVO

Il sistema deve prevedere la gestione della contabilità clienti e in generale il controllo di tutto il ciclo attivo direttamente o utilizzando i programmi di fatturazione delle diverse strutture operative aziendali, dovrà comunque gestire l’anagrafica, l’emissione delle fatture/note attive con alimentazione della Contabilità Generale e della Contabilità Analitica, la gestione incassi (da sportelli cassa aziendali, sportelli cassa esterni, conti correnti postali, macchinette riscuotitrici, Istituto Tesoriere) fino alla gestione dei solleciti e l’eventuale messa a ruolo.

Il sistema deve garantire che le operazioni relative al ciclo attivo siano il più possibile guidate sia ai fini della emissione della fattura, sia nella “scelta” dei sezionali IVA a seconda che si tratti di attività commerciale o di attività istituzionale, sia, infine, per la corretta allocazione ai conti di Contabilità Generale e Analitica, tenuto conto anche delle norme in essere sullo “Split – Payment”.

4.12.1. Emissione Fattura

Il sistema deve:

A. avere un modulo dedicato all’emissione dei documenti attivi anche in formato elettronico, sia fatture con IVA, che note di addebito proprie dell’attività istituzionale;

B. consentire l’emissione della fattura in formato elettronico in modalità integrata con il sistema regionale per la fatturazione elettronica NoTIER (Nodo Telematico di Interscambio Xxxxxx – Romagna) e secondo le specifiche tecniche definite nella sezione dedicata del portale dell’Agenzia Regionale per lo Sviluppo dei Mercati Telematici – IntercentER. Eventuali aggiornamenti tecnici che si renderanno necessari a seguito di circolari regionali, dovranno essere effettuati dall'aggiudicatario senza oneri aggiuntivi per il committente.

C. gestire e monitorare lo stato delle fatture elettroniche (emesse, inviate, accettate, rifiutate, conservate,….);

D. garantire che il modulo di fatturazione attiva preveda:

a. la gestione di diversi listini (a titolo esemplificativo Nomenclatore Regionale, Nomenclatore Aziendale, Attività Libero Professionale, Convenzioni tipo);

b. il collegamento dei listini sia al centro di ricavo (obbligatorio) che al cliente;

c. in fase di emissione fattura, prioritariamente, la proposta del listino associato al contratto, qualora non sia presente un contratto, al centro di attività e in seconda istanza al cliente. Dovrà comunque essere possibile modificare il listino applicato in sede di inserimento, tenendo traccia delle modifiche effettuate;

d. il collegamento con il modulo di magazzino, oltre appositi automatismi per la generazione delle fatture nel caso di cessione dei beni nei confronti dei soggetti singoli, aziende pubbliche e private, ai fini del rispetto delle norme vigenti (per esempio il riferimento dei DDT sulla fattura ecc..);

e. una gestione dei contratti in cui possono essere inseriti i dati del cliente, gli articoli facenti parte del contratto, il listino applicato, il centro di ricavo, la rilevanza ai fini IRES consentendo in fase di inserimento fattura l’utilizzo di tale sottoinsieme di informazioni;

f. che su tutti i documenti emessi sia presente il codice identificativo d'incasso compatibile con i sistemi di riscossione in uso presso l’Azienda (es. macchine riscuotitrici automatiche ecc..);

g. una funzione automatica di storno completo (nota di accredito o storno di nota di addebito) del singolo documento emesso chiudendo automaticamente la partita contabile di credito in fase di contabilizzazione;

h. la gestione automatica della data di scadenza della fattura sulla base delle condizioni di pagamento inserite nella parte anagrafica (cliente, contratto, ecc.);

i. la gestione di più scadenze o rateizzazioni sullo stesso documento;

j. l’esportazione verso procedure esterne: la soluzione proposta dovrà consentire l’esportazione dei dati atti ad emettere fatture attive da parte di altri sistemi in uso nell’Azienda;

k. l’acquisizione da procedure esterne di documenti attivi già emessi al fine della contabilizzazione in Contabilità Generale e Analitica, nonché l’aggiornamento automatico dei sezionali IVA vendite sui registri specifici;

l. l’acquisizione automatica dalle altre procedure aziendali, sulla base di tracciati predefiniti, delle informazioni necessarie per gestire la proposta di emissione della fattura;

m. la possibilità di effettuare scarichi a procedure esterne: l’applicativo dovrà prevedere la possibilità di trasferire a procedure esterne le informazioni relative alle fatture emesse (con tutti gli attributi rilevanti) e agli incassi effettuati (es. programma gestione Attività Libera Professione o stipendi);

n. che la fase di contabilizzazione generi automaticamente l’alimentazione della contabilità generale (sia per la parte commerciale che istituzionale), la contabilità analitica e i registri IVA;

o. la gestione delle eccezioni del conto di imputazione definite, in modo da consentire la corretta imputazione degli scambi fra aziende sanitarie della regione e delle prestazioni erogate nei confronti di enti pubblici, senza la duplicazione dell’articolo o la digitazione manuale del conto;

p. la gestione delle informazioni necessarie ai fini della predisposizione dei flussi relativi al modello 730 precompilato ai sensi del Dlgs.175/2014.

4.12.2. Gestione del Credito

Il sistema deve garantire la gestione del credito con le seguenti caratteristiche:

A. il sistema deve disporre di adeguati strumenti di controllo e prevedere per ogni cliente gestito una scheda riassuntiva di valutazione costituita da una serie di informazioni che consentono una rapida interpretazione dello stato del singolo credito e delle azioni intraprese (credito scaduto, stato del sollecito, pratica trasmessa all’ufficio legale, fallimento ecc..);

B. prevedere varie fasi di recupero parametrizzabili e personalizzabili dalla singola azienda per tipologia del credito, a titolo puramente indicativo: primo sollecito, secondo sollecito con raccomandata R/R, recupero coattivo (giudiziale o iscrizione a ruolo);

C. prevedere elaborazione dei tracciati necessari per l’iscrizione a ruolo secondo le modalità previste dal concessionario della riscossione);

D. prevedere il calcolo delle spese e degli interessi a carico del debitore;

E. nelle varie fasi di sollecito dovrà essere possibile generare automaticamente lettere/PEC di sollecito o diffida, contenenti l’addebito di eventuali rimborsi spese e il calcolo degli interessi maturati sulla base del tasso selezionabile;

F. i modelli di lettera/PEC e gli addebiti di spese e interessi dovranno essere personalizzabili tramite parametri per ogni diversa fase dell’iter procedurale;

G. l’applicativo deve consentire di memorizzare sulla pratica di sollecito informazioni utili come contatti telefonici intercorsi o note varie e allegare documenti quali fax o altro;

H. il sistema deve permettere di visualizzare/stampare lo scadenziario della pratica di recupero in funzione del relativo stato di avanzamento e richiamare visualizzazioni e/o stampe della situazione debitoria dei clienti.

4.14. CICLO PASSIVO

Il sistema deve prevedere tutte le operazioni contabili inerenti il ciclo passivo, a partire dal protocollo fatture passive con imputazione sui registri IVA, alimentazione della Contabilità Generale e della Contabilità Analitica sulla base delle informazioni connesse all’ordine ed al fattore produttivo, conto economico e/o patrimoniale, centro di costo, e rilevazione del debito verso il fornitore.

Il sistema deve garantire che le operazioni relative al ciclo passivo siano il più possibile guidate sia ai fini della registrazione della fattura, sia nella scelta del fornitore, nella scelta dei registri IVA a seconda che si tratti di attività commerciale o di attività istituzionale, sia, infine, per la corretta allocazione ai conti di Contabilità Generale e Analitica, tenuto conto anche delle norme in essere sullo “Split – Payment”.

4.13.1. Registrazione dei documenti passivi

Il sistema deve garantire che la gestione dei fornitori e dei documenti passivi preveda le seguenti caratteristiche:

A. consentire la ricezione della fattura in formato elettronico in modalità integrata con il sistema regionale per la fatturazione elettronica NoTIER (Nodo Telematico di Interscambio Xxxxxx – Romagna) e secondo le specifiche tecniche definite nella sezione dedicata del portale dell’Agenzia Regionale per lo Sviluppo dei Mercati Telematici – IntercentER. Eventuali aggiornamenti tecnici che si renderanno necessari a seguito di circolari regionali dovranno essere effettuati dall'aggiudicatario senza oneri aggiuntivi per il Committente;

B. gestire e monitorare lo stato delle fatture elettroniche (ricevute, accettate, rifiutate, conservate,….);

C. la registrazione della fattura passiva, nota debito o altro documento equivalente di richiesta di pagamento da parte del fornitore deve articolarsi nelle seguenti fasi:

• protocollazione, ovvero l’attribuzione al documento passivo della data di arrivo e del numero di protocollo attribuito dal sistema, con rilevazione della data di scadenza del documento;

• registrazione della testata della fattura, con individuazione del tipo di attività cui si riferisce e assegnazione del codice di protocollo;

• registrazione dei dati della fattura ai fini IVA (sia per attività istituzionale che commerciale);

• registrazione in contabilità generale sul conto di appartenenza (economico o patrimoniale) e rilevazione del debito nei confronti del fornitore; il sistema deve prevedere la possibilità di effettuare la registrazione in forma provvisoria con modalità automatiche di passaggio alla movimentazione definitiva al verificarsi di determinate condizioni (per esempio liquidazione fattura ecc…);

• gestire le eccezioni del conto di imputazione definite, in modo da consentire la corretta imputazione degli scambi fra aziende sanitarie della regione e delle prestazioni erogate senza duplicazione di budget o digitazione manuale;

• invio dei dati fiscali di registrazione al sistema NOTIER al fine di consentire la conservazione sul ParER secondo le specifiche disponibili nell’area dedicata del portale di IntercentER.

D. le note di accredito devono essere legate alle fatture cui competono;

E. il sistema deve garantire, attraverso funzioni specifiche, la registrazione contabile dei documenti passivi nella tipologia di attività cui si riferiscono: Attività Istituzionale, Attività Commerciale, Gestione Sociale (laddove esistente), e con le ulteriori suddivisioni al loro interno che si riterrà necessario impostare;

F. il sistema deve prevedere l’aggiornamento dei registri IVA acquisti e IVA in sospensione;

G. il sistema deve gestire lo Split Payment sia relativo all’attività istituzionale che commerciale;

H. il sistema deve gestire le ritenute di acconto;

I. il sistema deve prevedere la gestione del codice CIG o CUP;

J. il sistema deve gestire gli anticipi a beneficiari (es. per deposito) o a dipendenti (es. per spese viaggio) e la relativa chiusura;

K. il sistema deve garantire che la registrazione dei documenti passivi riferiti ai cespiti assicuri:

• la contabilizzazione provvisoria al conto delle immobilizzazioni in corso fino al superamento del collaudo, ove previsto;

• la sospensione della pagabilità fino al superamento del collaudo, ove previsto, e, successivamente al superamento dello stesso, la contabilizzazione automatica del cespite al conto patrimoniale di riferimento con storno dell’immobilizzazione in corso e l'aggiornamento nella gestione cespiti;

• il collegamento con la gestione dei finanziamenti in conto capitale;

L. tutte le modifiche relative alle scadenze delle fatture/note di credito dovranno essere trasferite in automatico sulle scritture di cessione già presenti e collegate alle partite contabili;

4.13.2. Liquidazione fatture

Il sistema proposto dovrà permettere il controllo e la verifica delle fatture dai rispettivi uffici competenti avendo la possibilità di interrogare e visualizzare i protocolli delle fatture o altri documenti di addebito di propria competenza.

Per i beni, il sistema proposto nella fase di controllo fatture dovrà effettuare la verifica di congruenza in valore fra i prodotti fatturati, consegnati e ordinati (fattura – ordine - D.D.T.).

I movimenti di carico dovranno poter essere valorizzati con il prezzo riportato in fattura, se diverso da quello indicato nell'ordine dovrà essere possibile variare direttamente il prezzo in fase di liquidazione con modifica contestuale del valore di magazzino ed aggiornamento del costo medio di acquisto, dell'ultimo prezzo di acquisto di ogni prodotto di magazzino, del ricalcolo del prezzo medio ponderato continuo e con la possibilità di effettuare la rivalorizzazione degli scarichi.

Per i servizi il sistema proposto nella fase di controllo fatture o altri documenti di addebito dovrà effettuare la verifica di congruenza in valore fra importi fatturati, ricevimenti dei servizi e ordini (fattura – ordine – movimento di carico).

Il sistema dovrà prevedere le seguenti funzionalità:

• gestione di una cartella contabile/dossier che permetta l’associazione di più documenti contabili ad una singola bolla o ricevimento del servizio e viceversa senza limite di numero;

• ricerca di un ordine e/o di una/un bolla/documento di trasporto o di un ricevimento di servizi a partire dagli estremi della fattura;

• estrazione di liste di documenti contabili secondo vari criteri di selezione (per periodo, per ufficio competente, per n. distinta, per conto economico ecc..);

• ricerca degli ordini collegati ad un progetto tramite codice di progetto e ricerca dei codici CIG/CUP dall'ordine.

Dovrà essere possibile indicare sulle fatture una scadenza diversa da quella standard, applicata per legge in relazione al fatto che il servizio ordinatore può avere motivazioni diverse per richiedere un pagamento con variabile tempo parametrizzabile e/o sospendere i termini di pagamento qualora ne ravvisi la necessità.

Dovrà essere possibile ottenere un’elaborazione contenente le fatture da ricevere, le note di accredito da ricevere, e per ciascuna il dettaglio di tutte le informazioni contabili necessarie, (almeno: fornitore, movimenti di carico, ordine, descrizione, importo, riferimenti contabili in merito al conto economico/patrimoniale, riferimenti contabili in merito al conto delle fatture da ricevere e note di credito da ricevere) a cui la nota di accredito o la fattura da ricevere si riferisce. Tale elaborazione deve costituire il dettaglio della/e scrittura/e contabile/i generata/e automaticamente di cui al punto I del paragrafo 3.5.

Il sistema deve, inoltre, prevedere strumenti di controllo idonei a garantire il monitoraggio nel corso dell’esercizio successivo o degli esercizi successivi delle fatture e note di accredito ricevute e registrate a fronte delle fatture da ricevere e note di accredito da ricevere di cui all’elaborazione suddetta.

Analoghe funzionalità di determinazione e controllo delle fatture da ricevere e note di accredito da ricevere dovranno essere garantite nel caso in cui i servizi siano gestiti con soluzioni diverse e/o alternative all’emissione dell’ordine e del ricevimento del servizio di cui al punto D della Gestione dei Servizi paragrafo 5.8.

Dovrà essere possibile parametrizzare il valore di discrepanza da bolla/ricevimento del servizio/autorizzazione al pagamento e fattura che consenta la liquidazione automatica.

Lo stato di “pagabilità”, quindi “liquido” del documento deve essere chiaramente evidenziato dalla procedura e lo stesso non può più essere modificato una volta emesso l’ordinativo di pagamento.

Il sistema deve guidare l’operatore nella contabilizzazione delle fatture passive in modo controllato dai parametri di sistema (anagrafiche, condizioni, tipi movimento) e deve essere integrato con le informazioni residenti e accessibili sul sistema degli ordini/ricevimenti (prezzi, quantità, ecc). Come struttura minimale l’applicativo deve:

• prevedere il caricamento della fattura e abilitazione al pagamento automatica quando si verificano le seguente condizioni: quadratura dei movimenti di carico (di beni e servizi) con l’importo della fattura, con previsione di livelli di discrepanza definiti ammissibili; quadratura dell’IVA e possibili verifiche automatiche;

• gestire automaticamente lo smistamento delle fatture elettroniche ai vari uffici liquidatori, qualora la liquidazione non sia automatica;

• prevedere il caricamento della fattura e abilitazione al pagamento affidata ad un diverso servizio aziendale che effettua la liquidazione contabile. Il sistema deve prevedere la

gestione del processo di liquidazione nelle varie fasi (verifica, conferma, autorizzazione/approvazione);

• prevedere soluzioni diverse e/o alternative all’emissione dell’ordine e del ricevimento del servizio per la gestione delle diverse fasi del processo di liquidazione dei servizi e relativo controllo (per esempio autorizzazioni al pagamento).

4.13.3. Registro Unico delle Fatture (RUF) – Piattaforma Certificazione dei Crediti del MEF (PCC)

Il sistema deve essere in grado di produrre il registro unico delle fatture – RUF - così come previsto dal DL 66/2014 e successive modifiche.

Inoltre, il sistema deve consentire, dopo aver eseguito tutti i controlli e le quadrature dei dati, la generazione dei flussi necessari all’alimentazione della Piattaforma per la Certificazione dei Crediti del MEF secondo quanto previsto dall’art.7-bis del DL 35/2013 e sms e dalle Circolari Ministeriali. Il sistema deve essere in grado di gestire gli esiti degli invii alla PCC consentendo, in caso di esito negativo, di rielaborare il flusso limitatamente ai record scartati al fine di un successivo reinvio.

Tale attività dovrà essere prevista tramite Web Service.

4.13.4. Cessione del Credito

Il sistema deve gestire la cessione del credito con le seguenti caratteristiche:

A. la cessione del credito pro-soluto deve poter essere gestita secondo diverse modalità (chiusura automatica partita del cedente sul cessionario al momento dell'introduzione del movimento), in maniera massiva con selezione multipla (per tutte le fatture di un fornitore) o puntuale (fattura per fattura);

B. la cessione del credito pro-solvendo deve poter essere gestita mediante l’individuazione del cessionario e della modalità indicata dallo stesso. In tal caso sarà modificata la modalità di pagamento in maniera massiva con selezione multipla (per tutte le fatture di un fornitore) o puntuale (fattura per fattura), senza chiusura del documento;

C. la procura all’incasso deve essere gestita con modalità analoghe alla cessione del credito pro-solvendo purché sia distinguibile dalla stessa;

D. il sistema deve garantire una reportistica a supporto dell’analisi di tali operazioni contabili;

E. il sistema dovrà permettere di adempiere ai controlli imposti dalla normativa vigente;

F. il sistema dovrà inoltre mantenere disponibile, per le interrogazioni a sistema e per la reportistica sulle partite aperte e sui pagamenti, l’informazione del soggetto cedente;

G. il sistema dovrà permettere la distinzione del credito pro-soluto e pro-solvendo e il pagamento per procura e tale distinzione dovrà essere gestita anche nelle estrazioni/statistiche previste per gli utenti.

4.13.5. Portale Fornitori

Il sistema dovrà prevedere uno “Sportello virtuale per il fornitore” accessibile via internet con le seguenti caratteristiche:

A. accesso da parte del fornitore in qualunque momento a dati e attività che lo riguardano (es. stato fatture emesse e storico dei pagamenti effettuati);

B. accesso ad un numero illimitato di fornitori;

C. invio automatico di mail di notifica.

4.13.6. Indicatore dei Pagamenti

Il sistema deve garantire il calcolo dell’indice di tempestività dei pagamenti secondo parametri preimpostati e nel rispetto della normativa vigente nazionale in merito agli obblighi sulla trasparenza e gli obblighi informativi nei confronti del livello regionale.

4.15. GESTIONE DELLA CASSA

Il sistema deve garantire la gestione della cassa e deve essere in grado di:

A. acquisire in automatico le scritture del giornale di cassa dal flusso prodotto dal tesoriere alimentando:

• conto di tesoreria;

• conto provvisori di uscita;

• conto provvisori di entrata;

consentendo in tal modo l’allineamento automatico tra scritture del tesoriere e scritture contabili;

B. consentire inoltre un'integrazione con il Tesoriere, al fine di assolvere gli adempimenti per il controllo interno e per quelli di tipo informativo previsti dalla vigente normativa; dovrà inoltre permettere il confronto fra la situazione di cassa e quella presentata dalla Banca Tesoriere, nonché la stampa del giornale di cassa;

C. gestire la programmazione della cassa mediante simulazioni estrapolate da dati già presenti in procedura (es. pagamenti in scadenza) e da dati inseriti manualmente (es. previsione rimesse regionali o altre entrate) secondo uno schema da definire in sede di esecuzione del contratto;

D. monitorare l’andamento delle riscossioni e dei pagamenti rispetto alla programmazione effettuata;

E. elaborare reportistica o ricerca rispetto a sospesi da regolarizzare.

4.14.1. Gestione dell’incasso

Il sistema deve garantire la gestione degli incassi con le seguenti caratteristiche:

A. presentare in fase di regolarizzo dei provvisori d’entrata, l’elenco di quelli da regolarizzare (acquisiti in automatico dal Tesoriere);

B. consentire la regolarizzazione di più provvisori su un unico documento e viceversa;

C. non deve essere possibile l’emissione della reversale che regolarizza parzialmente un provvisorio;

D. gestire la reversale collegata a un mandato commutabile in quietanza d’entrata (da utilizzare nelle compensazioni fra enti pubblici);

E. gestire l’elaborazione e la trasmissione della reversale informatica tramite la produzione di un file secondo le specifiche tecniche definite dal tesoriere. Il sistema deve garantire la produzione del file e apposizione di firma digitale direttamente dalla procedura contabile;

F. gestire il codice SIOPE, da ricavare, con opportuni automatismi, dal conto di contropartita economica e/o patrimoniale o alimentabile manualmente solo quando non sia possibile l’attribuzione automatica; il codice SIOPE andrà esposto nell'ordinativo;

G. prevedere l’estrazione di riepilogo degli ordinativi anche per codice SIOPE;

H. recepire le modifiche previste dal Codice dell’Amministrazione Digitale per l’effettuazione dei pagamenti elettronici a favore delle pubbliche amministrazioni e dei gestori di pubblici servizi, integrandosi con i futuri canali di pagamento.

4.14.2. Gestione del Pagamento

Il sistema deve garantire la gestione del pagamento con le seguenti caratteristiche:

A. verifica dello stato di pagabilità del documento;

B. gestione dello scadenziario per la programmazione dei pagamenti mensili;

C. il pagamento deve essere predisposto attraverso un procedimento automatico che consenta di gestire le priorità di pagamento mediante appositi criteri parametrizzabili:

• fasce di importi;

• data di scadenza;

• tipologia dei fornitori;

• tipologia dei fattori di produzione (individuati dai conti XX.XX).

D. il sistema dovrà prevedere le funzionalità per la gestione dei codici CIG e CUP al fine di garantire la tracciabilità dei pagamenti (legge 136/2010);

E. il sistema dovrà prevedere la modifica massiva dei dati presenti su partite al fine dell’emissione dei mandati di pagamento (es. variazione coordinate bancarie);

F. il sistema dovrà consentire l’importazione dall’esterno di dati per la generazione automatica dei beneficiari, delle relative modalità di pagamento e dei mandati di pagamento;

G. il sistema deve prevedere automatismi per adempiere agli obblighi di legge in merito alla verifica della regolarità del DURC;

H. il sistema dovrà prevedere automatismi per adempiere agli obblighi di legge sulla verifica e sul controllo delle posizioni debitorie;

I. in fase di estrazione dei documenti da pagare dovranno essere segnalate eventuali anomalie rispetto alle modalità di pagamento (es. IBAN mancante od incompleto);

J. i pagamenti effettuati devono essere contabilizzati in un conto transitorio che deve successivamente essere quadrato con i pagamenti confermati da parte della Tesoreria;

K. la trasmissione al Tesoriere degli ordinativi di pagamento dovrà avvenire tramite la produzione di file secondo le specifiche tecniche definite dallo stesso Xxxxxxxxx e finalizzato all’utilizzo degli ordinativi informatici nel rispetto della normativa vigente; il sistema deve garantire la produzione del file e apposizione di firma digitale direttamente dalla procedura contabile;

L. il sistema di pagamento deve gestire il codice SIOPE, da ricavare, con opportuni automatismi, dal conto di contropartita economica e/o patrimoniale o alimentabile manualmente solo quando non sia possibile l’attribuzione automatica; il codice SIOPE andrà esposto nell'ordinativo;

M. il sistema deve garantire la corretta gestione del codice SIOPE nel caso di applicazione dello Split Payment, ossia l’attribuzione del codice SIOPE con riferimento alla contropartita economica e/o patrimoniale (riferimento al conto del bene, del servizio o immobilizzazione) e non dell’IVA;

N. il sistema deve prevedere l’estrazione di riepilogo degli ordinativi anche per codice SIOPE.

4.16. SISTEMI AUTOMATICI DI SPEDIZIONE

L’applicativo deve prevedere l’integrazione con sistemi di spedizione automatizzata. In particolare:

A. gli spool di stampa devono poter essere prodotti, senza strumenti software di rielaborazione, nei principali formati standard presenti sul mercato (per es. per l’invio di lettere di sollecito, recupero crediti, comunicazioni ai fornitori, fatturazioni, Certificazione Uniche dei redditi);

B. il sistema deve essere in grado di recepire il flusso informativo di ritorno (esiti invio);

C. la documentazione (fatture, avvisi di pagamento, solleciti, certificazione unica dei redditi) deve poter essere spedita anche con fax e posta elettronica e PEC direttamente dal sistema.

5. GESTIONE MAGAZZINI E SERVIZI

5.1. PREMESSA

L’assetto dei processi di Supply Chain e di logistica operativa in atto all’interno della Regione Xxxxxx Xxxxxxx, l’implementazione operativa dei magazzini di area vasta (AVEN), della Azienda Unica di Romagna e i progetti in atto di progressiva concentrazione in AVEC, suggeriscono che il presente documento assuma una visione prospettica e consideri gli aspetti strategici che la Regione stessa vorrà implementare. In tale contesto, risulta necessario prevedere tutte le funzionalità utili alla gestione separata del magazzino commerciale.

Devono essere previste tutte le funzionalità che permettono di gestire le movimentazioni dei prodotti all’interno e al di fuori dell’Ente: carichi, scarichi, trasferimenti, storni, rettifiche, prestiti fra unità organizzative interne e prestiti fra struttura ed Enti esterni (il tutto di volta in volta anche per le merci in visione, in omaggio e con contratto estimatorio/conto deposito).

Il sistema deve prevedere tutte le funzionalità che permettano la gestione di modelli differenti di stock management (modello a intervallo di riordino fisso, modello a livello di riordino fisso, a consumo/replenishment).

Oltre alle transazioni standard previste dalla procedura dovrà essere consentito all’utente di introdurne di nuove definendone il tipo e le modalità con cui la transazione deve operare.

I principali report richiesti:

• capienza residua del budget assegnato per classe/fattore produttivo;

• riepilogo consumi con vari criteri: magazzino, periodo, articolo, CdC, tipo di transazione, classificazioni, ecc. con confronto pari periodo anno precedente;

• indice di rotazione secondo immissione parametri relativi;

• analisi ABC (Pareto) per quantità e valore;

• elenco disponibilità economiche per contratto;

• stampa di quadratura della contabilità di magazzino con indicazione dei ricavi e costi per le giacenze;

• Il sistema deve rendere possibile il monitoraggio degli articoli sotto scorta attraverso l’utilizzo di appositi filtri.

5.2. GESTIONE CONTRATTI

Il modulo deve prevedere la gestione almeno delle seguenti informazioni, che, in parte verranno acquisite dalla Piattaforma di e-procurement di Intercent-ER:

A. data Creazione Contratto;

B. data validità contratto (un campo “dal” ed un campo “al”);

C. codice contratto;

D. anno contratto;

E. descrizione contratto (senza limiti di testo);

F. servizio autorizzato alla modifica del contratto;

G. abilitazioni utente specifiche per la modifica del contratto in base al servizio gestore del contratto;

H. codice e descrizione fornitore;

I. indicazione se si tratti di acquisto in economia, rdo, accordo quadro, proroga, rinnovo, ecc.;

J. indicazione se si tratti di contratto creato per acquisto in danno. In questo caso il sistema software dovrà consentire di effettuare ordini tenendo in considerazione gli aspetti a cui gli acquisti in danno si riferiscono ad es. l’erosione dell’importo del contratto originario a cui l’acquisto in danno si riferisce per la parte relativa al valore del contratto del fornitore aggiudicatario della gara, ecc.;

K. importo totale del contratto, con l’opzione che tale campo sia compilabile a mano o calcolato in automatico analizzando le singole righe di contratto;

L. importo indicato riferito all’imponibile, prevedendo l’indicazione dell’ammontare dell’IVA in un campo dedicato; il sistema di verifica della disponibilità economica sul contratto dovrà, quindi, distinguere gli ordini emessi in attività istituzionale da quelli in attività commerciale, decurtando conseguentemente l’importo relativo alla disponibilità residua del contratto;

M. campo note storicizzato in base ad ogni modifica dell’importo del contratto;

N. indicazione se il contratto è esclusivo ossia che i prodotti in esso contenuti siano acquistabili solo all’interno di quello specifico contratto, se valido;

O. indicazione se il contratto è vincolato ossia i prodotti in esso contenuti siano acquistabili solo da quel fornitore, se il contratto è attivo;

P. importo bloccabile: ossia che in fase di ordine se si acquista più di quanto previsto nella disponibilità del contratto, non sia possibile ordinare (come somma degli ordini già emessi più quello che si cerca di emettere);

Q. quantità bloccante: ossia non sia possibile ordinare una quantità superiore a quanta indicata nel contratto (come somma degli ordini già emessi più quello che si cerca di emettere);

R. CIG;

S. CUP;

T. delibera di riferimento;

U. giorni (naturali continuativi) entro i quali il fornitore dovrà consegnare il materiale ordinato in regime ordinario ed in urgenza;

V. minimo ordinabile per contratto;

W. sconti previsti;

X. tempi di approvvigionamento normali ed in urgenza;

Y. penale (sotto forma di formula applicabile).

All’interno del contratto dovranno essere inserite le singole righe di prodotti (beni e servizi).

Per ciascuno prodotto dovrà essere possibile indicare codice, descrizione, quantità, prezzo, iva, minimo ordinabile; prodotti omaggio (si precisa che all’interno di uno stesso ordine lo stesso codice articolo potrà essere gestito sia in omaggio sia a prezzo diverso da zero).

Si ricorda che all’interno del contratto dovrà essere possibile inserire i componenti di un eventuale kit con il relativo prezzo di acquisto e volendo anche il codice kit con il relativo prezzo ottenuto automaticamente dalla somma dei prezzi dei componenti del kit.

Dovrà essere possibile importare da altri file i contratti nuovi e modificare i contratti già esistenti solo per i campi modificati.

Si precisa, inoltre, che:

• a ciascun articolo dovranno essere associabili singoli file immagine e/o testo senza limiti di dimensioni;

• dovrà essere possibile dall’anagrafica del prodotto poter risalire direttamente al consumo storico con la possibilità di visualizzazione grafica dei risultati;

• dovrà essere possibile gestire i kit di prodotto, quindi dovrà essere possibile codificare i singoli pezzi del kit singolarmente e produrre successivamente anche il codice kit che li raggruppa. Tale sistema di gestione kit dovrà essere accessibile sia in fase di gestione del contratto e dell’ordine sia in fase di approvvigionamento, di richiesta da reparto, di ricevimento da fornitore e di preparazione a magazzino;

• devono essere garantite la gestione e l’aggiornamento delle catene di equivalenza;

• devono essere garantiti la gestione e l’aggiornamento dei prodotti sostitutivi;

• deve essere definito il magazzino in cui è gestito.

Per ciascun magazzino in cui il prodotto è gestito dovranno essere rese disponibili, a titolo esemplificativo, le seguenti informazioni:

• quantità di pezzi minima distribuibile;

• punto di riordino;

• scorta minima;

• scorta massima;

• CDC da disabilitare in caso in cui non sia autorizzata la consegna di quello specifico prodotto a quello specifico cdc (tale funzione dovrà essere semplice, efficace ed efficiente sia per la parte di abilitazione che di disabilitazione);

• richiedibilità da reparto;

• ordinabilità a fornitore;

• qualsiasi eventuale ulteriore attributo specifico che consenta la selezione di altri processi trasversali;

• indicazione classe di appartenenza ABC (metodo Pareto);

• quantità minima ordinabile a fornitore;

• tipo di gestione a magazzino (scorta/transito/conto deposito/Conto visione, ecc.);

• tipo di gestione dell’approvvigionamento (a punto di riordino, a ripristino di livello, per commessa);

• tipo gestione (consumo, prestazione);

• tipo di gestione del lotto: dovrà essere possibile selezionare: gestione senza lotto e scadenza, gestione solo lotto; gestione solo scadenza; gestione lotto e scadenza;

• prezzo ultimo ordine riferito al magazzino di riferimento;

• l’indicazione della necessità di una richiesta motivata.

5.3. GESTIONE RICHIESTE/PRESCRIZIONI

Il sistema deve prevedere la possibilità di gestire il magazzino delle unità di prelievo (es. reparto), sia per la gestione dei movimenti di carico che di scarico, l’emissione di richieste di fornitura dal magazzino, la gestione di resi e l’inventario del materiale giacente nelle unità di prelievo.

5.3.1. Richiesta di approvvigionamento dall’unità di prelievo

Il sistema proposto, in particolare per la gestione degli approvvigionamenti di magazzino e di riordino dei reparti dovrà utilizzare algoritmi di ottimizzazione dei consumi e di riduzione della giacenza in ottica di gestione con Livelli Obiettivo e di gestione più efficiente della spesa.

Il sistema dovrà prevedere la possibilità di immissione di richieste che possono rimanere pending nel sistema e la loro conseguente gestione.

Il sistema dovrà prevedere la gestione del calendario di consegna informatizzato, comprensivo di eventuali cut off orari.

Si dovrà prevedere la funzionalità di quantità massima richiedibile, calcolata sulla base di algoritmi di deviazione standard.

Le caratteristiche fondamentali della gestione di richieste di approvvigionamento possono riassumersi come segue:

• devono essere gestite le richieste informatizzate dall’unità di prelievo, con la possibilità di configurare le unità di prelievo con differenti gradi di accesso (es. solo alcuni prodotti richiedibili);

• il processo di redazione ed approvazione deve essere effettuato on line;

• facilità e velocità di immissione on-line: il processo di digitazione a schermo di una RdA deve essere semplice e richiedere tempi limitati; deve essere altresì possibile la riemissione, nel caso una RdA non procedesse come previsto o la cancellazione di RdA sbagliate;

• deve essere sempre possibile verificare lo stato di approvazione dell’RDA, consentendo di seguire l’avanzamento della richiesta;

• all’atto dell’immissione della RDA deve essere effettuato il controllo (opzionalmente bloccante) della disponibilità di budget per singolo CdC.

Dovranno essere possibili tutti i tipi di richieste che verranno specificate in fase di esecuzione del contratto, in particolare dovranno essere possibili richieste ordinarie, urgenti, in emergenza.

Dovrà essere prevista la gestione di richieste di materiale a scorta, a transito, in conto deposito, richieste motivate personalizzate, ecc..

Dovranno essere previste le richieste informatizzate anche per gestire tutti i processi di reverse logistics (sia da reparto che a fornitore). Tali richieste dovranno verificare anche la coerenza dei lotti e scadenze eventualmente indicati con quanto consegnato in precedenza a quello specifico centro di costo.

Per ciascuna richiesta dovrà esser possibile mostrare, o meno, il costo relativo ai materiali richiesti e la giacenza presso i magazzini a cui il cdc è abilitato, configurabile per magazzino.

Una volta che la richiesta sia stata completata, essa viene trasmessa all’approvatore. Deve essere possibile definire una o più gerarchie di persone le quali hanno la facoltà di approvare le richieste e gli ordini fino a limiti di spesa predefiniti, e/o per famiglia di articoli. Tale definizione deve essere elastica e modificabile nel tempo a seconda delle modalità organizzative stabilite.

Tutte le attività di approvazione dei documenti che riguardano il ciclo degli acquisti deve essere effettuata on line, con la possibilità da parte dell’approvatore di visualizzare il dettaglio del documento sottoposto a verifica con evidenziazione di eventuali anomalie.

5.3.2. Tracciabilità delle consegne all’unità di prelievo

Il sistema deve garantire la gestione del workflow dallo scarico del magazzino alla consegna all’unità di prelievo, con l’evidenza delle varie fasi del processo oltre a prevedere più stati relativi al processo di accettazione (ad esempio accettazione con riserva, accettazione parziale, controllo). Il sistema deve, inoltre, prevedere la possibilità di considerare accettati i beni consegnati allo scadere di un arco temporale predefinito (configurabile per ambito aziendale).

5.4. GESTIONE ORDINI

5.4.1. Algoritmi di gestione Scorte (Scorta Minima;Punto di Riordino)

Il sistema dovrà consentire, per il materiale gestito a scorta, il calcolo dei livelli di scorta minima (SM) e di punto di riordino (ROP) partendo dall’analisi di un periodo di indagine dei consumi (dal, al), considerando un valore di giorni di copertura della SM e un tempo di approvvigionamento (LeadTime) dei fornitori (dinamico o meno*). Tale fase deve possedere le caratteristiche di versatilità massima rispetto alla identificazione dei prodotti, o aggregazioni di prodotti, oggetto dell’analisi stessa.

*il concetto di dinamico o meno si esplicita nella possibilità che il Lead Time del fornitore non sia un dato contrattuale/di prassi ma sia un valore calcolato (data invio ordine di fornitura-giorno consegna).

5.4.2. Gestione Ordini

Per gestione degli ordini si intende in senso più lato tutta la gestione del ciclo degli acquisti, di beni e servizi, dalla richiesta di acquisto fino all’abbinamento delle fatture con l’ordine o con i documenti di trasporto.

Il sistema deve garantire l’emissione degli ordini in formato elettronico in modalità integrata con il sistema regionale NoTIER (Nodo Telematico di Interscambio Xxxxxx – Romagna) e secondo le specifiche tecniche definite nella sezione dedicata del portale dell’Agenzia Regionale per lo Sviluppo dei Mercati Telematici – IntercentER. Eventuali aggiornamenti tecnici che si renderanno necessari a seguito di circolari regionali dovranno essere effettuati dall'aggiudicatario senza oneri aggiuntivi per il Committente;

Tutte le fasi del ciclo devono essere gestite in modo integrato dalla procedura.

Negli ordini dovrà essere possibile indicare almeno tutte le informazioni utili alla generazione elettronica degli stessi secondo le specifiche suindicate. Inoltre, devono poter essere registrati anche ad esempio:

• Sigla operatore che ha creato l’ordine

• Sigla operatore ultima modifica

• Riferimento al preventivo – numero e data

• Tipo pagamento con possibilità di impostare rateizzazione

L’ordine d’acquisto può essere generato automaticamente dalla RDA (opportunamente differenziate per beni, cespiti e servizi), generato da un processo di suggerimento d’acquisto o inserito manualmente.

Il sistema deve garantire:

• calendario automatico di elaborazione pre-ordini parametrizzabile per:

a. gruppi di prodotti

b. fornitori

c. periodo

• possibilità di vedere tutti gli acquisti effettuati presso un fornitore particolare –

REPORTISTICA;

• creazione rapida degli ordini, semplicemente immettendo fornitore, prodotti;

• gestione di molteplici diverse tipologie di ordini: ordini standard, ordini aperti, contratti, ecc.;

• creazione di ordini standard e “rilasci” di ordini aperti da RdA on line e su carta;

• determinazione automatica del prezzo in base al listino fornitore (o all'ultimo prezzo), percentuale Iva, sconti (fino a due);

• possibilità di specificare sull'ordine il luogo di consegna dei prodotti o dei servizi e altre informazioni rilevanti (persona da contattare, numero di telefono, orari ecc…);

• controllo della disponibilità Budgetaria sul fattore/centro di costo al momento della creazione dell’ordine;

• gestione dello stato di un ordine: da autorizzare, bloccato, annullato, evaso, ecc.;

• rendere opzionale la possibilità o meno di emettere un ordine anche senza disponibilità di budget o di contratto;

• possibilità di saldare/chiudere ordine inevaso o evaso parzialmente.

La procedura dovrà quindi essere in grado di acquisire informazioni dai principali sistemi di acquisto tra cui INTERCENTER e CONSIP relativamente all’acquisizione dei dati di gare aggiudicate e alla possibilità di gestire gli ordini mediante la procedura ordini aziendale e il collegamento di tale sistema con il magazzino aziendale.

Il sistema dovrà prevedere la numerazione automatica degli ordini a inizio anno a livello aziendale senza sovrapposizioni numeriche.

Il sistema in particolare per alcune tipologie di ordini dovrà gestire informazioni aggiuntive specifiche dell'ordine. Ad esempio per ordini relativi a manutenzioni di attrezzature sanitarie e/o informatiche dovrà essere prevista la gestione di:

• numero di inventario apparecchiatura/cespite;

• numero di chiamata/ticket;

• classe apparecchiatura biomedica – Codifica CIVAB.

L’ordine di un cespite bene mobile deve contenere una o più righe di articoli ordinati. A ciascuna riga di articolo deve essere attribuita una descrizione, una tipologia, un centro di costo e una localizzazione e deve essere trasformato automaticamente in cespite (aggregato o modulo) e successivamente creato un numero di inventario unico regionale (IUR). Con lo IUR dovrà essere possibile creare un’etichetta con codice a barre e/o RFID.

5.5. GESTIONE ATTIVITA’ DI XXXXXXXXX

Il sistema proposto dovrà prevedere anche le funzioni riportate di seguito.

5.5.1. Ricevimento merce

Il sistema dovrà permettere in fase di ricevimento di :

• acquisire in modalità strutturata i dati del documento di trasporto elettronico ricevuti in modalità integrata con il sistema regionale NoTIER (Nodo Telematico di Interscambio Xxxxxx – Romagna) e secondo le specifiche tecniche definite nella sezione dedicata del portale dell’Agenzia Regionale per lo Sviluppo dei Mercati Telematici – IntercentER;

• richiamare l’ordine;

• caricare il materiale ricevuto, fatti i controlli quali-quantitativi, in modo diretto o con specifica fase di precarico;

• prevedere una fase di conferma delle quantità caricate;

• effettuare carichi secondo parametri predefiniti per ciascun magazzino.

Dovrà essere possibile effettuare il controllo del consegnato e la riconciliazione a diversi livelli: ordine, documento di trasporto e fattura.

La gestione di alcune caratteristiche imprescindibili della filiera di approvvigionamento di beni sanitari dovrà trovare adempimento, quale ad esempio la gestione di controlli/avvisi relativi ai blocchi all’ingresso per ordini/prodotti/lotti in regime di recall, in regime di quarantena o comunque in fase di sospensione/fermo di distribuzione della struttura ricevente.

5.5.2. Preparazione Merce

Per ogni articolo dovranno essere previste una o più locazioni di stoccaggio dinamiche per materiali in “stock” con gestione di specifiche sotto aree di magazzino (area bunker, frigo, ecc).

Predisposizione alla lettura di codici a barre relativi alla precedente fase e conseguente processo di suggerimento del lotto/scadenza da prelevare.

5.5.3. Spedizione Merce

Permettere la creazione e la trasmissione di documenti di trasporto elettronici in modalità integrata con il sistema regionale NoTIER (Nodo Telematico di Interscambio Xxxxxx – Romagna) e secondo le specifiche tecniche definite nella sezione dedicata del portale dell’Agenzia Regionale per lo Sviluppo dei Mercati Telematici – IntercentER in relazione al centro di costo richiedente, con l’indicazione di tutte le informazioni previste a norma di legge.

I movimenti di scarico di magazzino dovranno essere valorizzati secondo differenti modalità che potrà differire per ogni singola azienda (es. valore di listino, prezzo medio ponderato continuo, ecc.).

5.5.4. Non conformità di servizio

Si dovranno poter trattare gli indicatori di performance presenti nei contratti di servizio (IntercentER, Area Vasta, singola azienda). A titolo di esempio: l’indice di completamento dell’ordine (OFR-Order Fill Rate) e i ritardi di consegna relativi ai singoli articoli (LIFR Line Item Fill Rate) presenti nei contratti informatizzati.

Dovrà essere integrato nei suddetti calcoli un calendario italiano ed estero collegato alle anagrafiche fornitori ed al modulo ordini che dovrà tener conto delle festività principali.

Parimenti dovrà essere gestibile l’applicazione della penale agli eventi di non conformità di servizio per la quantificazione economica della non conformità sul periodo di tempo imputato.

Dovranno, inoltre, poter essere gestiti periodi di indisponibilità dei prodotti se presenti comunicazioni specifiche dei fornitori in tal senso. Dovrà essere possibile gestire l’inserimento di tali indisponibilità collegate ai prodotti con specifici requisiti:

• articolo oggetto della indisponibilità;

• data di presunta fine indisponibilità;

• sostituto nel periodo di indisponibilità.

Dovrà essere prevista l’emissione di comunicazioni automatiche, con testi predefiniti, nei confronti dei fornitori le cui performance saranno inferiori o superiori a determinate soglie di performance calcolate con gli indicatori di cui sopra o con indici di servizio riassuntivi.

5.5.5. Gestione “distinta base”

Il sistema dovrà consentire la gestione della “distinta base”, tenendo conto delle materie prime utilizzate per il prodotto finito, mantenendo l’associazione quantità/costi. Dovrà essere possibile la stampa dell’etichetta riportante i vari componenti del prodotto finito (es. gestione dei pasti, galenici, centro stampa, emoderivati).

5.6. CONTO DEPOSITO E SERVICE

Dovrà garantire una completa informatizzazione della gestione del materiale in conto deposito e del materiale in service attribuendo in modo puntuale i consumi sui corretti centri di costo e garantendone la tracciabilità (ad esempio attraverso l’uso di RFID e codici a barre) e sistemi automatici di riordino.

5.7. INVENTARIO DI MAGAZZINO/UNITA’ DI PRELIEVO

5.7.1. Valorizzazione delle rimanenze di magazzino e di unità di prelievo

Deve essere prevista la gestione automatica dell'inventario fisico con eventuali generazioni dei movimenti di rettifica delle giacenze per la riconciliazione del sistema contabile e fisico.

Dovrà essere possibile gestire l’inventario fisico in più modalità:

• completamente automatica: dovrà essere possibile utilizzare funzionalità (ad es. disponibili su palmari) che permettano la rilevazione selezionando il codice a barre articolo o il codice ubicazione per poter inserire e verificare immediatamente la corrispondenza fisico/contabile;

• semiautomatica: dovrà essere possibile generare un modulo, stampabile e compilabile a video, per la rilevazione dei dati relativi alle giacenze fisiche presenti.

Il sistema dovrà in ogni caso consentire di estrarre l’elenco dei prodotti da inventariare secondo le regole di gestione di magazzino più comuni. Ad es. dovrà essere possibile elaborare l’elenco dei prodotti da controllare in base ad un parametro che ne identifichi l’alto costo; oppure in base ai prodotti di classe A/B/C (metodo di Pareto), tale classe dovrà essere individuata sia in base al valore che alla quantità movimentata. Per ciascun prodotto elaborato in base ad esempio ai filtri sopra descritti dovrà essere indicata la quantità per ubicazione, il lotto, la scadenza ecc.

Dovrà essere possibile elaborare l’inventario e i controlli per l’inventario fisico sia per lotto e scadenza che solo per quantità.

Il sistema dovrà tenere distinti i tipi di richiesta di lotto da quelle di quantità. Nel caso di rettifiche di lotto il sistema dovrà consentire la rettifica dei lotti in più ed in meno nella stessa maschera ed effettuare una verifica di coerenza (somma algebrica delle quantità per prodotto uguale a zero) per portare a termine l’elaborazione. Dovrà inoltre essere possibili modificare lotto e quantità con un unico tipo di movimento che permetta di aggiornare contestualmente sia i lotti sia le giacenze.

Dovrà essere possibile elaborare il libro giornale di magazzino con tutte le informazioni previste dalla normativa vigente. Tale elaborazione dovrà essere stampabile su carta ed elaborabile su file non modificabile e dovrà poter essere sviluppata sia in modo provvisorio che definitivo.

5.7.2. Resi merce

Necessario tracciare in maniera informatica i resi da reparto e quelli a fornitore con possibilità di storno contabile dalla contabilità di reparto (istituzionale) o emissione di nota di accredito in caso di gestione commerciale. Per i resi a fornitori dovrà essere resa disponibile la stampa del documento di consegna al fornitore stesso.

Tale funzionalità deve essere implementata in modalità integrata con il sistema regionale NoTIER (Nodo Telematico di Interscambio Xxxxxx – Romagna) e secondo le specifiche tecniche definite nella sezione dedicata del portale dell’Agenzia Regionale per lo Sviluppo dei Mercati Telematici – IntercentER.

5.7.3. Ritiri e recall

Il sistema dovrà poter gestire, partendo da un inserimento informatico dei dati relativi ai ritiri e recall da effettuare (ad esempio numero comunicazione AIFA, prodotto, lotto, causale, ecc) in maniera centralizzata o a seguito di flusso dati proveniente da banca dati esterna (ad esempio AIFA), i dati relativi nelle fase di ricevimento merce (per pre segnalare ed evitare ingressi di merce oggetto di ritiri nella fase di distribuzione) e nella fase di reverse logistics ove presente (ritiri da reparto centralizzati).

5.8. GESTIONE DEI SERVIZI

Il sistema deve garantire l’esistenza di strumenti adeguati a gestire il processo di acquisto dei servizi sanitari e non sanitari.

In particolare il sistema deve:

A. prevedere una gestione dei contratti analoga a quella prevista al paragrafo 5.2;

B. garantire la possibilità di emettere ordini ai fornitori con modalità analoghe a quelle previste nel paragrafo 5.4.2, tenuto conto delle specificità proprie dei servizi (ad es. erogazione non in una data precisa, ma in un arco temporale; le unità di misura corrispondono a ore, giornate, mese, a consumo, a canoni predefiniti)

C. prevedere la gestione del servizio ricevuto, attraverso:

- richiamo dell’ordine;

- acquisizione dell’attestazione di erogazione del servizio da parte del fornitore (ad es. attraverso DDT semplificato);

- generazione di un movimento attestante il ricevimento del servizio;

D. prevedere soluzioni diverse e/o alternative all’emissione dell’ordine e del ricevimento del servizio (per esempio autorizzazioni al pagamento per assegni e sussidi);

E. garantire che indipendentemente dallo strumento utilizzato sia impegnato il budget assegnato, il contratto qualora esistente e la corretta alimentazione della contabilità analitica.

6. GESTIONE REGIONALE DEI DATI

6.1. PREMESSA

Il sistema richiesto si propone di uniformare il contesto amministrativo/contabile per tutte le Aziende Sanitarie regionali e di fornire una soluzione informatizzata volta a garantire le necessarie autonomie aziendali e al tempo stesso, consentire la realizzazione di sinergie gestionali, a livello sovra aziendale e regionale. Tale sistema deve essere in grado di rispondere alle esigenze amministrativo contabili di tutte le Aziende sanitarie regionali e allo stesso tempo di soddisfare le esigenze di sistema regionale tenuto conto sia delle richieste normative in tal senso (D.Lgs.118/2011) sia delle prossime evoluzioni degli assetti istituzionali regionali.

Il sistema deve rendere disponibile alla Regione Xxxxxx – Romagna i dati registrati dalle singole Aziende Sanitarie, con ampia possibilità di effettuare analisi ed elaborazioni finalizzate alla redazione del bilancio consolidato, riclassificazioni e reportistiche per soddisfare adempimenti informativi ai vari livelli (es. Ministero, Corte dei Conti). In particolare, il sistema deve consentire la gestione delle informazioni relative agli scambi tra Aziende Sanitarie della Regione e Gestione Sanitaria Accentrata finalizzata all’elisione delle partite infragruppo per la redazione del Bilancio Consolidato.

Inoltre, il sistema deve gestire i dati di contabilità analitica delle Aziende Sanitarie della Regione e della Gestione Sanitaria Accentrata per soddisfare gli adempimenti informativi regionali e ministeriali (es. COA01, Modello LA) e le elaborazioni dei costi pro-capite e la relativa reportistica regionale.

Da qui l’esigenza di gestire in un unico sistema tutte le informazioni e di prevedere un ambiente dedicato alla gestione dei dati ad uso esclusivo del livello regionale che acquisisca le informazioni automaticamente dai diversi moduli presenti nel sistema e permetta tutte le elaborazioni necessarie.

6.2. RICLASSIFICAZIONI

Il sistema deve rendere disponibili, attraverso appositi meccanismi di validazione dei dati da parte delle Aziende Sanitarie, le informazioni contabili relative a:

A. Conti economici preventivi, trimestrali e consuntivi delle singole Aziende suddivisi per conti regionali e aziendali;

X. Xxxxx patrimoniali consuntivi delle singole Aziende suddivisi per conti regionali e aziendali;

X. Xxxxx Economici Ministeriali (CE) preventivi, trimestrali e consuntivi delle singole Aziende;

D. Stati Patrimoniali Ministeriali (SP) consuntivi da parte delle singole Aziende.

Deve, inoltre, garantire:

A. interrogazione, estrazione e stampa analitica dei dati per conto economico e patrimoniale regionale e aziendale;

B. interrogazione e stampa analitica dei Conti Economici e Stati Patrimoniali delle singole Aziende, riclassificati secondo i modelli regionali, ministeriali (Decreto Ministeriale del 15/06/2012), e secondo gli schemi di cui al Decreto legislativo 118/2011 come modificato dal Decreto Interministeriale 20/03/2013;

C. elaborazione di una matrice che riporti i dati contabili organizzati secondo le seguenti modalità:

• per riga il codice del modello di riclassificazione prescelto;

• per colonna le Aziende Sanitarie;

D. ulteriori riclassificazioni dei dati necessari al fine di rispondere a esigenze informative regionali e ministeriali da definire in sede di esecuzione del contratto (per esempio riclassificato relativo alle sole voci (FR) del Fondo Regionale della non Autosufficienza);

E. analisi e stampe di confronto tra dati di preventivo, trimestrali e consuntivo, con variazioni assolute e percentuali.

6.3. BILANCIO CONSOLIDATO

Il sistema deve garantire la redazione del bilancio consolidato regionale ottenuto dalle contabilità delle singole Aziende Sanitarie e della Gestione Sanitaria Accentrata, previa elisione delle partite infragruppo.

A tal fine l’applicativo deve garantire:

A. oltre all’acquisizione dei dati di CE e SP Ministeriali delle Aziende Sanitarie di cui ai punti C e D del paragrafo 6.2, il caricamento da fonti esterne, nel medesimo ambiente dei dati di Conto Economico Ministeriale preventivi, trimestrali e consuntivi e dei dati di Stato Patrimoniale Ministeriale consuntivi della Gestione Sanitaria Accentrata fino a quando la componente GSA non sarà a regime;

B. l’acquisizione dei Rendiconti Finanziari validati dalle Aziende Sanitarie e dalla Gestione Sanitaria Accentrata;

C. l’acquisizione delle tabelle della Nota Integrativa validate dalle Aziende Sanitarie e dalla Gestione Sanitaria Accentrata;

D. l’acquisizione dei dati di CE e SP Ministeriali delle Aziende Sanitarie e della GSA dal Sito Ministeriale NSIS;

E. la gestione della piattaforma regionale relativa agli scambi tra Aziende Sanitarie della Regione alimentata dai flussi generati dalle Aziende Sanitarie, così come indicato al paragrafo 4.7 “Matrice Scambi”, attraverso opportuni percorsi di validazione e consolidamento dei dati. Tale gestione dovrà inoltre consentire:

a. l’acquisizione informatizzata dei flussi economici/patrimoniali attivi e passivi generati dalle Aziende sanitarie;

b. l’acquisizione informatizzata dei flussi economici/patrimoniali attivi e passivi generati da fonti esterne per la Gestione Sanitaria Accentrata fino a quando la componente GSA non sarà a regime;

c. la generazione di una matrice economica aziendale, di confronto dei ricavi e costi delle Aziende per singolo documento o per totali, per conto economico ministeriale e regionale con evidenza delle squadrature per Azienda, per singolo documento, per conto e per totale ricavi e costi;

d. la generazione di una matrice patrimoniale aziendale, di confronto dei crediti e dei debiti delle Aziende per singolo documento o per totali, per conto patrimoniale ministeriale e regionale con evidenza delle squadrature per Azienda, per singolo documento, per conto e per totale crediti e debiti;

e. la possibilità da parte delle Aziende Sanitarie di acquisire automaticamente attraverso un percorso autorizzato di abilitazione utenze le elaborazioni di cui al punto c) e d) limitatamente ai dati di propria competenza;

f. la generazione di una matrice economica regionale, di confronto dei ricavi e costi delle Aziende per singolo documento e per totali, per conto economico ministeriale e regionale con evidenza delle squadrature per Azienda, per singolo documento, per conto e per totale ricavi e costi;

g. la generazione di una matrice patrimoniale regionale, di confronto dei crediti e dei debiti delle Aziende per singolo documento e per totali, per conto patrimoniale ministeriale e regionale con evidenza delle squadrature per Azienda, per singolo documento, per conto e per totale crediti e debiti;

F. funzionalità finalizzate a controlli di coerenza dei dati, quali a titolo esemplificativo e non esaustivo:

a. verifica di corrispondenza dei CE e SP ministeriali validati dalle Aziende di cui al punto B e C con i dati inseriti nel Sito Ministeriale NSIS;

b. verifica di coerenza dei dati inseriti nella piattaforma regionale relativa agli scambi tra Aziende Sanitarie della Regione e GSA con i dati dei CE e SP ministeriali validati dalle Aziende e i dati inseriti nel Sito Ministeriale NSIS;

c. verifica di corrispondenza dei dati inseriti nelle Tabelle della Nota Integrativa con i dati dei CE e SP ministeriali validati dalle Aziende e dalla GSA;

d. verifica di corrispondenza dei dati inseriti nei rendiconti finanziari delle Aziende e della GSA con i dati dei CE e SP ministeriali validati dalle Aziende e dalla GSA oltre ai dati delle tabelle della Nota Integrativa.

G. funzionalità finalizzate alla redazione del bilancio consolidato:

a. rettifiche o integrazioni;

b. elisione delle partite infragruppo quali voci economiche codificate ( R ) di cui al Decreto Ministeriale del 15/06/2012 con possibilità di intervenire sugli importi;

c. elisione delle partite infragruppo quali voci patrimoniale codificate ( R ed RR ) di cui al Decreto Ministeriale del 15/06/2012 con possibilità di intervenire sugli importi;

d. prevedere apposite funzioni per la predisposizione automatica del rendiconto finanziario consolidato;

e. prevedere apposite funzioni per la predisposizione automatica delle tabelle della Nota Integrativa.

H. interrogazione e stampa analitica dei dati per conto economico ministeriale, regionale e aziendale;

I. interrogazione e stampa analitica dei Conti Economici e Stati Patrimoniali delle singole Aziende, della GSA e del Consolidato Regionale riclassificati secondo i modelli regionali, ministeriali (Decreto Ministeriale del 15/06/2012), e secondo gli schemi di cui al Decreto legislativo 118/2011 come modificato dal Decreto Interministeriale 20/03/2013;

J. analisi e stampe di confronto tra dati di preventivo, trimestrali e consuntivo, con variazioni assolute e percentuali;

K. generazione dei tracciati txt per l’alimentazione del Sito Ministeriale NSIS in relazione ai CE preventivi, trimestrali, consuntivi e SP consuntivi consolidati;

L. tutti i report dovranno prevedere la possibilità di effettuare l’estrazione degli stessi dati su foglio di calcolo, su formati aperti (txt, ods, cvs, ecc.) e pdf.

6.4. CONTABILITA’ ANALITICA

Il sistema deve:

A. gestire i piani di codifica relativi al COA01 e i fattori produttivi di cui al paragrafo 1.8;

B. gestire gli schemi dei modelli regionali COA01 e dei modelli ministeriali LA e relativi allegati;

C. prevedere la possibilità da parte delle Aziende Sanitarie di acquisire automaticamente attraverso un percorso autorizzato di abilitazione utenze gli schemi di cui al punto B);

D. acquisire i modelli COA01 compilati dalle Aziende Sanitarie e gli allegati del modello ministeriale LA;

E. acquisire il modello ministeriale LA delle singole Aziende Sanitarie, quale riclassificazione del modello COA01 (solo costi), avendo la possibilità di visualizzare tutti i passaggi intermedi;

F. prevedere controlli automatici, secondo determinati parametri, dei dati contenuti nei modelli regionali COA01 e nei modelli ministeriali LA e relativi allegati con le informazioni contabili contenute nei dati dei Conti economici consuntivi delle singole Aziende suddivisi per conti regionali e aziendali e nei Conti Economici Ministeriali (CE) consuntivi;

G. prevedere la possibilità di estrarre i dati contenuti nei modelli regionali COA01 e nei modelli ministeriali LA e relativi allegati;

H. garantire la gestione della piattaforma regionale di elaborazione del costo pro-capite e della reportistica regionale. A titolo esemplificativo si riportano le seguenti funzionalità richieste:

• gestione dei dati del COA01 con possibilità di rettifica automatica e manuale;

• gestione dei dati di popolazione;

• gestione dei dati contabili dei conti regionali (per esempio mobilità attiva, quota utilizzi contributi in conto capitale);

• elaborazione costi pieni e delle relative rettifiche e integrazioni;

• elaborazione costi pro-capite con evidenza dei passaggi intermedi per Azienda, per livello di assistenza e sul totale;

• reportistica regionale.

I. generazione dei tracciati per l’alimentazione del Sito Ministeriale NSIS in relazione ai modelli LA della GSA e del consolidato regionale.

Modalità analoghe dovranno essere previste per la gestione dei modelli CP (Costi Presidio), tenuto conto delle modifiche di legge in corso di approvazione.

7. INTEGRAZIONI

Il sistema deve potersi integrare attraverso i più comuni protocolli e metodologie riconosciute standard di mercato. E’ richiesta al sistema la capacità di integrazione tramite l’adozione di formati XML e dei protocolli di scambio da esso derivati (Web Services) per consentire il completo automatismo e impedire l’ accesso diretto al dato, nonché garantire il massimo livello di sicurezza.

Nel caso di integrazioni che prevedono accessi di sola lettura possono essere utilizzate anche delle viste di database con le opportune regole per garantirne la sicurezza. Il sistema deve consentire a seconda della tipologia di integrazione la definizione di tempi e modi del processo di integrazione: asincrono con cadenza prefissata e configurabile, sincrono (real-time) a fronte della variazione del dato.

Laddove non sia possibile garantire un’integrazione standard per le integrazioni in essere o per problematiche relative all’applicativo aziendale coinvolto, deve essere possibile allestire comunque tramite apposita interfaccia uno strumento per lo scambio delle informazioni e la loro automazione e tempificazione.

Si riportano di seguito le integrazioni che devono essere previste , secondo le specifiche di riferimento con:

Applicativi Regionali o a valenza regionale

• Piattaforma Intercent-ER (gestione gare, convenzioni, ecc…);

• SAP contabilità (per raccordo gestione GSA);

• NoTIER (Nodo Telematico di Interscambio Xxxxxx – Romagna)

• PROFILER (gestione della programmazione degli interventi in conto capitale, finanziati con fondi statali e regionali per l’edilizia, delle Aziende sanitarie e degli attuatori (Comuni, ASP…) per l’area socio sanitaria, socio assistenziale e sociale;

• FISSER (applicativo di gestione del Fondo Immobiliare del Servizio Sanitario dell’ Xxxxxx-Romagna);

• SITAR – Sistema Informativo Telematico dell’Osservatorio Regionale dei Contratti Pubblici di lavori, servizi e forniture;

• PCC – Piattaforma Certificazione Crediti;

• ARA- Anagrafe Regionale Assistiti;

• PARIX – Registro Imprese di Sintesi

• SISEPS – Anagrafe Strutture Sanitarie (es. integrazione via web services);

• Sistema SOLE (es. catalogo delle prestazioni);

• Sistema GRU (Gestione Risorse Umane unico Regionale);

• Sistema FEDERA/SPID;

• Sistema PagoPA;

• Sistema PARER;

• Sistema gestione anagrafiche farmaci.

Applicativi Aziendali:

• WMS dei magazzini centralizzati (Romagna, AVEN e AVEC);

• gestione riscossione e fatturazione (es. sistemi veterinari, analisi latte, libera professione);

• gestione recupero crediti (es. XXXX, gestione incassi);

• gestione order entry effettuato con gli applicativi che prevedono le richieste da reparto;

• gestione Tecnologie Biomediche (es. flussi informativi versus Ministero, gestione parco tecnologie).

Pertanto, il sistema dovrà possedere delle funzioni di import ed export verso altri applicativi. Dovrà consentire l'importazione e l'utilizzo di banche dati generate da altri sistemi (come ad es. la quotazione dei listini dei mercati telematici, tramite integrazione e/o interfaccia (es. da portali)).

Oltre a quanto suindicato, si riportano in modo esemplificativo e non esaustivo le integrazioni specifiche che devono essere garantite nelle diverse Aziende Sanitarie (vedi Allegato E).

Le integrazioni con gli applicativi aziendali per la gestione dei cespiti devono essere realizzate tramite delle viste di database, con le opportune regole per garantirne la sicurezza, con gli applicativi di business intelligence. Stessa modalità di integrazione deve essere adottata per i sistemi di gestione dei dispositivi medici.

La contabilità analitica deve prevedere la possibilità di integrarsi con gli applicativi aziendali di gestione amministrativa dei progetti ricerca attraverso delle viste di database.

Si richiede, inoltre, di formulare un progetto che preveda l’integrazione (parte integrante dell’offerta) con gestione utenze, manutenzioni, rifiuti e pulizie (al fine di permettere il ribaltamento automatico dei costi sugli edifici) .

Sono ritenute, infine, di particolare interesse le soluzioni che permettano l’integrazione con:

• sistemi documentali aziendali con possibilità di gestire workflow;

• altri sistemi informativi aziendali utili allo sviluppo dei sistemi di controllo direzionale (ad es. dati di attività).

ALLEGATO B

Requisiti tecnologici dell’impianto HW/SW di base e di ambiente necessario per il corretto funzionamento del sistema GAAC a livello Regionale

1. Hardware necessario al funzionamento dell’applicazione

L’infrastruttura Hardware, oggetto di acquisizione, riguarderà le componenti hardware e software di base necessarie all’utilizzo del sistema GAAC relativamente a tutte le aree funzionali e a tutte le aziende sanitarie, secondo le tempistiche espresse nel piano di implementazione, strutturato per fasi, riportato nel capitolato.

L’infrastruttura hardware dovrà rispettare i seguenti requisiti:

• Caratteristiche tecniche e prestazionali utili per la gestione dell’applicativo stimando un numero di utilizzatori pari a 25.000 utenti di cui 5.000 concorrenti, secondo la distribuzione a livello aziendale come riportata nel capitolo “Contesto attuale di riferimento” del Capitolato;

• Scalabilità in termini prestazionali e capacità di Mass Storage utili a garantire le fasi attuative del piano di implementazione e a garantire i livelli prestazionali e di capacità di Mass Storage per tutta la durata contrattuale della fornitura oggetto del Capitolato;

• Centralizzazione del sistema adibito alla gestione delle Banche Dati;

• Centralizzazione e/o distribuzione dell’Application Server secondo l’architettura finalizzata all’ottimizzazione prestazionale individuata dal fornitore.

La proposta tecnica del fornitore dovrà riportare l’architettura del sistema e le caratteristiche delle sue componenti.

2. Distribuzione hardware

L’Amministrazione mette a disposizione le strutture di Data Center, sia a livello Aziendale che di Area Vasta e Regionale, nonché le strutture di Data center regionali “in house”, per ospitare l’infrastruttura del sistema secondo l’architettura proposta dal fornitore. L’Amministrazione mette anche a disposizione la connettività tra i siti che è garantita dalla rete regionale Lepida (fibre ottiche) con banda da 100 Mbits/s a 1 Gbits/s. Oltre alla connettività, sono a carico dell’Amministrazione, i costi di housing (gestione base, sicurezza, armadi rack, consumi energetici, condizionamento, ecc).

La proposta tecnica del fornitore dovrà descrivere l’architettura e le relative funzionalità dell’impianto in rapporto alla dislocazione logistica, e riportare per sito l'occupazione fisica, i consumi elettrici e i requisiti di connettività.

3. Gradualità della fornitura hardware

La gradualità della fornitura dell’infrastruttura hardware e software di base è a discrezione del fornitore che, nel rispetto dei livelli prestazionali da garantire, potrà modulare la gradualità coerentemente con le caratteristiche di scalabilità del sistema e con il piano di implementazione.

La proposta tecnica del fornitore dovrà riportare la modularità della configurazione infrastrutturale prevista per l’attuazione del piano di implementazione a livello regionale.

4. Business Continuity, Sistema di Backup e Disaster recovery

La soluzione proposta per l’impianto HW/SW di base e di ambiente dovrà essere caratterizzata da un’architettura che garantisca la continuità operativa (business continuity) in caso di malfunzionamento o interruzione del funzionamento di una parte qualsiasi del sistema.

Il livello di servizio richiesto al fornitore (service level agreements) deve garantire quanto espresso nel capitolo 8 in merito a “Qualità e i livelli dei servizi”.

Il sistema di backup fornito dovrà consentire la pianificazione del salvataggio giornaliero e periodico dei dati/sistemi ed il recupero guidato delle informazioni salvate.

Le procedure di salvataggio dovranno consentire, per ogni funzionalità fornita, il ripristino delle informazioni fino all'ultimo “Commit” eseguito. La gestione del salvataggio è in carico al Fornitore ad esclusione delle operazioni manuali che rimangono in carico alla gestione base effettuata dal Datacenter.

Dovranno essere trasmesse al personale tecnico informatico delle aziende le informazioni dettagliate relative alle procedure di back-up e del relativo ripristino.

La gestione del back-up deve consentire una puntuale trasmissione degli esiti delle operazioni di salvataggio verso i referenti e/o sistemi di monitoraggio a livello aziendale/area vasta/regionale.

Il fornitore dovrà proporre una soluzione per la gestione del Disaster Recovery (di seguito DR) il cui dimensionamento e architettura dovranno garantire adeguati livelli di servizio SLA in merito alle tempistiche e alle modalità di ripristino. L’Amministrazione attribuirà specifica valutazione alle soluzioni che configurano per l’impianto DR funzionalità di servizio in load sharing del sistema gestionale. L’Amministrazione mette a disposizione i siti e la relativa connettività per la realizzazione del DR. Pertanto saranno in carico all’Amministrazione i costi di housing e di connettività nonché della ridondanza di connettività.

La proposta tecnica del fornitore dovrà riportare l’architettura del sistema DR e le caratteristiche delle componenti.

Al fine di garantire agli utilizzatori del sistema GAAC la continuità operativa su un sottoinsieme di funzioni applicative anche in condizioni di mancanza di connettività saranno premiate soluzioni che prevedano tale ulteriore funzionalità (modalità OFFLINE).

Le funzionalità OFFLINE dovranno attivarsi automaticamente dopo un periodo limitato di tempo configurabile e dovranno essere circoscritte a momenti sporadici e limitati nel tempo. Non appena ristabilita la connettività in automatico il sistema dovrà allinearsi nuovamente.

Le funzionalità minime per le quali dovrà essere garantito il funzionamento del sistema sono:

• Gestione richiesta di approvvigionamento

• Gestione carico/scarico

• Gestione ordini di acquisto

La soluzione deve prevedere che, quando l’applicazione lavora in modalità OFFLINE, sia possibile effettuare le normali operazioni di login e logout.

Nella documentazione tecnica di offerta presentata devono essere descritte nel dettaglio le seguenti attività (set minimo richiesto):

• modalità tecnica utilizzata;

• contesto architetturale;

• soluzione adottata;

• alcuni scenari di utilizzo in OFFLINE;

• gestione in caso di conflitti all’avvio della sincronizzazione;

• rilevazione dello stato di OFFLINE.

5. Sistema per la gestione di basi di dati

Il sistema per la gestione di basi di dati relazionali (RDBMS) che sarà riportato nella proposta tecnica del fornitore, dovrà rispettare i seguenti requisiti:

• garantire la piena compatibilità con la piattaforma tecnologica RDBMS della Oracle;

• garantire i livelli prestazionali, di seguito indicati, richiesti per il sistema GAAC;

• consentire l'integrazione con i sistemi aziendali con viste per gli RDBMS Oracle e Sql Server in ambienti Unix e Microsoft;

• prevedere licenze per l’accesso diretto al RDBMS, a scopi statistici, amministrativi e di monitoraggio, aggiuntive a quelle previste per l’operatività dell’infrastruttura applicativa.

La proposta tecnica del fornitore dovrà riportare la tipologia delle licenze d’uso del RDBMS e le metriche in rapporto alla gradualità implementativa del sistema GAAC.

L’acquisizione del software per la gestione delle banche dati “RDBMS” è in carico all'offerente.

6. Livelli prestazionali

Il sistema GAAC dovrà garantire i livelli prestazionali precisati nel capitolo qualità e livelli di Servizi.

7. Monitoraggio

Il sistema dovrà essere dotato degli strumenti utili alla rilevazione del funzionamento delle varie componenti e della continuità operativa delle stesse finalizzate ad un completo monitoraggio del

sistema nel suo complesso e della continuità operativa dei processi portanti sia in relazione alla infrastruttura tecnologica sia in relazione alla piattaforma applicativa. Inoltre, devono essere rese disponibili tutte le informazioni necessarie per l’utilizzo di sistemi di monitoraggio esterni al sistema.

ALLEGATO C

Competenze e Figure professionali per l’erogazione dei servizi necessari all’implementazione e alla gestione del sistema GAAC

Il fornitore dovrà specificare le figure professionali previste per l’erogazione dei servizi e fornire i relativi curricula delle risorse che saranno assegnate. Il numero di figure professionali dovrà essere adeguato per garantire il parallelismo delle attività necessarie per l’attivazione di più aziende contemporaneamente nel rispetto del piano di implementazione del sistema a livello regionale.

Dovrà essere garantito il passaggio di consegne, senza oneri per il committente, nel caso di sostituzione di figure professionali nel corso della validità del contratto. La verifica delle competenze e delle capacità dei nuovi tecnici andrà svolta preventivamente, con trasmissione dei curricula dei nuovi professionisti ai referenti aziendali/regionali, e sul campo durante l’attività di affiancamento, al termine della quale i nuovi professionisti dovranno essere in grado di lavorare in assoluta autonomia. La presa in carico di tale know-how dovrà avvenire a titolo non oneroso per il committente.

Le figure professionali necessarie all’erogazione dei servizi sono:

Capo Progetto

Ha il compito di organizzare le risorse umane e tecniche per il raggiungimento degli obiettivi sostanziali del progetto, nel rispetto dei vincoli di qualità, tempi e costi. E' richiesta una particolare competenza delle tecniche di gestione dei progetti, oltre ad una vasta conoscenza dell'ICT e in particolare del contesto applicativo dei sistemi di GAAC.

Seniority richiesta: 5 anni

Le attività tipiche di questa figura professionale sono:

- Permettere ai componenti del gruppo di progetto di lavorare in modo efficace sui corretti argomenti e nell’influenzare positivamente tutte le parti interessate, assicurando il rispetto dei vincoli di qualità, tempo e costi preventivati.

- Assumere la responsabilità del progetto con tutte le parti interessate: la struttura committente, l’organizzazione di progetto (gruppo di progetto, utenti chiave, ecc.), gli utenti finali.

- Sviluppare in modo iterativo i piani di lavoro delle diverse fasi di implementazione del sistema GAAC.

- Identificare, mitigare e gestire i rischi di progetto per evitare che tali rischi si trasformino in problemi di progetto.

- Risolvere, se necessario, eventuali problemi di comunicazione tra gruppi di membri del team e altre parti interessate al progetto.

- Gestire le richieste di implementazione evolutiva e relativi piani di attuazione.

Consulente Gestione Area Amministrativa Contabile

E’ una figura professionale, con specifica esperienza sui processi di GAAC e delle aziende sanitarie pubbliche, e competenza nell’organizzazione dei sistemi gestionali alle esigenze del committente.

Si occupa di identificare i requisiti e di definire modelli di flussi informativi e di oggetti da gestire per processi complessi.

Le attività tipiche di questa figura professionale sono:

- Partecipa al Gruppo di lavoro GAAC, costituito dalla Committenza, che avrà in carico il coordinamento e il governo dei lavori di implementazione del sistema.

- Confronta i processi in essere delle aziende per la definizione di un modello unico da implementare a livello regionale.

Seniority richiesta: 5 anni

Esperto in analisi

E’ una figura professionale, con specifica esperienza sui sistemi di GAAC e sistemi informativi amministrativi delle aziende sanitarie pubbliche, competente nell’organizzazione dei sistemi e nelle tecniche di definizione di diagrammi di flusso.

- Definisce le metodologie che il gruppo di progetto segue;

- Analizza i processi di business e configura le caratteristiche dei moduli della piattaforma applicativa GAAC alle esigenze del committente.

- Fornisce supporto e consulenza ai gruppi di progetto;

- Analizza le modalità con le quali vengono erogati i servizi;

- Descrive i servizi oggetto di analisi in maniera naturale e strutturata;

- Evidenzia interventi organizzativi e attuativi, funzionali alla implementazione del sistema;

Seniority richiesta: 5 anni

Progettista/Specialista piattaforme applicative GAAC

E’ una risorsa, con specifica esperienza sulle piattaforme applicative di GAAC, con conoscenze tecniche e capacità progettuali approfondite su funzionalità, flussi operativi e struttura dei dati.

- Analizza i requisiti di progetto;

- Configura e parametrizza le caratteristiche funzionali e la struttura dei dati della piattaforma applicativa GAAC;

- Descrive le soluzioni individuate in maniera naturale e strutturata;

- Evidenzia interventi organizzativi e attuativi, funzionali alla implementazione del sistema;

- Segue le metodologie individuate per il gruppo di progetto;

Seniority richiesta: 5 anni

Programmatore

E’ una risorsa, con specifiche conoscenze tecniche dei metodi e degli strumenti di sviluppo funzionali alla implementazione della piattaforma applicativa GAAC, che crea soluzioni per la realizzazione di componenti software e relative evoluzioni.

Svolge l’attività di progettazione e sviluppo del software:

- Analizza le specifiche di dettaglio;

- Sviluppa componenti software assicurandone il corretto funzionamento;

- Verifica qualitativamente il codice secondo un piano di test definito;

Seniority richiesta: 3 anni

Formatore

E’ una risorsa con competenze nella conduzione di moduli formativi.

- Supporta il Gruppo di progetto nella configurazione e pianificazione dell’attività formativa;

- Eroga la formazione;

- Svolge attività di affiancamento;

- Svolge attività di ripresa formativa.

Seniority richiesta: 3 anni

Responsabile della fornitura

La Committenza richiede la messa a disposizione da parte del Fornitore di una figura professionale, esperto nel project management, nella composizione di gruppi di lavoro adeguati alle esigenze dei progetti, con elevate capacità organizzative, tecniche, di relazione con i clienti, destinato a svolgere compiti di supervisore e coordinatore delle attività e delle risorse dei gruppi di lavoro e di interfaccia unica con la Committenza per la gestione della fornitura.

E’ valutata positivamente la certificazione PMP o certificazioni equivalenti nell’ambito del Project Mangement.

Nel caso in cui l’Amministrazione, a suo insindacabile giudizio, non lo ritenesse idoneo a svolgere i compiti citati, il responsabile della fornitura deve essere sostituito.

Tale figura professionale è messa a disposizione senza nessun onere per l’Amministrazione regionale.

Seniority richiesta: 5 anni.

ALLEGATO D

INDICAZIONI PER CAPITOLATO GAAC - PARER

Il Sistema GAAC deve implementare le funzionalità necessarie a gestire le fasi del processo di conservazione dei documenti informatici in capo al Produttore.

Tali funzionalità non devono tenere in considerazione i documenti per i quali è prevista la conservazione attraverso il SICIPA-ER.

In particolare, le fasi previste sono:

1. Individuazione degli oggetti da inviare in conservazione

2. Preparazione del pacchetto di versamento (SIP)

3. Versamento dei SIP al Sistema di conservazione

4. Monitoraggio dei versamenti

5. Aggiornamento oggetti in conservazione

6. Recupero delle informazioni e degli oggetti conservati

Per una maggiore comprensione tanto degli oggetti da conservare che delle modalità con cui il processo di conservazione è gestito, si rimanda ai seguenti documenti (tutti disponibili nella sezione Documentazione del sito di Parer, all’indirizzo: xxxx://xxxxx.xxx.xxxxxxx.xxxxxx- xxxxxxx.xx/xxxxxxxxxxxxxx):

- Oggetti da conservare: Manuale di conservazione, capitolo 6.1.

- Struttura e composizione del pacchetto di versamento (SIP): Manuale di conservazione, capitolo 6.2; Linee guida per la realizzazione dei SIP

- Processo di conservazione: Manuale di conservazione, capitolo 7.

- Servizi di versamento: Specifiche tecniche dei servizi di versamento; Codifiche errori

- Servizi di recupero: Specifiche tecniche dei servizi di recupero; Codifiche errori

1. Individuazione degli oggetti da inviare in conservazione

Gli oggetti da inviare in conservazione si dividono in:

- documenti: sono suddivisi in tipologie, per ognuna delle quali sono definiti set di metadati dedicati. Sono inviati in conservazione sotto forma di SIP di unità documentaria;

- serie: sono aggregazioni annuali di documenti della stessa tipologia. Sono inviate in conservazione sotto forma di SIP di serie;

- fascicoli: sono insieme di documenti raggruppati in base alle attività correnti, spesso nell’ambito di procedimenti amministrativi. Un tipico esempio di fascicolo è la pratica. Sono versati in conservazione sotto forma di SIP di fascicolo.

Il Sistema GAAC deve consentire di gestire la fase di individuazione degli oggetti da inviare in conservazione in varie modalità, ognuna delle quali attivabili a seconda delle esigenze:

- tramite un esplicito passo del workflow documentale (ad un certo punto del processo di gestione un documento viene inviato in conservazione);

- tramite delle regole automatiche di identificazione (tutti i documenti di un certo tipo che soddisfano determinate condizioni);

- tramite selezione manuale.

Inoltre, occorre considerare che le tempistiche di invio in conservazione sono diverse a seconda degli oggetti da conservare:

- documenti: nel più breve tempo possibile dalla loro produzione/ricezione, e comunque una volta che sono completi di tutti gli elementi (inclusi i metadati);

- aggregazioni (serie e fascicoli): quando sono chiusi e pronti per il versamento in archivio. La chiusura del fascicolo è legata alla chiusura del singolo procedimento/attività che lo ha generato, mentre le serie sono chiuse e versate in conservazione l’anno successivo a quello cui si riferiscono.

2. Preparazione del pacchetto di versamento (SIP)

Una volta individuati gli oggetti da inviare in conservazione, il Sistema GAAC deve reperire tutti i file e tutti i metadati necessari a predisporre il pacchetto di versamento (SIP).

Deve essere predisposto un pacchetto di versamento (SIP) per ogni oggetto da inviare in conservazione, secondo le indicazioni contenute nei documenti Linee guida per la realizzazione dei SIP (dove sono indicati composizione e set di metadati per ogni tipologia documentaria e di aggregazione trattata) e Specifiche tecniche dei servizi di versamento (dove è indicata la struttura dati del SIP per ogni tipologia di oggetto da inviare in conservazione).

Il SIP si compone di due elementi: l’Indice del SIP (sempre presente) e uno o più file (normalmente assenti nei SIP delle aggregazioni). I metadati degli oggetti da conservare devono essere reperiti dal Sistema GAAC in un momento immediatamente precedente all'invio in conservazione. Particolare attenzione va posta nel "mappare" le informazioni provenienti dal sistema all'interno dell'indice del SIP, in modo che siano correttamente riferite alle diverse parti dell’oggetto: identificativi, tipizzazione, metadati specifici, parametri di versamento, ecc.

3. Versamento dei SIP al Sistema di conservazione

La trasmissione del pacchetto di versamento avviene invocando il corrispondente web service (vedi documento "Specifiche tecniche dei servizi di versamento). E' possibile inviare più richieste in parallelo e non è necessario gestire una coda sequenziale di invii.

Il Sistema GAAC, inoltre, deve gestire il salvataggio degli esiti del versamento, sia in caso di versamento andato a buon fine che di versamento fallito.

Nel primo caso, il Sistema GAAC deve aggiornare le informazioni su ogni singolo oggetto inviato correttamente in conservazione, aggiornandone lo stato, memorizzando le informazioni essenziali (data di versamento, ecc.) e i documenti ricevuti in risposta alla chiamata dal sistema di conservazione (Esito versamento e, soprattutto, Rapporto di versamento).

Nel caso di versamento fallito, il Sistema GAAC deve memorizzare tutte le informazioni necessarie a valutare natura e motivi degli errori e a gestirne eventuali correzioni e nuovi invii (vedi punto sul monitoraggio).

In particolare si reputano utili funzionalità mirate a gestire la reiterazione automatica dell'invio in conservazione in caso di possibili problemi temporanei (problemi di rete, indisponibilità temporanea dei sistemi del ParER, time-out nella risposta ai servizi del ParER, ecc.).

Occorre che il Sistema GAAC gestisca il caso particolare (descritto più diffusamente in documentazione) dell’errore "UD-002 la chiave indicata corrisponde ad una Unità Documentaria già presente nel sistema" che è da considerare alla stregua di versamento effettuato con successo.

4. Aggiornamento oggetti in conservazione

Il Sistema GAAC deve consentire l’aggiornamento degli oggetti in conservazione, in particolar modo per le unità documentarie. Le variazioni possono essere di due tipi: nuovi documenti che si aggiungono a un’unità documentaria già in conservazione, oppure la modifica/aggiornamento dei suoi metadati.

Il Sistema GAAC deve mettere a disposizione funzionalità atte a gestire gli aggiornamenti, in particolare per:

• Identificare le variazioni, stabilendo regole che consentano di identificare quali siano le variazioni da inviare in conservazione (non tutte le variazioni all'unità documentaria potrebbero essere significative per la conservazione).

• Inviare gli aggiornamenti al sistema di conservazione, trasmettendo il SIP di aggiornamento utilizzando gli appositi servizi (vedi documento Specifiche tecniche servizi di versamento).

5. Recupero delle informazioni e degli oggetti conservati

Il Sistema GAAC deve consentire l’aggiornamento della propria base dati con le informazioni sullo stato di conservazione dei singoli oggetti inviati in conservazione invocando i servizi di recupero delle informazioni esposti dal sistema di conservazione (vedi Specifiche tecniche dei servizi di recupero).

Inoltre, il Sistema GAAC deve consentire alle persone autorizzate di ottenere dal sistema di conservazione il DIP per l’esibizione, da utilizzare nel caso in cui si renda necessaria l’esibizione formale dell’oggetto conservato.

6. Monitoraggio

Il Sistema GAAC deve mettere a disposizione funzionalità di monitoraggio adeguate ad assicurare il controllo del processo di invio in conservazione, consentendone l’avvio, il controllo dello stato di avanzamento, e la sua interruzione se necessaria.

Il monitoraggio deve ricomprendere tutte le casistiche inerenti il processo di conservazione: versamento, recupero, aggiornamento, annullamento, ecc.

Il Sistema GAAC deve consentire l’agevole verifica di quali oggetti sono stati inviati in conservazione, quali sono stati accettati in conservazione e quali invece rifiutati e per quale motivo, riportando per ogni sessione di versamento esito ed eventuali warning ed errori (l’elenco e il significato degli errori/warning è disponibile nel documento “Codifiche errori”).

Inoltre, nel caso dei versamenti falliti, il Sistema GAAC deve mettere a disposizione le funzionalità adeguate a gestire gli errori di versamento consentendo, sia in modo puntuale sul singolo SIP che massivo su un insieme di SIP, l’eventuale modifica dei parametri di versamento (le c.d. forzature) e il nuovo invio in conservazione del SIP.

Infine, il Sistema GAAC deve consentire l’annullamento di un versamento andato a buon fine mediante l’invocazione dell’apposito web service (vedi Specifiche tecniche dei servizi di versamento).

7. Gestione fase di test e di avvio dei versamenti

Il passaggio in produzione del sistema di invio in conservazione installato presso un Ente implica un processo di avvio che prevede:

• effettuazione dei test in un ambiente di staging del ParER;

• validazione dei test da parte del ParER;

• eventuale applicazione di modifiche alle configurazioni e ripetizione dei test e delle validazioni;

• collegamento al sistema di produzione;

• monitoraggio dei primissimi invii in produzione.

Questo significa, ad esempio, che il Sistema GAAC deve consentire di:

• inviare in conservazione più volte gli stessi documenti per test reiterati, eventualmente anche cancellando lo stato di conservazione del documento riferito ad invii già effettuati;

• cambiare facilmente i parametri di configurazione al servizi del ParER per gestire dinamicamente il collegamento alla produzione o differenti aree di staging;

• selezionare ristrette selezioni di documenti da inviare una tantum sia allo staging, sia alla produzione.

ALLEGATO E

Applicativi in uso presso le Aziende Sanitarie e principali integrazioni richieste a valenza aziendale

GESTIONE MAGAZZINO

	GESTIONE MAGAZZINO
	NOME APPLICATIVO ATTUALE	FORNITORE
Azienda USL di Piacenza	Enco	GPI
Azienda USL di Parma	Eusis MAGAZZINO	GPI
Azienda USL di Reggio Xxxxxx	E00V4	Data Processing
Azienda USL di Modena	Diapason DTF (versione 6.03)	Gruppo Formula spa
Azienda USL di Bologna	EUSIS MAGAZ	GPI
Azienda USL di Imola	Oliamm	ENGEENERING
Azienda Ospedaliera di Ferrara	SAP ERP - SAP AG	SAP ITALIA
Azienda USL ROMAGNA	NFS	Dedalus DEDALUS
Azienda Xxxxxxxxxxx xx Xxxxx	X0X
Xxxxxxx Xxxxxxxxxxx xx Xxxxxx Xxxxxx	X00X0	Data Processing
Azienda Ospedaliera di Modena	NFS	DEDALUS
Azienda Ospedaliera di Bologna	GE4	Data Processing Spa (Gruppo Finmatica)
Azienda USL di Ferrara	EUSIS MAGAZ	GPI
Istituti Ortopedici Rizzoli di Bologna	GE4	Data Processing

	APPLICATIVI AZIENDALI
	APPLICATIVI AZIENDALI		MODALITA' DI INTEGRAZIONE
	NOME APPLICATIVO	FORNITORE	FILE,VISTE, MESSAGGI HL7, trasmissione BIDIREZIONALE/MONODIREZIONALE
Azienda USL di Parma	Eusis PHARMA	GPI.	integrazione applicativa
	Eusis GEST	GPI	integrazione applicativa
Azienda USL di Bologna	MYSANITA' (adiuweb)	DELTA	CHIAMATA SERVIZIO
	RURER- INVALIDITA' (adiuweb)	ENGINEERING	CHIAMATA SERVIZIO
Azienda Ospedaliera di Ferrara	GESTAPP	ERREFFE INFORMATICA	HL7
	COMPENDIO FARMACEUTICO	FARMADATI	HL7
	LOG80	LOG80 SRL	HL7
	ORMAWEB	DEDALUS	HL7
Azienda Ospedaliera di Parma	ORMAWEB	DEDALUS	MESSAGGI HL7 E VISTE, TRASMISSIONE BIDIREZIONALE
	APC	ADS	MESSAGGI HL7 E VISTE
	LOG80	LOG80	MESSAGGI HL7 E VISTE
Azienda USL di Ferrara	Anagrafe centralizzata (DB CODIFICHE)	sviluppato internamente	Job monodirezionale verso GE4
Istituti Ortopedici Rizzoli di Bologna	GE4RWEB (richieste online da reparto)	Data Processing	integrazione nativa bidirezionale
	PRWEB (gestione amministrativa progetti ricerca)	Data Processing	integrazione nativa bidirezionale
	SO4 (struttura organizzativa)	Data Processing	integrazione nativa monodirezionale
	GDM (gestione documentale)	Data Processing	integrazione nativa monodirezionale

GESTIONE CESPITI

	GESTIONE CESPITI
	NOME APPLICATIVO ATTUALE		FORNITORE
Azienda USL di Piacenza	Enco		GPI
Azienda USL di Parma	EUSIS CESPITI		GPI
Azienda USL di Reggio Xxxxxx	CI4		Data Processing
Azienda USL di Modena	Diapason DTF (versione 6.03)		Gruppo Formula SPA
Azienda USL di Bologna	EUSIS CESPITI		GPI
Azienda USL di Imola	OLIAMM		ENGEENERING
Azienda Ospedaliera di Ferrara	SAP ERP - SAP AG		SAP ITALIA
Azienda USL ROMAGNA	NFS		Dedalus DEDALUS
Xxxxxxx Xxxxxxxxxxx xx Xxxxx	X0X
Xxxxxxx Xxxxxxxxxxx xx Xxxxxx Xxxxxx	XX0		Data Processing
Azienda Ospedaliera di Modena	NFS		DEDALUS
Azienda Ospedaliera di Bologna*
Azienda USL di Ferrara	EUSIS CESPITI		GPI
Istituti Ortopedici Rizzoli di Bologna	CI4WEB		Data Processing

*N.B. Non attivo, in fase di unificazione con procedure disponibili c/o altre Aziende

	APPLICATIVI AZIENDALI
	APPLICATIVI AZIENDALI		MODALITA' DI INTEGRAZIONE
	NOME APPLICATIVO	FORNITORE	FILE,VISTE, MESSAGGI HL7, trasmissione BIDIREZIONALE/MONODIREZIONALE
Azienda Ospedaliera di Ferrara	GESTAPP	ERREFFE - INFORMATICA	MESSAGGI HL7
Istituti Ortopedici Rizzoli di Bologna	SO4 (struttura organizzativa)	Data Processing	integrazione nativa monodirezionale

CONTABILITA’ ANALITICA

	CONTABILITA' ANALITICA
	NOME APPLICATIVO ATTUALE	FORNITORE
Azienda USL di Piacenza	Enco	GPI
Azienda USL di Parma	EUSIS STATUS	GPI
Azienda USL di Reggio Xxxxxx	CGA	Data Processing
Azienda USL di Modena	Sistema Rages-R3	CSIO srl
Azienda USL di Bologna	EUSIS STATUS	GPI
Azienda USL di Imola	Oliamm	ENGEENERING
Azienda Ospedaliera di Ferrara	SAP ERP - SAP AG	SAP ITALIA
Azienda USL ROMAGNA	Formula Planning	Gruppo Formula
Azienda Ospedaliera di Parma	C4H	DEDALUS
Azienda Ospedaliera di Reggio Xxxxxx	CGA	Data Processing
Azienda Ospedaliera di Modena	Xxxx	Xxxxxxxxxxxx
Azienda Ospedaliera di Bologna	CGS - Controllo di Gestione	Data Processing Spa (Gruppo Finmatica)
Azienda USL di Ferrara	EUSIS STATUS	GPI
Istituti Ortopedici Rizzoli di Bologna	CONAN	OSLO

	APPLICATIVI AZIENDALI
	APPLICATIVI AZIENDALI		MODALITA' DI INTEGRAZIONE
	NOME APPLICATIVO	FORNITORE	FILE,VISTE, MESSAGGI HL7, trasmissione BIDIREZIONALE/MONODIREZIONALE
Azienda USL di Parma	Eusis GEST	G.P.I.	integrazione applicativa
Azienda Ospedaliera di Bologna	Anagrafe centralizzata	sviluppato internamente	Job (monodirezionale)

CONTABILITA’ GENERALE

	XXXXXXXXXXX' GENERALE
	NOME APPLICATIVO ATTUALE		FORNITORE
Azienda USL di Piacenza	Enco		GPI S.p.A.
Azienda USL di Parma	EUSIS CONTAB		G.P.I.
Azienda USL di Reggio Emilia	CE4		Data Processing
Azienda USL di Modena	Diapason DTF (versione 6.03)		Gruppo Formula SPA
Azienda USL di Bologna	EUSIS CONTAB		GPI
Azienda USL di Imola	Oliamm / OliammWEB		ENGEENERING
Azienda Ospedaliera di Ferrara	SAP ERP - SAP AG		SAP ITALIA
Azienda USL ROMAGNA	NFS x il CICLO PASSIVO AREAS x il CICLO ATTIVO		Dedalus Engineering
Xxxxxxx Xxxxxxxxxxx xx Xxxxx	X0X		XXXXXXX
Xxxxxxx Xxxxxxxxxxx xx Xxxxxx Xxxxxx	CE4		Data Processing
Azienda Ospedaliera di Modena	NFS		DEDALUS
Azienda Ospedaliera di Bologna*
Azienda USL di Ferrara	EUSIS CONTAB		GPI
Istituti Ortopedici Rizzoli di Bologna	CE4WEB		Data Processing

*N.B. Non attivo, in fase di unificazione con procedure disponibili c/o altre Aziende

	APPLICATIVI AZIENDALI
	APPLICATIVI AZIENDALI		MODALITA' DI INTEGRAZIONE
	NOME APPLICATIVO	FORNITORE	FILE,VISTE, MESSAGGI HL7, trasmissione BIDIREZIONALE/MONODIREZIONALE
Azienda USL di Parma	DIGIT_GO WORKFLOW	GPI	integrazione applicativa
	DIGIT_GO E_VOICE	GPI	integrazione applicativa
	DIGIT_GO BILLING	GPI	integrazione applicativa
	EUSIS PHARMA	GPI	integrazione applicativa
	KOFAX WEB	GPI	integrazione applicativa
Azienda USL di Reggio Emilia	GDM GDM	Data Processing Data Processing	Gestore Documentale Gestore Documentale
Azienda Ospedaliera di Reggio Xxxxxx
Istituti Ortopedici Rizzoli di Bologna	PRWEB (gestione amministrativa progetti ricerca)	Data Processing	integrazione nativa bidirezionale
	SO4 (struttura organizzativa)	Data Processing	integrazione nativa monodirezionale
	GDM (gestione documentale)	Data Processing	integrazione web service bidirezionale
	GST (cassa ticket Bagheria)	Data Processing	integrazione nativa monodirezionale
	Certificazione Unica	Data Processing	integrazione nativa monodirezionale