CAPITOLATO SPECIALE D'APPALTO PER LA FORNITURA DI UN SISTEMA INFORMATICO DI GESTIONE IMPOSTA di SOGGIORNO

Transcript

1 CAPITOLATO SPECIALE D'APPALTO PER LA FORNITURA DI UN SISTEMA INFORMATICO DI GESTIONE IMPOSTA di SOGGIORNO 1

2 ART. 1: OGGETTO DELLA FORNITURA L oggetto della fornitura consiste nella realizzazione di un sistema informatico per la gestione dell imposta di soggiorno. Le componenti della fornitura sono: - Licenza d uso illimitata nel tempo, per un numero di utenti illimitati e per postazioni di accesso illimitate, di tutte le componenti del Sistema informatico di cui al presente C.S.A., - Attività di installazione e configurazione del Sistema informatico, - Attività di analisi, configurazione e parametrizzazione del Sistema informatico secondo il regolamento relativo all applicazione dell imposta di soggiorno presso il comune di Padova, - Attività di migrazione dati da archivi su base Excel attualmente in uso presso l ente; - Documentazione del software fornito (comprensiva di manuale di amministrazione, manuale utente, funzionalità di help in linea), - Documentazione analitica della Base Dati: rappresentazione dello schema concettuale secondo il modello Entità/Relazioni e rappresentazione dello schema logico secondo il modello relazionale (da consegnarsi in sede di collaudo), - Documentazione analitica di carattere sistemistico relativa agli script di avvio e chiusura dei servizi, ai processi da monitorare, ecc (da consegnarsi almeno 10 giorni prima della data concordata per la messa in esercizio del Sistema informatico), - Attività di addestramento all uso della procedura, - Attività di avviamento della procedura, - Attività relative ai collaudi; - Servizio di assistenza e manutenzione della durata di 3 anni dalla data di collaudo del Sistema. La fornitura è suddivisa in 2 lotti: - il lotto A verrà commissionato alla conclusione del procedimento di gara, - il lotto B verrà commissionato successivamente, entro il termine massimo di 12 mesi dalla data del primo ordine, salvo il diritto di recesso di cui all art. 16. ART. 2: DEFINIZIONI ED ACRONIMI UTILIZZATI NEL CAPITOLATO F.O. B.O. RAC I.M. SSO Check-in Check-out Albergatore Front Office, in questo contesto Portale Registro Presenze per albergatori Back Office, in questo contesto Sistema di gestione Imposta di Soggiorno per Ufficio Tributi dell Ente Real Application Cluster Identity Management modulo centrale per la gestione della Registrazione, Autenticazione e il SSO dei portali del Comune di Padova Single Sign-On Arrivo ospiti presso la struttura alberghiera Partenza ospiti dalla struttura alberghiera Usato in senso lato per intendere l operatore/gestore di struttura ricettiva ART. 3: OBIETTIVI DELLA FORNITURA Il sistema informatico dovrà comprendere due componenti - Una di front office, denominata Portale delle Presenze rivolta alla collettività degli alberghi, ostelli, bed&breakfast etc. per la presentazione on-line delle dichiarazioni - Una di back office di supporto all ufficio del Comune per le verifiche e le attività di contabilità. La fornitura è suddivisa in due lotti: 2

3 il lotto A comprendente le funzionalità principali sia della componente di Front Office che di quella di Back Office il lotto B riguardante alcune funzionalità di integrazione verso altri sistemi informatici in uso presso il Comune di Padova ART. 4: IL CONTESTO ATTUALE DEL COMUNE DI PADOVA 4.1 Informazioni generali A seguito dell art. 4 del Decreto Legislativo , n. 23 Disposizioni in materia di federalismo fiscale municipale il Comune di Padova ha introdotto un imposta di soggiorno a carico di coloro che alloggiano nelle strutture ricettive del territorio comunale. Con deliberazione G.C. si definisce l obbligo per i gestori di tali strutture di fare una dichiarazione trimestrale delle presenze, suddivisa per misura d imposta e di provvedere al versamento dell imposta dovuta (di seguito dovuto ) entro 15 giorni dalla scadenza del trimestre solare. Per la corretta applicazione dell imposta, è prevista da parte del Comune un attività di accertamento, e conseguentemente l applicazione di eventuali sanzioni pecuniarie o eventualmente di rimborsi in caso di pagamenti superiori al dovuto nonché, in caso di evasione, la messa a ruolo coattivo dei dovuti. Qualunque informazione di carattere normativo è disponibile sul sito del Comune di Padova all indirizzo Il contesto attuale dell ufficio Imposta di Soggiorno Il settore Tributi ha avviato un attività di censimento delle strutture ricettive, nonché la loro catalogazione in base alla disciplina regionale (T.U. delle leggi regionali del turismo 04 novembre 2002 n. 33) al fine di poter assegnare ad ogni struttura le imposte unitarie. Le strutture ricettive sono in tutto circa 260 (255) così articolate Strutture ricettive alberghiere 4 stelle 17 3 stelle 23 2 stelle 8 1 stella 6 Strutture ricettive extra-alberghiere Attività ricettive in esercizi di ristorazione 1 Residence 4 Unità abitative ad uso turistico 58 Bed&breakfast 113 Affittacamere 8 Case religiose e case per ferie Foresterie 2 Attività agrituristiche Attività agrituristiche 2 Le dichiarazioni vengono inviate trimestralmente via fax e i controlli sono eseguiti manualmente. Il pagamento dell imposta avviene con le seguenti modalità: - Presso la Tesoreria Comunale in Cassa di Risparmio - A mezzo bonifico bancario presso qualsiasi banca - A mezzo bonifico bancario su conto corrente postale 3

4 4.3 Le caratteristiche minime delle postazioni di lavoro amministrative Presso il Comune di Padova le postazioni di lavoro hanno le seguenti caratteristiche: Processore: Intel, Pentium IV 2.4 Ghz, AMD Athlon XP 2.4 Ghz RAM: 512 Mb H.D.: 40Gb Sistema Operativo: Windows Xp Professional Browser Internet: Microsoft Internet Explorer 6.0 e Mozilla Firefox 10.0 Protocollo di rete: TCP/IP Oppure Processore: Intel, Pentium IV 2.4 Ghz, AMD Athlon XP 2.4 Ghz RAM: 512 Mb H.D.: 40Gb Sistema Operativo: Linux Ubuntu o sup. con Boot da rete tramite RDP Browser Internet: Mozilla Firefox 10.0 o sup. Protocollo di rete: TCP/IP ART. 5: CARATTERISTICHE E REQUISITI TECNICI RICHIESTI 5.1 Le caratteristiche del software L applicazione deve essere progettata e realizzata in architettura web-oriented a tre livelli e deve essere compatibile con entrambi i browser Internet Explorer e Mozilla Firefox. Le caratteristiche dell architettura software distribuita devono tener conto della: - modularità: l applicativo proposto deve essere strutturato in moduli integrabili tra loro (senza duplicazione di movimenti o inserimento dati) e attivabili in tempi diversi; - sicurezza dei dati; - facilità d uso; - semplicità e completezza di gestione; - tempi di risposta della procedura consoni all utilizzo specifico senza rallentamenti all operatività; - scalabilità. Il sistema non deve essere costituito da un insieme di applicazioni aventi caratteristiche sistemistiche e ambienti di sviluppo diversi tra loro. Il sistema deve prevedere l utilizzo di client che sfruttano le funzioni base del browser senza richiedere l installazione di particolari componenti aggiuntive. L interfaccia grafica proposta deve essere ricca e user friendly. La rappresentazione delle informazioni dovrà seguire la logica di gestione operativa vicina all Utente del Sistema informatico. L interfaccia grafica utente dovrà disporre di menù capaci di guidare l operatore nella scelta delle funzioni previste con l ausilio del mouse e di oggetti grafici. Sarà valutata favorevolmente la presenza di documentazione utente chiara ed esaustiva, funzionalità a video corredate da idonei e contestuali help on line e messaggi di errore di facile comprensione per l utente. In questo caso sia l help on line che la messaggistica dovranno essere in lingua italiana. I menù, le finestre di dialogo, i messaggi, le convenzioni d uso dovranno essere utilizzati in modo uniforme e omogeneo in tutta l applicazione. L applicativo si compone di due applicazioni distinte, quella di front office rivolta agli albergatori, e quella di back office di supporto al settore Tributi. Le due componenti sono strettamente unite e la parte di gestione imposta di back office è requisito essenziale al funzionamento della componente Portale delle Presenze di front-office. La componenete di Front-Office sarà in un secondo momento integrata al Prodotto di Identity Management in uso presso l ente e che si basa su protocollo SAML.2. 4

5 5.2 L ambiente tecnologico di riferimento Il Sistema dovrà essere configurato secondo le seguenti specifiche: Data Base Server del Comune di Padova: Sistema Operativo: distribuzione SUSE Linux Enterprise Server (vers. 10 SP3 o superiori) Database Server: Oracle (vers. 11g o superiori) Web/Application Server del Comune di Padova: Sistema Operativo: distribuzione Debian (vers. 4.0 o superiori) con pacchettizzazione standard: - Web Server: Apache (vers. 2.2 o superiori) - Application Server: Tomcat (vers. 6.0 o superiori) La componente Application e Web dell applicazione potrebbe essere installata su un ambiente contenente altre applicazioni gestionali. La Ditta dovrà indicare la strategia di installazione al fine di garantire la convivenza dei diversi applicativi. Inoltre gli Application e i Web Server saranno macchine virtuali compatibili con entrambe le piattaforme di virtualizzazione sottoelencate: -VSPHERE 4.1 o sup. e -Proxmox Virtual Environment 1.9 o superiori. Clients: Sistema Operativo: Windows. Per la produttività individuale deve essere previsto l impiego di LibreOffice per Windows, version 3.5.4, Italiano o superiori. Preferibilmente l applicazione deve utilizzare la tecnologia applicativa conforme allo standard Servlet/JSP, ossia basarsi sulle tecnologie servlets, jsp e java bean, prevedere servizi di accesso a protocolli standard (https), database relazionali Oracle (JDBC), posta elettronica (java Mail). Possibilmente la componente back office deve essere integrabile con i servizi di LDAP per l autenticazione degli utenti intranet. 5.3 La Base Dati La gestione dei dati deve avvenire con un data base relazionale sviluppato e configurato al fine di garantire l integrità e la transazione. Il DBMS per il Comune di Padova è Oracle (vers. 11g o superiori) in configurazione Real Application Cluster (RAC). Il Sistema deve gestire l accesso multiente e concorrente ai dati condivisi. Gli utenti applicativi dovranno risultare collegati al Database con un utente Oracle che non sia il proprietario dello schema. Il Sistema proposto dovrà inoltre: - disporre di funzioni atte a garantire il monitoraggio e l ottimizzazione della base dati in caso di degrado delle prestazioni; - prevedere funzioni di log che garantiscano la tracciabilità delle operazioni eseguite sui dati Si segnala che il Database dell Imposta di Soggiorno potrebbe essere collocato su un istanza contenente database relativi ad altre applicazioni gestionali. La Ditta dovrà perciò indicare se vi sono necessità particolari di configurazione che potrebbero limitare tale attività. 5.4 I servizi di rete Per quanto riguarda i servizi di rete tutte le comunicazioni dovranno avvenire tramite protocolli standard sicuri (SSL), in modo da garantire la riservatezza delle comunicazioni in ambito intranet e internet. 5

6 5.5 L ambiente di test La Ditta dovrà predisporre un ambiente di test (applicativo e database) da utilizzarsi in fase di impianto, addestramento e prova di nuove funzionalità pre-avviamento in produzione. ART. 6: REQUISITI HARDWARE E SOFTWARE D AMBIENTE La Ditta dovrà indicare, sulla base della piattaforma specificata all art. 5.2 L ambiente tecnologico di riferimento, le risorse minime necessarie sia lato server che client (RAM, Processori, occupazione spazio, banda di rete minima richiesta/utente) nonché tutte le componenti software integrative al browser specificandone il nome e le funzionalità per cui vengono installate. ART. 7: CARATTERISTICHE GENERALI E FUNZIONALITA APPLICATIVE 7.1 Le caratteristiche generali L applicazione in realtà è costituita da due componenti, una di F.O. rivolta agli albergatori che deve svolgere funzioni di registro presenze, presentazione dichiarazioni e notifica pagamento imposta. Una seconda componente di B.O. è invece a supporto dell operatività dell ufficio Imposta di Soggiorno del settore Tributi. La prima verrà chiamata Modulo di Front Office e la seconda modulo di Back Office. 7.2 Modulo di Front Office Questa componente deve fornire all utente tutte le funzionalità sotto descritte ma le operazioni di autenticazione e registrazione sono gestite dapprima in modalità verticale e successivamente integrate con il sistema di Identity Management dell Ente. Pertanto si definiscono 2 lotti della fornitura e precisamente: LOTTO A versione non integrata con il prodotto di Identity Management. La componente Portale delle Presenze di Front Office è completo delle funzioni di Identity Management, cioè comprende le funzionalità utili a inserire e gestire utenti e la loro profilazione, in particolare deve supportare una profilazione atta a distinguere le funzionalità degli utenti di F.O. da quelle di B.O. e possibilmente sia un ruolo Amministratore che un ruolo Operatore a lato B.O. 6

7 Albergatore Settore Tributi Id.Management AlberghiWeb FO Id.Management Alberghi BO Inserisce l albergo le strutture e la categoria (P. IVA, codfiscale) Esegue la preregistrazione del Utente Albergo Consegna le credenziali all albergatore L Utente Albergo completa la registrazione inserendo i dati del profilo Esegue registro presenze o dichiarazioni Notifica pagamenti Gestione dichiarazioni e controllo 7

8 LOTTO B versione integrata con Identity Management del Comune di Padova Questo secondo lotto deve operare in modalità integrata con i portali dei Servizi del Comune di Padova pubblicati. Il modulo di F.O. dovrà integrarsi con l architettura di Identity Management (I.M.) in uso presso il Comune di Padova e ne dovrà utilizzare lo stesso foglio di stile per coerenza grafica. In questa architettura l applicazione deve ereditare dal sistema di I.M. le credenziali dell utente e il suo profilo. Il prodotto di Identity Management sarà basato sul protocollo SAML 2.x e si devono prevedere le tecnologie opportune per l integrazione atta a garantire l operatività in SSO con gli altri Portali dei Servizi. Si fornirà tutta la documentazione necessaria alla ditta aggiudicataria. L adeguamento del modulo di F.O. all interfacciamento con l I.M. esterno deve essere quotato con una voce distinta nell offerta in quanto la realizzazione avverrà successivamente: si stima entro un anno a partire dal completamento del Lotto A. Identity Management Registrazione Autenticazione Profilo Master EgovPadova (PayWeb) SSO Imposta Soggiorno (Front Office) Profilo Locale Profilo Locale 8

9 Albergatore Settore Tributi Id.Management AlberghiWeb FO Id.Management Alberghi BO Esegue la preregistrazione del Utente Albergo Consegna le credenziali all albergatore Inserisce l albergo le strutture e la categoria (P. IVA, codfiscale) Completa la registrazione e gestisce i dati del profilo L utente di tipo ALBERGO accede all applicazione Imposta Soggiorno autenticandosi su I.M. Dichiarazione Verifica della presenza della P.IVA/codfisc Recupero categoria della struttura Memorizzazione della dichiarazione Dalla Dichiarazione Esegue il calcolo Notifica pagamento Memorizzazione del pagamento dai vari canali L utente interroga l elenco delle dichiarazioni e quello dei pagamenti di Soggiorno 9

10 7.2.1 Dichiarazione Presenze manuale L utente operando in qualità di rappresentante dell albergo è identificato tramite la partita iva o il codice fiscale; l applicazione interroga le anagrafiche di db di back office ed elenca le strutture ad esso collegate; selezionata una struttura l applicativo permette l inserimento delle presenze suddivise per categoria. L utente può compilare direttamente la dichiarazione inserendo ospiti e presenze dei mesi relativi alla dichiarazione in oggetto. La dichiarazione deve prevedere la possibilità di inserimento sia del numero di ospiti che il numero delle presenze (ossia pernottamenti) per singolo mese, ma accorpare poi i dati a trimestre coerentemente con il modello della dichiarazione pubblicato sul sito dell ente all indirizzo: modulo C) Si deve prevedere la possibilità di invio di dichiarazione nel caso di 0 presenze (la dichiarazione va presentata ugualmente); pertanto se non è stato inserito alcun pernottamento la maschera avvisa che il totale è 0 e chiede conferma ma permette l invio. Si devono prevedere anche le presenze da riportare dal trimestre precedente e non ancora pagate e quelle in sospeso da pagare il trimestre successivo (ospiti non ancora partiti) per permettere facoltativamente all albergatore di gestire il dovuto nel modo preferito. Contestualmente viene predisposto un pdf con i dati della dichiarazione disponibile al download e alla stampa/salvataggio da parte dell Albergatore. La dichiarazione può essere: 1. Stampata, firmata dal dichiarante in calce, scannerizzata assieme ad un documento di identificazione e poi va eseguito l invio da applicazione di F.O. 2. Dopo il download l Albergatore firma digitalmente e poi esegue l invio da applicazione di F.O. L utente deve poter salvare (stato in bozza) le informazioni per potervi riaccedere e modificarle, tornare subito alla pagina precedente per correggerle (ripresentando i dati) oppure fare invio confermandole; al momento dell invio la dichiarazione è salvata e non è più modificabile (stato inviata). Al momento dell invio, il programma deve effettuare in cooperazione applicativa una chiamata al sistema di Protocollo Informatico dell Ente in modo trasparente all utente per assegnare il numero di protocollo ed effettuare l archiviazione documentale del documento. La assegnazione del numero di protocollo sfrutterà il servizio pubblicato dall applicazione P@DOC in uso presso il Comune di Padova. La funzione di invio redige dopo l inserimento della pratica nel gestionale stesso una segnatura in formato XML con i dati relativi al titolario, la classificazione e l ufficio destinatario. Detta segnatura in formato XML viene inoltrata, al sistema di protocollo secondo le modalità della tecnologia di comunicazione basata sugli standard denominati Web Services (nello specifico XMLRPC). La chiamata si conclude con la restituzione del numero di protocollo che deve essere salvato sulla dichiarazione. L Albergatore deve ricevere un messaggio di di conferma di ricevuta in modo automatizzato contenente il numero di protocollo. E disponibile a richiesta delle ditte partecipanti la documentazione relativa alla ws di interoperabilità con il Protocollo Informatico Dichiarazione da registro presenze. Si intende agevolare le strutture ricettive di dimensioni minori, non dotate di prodotti software per la gestione delle presenze, mettendo a disposizione su questo portale funzionalità per registrare i check-in e check-out e per produrre poi, in alternativa alla funzione del punto 7.2.1, la dichiarazione presenze periodica automaticamente. 10

11 La maschera di inserimento Dichiarazione deve dare la possibilità di generare la dichiarazione in modalità automatica a partire dal Registro Presenze; indicata la rata, il programma esegue il calcolo delle presenze per il periodo indicato. L estrazione lavora per data di partenza, in modo da tenere conto solo di coloro che sono partiti nel periodo esaminato e, se vi era un certo dovuto da riportare alla rata successiva nell ultima dichiarazione inviata, questo dovuto viene riportato automaticamente sulla rata attuale. Vanno conteggiati anche gli ospiti e i pernottamenti effettuati durante la rata precedente, ma corrisposti in questo periodo, nonché quelli pendenti corrispondenti ad ospiti presenti ma non ancora partiti. Questi ultimi non devono concorrere al totale da pagare. Viene presentata a video una dichiarazione compilata automaticamente che non può essere modificata se non attraverso la correzione del registro presenze. L utente può proseguire poi come già descritto nel punto precedente con la generazione del pdf e l operatività preferita, fra firma in calce o firma digitale e invio tramite upload e generazione della segnatura XML per il richiamo della WS verso il Protocollo Informatico. Al momento dell invio le presenze coinvolte nella dichiarazione vengono bloccate e l utente non può più modificarle Elenco dichiarazioni presentate Tale funzione deve esporre l elenco delle dichiarazioni presentate on line dalla struttura alberghiera. Va anche prevista la paginazione al crescere del numero di dichiarazioni. Si deve potere accedere alle informazioni di dettaglio e procedere alla visualizzazione del PDF Registro presenze Si intende predisporre a portale un servizio di supporto all albergatore che lo sostenga nella registrazione delle presenze affinché possa produrre in automatico e in modo quindi molto semplificato e veloce la dichiarazione trimestrale. L inserimento deve avvenire giorno per giorno, e secondo la filosofia vigente presso gli alberghi permettere l inserimento del numero di chek-in, check-out, e presenze. Ogni arrivo e ogni partenza devono computare automaticamente le presenze per dare sempre l informazione sia dei pernottamenti che del numero degli ospiti mensili. Tali informazioni devono essere modificabili fintanto che non vengono utilizzate per l invio della dichiarazione trimestrale in cui vanno conteggiate Riepilogo registro presenze Deve essere possibile effettuare l estrazione di un riepilogo delle presenze per un periodo a scelta e con filtro ad esempio per tipologie di strutture (es: alberghi a quattro stelle); a partire quindi da una data inizio e una data fine viene predisposto un elenco che può essere estratto in formato pdf oppure csv. Deve riportare il numero degli arrivi, delle partenze, presenze, presenze per più di 5 giorni, esenti delle varie tipologie e numero di ospiti che si sono rifiutati di pagare l imposta completo di totali e subtotali per finalità di tipo statistico. 11

12 7.2.6 Notifica pagamento imposta di soggiorno La funzione presenta le dichiarazioni on line da pagare (stato inviata) e le elenca offrendo la possibilità di procedere con la registrazione dei dati del pagamento effettuato relativo ad ognuna. Selezionata la dichiarazione, si emette una maschera con i dati riassuntivi dei totali da pagare ossia relativi alle presenze inferiori ai 5 giorni. L Albergatore può inserire data e importo di pagamento e canale di pagamento nonché identificativo. Nel caso di pagamento in Tesoreria deve poter inserire il n. quietanza, in caso di bonifico il CRO. Ad oggi i gestori delle strutture ricettive non sono stati riconosciuti sostituti d imposta e pertanto il comune non può applicare né ravvedimento operoso né sanzioni per mancato/ritardato pagamento. Non potendo però escludere che in futuro vi siano modifiche normative in tal senso, sarà considerata positivamente la presenza di una funzione opzionale di conteggio del ravvedimento operoso per il computo del dovuto se superati i termini. In questo caso si riportano le modalità del computo del dovuto e del ravvedimento operoso. Il dovuto va corrisposto entro i primi 15 giorni successivi alla scadenza di fine trimestre; il calcolo è un semplice prodotto dell imposta base per il numero delle presenze. Il ravvedimento si paga se la data è superiore al 15esimo giorno dopo la scadenza con le modalità previste dalla legge Riepilogo notifiche pagamenti L Albergatore deve poter interrogare le notifiche di pagamento inserite Riepilogo pagamenti L Albergatore deve poter interrogare gli eventuali pagamenti inseriti da Back Office Caricamento massivo presenze da Portale di Front Office. Costituirà punteggio aggiuntivo la possibilità per le strutture alberghiere di sottoporre al sistema di F.O. dei flussi presenze che vadano ad alimentare in maniera massiva il Registro Presenze provenienti dai software in uso presso le strutture alberghiere Caricamento dichiarazioni di omesso versamento. Costituirà punteggio aggiuntivo la possibilità per le strutture alberghiere di sottoporre al sistema di F.O. le dichiarazioni degli ospiti che si rifiutano di pagare l imposta con relativo upload del documento e invio con protocollazione informatica predisponendo la segnatura XML e il richiamo al servizio del Protocollo Informatico. 7.3 Modulo di Back Office Il modulo di Back Office si può distinguere in 3 componenti : Gestione dell Imposta Gestione dei Controlli Gestione Iter Provvedimenti 12

13 Tale modulo si scompone nei due lotti di fornitura con questa logica: LOTTO A Gestione Imposta Gestione controlli Gestione Iter Provvedimenti LOTTO B Interrogazione Fascicolo di Protocollo e Documentale Gestione Imposta Questa componente è necessaria per avviare il modulo di Front Office Gestione anagrafiche Si deve gestire l anagrafica delle strutture ricettive sia in quanto persone giuridiche (alberghi, bed&breakfast) ma anche fisiche (agriturismi e affittacamere); l operatività deve essere completa sia per l inserimento, che la modifica e la cancellazione logica. Oltre alla ragione sociale/denominazione deve essere prevista la registrazione del nome commerciale. Deve comprendere la gestione degli indirizzi e dei rappresentanti legali garantendo la storicità dell informazione. Per l indirizzo va previsto sia il tipo sede legale che sede operativa. Per la consultazione delle anagrafiche presenti, deve essere possibile effettuare una ricerca impostando anche parzialmente i seguenti campi: Codice Partita iva Codice fiscale Denominazione/ragione sociale/nome commerciale Indirizzo Rappresentante legale La ricerca sul campo denominazione deve essere di tipo like; il programma estrae le anagrafiche che soddisfano la condizione per procedere poi alla gestione puntuale dell anagrafica cercata Gestione strutture Ad ogni anagrafica deve corrispondere almeno una struttura ricettiva, ma deve essere possibile anche gestire una molteplicità maggiore. La funzione parte dalla selezione dell anagrafica e poi ad essa aggancia una o più occorrenze della struttura ricettiva. Infatti in città vi sono alberghi e attività extra-alberghiere con più strutture ricettive e anche di classificazione diversa. Prevedere anche l indirizzo . Si deve poter storicizzare le strutture (data fine attività e stato). Si deve prevedere la possibilità di ricercare la struttura per Codice Partita iva Codice fiscale Denominazione struttura Indirizzo Rappresentante legale 13

14 Gestione tipo struttura (tabelle di servizio) Il programma deve permettere all operatore di B.O. la gestione delle classificazioni delle strutture suddividendole in strutture alberghiere (a 4, 3, 2, 1 stella), strutture extraalberghiere (attività ricettive, residence, ), agriturismi Gestione categorie, esenzioni, rate e interessi legali (tabelle di servizio) Deve essere possibile per l operatore dell ufficio intervenire in modifica o creazione delle categorie, delle tariffe, delle esenzioni, delle rateizzazioni e delle scadenze. Questo implica che il programma deve essere parametrico e che le tabelle di appoggio di questi parametri devono essere modificabili da maschera. Inoltre questi parametri devono prevedere storicizzazione: tramite l uso di date inizio e date fine il programma deve poter gestire in automatico cambiamenti di applicazione dell imposta. Il calcolo deve essere impostato tenendo come unità minima il mese: infatti per mantenere l elasticità sulle variazioni di tariffa deve essere possibile gestire il caso limite di tariffe diverse ad ogni mese e viceversa nel caso più semplice una sola identica tariffa tutto l anno (possibilità di alta e bassa stagione) Gestione sanzioni (tabelle di servizio) Sono previste sanzioni sia per la mancata/infedele presentazione trimestrale della dichiarazione presenze, sia per il mancato o ritardato pagamento. Non essendo gli albergatori sostituti d imposta le uniche sanzioni che si possono applicare sono ad oggi quelle per ritardata o mancata dichiarazione. Come già scritto sarà però valutata positivamente la presenza delle funzioni per l applicazione opzionale della sanzione anche su i mancati o ritardati versamenti. Per l omessa, incompleta o infedele dichiarazione alla scadenza trimestrale, si applica una sanzione da 25 a 500 Euro Per l omesso, ritardato o parziale versamento si prevede una sanzione pari al 30% dell importo non versato. Per l omesso, ritardato o parziale versamento va distinta la sanzione dal ravvedimento operoso. La sanzione (calcolo ad opera dell ufficio) è pari al 30% dell importo dovuto. In caso di ravvedimento operoso (calcolo e pagamento spontaneo dell Albergatore) vanno applicate le modalità previste dalla legge. Anche la tabella delle sanzioni deve essere modificabile a maschera e prevedere la storicizzazione dei cambiamenti. Un eventuale calcolo automatico della sanzione deve tener conto del periodo di validità del regime sanzionatorio e modificarne il computo di conseguenza Gestione dichiarazioni Va predisposta una maschera di ricerca di tipo parametrico delle dichiarazioni trimestrali; si possono selezionare a partire dai seguenti campi di ricerca opzionali Ragione sociale o denominazione per cognome nome o nome commerciale Partita IVA e codice fiscale Anno e rata Tipologia di struttura indirizzo 14

15 Prevedendo di ricevere dichiarazioni cartacee, oltre che on line da modulo di Front Office, il programma di back office deve poter inserire la dichiarazione (oltre che modificarla, o annullarla). La cancellazione è logica ed è basata sulla data fine che se impostata cambia lo stato della dichiarazione. Si deve prevedere un attributo che identifichi le dichiarazioni d ufficio da quelle presentate dall Albergatore. In caso di rettifica si deve poter annullare la dichiarazione e inserirne una nuova che evidenzi la sua natura di dichiarazione in rettifica. La gestione della dichiarazione deve comprendere la presenza del numero di protocollo Gestione dovuti Il programma deve garantire il calcolo del dovuto a fronte delle dichiarazioni inserite. Tale calcolo deve tener conto delle presenze dichiarate e delle tariffe ed esenzioni in vigore nel periodo calcolato. Deve permettere l inserimento/modifica di sanzioni e interessi per omesse/infedeli dichiarazioni o in caso di ritardata presentazione della dichiarazione o del ritardato pagamento. A ultimazione della 3^ fase di sviluppo del modulo di back office (Gestione Iter provvedimenti) questi importi di sanzione e interessi saranno calcolati automaticamente dalla funzione di Controllo Posizione Contabile, nella prima fase possono essere forzati a mano Gestione pagamenti Va predisposta una maschera di ricerca dei pagamenti pervenuti; si possono selezionare a partire dai seguenti campi di ricerca opzionali anagrafica (denominazione o partita iva o codice fiscale o nome commerciale) anno e rata periodo di pagamento tipologia di struttura indirizzo importo I campi possono essere valorizzati tutti o solo alcuni, e la ricerca sulla denominazione deve essere di tipo like. Il programma predispone un elenco dei pagamenti per poi dare la possibilità di vedere il dettaglio della riga di pagamento; si deve poter modificare o cancellare logicamente il singolo pagamento, ma anche permettere l inserimento da parte dell operatore dell ufficio. All inserimento/variazione del pagamento deve essere aggiornata la posizione contabile Gestione notifiche di pagamento Va predisposta una maschera di ricerca delle notifiche di pagamento pervenute; si possono selezionare a partire dai seguenti campi di ricerca opzionali anagrafica (denominazione o partita iva o codice fiscale o nome commerciale) anno e rata periodo di pagamento tipologia di struttura 15

16 Gestione dichiarazione di omesso pagamento Va predisposta una maschera di ricerca delle dichiarazioni di omesso pagamento pervenute; si possono selezionare a partire dai seguenti campi di ricerca opzionali anagrafica (denominazione o partita iva o codice fiscale o nome commerciale ) anno e rata periodo di pagamento tipologia di struttura Gestione controlli Posizione contabile Alla scadenza della rata, ad ogni anagrafica deve corrispondere la sua posizione contabile che deve essere rigenerata ad ogni nuova rata. La posizione contabile deve riportare il dovuto netto, l importo di eventuale ravvedimento operoso, sanzioni, interessi, il totale pagato e l eventuale differenza a debito oppure a credito e quindi a compensazione su futuri pagamenti. Sarebbe ottimale mantenere registrata l evoluzione rata per rata in modo da poter effettuare più velocemente l analisi della posizione Controllo dichiarazioni Per l omessa, incompleta o infedele dichiarazione alle prescritte scadenze si applica una sanzione. Bisogna predisporre un elenco degli Alberghi che non hanno presentato la dichiarazione, o l hanno presentata in ritardo. Per l infedeltà le inesattezze potrebbero riguardare o le presenze o la classificazione. L estrazione si fa su rata specificata dall operatore e si deve poter estrarre o solo le dichiarazioni mancanti oppure solo quelle presentate in ritardo. La funzione estrae un elenco a video con possibilità di girarlo su file in formato foglio di calcolo Controllo pagamenti Il sistema fornirà elenchi dei pagamenti omessi, ritardati e parziali. L estrazione si fa per rata e viene emesso un elenco a video con possibilità di girarlo su file in formato foglio di calcolo. Si deve poter estrarre un elenco dei pagamenti che non si sono agganciati ad una posizione contabile e quindi non ad una anagrafica per poter procedere con la correzione del pagamento o la verifica dell anagrafica. In particolare questa funzione serve alla sistemazione degli scarti dei pagamenti recepiti tramite le funzioni di interscambio massivo delle funzioni e L elenco dovrebbe essere predisposto sulla base di un filtro flessibile impostabile dall operatore e per periodo classificazione struttura categorie scarti (si/no) e riportare anche le statistiche per le varie esenzioni. 16

17 Interscambio massivo pagamenti su canale ATM E previsto l interscambio di flussi con la Banca di Tesoreria per fornire i dovuti da pagare su ATM e la ricezione dei pagamenti effettuati su tale canale per il conseguente aggiornamento della banca dati. I movimenti devono avere un identificativo univoco secondo un certo standard che verrà restituito dalla banca per permettere la riconciliazione automatica dei pagamenti. Il tracciato e le informazioni verranno fornite alla ditta aggiudicataria. A fronte di errore nella riconciliazione dei pagamenti di ritorno deve essere prodotto un elenco scarti per l ulteriore bonifica e aggancio manuale da parte dell ufficio Caricamento massivo pagamenti da tesoreria Giornalmente la Tesoreria trasferisce all ufficio Entrate del Comune un flusso di rendicontazione dei pagamenti effettuati direttamente in Tesoreria. Periodicamente ritornano gli estremi dei versamenti effettuati che vanno ad aggiornare le singole posizioni. Il flusso è di tipo excel oppure txt con tracciato Prefissato. I campi previsti sono: Capitolo Giornale Sottoconto Importo Versante Causale N. operazione La causale sarà composta in modo da permettere la riconciliazione con i dovuti. A fronte dei mancati riconoscimenti della causale deve essere prodotto un elenco scarti per l ulteriore bonifica e aggancio manuale da parte dell ufficio Gestione iter provvedimenti Controllo posizione contabile La posizione contabile riporta sempre ad ogni rata la situazione riepilogativa del contribuente per quel che riguarda il dovuto e il pagato, oltre a eventuali debiti o crediti residui nei confronti dell imposta di Soggiorno. La funzione di controllo posizione contabile Verifica data presentazione dichiarazione e se la dichiarazione è assente o in ritardo aggiorna la sanzione dovuta Calcola il pagato-totale alla data tenendo conto dell importo A compensazione della posizione contabile della rata precedente Calcola il ravvedimento operoso se sul pagato la data è ritardata e l importo maggiore del dovuto e aggiorna i campi relativi a interessi, sanzioni ed effettua il controllo della correttezza del pagato Controlla la data di pagamento e se in ritardo calcola sanzione Confronta il totale da pagare con il totale pagato e aggiorna eventuale residuo a debito o a credito Aggiorna conseguentemente lo stato (ok, da accertare, ) Gli importi delle sanzioni, interessi devono essere modificabili Gestione provvedimenti 17

18 In caso di provvedimento da emettere vs nei confronti di un contribuente, dopo aver eventualmente inserito una dichiarazione d ufficio e aver effettuato il controllo della posizione contabile con relativa eventuale forzatura manuale degli importi, si procede all emissione del provvedimento. In questa prima fase si pensa ad una maschera gestita in modalità libera da parte dell ufficio con predisposizione anche fuori procedura dell avviso. Vanno solo memorizzate le informazioni necessarie a individuare l elenco delle dichiarazioni, dei versamenti interessati. Deve essere gestito un semplice iter manuale con le fasi: 1. In verifica 2. alla firma 3. inviato 4. notificato (con data notifica) 5. annullato 6. sospeso 7. a ruolo/a ingiunzione fiscale In fase di invio si deve assegnare il numero di protocollo; il sistema all invio deve effettuare in cooperazione applicativa una chiamata al sistema di Protocollo Informatico sfruttando il servizio pubblicato dall applicazione P@DOC in uso presso il Comune di Padova. A richiesta verrà fornita alla ditta aggiudicataria tutta la documentazione relativa. Costituirà punteggio aggiuntivo la presenza di ulteriori funzionalità o automatismi per la gestione dei provvedimenti Interrogazione fascicolo di Protocollo e Documentale Con la consegna del lotto B deve essere implementata la funzione di Interrogazione del Fascicolo che a partire dall anagrafica interroghi il fascicolo di protocollo per visualizzare tutti i documenti archiviati relativamente all imposta di soggiorno. L interrogazione avverrà verso la procedura di protocollo informatico P@DOC in uso presso il Comune di Padova secondo lo standard XMLRPC. A richiesta verrà fornita alla ditta aggiudicataria tutta la documentazione relativa. ART. 8: CONSEGNA, INSTALLAZIONE E MESSA IN ESERCIZIO 8.1 Consegna e installazione del Sistema informatico La consegna, l installazione e la messa in esercizio del Sistema informatico devono essere suddivise in due lotti come già scritto e dettagliato più sotto. La Ditta dovrà presentare una pianificazione delle attività di installazione, configurazione, analisi, parametrizzazione, migrazione degli archivi preesistenti, addestramento del personale, collaudi, messa in esercizio e avviamento nel rispetto dei termini di seguito indicati. Le attività devono comprendere la messa in produzione (installazione, configurazione, parametrizzazione, attività formativa concordata, migrazione, rilascio documentazione richiesta della banca dati e sistemistica. Il Comune di Padova si riserva la facoltà di richiedere alla Ditta aggiudicataria modifiche al piano di lavoro al fine di adattarlo ad esigenze organizzative interne. 18

19 8.2 LOTTO A La prima parte consiste in Modulo di Front Office come descritto nell art. 7 nella versione non integrata con il prodotto di I.M. Modulo di Back Office le funzioni dei punti Gestione Imposta Gestione controlli Gestione Iter Provvedimenti Migrazione degli archivi del Comune di Padova Addestramento del personale Installazione e Avviamento La consegna e l installazione di questo lotto deve avvenire entro 60 giorni naturali e consecutivi dalla data dell ordine di avvio della fornitura. Il collaudo e la messa in esercizio devono avvenire entro i seguenti 30 giorni naturali. Si sottolinea che, condizione necessaria per la messa in esercizio, è la consegna della documentazione analitica di carattere sistemistico di cui all art LOTTO B La seconda parte del sistema riguarda Modulo di Front Office come descritto nell art. 7 nella versione integrata con il prodotto di I.M. Modulo di Back Office - le funzioni del punto Interrogazione Fascicolo di Protocollo e Documentale La consegna e l installazione di questo lotto deve avvenire entro 40 giorni naturali e consecutivi dalla data dell ordine di avvio della fornitura. Il collaudo e la messa in esercizio devono avvenire entro i seguenti 30 giorni naturali. ART. 9: MIGRAZIONE DEGLI ARCHIVI DEL COMUNE DI PADOVA Attualmente l Imposta di Soggiorno è gestita manualmente con il solo supporto di fogli Excel per la registrazione dei dati anagrafici delle strutture alberghiere, delle dichiarazioni e dei dati contabili. La Ditta deve provvedere all importazione di questi dati nel nuovo sistema. Poiché la gestione è manuale, è evidente che si dovrà effettuare un attività di bonifica e normalizzazione in particolare per gli indirizzi. ART. 10: ADDESTRAMENTO UTENTE Deve essere effettuato un piano di addestramento dell utente stimato all incirca in 8 giornate lavorative complessive. Il fabbisogno effettivo verrà definito con la Ditta aggiudicataria in fase di pianificazione esecutiva delle attività e le date saranno concordate tra le parti. Le giornate necessarie verranno commissionate sulla base delle effettive necessità e liquidate a consuntivo. Il piano di addestramento deve essere adeguatamente distribuito considerando che le fasi di messa in esercizio sono due per l intero sistema. Le giornate di addestramento si intendono di 8 ore quotidiane. Nella stessa giornata potranno essere previste due diverse sessioni di corso. 19

20 L attività di addestramento dovrà essere effettuata prima della messa in esercizio del Sistema e dovrà essere realizzata presso i locali del Comune di Padova. Il piano di addestramento dovrà contemplare: - l utilizzo della procedura in tutte le sue funzionalità - le opportune modalità operative da adottare in caso di problematiche di gestione. Fra le giornate almeno una va destinata alla presentazione plenaria del modulo di Front Office alle associazioni di categoria. Contestualmente deve essere messo a disposizione un manuale utente sia per il modulo di Front Office che uno per l utente di Back Office. Per l amministratore di sistema, in particolare, l addestramento dovrà contemplare un livello di formazione dettagliato relativamente alle funzioni di amministratore, alla sicurezza del Sistema Informatico, alle attività di installazione, gestione delle postazioni utente e configurazione dell applicativo. Il piano dovrà tendere alla conoscenza del nuovo ambiente informatico con l obiettivo di: - poter interagire facilmente con la Ditta aggiudicataria nella gestione dei servizi; - rendere autonomo il Comune nella configurazione e parametrizzazione del sistema; - poter assumere l incarico di un eventuale docenza di corsi base per l utilizzo della procedura da parte di personale dell Ente. ART. 11: ATTIVITA DI SUPPORTO ALL'AVVIAMENTO Nel primo periodo di esercizio del Lotto A del Sistema, devono essere previste 2 giornate/uomo di affiancamento all utente al fine di supportarlo nella fase di avviamento e configurazione del sistema. Nell ambito dello sviluppo e avviamento si dovranno prevedere anche eventuali compresenze del personale della Ditta presso il SIT per la configurazione dei servizi di cooperazione applicativa con il sistema di Identity Management e con P@doc. ART. 12: COLLAUDO Data l'articolazione in due fasi del progetto sono previsti complessivamente due collaudi ossia uno per ogni fase realizzativa. I collaudi sono finalizzati a verificare la conformità del Sistema con le specifiche di dettaglio di cui al presente C.S.A. e di quanto offerto dalla Ditta aggiudicataria. In ogni caso il collaudo, anche se favorevole, non esonera la Ditta appaltatrice dalle responsabilità sancite dal vigente Codice Civile. Le prove di collaudo saranno eseguite da una commissione costituita da rappresentanti del Comune di Padova e della Ditta aggiudicataria. Di ciascun collaudo verrà redatto un verbale sottoscritto dalle parti. Se il collaudo del lotto A risultasse negativo, il Comune di Padova valutata la natura e l entità delle anomalie riscontrate, potrà, a propria discrezione: - concedere, fermo restando l applicazione delle relative penali previste al successivo art. 15 e fatto salvo il risarcimento di ogni eventuale ulteriore danno, un ultimo termine per la rimozione definitiva dei vizi e difetti riscontrati; - risolvere il Contratto, fatto salvo il diritto al risarcimento di tutti i danni diretti ed indiretti comunque subiti dall Amministrazione. ART. 13: ASSISTENZA IN GARANZIA E MANUTENZIONE ORDINARIA 20

21 Tutte le componenti della fornitura devono essere coperte dal servizio di assistenza e manutenzione per la durata di 3 anni dal collaudo e il servizio di assistenza e manutenzione ordinaria dovrà essere erogato con le caratteristiche e modalità sotto specificate La continuità del servizio dovrà essere assicurata per un minimo di 8 (otto) ore giornaliere (dalle 8.00 alle e dalle alle 18.00), almeno dal lunedì al venerdì. L attività di manutenzione ordinaria dovrà comprendere: - il supporto continuativo di assistenza on-site e teleassistenza per almeno 5 giorni la settimana, esclusi il sabato e i festivi; - la fornitura ed installazione di eventuali aggiornamenti software; - la correzione di ogni errore e/o malfunzionamento; - il supporto per la corretta gestione delle applicazioni; - modifiche migliorative, nuove releases software inerenti la fornitura a capitolato; - l adeguamento del software alle variazioni di norme e regolamenti a livello centrale e locale non risolvibili nell ambito della flessibilità di base dei prodotti. Tale attività si intende dovuta solamente per variazioni che non stravolgano l architettura funzionale del software; L Ente comunicherà (anche via fax, , o telefono) tutte le segnalazioni di anomalie rilevate e che richiedono l intervento di manutenzione. L assistenza si intende rivolta solamente al Comune in quanto per il FO l assistenza sarà mediata da parte di personale del Comune; eventuali malfunzionamenti nel FO saranno segnalati dal Comune. Tale intervento (dove possibile) dovrà essere realizzato in teleassistenza. Ogni richiesta di assistenza e/o intervento, deve essere codificata con il rilascio di un numero di riferimento univoco (ticket) e deve essere tracciata fino al completamento. Gli interventi in garanzia, nonché quelli di manutenzione, dovranno essere effettuati - per guasti bloccanti per il F.O. entro 1 giorno lavorativo (8 ore) dalla segnalazione dell intervento per il B.O. entro 2 giorni lavorativi dalla segnalazione dell intervento - per guasti non bloccanti entro 2 giorni lavorativi dalla segnalazione dell intervento. Le modifiche dovute per l adeguamento alla normativa dovranno essere completate, rese disponibili e funzionanti entro i termini inderogabili e perentori imposti dalle leggi e regolamenti, e cioè in un tempo utile sufficiente a garantire che l Ente possa rispettare le varie scadenze imposte. Il mancato rispetto dei termini previsti comporterà l applicazione delle penali di cui all art. 15 ART. 14: CORRISPETTIVI E MODALITA' DI PAGAMENTO I corrispettivi per le voci di fornitura lotto A e lotto B, onnicomprensivi di tutti gli oneri IVA esclusa, a corpo, saranno quelli indicati dalla Ditta aggiudicataria nell Offerta Economica. Il corrispettivo per le giornate di addestramento sarà determinato a misura, in base al costo giornaliero desumibile dall importo indicato alla voce C dell offerta economica. Con i corrispettivi di cui sopra si intendono interamente compensati dal Comune di Padova tutti i servizi, le provviste, le prestazioni, le spese accessorie, ecc. necessarie per la perfetta esecuzione dell appalto, qualsiasi onere espresso e non dal presente C.S.A. inerente e conseguente ai servizi di cui si tratta. Dal pagamento del corrispettivo sarà detratto l importo delle eventuali penalità applicate per inadempienza a carico della Ditta appaltatrice, e quant altro dovuto dalla stessa. I corrispettivi dovranno essere fatturati come segue: lotto A al collaudo con esito positivo; lotto B al collaudo con esito positivo; addestramento a consuntivo, sulla base delle giornate effettivamente erogate. Il pagamento delle varie voci di fornitura verrà effettuato a fronte del ricevimento di apposite regolari fatture. 21

22 ART. 15: PENALI Nel caso in cui la Ditta aggiudicataria violi le disposizioni del presente C.S.A., previa contestazione alla Ditta aggiudicataria con formale lettera di addebito, il Contraente applicherà le seguenti penali pecuniarie: penale 100 per ogni giorno calendariale, continuo di ritardo per mancato rispetto del termine di collaudo e messa in esercizio del Sistema come previsto dall art. 8 del C.S.A.; la penale è raddoppiata in caso di ritardo superiore a 15 giorni calendariali. Tale penale si calcola anche in caso di collaudo negativo. penale 50 per ogni giorno per mancato rispetto dei tempi di intervento di manutenzione ordinaria in caso di errori bloccanti l operatività; la penale è raddoppiata a partire dal secondo giorno lavorativo di ritardo. Le penali non risulteranno applicabili qualora l inadempimento dipenda da causa imputabile all utenza. Alla contestazione della inadempienza la Ditta aggiudicataria ha facoltà di presentare le proprie controdeduzioni entro e non oltre 10 (dieci) giorni dalla data di ricevimento della lettera di addebito. Il Comune di Padova procederà al recupero della penalità mediante trattenuta sulle fatture emesse dalla Ditta. Raggiunto un controvalore di penale pari al 10% del relativo importo di aggiudicazione, il Comune di Padova avrà facoltà di recedere dal contratto dandone comunicazione alla Ditta aggiudicataria mediante lettera raccomandata con avviso di ricevimento, e ciò senza pregiudizio per eventuali azioni di risarcimento danni. ART. 16: RISERVA DI RECESSO Il Comune di Padova si riserva la facoltà di recedere parzialmente dal contratto e precisamente di non procedere all affidamento del lotto B qualora, per sopravvenute innovazioni tecnologiche o variazioni organizzative della struttura, tali prestazioni non siano più considerate di utilità per l Ente. Il contratto è sottoposto a diritto di recesso unilaterale da parte dell Ente ai sensi e con le modalità di cui all art. 1 comma 14 del DL 95 del 6/7/2012 convertito con modifiche dalla L. 135/2012. ART. 17: CAUZIONE DEFINITVA La Ditta aggiudicataria è tenuta, a garanzia degli impegni contrattuali, a prestare una cauzione definitiva nella misura e con le modalità previste all art. 113 del D.Lgs 163/2006. ART. 18: TRATTAMENTO DEI DATI PERSONALI E RISERVATEZZA La Ditta ha l obbligo di mantenere riservati i dati e le informazioni di cui venga in possesso, di non divulgarli e di non farne oggetto di utilizzazione a qualsiasi titolo. Il trattamento dei dati personali e sensibili dovrà avvenire in attenta ottemperanza alle disposizioni del Codice in materia di protezione dei dati personali D. Lgs. 196/2003, e dei provvedimenti del Garante per la protezione dei dati personali con particolare riferimento a quello del 27/11/2008 e s.m.i.. 22