Comune di Firenze Direzione Risorse Finanziarie/Direzione ... · o Sistema Informativo Territoriale...

Comune di Firenze Direzione Risorse Finanziarie/Direzione Sistemi Informativi

1

Comune di Firenze

Direzione Risorse Finanziarie – Direzione Sistemi Informativi

Sistema informativo integrato per la gestione delle entrate del Comune di Firenze

(SIGE)

CAPITOLATO TECNICO


2

SOMMARIO

1. Presentazione generale dell'esigenza ................................................................................ 4 2. Definizioni, abbreviazioni e convenzioni generali................................................................. 5 3. Natura ed elementi della fornitura .................................................................................... 5 4. I processi di servizio attualmente svolti dal DRFSE ............................................................. 7 4.1 La struttura organizzativa ed il personale del DRFSE...................................................... 8 4.2 Le competenze attuali del DRFSE ................................................................................ 8

5. Il sistema informativo attuale .......................................................................................... 8 5.1 Gli attuali programmi applicativi di gestione delle entrate ............................................... 8

6. Interazioni con gli altri sistemi informativi ......................................................................... 9 6.1 BDPI (Banca Dati Patrimonio Informativo).................................................................. 10 6.2 People ed EFirenze ................................................................................................. 10 6.2.1. Area ICI.........................................................................................................11 6.2.2. Area CIMP......................................................................................................13 6.2.3. Area COSAP ...................................................................................................13

6.3 Sistema STARIS (stato della riscossione) e collegamento al gestionale di contabilità (applicativo Inf.Or.)................................................................................................. 14

6.4 Protocollo dell’Ente .................................................................................................. 16 6.5 Catasto .................................................................................................................. 16 6.6 SIT........................................................................................................................ 17 6.7 Altre banche dati comunali ....................................................................................... 18

7. Requisiti del SIGE......................................................................................................... 18 7.1 Caratteristiche generali ............................................................................................ 18 7.2 Caratteristiche tecnologiche...................................................................................... 21 7.3 Caratteristiche funzionali .......................................................................................... 22

7.3.1. Elementi funzionali comuni a tutti i sottosistemi................................................ 22 7.3.2. Sottosistema COSAP ..................................................................................... 25 7.3.3. Sottosistema CIMP ........................................................................................ 28 7.3.4. Sottosistema ICI........................................................................................... 31 7.3.5. Sottosistema “Gestione verifiche di classamento” (GESDIA) ............................... 34 7.3.6. Sottosistema Gestione Contenzioso ................................................................. 35

8. Servizi professionali correlati al software applicativo ......................................................... 39 8.1 Predisposizione definitiva del PI ................................................................................ 39 8.2 Importazione dei dati pregressi ................................................................................. 41 8.3 Personalizzazione applicativa .................................................................................... 42 8.4 Formazione degli utenti............................................................................................ 42 8.5 Assistenza all'avviamento del sistema........................................................................ 43 8.6 Servizio di assistenza funzionale agli utenti................................................................. 44 8.7 Manutenzione ......................................................................................................... 45 8.7.1 Manutenzione ordinaria.....................................................................................45 8.7.2 Manutenzione straordinaria ...............................................................................46 8.7.3 Condizioni per lo svolgimento delle attività manutentive .......................................46

8.8 Gestione del software applicativo .............................................................................. 47 8.9 Garanzia ................................................................................................................ 47 8.10 Documentazione.................................................................................................... 48

9. Affidamento dei servizi di assistenza e di manutenzione ordinaria....................................... 48 10. Organizzazione e gestione del rapporto contrattuale ....................................................... 49 10.1 Vincoli contrattuali ................................................................................................. 49 10.2 Referenti del Fornitore e dell’Ente ............................................................................ 49 10.3 Obblighi del Fornitore............................................................................................. 50 10.4 Obblighi dell’Ente................................................................................................... 51 10.5 Codici sorgente ..................................................................................................... 52

11. Risoluzione anticipata del contratto............................................................................... 52 12. Test di accettazione provvisoria, verifica dei servizi e collaudo.......................................... 53


3

12.1 SAL: test di accettazione e verifiche......................................................................... 53 12.1.1 Test di accettazione provvisori .........................................................................54 12.1.2 Verifiche in corso d’opera ................................................................................54

12.2 Collaudo............................................................................................................... 54 13. Modalità di pagamento ................................................................................................ 55 14. Penali........................................................................................................................ 56 15. Subappalto ................................................................................................................ 56 16. Diritti di proprietà ....................................................................................................... 57 17. Trattamento dei dati personali e sensibili ....................................................................... 57 18. Garanzia fideiussoria ed oneri fiscali.............................................................................. 57 19. Foro competente ........................................................................................................ 57


4

1. P resentazione generale dell'esigenza

Il Comune di Firenze è attualmente dotato di una serie di applicazioni software per la gestione delle sue entrate tributarie e dei canoni ad esse assimilabili. Ognuna di tali applicazioni risulta di per sé aderente ai requisiti operativi degli uffici, in quanto frutto di una continua e ormai lunga attività di personalizzazione e messa a punto specifica. D’altro canto, la presenza di applicativi diversi dà luogo a una situazione di frammentazione che è all’origine di numerosi scompensi di natura organizzativa e tecnica.

Si pone, pertanto, l’esigenza di superare l’attuale situazione senza dover, però, rinunciare ai vantaggi che essa offre di un’informatizzazione capillare e caratterizzata da un alto grado di specializzazione funzionale.

Il Comune si propone di giungere a questo risultato attraverso l’acquisizione di un sistema informativo unico di gestione delle predette entrate che, nel rispondere a requisiti quali la piena integrazione di dati e funzionalità, la sicurezza, il supporto all’interoperabilità del personale, nonché l’offerta di servizi di cooperazione applicativa nei confronti di altri Enti e uffici e di servizi online ai cittadini e alle imprese, rispetti altresì la condizione necessaria di non dover rinunciare ad alcuna delle funzionalità attualmente presenti e utilizzate dagli uffici competenti.

Tale nuovo sistema informativo è, di qui in avanti, denominato SIGE (Sistema Informativo per la Gestione delle Entrate).

Obiettivi principali del SIGE sono i seguenti:

Consentire la gestione unitaria ed integrata di tutte le informazioni e di tutti i processi relativi alle entrate del Comune di Firenze, attualmente svolti sia dal Servizio Entrate della Direzione Risorse Finanziarie, sia con particolare riferimento alle procedure per la riscossione coattiva da altri uffici del Comune. Si precisa che è intenzione dell’Amministrazione Comunale costituire un ufficio unico per la gestione della riscossione coattiva e che, dunque, obiettivo del SIGE è anche fornire l’infrastruttura informatica di tale gestione.

Consentire il trattamento dei summenzionati dati e informazioni a tutti gli utenti del Comune per i quali ciò venga ritenuto necessario, secondo ruoli e privilegi specifici. L’impostazione di ruoli e privilegi sarà configurabile da parte dell’utente avente il ruolo di amministratore del SIGE, nel rispetto di quanto previsto dalla normativa vigente sulla tutela dei dati personali.

Fornire strumenti per l’interoperabilità con gli altri sistemi e banche dati di seguito elencati: o Contabilità comunale (applicazione fornita dalla ditta Inf.Or. s.r.l.). o Banca Dati del Patrimonio Informativo comunale (BDPI), progetto realizzato con la

collaborazione dello RTI tra Gruppo S Lab s.r.l. e Oracle Italia s.r.l. o Pratiche dello Sviluppo Economico (applicazione SIGEPRO. fornita da In.I.T. s.r.l.). o Sistema Informativo Territoriale (SIT), progetto interno che si avvale della

collaborazione di diversi fornitori. o Pratiche di Mobilità, con specifico riferimento ai passi carrai (applicazione sviluppata

internamente dalla Direzione Sistemi Informativi). o Progetti di egovernment People ed EFirenze, per l’interazione online con i

contribuenti. o Sistema anagrafico (S.I.Po., fornito da IBM e Comune di Bologna e manutenuto

internamente), per quanto riguarda i dati della popolazione residente. o Sistema di protocollazione e gestione documentale, denominato Si.Ge.Do., fornitore

la ditta ADS S.p.A. o Sistemi di Equitalia Servizi, per quanto concerne la gestione dei ruoli e la loro

rendicontazione. o Sistema camerale, per quanto riguarda i dati delle imprese.


5

o Dati catastali e relativi aggiornamenti, da reperire direttamente dall’Agenzia del Territorio oppure tramite il Servizio SIT comunale.

o Agenzia delle Entrate, per quanto riguarda i dati relativi ai versamenti effettuati tramite modello F24: lo scarico periodico di tali modelli avviene utilizzando il sistema SIATEL.

o Sistema POSTE italiane per i versamenti effettuati tramite bollettini. o Banca dati TIA, gestita da Quadrifoglio S.p.A.

Offrire cruscotti e quadri di sintesi orientati al supporto alle decisioni, al fine di effettuare analisi, report statistici (soprattutto per il monitoraggio delle entrate) e simulazioni (analisi di sensitività) per poter effettuare previsioni di bilancio.

2. Definizioni, abbreviazioni e convenzioni generali

In questo capitolato sono utilizzate le seguenti abbreviazioni e sigle:

Ø SIGE: Il Sistema Informativo per la Gestione delle Entrate. Nel seguito, nel far riferimento al SIGE, si utilizzeranno altresì, come suoi sinonimi assolutamente equivalenti, i termini Applicazione, Procedura o Sistema.

Ø Comune, Ente, Amministrazione: Il Comune di Firenze. Ø Ditta aggiudicataria, Fornitore: La società, ditta o raggruppamento di imprese che,

al termine dell’intero procedimento della gara d'appalto, ne risulterà vincitrice.

Ø DSI: La Direzione Sistemi Informativi del Comune. Ø DRF: La Direzione Risorse Finanziarie del Comune. Ø DSE: La Direzione Sviluppo Economico del Comune. Ø DRFSE: Il Servizio Entrate della Direzione Risorse Finanziarie del Comune. Tale Servizio

è la struttura del Comune preposta ai processi di gestione delle entrate tributarie, derivanti da imposte e da canoni.

Ø Referenti dell’Ente: Il Referente amministrativo e il Referente tecnico del Comune. Ø Referenti del Fornitore: Il referente commerciale e il capo progetto della Ditta

aggiudicataria, da essa indicati ai fini dell’esecuzione del contratto.

Ø Ditte concorrenti: Le aziende partecipanti alla gara ammesse alla fase di valutazione delle rispettive offerte tecniche.

Ø PI: il Piano di implementazione integrato che descrive le fasi di progetto, finalizzate all’implementazione del SIGE come prodotto finito corrispondente alle specifiche del presente capitolato e alle esigenze dell’Ente.

Ø Prodotto originario: Il prodotto software di gestione delle entrate comunali che la ditta concorrente può proporre quale base da implementare nel corso del progetto, le cui fasi sono delineate dal PI.

Ø Costo prodotto: il costo dell’Applicazione e dei Servizi Professionali Correlati di cui all’offerta economica della Ditta aggiudicataria.

3. Natura ed elementi della fornitura

3.1 Natura e linee guida della fornitura

Come affermato nel capitolo 1, l'Applicazione deve essere in grado di gestire le esigenze di automazione relative alle entrate di un ente locale quale il Comune di Firenze, dotato di un sistema informativo aziendale composito. Inoltre, le funzionalità offerte e i dati gestiti dall’Applicazione devono rispondere, sia in termini qualitativi sia quantitativi, a specifiche almeno pari a quelle soddisfatte dagli applicativi esistenti.


6

Per tale motivo il SIGE va inteso e considerato come un insieme funzionale complesso, composto non solo dall'insieme dei programmi eseguibili dall'elaboratore, ma anche da ogni altro eventuale e ulteriore programma a corredo, accessorio, componente, parte, modulo, libreria, specifica macchina o dispositivo hardware, documento, manuale e, in genere, ogni altra parte necessaria alla regolare installazione, funzionamento e proficuo uso di tale insieme funzionale da parte del personale dell'Amministrazione.

A questo proposito si ricorda che l’aggiudicazione avverrà sulla base della valutazione degli aspetti funzionali, progettuali, economici, etc. rilevabili dalle offerte delle ditte concorrenti. La valutazione riguarderà sia l’analisi dell’eventuale prodotto originario sia l’attitudine (per come riscontrabile dalla documentazione presentata in sede di gara) ad adeguare, se necessario, tale prodotto al livello di compiutezza funzionale richiesto nel presente capitolato, mediante specifiche attività di personalizzazione e adeguamento applicativo. Ci si riferisce col termine di SIGE (o Applicazione, etc…) al prodotto risultante dalle varie attività implementative previste dal progetto.

L’Amministrazione si riserva altresì di richiedere l’attivazione in tempi diversi dei singoli moduli applicativi.

Saranno a carico del Fornitore tutte le componenti hardware e software specializzate che dovessero rivelarsi indispensabili per assicurare le funzionalità della Procedura a regime ma che non sono state espressamente indicati come tali nella sua offerta tecnica. In tal caso si verificherà un collaudo negativo del Sistema o di alcune sue parti.

3.2 Elementi specifici della fornitura

Gli elementi specifici da comprendere obbligatoriamente nella fornitura, e coperti dal “costo prodotto”, sono i seguenti:

1) Licenze

L'appalto include la fornitura della licenza d’uso della Procedura. Tale licenza sarà illimitata, cioè valida per tutti gli utenti dell'Ente, e permanente, cioè non soggetta a scadenza.

E’ ammessa la possibilità di utilizzare, integrate nell’Applicazione, componenti software prodotte da terze parti, alle seguenti condizioni: ü piena responsabilità della Ditta aggiudicataria per quanto attiene il corretto

funzionamento di tali componenti; ü compresa nel prezzo della fornitura, la cessione all’Ente della loro licenza d’uso illimitata

e permanente.

Le caratteristiche (generali, tecnologiche e funzionali) cui il Sistema dovrà aderire sono specificate nei capitoli 6 e 7 (rispettivamente inerenti le integrazioni con i sistemi informativi esistenti e le specifiche).

2) Servizi professionali correlati al software applicativo

L’appalto include l’erogazione dei servizi professionali correlati (d’ora in avanti anche SPC) elencati nel seguito, sostanzialmente finalizzati alla messa in opera del Sistema e all’addestramento degli utenti:

a) Predisposizione, in forma definitiva, del Piano di implementazione integrato (d’ora in avanti PI) del Sistema.

Il PI conterrà l’indicazione degli SPC e dei relativi tempi di attuazione, nonché dei prodotti e dei relativi tempi di rilascio, come specificato nel succ.vo par. 8.1. Esso si baserà sulla proposta presentata dalla Ditta aggiudicataria in sede di gara e sarà allegato, come parte integrante, al contratto che verrà sottoscritto con la Ditta medesima.

b) Importazione dei dati pregressi.

Questo servizio si concretizza dapprima nell’analisi dei dati contenuti negli archivi gestiti


7

dagli attuali applicativi relativi alle entrate dell’Ente (dati pregressi) e delle azioni necessarie al fine della loro importazione nel database dell’Applicazione. Successivamente a tale analisi il Fornitore svilupperà appositi programmi di importazione. Nel caso in cui l’analisi dei dati pregressi accerti l’esistenza di insormontabili incompatibilità strutturali o, per alcuni di tali dati, una qualità eccessivamente bassa, il Fornitore si impegna comunque, comprese nel “costo prodotto”, a mettere a disposizione del Comune risorse – di qualifica e in quantità che saranno da concordare congiuntamente fra lo stesso Comune e il Fornitore – atte ad agevolare comunque l’Ente nei tentativi di recupero il più possibile automatico delle più importanti informazioni da quest’ultimo individuate. Ulteriori indicazioni in merito al servizio sono fornite al succ.vo par. 8.2.

c) Servizio di adeguamento applicativo del prodotto originario offerto

Sono comprese in tale servizio tutte le attività del Fornitore necessarie per costruire il SIGE, ovverosia adeguare il prodotto originario alle esigenze dell’Ente, con principale e prioritario riguardo a quelle espresse nel presente capitolato. Ulteriori indicazioni in merito al servizio sono fornite al succ.vo par. 8.3.

d) Formazione degli utenti

Il servizio riguarda la formazione degli utenti del Comune, per tutte le tipologie di utenza, con la realizzazione di una guida operativa utilizzabile on line. Il numero totale di utenti da formare ammonta approssimativamente a 150. Modalità di svolgimento dell'attività e specifiche della guida d’utilizzo del Sistema sono al succ.vo par. 8.4.

e) Assistenza all'avviamento del Sistema

Questo servizio consiste nell’attività di affiancamento di personale della Ditta agli utenti gestionali del Comune nella fase di avviamento del SIGE. Ulteriori indicazioni sono fornite al succ.vo par. 8.5.

f) Assistenza applicativa agli utenti

Il succ.vo par. 8.6 specifica meglio le condizioni di erogazione di questi servizi.

g) Manutenzione

Le relative condizioni di erogazione sono specificate al par. 8.7.

h) Gestione del software applicativo

Il succ.vo par. 8.8 chiarisce le condizioni di erogazione di questo servizio.

i) Garanzia

Si intende qui il periodo di garanzia comprendente le attività di assistenza e manutenzione ordinaria del software applicativo, da svolgersi su richiesta del Comune. Le modalità di svolgimento dell'attività sono delineate nel succ.vo par. 8.9.

j) Documentazione

E’ inclusa tra gli SPC la fornitura e l’aggiornamento della documentazione tecnica ed operativa relativa all’Applicazione. Le caratteristiche ed i contenuti della documentazione sono delineati nel succ.vo par. 8.10.

Gli elementi sopra esposti dovranno essere forniti entro i tempi massimi specificati al successivo Capitolo 8 e secondo le modalità ivi indicate, salvo eventuali successivi accordi riportati nel PI definitivo e quindi ratificati nel contratto che verrà sottoscritto col Fornitore.

4. I processi di servizio attualmente svolti dal DRFSE

Questo paragrafo e gli allegati in esso citati espongono la struttura organizzativa attuale del DRFSE, ed i processi di servizio attualmente svolti in merito alla gestione delle entrate.


8

4.1 La struttura organizzativa ed il personale del DRFSE

La struttura organizzativa è determinata da provvedimenti normativi ed è variabile nel tempo. In particolare, come prossima evoluzione, è prevista la costituzione dell’ufficio unico di gestione delle entrate derivanti da ruoli coattivi.

La struttura organizzativa attuale consiste di:

• Personale alle dirette dipendenze del dirigente del Servizio Entrate • PO Imposta Comunale sugli Immobili • PO TARSU/TIA e rapporti con il concessionario • PO Pubblicità ed affissioni • PO COSAP (Canone occupazione spazi ed aree pubbliche) • PO Contenzioso

Le varie unità organizzative del Servizio sono ubicate presso la sede della DRF del Comune di Firenze, situata in via Pietrapiana n.53.

4.2 Le competenze attuali del DRFSE

Le attuali competenze sono così definite:

• gestione e riscossione in forma diretta, accertamento, liquidazione e rimborso dell'ICI, del canone sulla Pubblicità Affissioni e del COSAP;

• cura della gestione del contenzioso;

• informazione dei contribuenti;

• elaborazione di proposte tecniche in materia tributaria.

Sono altresì parte delle competenze del DRFSE i rapporti con altre strutture del Comune, ad esempio:

• la Direzione Sviluppo Economico per quello che concerne pubblicità, insegne, occupazione spazi e aree pubbliche relative ad attività commerciali e pubblici spettacoli;

• la Direzione Mobilità per le occupazione temporanee di suolo pubblico, ad es. traslochi e ponteggi, e per i passi carrai.

Tali Direzioni producono flussi di input finalizzati alla creazione di posizioni di pagamento del tributo da parte del soggetto passivo di imposta e ricevono flussi di output per lo svolgimento degli atti conseguenti.

5. I l sistema informativo attuale

Il paragrafo seguente espone lo stato attuale dell'automazione nel settore oggetto del presente appalto. Lo scopo del paragrafo è fornire informazioni di riferimento utili ad una migliore definizione del contesto e necessarie per stimare l’entità delle attività, ivi compresa quella di importazione sul nuovo sistema dei dati pregressi. Tutti i programmi applicativi di gestione dovranno, infatti, essere sostituiti da corrispondenti funzionalità offerte dal SIGE.

5.1 Gli attuali programmi applicativi di gestione delle entrate

Come detto al cap. 1, per la gestione delle entrate sono attualmente utilizzate alcune applicazioni afferenti a più archivi informatici. Tali applicativi sono stati progettati e realizzati ad hoc sia da risorse interne che esterne, in periodi diversi.

Il parco applicativo esistente è esposto nei seguenti raggruppamenti principali:

• Applicativo COSAP: sviluppato in linguaggio Visual Basic (tecnologia clientserver) con DBMS MS SQL SERVER 2000 su sistema Windows 2000. Un’azienda esterna


9

svolge la manutenzione ordinaria, straordinaria e l’assistenza all’uso.

• Applicativo CIMP: sviluppato in linguaggio Visual Basic (tecnologia clientserver) con DBMS MS SQL SERVER 2000 su sistema Windows 2000. Un’azienda esterna svolge la manutenzione ordinaria, straordinaria e l’assistenza all’uso.

• Applicativo ICI: sviluppato in linguaggio PROGRESS con DBMS di riferimento PROGRESS (vers 10.1B) su sistema Linux RedHat ES 4. Un’azienda esterna svolge la manutenzione ordinaria e l’assistenza all’uso.

• Applicativi di gestione del contenzioso: Si tratta di applicativi realizzati sia da personale interno sia da fornitori esterni.

In particolare, il sistema principale di gestione è stato sviluppato in linguaggio DELPHI 5 (tecnologia clientserver) con DBMS IBM DB2 su host Z/OS. Personale interno svolge la manutenzione ordinaria e l’assistenza all’uso.

Un secondo applicativo sviluppato in ambiente Access (e mantenuto da personale esterno) è utilizzato per la gestione dei fallimenti e dei ricorsi (relativamente ai quali la competenza ricade sotto l’autorità giudiziaria ordinaria –AGO).

Un terzo applicativo sviluppato anch’esso in ambiente Access (e mantenuto da personale interno) viene utilizzato per necessità di supporto informativo durante le udienze, tramite una funzione di consultazione dei dati relativi a precedenti sentenze emesse e relative decisioni.

• Applicativo gestione stato riscossioni (STARIS): Il software è realizzato in ambiente Access, ma è disponibile anche la versione .Net con DBMS MS SQL SERVER. Un’ azienda esterna svolge la manutenzione ordinaria e l’assistenza all’uso.

• Applicativo gestione verifiche di classamento (GESDIA): sviluppato in linguaggio PROGRESS con DBMS di riferimento PROGRESS (vers 10.1B) su sistema Linux RedHat ES 4. Un’azienda esterna svolge la manutenzione ordinaria e l’assistenza all’uso.

• Applicativo Pubbliche Affissioni: sviluppato in Clipper con archivi DB3. E’ in corso di sviluppo una nuova applicazione, fornita dalla ditta Inf.Or. s.r.l. di Arezzo, che sostituirà tale software.

• Applicativo Gestione TARSU: sviluppato in linguaggio DELPHI 5 con DBMS IBM DB2, la sua struttura è condivisa dal sistema di gestione del contenzioso. Tale applicazione è utilizzata per una gestione a stralcio e NON è richiesta nella fornitura in oggetto.

I database contenenti i dati gestiti dagli applicativi sopra riferiti sono ospitati su server del Comune.

Le applicazioni sopra elencate interagiscono con altri archivi e procedure del Comune, nonché con sistemi esterni. Tali interazioni dovranno, comunque, essere ridefinite nel corso del progetto di attuazione del SIGE e il PI dovrà prevedere specifici passi di analisi in merito.

6. Interazioni con gli altri sistemi informativi

In questo capitolo vengono evidenziate le interazioni alle quali il SIGE dovrà adempiere al fine sia di ottenere una corretta integrazione con la realtà dei sistemi e delle banche dati già in essere o in divenire all’interno del Comune di Firenze, sia di minimizzare la quantità di operazioni che gli utenti finali devono effettuare a video, garantendo un’unica immissione di dati senza duplicazioni di informazioni già esistenti.


10

6.1 BDPI (Banca Dati Patrimonio Informativo)

Il progetto BDPI prevede la costruzione di una banca dati unificata di tutti i dati del Comune di Firenze, normalizzati e bonificati. La BDPI (Banca Dati del Patrimonio Informativo) è il risultato atteso di questo progetto, con l'intendimento di farne nel tempo la fonte unica e unitaria di tutti i dati del Comune, mediante la graduale confluenza dei dati contenuti in tutti i database applicativi attuali.

Tale progetto, in corso di attuazione nel periodo previsto di esecuzione del contratto oggetto della presente gara, si articola in tre fasi che, rispettivamente, prevedono:

• La creazione di una prima versione della BDPI che accoglie una copia statica, estratta a un dato momento, dei dati delle "banche dati sorgente" 1 (mediante l'impiego di strumenti di tipo ETL); sulla "BDPI statica" vengono esercitati e affinati gli algoritmi di bonifica e integrazione che, una volta messi a punto, generano una serie di proposte di correzione dei dati scorretti individuati sulle banche dati sorgente. Tale fase è già conclusa.

• Dopo un'ultima alimentazione statica, tutti gli aggiornamenti da allora in poi effettuati sulle banche dati sorgente verranno immediatamente replicati sulla BDPI attraverso opportuni automatismi. Tale fase è in uno stadio realizzativi molto avanzato.

• La creazione di un cruscotto avanzato di gestione e monitoraggio della "BDPI dinamica". Quest’ultima fase verrà svolta entro la prima metà del 2008.

La BDPI si configura pertanto come un sistema terzo, di livello intermedio e intermediario in grado di ottenere i dati di tutte le applicazioni comunali e di ritrasmetterli (naturalmente secondo determinate regole di protezione della privacy, etc.). Su tale banca dati potranno essere definite le “business rules” di interscambio.

In tale contesto, il Sistema dovrà permettere una semplice estrazione del "differenziale dei dati" (modifiche dalla precedente esportazione) su tabelle di database o flussi XML, in grado di alimentare la BDPI.

Le principali tabelle della BDS SIGE (anagrafiche dei soggetti e degli oggetti) dovranno possedere un insieme minimo di attributi obbligatorio che verrà specificato in fase di analisi di dettaglio.

L’Applicazione dovrà, come del resto già richiesto, fornire a corredo una dettagliata documentazione della logica applicativa e della BDS ed essere in grado di gestire e storicizzare “la segnalazione di bonifica” proveniente dalla BDPI, almeno tramite campi note su tutti i record o, meglio, tramite soluzioni più strutturate.

Inoltre, dovrà permettere di importare in automatico le bonifiche sui dati effettuate su BDPI, permettendo aggiornamenti automatici o semiautomatici delle informazioni contenute nella BDS.

6.2 People ed EFirenze

People è acronimo di “Progetto Enti Online Portali Locali Egovernment”. I riferimenti al progetto sono visibili sul sito http://www.progettopeople.it. Obiettivo di People è la costruzione di portali, configurati come "Comuni virtuali" che, affiancandosi ai "Comuni fisici", consentano ai cittadini un accesso diversificato, multicanale, sicuro e sempre disponibile ai più significativi servizi comunali, ovvero:

• Servizi per la fiscalità locale; • Servizi per il rilascio di autorizzazioni e concessioni; • Servizi diretti alla persona (assistenziali, scolastici, culturali, educativi ...); • Servizi delle anagrafi comunali; • Servizi dai Sistemi Informativi Territoriali (SIT).

1 Col termine di “banca dati sorgente” (o BDS) si intende quella dell’applicazione in questione: in questo caso, dunque, la banca dati propria del SIGE.


11

Per quanto riguarda l’area dei servizi fiscali il cittadino sarà in grado di: • Realizzare visure fiscali; • Compilare e pagare le dichiarazioni fiscali; • Presentare pratiche di richiesta rimborso o istanze di vario tipo

People mette a disposizione un framework che espone i servizi cui si è testé accennato, denominati “servizi di frontend”.

Ad ogni servizio di frontend possono corrispondere uno o più servizi di backend.

Nell’ambito di integrazione del SIGE con People, il Fornitore dovrà realizzare alcuni moduli software (denominati appunto “servizi di backend”) sulla base delle specifiche architetturali definite dal progetto People stesso e, comunque, fornite dalla DSI.

In generale, un servizio di backend dovrà esporre uno o più web service che rispecchino l’interfaccia e il dominio del componente fornito con il framework People. I servizi People dell’area fiscale da prendere in esame sono quelli relativi alle aree tematiche ICI e COSAP, mentre per il CIMP ancora non sono stati modellati servizi.

L'integrazione con i servizi People deve avvenire in modo da poter far gestire agli operatori comunali, detti di backoffice, la pratica People esattamente con le medesime modalità adottate nel caso in cui la pratica venga presentata attraverso sportello.

Quindi, ogni servizio People dovrà fornire, per quanto riguarda il backoffice, tutti gli elementi necessari ed utili per l'assegnazione della pratica da parte di un supervisore all'operatore e per la lavorazione della stessa.

Nei paragrafi seguenti è esposta la lista dei servizi, suddivisi per tipologia, che dovranno essere integrati verso i sistemi di backoffice presenti all’interno del SIGE.

6.2.1. Area ICI

A) SERVIZI DI VISUALIZZAZIONE E CALCOLO

Calcolo Manuale Imposta ICI

L'Utente può calcolare l'imposta dovuta per l'anno di competenza selezionato, comprensiva di un eventuale ravvedimento operoso, solamente in base ad informazioni fornite dall'utente stesso.

Calcolo Imposta Dovuta Per il Contribuente ICI

L'Utente può calcolare l'imposta dovuta, comprensiva di un eventuale ravvedimento operoso, a partire dalle informazioni in possesso del Comune relativamente ai cespiti imponibili attivi per l'anno di competenza selezionato. Queste informazioni possono essere eventualmente integrate con informazioni relative ad altri cespiti dichiarati, ma non ancora recepiti dall'amministrazione

Visualizzazione Pagamenti ICI Effettuati

Il servizio permette all'Utente la visualizzazione delle informazioni relative ai pagamenti ICI effettuati e recepiti dal comune divisi per pagamenti di provvedimenti e di imposta ordinaria

Visualizzazione Cespiti Attivi ICI per Anno

Il servizio permette all'Utente di visualizzare le informazioni relative ai cespiti imponibili ICI, attivi nell'anno di imposta.

Visualizzazione Cespiti ICI con Richiesta Aliquote Speciali


12

Il servizio permette la visualizzazione dei cespiti per i quali il Contribuente ha presentato richiesta per poter usufruire di agevolazioni quali aliquota ridotta o maggiore detrazione.

Visualizzazione Dichiarazioni e Comunicazioni ICI Presentate e Recepite dal Comune

Il servizio permette all'Utente la visualizzazione delle informazioni relative alle dichiarazioni/comunicazioni ICI presentate e recepite dal Comune

Visualizzazione Provvedimenti di Rimborso ICI Emessi

Il servizio permette all'Utente la visualizzazione delle informazioni relative ai provvedimenti di rimborso ICI emessi dal Comune

Stato delle istanze amministrative presentate dal contribuente

Il servizio permette all'Utente la visualizzazione dello stato delle istanze presentate all'Ufficio ICI e per le quali è necessaria l'attivazione di una fase istruttoria da parte dell'Ufficio

Visualizzazione Provvedimenti Sanzionatori ICI Rateizzati

Il servizio permette all'Utente la visualizzazione delle informazioni relative ai provvedimenti sanzionatori ICI rateizzati emessi dal Comune.

B) SERVIZI DI RICHIESTA

Istanza di Rimborso ICI

Il servizio permette all'Utente la presentazione di una richiesta di rimborso ICI a seguito di un pagamento effettuato in misura maggiore rispetto al dovuto.

Istanza di Interpello ICI

Il servizio permette all'Utente di chiedere all'Amministrazione Comunale un parere in caso di dubbi nell'applicazione dei regolamenti.

In questo caso, se il contribuente fornisce una proposta di soluzione al quesito e non riceve risposta in merito entro x giorni, la proposta di soluzione del contribuente, anche se errata, è vincolante per il Comune. Se il Comune fornisce una risposta entro x giorni, e questa si rivela errata a favore del contribuente, è comunque vincolante per il Comune.

Istanza per Aliquote Ridotte ed Ulteriori Detrazioni ICI

Il servizio permette all'Utente la presentazione di una richiesta per poter usufruire delle agevolazioni ICI per specifiche categorie di contribuenti e cespiti imponibili.

Istanza per Rateizzazione Provvedimenti sanzionatori ICI

Il servizio permette all'utente di inserire una richiesta di rateizzazione riguardante uno o più provvedimenti sanzionatori ICI.

Può essere richiesta la rateizzazione dei provvedimenti notificati nello stesso anno solare qualora l'importo complessivamente dovuto risulti uguale o superiore ad un fissato importo. La rateizzazione, possibile fino ad un massimo di ventiquattro rate mensili, e' subordinata all'esistenza di una situazione di temporaneo disagio economico del contribuente. L'istanza va inviata entro sessanta giorni dalla notifica dell'ultimo provvedimento.

Annullamento di un provvedimento ricevuto

Il servizio permette all'utente di richiedere l'annullamento di un provvedimento sanzionatorio ICI inviato dal Comune, motivando adeguatamente tale richiesta.

Accertamento con adesione


13

Il servizio permette al contribuente al quale sia stato notificato avviso di accertamento, di formulare, anteriormente all'impugnazione dell'atto innanzi alla Commissione Tributaria Provinciale, istanza in carta libera di accertamento con adesione indicando il proprio recapito anche telefonico.

L'accertamento con adesione è applicabile ai soli accertamenti sostanziali (nei quali è stimato l'imponibile) e non si estende agli atti di liquidazione dell'imposta né a quegli accertamenti nei quali l'importo dovuto è determinato da elementi certi e incontrovertibili.

C) SERVIZI DI PAGAMENTO

Pagamento ICI in modalità anonima

Il servizio permette all'Utente il pagamento del bollettino ICI in forma anonima per conto di un cittadino che, comunque, viene identificato.

Pagamento ICI in modalità guidata

L'Utente, a partire dalle informazioni in possesso del Comune relativamente agli immobili attivi per l'anno, che può eventualmente integrare con informazioni relative ad altri immobili dichiarati, ma non ancora recepiti dall'amministrazione, può calcolare l'imposta dovuta per l'anno corrente, in base ai regolamenti vigenti ed effettuare il pagamento del bollettino ICI.

Il servizio è utilizzabile solo nel periodo di tempo in cui è ammesso il pagamento dell'ICI: dal 1° gennaio al 16 giugno oppure dal 1° al 16 dicembre. Qualora la data di scadenza fosse superata l'utente deve utilizzare il servizio di pagamento con ravvedimento operoso.

Pagamento con ravvedimento operoso in modalità guidata

Il servizio permette all'Utente il pagamento del bollettino ICI in forma anonima per conto di un cittadino che, comunque, viene identificato.

Pagamento nell’ambito di una rateizzazione concessa in modalità guidata

Il servizio permette all'Utente il pagamento di un provvedimento sanzionatorio ICI in forma rateale in base al piano di ammortamento concesso dal Comune. Il pagamento delle singole rate deve avvenire inderogabilmente entro le scadenze fissate. Il mancato pagamento di una rata entro la scadenza prevista comporta la decadenza del provvedimento di rateizzazione e la riscossione di quanto ancora dovuto in un'unica soluzione.

Pagamento provvedimento in modalità guidata

Il servizio permette all'Utente il pagamento di un provvedimento sanzionatorio ICI in forma rateale in base al piano di ammortamento concesso dal Comune. Il pagamento delle singole rate deve avvenire inderogabilmente entro le scadenze fissate. Il mancato pagamento di una rata entro la scadenza prevista comporta la decadenza del provvedimento di rateizzazione e la riscossione di quanto ancora dovuto in un'unica soluzione.

6.2.2. Area CIMP

Non esistono al momento realizzazioni di servizi People tributari riguardo al CIMP.

6.2.3. Area COSAP

A) SERVIZI DI VISUALIZZAZIONE E CALCOLO

Calcolo manuale dei preventivi di spesa COSAP

Il servizio permette all'utente di effettuare il calcolo del dovuto COSAP in base alle informazioni sulla singola occupazione fornite dall'utente stesso.

Visualizzazione provvedimenti sanzionatori


14

Il servizio permette all'utente la visualizzazione dei provvedimenti sanzionatori COSAP emessi dal Comune nei suoi confronti.

Visualizzazione pagamenti effettuati e da effettuare

Il servizio permette all'Utente la visualizzazione dei pagamenti COSAP effettuati e di quelli ancora da effettuare

B) SERVIZI DI RICHIESTA

Richiesta di rimborso COSAP

Il servizio permette la presentazione di una richiesta di rimborso COSAP a seguito di un pagamento effettuato in misura maggiore rispetto al dovuto.

C) SERVIZI DI PAGAMENTO

Pagamento COSAP in modalità guidata

Pagamento COSAP in modalità anonima e guidata

Pagamento provvedimenti sanzionatori

6.3 Sistema STARIS (stato della riscossione) e collegamento al gestionale di contabilità (applicativo Inf.Or.)

Il Comune di Firenze si avvale di alcuni servizi forniti dal sistema Equitalia Servizi relativamente alla emissione e rendicontazione dei ruoli coattivi.

In particolare, il DRFSE acquisisce un flusso fornito dal sistema web di Equitalia Servizi contenente quanto segue: • le comunicazioni di iscrizioni a ruolo (CIR), gli avvisi bonari (prodotti, non prodotti e non

recapitati) e informazioni sulla formazione, notifica e delega delle cartelle; • i provvedimenti emessi dall'Ente e presi in carico dagli agenti della riscossione (informazioni

sulle riscossioni);

• dati contabili relativi ai riversamenti; • dati identificativi delle informazioni da annullare (relativamente alle operazioni di discarico del

ruolo);

• dati riepilogativi sulle partite, movimentate e non, per i ruoli presi in carico dalla Concessione; • informazioni di dettaglio delle procedure esecutive svolte dai Concessionari; • dati identificativi sullo stato della riscossione trasmessi dai Concessionari al sistema Equitalia

Servizi;

• comunicazioni ed informazioni relative all’inesigibilità del ruolo.

Il flusso informativo sopra descritto viene prodotto e caricato periodicamente all’interno del sistema denominato STARIS attraverso il quale si effettuano le seguenti principali operazioni: • Elaborazione dati relativi al flusso proveniente dal sistema web di Equitalia Servizi,

attraverso la quale si ottengono raggruppamenti anche per accertamento finanziario e si conosce in modo dettagliato la posizione di iscrizione a ruolo del soggetto, ivi comprese le informazioni rese che documentano le fasi intraprese dal concessionario stesso per l’acquisizione del credito. Inoltre consente di conoscere la situazione relativa agli accertamenti e ai dati di associazione tra ruolo e tributo.

• Elaborazione delle comunicazioni di inesigibilità. Nei casi per i quali il concessionario non è riuscito a riscuotere il dovuto, produce, in accordo a dei termini temporali, la documentazione relativa alle azioni intraprese con la quale giustifica le situazioni di mancata riscossione del credito (es: casi di fallimento etc...). Nei casi in cui tale documentazione è insufficiente, o non viene prodotta nei termini previsti, il Comune può esigere il credito direttamente dall’agente della riscossione di riferimento.


15

• Produzione flusso elettronico per il sistema della contabilità, utilizzato dalla Ragioneria comunale (sistema fornito dalla ditta Inf.Or. s.r.l. di Arezzo). Tale operazione è emessa a seguito del procedimento relativo alla riscossione di una “partita” andata a ruolo, attraverso la quale l’agente della riscossione è in grado di emettere una bolletta. Nell’accezione generale di gestione del procedimento relativo al ruolo (in ambito comunale) le bollette emesse vengono inviate al servizio Ragioneria, il quale le suddivide in base al tributo/canone di riferimento; successivamente vengono inviate agli uffici di competenza che hanno quindi la possibilità di emettere le relative reversali di incasso. Attraverso il sistema STARIS le operazioni di ricongiungimento delle bollette, di comunicazione agli uffici e di emissione delle relative reversali sono fatte in modo automatico in quanto tali funzionalità sono state integrate con il sistema di contabilizzazione delle entrate dai ruoli sopra menzionato.

Attualmente per ogni entrata comunale esiste una diversa procedura di gestione del ruolo (formazione, iscrizione, discarico, sospensione, etc...): a partire dal 2008 verrà istituito un ufficio unico comunale che gestirà per intero le funzioni relative alla riscossione coattiva, mantenendo a livello decentrato la competenza riguardo al solo merito di quanto iscritto a ruolo.

Pertanto le funzionalità del Sistema dovranno essere strutturate in modo da renderlo idoneo alla gestione unificata del ruolo comunale.

Al fine di ottimizzare le operazioni di gestione centralizzata del ruolo, all’interno del SIGE dovranno, pertanto, essere adeguati i procedimenti di creazione del flusso telematico da inviare al sistema Equitalia Servizi per le lavorazioni successive quali:

• discarico; • sospensione; • revoca della sospensione; • acquisizione maggiore rateizzazione; • revoca maggiore rateizzazione.

Dovranno pertanto essere ottimizzati i procedimenti di creazione del flusso telematico da inviare al sistema Equitalia Servizi per le lavorazioni successive.

Oltre alle operazioni sopra elencate, attraverso le quali è possibile ottenere la situazione completa delle attività di riscossione e delle procedure esecutive operate dagli agenti della riscossione su ruoli e avvisi di pagamento emessi dall’Ente, con STARIS possono essere consultati elaborati sintetici ed analitici relativi agli elenchi di carico e alle singole posizioni contributive, monitorando l’andamento stesso dell’attività di riscossione, tramite: • stampe sintetiche di riepilogo sullo stato della riscossione di uno o più ruoli • stampe analitiche di dettaglio sullo stato della riscossione (per ruolo, per codice entrata, per

singolo contribuente, per concessione) • svecchiamento del ruolo completamente riscosso dalla propria base dati ruoli • compressione, per il ruolo in gran parte riscosso, delle informazioni di dettaglio del ruolo,

tenendo traccia della informazione di ripresa saldo del ruolo.

L’integrazione del sistema STARIS con i sottosistemi di cui sarà composto il SIGE dovrà consentire, pertanto, di recepire e poter consultare informazioni relativamente a: • stato della riscossione; • carico del ruolo suddiviso per contribuente; • quantitativo riscosso del carico relativo ad un soggetto; • quantitativo ancora da riscuotere relativamente ad un soggetto; • altri elementi utili alla gestione della posizione relativa al ruolo emesso, anche in riferimento

alla documentazione fornita dagli agenti della riscossione.


16

6.4 Protocollo dell’Ente

Il SIGE dovrà integrarsi col nuovo sistema di protocollazione unico dell’Ente (progetto SIGEDO, fornitore la ditta ADS S.p.A.), offrendo funzionalità che consentano di effettuare le registrazioni di protocollo immesse dal DRFSE, ovverosia dei dati previsti dal DPR 445/2000 e ss.mm.ii., in particolare l’art. 53, per quanto riguarda il nucleo minimo di protocollo, tramite web service) da definirsi nei dettagli dopo l’aggiudicazione della fornitura.

Ogni documento da e per il DRFSE verrà protocollato, rispettivamente in uscita e in ingresso, con un numero attribuito da tale sistema centralizzato. Quest’ultimo, dunque, funzionerà primariamente, rispetto al SIGE, come motore unico di numerazione. Il SIGE acquisirà tale numero unico e lo utilizzerà per tutte le funzioni per le quali si renda necessario il riferimento a un documento (comunicazioni con i contribuenti, con gli altri uffici o con altri Enti).

E’ da prevedere anche l’utilizzo di numeri di pratica (o faldone o incartamento). Una pratica consiste in un raggruppamento omogeneo di documenti, protocollati singolarmente in momenti diversi, che si riferiscono a un unico procedimento o un’unica posizione contributiva e aventi un’unica classificazione. Il SIGEDO prevede la possibilità di definire tali pratiche e gestirne la numerazione, sicché l’interazione richiesta tra SIGE e SIGEDO dovrà consentire l’uso di tali numeri di pratica.

Il SIGEDO, in tale contesto, prevede, attraverso un sistema integrato di gestione documentale, la storicizzazione completa delle informazioni relative ai documenti protocollati e archiviati, nonché dei riferimenti, dei parametri e dei codici tabellari che consentono di effettuare elaborazioni di situazioni storiche pregresse. Le funzione di acquisizione, inoltro e archiviazione dei documenti, degli atti e di eventuali allegati ad essi dovranno essere integrate all’interno del SIGE tramite chiamate ad apposite librerie che saranno messe a disposizione dal SIGEDO.

I profili degli utenti del SIGE abilitati a svolgere funzioni di protocollazione dovranno essere sincronizzati automaticamente sul SIGEDO il quale, pertanto, esporrà funzionalità di abilitazione alla registrazione, modifica, annullamento e storicizzazione dell’utente.

Il nucleo minimo di protocollo consente di gestire il titolario di classificazione, che – nell’ambito dell’integrazione richiesta dovrà essere dinamicamente alimentato con le categorie di specifico interesse del DRFSE.

Il sistema SIGE dovrà inoltre mettere a disposizione, tramite BDPI, al sistema SIGEDO le anagrafiche dei mittenti o dei destinatari delle comunicazioni relative ad es. ad una pratica, nel rispetto dei canoni di sicurezza della trasmissione dei dati personali, utilizzando cioè protocolli di trasmissione sicura.

Tramite l’integrazione richiesta, si potrà tenere traccia delle comunicazioni del DRFSE interne ed esterne all’Ente.

6.5 Catasto

Dal 1° novembre 2007 il Comune di Firenze, quale Comune capofila, gestisce in forma diretta e completa le funzioni catastali. E’ costituito l'ufficio denominato "Ufficio Catastale Area Fiorentina", così come previsto dalla Legge Finanziaria 2007, con un polo centrale ubicato a Firenze (in via Pietrapiana) e sportelli dislocati nei singoli Comuni. A titolo informativo si riporta che, con molta probabilità, la gestione verrà svolta in forma associata (dopo la stipula di una convenzione) con i comuni di Bagno a Ripoli, Barberino Valdelsa, Calenzano, Campi Bisenzio, Fiesole, Figline, Greve in Chianti, Impruneta, Incisa, Lastra a Signa, Rignano, San Casciano, Scandicci, Sesto Fiorentino, Signa, Tavarnelle (per un totale di oltre 600mila abitanti).

Le funzioni catastali attribuite ai Comuni saranno: • la consultazione della banca dati catastale unitaria nazionale e servizi di visura catastale; • la certificazione degli atti catastali conservati nella banca dati informatizzata;


17

• l'aggiornamento della banca dati del catasto mediante trattazione delle richieste di variazioni di intestazione e correzione dei dati amministrativi;

• le riscossioni erariali per i servizi catastali; • la verifica formale, accettazione e registrazione delle dichiarazioni tecniche di aggiornamento

del catasto fabbricati e del catasto terreni (aggiornamento geometrico e variazioni colturali); • la definizione dell'aggiornamento della banca dati catastale, sulla base delle proposte di parte

e degli adempimenti d'ufficio. La gestione diretta di queste funzioni consentirà ai comuni di migliorare l'integrazione dei processi tecnicoamministrativi con l'Agenzia del Territorio, di favorire il processo di allineamento fra le informazioni in dotazione, di accrescere la conoscenza del patrimonio immobiliare del proprio territorio e di ottimizzare i processi di programmazione e gestione, nonché quelli impositivi, di rendere disponibile al cittadino un servizio più agevole e funzionale, in quanto fornito in un ambito più vicino.

Per lo svolgimento delle operazioni di pertinenza del DRFSE, il SIGE dovrà garantire l’integrazione con il sistema di interscambio realizzato da SOGEI che sarà utilizzato dai Comuni per l’aggiornamento e la consultazione dell’Anagrafe Immobiliare Integrata.

6.6 SIT

Il sistema SIT, all’interno del Comune di Firenze, svolge il ruolo di collettore dei dati relativi alla mappatura di informazioni di carattere territoriale. Esso ha funzioni di supporto non solo relative alla pianificazione urbanistica, ma soprattutto agli uffici che si occupano della gestione amministrativa del territorio, anche per quello che riguarda la fiscalità locale e le attività economiche ad essa connesse.

Il SIT farà da tramite con la cartografia catastale aggiornata (con relative informazioni censuarie), che dovrà integrarsi con la cartografia tecnica comunale e con gli strumenti urbanistici.

Per quello che riguarda i tributi e la fiscalità locale, il SIT consente di integrare l’informazione prettamente fisica del territorio con l’informazione a carattere economico, ai fini della corretta applicazione dei tributi locali. La conoscenza aggiornata ed integrata del territorio fornisce la possibilità di seguire l’evoluzione nel tempo di ogni singola particella o oggetto di natura territoriale sottoposto a canone o imposta.

Il sistema SIGE avrà accesso a specifiche funzionalità offerte dal SIT (in maniera diretta o tramite BDPI) per quello che concerne: • Interrogazione della banca dati delle concessioni edilizie, per ottenere i dati relativi alle unità

immobiliari con concessione edilizia in scadenza o che hanno appena dichiarato la chiusura dei lavori, prima ancora della presentazione della dichiarazione da parte del contribuente. Contestualmente a tali informazioni dovranno essere accessibili anche le relative planimetrie, di provenienza catastale.

• Interrogazione della componente toponomastica (stradario comunale) e, più in generale, di tutti gli spazi della città (aree di circolazione) per quanto riguarda il loro nome ed il numero civico. Tale collegamento è rilevante per il fatto che il SIT costituisce il riferimento principale degli aggiornamenti relativi al piano topografico di tutto il territorio comunale in conseguenza dello sviluppo urbanistico, della denominazione delle vie e dell’attribuzione dei numeri civici a fronte di modifiche del piano stesso (nuove costruzioni, abbattimenti, etc.).

• Interrogazione integrata dell’anagrafe delle unità immobiliari (dati censuari, dati anagrafici dell’immobile e localizzazione delle unità immobiliari, urbane o terreni): per quello che concerne le unità immobiliari urbane, i vantaggi derivano dalla possibilità di incrociare le informazioni di carattere territoriale proveniente dagli archivi catastali, delle concessioni edilizie e delle attività economiche con i dati anagrafici e fiscali del contribuente; per quello che riguarda invece le unità immobiliari terreni, il vantaggio deriva dall’incrocio tra la cartografia catastale, il PRG/Piano strutturale e gli strumenti attuativi, i permessi di


18

costruzione e le dichiarazioni dei contribuenti: è comunque evidente che il problema non si risolve con un semplice incrocio, ma anche considerando le informazioni di carattere tributario presenti nel SIGE (valore commerciale dei terreni).

• Localizzazione geografica degli impianti pubblicitari, attraverso una banca dati cartografica (con rilevazione da terra).

• Localizzazione delle aree soggette ad occupazione di suolo pubblico anche attraverso la banca dati toponomastica e banca dati edilizia.

6.7 Altre banche dati comunali

In generale, si richiede che il SIGE renda possibile sia l’esecuzione di attività di verifica e controllo, offrendo servizi che consentano di esportare i suoi dati allo scopo di incrociarli con quelli di altre banche dati (oltre la BDPI, descritta al paragrafo 6.1), sia di importare dati da tali banche dati, allo scopo di realizzare un adeguato livello di integrazione funzionale e organizzativa, evitando il più possibile la digitazione duplicata dei medesimi dati, col corredo di potenziali errori, disallineamenti e inefficienze che ciò comporta.

I sistemi e le relative banche dati, oggetto di tale integrazione, sono quelli dello Sviluppo Economico, dell’Anagrafe, etc: a tale proposito, il SIGE offrirà apposite funzionalità di cooperazione applicativa specificate, laddove necessario, nel seguente cap. 7.

Si citano, a titolo di esempio, i sottosistemi COSAP e CIMP, in quanto l’emissione dell’atto autorizzatorio da parte della Direzione competente deve consentire la creazione, all’interno del SIGE, della posizione relativa al soggetto passivo del canone e all’oggetto o agli oggetti del provvedimento. In sostanza, le procedure informatiche delle Direzioni competenti invieranno al SIGE i dati, le cui descrizioni più dettagliate sono riportate nei paragrafi relativi ai sottosistemi di gestione dei due canoni. A sua volta, il SIGE restituirà alle procedure delle Direzioni competenti le notifiche conseguenti da procedimenti propri del DRFSE.

7. Requisiti del SIGE

L’Applicazione dovrà soddisfare i requisiti descritti nel seguito (da intendersi come requisiti minimi richiesti), con riferimento alle caratteristiche generali (par. 7.1), a quelle tecnologiche (par. 7.2) e a quelle funzionali (par. 7.3).

Essa dovrà garantire la gestione completa di tutti gli adempimenti previsti per il trattamento dei dati e dei processi amministrativi riguardanti le entrate comunali. Di seguito vengono descritte le caratteristiche generali, tecnologiche e funzionali alle quali il SIGE dovrà rispondere.

7.1 Caratteristiche generali

[RG1] Flessibilità L’Applicazione dovrà garantire un elevato grado di flessibilità di gestione dei dati, di modellazione dei processi e delle logiche di elaborazione e poter consentire l’esportazione di dati e funzionalità. Dovrà inoltre consentire il rapido e agevole recepimento delle evoluzioni riguardanti la normativa di riferimento in materia tributaria. A tali fini, il SIGE deve consentire il facile svolgimento, da parte degli utenti a ciò abilitati, di tutte le operazioni di gestione e amministrazione dei dati contenuti nelle tabelle generali e di impostazione parametrica. A questo proposito, la Ditta renderà disponibili i dati precaricati del maggior numero possibile di tabelle generali.

[RG2] Integrazione Uno dei presupposti del SIGE è quello di prevedere la creazione di una banca dati tributaria unificata di riferimento per la totalità dei sottosistemi di cui esso si compone, nella quale il contribuente è il principale attore. Ogni sottosistema o modulo della Procedura dovrà,


19

pertanto, essere completamente e coerentemente integrato con gli altri sottosistemi o moduli per quanto riguarda i dati gestiti. Ciò significa, in particolare, che il database di riferimento dell’applicazione sarà unico e adeguatamente normalizzato, allo scopo di evitare ogni duplicazione e inconsistenza dei dati.

[RG3] Storicizzazione e congruenza degli aggiornamenti RG3.1 L’Applicazione dovrà permettere la storicizzazione completa delle informazioni relative alle denunce, nonché di tutti i parametri, i codici ed i dati tabellari che consentano di effettuare ricalcoli, conguagli e ricostruzioni automatiche di situazioni storiche pregresse. RG3.2 Ogni variazione su un dato (o su una combinazione di dati nel database) dovrà produrre in automatico l'aggiornamento di tutti i dati derivati (utilizzati nei processi connessi), in modo da rendere congruente la nuova situazione, a partire dalla data di validità della variazione, e tenendo conto degli effetti già prodotti dalla precedente informazione.

[RG4] Sicurezza, riservatezza, gestione degli utenti Il Sistema dovrà prevedere adeguati strumenti di sicurezza nell’accesso ai dati e di personalizzazione dei profili di utenza, per l’abilitazione alle specifiche funzionalità relative al trattamento dei dati previsti per ciascun profilo, garantendo la massima sicurezza negli accessi e la riservatezza delle informazioni gestite, a norma del D. Lgs. 196/03 e ss. mm. Nel PI dovranno puntualmente essere specificate le politiche di protezione e di tutela che si intende applicare, e i dati sui quali applicarle, allo scopo di garantire il pieno rispetto della normativa vigente. RG4.1 La gestione dell'autenticazione degli utenti dell’Applicazione dovrà essere attuata attraverso il ricorso a meccanismi di single signon messi a disposizione dall’Ente e basati sui più consolidati sistemi di amministrazione degli utenti che aderiscono al modello di metadirectory LDAP. Gli utenti saranno registrati e autenticabili nel dominio comune intranet dell'Ente. RG4.2 Rispetto alle modalità di accesso al sistema, gli utenti dovranno essere distinti almeno nei seguenti raggruppamenti logici: • Utenti amministratori: gli utenti che hanno il compito di configurare e amministrare i

parametri generali di utilizzo del sistema. • Utenti con privilegi speciali (lancio di determinati report, controllo dei log, etc.). • Utenti gestionali: gli utenti, della DRFSE o di altre strutture, preposti alla gestione di

specifici processi. • Utenti abilitati alla sola consultazione di determinate e specifiche informazioni. RG4.3 Ogni utente (persona fisica) del sistema può appartenere contemporaneamente a più tipologie di utenza. RG4.4 I privilegi potranno essere assegnati agli utenti sulla base di elementi quali unità organizzativa di appartenenza dell'utente, ruoli costituiti da funzioni/mansioni e profili di competenza all'interno di unità organizzative. RG4.5 Gruppi di utenti potranno essere strutturati anche in modo trasversale rispetto alle unità organizzative, considerando che gli utenti possono svolgere più ruoli nell'ambito di più unità organizzative. RG4.6 L'amministrazione dei privilegi deve essere svolta tramite apposite funzioni che consentano all'amministratore di procedimento l’attribuzione, la revoca e la delega temporanea dei privilegi ad altri utenti. RG4.7 La gestione dei privilegi dovrà garantire anche agli utenti amministratori la possibilità di delegare, e successivamente revocare, propri privilegi a qualsiasi altro utente o gruppi di utenti.

[RG5] Facilità d’uso RG5.1 La Procedura dovrà presentare un’interfaccia utente grafica intuitiva, snella, coerente e aderente agli standard di mercato. Dovrà essere adottato ogni accorgimento affinché l'utente possa essere "naturalmente" guidato nell'utilizzo dei moduli applicativi e facilitato nelle operazioni di gestione dei dati.


20

RG5.2 Ogni modulo applicativo componente dovrà essere reso omogeneo a prescindere dal fatto che riguardi una funzionalità legata ad un’area applicativa piuttosto che un’altra (es. ICI piuttosto che COSAP). RG5.3 In particolare, dovrà essere curata la razionale organizzazione delle transazioni complesse, prestando particolare attenzione alle caratteristiche di usabilità quali: intuitività, composizione e disposizione delle maschere a video, organizzazione dei menu e delle funzioni, disponibilità nelle operazioni di input di dati precaricati e ogni altro accorgimento atto a facilitare i compiti degli utenti.

[RG6] Aiuto in linea e manuali utente RG6.1 Il Sistema dovrà contenere funzioni di help contestuale online sulle diverse funzionalità. Le pagine di help dovranno essere esposte, per tutte le funzioni utente, in lingua italiana. RG6.2 Le funzioni di help potranno fare riferimento alla "Guida all’utilizzo del sistema" (par. 9.4) cioè il manuale utente che, tassativamente, dovrà essere fornito a corredo del Sistema.

[RG7] Statistiche e reportistica L’Applicazione dovrà consentire di svolgere attività di reportistica avanzata: tutte le informazioni di interesse dovranno essere ricercabili sia attraverso funzioni standard, che automatizzino le richieste ricorrenti con maggiore frequenza, sia in maniera non predefinita, utilizzando schemi liberamente definiti dall’utente per l’estrazione parametrica dei dati, secondo le diverse esigenze e privilegi degli utenti. I risultati delle interrogazioni dovranno poter essere visualizzati, stampati su dispositivi locali ed esportati secondo i più comuni formati.

[RG8] Modulistica e stampa RG8.1 L’Applicazione dovrà prevedere specifiche funzionalità che forniscano opportuni template per la predisposizione di modulistica standard secondo schemi predefiniti, personalizzabili dall’utente. RG8.2 Per tutti i documenti la Procedura consentirà la stampa immediata sulle stampanti locali (evitando ovunque possibile l'uso di modulistica prestampata, prefincata o a modulo continuo), assicurando la completa gestione delle operazioni di stampa con visualizzazione della c.d. ”anteprima” a video, ristampa di documenti già emessi e ripartenza da una certa pagina.

[RG9] Interoperabilità con strumenti di produttività individuale L’Applicazione dovrà interoperare con i pacchetti d’automazione d’ufficio, in particolare quelli delle suite OpenOffice e Microsoft Office e dovrà dare la possibilità di generare dinamicamente documenti e modulistica con alternanza di parti fisse e parti variabili.

[RG10] Registrazione delle attività Il Sistema dovrà consentire il monitoraggio degli accessi effettuati in un determinato arco temporale, all’interno di ogni sottosistema, con l’indicazione delle operazioni svolte. I meccanismi di monitoraggio delle attività (log) tracceranno, dunque, le interazioni utente/sistema (identificativo dell'utente, dataora e tipo della transazione, operazione svolta, ecc.), con possibilità di visualizzazione e/o di effettuare stampe riservate.

[RG11] Operazioni batch L’Applicazione garantirà la possibilità per l'utente finale a ciò autorizzato di prenotare, direttamente a video e a propria discrezione, le elaborazioni da eseguire in differita (c.d. batch), ad esempio per lo scambio automatico di dati con altre procedure. Le elaborazioni in differita debbono poter essere eseguite in sicurezza senza interrompere la contemporanea possibilità di gestione decentrata da parte di altri utenti finali (c.d. "elaborazioni batch con gli archivi aperti"), salvo i casi particolari di manutenzioni "di sistema".

[RG12] Prestazioni La Procedura dovrà essere strutturata in modo da assicurare prestazioni e tempi di risposta


21

adeguati alle esigenze degli utenti dell'Ente. Tali parametri verranno valutati in maniera indipendente dall’influenza delle condizioni della rete Intranet dell’Ente e delle macchine server e client utilizzate.

7.2 Caratteristiche tecnologiche

[RT1] Il sistema operativo server impiegato potrà essere Linux o Windows 2000/2003. Sono ammesse anche soluzioni miste, fatta salva l’eccellenza della soluzione architetturale complessiva in termini di compatibilità funzionale dei sistemi, continuità di funzionamento e possibilità di gestione e controllo del sistema hw/sw nel suo complesso. Nel caso di proposta che preveda soluzioni miste devono esserne specificate le motivazioni (p. es., economicità, opportunità funzionale o altro).

[RT2] L’Applicazione sarà basata su un’architettura di tipo 2tier o 3tier clientserver o, preferibilmente, webbased.

[RT3] Per le funzionalità web dovrà essere utilizzabile anche un browser di tipo open source.

[RT4] E’ tassativo l’uso del DBMS Oracle.

[RT5] Per l’installazione del software applicativo, l’Ente metterà a disposizione uno o più server o cluster di server, collegati alla sua rete intranet, per cui la Ditta aggiudicataria dovrà offrire la miglior versione dell’Applicazione ottimizzata per tali sistemi.

[RT6] Dal lato client, l'Ente dispone di diversi modelli di personal computer, con sistemi operativi Microsoft Windows (il più frequente è Windows XP), a partire da Pentium 233MHz con 64 MB di RAM, per cui la Ditta dovrà consentire il pieno utilizzo del Sistema da tutti questi tipi di posto di lavoro, precisando se direttamente o attraverso un'architettura a più livelli (c.d. ntier).

[RT7] I posti di lavoro di cui al punto precedente sono installati nelle sedi del Comune di Firenze e tutti collegati alla rete intranet FiNet, a larghissima banda, dell’Ente. Ad ogni modo, per i casi in cui si rivelasse opportuno (ad es. collegamenti Internet), saranno preferite le applicazioni già predisposte per funzionare anche con configurazioni di client “leggeri”.

[RT8] La Procedura dovrà essere dimensionata per sostenere il carico di lavoro transazionale prodotto da tutti gli utenti collegati per la normale attività d'ufficio.

[RT9] Il tempo medio di risposta a video dovrà essere mantenuto entro tempi accettabili per transazioni unitarie complete di media complessità.

[RT10] Tutte le elaborazioni batch, comprese le riorganizzazioni periodiche degli archivi, dovranno essere progettate accuratamente in modo da poter essere eseguite con sufficiente sicurezza nell'ambito di uno stesso turno di lavoro.

[RT11] In relazione a quanto specificato al precedente cap. 6, l'Applicazione dovrà prevedere la disponibilità di adeguati strumenti di interfacciamento automatico dei dati gestiti con quelli delle altre applicazioni usate dall'Amministrazione al proprio interno e/o in collegamento con altri Enti della P.A. Tali strumenti possono consistere in: ü interfacce, programmi, routine richiamabili, modalità, protocolli "API" e simili (sia batch

che TP) da mettere a disposizione del personale tecnico dell'Amministrazione o di suoi fornitori a ciò autorizzati, per predisporre all'occorrenza interscambi automatici di dati con altre applicazioni;

ü collegamenti software per riutilizzare i dati di valenza generale indicati dall'Amministrazione tra quelli già esistenti nel sistema informativo (anagrafe della popolazione, Banca Dati Patrimonio informativo, protocollo unificato, capitoli/impegni di Bilancio, etc.) o almeno per mantenere con essi un costante allineamento batch controllato.


22

[RT12] La realizzazione di tali collegamenti ed interfacce sarà gestita con le stesse modalità previste per le personalizzazioni del software applicativo di cui al succ.vo par. 8.3.

7.3 Caratteristiche funzionali

La Ditta aggiudicataria deve tassativamente fornire almeno tutte le funzionalità e implementare tutte le caratteristiche descritte in questo paragrafo, tenendo conto che tali specifiche non sono esaustive e, in molti casi, per la loro effettiva realizzazione si rendono necessari ulteriori approfondimenti, da effettuarsi nella fase di analisi di dettaglio prevista dal PI. L’obiettivo qui è di fornire i principali elementi di riferimento alle ditte concorrenti, affinché possano valutare con buona approssimazione le esigenze dell’Ente, e di sottolineare le caratteristiche che verranno ritenute maggiormente significative in sede di valutazione delle offerte tecniche. Imprescindibile, ad ogni modo, è la rispondenza delle funzionalità dell’Applicazione alle prescrizioni ed ai vincoli imposti dalla normativa di riferimento (i cui estremi sono riportati laddove necessario).

Nel prossimo sottoparagrafo sono specificati gli elementi funzionali comuni, consistenti in funzioni o moduli richiamabili da tutti i sottosistemi. Le caratteristiche funzionali dei singoli sottosistemi sono invece riportate nei sottoparagrafi dal 7.3.2 al 7.3.5.

7.3.1. Elementi funzionali comuni a tutti i sottosistemi

[RF1] Anagrafe dei contribuenti Il SIGE dovrà consentire la gestione unificata delle anagrafi dei contribuenti e dei soggetti comunque collegati ai procedimenti del DRFSE (vd. anche a questo proposito [RG2]).

[RF2] Gestione storica dell’anagrafica Il SIGE deve consentire la gestione storica dell’anagrafica (vd. anche a questo proposito [RG3.1]), in riferimento agli iter legati ai procedimenti amministrativi da svolgere. Per esempio, ai fini della gestione del contenzioso è necessario, relativamente all’istruttoria dell’atto, riferirsi alla ragione sociale o a dati del soggetto che risultavano essere ad una certa data e con il quale è stato avviato il rapporto.

[RF3] Gestione e verifica dei pagamenti RF3.1 Il SIGE dovrà consentire la comunicazione ai contribuenti degli importi da loro dovuti e la produzione dei titoli di pagamento. Attualmente ciò avviene attraverso l’integrazione con il sistema POSTEL. RF3.2 Il SIGE dovrà consentire, attraverso semplici impostazioni parametriche, l’acquisizione dei dati relativi ai pagamenti anche attraverso nuove modalità. RF3.3 Esso garantirà altresì la corretta importazione e riconciliazione dei pagamenti effettuati tramite tutte le differenti forme accettate dall’Ente, incluse le modalità interattive di versamento offerte dai servizi di People e da altri servizi online; in sostanza il SIGE deve essere in grado di accettare modalità di pagamento di varia natura: • addebito su conto corrente bancario o postale (anche a mezzo RID); • pagamento on line (tramite People, e altri servizi già utilizzati); • tramite POS allo sportello. RF3.4 L’elaborazione dei file di rendicontazione e dei flussi elettronici dovrà essere eventualmente integrata anche a servizi web sviluppati in tecnologia XML over http/s. RF3.5 In fase di riconciliazione, viene effettuata la verifica e il controllo dei pagamenti e, in conseguenza di tale attività, il SIGE deve consentire di emanare i provvedimenti conseguenti. Attualmente la modalità di riscontro dei pagamenti avviene tramite l’elaborazione dei dati comunicati dal sistema POSTEL. Il controllo viene effettuato periodicamente in maniera massiva, considerando parametri quali: data di scadenza, data di pagamento ed eventuali note. RF3.6 Nei casi di omesso, parziale o tardivo pagamento del canone o dell’imposta dovuta può essere prevista la definizione agevolata della penale, sempre che essa non sia già stata contestata e comunque non siano iniziate attività di ispezione, verifica o di accertamento da parte degli agenti preposti al controllo, o da parte della stessa DRFSE. La definizione agevolata di tale


23

penale è diversa in percentuale a seconda della data in cui è avvenuto il “ravvedimento operoso”, cioè il versamento dopo la data di scadenza del canone mancante da parte del soggetto. Il SIGE consentirà un’agevole e parametrica gestione di tali situazioni.

[RF4] Compensazioni tra canoni, imposte e altri crediti e debiti dell’Amministrazione comunale Il SIGE dovrà poter gestire le compensazioni tra canoni, imposte e altri crediti dell’Amministrazione Comunale in considerazione di quanto previsto da norme di legge, regolamenti e atti comunali.

[RF5] Diffide ad adempiere, accertamenti, ingiunzioni e riscossione coattiva. Penalità, interessi di mora, sanzioni 2 , indennità Il SIGE deve gestire le procedure sanzionatorie e di riscossione coattiva (ruolo coattivo). RF5.1 La fase coattiva è, però, successiva e consequenziale, nei casi appropriati, alla fase di controllo dei pagamenti. La fase di controllo prevede l’emanazione preliminare di due diversi atti amministrativi a seconda del caso. In particolare si ha: • diffida ad adempiere e accertamento, nei casi di ritardato, parziale o di omesso pagamento,

per i quali è previsto il calcolo e l’applicazione di interessi di mora e/o penali; • ingiunzione, accertamento nel caso di applicazione di sanzioni. La generazione delle diffide ad adempiere viene effettuata creando gli “oggetti di diffida” in uno stato “temporaneo”. Solo dopo un’ulteriore attività di verifica avviene il consolidamento con la relativa attribuzione della numerazione definitiva e successiva notifica al soggetto. A seguito di tali procedimenti amministrativi, vengono nuovamente effettuati i controlli sui pagamenti. Dopo la scadenza di ulteriori 60 giorni, per i quali non si è riscontrato il rientro dell’importo del canone imputato, si dà corso alla creazione della “proposta di ruolo coattivo”. RF5.2 L’emissione del ruolo coattivo comprende la produzione del supporto magnetico o altra forma prescritta dalla legge di riferimento. Il flusso del ruoli coattivi emessi è conforme al tracciato definito dal sistema Equitalia Servizi. Quest’ultimo effettua infatti i controlli relativi a : • anagrafe tributaria (tramite il sistema dell’Agenzia delle Entrate); • stampa del ruolo; • invio al Comune per la messa in opera dell’esecutività dello stesso (relativamente ai ruoli

passati alla fase di controllo); • segnalazione dei ruoli con errori per i quali gli uffici dovranno effettuare una nuova verifica. RF5.3 La fase del ruolo coattivo è comune, oltre che alle procedure di gestione dei tributi comunali (ICI, CIMP, etc...), anche ad altre procedure presenti all’interno dell’Ente (es. refezione scolastica, contravvenzioni di Polizia Municipale, etc.). Ciò significa che il modulo di gestione dei ruoli del SIGE metterà a disposizione strumenti che consentano alle altre Direzioni di convogliarvi i flussi, attinenti i ruoli, generati dalla rispettive procedure di gestione e destinati al sistema Equitalia Servizi. RF5.4 Attraverso lo STARIS (descritto al precedente par. 6.3) sarà poi possibile gestire e monitorare, in maniera centralizzata, lo stato delle riscossioni dai ruoli emessi e di emettere le relative reversali di incasso.

[RF6] Contenzioso Alla stessa stregua, il SIGE, attraverso il sottosistema di gestione del contenzioso, dovrà interagire con gli altri sottosistemi in maniera completamente integrata, fornendo tutti gli elementi utili per la gestione delle controversie tributarie, come specificato in dettaglio nel seguito del presente paragrafo.

[RF7] Funzionalità di ricerca del soggetto passivo Le funzionalità di ricerca del soggetto passivo di canoni e imposte dovranno essere realizzate nel SIGE prevedendo meccanismi quanto più funzionali per gli operatori, a prescindere dal fatto, ad es., che si tratti di una persona fisica piuttosto che giuridica.

[RF8] Protocollo e gestione documentale: integrazione col SIGEDO

2 Per quanto riguarda solo il COSAP, le sanzioni sono di tipo amministrativopecuniario, in riferimento alla L. 689/81.


24

RF8.1 Come già indicato al precedente par. 6.4, il Sistema dovrà essere in grado di attribuire un numero di protocollo mediante l’interazione col sistema SIGEDO, laddove ciò si renderà necessario e, in particolare, in tutti i punti espressamente indicati dai requisiti di questo capitolato. RF8.2 Il Sistema, sempre interagendo col SIGEDO, permetterà altresì di recepire la documentazione elettronica (eventualmente firmata digitalmente) degli atti autorizzatori di riferimento, utili in sede di verifiche e controllo da parte degli operatori. RF8.3 Di ogni oggetto dovrà essere possibile ricercare atti e documenti presentati anche in forma grafica, interagendo col sistema di archiviazione documentale mediato dal SIGEDO.

[RF9] Rimborsi Il SIGE, attraverso tale modulo, deve consentire la gestione del procedimento relativo ad una richiesta di rimborso effettuata dal contribuente a seguito di somma versata e non dovuta (e, comunque, entro i termini previsti dalla normativa statale e comunale vigente di riferimento). RF9.1 Il modulo Rimborsi del SIGE consentirà la gestione dei dati legati alla pratica di rimborso comprendenti: • le generalità del titolare del provvedimento; • del richiedente (se diverso dal titolare); • gli estremi del provvedimento stesso; • le motivazioni della richiesta; • la documentazione ulteriore (comprese eventuali ricevute di pagamento) necessaria ad

istruire la pratica stessa; • importo eventualmente compensato. RF9.2 Gli estremi di ogni atto e documento legato alla pratica devono essere registrati e informatizzati all’interno del SIGE, cui dovranno essere resi disponibili dal SIGEDO (che conterrà la parte documentale di riferimento della pratica – vd. requisito RF8). L’istruzione del rimborso consente di verificare la presenza di un eventuale credito nei confronti del contribuente, a seguito dei controlli di ricalcolo effettuati. RF9.3 Il SIGE dovrà consentire di emettere l’eventuale rimborso avvalendosi dei più comuni canali di riscossione utilizzabili dal contribuente: pagamento a mezzo tesoreria comunale, conto corrente bancario o postale, etc.

[RF10] Simulazioni del gettito relative a dichiarazioni permanenti e/ o periodiche Il Sistema deve prevedere in ogni momento la possibilità di analisi del gettito attraverso la modifica dei parametri di calcolo, allo scopo di ottenere proiezioni riguardo gli effetti delle variazioni di imposta o canone ipotizzate. Le ipotesi di variazione devono potersi riferire anche a singole sottotipologie di canone o di imposta.

[RF11] Riepiloghi di rendicontazione, di incasso, di liquidazione e di rimborso La Procedura renderà possibile ottenere riepiloghi e, pertanto, effettuare controlli sugli importi versati, a seguito della riconciliazione dei flussi di pagamento acquisiti dalle fonti esterne (p. es. Postel), anche ai fini delle attività di accertamento.

[RF12] Incrocio con altri tributi Attraverso il SIGE dovrà essere possibile effettuare indagini incrociate sugli altri oggetti di imposta o canone (es: possibilità di associare l’oggetto di imposta COSAP ad un immobile).

[RF13] Comunicazioni ai contribuenti RF13.1 La Procedura consentirà di associare, in tutti i passi degli iter delle pratiche in cui ciò si renda necessario, una o più comunicazioni verso il soggetto (es.: per la pratica di rimborso, negli step opportuni, si dovrà prevedere la generazione di diniego ovvero di concessione del rimborso, etc…). RF13.2 Sarà altresì possibile la gestione dei diversi stati possibili di tali comunicazioni (es. invio effettuato / attesa risposta, risposta ricevuta, etc.) e delle relative tempificazioni. RF13.3 Ciò avverrà attraverso l’integrazione con il sistema di protocollo unico (SIGEDO – vd. requisito RF8), almeno per quanto riguarda gli aspetti di gestione documentale. E’, comunque,


25

preferibile un’integrazione più stretta, attraverso l’utilizzo delle funzionalità offerte dal sistema di workflow fornito dal SIGEDO.

[RF14] Report e statistiche Il SIGE (vd. anche requisito RG7) deve essere dotato di funzionalità per generare statistiche di vario tipo, sulla base di impostazioni parametriche definibili dall’utente per quello che riguarda: • adempimenti previsti dalla legge; • indagini volte a individuare anomalie e discordanze presenti sulle banche dati attuali; • riepiloghi contabili su accertamenti, liquidazioni, incassi, etc.; • riepiloghi sul soggetto passivo dell’imposta, su oggetti e posizioni contributive; • riepiloghi sulle classi di tariffazione; • quanto altro possa essere necessario come strumento di supporto alle decisioni.

[RF15] Stampe, estrazioni di dati ed esportazioni verso strumenti di produttività individuale Il SIGE (vd. anche requisiti RG 8 e RG9) deve essere dotato di funzioni di stampa evolute, personalizzabili da parte degli utenti, con possibilità di definirle in forma parametrica (html, testo, pdf), prevedendone l’esportazione verso sistemi di office automation (elaboratore testi, foglio di calcolo, etc..).

7.3.2. Sottosistema COSAP

[COSAP1] Asserti fondamentali riguardo al sottosistema COSAP L'obiettivo di tale sottosistema del SIGE è quello di fornire gli elementi tecnico operativi per la gestione informatizzata delle funzioni inerenti le fasi di gestione del “canone di occupazione spazi su aree pubbliche” in riferimento al regolamento comunale e all’art. 63 del D.Lgs. n.446/1997 e successive modificazioni e integrazioni. In particolare, sono soggette a tale tipologia di canone le occupazioni permanenti o temporanee realizzate su strade, piazze ed aree appartenenti al demanio o patrimonio del Comune di Firenze, comprese le aree destinate a mercati anche attrezzati. Il canone si applica anche alle occupazioni realizzate su aree private soggette a servitù di pubblico passaggio. La definizione dei tipi di occupazione avviene sulla base di caratteristiche come la durata (occupazione temporanea o permanente), il carattere ambientale (suolo, sottosuolo, soprasuolo) e la Direzione competente a emanare l’atto autorizzatorio. Per quanto riguarda le Direzioni di competenza si ha la seguente suddivisione: Direzione Sviluppo Economico: • ambulanti a posto fisso • fiere e ambulanti a sorteggio • manifestazione, spettacoli, riprese televisive e raccolte di firme • mercati chiusi • giostre, mostre a terra • fioriere • tavolini bar temporanei • taxi merci • taxi a persone • tettoie relative ad attività commerciali • distributori di carburante • altro Direzione Mobilità: • passi carrai • ponteggi • alterazioni del suolo stradale • sottosuolo fisso • traslochi • altro Direzione Servizi Sportivi:


26

• riprese televisive inerenti manifestazioni sportive Il sottosistema COSAP dovrà essere realizzato sviluppando interamente le funzionalità previste dalla procedura attuale, con particolare riferimento agli aspetti di seguito elencati.

[COSAP2] Autorizzazioni COSAP2.1 Tale funzionalità consente di gestire gli aspetti legati alla definizione della tariffa COSAP dovuta in conseguenza dell’emanazione dell’atto autorizzatorio da parte della competente Direzione, per l’occupazione richiesta. Essa consente, pertanto, la gestione dei dati fondamentali della pratica, comprendenti: • dati relativi al richiedente; esso può essere sia una persona fisica, sia giuridica (per

quest’ultima sono registrati anche la denominazione, la sede sociale, il codice fiscale e/o la partita IVA, nonché ulteriori generalità relative al legale rappresentante, la sua sede sociale, etc…). Per tutti i richiedenti sono obbligatori gli indirizzi utili ai fini del recapito, in caso di residenza diversa da quella anagrafica o dalla sede;

• dati di individuazione dell’area soggetta all’occupazione; • durata e modalità d’uso dell’occupazione; • misura dell’occupazione (che dovrà essere espressa secondo unità di misura differenti in base

alla tipologia di occupazione stessa: ml, mq, mc); • dati relativi all’autorizzazione di riferimento (che verrà rilasciata dalla Direzione di

competenza). COSAP2.2 Relativamente ai subentri effettuati a seguito di DIA, inerenti alle attività commerciali su aree pubbliche (rif. LR 28/2005), dovranno essere previsti analoghi meccanismi di informatizzazione, necessari poi al rilascio del bollettino non tramite la Direzione che ne ha emanato l’atto autorizzatorio ma direttamente al richiedente.

[COSAP3] Determinazione del canone e sua riscossione (gestione della fase economica) Ai fini dell’applicazione e del calcolo del relativo canone, spazi e aree pubbliche sono classificati in categorie, così come specificato all’interno del Regolamento comunale vigente in materia. L’art. 21 di tale Regolamento specifica, infatti, che il territorio comunale è suddiviso in 4 categorie, eccetto per i passi carrai e gli spazi di sosta riservata agli alberghi (tutti di 1° categoria) e le aree occupate permanentemente con installazione di giostre, alle quali è stata attribuita la 4° categoria (si rimanda agli allegati di A e B di tale regolamento per ulteriori specifiche). COSAP3.1 Il sottosistema gestirà le attribuzioni di categoria, per come stabilite dal vigente Regolamento, e tutti gli aspetti funzionali legati all’aggiornamento di tali attribuzioni (che, per le nuove aree di circolazione, scaturiranno da comunicazioni preferibilmente provenienti da BDPI e, comunque, originate dal Servizio Toponomastica). Il Sistema dovrà considerare, a tale proposito, almeno i seguenti aspetti particolari: determinate vie, di particolare lunghezza, possono essere ripartite tra più categorie e come, per alcune strade indicate dal Piano Generale del Traffico Urbano, sia necessario prevedere delle maggiorazioni percentuali sul canone. COSAP3.2 Il sottosistema COSAP del SIGE consentirà di impostare le voci necessarie al calcolo e le relative regole di applicazione: le tipologie delle aree di occupazione, le categorie e i parametri per il calcolo delle riduzioni, etc… Le tariffe sono determinate: • per tipologia di occupazione, in ragione di metro quadrato, metro cubo o lineare; • per durata dell’occupazione; • e in ragione di coefficienti specifici, determinati ciascuno per tipologia di occupazione. Per la determinazione della misura dell’occupazione occorre tenere conto anche delle riduzioni stabilite dall’art. 20 del vigente Regolamento COSAP. COSAP3.3 Il SIGE dovrà comunque consentire (coerentemente a quanto richiesto negli appositi requisiti di natura generale e comune) una gestione parametrica e storicizzata sia degli elementi che concorrono al calcolo (categorie, tariffe, unità di misura, …) sia, per quanto possibile, delle stesse formule di calcolo. Poiché, inoltre, nel Regolamento citato sono previste agevolazioni e riduzioni del canone la cui applicazione è disposta dagli uffici comunali competenti, il Sistema dovrà gestire gli aspetti tariffari anche sulla base di parametri specifici definibili e configurabili in accordo a codifiche tabellari.


27

COSAP3.4 La gestione tariffaria deve coprire quella corrente, ma allo stesso tempo quella storica e consentire il ricalcolo di una situazione sulla base del sistema tariffario pregresso. COSAP3.5 Sarà possibile eseguire il calcolo del canone sia per singola occupazione, sia per più occupazioni aventi la stessa caratteristica (es. tutte le occupazioni permanenti). COSAP3.6 Il Sistema consente di effettuare il ricalcolo del canone sulla base di richieste da parte del contribuente, producendo i prospetti di determinazione con definizione sia agevolata sia non agevolata. COSAP3.7 La fase di calcolo alimenterà l’archivio dei canoni dovuti, presupposto necessario per la successiva fase di riscontro dei pagamenti. Da questo archivio, infatti, devono essere estratti i dati necessari per l’emissione dei bollettini o di altre comunicazioni contabili ai fini del pagamento del canone. Questo archivio è fonte di elenchi e statistiche varie (elenco pagamenti giornalieri, distinta ruoli, ecc.). COSAP3.8 La gestione del canone deve essere resa quanto più flessibile anche riguardo a: • concessioni cumulative (es: emanate dalla Direzione Mobilità per quello che concerne i

traslochi); • concessioni distinte soggette a riepilogo mensile ma relative alla stessa occupazione (es:

alterazioni del suolo stradale); • concessioni relative alle piazzole di sosta (es: per i taxi, annualmente deve essere gestito il

relativo censimento delle piazzole esistenti e, di conseguenza, la corretta ripartizione del canone tra i titolari delle relative licenze).

[COSAP4] Comunicazioni di pagamento (bollettini) COSAP4.1 Per quanto riguarda i pagamenti, fermo restando il richiamo alle funzionalità generali sopra descritte al subparagrafo 7.3.1, va comunque gestita la modalità attualmente prevalente per il COSAP, che è quella tramite bollettino, di seguito descritta. L’emissione dei bollettini di pagamento avviene sulla base della tipologia di occupazione: nel caso essa sia temporanea, il bollettino (o i bollettini in caso di rateizzazione) viene prodotto dopo aver effettuato il calcolo, contestualmente al prospetto di determinazione, ed inviato alla Direzione che ne rilascia l’atto autorizzatorio. Nel caso si tratti di occupazioni permanenti e per il commercio su aree pubbliche (cd. ambulantato) viene annualmente generato il prospetto massivo degli importi relativi alle concessioni attive e, nell’eventualità (per una data concessione), che l’importo superi una determinata soglia, si dà luogo alla possibilità di rateizzarlo attraverso la generazione di un bollettino per l’intero importo e di ulteriori tre bollettini con la rateizzazione relativa. COSAP4.2 Per l’invio dei bollettini ci si avvale del sistema di POSTEL, al quale vengono fornite le informazioni relative a: • bollettini da emettere (con l’importo che dovrà essere corrisposto); • lettera di accompagnamento da inviare al soggetto con il prospetto di determinazione

dell’importo; • elenco delle occupazioni di riferimento.

[COSAP5] Volturazioni e cessazioni Tale funzionalità deve gestire gli aspetti legati al canone in conseguenza di istanza di cessazione per cause varie (voltura per subentro, cambio intestazione, etc….). In base alla tipologia dell’occupazione trattata, temporanea o permanente, si dà luogo a un meccanismo di calcolo/ricalcolo del canone che comporta, in base all’art. 16 del Regolamento comunale, l’attribuzione del pagamento (di tutto o parte di esso) dell’importo al subentrante, oppure sia al subentrante che al cedente in riferimento al periodo di occupazione.

[COSAP6] Revoca, sospensione, decadenza della concessione o autorizzazione, rinuncia all’occupazione (art. 13, 14, 15 regolamento comunale) Il Sistema deve essere in grado, attraverso meccanismi di cooperazione applicativa o quanto meno attraverso meccanismi di notifica elettronica, di: • recepire le informazioni che possano comportare una riduzione o un rimborso (nei casi di

revoca o di sospensione della concessione ed, in alcuni casi, di rinuncia) al fine di comminare


28

penalità ed interessi e, eventualmente, obbligare al pagamento del canone (nei casi di rinuncia per i quali non sia stata ritirata l’autorizzazione, etc…)

• inviare comunicazioni alle Direzioni che hanno emanato l’atto di occupazione, a seguito ad es. di revoca del permesso di autorizzazione (per reiterata violazione alle prescrizioni, in caso di mancato pagamento del canone, in caso di uso improprio dell’occupazione, etc..);

• e di gestire le eventuali fasi sottese al verificarsi di tali eventi.

[COSAP7] Statistiche Il SIGE, relativamente al sottosistema COSAP, dovrà permettere l’elaborazione di statistiche definibili in forma parametrica dall’utente. Si richiedono, in particolare, report statistici relativi a: • oggetti censiti e loro caratteristiche dimensionali; • tipologia di occupazione; • importi dovutirichiesti e pagati; • individuazione zone di maggior evasione (con particolare riferimento agli spazi mercatali); • diffide (pagate, non pagate, notificate); • gettito complessivo e per tipologie e/o aree di occupazione in funzione di eventuali manovre

tariffarie; • altre caratteristiche. Ogni report potrà essere prodotto sia in modo aggregato, sulla base di uno o più criteri definibili dall’operatore, sia disaggregato, per analizzare in modo puntuale particolari situazioni.

[COSAP8] Interazione specifiche del COSAP con altre procedure comunali Il Sistema dovrà interagire anche con il sottosistema di gestione dei passi carrai in dotazione alla Direzione Mobilità attraverso il quale vengono rilasciate le autorizzazione relative; analogamente la stessa cosa avviene relativamente al sistema in dotazione alla Direzione Sviluppo Economico, per le altre pertinenze (spazi mercatali, spazi per attività commerciali all’aperto, spazi per pubblici spettacoli, etc..) e verso procedure presenti alla Direzione Urbanistica (ad es: relativamente alle pratiche di denuncia di un nuovo passo carraio).

7.3.3. Sottosistema CIMP

[CIMP1] Asserti fondamentali riguardo al sottosistema CIMP L'obiettivo del sottosistema è quello di fornire gli elementi tecnicooperativi per la gestione informatizzata delle funzioni inerenti il canone sulla pubblicità e i diritti derivanti, quali l'acquisizione delle denunce e dei versamenti per autoliquidazione dello stesso, l'accertamento e la liquidazione con il relativo addebito di sanzioni, penalità e mora. La normativa di riferimento per il CIMP per il Comune di Firenze è regolata dal “Piano generale degli impianti pubblicitari” (rif. Delibera n. 20/38 del 27/03/2001), dal D. Lgs. N. 446 art. 62 del 17/12/1997 e successive modifiche ed integrazioni e dalla legge 24/4/2002 n. 75 (relativamente all’esenzione delle insegne di esercizio). La struttura tariffaria, al fine di effettuare i presupposti di calcolo dell’entrata, è tabellata. Il modulo consente di gestire la fase successiva, inerente il riscontro dei pagamenti e l’accertamento delle posizioni. Anche questa struttura è tabellata, in quanto le sanzioni tributarie da applicare sul canone possono essere, all’interno di limiti definiti dalla legge, applicate secondo le modalità previste dal regolamento. Per ogni tipologia di mezzo pubblicitario la legge prevede una specifica individuazione della base imponibile (superficie del mezzo, numero autoveicoli, numero addetti, giorni di diffusione del messaggio, etc.) e della relativa tariffa; inoltre, la determinazione della superficie imponibile è soggetta ad una norma che ne specifica la modalità di arrotondamento. La norma prevede, inoltre, maggiorazioni e riduzioni del canone; le maggiorazioni sono cumulabili, le riduzioni no. Le attività di gestione del procedimento autorizzatorio (rilascio, volturazioni, variazioni, cancellazioni parziali o totali delle autorizzazioni stesse), vengono effettuate dalla Direzione Sviluppo Economico del Comune di Firenze utilizzando le funzionalità dell’iter dei procedimenti amministrativi.


29

Il sottosistema CIMP del SIGE dovrà essere realizzato sviluppando interamente le funzionalità previste dalla procedura attuale, con particolare riferimento ai requisiti che seguono.

[CIMP2] Autorizzazioni CIMP2.1 Devono essere gestiti gli aspetti legati all’iscrizione dell’utenza relativa al canone dovuto in conseguenza dell’emanazione dell’atto autorizzatorio di effettuazione della pubblicità, emanato dalla competente Direzione Sviluppo Economico (per gli aspetti riguardanti l’interazione funzionale col software SIGEPRO utilizzato dalla Direzione Sviluppo Economico, si rimanda al successivo requisito [CIMP6]). I dati fondamentali della pratica sono (vd. requisiti seguenti) il richiedente, il mezzo pubblicitario con le sue caratteristiche dimensionali, la tipologia del mezzo, la durata dell’applicazione del canone, i dati relativi all’autorizzazione di riferimento e – per gli impianti pubblicitari censiti nel SIT il relativo codice impianto. CIMP2.2 Oltre alla figura del richiedente, il CIMP definisce quella del concessionario e di altri interessati all’installazione del manufatto. Le rispettive anagrafiche devono contenere i dati fiscali (sesso, luogo, data di nascita, codice fiscale, etc..) e l’indirizzo di sede legale e di notifica. CIMP2.3 Devono essere gestiti i dati relativi all’oggetto dell’autorizzazione e del relativo canone. Vengono memorizzate le informazioni relative a: • numero del provvedimento di autorizzazione emanato dalla Direzione Sviluppo Economico; • tipologia del mezzo pubblicitario; • ubicazione; • dati dimensionali (lunghezza, larghezza, superficie, numero facce, numero esemplari, numero

automezzi); • luminosità del mezzo; • tipologia di installazione: suolo pubblico o privato; • informazioni su agevolazione della tariffa da applicare, in base alla tipologia di installazione

(se trattasi di installazione su suolo pubblico si applica la tariffa per intero, se su suolo privato si applica la tariffa agevolata);

• caratteristiche costruttive e descrizione libera del mezzo stesso; • altre caratteristiche. CIMP2.4 In relazione a ogni oggetto sarà possibile archiviare atti e documenti presentati anche in forma grafica (es. progetti), attraverso interazione col sistema SIGEDO (vd. requisito [RF8]). CIMP2.5 Altre funzioni consentiranno di gestire le informazioni necessarie per il calcolo del dovuto, quali: • valore imponibile del manufatto (superficie, lunghezza, numero facce, opaco/luminoso,

numero automezzi, ecc); • zona di pertinenza (inferiore, superiore e ulteriore); • durata dell’autorizzazione; • voci di calcolo correlate; • eventuali esenzioni o riduzioni.

[CIMP3] Determinazione del canone, sua riscossione ed emissione dei bollettini CIMP3.1 Questa funzionalità consente di effettuare il calcolo del CIMP. Oltre alle informazioni di cui al requisito precedente, il Sistema utilizzerà informazioni registrate in apposite tabelle, che saranno relative a zonizzazione, tariffe e regole di applicazione. CIMP3.2 Il calcolo deve poter essere eseguito anche attraverso l’elaborazione periodica anche massiva (attualmente con POSTEL) nel caso di mezzi pubblicitari permanenti. Questa funzione produce la stampa del bollettino di versamento e le altre stampe previste dalla legge o dal regolamento. CIMP3.3 L’emissione dei bollettini di pagamento segue una procedura di calcolo su base rateale: essa avviene emanando la rata per intero e/o prevedendo la rateizzazione dell’importo in 3 rate. CIMP3.4 Per l’invio dei bollettini ci si avvale attualmente del sistema di POSTEL al quale vengono fornite le informazioni relative a: • bollettini da emettere; • lettera di accompagnamento da inviare al soggetto; • elenchi dei mezzi pubblicitari di riferimento.


30

CIMP3.5 L’emissione rateale (sempre relativa all’installazione di mezzi di natura permanente) avviene per gli anni successivi a quello di emissione dell’atto autorizzatorio iniziale, del quale invece è previsto il pagamento concomitante. Il procedimento di rateizzazione avviene sulla base di specifici criteri relativi al canone da applicare: se il canone supera una certa soglia allora l’importo viene rateizzato analogamente a quanto avviene per il sottosistema COSAP. Il calcolo del canone dipende inoltre dalla data di concessione dell’autorizzazione.

[CIMP4] Verifica e gestione dei pagamenti CIMP4.1 Per il sottosistema CIMP, il sistema di verifica dei pagamenti deve tener conto della seguente suddivisione fra tre tipologie di pagamento: • pagamenti attesi in base al canone dovuto; • crediti (analoghi ai casi di ravvedimento operoso dell’ICI); • cassa (nella quale ricadono i pagamenti non riconducibili ad un canone specifico). CIMP4.2 L’applicazione di penalità per il CIMP è prevista nei casi di omesso, parziale o ritardato pagamento. Quella delle sanzioni nei casi di pubblicità abusiva od effettuata in difformità dal titolo autorizzatorio.

[CIMP5] Statistiche Il SIGE, relativamente a tale sottosistema, dovrà essere dotato di funzionalità di statistiche definibili in forma parametrica dall’utente: in pratica dovrà essere in grado di effettuare report statistici sulla base di: • mezzi pubblicitari censiti • importo del mezzo pubblicitario • superficie • tipologia di occupazione • altre caratteristiche

[CIMP6] Cooperazione applicativa tra SIGE modulo CIMP e SIGEPRO (calcolo automatico bollettino e creazione posizione contributiva) CIMP6.1 Come già affermato (vd. requisito CIMP2.1 e il precedente paragrafo 6.7), la Direzione Sviluppo Economico (DSE) ha competenza sui procedimenti autorizzativi relativi ai mezzi pubblicitari in genere. L’iter inizia, dunque, presso tale Direzione, al momento della richiesta da parte dell’azienda o del cittadino interessato, ma il relativo canone deve essere calcolato dal SIGE. Alla scadenza dei termini di legge i richiedenti si presentano a ritirare il provvedimento presso la DSE, eventualmente muniti della quietanza di pagamento del bollettino (a meno che non abbiano già pagato tramite POS oppure online, in tal caso l’autorizzazione gli viene inviata per posta all’indirizzo indicato). Si desidera raggiungere l’obiettivo di un’integrazione funzionale nell’adempimento dei compiti dei diversi uffici, migliorandone l’operatività e minimizzando, così, anche le operazioni dell’utente. L’applicazione in uso presso la DSE per la registrazione delle istanze e l’espletamento dell’iter amministrativo è il SIGEPRO, fornito dalla ditta In.I.T. s.r.l. di Perugia. Il presupposto per l’integrazione è che, dei dati elencati al precedente requisito [CIMP2], possano essere trasmessi dal SIGEPRO al SIGE tutti quelli già inseriti nel SIGEPRO stesso al momento della presentazione dell’istanza. Le altre informazioni necessarie per il calcolo saranno inserite nel SIGE, oppure ivi già presenti: con queste ultime si intendono quelle inerenti la situazione pregressa delle competenze degli utenti già registrati nel SIGE/CIMP, con particolare riferimento, chiaramente, alle installazioni pubblicitarie e alle insegne riconducibili a tali utenti. Pertanto, alle richieste di nuovi mezzi pubblicitari, il SIGE/CIMP metterà a disposizione del SIGEPRO servizi applicativi per la trasmissione dei seguenti dati: • Contribuenti, che possono essere di due tipi: Giuridici e Persone fisiche. In ogni caso, il campo

chiave fondamentale per entrambe le tipologie è il codice fiscale. • Elenco dei diversi mezzi pubblicitari richiesti. A supporto della compilazione di tali mezzi sono

utilizzate le seguenti informazioni che, dunque, devono essere presenti nella banca dati SIGE/CIMP:


31

o Tariffe o Tipi Documento o Tipi Pubblicità

CIMP6.2 Attraverso tale meccanismo, viene generata una richiesta di calcolo canone verso il sottosistema SIGE/CIMP. Un parametro del sottosistema consentirà di scegliere tra la modalità “calcolo immediato del canone e stampa bollettino” e quella di “accodamento richiesta”: in quest’ultima modalità, l’operazione di calcolo e stampa potrà essere lanciata in tempo differito. Si riassume di seguito, quindi, la sequenza delle operazioni: 1. L’operatore seleziona la richiesta voluta. 2. Viene presentato il contribuente inserito in SIGEPRO: il Sistema cercherà, tramite il codice

fiscale, se il contribuente risulta già essere presente. 3. Se trovato, viene visualizzato e confermato dall’operatore. Se alcuni dati non sono uguali (per

esempio, un diverso indirizzo) SIGE/CIMP li proporrà all'operatore che dovrà confermare quello ritenuto più corretto (naturalmente, se il dato più vecchio risultasse quello del database SIGE/CIMP, esso andrà storicizzato).

4. Se non trovato, viene creato recuperando i dati forniti mediante il SIGEPRO. 5. Quindi dovranno essere gestiti i mezzi pubblicitari, anch’essi indicati dal SIGEPRO. 6. L’operatore rivede i dati ricevuti dal SIGEPRO ed eventualmente opera delle correzioni. 7. Se in modalità immediata, l’operatore lancia il calcolo del canone e la stampa del bollettino. 8. Lo stato della richiesta segue poi le varie fasi dell’attività. Se è impostata la modalità differita, SIGE permetterà di verificare la fase in cui si trovano le diverse richieste tramite filtri costituiti da: contribuente, data richiesta, numero della richiesta e stato di calcolo e stampa del bollettino. CIMP6.3 Il SIGE permetterà, inoltre, la verifica da SIGEPRO della condizione di morosità o inadempienza del richiedente, utile nell’istruttoria delle autorizzazioni pubblicitarie, ciò mettendo a disposizione del SIGEPRO un apposito servizio di interrogazione di questo tipo di informazioni.

7.3.4. Sottosistema ICI

[ICI1] Asserti fondamentali riguardo al sottosistema ICI Questo sottosistema consente di gestire gli adempimenti connessi all’applicazione dell’Imposta comunale sugli Immobili, in riferimento a: • regolamento comunale • D. Lgs. N. 504/92 e successive modifiche ed integrazioni • Deliberazioni di Giunta Comunale per l’emissione delle aliquote di riferimento e le detrazioni

applicabili • art. 1, commi dal 161 al 171 della L. n. 296/2006 (legge Finanziaria 2007) in merito alla

tempistica per la presentazione di richiesta di rimborso nonché agli atti accertativi e a tutti gli altri aspetti applicativi dell’imposta, novellati o disciplinati exnovo da tale normativa. Si tratta, in sostanza, delle operazioni sottese alla fase di liquidazione e di accertamento dell’imposta, con l’emanazione del provvedimento e la stampa del bollettino postale per la comminazione delle sanzioni.

Il sottosistema SIGE/ICI deve prevedere, inoltre, l’evasione delle pratiche di rimborso, consentendo le verifiche del caso a fronte di un’istanza presentata. Consente, inoltre, di seguire la fase successiva all’emissione del provvedimento: e cioè la notifica dell’atto, la registrazione dei versamenti del contribuente, l’eventuale presentazione di ricorso (attraverso il sottosistema di gestione del contenzioso), e l’elaborazione, per le posizioni incoerenti, del ruolo coattivo. Più in dettaglio, dovranno essere quanto meno implementate nel SIGE le funzionalità presenti nell’attuale sistema, tenendo conto della massima rispondenza alle esigenze puntuali degli uffici.

[ICI2] Dichiarazioni/ comunicazioni e versamenti ICI2.1 Questa funzionalità comprende le operazioni legate alla gestione delle denunce e dei versamenti, codificati per anno di imposta, consentendo di ottenere, per ogni contribuente, sia l’elenco delle posizioni denunciate (come titolare oppure contitolare), sia la situazione per un determinato anno di imposta, derivante dalla stratificazione delle denunce nel tempo; ognuna di


32

tali operazioni sarà dotata delle relative funzioni di stampa evoluta, sia riepilogativa che di dettaglio sulla base delle impostazione scelte dall’utente (ed eventualmente sulla base della definizione di parametri specifici). ICI2.2 Tale modulo dovrà garantire funzionalità di importazione da fonti dati esterne, in formati diversi quali SOGEI, SIGAI, etc., oltre all’acquisizione dei versamenti in formato: • Equitalia Servizi a seguito di riscossione diretta a mezzo conto corrente; • bancoposta Impresa formato Poste Italiane a seguito di pagamenti tramite bollettino; • modello F24 a seguito di versamenti all’agenzia delle entrate; • ogni altro eventuale flusso informativo concernente i versamenti provenienti da altri canali già

attivati o di futura attivazione.

[ICI3] Gestione imposta (aliquote, detrazioni) ICI3.1 Questa funzione gestisce e i dati relativi alle tabelle delle aliquote, per il controllo di calcolo da effettuare sull’imposta dovuta, e i dati relativi alle detrazioni, sulla base delle tabelle fissate dai regolamenti di riferimento. ICI3.2 Essa deve, inoltre, consentire la possibilità di definire parametri di calcolo delle aree fabbricabili attraverso la destinazione e il relativo importo al mq. ICI3.3 Deve essere altresì previsto il conseguente recupero dati dal sistema SIT comunale con il quale – come detto al precedente paragrafo 6.6 il SIGE deve prevedere un legame di interazione. Ciò anche attraverso servizi WEB basati, ad esempio, su protocollo http/s e finalizzati al recupero di informazioni di carattere territoriale.

[ICI4] Comunicazioni di pagamento (bollettini) L’emissione dei bollettini di pagamento viene attualmente effettuata avvalendosi del sistema di POSTE (POSTEL) che ne cura anche l’invio verso i soggetti passivi dell’imposta accompagnandolo con un foglio informativo. L’elenco di tali soggetti (con i relativi dati anagrafici) verrà fornito dal sottosistema SIGE/ICI. I bollettini inviati sono quello per l’acconto, quello per il saldo più un terzo, che può essere utilizzato o per versare l’imposta in un'unica soluzione o in caso di errata compilazione.

[ICI5] Liquidazioni ICI5.1 Il calcolo deve poter essere effettuato con la conseguente emissione delle sanzioni sulla base della specifica di controlli incrociati su: • dichiarazioni rese; • versamenti effettuati dal contribuente; • dati di risultanza delle altre banche dati di riferimento (catasto, anagrafica SIPO, BDPI, SIT,

SIGEPRO, etc..). ICI5.2 L’attività di liquidazione prevede la verifica sul rispetto dei termini per compiere i versamenti. Per effettuare tale controllo devono essere utilizzati parametri configurabili relativi agli accertamenti, alle sanzioni (per quanto concerne le loro regole di applicazione), alle aliquote annuali di interesse e ai dati di riferimento delle date di scadenza. ICI5.3 La procedura di liquidazione è organizzata in due distinte fasi: precalcolo (istruttoria iniziale) ed elaborazione definitiva (emissione provvedimenti). La fase di ‘precalcolo importi’ esegue, in base ai parametri sopra descritti, un ricalcolo dell’imposta dovuta per ciascun immobile dichiarato ed effettua il calcolo dell’imposta dovuta annualmente e la suddivide sulle due rate. Si tratta di una simulazione che ha l’obiettivo di indicare le posizioni incoerenti, senza arrivare però all’emissione del provvedimento. Una volta effettuata tale elaborazione, tutti i contribuenti (titolari e contitolari) che hanno versato meno di ciò che dovevano versare, oppure che hanno versato la prima o la seconda rata in ritardo, vengono segnalati opportunamente. Prima di lanciare questa simulazione, la Procedura deve consentire la selezione in cui indicare gli anni per cui effettuare il controllo e la data di liquidazione. ICI5.4 La data di liquidazione viene utilizzata dalla Procedura per il calcolo degli interessi di mora. ICI5.5 La Procedura esegue, inoltre, una verifica su alcune anomalie che potrebbero in qualche caso inficiare il risultato del calcolo dell’imposta dovuta o della sovrattassa e della mora da applicare. Tali anomalie si possono suddividere in tre tipologie:


33

a. anomalie derivanti da errori formali presenti sulle dichiarazioni non evidenziabili se non dopo analisi dei dati non presenti sulla dichiarazione;

b. anomalie relative ai versamenti; c. situazioni particolari dei contribuenti e presentazione di variazione per l’anno di denuncia in

esame. ICI5.6 Infine il SIGE/ICI prevedrà la fase di “elaborazione definitiva”, mirata alla disamina dei provvedimenti di liquidazione ed organizzata nelle seguenti operazioni: • selezione del/i contribuente/i nei cui confronti emettere avviso di liquidazione, richiedendo o

meno l’applicazione di sanzioni e di interessi moratori; • esecuzione del ricalcolo dell’imposta, della sanzione e degli interessi moratori in base alle

scelte effettuate al punto precedente, ottenendo un nuovo prospetto di liquidazione; la funzione di calcolo elaborerà anche una serie di messaggi che descrivono le motivazioni legate all’emissione del provvedimento;

• manutenzione importi di imposta, sanzione e interessi moratori calcolati dal programma e personalizzazione dei messaggi relativi ai rilievi prodotti in automatico dal programma;

• emissione, per i contribuenti evidenziati, delle comunicazioni contenenti anche il prospetto di liquidazione.

[ICI6] Controlli incrociati Attraverso l’interoperabilità con gli altri sistemi informatici dovrà essere possibile effettuare: • Incrocio fra nuclei familiari e posizioni contributive TIA per identificare eventuali nuclei

familiari evasori della tassa rifiuti; • Verifica della corretta attribuzione della riduzione della tassa rifiuti per nuclei familiari

monocomponenti; • Verifica della corretta attribuzione della detrazione ICI prevista per la "prima casa"; • Incroci fra tributi aventi come cardine l’immobile o il contribuente.

[ICI7] Rimborsi La funzione ha l’obiettivo di consentire l’esecuzione dei controlli formali connessi a una richiesta di rimborso, il calcolo degli importi da rimborsare (maggiore imposta versata e interessi) e l’emanazione del provvedimento di rimborso. Per raggiungere tale obiettivo, il sottosistema SIGE/ICI effettua un controllo formale della corrispondenza tra i dati denunciati dal contribuente e i versamenti effettuati. Per effettuare i controlli si utilizzano i parametri relativi agli “Accertamenti/Sanzioni” (per quanto attiene alle regole di applicazione degli interessi) e “Riferimenti Annuali” (per quanto attiene alle regole per il calcolo dell’imposta). Per istruire una richiesta di rimborso è, quindi, assolutamente necessario inserire tutti gli eventi che riguardano il contribuente dai quali si genera un credito di imposta (eventuali dichiarazioni, denunce di variazione e versamenti). Il diritto al rimborso può derivare dal fatto che si è versato un importo superiore all’imposta denunciata oppure dal fatto che si è attribuita una rendita definitiva inferiore a quella denunciata o, ancora, a seguito dell’accertamento di una nuova situazione che comporti il versamento di una imposta inferiore a quella effettivamente versata. In questo caso le elaborazioni vengono effettuate da funzionalità del sottomodulo “Accertamento” (vd. [ICI8]). Questa funzionalità dovrà consentire l’applicazione di quanto previsto al punto [RF9] riguardo alle compensazioni.

[ICI8] Verifica dei pagamenti e accertamenti (penalità, sanzioni, ruolo coattivo) ICI8.1 Il modulo consente di eseguire le operazioni sottese ai procedimenti di liquidazione in base alla rendita definitiva, di accertamento e di comminazione della sanzione pecuniaria. Attraverso questo modulo vengono eseguite tutte quelle operazioni che hanno come presupposto un’istruttoria aggiuntiva rispetto a quanto dichiarato (e di conseguenza versato) dal contribuente. Le causali di accertamento devono poter essere liberamente codificate dall’utente attraverso la tabella delle variazioni e sono distinguibili in quattro famiglie: • comminazione di sanzione per errori formali; • applicazione di rendita catastale definitiva; • codifica di inesatta denuncia;


34

• codifica di omessa/tardiva denuncia. ICI8.2 In sede di liquidazione della maggiore imposta, relativa all’emissione di un provvedimento di accertamento, la procedura considera l’esistenza di eventuali procedimenti di ‘Liquidazione’ o ‘Rimborso’ a carico del contribuente per lo stesso anno di imposta. Se tali procedimenti sono già stati definiti (e quindi è già stato emesso un provvedimento definitivo), l’importo liquidato (o rimborsato) viene detratto dalla o sommato alla maggiore imposta dovuta. In aggiunta vengono indicati nella messaggistica specifica tutti gli estremi del provvedimento già emesso (cioè numero e data del provvedimento e imposta liquidata o rimborsata). Nel caso in cui i procedimenti non fossero ancora stati definiti – considerato quindi che non sia stato emesso un provvedimento definitivo viene data possibilità sia di confermare il provvedimento in itinere (attraverso l’emissione di un avviso di liquidazione o di un provvedimento di rimborso), sia di bloccarne l’emissione. ICI8.3 In sede di liquidazione della maggiore imposta relativa all’emissione di un provvedimento di accertamento, la Procedura tiene conto dell’esistenza di eventuali procedimenti di liquidazione per ‘Attribuzione di rendita definitiva’. A differenza di quanto accade in caso di concorrenza di provvedimenti di Liquidazione/Rimborso ed Accertamento, è però necessario tenere distinti i provvedimenti di Liquidazione per attribuzione di rendita definitiva e di Accertamento; inoltre, se per la stessa posizione vi fosse concorrenza di Liquidazione/Rimborso, Liquidazione per attribuzione di rendita definitiva ed Accertamento, sarà possibile o emettere distintamente i tre provvedimenti oppure emettere due provvedimenti distinti, uno dei quali cumulerà i provvedimenti di Liquidazione/Rimborso e Liquidazione per attribuzione di rendita definitiva e l’altro esclusivamente i provvedimenti per l’Accertamento. ICI8.4 Per effettuare il calcolo del dovuto a seguito di accertamento vengono utilizzati i parametri immessi in tabelle relative ad “Accertamenti / Sanzioni” (per quanto attiene alle regole di applicazione delle sanzioni), “Aliquote annuali di interesse” (per quanto attiene agli interessi) e “Riferimenti Annuali” (per quanto attiene alle date di scadenza e alle regole per il calcolo dell’imposta). ICI8.5 Il sottosistema deve poi prevedere un’iterazione automatica per i periodi di imposta successivi dell’accertamento. A tal fine vengono proposte una serie di stampe/report che consentono di individuare le variazioni nel frattempo intercorse rispetto alle posizioni oggetto di accertamento. Ciò naturalmente sia in riferimento agli immobili che ai contribuenti.

[ICI9] Ruolo coattivo L’emissione del ruolo coattivo avviene a seguito di un “atto accertativo”; tale atto può scaturire a seguito di: • avviso di accertamento; • avviso di liquidazione (a seguito del ricalcolo dell’imposta dovuta); • atto di contestazione (per omessa o tardiva comunicazione di variazione). Il flusso prodotto da tale analisi viene prodotto sia in forma cartacea che elettronica in formato Equitalia Servizi alla stessa stregua di quanto avviene per gli altri sottosistemi (CIMP, COSAP).

[ICI10] Stampe dichiarazioni Il sottosistema è dotato di funzionalità per la stampa delle dichiarazioni dei contribuenti.

7.3.5. Sottosistema “Gestione verifiche di classamento” (GESDIA)

[GESDIA1] Asserti fondamentali riguardo al sottosistema GESDIA Tale sottosistema può essere considerato un’appendice molto rilevante del sottosistema ICI, in quanto il riferimento principale è basato sui dati della banca dati gestita da quest’ultimo. Attraverso il modulo GESDIA gli uffici svolgono attività di verifica, indagine e controllo in merito alla legge finanziaria del 2005, a seguito della quale i Comuni possono richiedere ai possessori di immobili di proprietà privata non iscritti in catasto, o di immobili per i quali le situazioni di fatto non siano più corrispondenti con i classamenti catastali a seguito di variazioni edilizie, la presentazione dell’atto di iscrizione o di aggiornamento catastale. Qualora i soggetti interessati non eseguano quanto richiesto entro 90 giorni dall’avviso del Comune, l’Agenzia del Territorio (Catasto) procederà d’ufficio all’iscrizione all'aggiornamento, addebitando le spese della


35

procedura ai titolari degli immobili. Il SIGE deve integrare tutte le funzionalità attualmente presenti in tale sistema.

[GESDIA2] Specifica relativa all’attività di verifica L’attività di verifica effettuata tramite tale sottosistema consiste nell’incrociare le risultanze di più banche dati: banca dati urbanistica delle pratiche edilizie (comprese le concessioni), DIA e banca dati catastale. Attraverso tali risultanze di carattere puntuale e a ulteriori indagini di contesto del classamento catastale di un cespite, ad es. mediante il riferimento alla particella e alla rendita catastale dello stesso nei confronti di cespiti adiacenti, si richiede che vengano generati dei flussi elettronici, da inviare all’Ente incaricato delle modifiche catastali (Agenzia del territorio o Comune), contenenti le segnalazioni desunte dai mancati aggiornamenti del classamento catastale. Ovviamente le analisi sopra descritte non producono con certezza l’individuazione di una situazione di evasione o elusione, ma sono senza dubbio uno degli strumenti di supporto alle decisioni e di lotta all’evasione fiscale.

7.3.6. Sottosistema Gestione Contenzioso

[CONT1] Asserti fondamentali riguardo al sottosistema di gestione del contenzioso CONT1.1 La gestione del contenzioso relativo ai tributi comunali consiste nella gestione amministrativa dei procedimenti giudiziali. Si richiede, in proposito, che nel sottosistema di gestione del contenzioso della Procedura (denominato nel seguito SIGE/CONT per brevità), siano presenti tutte le funzionalità descritte nei requisiti seguenti e, attualmente, svolte mediante il ricorso a più applicativi. CONT1.2 Il SIGE/CONT dovrà essere interamente integrato con i sottosistemi relativi ai tributi e canoni del DRFSE, descritti nei precedenti paragrafi, in modo da rendere il più efficace possibile l’iter amministrativo legato a tale materia, dall’apertura del ricorso alla sua soluzione in riferimento al decreto legislativo 546/1992 e successive modifiche e integrazioni. CONT1.3 Il sottosistema sarà dotato di funzionalità trasversali che, a prescindere dal particolare procedimento in atto (fallimenti, ricorsi all’AGO o alle Commissioni Tributarie), devono consentire di gestire in modo chiaro ed immediato le scadenze previste dall’iter, calcolando di conseguenza le tempistiche reali relative alla presentazione dei ricorsi e alle vicende processuali connesse. Tali funzionalità trasversali sono le seguenti: • Gestione dei ricorsi / fallimenti; • Gestione delle udienze e delle decisioni collegate ai ricorsi / fallimenti; • Gestione passaggio dei ricorsi / fallimenti alle varie P.O.; • Collegamento con il software di gestione della banca dati relativa alle sentenze emesse

in seguito a precedenti ricorsi, da utilizzare come riferimento informativo per fattispecie analoghe in casi successivi.

[CONT2] Gestione dei ricorsi CONT2.1 La gestione dei ricorsi consente di registrare le informazioni inerenti i ricorsi nei confronti dell’amministrazione comunale e quelli dell’amministrazione nei confronti dei contribuenti. CONT2.2 Collegata a questa gestione c’è quella delle anagrafiche dei contribuenti, i legami con le udienze e con le decisioni/sentenze che le riguardano. L’anagrafica è, chiaramente, quella centralizzata del SIGE: a tal proposito, si ribadisce l’estrema importanza di quanto esposto al precedente paragrafo 7.3.1, requisito [RF1] “Anagrafe dei contribuenti”, in quanto la memoria storica è essenziale soprattutto per il Contenzioso, stante la durata, talvolta indefinita, dei procedimenti prima di giungere a chiusura. CONT2.3 Tutti i passaggi di procedura sono registrati e fanno parte di un vero e proprio iter del ricorso. L’iter è controllato dal sistema e dovrà essere reso parametrico, visti i continui cambiamenti normativi e le eccezioni che si verificano nei passaggi di stato: in fase di realizzazione del software il Fornitore prenderà visione del diagramma degli stati attraverso i quali è rappresentato l’iter amministrativo e giuridico del ricorso, allo scopo di integrarlo in SIGE/CONT.


36

CONT2.4 La consegna del ricorso/appello può avvenire tramite: • consegna diretta agli uffici • invio postale • notifica da parte di un ufficiale giudiziario. CONT2.5 I vari passaggi di stato del ricorso fanno sempre riferimento alle informazioni di seguito riportate: • dati anagrafici del ricorrente; • anno e numero di protocollo del ricorso; • numero di ricevuta restituita al ricorrente al momento della presentazione del

ricorso/appello presso gli uffici. Tale numero è generato solo nel caso in cui l’atto sia recapitato tramite consegna diretta agli sportelli degli uffici. L’atto viene preso in consegna, ne viene generato un numero di ricevuta e un numero di protocollo (vd. requisito RF8): una copia è rilasciata al ricorrente con il riferimento al numero di ricevuta assegnato;

• data presentazione del ricorso; • data scadenza della presentazione delle deduzioni; • protocollo di costituzione presso la Commissione Tributaria Provinciale; • data di trattazione del ricorso in udienza provinciale; • protocollo di costituzione presso la Commissione Tributaria Regionale; • data di trattazione del ricorso in udienza regionale; • tipologia e numero dell’atto impugnato; • data di consolidamento del ricorso; • stato che identifica la fase del ricorso; • data di restituzione dalla P.O.; • collegamento del ricorso all’atto impugnato (a cura della P.O. di riferimento); • varie note collegate al ricorso; • altri ricorrenti collegati, divisi per qualifica (es. legali rappresentanti di società, obbligati

in solido, eredi, ecc.). Le informazioni sono legate ai vari stati del ricorso e talvolta sono calcolate automaticamente, in base a criteri stabiliti da parametri impostati dall’ufficio di riferimento.

[CONT3] Gestione delle udienze e delle decisioni collegate ai ricorsi CONT3.1 Ad un ricorso sono collegate più udienze riferite al grado di giudizio: Commissione Tributaria Provinciale, Commissione Tributaria Regionale, Cassazione. Per ciascun grado le udienze possono essere ripetute più volte. Ad ogni udienza è legata una decisione. Le informazioni gestite, relative alle udienze, sono le seguenti: • data udienza; • se si tratta di un udienza pubblica o meno; • ricorsi collegati all’udienza; • grado dell’udienza (provinciale, regionale, cassazione); • se si tratta di udienza di sospensiva oppure no; • la sezione; • l’ora dell’udienza; • la data di scadenza di presentazione delle memorie; • la data di scadenza di presentazione delle memorie brevi; • la richiesta di pubblica udienza da parte del Comune; • la data di notifica della richiesta pubblica udienza da parte del Comune; • la richiesta di pubblica udienza da parte del ricorrente; • la data di notifica della richiesta di pubblica udienza da parte del ricorrente; • annotazioni sull’udienza. Alcune informazioni sono legate ai vari stati dell’udienza e talvolta sono calcolate automaticamente in base a criteri stabiliti da parametri impostati dall’ufficio di riferimento. CONT3.2 Le informazioni relative alle decisioni sono le seguenti: • numero della decisione; • data della decisione;


37

• l’anno e il numero di protocollo del dispositivo di sentenza; • RGR (Registro Generale Ricorsi) – RGA (Registro Generale Appelli); • data deposito della decisione; • se si tratta di una data deposito provvisoria o definitiva; • se si tratta di una revisione di sentenza o no; • data notifica della decisione al Comune; • data notifica della decisione al ricorrente; • esito della decisione; • genere della decisione (del quale si ha attualmente un’esportazione in Access); • tipo della decisione; • l’ammontare delle spese di giudizio irrogate ad una parte (al ricorrente o al Comune); • la motivazione della decisione; • il collegamento all’udienza; • la motivazione della revisione; • la data di scadenza della decisione; • i ricorsi collegati alla decisione; • iscrizioni a ruolo (emesse a seguito delle spese di giudizio irrogate a favore del

Comune); • determinazione dirigenziale di liquidazione delle spese irrogate a sfavore del Comune. Alcune informazioni sono legate ai vari stati dell’udienza e talvolta sono calcolate automaticamente in base a criteri stabiliti da parametri impostati dall’ufficio di riferimento.

[CONT4] Gestione dei passaggi dei ricorsi alle varie unità operative CONT4.1 Durante i vari passaggi dell’iter è previsto il collegamento alle pratiche dei tributi o canoni interessati al ricorso. Tale legame è diretto con la TARSU, che il DRFSE gestisce a stralcio, mentre è indiretto con il sistema per la gestione della TIA (adesso di competenza della consorziata Quadrifoglio S.p.A.). Relativamente a tale ultimo sistema, il SIGE deve garantire la registrazione dei dati estrapolati dal ricorso proposto dal contribuente. CONT4.2 Per gli altri tributi/canoni la gestione attualmente avviene attraverso flussi cartacei. Durante l’iter è previsto un passaggio per l’assegnazione del lavoro alla P.O. competente ed uno per il ritorno della pratica istruita alla P.O. Contenzioso. Si richiede, pertanto, nel SIGE/CONT la presenza di funzioni di integrazione con gli altri sottosistemi, attraverso i quali le altre P.O. possano recepire (non più tramite lo scambio cartaceo) le informazioni relative ai ricorsi, ai fallimenti (con atti annessi) e il relativo stato di avanzamento legato all’iter. CONT4.3 Le informazioni relative al passaggio alle varie Unità operative di competenza sono le seguenti: • il collegamento del ricorso all’atto impugnato; • la P.O. di competenza; • il grado di giudizio; • la data di trasmissione alle P.O. competenti; • la data di scadenza per la restituzione alla P.O. Contenzioso della pratica istruita; • la data dell’effettiva restituzione alla P.O. Contenzioso della pratica istruita.

[CONT5] Collegamento con banca dati delle sentenze emesse in seguito a precedenti ricorsi Vista la necessità di avere un supporto informativo per la stesura delle memorie difensive, i dati relativi alle decisioni emesse vengono attualmente archiviate su un database Access, gestito tramite un applicativo interno che è pienamente adeguato alle aspettative funzionali ed operative della PO Contenzioso. Nel sottosistema SIGE/CONT devono essere pertanto riportate analoghe funzionalità o, quanto meno, dovrà essere prevista la funzione di esportazione dei dati di interesse, analoga a quella prevista dal sistema attuale.

[CONT6] Fallimenti CONT6.1 Per quanto riguarda lo specifico della gestione fallimentare, le informazioni da registrare nel sottosistema devono essere:


38

• i dati anagrafici del soggetto, Codice Fiscale / Partita IVA; • i dati relativi all’atto e al tributo/canone di riferimento; • dati relativi a eventuali comunicazioni con altri uffici; • i termini di restituzione della pratica da parte degli uffici; • dati relativi al fallimento del soggetto: data del fallimento, curatore fallimentare,

numero e anno di riferimento del fallimento. Tali informazioni pervengono attraverso il curatore fallimentare o dal Tribunale tramite l’estratto della sentenza;

• dati relativi all’udienza; • informazioni relative allo stato di gestione dell’iter del procedimento con eventuale

indicazione da parte di ciascuna P.O. di riferimento dei crediti vantati e successivo riscontro della loro ammissione o meno al passivo fallimentare da parte del curatore;

• dati relativi al giudice; • dati relativi ai curatori. CONT6.2 SIGE/CONT dovrà prevedere l’aggancio ai servizi di cooperazione applicativa forniti dalla Regione Toscana per ottenere informazioni dal sistema camerale: visure di bilanci, protesti e altri tipi di atti o informazioni presenti negli archivi camerali. L’obiettivo sarà quello di estrarre e riportare nel SIGE informazioni utili anche alla definizione della posizione del contenzioso generale nei riguardi del soggetto. Attualmente ciò avviene attraverso l’utilizzo del sistema Telemaco che consente l’effettuazione di visure camerali puntuali e fuorilinea rispetto al software di gestione del contenzioso. CONT6.3 Dopo aver ricevuta notizia/comunicazione del fallimento di un soggetto, attraverso i canali sopra detti, la P.O. Contenzioso fa richiesta formale agli altri uffici richiedendo, in riferimento al soggetto, ulteriori casi di credito pendente (a seguito ad esempio di diffide, avvisi di accertamento, etc..). Tale procedimento di riconciliazione delle informazioni genera la cosiddetta “creazione di un elenco di crediti”, che poi potrà essere utilizzato in sede di insinuazione presso il Tribunale. Le ultime fasi sopra descritte sono attualmente gestite attraverso scambio di comunicazioni in forma sia cartacea sia elettronica (scambio di report via mail) ma è richiesta nel SIGE la gestione informatizzata del processo, anche attraverso la definizione di nuove metodologie operative degli uffici.

[CONT7] Ricorso di competenza dell’autorità giudiziaria ordinaria CONT7.1 L’autorità giudiziaria ordinaria (d’ora in avanti menzionata per brevità AGO) è costituita da Tribunale, Giudice di Pace, TAR o Cassazione, aditi in base al riferimento legislativo. Il procedimento innescato nel caso di ricorso di competenza dell’AGO prevede la memorizzazione nel sistema delle informazioni relative a: • autorità giudiziaria di competenza; • soggetti (più soggetti in caso di costituzione in giudizio di più ricorrenti); • informazioni relative all’atto e al tributo/canone oggetto del ricorso; • scadenziario (data dalla quale decorrono i termini per attivare e/o subire il giudizio di

appello); • data di arrivo del ricorso; • data e numero di protocollazione; • data di invio alla P.O. di riferimento; • data di restituzione dalla P.O. di assegnazione; • informazioni sul ricorso (se evaso, se definitivo); • sentenza con l’esito del ricorso; • data di notifica, di deposito, di invio a P.O. se esito sfavorevole, di consolidamento; • determinazione dirigenziale di autorizzazione al giudizio; • esito Cassazione; • altri dati di comunicazioni da e verso la Direzione Avvocatura del Comune e P.O. di

riferimento. CONT7.2 Recenti modifiche di legge introducono altresì il grado di giudizio di appello: si richiede che il sottosistema Contenzioso del SIGE tenga conto di tali modifiche. CONT7.3 L’iter del procedimento, nei casi previsti da tale tipologia di ricorsi, viene seguito dalla Direzione Avvocatura, attraverso proprie procedure informatiche mentre, da


39

parte DRFSE, la lavorazione del procedimento prevede l’istruttoria della pratica. Tale istruttoria può anche comportare un intervento in autotutela (e, in tal caso, può essere previsto l’avvio di un nuovo procedimento, eventualmente di annullamento): gli uffici producono pertanto un “rapporto istruttorio” che viene restituito alla P.O. Contenzioso.

[CONT8] Tipologie di dati e stampe per fallimenti e ricorsi all’AGO CONT8.1 Il SIGE/CONT deve gestire dati relativi ai seguenti procedimenti: • fallimenti: o curatori; o giudici; o stati del fallimento; o varie procedure concorsuali.

• ricorsi: o autorità giudiziaria adita; o esiti (descrizioni esiti di giudizio).

Per entrambe le tipologie di dati è gestita l’anagrafica del ricorrente/i o del soggetto. CONT8.2 Sono previste inoltre funzionalità di stampa e reportistica di elenchi sia di prova che effettivi: • per i fallimenti: stampa elenchi di prova e definitivi. La stampa elenco di prova individua i

fallimenti (categorizzati in elenchi) che si trovano in un particolare stato (“nuovo”), mentre la stampa effettiva visualizza le medesime informazioni causando però il passaggio dei fallimenti considerati in uno stato denominato “invio elenco uffici”.

• per i ricorsi all’AGO le stampe prodotte sono relative a: o scadenza contenzioso; o scadenza relativa a direzione Avvocatura; o elenco ricorsi consolidati (per i quali è definitiva la sentenza).

CONT8.3 Ogni informazione di interesse per gli altri uffici della DRFSE dovrebbe essere resa disponibile agli altri moduli del SIGE attraverso meccanismi di segnalazione interni alla Procedura stessa.

[CONT9] Ricorsi alle Commissioni Tributarie SIGE/CONT dovrà, inoltre, gestire l’iter dei ricorsi, relativi a tributi e canoni, proposti innanzi alle Commissioni Tributarie (Provinciale e Regionale) e alla Cassazione, permettendo di gestire i dati inerenti: redazione delle deduzioni difensive, costituzione in giudizio, deposito di documenti e memorie illustrative, trattazione delle controversie in pubblica udienza, gestione conciliazioni e notificazione degli atti del processo tributario.

8. Servizi professionali correlati al software applicativo

Come già specificato al punto 2) del paragrafo 3.2, la fornitura dovrà comprendere una serie di Servizi Professionali Correlati (SPC), secondo le caratteristiche e le modalità descritte nel seguito.

8.1 P redisposizione definitiva del PI

La prima attività susseguente all’aggiudicazione sarà la stesura del Piano di implementazione integrato (in sintesi PI) dell’Applicazione, svolta congiuntamente dai referenti delle Parti. Esso sarà formulato sulla base della proposta di Piano presentata dal Fornitore nella sua offerta tecnica – oggetto di valutazione – e verrà aggiornato apportandovi tutte le modifiche occorrenti per una migliore e più completa aderenza alle esigenze dell’Ente.

Si ribadisce, pertanto, che la proposta di Piano presentata dal Fornitore in sede di offerta tecnica non è vincolante per l'Ente, il quale si riserva la facoltà di indicare le opportune modifiche ai fini della stesura del PI definitivo. Quest’ultimo sarà, dunque, definito


40

congiuntamente dall’Ente e dal Fornitore, entro un termine massimo fissato a due mesi dalla data di affidamento della fornitura.

Il PI sarà descritto anche tramite diagrammi (p.es. PERT e di Gantt), sarà articolato in fasi, tra loro eventualmente sovrapponibili, e dovrà includere un P iano di rilascio degli output tecnologici. Per ciascuna fase dovranno essere indicati: • la data di inizio e di fine della fase, relativi alla data di aggiudicazione; • le attività da svolgere e la relativa tempistica, ivi incluse quelle relative ai “test di

accettazione” di cui al succ.vo paragrafo 12.1;

• i prodotti specifici che verranno rilasciati; • i servizi specifici che saranno attivati e/o conclusi; • le risorse che saranno impegnate per ciascuna attività dal Fornitore e dall'Ente; • eventuali rischi e azioni correttive che si prevede di intraprendere.

Il PI dovrà prevedere specifici SAL, in corrispondenza dei quali saranno effettuati gli opportuni “test di accettazioni” parziali e le opportune verifiche (vd. par. 12.1) e saranno rilasciati i relativi verbali.

La data di inizio del PI non potrà oltrepassare i dieci giorni dall’aggiudicazione.

Il periodo di garanzia (vd. par. 8.9) decorrerà dalla data di conclusione del collaudo, di cui al succ.vo par. 12.2.

Il Piano di rilascio contenuto nel PI dovrà indicare le scadenze relative agli specifici prodotti/output:

• Sottosistema ICI

• Sottosistema Gestione verifiche di classamento (GESDIA)

• Sottosistema COSAP

• Sottosistema CIMP

• Sottosistema Gestione del contenzioso

• Collegamento con gli altri sistemi informatici

Il rilascio di ogni modulo comporterà l’attivazione dei conseguenti servizi:

• Importazione dei dati pregressi • Personalizzazione applicativa • Formazione degli utenti • Assistenza all'avviamento del sottosistema • Servizio di assistenza funzionale agli utenti

• Manutenzione

Ogni rilascio dovrà comprendere, quali specifici prodotti di fase, l’installazione dei prodotti software e la verifica mediante una dimostrazione pratica del corretto funzionamento del software su dati di prova desunti da dati reali forniti dal Comune.

Dopo il superamento dei test di accettazione provvisoria (inclusi gli interventi di personalizzazione eventualmente previsti per specifiche funzionalità) e previa formazione degli utenti, i moduli saranno rilasciati in esercizio a cura della Ditta aggiudicataria, inclusa l’importazione definitiva dei relativi dati.

Il PI dovrà assumere la data del 31 dicembre 2008 come termine di riferimento finale della pianificazione del progetto, salvo diversi e successivi accordi con l’Ente.

Lo sviluppo del progetto sarà monitorato con incontri di pianificazione e monitoraggio, da svolgersi con periodicità mensile fra i referenti delle Parti, salvo altrimenti concordato.


41

In occasione di tali incontri la Ditta aggiudicataria rilascerà documentazione esplicativa che verrà utilizzata come base per il riscontro delle attività svolte e per la pianificazione delle attività da svolgere.

Tali documenti saranno rilasciati, nelle versioni previste dal PI, nelle diverse fasi implementative del progetto stesso e saranno sottoposti ai referenti dell’Ente per l’approvazione.

Salvo diversamente concordato fra le due parti, il Comune si impegna a comunicare la propria valutazione sui documenti, con eventuali richieste di modifiche/integrazioni e osservazioni, entro 15 giorni solari dalla loro consegna e il Fornitore si impegna a recepire le richieste dell’Ente entro i 15 giorni solari successivi alla sua comunicazione. Il documento finale sarà approvato, se conforme, dai referenti dell’Ente.

Per ritardo nel rispetto dei termini di recepimento delle osservazioni/modifiche del Comune e per ritardi nell'esecuzione delle attività previste dal PI si applicano le penali di cui al succ.vo cap. 14.

Nel caso in cui l’Amministrazione accetti un adempimento parziale, la penale di cui al punto precedente è commisurata al prezzo relativo ai prodotti non consegnati o non messi in funzione.

La durata del contratto è stabilita dalla sua sottoscrizione fino al termine del periodo di garanzia, successivo alla conclusione delle attività previste nel PI.

Successivamente potrà essere sottoscritto il contratto di assistenza e manutenzione (secondo quanto previsto al succ.vo cap. 9). A tale scopo la Ditta si impegna a mantenere inalterati i costi, comunicati nell'offerta economica, per tali attività.

Le parti potranno concordare in corso d’opera variazioni alla pianificazione iniziale del progetto ed eventualmente riallocare diversamente le risorse messe a disposizione dalla Ditta aggiudicataria con l’offerta in oggetto, pur nel rispetto dell’importo complessivo di aggiudicazione, qualora ciò si renda necessario in conseguenza di variazioni di progetto.

Eventuali variazioni di rilievo concordate rispetto all’accordo originario saranno formalizzate apportando al contratto firmato le conseguenti necessarie modifiche o integrazioni.

8.2 Importazione dei dati pregressi

La fornitura include lo sviluppo dei programmi per la conversione e l’importazione nel database dell’applicazione dei dati pregressi disponibili sui database e sugli archivi attualmente utilizzati dal Comune.

Il piano di importazione dei dati pregressi sarà contenuto nel PI e mirerà, tra l'altro, a minimizzare il tempo necessario alla migrazione dai sistemi attuali al SIGE. Il piano prevedrà il recupero di tutti i dati la cui necessità storica sarà definita dalla DRFSE e la cui disponibilità effettiva sarà garantita dalla DSI. L’esecuzione di tale piano sarà coordinata dai referenti dell'Ente.

Il Fornitore provvederà alla realizzazione delle funzioni di importazione dei dati, dagli archivi di appoggio alla base dati del SIGE, fornendo conseguentemente alla DSI la documentazione delle funzioni di importazione.

Eventuali problematiche di incompatibilità o incompletezza dei dati da importare saranno affrontate e risolte dalla Ditta aggiudicatarie mediante la realizzazione di funzioni apposite volte a minimizzare le operazioni di inserimento o normalizzazione di dati da parte del Comune.

Saranno previste anche tutte le eventuali attività di registrazione diretta dei dati (data entry) che si rendessero necessarie per integrare la base dati SIGE con dati non recuperabili dagli attuali archivi.


42

Dovranno altresì essere previsti dei passi di bonifica automatica o semiautomatica dei dati in fase di importazione.

Le attività sono soggette a verifica (vd. par. 12.2) e, per ritardi nell'esecuzione delle attività o per qualità del servizio non corrispondente a quanto previsto, saranno applicate le penali specificate al succ.vo cap. 14.

8.3 Personalizzazione applicativa

I moduli offerti in licenza d’uso dovranno essere personalizzati, a cura della Ditta aggiudicataria, in base alle prescrizioni del presente capitolato, successivamente a una fase di analisi di dettaglio svolta dalla Ditta medesima col supporto dei referenti dell’Ente e del personale da loro incaricato.

Il PI specificherà tempi e modalità di conduzione di tale fase.

La documentazione sarà aggiornata con i documenti prodotti in sede di analisi di dettaglio e con tutti quelli inerenti l'implementazione.

Le attività sono soggette alle verifiche di cui al succ.vo cap. 12 e, per ritardi nell'esecuzione delle attività o per qualità del servizio non corrispondente a quanto previsto, saranno applicate le penali specificate al succ.vo cap. 14.

8.4 Formazione degli utenti

La formazione degli utenti sarà organizzata on site presso sedi del Comune; sarà erogata da istruttori incaricati dalla Ditta aggiudicataria e sarà rivolta agli utenti informatici ed amministratori e agli utenti gestionali secondo moduli formativi distinti. Prerequisito di ciascun modulo sarà, oltre alla conoscenza degli specifici processi automatizzati, la conoscenza del browser e della posta elettronica da parte degli utenti.

I moduli forniranno informazioni generali sull'ambiente di riferimento e, ciascuno per il proprio ambito, istruzioni specifiche sulle funzionalità del sistema e sul loro utilizzo da parte degli utenti.

I moduli formativi erogati dovranno includere apposite procedure di valutazione o autovalutazione del livello di apprendimento conseguito dai discenti.

La formazione degli utenti informatici ed amministratori sarà organizzata secondo un unico modulo formativo, erogato dopo l’installazione dell’applicazione e preliminarmente all'entrata in esercizio dei primi moduli del sistema. Nel caso in cui il rilascio di nuovi moduli abbia impatto sulle funzioni di amministrazione, la formazione sarà completata ed aggiornata preliminarmente all'entrata in esercizio di tali moduli.

La formazione degli utenti gestionali, in considerazione della numerosità e della varietà dei processi automatizzati dal sistema, sarà organizzata in opportuni sottomoduli, da tenersi prima del rilascio in esercizio dei corrispondenti moduli software. Ogni modulo software sarà illustrato in un'unica sessione formativa, di durata opportuna.

Uno specifico modulo formativo sarà dedicato ad una presentazione generale delle informazioni gestite dal sistema e delle funzionalità di consultazione, stampa, selezione, estrazione, analisi e sintesi offerte dai diversi moduli, fornendo un quadro esaustivo della ricchezza informativa offerta dal sistema.

I corsi si terranno, salvo diversamente concordato con il Comune, in ambienti didattici adeguati messi a disposizione dal Comune. La Ditta curerà la distribuzione del materiale didattico su supporto cartaceo ai discenti di ciascun modulo formativo. Il programma formativo dovrà essere contestualizzato alla specifica realtà e alle esigenze del DRFSE. La


43

formazione sarà erogata da istruttori incaricati dalla ditta; dovrà essere indicato precisamente il bilanciamento fra le risorse umane impiegate, esplicitando il rapporto fra quelle della ditta e quelle del DRFSE e i rispettivi ruoli.

L’organizzazione e la calendarizzazione dei moduli formativi saranno dettagliate nel PI.

La Ditta fornirà altresì copia elettronica del materiale didattico al referente tecnico. Il Comune potrà riprodurre senza limiti il materiale didattico e pubblicarlo sui propri siti interni, anche nel caso in cui il materiale didattico contenga sezioni di proprietà di terze parti.

Al fine di fornire anche agli utenti non partecipanti alle sessioni formative tutte le conoscenze necessarie sul sistema applicativo, la Ditta fornirà, su CDROM, una "Guida all'utilizzo del sistema".

La guida sarà organizzata secondo le modalità diffusamente utilizzate negli ambienti di help online dei vari prodotti software in commercio e conterrà, pertanto, sommario, indici, funzioni di ricerca, pagine di descrizione delle funzionalità del sistema e delle loro modalità di utilizzo, collegamenti ipertestuali, esempi pratici dell'uso del sistema e quant'altro ritenuto utile per favorire la conoscenza del sistema ed il reperimento delle informazioni.

La guida conterrà, in particolare, percorsi di navigazione predefiniti per utenti gestionali ed utenti generici.

Saranno preferite soluzioni che rendano disponibile la guida all'interno del sistema stesso. Il Comune potrà riprodurre senza limiti la guida e pubblicarla sui propri siti interni, anche nel caso in cui la guida contenga sezioni di proprietà di terze parti.

La guida sarà rilasciata dalla Ditta aggiudicataria in parallelo alle funzionalità esposte nei corsi erogati.

La qualità dei servizi formativi e della “Guida all’utilizzo del Sistema” saranno valutate in fase di collaudo attraverso lo svolgimento di apposite sessioni di verifica, secondo quanto indicato al succ.vo cap. 12.

8.5 Assistenza all'avviamento del sistema

La fornitura include un'attività di assistenza all'avviamento del Sistema, con lo scopo di affiancare e supportare gli utenti informatici, amministratori e gestionali nel suo corretto utilizzo.

Il servizio sarà svolto in orario lavorativo presso sedi del Comune e sarà erogato, per ogni modulo software rilasciato, entro il periodo massimo di un mese solare successivo al rilascio in esercizio del modulo stesso, salvo diversamente concordato con i referenti dell’Ente.

L'attività comporterà l’utilizzo di personale appositamente dedicato dalla Ditta aggiudicataria, per il totale complessivo di giorni/persona specificato in offerta.

Il personale utilizzato dovrà essere di gradimento dell’Amministrazione. L'utilizzo del personale del Fornitore potrà coinvolgere un massimo di tre persone nell'ambito di una stessa giornata, salvo condizioni di miglior favore accettate dallo stesso Fornitore, e potrà essere richiesto per periodi temporali non consecutivi.

La calendarizzazione delle attività e le sedi, situate in Firenze, presso le quali svolgere l’attività stessa, saranno comunicate dal Comune alla Ditta aggiudicataria con preavviso di almeno cinque giorni lavorativi.

Le attività sono soggette a verifica (vd. par. 12.2) e, per ritardi nell'esecuzione delle attività o per qualità del servizio non corrispondente a quanto previsto, saranno applicate le penali specificate al succ.vo cap. 14.


44

L'attività sarà liquidata sulla base dei consuntivi periodici delle prestazioni effettivamente svolte (al costo giornaliero, si ricorda, specificato dal Fornitore in sede di offerta economica).

8.6 Servizio di assistenza funzionale agli utenti

Lo scopo del servizio è fornire assistenza agli utenti sull'utilizzo delle funzionalità del Sistema al fine di garantirne il corretto e buon utilizzo.

A tal fine la Ditta aggiudicataria metterà a disposizione un apposito servizio di helpdesk che dovrà prevedere:

• Risposte a domande circa l’utilizzo dell’applicazione e consigli sulle migliori soluzioni ai problemi posti; nel caso di anomalie attribuibili a difetti di realizzazione dell’Applicazione, il centro di assistenza provvederà alla risoluzione del problema, con successivo aggiornamento del software e delle relative note operative. Le risposte saranno fornite via telefono o via email, di norma entro i trenta minuti successivi alle chiamate stesse.

• Assistenza per via telematica, permettendo al personale dell’Ente di inviare al Fornitore eventuali dati errati in forma protetta, perché sia possibile esaminarne le cause, operare eventuali ripristini (in tempi adeguati alle necessità dell’Ente) e restituire una relazione dei difetti riscontrati ed eventualmente corretti.

• Accettazione di richieste di intervento per attività di manutenzione urgente o di supporto in sede.

• Il servizio di supporto in sede potrà essere invocato come urgente (p. es. per ripristino dati o recupero funzionalità generali dell’Applicazione) e, in tal caso, l'intervento dovrà essere effettuato entro dodici ore dalla richiesta. Negli altri casi l’intervento dovrà essere effettuato entro 3 giorni lavorativi dalla richiesta stessa.

In ogni caso il Fornitore indennizzerà gli eventuali danni provocati in caso di sua colpa, dolo o grave negligenza.

Il servizio potrà essere acceduto da qualunque utente autorizzato del SIGE tramite telefono (chiamata urbana effettuata dal distretto telefonico di Firenze o numero verde) o fax oppure tramite email.

Il servizio telefonico sarà fornito tramite operatore (persona fisica) e dovrà essere dimensionato in modo tale da garantire la connessione con gli operatori entro un tempo medio di attesa non superiore a due minuti.

L'orario minimo richiesto per l’erogazione dei servizi è dalle 08.30 alle 17.30 dal lunedì al venerdì, salvo orari più estesi e la copertura del sabato offerti in gara quali elementi migliorativi.

Al di fuori dell’orario minimo le segnalazioni potranno avvenire tutti i giorni nell’arco delle 24 ore tramite fax o posta elettronica.

Per i collegamenti della Ditta da remoto verrà attivata, stanti le attuali politiche di sicurezza informatica dell’Ente, un’apposita connessione VPN, attraverso la quale effettuare l’intervento a distanza sui dati e/o programmi del Fornitore. Il servizio sarà concordato nelle modalità operative con il Fornitore, ma considerando che tutti i dati dell’applicazione saranno leggibili, il Fornitore si impegna al rispetto delle norme del D. Lgs. 196/2003. Per particolari esigenze di analisi e di elaborazione, il Fornitore potrà essere autorizzato a trasferire dati dell’Ente su propri sistemi; tali dati sono soggetti alla tutela prevista dalla normativa sulla privacy, pertanto il Fornitore dovrà garantire il trasferimento di tali dati in forma protetta, utilizzandoli al solo fine di testare i programmi e tenendoli per il solo tempo necessario.

Il servizio di assistenza funzionale agli utenti sarà fornito per tutta la durata del contratto a partire dal rilascio in esercizio del primo modulo software e fino al termine del periodo di


45

garanzia.

Successivamente al periodo di garanzia potrà essere sottoscritto specifico contratto, rinnovabile annualmente, per i servizi di assistenza e di manutenzione ordinaria.

Per tutta la durata del servizio la Ditta aggiudicataria fornirà con periodicità mensile ai referenti dell’Ente una documentazione, anche in formato elettronico, sulle attività svolte. La documentazione conterrà gli elementi di riscontro principali per la valutazione del servizio e dell'impatto del sistema sugli utenti del Comune. In particolare, la Ditta fornirà l’elenco delle FAQ (Frequently Asked Questions) in modo pubblicabile sul sito interno del Comune.

Per qualità del servizio non corrispondente a quanto previsto, a seguito di verifica negativa secondo quanto previsto al par. 12.2, si applicano le penali di cui al cap. 14.

8.7 Manutenzione

Per manutenzione si intende ogni modifica dei programmi, della struttura della base di dati e della documentazione dell’Applicazione effettuata dal Fornitore sia durante l’esecuzione del contratto sia dopo la sua conclusione, in tal caso sulla base di specifici successivi accordi con l’Ente (es. contratto di manutenzione ordinaria, affidamenti di interventi di manutenzione straordinaria).

La manutenzione si applica anche nel caso che modifiche legislative o normative (intervenute indipendentemente dalla volontà dell'Amministrazione, ad es. da Organi centrali dello Stato) rendano l'Applicazione non più conforme e/o adeguata alle nuove condizioni, per cui la Ditta aggiudicataria dovrà ripristinare il corretto funzionamento e la capacità di svolgere adeguatamente tutto quanto richiesto dalle normative in vigore.

Dei seguenti sottoparagrafi, i primi due distinguono le tipologie di servizio ai fini della gestione contrattuale, l’ultimo precisa le condizioni di erogazione del servizio.

8.7.1 Manutenzione ordinaria

Manutenzione adattativa: Rientrano in questa categoria sia gli adeguamenti e le estensioni della Procedura necessari per ottemperare a nuove e vincolanti norme, aventi valenza soprannazionale, nazionale o regionale, sia la fornitura di nuove versioni (o release) via via introdotte sul mercato dal Fornitore durante la vita operativa del SIGE, in quanto tali aggiornamenti offrono ulteriori funzioni e correggono eventuali errori e difetti evidenti o latenti presenti nei programmi precedenti (c.d. “bug fix”).

Manutenzione evolutiva: Fanno parte della manutenzione evolutiva gli interventi funzionali, dipendenti da novità esterne al Fornitore, quali ad esempio le variazioni al software d’ambiente, e le modifiche prodotte per adeguare il software a nuovi standard tecnologici e di mercato, nonché variazioni sui programmi di trasmissione dati forniti da soggetti esterni.

Manutenzione preventiva e correttiva: Essa è finalizzata sia a prevenire il manifestarsi di difetti (originari o intervenuti senza colpa dell'Amministrazione) o di guasti, errori, malfunzionamenti, bug e/o ogni altra imperfezione, compreso il degrado delle prestazioni fornite dai software applicativi rispetto ai livelli abituali (di seguito comunque "guasto"); sia a ripristinare il corretto funzionamento dei prodotti software che rivelassero uno o più guasti. In quest’ultimo caso si tratta, pertanto, degli interventi necessari per riparare a comprovati difetti e/o anomalie della fornitura, dove: • difetto congenito è la causa di ogni errore o malfunzionamento che provochi indesiderate e comprovabili perdite, alterazioni o errato trattamento dei dati gestiti e sia suscettibile di generare output errati;

• anomalia è la causa di ogni errore o malfunzionamento che fa sì che il comportamento si discosti da quello atteso in base a quanto specificato nel presente capitolato e alle specifiche ricavate dall’analisi di dettaglio.


46

8.7.2 Manutenzione straordinaria

Manutenzione migliorativa e personalizzazioni: Si tratta degli interventi richiesti dal personale autorizzato dell’Ente per adeguare il software oggetto dell’appalto a nuove esigenze sorte in corso d’esercizio, da attuarsi per esempio attraverso l'estensione delle funzionalità della Procedura. Rientrano in tale ambito gli interventi dovuti a normative di ambito locale (es. Regolamento comunale).

8.7.3 Condizioni per lo svolgimento delle attività manutentive

A partire dal rilascio in esercizio del primo modulo software, e per tutta la durata del contratto, la Ditta aggiudicataria si impegna a mettere a disposizione del Comune idoneo personale per attività di manutenzione, quali la realizzazione di nuove funzionalità o evoluzione di funzionalità già rilasciate o la consulenza per una migliore e più rapida identificazione, soluzione e prevenzione di problemi applicativi.

Le attività saranno richieste dai referenti dell’Ente con le stesse modalità previste per l’attività di assistenza agli utenti (vd. precedente par. 8.6).

Gli interventi di manutenzione correttiva dovranno essere effettuati entro 12 ore dalla segnalazione, nel caso di errori bloccanti, ed entro 3 giorni lavorativi nel caso di errori non bloccanti. Su segnalazione dell'Ente, il Fornitore si impegna a dedicare maggiori risorse alla soluzione del problema per ridurre i tempi di completamento dell’intervento in prossimità di scadenze di legge, amministrative, regolamentari, etc., che l'Amministrazione non può trasgredire per guasti a lei non imputabili e sui quali non può intervenire.

Gli interventi tecnici di manutenzione preventiva e gli altri che comportino adeguamenti, aggiornamenti, ovverosia in genere tutti quelli che comportino un “fermo programmato” dell’Applicazione, dovranno essere effettuati nei giorni e con gli orari esplicitamente concordati con l'Amministrazione.

A fronte di ogni richiesta per manutenzione straordinaria la Ditta aggiudicataria presenterà la propria proposta di utilizzo qualitativo e quantitativo di proprie risorse, specificando i tempi di completamento dell’intervento ed il relativo preventivo.

L'attività sarà svolta sulla base dell'accettazione da parte del Comune dei preventivi presentati e della tempificazione delle attività in essi esposta e sarà liquidata sulla base dei consuntivi periodici delle prestazioni effettivamente svolte, secondo le modalità di collaudo descritte nel succ.vo par. 12.2.

Il servizio di manutenzione ordinaria dovrà essere assicurato per tutta la durata del contratto e fino al termine del periodo di garanzia, senza alcun onere a carico dell’Ente.

Come detto al precedente par. 8.6, successivamente al periodo di garanzia potrà essere sottoscritto specifico contratto di assistenza e manutenzione ordinaria: a tal fine la Ditta indicherà nell’offerta il canone annuo che applicherà al termine del periodo di garanzia.

Il servizio di manutenzione straordinaria dovrà essere assicurato per tutta la durata del contratto e fino al termine del periodo di garanzia, applicando l’importo unitario indicato in offerta economica, di un giorno/persona di un “progettista” e di un “analista/programmatore”.

Per tutta la durata del servizio la Ditta fornirà con periodicità mensile al referente tecnico una documentazione, anche in formato elettronico, sulle attività svolte. La documentazione conterrà gli elementi di riscontro principali per la valutazione del servizio e dell'impatto del sistema sugli utenti del Comune. In particolare, la Ditta fornirà l’elenco delle FAQ (Frequently Asked Questions) in modo pubblicabile sul sito interno del Comune.

Prima di essere rilasciati in esercizio, i moduli software modificati e/o realizzati saranno sottoposti al test di accettazione provvisoria di cui al par. 12.1.


47

Per ritardi nello svolgimento delle attività di cui al presente paragrafo saranno applicate le penali di cui al cap. 14.

8.8 Gestione del software applicativo

Ogni impresa che si propone di fornire applicazioni ad Enti della complessità del Comune, deve essere in grado di sostenere con particolare impegno la qualità del proprio prodotto durante la sua vita operativa (non inferiore a cinque anni), al fine di conservare i livelli di efficacia ed efficienza che lo caratterizzavano al momento dell'acquisto:

ü effettuando le modifiche necessarie a mantenerlo adeguato alle frequenti variazioni normative, personalizzazioni, nuove esigenze, etc.;

ü fornendo un adeguato servizio sistemistico per l'ottimizzazione e la messa a punto periodica dell'intero sistema installato (c.d. “fine tuning”).

Per "gestione del software applicativo" si intende qui l'insieme organizzato di attività messe in atto dalla Ditta aggiudicataria a proprio rischio e spese per fornire all'Amministrazione i servizi di cui al punto precedente, se questa lo richiederà, senza che questo degradi le normali prestazioni e disponibilità dell'applicazione nei confronti degli utenti.

In particolare la Ditta curerà i seguenti aspetti, fornendo all'Amministrazione rapporti e statistiche mensili sull'andamento delle prestazioni:

ü il sistema operativo del server che ospita l'Applicazione; ü i programmi dell'Applicazione e relative modifiche e personalizzazioni; ü il database che ospita i dati del SIGE e relativi ripristini.

L'Amministrazione curerà invece i seguenti aspetti:

ü a) funzionamento hardware del server; ü b) collaudo dei programmi della Procedura e delle modifiche apportate; ü c) quotidiana esecuzione dei backup del database; ü d) gestione degli utenti e relative autorizzazioni.

Gli interventi effettuati su moduli già in produzione sono sempre complessi, perché non solo occorre coordinarsi con gli utenti finali per limitare il disservizio, ma si introduce inevitabilmente instabilità di funzionamento rispetto alla situazione precedente, per cui ogni attività deve essere pianificata e verificata in stretta collaborazione tra il personale del Fornitore e quello dell'Amministrazione.

Scopo della pianificazione è garantire che, alla scadenza del termine concordato, gli utenti finali riprendano comunque il loro lavoro, eventualmente ripristinando le condizioni precedenti qualora imprevisti o difficoltà abbiano impedito di completare l'intervento, che dovrà essere ritentato in seguito senza ulteriori costi per l'Amministrazione.

Prima di effettuare ogni intervento, la Ditta aggiudicataria dovrà informare l'Ente ed ottenerne il parere favorevole, in mancanza del quale potrà procedere per quanto di propria competenza assumendosene ogni responsabilità.

8.9 Garanzia

I prodotti software rilasciati, pacchettizzati, personalizzati o realizzati ad hoc, devono essere coperti da garanzia e manutenzione correttiva per un periodo di almeno 12 mesi dalla data del loro collaudo.

Durante il periodo della garanzia, la Ditta aggiudicataria dovrà assicurare, in caso di inconvenienti o guasti ascrivibili a difetti di realizzazione, un intervento onsite senza alcun addebito e nel rispetto dei seguenti livelli minimi di servizio:

• rilascio, installazione e messa in esercizio degli aggiornamenti delle licenze software, siano essi release o versioni, rilasciate ufficialmente durante il periodo di validità del


48

presente contratto: entro un mese dalla data di effettivo rilascio;

• problemi relativi al software applicativo: risoluzione del problema per errori bloccanti entro 12 ore dalla segnalazione; risoluzione del problema per errori non bloccanti entro tre giorni lavorativi dalla segnalazione.

Il tipo, bloccante o non bloccante, di errore sarà giudicato dal referente amministrativo.

Gli oneri di garanzia sono estesi anche alla ricostruzione della base dati o della parte di essa che dovesse risultare danneggiata in seguito agli inconvenienti.

Per mancato rispetto dei livelli minimi di servizio saranno applicate le penali di cui al cap. 14.

Per tutte le componenti di software applicativo e d'ambiente fornite, dovrà essere rilasciata tutta la documentazione specifica.

8.10 Documentazione

La documentazione dovrà essere fornita sia su supporto cartaceo sia in formato elettronico (CDROM, DVD, ... ) e dovrà includere:

• specifiche tecniche e funzionali generali e di dettaglio; • descrizione completa e commentata della struttura della base dati; tale descrizione

deve essere finalizzata a consentire al personale dell'Amministrazione l'estrazione consapevole e lo sfruttamento ottimale dei dati contenuti negli archivi, senza modificare la relativa struttura;

• documenti d’analisi e progetto elaborati nelle forme consuete dal Fornitore, ivi inclusa la documentazione inerente i test case;

• manuali sistemistici ad uso degli utenti informatici;

• manuali operativi ad uso degli utenti amministratori; • manuali utente ad uso degli utenti gestionali; • documentazione esplicativa ed esemplificativa ad uso degli utenti generici.

La documentazione dovrà essere in lingua italiana.

La prima versione delle documentazioni dovrà essere consegnata secondo i tempi previsti nel PI e, nel prosieguo del progetto, essa dovrà essere costantemente integrata dai successivi aggiornamenti, in particolare quelli dovuti alle personalizzazioni.

La DSI potrà riprodurre la documentazione su supporto cartaceo o in formato digitale, nonché pubblicarla liberamente sui siti interni del Comune, anche nel caso in cui la stessa contenga sezioni di proprietà di terze parti.

La qualità della documentazione e la tempestività degli aggiornamenti in corso di esecuzione del progetto sono soggette a verifica nei termini di cui al succ.vo cap. 12.

9. Affidamento dei servizi di assistenza e di manutenzione ordinaria

Al termine del periodo di garanzia, l’Ente si impegna ad affidare alla Ditta, per i successivi dodici mesi, l’erogazione dei servizi della manutenzione ordinaria e si riserva altresì di affidargli, secondo necessità, l’erogazione della manutenzione straordinaria, secondo le specifiche condizioni riportate in offerta economica.

Il contratto di assistenza e manutenzione specificherà i servizi scelti dall’Ente.

Successivamente, il contratto sarà rinnovabile, a scelta dell’Ente, di anno in anno, con facoltà dell’Ente stesso di determinare, entro due mesi dalla scadenza, quali servizi rinnovare e/o attivare per l’anno successivo.


49

L’ammontare dei canoni e delle tariffe per un nuovo anno non potrà superare quello dell’anno precedente se non per la quota di rivalutazione dovuta all’inflazione verificatasi nell’anno precedente, misurata in base all'indice ISTAT dei prezzi al consumo.

Per le attività di servizio è data facoltà al Fornitore di avvalersi, previa autorizzazione dei referenti dell’Ente, anche di personale esterno alla sua organizzazione, ferma restando la sua responsabilità nei confronti dell’Ente, nei limiti e alle condizioni previsti dal presente capitolato.

Nel caso in cui, per l’anno in corso, l’Ente non abbia sottoscritto la copertura tramite canone di uno dei servizi di assistenza e manutenzione ordinaria, le prestazioni professionali ad essi relative possono essere attivate dall’Ente, in caso di necessità, applicando le modalità e le tariffe previste per la manutenzione straordinaria, eventualmente rivalutata come stabilito al punto precedente.

10. Organizzazione e gestione del rapporto contrattuale

10.1 Vincoli contrattuali

Fanno parte del contratto d'appalto:

• il presente capitolato tecnico firmato in ogni pagina per integrale accettazione; • l'offerta presentata dalla Ditta aggiudicataria, completa di ogni documento prodotto e di

tutto il materiale documentale; • il PI definitivo, prodotto secondo quanto indicato al precedente par. 8.1; • le specifiche risultanti dall’analisi di dettaglio, a seguito dello svolgimento delle attività

di adeguamento applicativo, secondo quanto prescritto al precedente par. 8.3.

Con la sua partecipazione alla gara, la Ditta aggiudicataria espressamente riconosce ed accetta tutte le condizioni poste dall'Amministrazione in proposito.

Le norme di cui al presente capitolato hanno validità sino al totale esaurimento della consegna e del positivo collaudo di accettazione dei prodotti relativi.

L'Amministrazione non riconosce infatti formalmente assolta l'obbligazione di consegna da parte della Ditta aggiudicataria fino al positivo superamento del collaudo, in quanto qualsiasi prodotto non ancora funzionante, difettoso, viziato o comunque inadeguato non può fornire all'Amministrazione l'utilità che la stessa si è prefissa e che costituisce lo scopo stesso della presente fornitura.

Le norme che si riferiscono a servizi postvendita (manutenzione, aggiornamenti, etc.) conservano invece la loro validità per tutto il tempo di utilizzo del prodotto acquistato da parte dell'Amministrazione (comunque non superiore a un decennio).

10.2 Referenti del Fornitore e dell’Ente

Al fine di seguire, controllare e coordinare le attività di realizzazione del progetto, garantendo la continuità dello scambio di informazioni tra l’Ente e il Fornitore, si seguiranno le modalità di seguito indicate.

Per la gestione operativa del contratto il Comune nominerà, subito dopo la stipula del contratto, un referente amministrativo e un referente tecnico, quali responsabili dei rapporti con il Fornitore per l’esecuzione del contratto, con funzioni d'interfaccia per il rispetto delle esigenze e delle priorità del Comune e la supervisione ed il controllo dell'avanzamento della fornitura nelle sue diverse fasi e componenti.

Allo stesso modo il Fornitore nominerà un responsabile operativo – Capo Progetto – e un referente commerciale con il compito di rappresentare e impegnare il Fornitore stesso nella


50

fase esecutiva del contratto. Tali responsabili saranno gli unici interlocutori dei referenti dell’Ente ogniqualvolta si presentino problemi sia nella fase realizzativa che in quelle successive di avviamento, personalizzazione ed assistenza, di tutto quanto è oggetto della presente fornitura.

In particolare, il responsabile operativo della Ditta aggiudicataria sarà il capo progetto indicato dalla Ditta stessa nella propria offerta. Tale capo progetto dovrà mantenere il proprio incarico per tutta la durata del contratto. L'eventuale ed eccezionale cambiamento del capo progetto da parte della Ditta dovrà essere da quest'ultima adeguatamente motivato. In tal caso la Ditta si impegna a designare un nuovo capo progetto, provvisto di un curriculum equivalente o superiore. Il nuovo capo progetto, referente della Ditta, dovrà essere formalmente accettato dal Comune.

I due referenti si serviranno, ciascuno per la propria parte, di team progettuali, i cui componenti potranno partecipare alle attività di pianificazione e monitoraggio delle attività.

La Ditta aggiudicataria dovrà allegare all’offerta il curriculum professionale del responsabile operativo e dei tecnici che si prevede lo affiancheranno nelle diverse attività oggetto dell’appalto (personalizzazioni, avviamento, formazione, assistenza, manutenzione, collegamenti e interfacce). Tutte le comunicazioni ufficiali della Ditta in merito alla fornitura dovranno essere indirizzate ai referenti dell’Ente ed, eventualmente, in copia a terzi da lui indicati. Analogamente tutte le comunicazioni del Comune saranno indirizzate ai referenti della Ditta.

I referenti dell’Ente, ove verifichino che una fornitura o un'attività non abbiano raggiunto i risultati previsti o siano state eseguite in modo difforme dalle prescrizioni del presente capitolato, ne dispongono il rifacimento; tale facoltà si può esercitare durante tutta la fase esecutiva, allorché si vengano ad evidenziare disfunzioni operative nell'integrazione del progetto, anche se la fornitura o l'attività in questione dovesse riguardare uno stato di avanzamento già approvato.

I referenti dell’Ente possono:

• Dare disposizioni ai referenti del Fornitore di sostituire una o più risorse umane impegnate nella realizzazione;

• Imporre al fornitore particolari prescrizioni tese alla piena riuscita delle attività nel rispetto delle finalità generali del progetto; tali eventi non daranno luogo a variazioni dell'importo della fornitura.

• Disporre la temporanea sospensione di alcune o di tutte le attività, sia per carenze imputabili al Fornitore, sia per motivi organizzativi dell'Amministrazione, senza per questo dare adito a riserve da parte del Fornitore medesimo.

• Autorizzare deroghe rispetto alla successione delle attività prevista dal PI ove, pur senza il completamento dell'attività precedente, sia possibile ed opportuno intraprendere quella successiva; tali deroghe sono esclusivamente di natura organizzativa e non possono influire sulla valutazione dell'avanzamento ai fini dei pagamenti.

I referenti dell’Ente hanno l'obbligo di segnalare ogni inadempienza del Fornitore.

10.3 Obblighi del Fornitore

La Ditta aggiudicataria ha l'obbligo di stipulare in forma pubblica amministrativa il contratto relativo alla presente fornitura, assumendosene le spese.

E' responsabilità del Fornitore scegliere, dimensionare ed assemblare i vari componenti di ciascuna soluzione software offerta per assicurarne la perfetta integrazione e compatibilità al fine di ottenere il miglior funzionamento complessivo possibile.

La Ditta Aggiudicataria dovrà installare ed attivare, con proprio personale tecnico e a proprie spese, tutta l'Applicazione oggetto della presente fornitura sulle piattaforme


51

hardware/software messe a disposizione dall'Ente, inclusa la configurazione ed il collegamento dei sistemi ai posti di lavoro ed altre unità periferiche esistenti, se necessario.

Tra le operazioni d'installazione a carico del Fornitore sono incluse, in quanto necessarie al pieno collaudo della fornitura, le attività di pianificazione, analisi, trasferimento dei dati dagli archivi dell’Ente al database del SIGE ed ogni altra attività necessaria a mettere in grado l'Amministrazione di sfruttare al meglio le potenzialità della Procedura.

Il Fornitore dovrà curare l'addestramento del personale dell'Amministrazione in modo da metterlo in condizione di provvedere autonomamente al funzionamento corrente dell'Applicazione, ricavando il maggior beneficio dall'uso di tutti i programmi.

Il Fornitore assume l'obbligo di tenere indenne in ogni tempo l'Ente da tutte le rivendicazioni, responsabilità, perdite, danni, costi, risarcimenti e quanto altro chiunque possa avanzare e/o pretendere per la presunta violazione di diritti d'autore, marchi di fabbrica, brevetti e simili, italiani o stranieri, derivanti dalla presente fornitura o dal suo uso.

Le Parti si impegnano a darsi reciprocamente immediata notizia di qualsiasi azione o questione di terzi di cui siano venute a conoscenza relativamente a quanto sopra.

La Ditta aggiudicataria assumerà a sue spese la difesa contro tale azione e terrà a suo carico gli oneri eventualmente conseguiti nei confronti del terzo attore.

Il Fornitore si assume tutte le responsabilità inerenti eventuali infortuni o danni a persone o cose arrecati all’Ente o a terze parti, durante lo svolgimento di attività legate alla fornitura.

Il Fornitore si impegna ad ottemperare a tutti gli obblighi verso i propri dipendenti, derivanti da disposizioni legislative, regolamenti e norme contrattuali vigenti in materia di lavoro, assicurazioni sociali e previdenza, assumendo a suo carico tutti gli oneri relativi.

Esso garantisce ed assume l'obbligo di poter fornire all'Amministrazione per i 4 (quattro) anni successivi alla data del collaudo, compreso il periodo di garanzia, tutti i servizi professionali correlati al software applicativo e i relativi interventi di consulenza a supporto del DRFSE, oggetto della presente fornitura (ove applicabili).

Dalla data del collaudo con esito favorevole o dalla data di completamento della consegna dell’intera fornitura, se successiva, il Fornitore dovrà assicurare a ciascun prodotto un periodo di garanzia onnicomprensiva non inferiore a 12 (dodici) mesi.

Trascorso il periodo di garanzia, esso continuerà a rendere disponibili (a pagamento) gli stessi servizi di cui al punto precedente, che il Comune si riserva di utilizzare o meno.

L’Ente solleva il Fornitore da qualsiasi responsabilità nei seguenti casi:

• eventuale utilizzo, da parte di personale dell'Ente, di prodotti software non regolarmente licenziati, tranne che nei casi in cui detto software sia stato installato dal Fornitore o su sua iniziativa;

• le caratteristiche tecniche dell’installazione (ambiente, impianto elettrico, collegamenti, etc...) non corrispondano alle specifiche tecniche del costruttore;

• guasti e anomalie della Procedura o dei suoi dati provocati da colpa, dolo o negligenza del personale dell’Ente;

• guasti e anomalie della Procedura o dei suoi dati provocati dall’utilizzo di software diverso da quello prodotto o indicato dal Fornitore.

10.4 Obblighi dell’Ente

L'Amministrazione metterà a disposizione della Ditta aggiudicataria la piattaforma hardware/software descritta al precedente par. 7.2 (o una sostanzialmente equivalente)


52

stimata in grado di eseguire efficacemente un'applicazione del tipo oggetto della presente fornitura.

L’Amministrazione metterà a disposizione del Fornitore il proprio personale tecnico per collaborare alle operazioni preliminari al collaudo e all'avviamento operativo, nonché per facilitare il trasferimento degli archivi di cui al precedente par. 8.2.

10.5 Codici sorgente

In relazione ai codici sorgenti dell’Applicazione, ferma restandone la proprietà da parte del Fornitore, il contratto dovrà prevedere quanto segue:

La cessione all’Ente, senza oneri aggiuntivi per lo stesso, dei codici sorgenti completi e aggiornati della Procedura nei casi di:

• fallimento; • liquidazione; • cessazione di attività; • cessione del ramo d'azienda; • concordato preventivo.

Il deposito, entro la data del collaudo, dei codici sorgente dell’Applicazione, insieme con la loro documentazione, presso studio notarile di fiducia della Ditta aggiudicataria.

Con cadenza almeno semestrale, se nel tempo intercorso la Ditta avrà effettuato interventi sull’Applicazione comportanti modifiche dei codici sorgenti, la comunicazione di aver provveduto all’aggiornamento, con le modifiche e le personalizzazioni nel frattempo apportate all’Applicazione, dei sorgenti depositati presso lo studio notarile scelto. Tale comunicazione sarà anche condizione per il rinnovo annuale del contratto di assistenza e manutenzione.

L’Ente ha diritto:

• alla piena conoscenza dei codici sorgente, senza però possibilità di rivendita di questi ultimi. Tale diritto si potrà esplicare anche attraverso la formulazione, su richiesta dell’Ente, di apposita offerta per la formazione del suo personale tecnico, allo scopo di approfondire la conoscenza del Sistema.

• A seguito di tali attività formative, il personale a ciò formato dell’Ente avrà facoltà di modificare i sorgenti, sempre al solo scopo di uso interno e senza possibilità di rivendita e fermo restando che l’intervento sui codici sorgenti da parte di altro personale causa il decadere di ogni forma di garanzia o di copertura manutentiva, sia pure in vigenza del contratto di assistenza e manutenzione.

• alla proprietà dei moduli di programma sviluppati dal Fornitore per le finalità del progetto SIGE e la titolarità di ogni diritto loro relativo, ivi compresa la proprietà dei codici sorgenti.

Ai sensi dell’art. 69 del D. Lgs. 7 marzo 2005 n. 82, l'Ente ha facoltà di disporre della Procedura, ivi compresi i suoi codici sorgenti, per il riuso a titolo gratuito da parte di altri Enti, ai quali il Fornitore presterà, dietro corrispettivo economico da pattuire con gli Enti interessati, servizi atti a consentire tale riuso.

Il Fornitore si impegna a garantire la facile portabilità del prodotto finito su piattaforme diverse da quella prevista per la presente fornitura.

11. Risoluzione anticipata del contratto

Fatta salva ogni altra disposizione che consente all’Ente la risoluzione anticipata del contratto, tale facoltà è prevista esplicitamente per il Comune nei seguenti casi:


53

• esito negativo del collaudo dei rilasci software per due volte consecutive; • applicazioni delle penali previste al succ.vo cap. 14 per un importo complessivo

superiore al 10% dell'importo contrattuale; • inadempienze gravi degli obblighi contrattuali che si protraggano oltre il termine

perentorio assegnato dal Comune alla Ditta per porre fine all'inadempimento; • quando il Fornitore ceda in subappalto tutta o parte della fornitura senza esserne stato

preventivamente autorizzato dall’Ente o, pur autorizzato, abbia subappaltato per una misura superiore a quella consentita dall’Ente stesso;

• quando, per cause di fallimento od altro (cessione del Fornitore o del ramo d'azienda ad altra impresa, cessazione dell'attività, concordato preventivo) non sia possibile al Fornitore di continuare il rapporto con l'Ente;

• mancata regolarizzazione da parte del Fornitore dei rapporti di lavoro con i suoi dipendenti entro tre mesi dall'eventuale contestazione;

• mancata reintegrazione della cauzione eventualmente escussa entro il termine di 15 giorni dal ricevimento della relativa richiesta da parte dell’Ente;

• violazione dei brevetti industriali e diritti d'autore; • qualora taluno dei componenti l'organo di amministrazione o l'amministratore delegato

o il direttore generale o il responsabile tecnico del Fornitore siano condannati, con sentenza passata in giudicato, per delitti contro la Pubblica Amministrazione, l'ordine pubblico, la fede pubblica o il patrimonio, ovvero siano assoggettati alle misure previste dalla normativa antimafia.

In caso di risoluzione anticipata del contratto il Comune effettuerà, tramite propri periti, una stima dei beni e servizi forniti e dei beni e servizi da fornire e valuterà l’entità del danno subito.

Fatto salvo ogni altro diritto, l’Amministrazione avrà potestà di rivalsa sulla cauzione prestata dalla Ditta.

Le spese occorrenti per l’eventuale risoluzione del contratto e consequenziali saranno a totale ed esclusivo carico del Fornitore.

Nel caso in cui la Ditta aggiudicataria si rifiuti, senza valida ragione, di stipulare il contratto entro il termine fissato dall’Ente o non versi i relativi diritti e spese, oppure non costituisca nel termine prefissato la cauzione definitiva di cui al cap. 18, decadrà automaticamente dall’aggiudicazione e ciò verrà fatto risultare con semplice comunicazione scritta da parte dell’Ente.

Qualora la Ditta aggiudicataria non proceda all’esecuzione dei compiti oggetto del presente atto con la perizia e la diligenza richiesta nella fattispecie, l’Ente può fissare un congruo termine entro il quale la società stessa dovrà uniformarsi alle condizioni della convenzione. Decorso inutilmente tale termine, i referenti dell’Ente potranno risolvere il contratto.

12. Test di accettazione provvisoria, verifica dei servizi e collaudo

Nel seguito vengono esplicitate le diverse attività previste per i test di accettazione provvisoria, per le verifiche degli SPC e per il collaudo finale del Sistema.

12.1 SAL: test di accettazione e verifiche

Secondo quanto sopra specificato, l’Applicazione sarà rilasciata in varie fasi, a ciascuna delle quali corrisponderà un SAL, cioè i moduli software via via rilasciati e gli SPC da svolgere durante la fase saranno sottoposti rispettivamente a provvisori test di accettazione e verifiche in corso d’opera.


54

I SAL verranno effettuati da un gruppo di lavoro appositamente nominato, di volta in volta per ogni singolo SAL, dai referenti dell’Ente.

La Ditta aggiudicataria si impegna a recepire le eventuali mancanze rilevate nei test e nelle verifiche entro il termine massimo di 20 giorni solari.

Scaduto tale termine senza che la Ditta nulla abbia fatto per rimediare ai difetti riscontrati o alle carenze rilevate riguardo all’erogazione degli SPC, si applicano le penali giornaliere appositamente specificate al succ.vo cap. 14.

12.1.1 Test di accettazione provvisori

I test di accettazione provvisori sono prove di funzionalità volte ad accertare, nel loro complesso, la rispondenza dei singoli moduli applicativi rilasciati:

• alle specifiche del presente capitolato; • a quanto successivamente concordato e fissato nel PI definitivo (vd. par. 8.1.); • alle specifiche risultanti dall’analisi di dettaglio di cui al par. 8.3.

I test verranno svolti su insiemi adeguati di dati di prova, precaricati sugli archivi dell’applicazione secondo le modalità e nei tempi indicati dal PI. Quando espressamente richiesto dai referenti dell’Ente, il Fornitore è tenuto a dare, senza alcun onere aggiuntivo, l’assistenza necessaria all’effettuazione dei test. I test potranno essere effettuati anche in assenza di rappresentanti del Fornitore, purché il loro esito sia verbalizzato e controfirmato dai partecipanti.

Dell'esito dei test verrà redatto apposito verbale, con particolare riguardo per l'efficacia, la completezza, la facilità d'uso, l'efficienza ed ogni altro aspetto significativo dell'applicazione.

Prima di ogni test di accettazione provvisorio la Ditta aggiudicataria fornirà ai referenti dell’Ente, per preventiva accettazione, i propri piani e casi di test.

12.1.2 Verifiche in corso d’opera

Le verifiche degli SPC in corso d’opera riguarderanno i diversi servizi da erogare nella fase di PI sottoposta a SAL.

Ogni verifica sarà condotta secondo le modalità proprie di erogazione e le caratteristiche dello specifico servizio sottoposto all’attenzione del gruppo di lavoro, e potrà svolgersi sia durante l’erogazione del servizio sia al termine del medesimo.

12.2 Collaudo

Il collaudo è inteso a verificare, per tutti gli elementi della fornitura, che essi siano conformi alle caratteristiche tecniche offerte in gara e comunque non inferiori ai requisiti minimi descritti in questo capitolato, a quanto successivamente concordato e fissato nel PI definitivo (vd. par. 8.1.) e nell’analisi di dettaglio di cui al par. 8.3.

Il collaudo sarà eseguito entro 60 giorni solari dalla comunicazione di disponibilità al collaudo da parte della Ditta. Qualora tale comunicazione superi i termini fissati dal PI e trascorsi invano i termini dell’apposito sollecito da parte dei referenti dell’Ente, si applicheranno le penali previste al succ.vo cap. 14.

L’Applicazione sarà considerata inclusiva anche degli eventuali moduli software nel frattempo realizzati tramite l’attività di adeguamento applicativo e di manutenzione migliorativa e/o di personalizzazione di cui ai precedenti par. 8.3 e 8.7.

Al collaudo sovrintenderà un gruppo di lavoro dell'Ente, nominato dai referenti del medesimo, e tutte le prove che lo costituiscono verranno effettuate presso le sue sedi.


55

Ogni singola prova sarà relativa a uno specifico e predeterminato insieme di requisiti (in tal caso la prova consisterà di uno o più specifici "test") o alla corretta esecuzione di un SPC (in tal caso la prova è detta verifica, come già al precedente par. 12.1). Delle singole attività (es. svolgimento di una giornata di formazione) o requisiti da sottoporre, rispettivamente, a verifica o test verrà data comunicazione al Fornitore entro i tre giorni lavorativi precedenti l'effettuazione della prova.

La Ditta aggiudicataria fornirà, inoltre, dei test di stress che consentano di rilevare la rispondenza del Sistema ai requisiti prestazionali.

L'attività di docenza e di espletamento per i corsi di formazione sarà verificata sia in forma preventiva sia in corso d'opera.

I test verranno svolti su insiemi adeguati di dati reali, sia caricati su un database di test sia in produzione effettiva. Quando espressamente richiesto dai referenti dell’Ente nella loro comunicazione, il Fornitore è tenuto a dare, senza alcun onere aggiuntivo, l’assistenza necessaria all’effettuazione dei test, i quali potranno, comunque, essere effettuati anche in assenza di rappresentanti del Fornitore, purché il loro esito sia verbalizzato e controfirmato dai partecipanti appartenenti al gruppo di lavoro dell’Ente.

Il verbale potrà raccogliere l’esito di più sessioni di prova. Ogni 2 settimane i verbali nel frattempo pervenuti ai referenti dell’Ente dovranno essere da loro valutati e approvati per iscritto. In mancanza di evidenze certe, di non pertinenza o inadeguatezza delle prove svolte i referente dell’Ente ne disporranno la ripetizione. Per le prove considerate valide, i referenti dell’Ente attesteranno: il grado di congruità delle soluzioni adottate dal Fornitore per il soddisfacimento dei requisiti sottoposti a test oppure quello di correttezza ed efficacia nell'esecuzione delle attività sottoposte a verifica e attribuiranno un punteggio variabile da 1 a 10 con intervalli minimi di 1/10. Sono da ritenere requisiti non soddisfatti dal Fornitore o servizi non eseguiti correttamente, a causa di soluzioni o attività non congrue, quelli alla cui valutazione viene attribuito nell’atto di approvazione e valutazione un punteggio inferiore o uguale a 6,5 (sei virgola cinque).

Gli eventuali moduli software realizzati successivamente al collaudo (tramite manutenzione migliorativa – vd. par. 8.7) saranno collaudati separatamente secondo le stesse modalità.

In caso di esito negativo di un collaudo, la Ditta dovrà provvedere entro il termine massimo di 20 giorni solari all'eliminazione dei vizi e delle difformità riscontrati. A discrezione dell’Ente, la ripetizione del collaudo è effettuata anche su un campione diverso da quello già esaminato.

Successivamente a tale termine saranno applicate le penali di cui al succ.vo cap. 14.

In caso di esito negativo di una verifica, la Ditta dovrà provvedere entro il termine massimo di 20 giorni solari all'eliminazione dei vizi e difformità riscontrati. A discrezione dell’Ente, potrà essere liquidata la quota parte di servizi che abbia superato la verifica positiva.

Successivamente a tale termine saranno applicate le penali di cui al succ.vo cap. 14.

Considerata la complessità dell’Applicazione in esame, è possibile che alcune funzioni o loro parti sfuggano alle verifiche sperimentali di cui sopra ma tali omissioni, anche se avvenute con il consenso o per scelta dell'Amministrazione, non potranno in nessun caso essere addotte dalla Ditta aggiudicataria per giustificare un imperfetto funzionamento scoperto a posteriori, rientrando anche in questo caso negli obblighi di fornitura.

Ciascuna parte della fornitura nonché la realizzazione globale si intendono accettate solo dopo l' esito positivo dei collaudi e delle verifiche corrispondenti.

13. Modalità di pagamento

Il pagamento in favore della Ditta aggiudicataria sarà effettuato secondo le norme di legge in vigore.


56

La Ditta dovrà indicare nelle fatture le modalità di pagamento e riportare gli estremi del contratto e della determinazione dirigenziale che impegna la spesa, che sarà tempestivamente comunicata dall'Ente al Fornitore.

Le fatture dovranno specificamente indicare le due tipologie di intervento (tecnologico e organizzativo); il corrispettivo verrà erogato con le modalità di seguito indicate:

•20 % dell'importo a seguito dell’approvazione del PI definitivo; • il restante 80% a seguito del superamento del collaudo di cui al precedente par. 12.2.

L'Amministrazione provvederà al pagamento della fornitura al netto di eventuali penali che dovessero essere comminate, entro 90 (novanta) giorni dalla data della fattura.

14. Penali

Le penali sono applicabili per mancato rispetto delle condizioni di erogazione dei servizi e fornitura di beni previste nel presente capitolato, accertate dall’Ente a seguito delle attività di test, verifica e collaudo di cui al precedente cap. 12.

Tali condizioni possono riferirsi a mancato svolgimento delle attività, ritardo nella loro esecuzione o mancato raggiungimento degli obiettivi di qualità. Per mancato svolgimento delle attività o ritardo nella loro esecuzione si intendono quelli non giustificati e non sanati con sospensioni o proroghe accordate dal Comune ed esclusivamente imputabili a cause dovute alla Ditta aggiudicataria o da essa provocate.

Il Fornitore prende atto che il Comune applicherà le penali di seguito riportate:

1. Per ogni giorno lavorativo di ritardo rispetto ai termini di recepimento delle osservazioni/modifiche di cui al par. 8.1 è stabilita una penale di € 250.

2. Per ogni giorno lavorativo di ritardo rispetto ad ogni attività prevista nel PI o alle attività di cui ai parr. 8.2 e 8.3 è stabilita una penale di € 75.

3. Per ogni giorno lavorativo di ritardo rispetto alle attività di manutenzione migliorativa, di cui al par. 8.7, è stabilita una penale di € 50.

4. Per ogni giorno/persona di mancata prestazione rispetto alle calendarizzazioni previste delle attività di assistenza all'avviamento del sistema, di cui al par. 8.5, è stabilita una penale di € 75.

5. Per ogni giorno lavorativo di ritardo rispetto a quanto previsto al cap. 12 per test, verifiche e collaudo è stabilita una penale di € 500.

6. Qualora i servizi di formazione degli utenti di cui al par. 8.4, quelli di assistenza all'avviamento del sistema, di cui al par. 8.5 e quelli di assistenza funzionale agli utenti, di cui al par. 8.6, non siano erogati secondo i livelli di qualità previsti e concordati, il Comune invierà una prima lettera formale di richiamo alla Ditta con l’indicazione delle carenze rilevate. Qualora si verificassero successivamente ulteriori problemi di qualità, il Comune potrà inviare una seconda lettera di richiamo ed applicare una penale di € 150 per ogni episodio contestato. Al perdurare dei problemi l’Ente potrà continuare ad applicare penali secondo le modalità sopra specificate.

15. Subappalto

Il subappalto è ammesso nei limiti e con le modalità di cui all’art. 118 del D.Lgs. 163/2006. Si precisa che, ai sensi dell'art. 118, comma 3, del D.L.g.s.163/06, il Comune non provvederà a corrispondere direttamente al subappaltatore o al cottimista l'importo dei lavori dagli stessi eseguiti. Pertanto il Fornitore aggiudicatario è obbligato a trasmettere, entro 20 gg. dalla data di ciascun pagamento effettuato nei confronti dei subappaltatori o cottimisti, copia delle fatture


57

quietanzate relative ai pagamenti da esso aggiudicatario via via corrisposti, con l'indicazione delle ritenute di garanzia effettuate.

16. Diritti di proprietà

Tutto ciò che sarà prodotto ad hoc nell'esecuzione delle attività contrattuali (analisi di dettaglio, applicazioni, codici sorgente, documentazione, ecc.) sarà di esclusiva proprietà dell’Ente che, in base alle vigenti norme di legge, potrà avvalersi della facoltà di riutilizzare completamente o in parte quanto prodotto. Tale materiale dovrà essere consegnato dalla Ditta aggiudicataria al Comune, su richiesta di quest'ultimo, anche prima della scadenza del contratto.

Tutti i dati gestiti dal Sistema sono, in ogni caso, di esclusiva proprietà del Comune.

17. Trattamento dei dati personali e sensibili

Per la presentazione dell'offerta, nonché per la stipula del contratto con la Ditta aggiudicataria, è richiesto alle Ditte concorrenti di fornire dati e informazioni, anche sotto forma documentale, che rientrano nell'ambito di applicazione del D.Lgs. 196/2003.

Le Parti si obbligano, per quanto di rispettiva competenza, ad effettuare il trattamento dei dati personali dei quali entreranno in possesso nella piena e totale osservanza di quanto disposto dal Codice in materia di protezione dei dati personali, approvato con D.Lgs. 30.6.2003, n° 196 e successive modificazioni ed integrazioni, con particolare riguardo al trattamento dei dati personali che verranno forniti dall’Ente al Fornitore. Si intendono qui espressamente richiamate ed applicate tutte le disposizioni in materia dettate dal menzionato D.Lgs. 196/2003 e successive modificazioni ed integrazioni.

18. Garanzia fideiussoria ed oneri fiscali

Il Fornitore dovrà versare una garanzia fideiussoria (o cauzione definitiva) pari al 10% (dieci per cento) dell’importo contrattuale. In caso di aggiudicazione con ribasso d’asta superiore al 10% la garanzia fideiussoria è aumentata di tanti punti percentuali quanti sono quelli eccedenti il 10%; ove il ribasso sia superiore al 20%, l’aumento è di 2 punti percentuali per ogni punto di ribasso superiore al 20%.

La garanzia fideiussoria è da costituirsi fideiussione bancaria o assicurativa, a garanzia delle obbligazioni contrattuali assunte.

Essa dovrà contenere l’espressa rinuncia al beneficio della preventiva escussione del debitore principale e l’obbligo a liquidare la somma garantita su semplice richiesta scritta dell’Amministrazione appaltante entro il termine di 15 giorni dalla richiesta medesima.

La garanzia fideiussoria sarà svincolata e quindi restituita al Fornitore al termine del periodo di garanzia, previa verifica dell’esatta e corretta esecuzione di tutte le obbligazioni contrattuali.

Gli oneri fiscali conseguenti all’aggiudicazione, registrazione e diritti di segreteria sono a completo carico del Fornitore, ad eccezione dell’IVA che è a carico dell’Ente.

19. Foro competente

In caso di controversia riguardante la fornitura, in prima istanza verrà ricercata una composizione amichevole tra le Parti.


58

Se il tentativo non dovesse aver successo, sarà incaricato un collegio arbitrale composto da tre membri, di cui uno nominato dall’Ente, uno dal Fornitore e il terzo d’accordo fra le parti o, in mancanza di accordo, dal Presidente del Tribunale di Firenze.

Il Foro competente è quello di Firenze.

Comune di Firenze Direzione Risorse Finanziarie/Direzione ... · o Sistema Informativo Territoriale...

Documents

Transcript of Comune di Firenze Direzione Risorse Finanziarie/Direzione ... · o Sistema Informativo Territoriale...