GE 05-16
Insiel – Informatica per il Sistema degli Enti Locali S.p.A. con unico socio Sede Legale: Trieste, Via San Xxxxxxxxx d’Assisi n. 43
GE 05-16
PROCEDURA APERTA, AI SENSI DEL D.LGS 50/2016
per la Fornitura di servizi relativi a pagamenti online compliant con il nodo spc
CAPITOLATO TECNICO
(allegato 7 al Disciplinare di gara) CIG 6770251BDB
SOMMARIO
1 Introduzione 3
1.1 Definizioni 3
1.2 Termini chiave 4
1.3 Glossario 5
1.4 Riferimenti 7
1.4.1 Riferimenti normativi 9
2 Il contesto 11
2.1 Sistemi di pagamento indirizzo nazionale-europeo 11
2.2 AGID – Nodo Pagamenti XXX 00
2.3 Strategia della Regione Friuli Venezia Giulia per il sistema dei Pagamenti Pubblici 12
2.4 Il sistema attuale 12
2.4.1 Modello concettuale dell’attuale sistema 16
3 Definizione dell’appalto 18
3.1 Oggetto 18
3.2 Durata dell’appalto 18
3.3 Caratteristiche del Servizio 18
3.4 Uniformità del Layout della pagine WEB 21
3.5 Ulteriori Obblighi dell’Affidatario 23
3.6 Modalità di attivazione ed erogazione del servizio 23
3.7 Demo 24
4 Servizi professionali correlati 25
4.1 Consulenza tecnica per lo start up 25
4.2 Assistenza specifica 25
4.3 Assistenza di secondo livello 25
4.4 Manutenzione adeguativa 27
5 Caratteristiche generali del sistema applicativo a supporto del Servizio 28
5.1 Accessibilità ed usabilità 28
5.2 Protezione dati personali 28
5.3 Requisiti di qualità 28
6 Disposizioni contrattuali 31
6.1 Referente per l’affidamento 31
6.2 Verifica di conformità 31
6.3 Fatturazione e pagamento 31
6.4 Penali 32
6.5 Obblighi di tracciabilità dei flussi finanziari – Legge n. 136/2010 33
6.6 Esecuzione in danno 33
6.7 Risoluzione e Clausola risolutiva espressa 33
6.8 Recesso 34
6.9 Subentro nel contratto 35
6.10 Documento Unico di Regolarità Contributiva (D.U.R.C.) 35
6.11 Revisione dei corrispettivi 35
6.12 Cessione dei crediti 36
1 Introduzione
La Regione Autonoma Friuli Venezia Giulia a partire da gennaio del 2016 risulta attestata sul nodo nazionale dei pagamenti SPC sia in qualità di ente creditore sia come intermediario tecnologico.
L’attuale sistema regionale dei pagamenti on line è costituito da una componente direttamente gestita dalla stazione appaltante, che funge da collettore per tutti i servizi di pagamento veicolati dal sistema e da una componente per l’interconnessione al nodo nazionale dei pagamenti SPC.
Tale componente è rappresentata da un servizio software non Insiel e derivante da una precedente procedura di affidamento in scadenza a novembre 2016.
1.1 Definizioni
Nel seguito del presente documento sono utilizzati i seguenti termini:
• “Bando di gara” o “Bando”: s’intende l’Avviso pubblicato secondo legge, allo scopo di diffondere l’intenzione di procedere all’affidamento del presente appalto mediante gara;
• “Capitolato Tecnico e d’Oneri” o “Capitolato”: s’intende il presente documento che contiene le informazioni relative alle condizioni/modalità ed ai termini di esecuzione delle attività oggetto dell’appalto;
• “Disciplinare di gara”, s’intende il documento che contiene tutte le informazioni riguardanti le condizioni e alle modalità di redazione e di presentazione delle offerte, ai criteri di aggiudicazione, alle cause di esclusione e di decadenza, nonché agli obblighi dell’Aggiudicatario per la stipula del contratto;
• “Atti di gara”, s’intende l’insieme dei documenti di cui sopra (Bando di gara – Capitolato Tecnico e d’Oneri – Disciplinare di gara);
• “Informazioni complementari”: s’intendono le informazioni e i chiarimenti forniti dalla Società Appaltante
• “Società Appaltante”: s’intende INSIEL spa;
• “Aggiudicatario”: s’intende il soggetto, in qualunque forma costituito, che, al termine della procedura di gara, è risultato primo nella relativa graduatoria definitiva;
• “Appaltatore”: s’intende il soggetto che, essendo risultato Aggiudicatario del presente appalto, ha stipulato il contratto con la Società Appaltante;
• “Legale rappresentante”: s’intende la persona fisica regolarmente munita di poteri di firma, conferitigli dai competenti organi aziendali, idonei a impegnare formalmente l’operatore concorrente nell’ambito della presente procedura;
• “Parti”: s’intende, congiuntamente, la Società Appaltante e l’Appaltatore.
1.2 Termini chiave
Nel presente documento sono utilizzati i termini chiave “DEVE”, “NON DEVE”, “OBBLIGATORIO”, “VIETATO”, “DOVREBBE”, “CONSIGLIATO”, “NON DOVREBBE”, “SCONSIGLIATO”, “POTREBBE”,
“OPZIONALE”, con i quali s’intende quanto di seguito specificato:
Termine chiave | Significato |
DEVE OBBLIGATORIO | definiscono elementi, requisiti, specifiche, condizioni che devono essere obbligatoriamente implementati/soddisfatti, fermo restando quanto specificato nel Disciplinare di gara in tema di esclusione dalla procedura di gara e nel seguito del presente documento in tema di verifiche e di penali e/o di risoluzione-recesso |
DOVREBBE CONSIGLIATO | definiscono elementi, requisiti, specifiche, condizioni che in particolari circostanze possono essere ignorati/derogati, ferme restando le implicazioni tecnico operative correlate alla scelta e fatto salvo quanto specificato nel Disciplinare di gara in tema di valutazione delle offerte e di attribuzione dei relativi punteggi |
PUÒ OPZIONALE | definiscono elementi, requisiti, specifiche, condizioni la cui implementazione/soddisfazione è facoltativa, ferme restando le implicazioni tecnico operative correlate alla scelta |
NON DOVREBBE SCONSIGLIATO | definiscono elementi, requisiti, specifiche, condizioni che in particolari circostanze possono essere introdotti/implementati, ferme restando le implicazioni tecnico operative correlate alla scelta e fatto salvo quanto specificato nel Disciplinare di gara in tema di valutazione delle offerte e di attribuzione dei relativi punteggi |
NON DEVE VIETATO | definiscono elementi, requisiti, specifiche, condizioni, che assolutamente non devono essere introdotti/implementati, fermo restando quanto specificato nel Disciplinare di gara in tema di esclusione dalla procedura di gara e nel proseguo del presente documento in tema di verifiche e di penali e/o di risoluzione-recesso |
1.3 Glossario
Termine | Definizione |
addebito diretto | un ordine di pagamento per l’addebito di un conto di pagamento del pagatore (o del soggetto versante) in cui l’operazione di pagamento è iniziata dal beneficiario in conformità al consenso del pagatore (o dal soggetto versante), eseguito sulla base degli standard SEPA pubblicati da EPC; |
ATM (Automated Teller Machine) | apparecchiatura automatica per l’effettuazione da parte della clientela di operazioni quali prelievo di contante, versamento di contante o assegni, richiesta di informazioni sul conto, bonifici, pagamento di utenze, ricariche telefoniche, ecc. Il cliente attiva il terminale introducendo una carta e digitando il codice personale di identificazione. In Italia, ad esempio, i circuiti Postamat e Bancomat si servono di ATM; |
bollettino di conto corrente postale | bollettino precompilato dal creditore - o da compilare a cura del debitore - con cui il debitore effettua il pagamento con accredito sul conto di pagamento detenuto dal creditore presso Poste Italiane S.p.A.; |
bonifico (bancario o postale) | un servizio di pagamento per l’accredito sul conto di pagamento del beneficiario eseguito, sulla base degli standard SEPA pubblicati da EPC, a partire da un conto di pagamento del pagatore (o del soggetto versante) da parte del prestatore di servizi di pagamento detentore del conto di pagamento del pagatore (o del soggetto versante), sulla base di un’istruzione data dal pagatore (o dal soggetto versante); |
carta di credito o di debito | strumento di pagamento costituito da una carta plastificata, dotata di banda magnetica e/o microchip, che in base a un rapporto contrattuale con l’emittente, abilita il titolare a effettuare pagamenti (es. tramite terminale POS o via internet); |
conto di pagamento | un conto intrattenuto presso un prestatore di servizi di pagamento da uno o più utilizzatori di servizi di pagamento per l’esecuzione di operazioni di pagamento. Rientra nella nozione di conto di pagamento il conto corrente bancario o postale nei limiti in cui venga utilizzato per operazioni di pagamento, nonché il conto sul quale vengono addebitate e accreditate le operazioni di pagamento eseguite a valere su una carta di debito o di credito |
enti creditori | le pubbliche amministrazioni definite nell’articolo 2, comma 2 del CAD ed i gestori di pubblici servizi “nei rapporti con l’utenza” |
EPC European Payments Council (Consiglio europeo per i pagamenti) | sostiene e promuove la creazione della SEPA attraverso l'autoregolamentazione dell’industria bancaria. EPC definisce le regole comuni per i servizi di pagamento di base all'interno di un mercato competitivo, fornisce orientamenti strategici per la standardizzazione, formula le migliori pratiche a supporto e controlla l'attuazione delle decisioni prese; |
gestori di pubblici | le aziende e gli enti organizzati in forma societaria che gestiscono servizi |
servizi | pubblici; |
IBAN International Bank Account Number | numero identificativo internazionale di un conto di pagamento che individua senza ambiguità un unico conto di pagamento e i cui elementi sono specificati dall’Organizzazione internazionale per la standardizzazione; |
istituto tesoriere | il soggetto finanziario affidatario del servizio di tesoreria o di cassa della singola amministrazione, ivi compresa la Banca d’Italia; |
micro-pagamenti | operazioni di pagamenti di importo non superiore a 30 euro o che presentano un limite di spesa complessivo di 150 euro o che sono avvalorati per un importo che in nessun momento supera i 150 euro, così come indicati all’articolo 4, comma 1 del Decreto legislativo 27 gennaio 2010, n. 11; |
pagatore | persona fisica o giuridica che effettua, direttamente o tramite un delegato (soggetto versante), un pagamento in favore di un ente per somme di denaro a vario titolo dovute; |
POS (Point Of Sale) | apparecchiatura automatica presidiata per la lettura di carte di pagamento (POS fisico) o servizio fruibile attraverso la rete internet (POS virtuale), messi a disposizione dai prestatori di servizi di pagamento, mediante i quali è possibile effettuare l’operazione di pagamento; |
prestatore di servizi di pagamento | uno dei seguenti organismi che presta servizi di pagamento sul territorio della Repubblica in quanto ivi insediato o in regime di libera prestazione di servizi: fanno parte dei prestatori di servizi di pagamento gli istituti di moneta elettronica e gli istituti di pagamento nonché, quando prestano servizi di pagamento, le banche, gli uffici postali, la Banca Centrale Europea e le banche centrali nazionali se non agiscono in veste di autorità monetarie, altre autorità pubbliche, le amministrazioni statali, regionali e locali se non agiscono in veste di autorità pubbliche; |
PSD Payment Services Directive | la direttiva 2007/64/CE relativa ai servizi di pagamento nel mercato interno; |
Pubblica Amministrazione | ente di cui all’articolo 2, comma 2 del CAD; |
ricevuta telematica | attestazione informatica di avvenuto pagamento rilasciata dal prestatore di servizi di pagamento al pagatore, o al soggetto versante, nonché all’ente creditore; |
richiesta di pagamento telematico | disposizione impartita dal pagatore, o dal soggetto versante, al prestatore di servizi di pagamento contenente tutti gli elementi richiesti dall’ente creditore beneficiario per effettuare un pagamento informatico; |
SEPA Single Euro Payments Area (Area unica dei pagamenti in euro) | ovvero un'area nella quale gli utilizzatori degli strumenti di pagamento - i cittadini, imprese, pubbliche amministrazioni e gli altri operatori economici - indipendentemente dalla loro residenza, possono effettuare e ricevere pagamenti in euro non in contanti sia all'interno dei confini nazionali che fra paesi diversi, alle stesse condizioni e con gli stessi diritti e obblighi. La SEPA |
riguarda 32 paesi (tutti i paesi dell'Unione Europea più l'Islanda, la Norvegia, il Liechtenstein, la Svizzera e il Principato di Monaco). Il progetto SEPA, avviato oltre 10 anni fa - su impulso delle autorità europee - dall'industria bancaria e dei pagamenti europea, prevede la definizione di standard comuni per bonifici e addebiti diretti, i due principali servizi di pagamento al dettaglio in euro diversi dal contante. | |
servizi pubblici | qualsiasi attività che si concretizzi nella produzione di beni o servizi che rispondano ad esigenze di utilità generale, non solo in termini economici ma anche in termini di promozione sociale, purché risponda ad esigenze di utilità generale o ad essa destinata in quanto preordinata a soddisfare interessi collettivi1 |
soggetto versante | persona, fisica o giuridica, che effettua un pagamento su delega del pagatore |
SPC | Sistema pubblico di connettività di cui al Capo VIII del CAD |
SPID | Sistema pubblico per la gestione dell'identità digitale di cittadini e imprese di cui all’articolo 64 del CAD |
strumento di pagamento | dispositivo personalizzato o insieme di procedure utilizzate dal prestatore di servizi di pagamento che consentono al pagatore, o al soggetto versante, di impartire richieste di pagamento informatico |
utilizzatore finale | il soggetto (pagatore o versante) che effettua il pagamento di somme a favore di un ente creditore |
1.4 Riferimenti
Il presente Capitolato Tecnico fa riferimento alle “Linee guida per l'effettuazione dei pagamenti elettronici a favore delle pubbliche amministrazioni e dei gestori di pubblici servizi” emanate dall’Agenzia per l’Italia Digitale, sentita la Banca d’Italia, ai sensi dell’articolo 5, comma 4, del Decreto legislativo 7 marzo 2005, n. 82 e successive modificazioni, recante il “Codice dell‘amministrazione digitale” (CAD).
Le Linee guida perseguono l’obiettivo del legislatore di cogliere le opportunità offerte dalle nuove tecnologie per facilitare le relazioni con i cittadini e le imprese. L’auspicato maggior utilizzo di strumenti di pagamento elettronici facilita la messa a punto di processi molto automatizzati per la gestione e la riconciliazione dei pagamenti da parte della Pubblica Amministrazione, nel rispetto delle soluzioni organizzative in essere.
Le Linee guida per i pagamenti della Pubblica Amministrazione, tenuto conto del quadro normativo di riferimento, delineano le attività che le pubbliche amministrazioni ed i gestori di pubblici servizi devono mettere in atto per consentire l’esecuzione di pagamenti attraverso l’uso di strumenti elettronici, nonché le specifiche dei codici da utilizzare per il pagamento, la riconciliazione e il riversamento delle somme raccolte.
L’Agenzia per l’Italia Digitale tiene aggiornate le Linee guida e i documenti a esse connessi, per tener conto delle variazioni del quadro di riferimento normativo, dell’evoluzione del contesto tecnologico e delle mutate esigenze delle pubbliche amministrazioni e degli utilizzatori finali, quali beneficiari del servizio pubblico erogato.
Il Servizio oggetto di gara proposto in fase di gara DEVE aderire pienamente al contenuto delle Linee guida e della relativa documentazione tecnica allegata e di completamento (il cui ultimo aggiornamento è del 22 Giugno 2016) rintracciabile in: xxxx://xxx.xxxx.xxx.xx/xxxxxx-xxxxxxxx/xxxxxxxx- amministrazione/pagamenti-elettronici/linee-guida e che viene riportato a livello di titoli di seguito (i documenti di riferimento sono suddivisi in ‘Linee Guida’ e ‘Regole Tecniche’), di cui si riporta elenco :
Linee Guida
• Linee guida per l’effettuazione dei Pagamenti Elettronici a favore delle Pubbliche Amministrazioni e dei Gestori di Pubblici Servizi.
E' parte integrante delle Linee guida la seguente documentazione tecnica:
- Allegato A - Specifiche attuative dei codici identificativi di versamento, riversamento e rendicontazione, che descrive le attività legate alla fase di generazione del pagamento, le specifiche dei codici da utilizzare per il versamento, nonché le modalità e le informazioni da utilizzare per la fase di regolamento contabile e riversamento dei fondi;
- Allegato B - Specifiche attuative del nodo dei pagamenti-SPC, che descrive le caratteristiche generali del sistema dei pagamenti, i protocolli applicativi per lo scambio delle informazioni, gli aspetti tecnici di dettaglio (Appendice 3 all’Allegato B), nonché i ruoli e le responsabilità nell’ambito del sistema.
🢭 Appendice 3 all'allegato B - Specifiche attuative del nodo dei pagamenti-SPC
🢭 Appendice 4 all'allegato B - MyBank Style Guide for Businesses
(AGID, a seguito dell'aggiornamento degli allegati A e B del 23 ottobre 2015, ha emanato un Vademecum che contiene il riepilogo delle modifiche apportate alle specifiche tecniche, organizzate per argomento o soggetto interessato, e il calendario dei rilasci).
Regole tecniche
• L'avviso di pagamento analogico nel Sistema pagoPA - NEW
• Il pagamento spontaneo presso i PSP: il caso d'uso della Tassa automobilistica - NEW
• Wizard Interattivo di Scelta del PSP
• Codici GS1 Global Location Number (GLN)
• Transazioni MyBank attraverso il Nodo dei Pagamenti-SPC
• Sistema centralizzato AGID per la connessione degli Enti Creditori
• Pagamento elettronico della Marca da bollo digitale
• Bollo telematico - Linee guida per Pubbliche Amministrazioni e Prestatori di Servizi di Pagamento.
1.4.1 Riferimenti normativi
Di seguito si riportano ulteriori norme prese a riferimento per la stesura del presente Capitolato Tecnico:
1. Regio decreto 23 maggio 1924, n. 827, e successive modificazioni recante “Regolamento per l’amministrazione del patrimonio e per la contabilità generale dello Stato”;
2. Decreto legislativo 1 settembre 1993, n. 385 e successive modificazioni, recante “Testo unico delle leggi in materia bancaria e creditizia”;
3. Decreto-legge 1° dicembre 1993, n. 487, convertito, con modificazioni, dalla legge 29 gennaio 1994, n. 71 recante “Trasformazione dell’Amministrazione delle poste e delle telecomunicazioni in ente pubblico economico e riorganizzazione del Ministero”, con riferimento all’articolo 2, comma 2 con il quale l’Ente Poste deve sottoscrivere convenzioni con gli enti pubblici al fine di regolare, tra le altre, le operazioni afferenti lo svolgimento del servizio di tesoreria;
4. Decreto legislativo 30 luglio 1999, n. 300 e successive modificazioni recante “Riforma dell'organizzazione del Governo, a norma dell'articolo 11 della legge 15 marzo 1997, n. 59”, con riferimento agli articoli 62 e 63, che regolano le funzioni delle agenzie fiscali (Agenzia delle entrate e Agenzia delle dogane e dei monopoli);
5. Decreto legislativo 18 agosto 2000, n. 267 e successive modificazioni recante “Testo unico delle leggi sull’ordinamento degli enti locali”, in particolare ci si riferisce al Titolo V della Parte II, riguardante la gestione del servizio di tesoreria;
6. Decreto del Presidente della Repubblica 14 marzo 2001, n.144 e successive modificazioni recante “Regolamento recante norme sui servizi di bancoposta”;
7. Decreto legislativo 7 marzo 2005, n. 82 e successive modificazioni recante il “Codice dell’amministrazione digitale”, di seguito indicato anche come “CAD”;
8. Decreto del Ministro dell’economia e delle finanze 9 ottobre 2006, n. 293 recante “Regolamento recante norme per l’introduzione di nuove modalità di versamento presso le tesorerie statali”;
9. Legge 27 dicembre 2006, n. 296 recante “Disposizioni per la formazione del bilancio annuale e pluriennale dello Stato (legge finanziaria 2007)”, con riferimento all’articolo 1, comma 455 per mezzo del quale le regioni possono costituire centrali di committenza regionali;
10. Provvedimento 20576 dell’Xxxxxxxx xxxxxxx xxxxx xxxxxxxxxxx x xxx xxxxxxx xxx 00 dicembre 2009 avente come argomento “Poste Italiane - aumento commissione bollettini c/c”;
11. Decreto legislativo 27 gennaio 2010, n. 11 recante “Attuazione della direttiva 2007/64/CE relativa ai servizi di pagamento nel mercato interno, recante modifica delle direttive 97/7/CE, 2002/65/CE, 2005/60/CE, 2006/48/CE e che abroga la direttiva 97/5/CE”. Si precisa che l’articolo 37, comma 6 del decreto stesso ha rinviato l’applicazione alle pubbliche amministrazioni delle norme in esso contenute ad un successivo decreto del Ministro dell’economia e delle finanze, sentita la Banca d’Italia, ancora in corso di definizione: in assenza di tale normativa si ritiene opportuno precisare che le presenti Linee guida prendono comunque a riferimento le disposizioni contenute nel citato decreto legislativo 27 gennaio 2010, n.11;
12. Provvedimento della Banca d’Italia del 5 luglio 2011 recante “Attuazione del Titolo II del Decreto legislativo n. 11 del 27 gennaio 2010 relativo ai servizi di pagamento (Diritti ed obblighi delle parti)”;
13. Decreto legge 13 agosto 2011, n. 138, convertito con modificazioni dalla legge 14 settembre 2011,
n. 148, recante “Ulteriori misure urgenti per la stabilizzazione finanziaria e per lo sviluppo” e in particolare, l’articolo 6, comma 5 che - introducendo il comma 2-bis all’articolo 81 del CAD - ha previsto la messa a disposizione da parte dell’allora DigitPA (oggi Agenzia per l’Italia Digitale), attraverso il Sistema pubblico di connettività, “di una piattaforma tecnologica per l’interconnessione e l’interoperabilità tra le pubbliche amministrazioni e i prestatori di servizi di pagamento abilitati”;
14. Decreto legge 6 dicembre 2011, n. 201, convertito con modificazioni dalla legge 22 dicembre 2011, n.214, recante “Disposizioni urgenti per la crescita, l’equità e il consolidamento dei conti pubblici” e, in particolare, l’articolo 12 “Riduzione del limite per la tracciabilità dei pagamenti a
1.000 euro e contrasto all’uso del contante”;
15. Regolamento (UE) 260/2012 del Parlamento europeo e del Consiglio del 14 marzo 2012 che stabilisce i requisiti tecnici e commerciali per i bonifici e gli addebiti diretti in euro e che modifica il regolamento (CE) n. 924/2009;
16. Decreto-legge 18 ottobre 2012 , n. 179, convertito con modificazioni dalla legge 17 dicembre 2012, n. 221, recante “Ulteriori misure urgenti per la crescita del Paese”, con particolare riferimento all’articolo 15 “Pagamenti elettronici”;
17. Provvedimento della Banca d’Italia del 12 febbraio 2013 recante “Istruzioni applicative del Regolamento 260/2012 del Parlamento europeo e del Consiglio che stabilisce i requisiti tecnici e commerciali per i bonifici e gli addebiti diretti in euro e che modifica il Regolamento (CE) n. 924/2009 “.
2 Il contesto
2.1 Sistemi di pagamento indirizzo nazionale-europeo
L’EPC European Payments Council (Consiglio europeo per i pagamenti) sostiene e promuove la creazione della SEPA Single Euro Payments Area ( Area unica dei pagamenti in euro) attraverso l'autoregolamentazione dell’industria bancaria.
La SEPA ovvero la Single Euro Payments Area (Area Unica dei Pagamenti in Euro) è un progetto promosso dalla Banca Centrale Europea e dalla Commissione Europea che, facendo seguito all'introduzione dell'euro, mira a estendere il processo d'integrazione europea ai pagamenti al dettaglio in euro effettuati con strumenti diversi dal contante (bonifici, addebiti diretti e carte di pagamento).
La realizzazione di un’area unica dei pagamenti consente quindi ai cittadini europei di poter effettuare pagamenti in euro a favore di beneficiari situati in qualsiasi paese della SEPA con la stessa facilità e sicurezza su cui si può contare nel proprio contesto nazionale. Il progetto SEPA, avviato oltre 10 anni fa, su impulso delle autorità europee, dall'industria bancaria e dei pagamenti europea, prevede la definizione di standard comuni per bonifici e addebiti diretti, i due principali servizi di pagamento al dettaglio in euro diversi dal contante.
2.2 AGID – Nodo Pagamenti SPC
L’Agenzia per l'Italia Digitale (AGID) e l’Associazione Italiana Istituti di Pagamento e di Moneta Elettronica (A.I.I.P.) hanno sottoscritto un accordo di collaborazione che permetterà a cittadini e imprese di fruire di nuovi canali e servizi per i pagamenti in favore della pubblica amministrazione (xxxx://xxx.xxxx.xxx.xx/xxxxx/xxxxxxx/xxxxx/xxxxxxx_xxxxxxxxxxxxx/xxxxxxx_xxx_xxxx_0.xxx).
A tal fine, è stata realizzata dall’AGID una soluzione tecnologica chiamata Nodo dei Pagamenti SPC (NdP), che permette di connettere un ente della PA a tutte le amministrazioni, centrali e locali e gestori di servizi pubblici che hanno già aderito all’infrastruttura NdP.
Il sistema dei pagamenti elettronici permette al cittadino di scegliere il canale di pagamenti da utilizzare tra banche, istituti di pagamento e moneta elettronica e permette inoltre di scegliere lo strumento con il quale effettuare il pagamento tra le modalità più diffuse nell’ambito tecnologico corrente (es. addebito in conto corrente, carta di credito, bollettino postale elettronico).
I servizi erogati dal NdP, consentono al cittadino di usufruire anche di altri benefici, quali conoscere preventivamente i costi dell’operazione, avere immediatamente la ricevuta di pagamento, e di evadere il pagamento tramite home banking, qualora il suo istituto di credito abbia aderito alla piattaforma.
Dal punto di vista della PA, il NdP permette di velocizzare gli incassi, ridurre i costi, e di eliminare la necessità di stipulare specifici accordi con i prestatori di servizi di riscossione.
La piattaforma garantisce a tutti gli aderenti di operare in condizioni paritetiche e senza la necessità di attivare accordi bilaterali con le PA.
2.3 Strategia della Regione Friuli Venezia Giulia per il sistema dei Pagamenti Pubblici
La Regione Friuli Venezia Giulia possiede fin dal 2008 una piattaforma regionale per i pagamenti elettronici che ha consentito ai cittadini regionali il pagamento di posizioni debitorie, attive e passive, nei confronti degli Enti Locali e delle Aziende Sanitarie.
Quindi sono anni che la Regione Friuli Venezia Giulia, nell’ottica del Sistema Informativo Integrato Regionale (SIIR), svolge il ruolo di “HUB” per molti servizi centralizzati fra cui quelli di pagamento.
La piattaforma iniziale per i pagamenti prevedeva che ogni ente locale poteva attivare un canale telematico, detto pos virtuale, relativo al proprio tesoriere (istituzione bancaria dove l’amministrazione locale ha i propri conti correnti bancari), in moda da consentire i pagamenti elettronici. In tale contesto il cittadino poteva pagare esclusivamente attraverso il servizio di pagamento online offerto dal pos virtuale della banca tesoriere scelta dall’ente.
Con l’adesione al nodo dei pagamenti-SPC, avvenuta a gennaio del 2016, nella doppia veste di ente creditore e intermediario tecnologico, per mezzo di un servizio software acquisito con precedente procedura di affidamento attualmente in scadenza a novembre 2016, invece, la Regione Friuli Venezia Giulia supera il vincolo del pos virtuale permettendo al cittadino, che vuole pagare una posizione debitoria nei confronti della PA, di scegliere attraverso quale PSP, tra quelli convenzionati, effettuare il pagamento elettronico. In questo modo si sono potute eliminare anche le convenzioni dirette tra amministrazioni locali e istituzioni bancarie, poiché ogni contratto viene stipulato e gestito a livello centrale.
Allo stato attuale risultano attivati sul nodo SPC quattro Enti (Regione FVG e tre Aziende Sanitarie) su due distinte tipologie di servizi di pagamento (diritti tavolari e ticket sanitari).
2.4 Il sistema attuale
La piattaforma originaria per la gestione integrata dei pagamenti elettronici, nata in forma sperimentale nel 2008, ha visto una forte espansione principalmente sul fronte dei pagamenti effettuati in ambito sanitario (ticket) e su quello dei pagamenti effettuati in ambito comunale; tra questi si possono citare i pagamenti derivanti dal sistema per la gestione della ristorazione scolastica.
L’attuale piattaforma è in grado di proporre ai cittadini le pendenze che effettivamente risultano pagabili presso i diversi enti abilitati e, ad esempio, al sistema CUP viene data comunicazione in tempo reale dell’avvenuto pagamento di un ticket, gestendo di fatto l’intero ciclo di vita del pagamento.
L’autenticazione con Carta Regionale dei Servizi (CRS) rappresenta uno strumento abilitante che permette di offrire servizi di pagamento on-line in modalità sicura con particolare attenzione alla tematica della tutela della privacy e della sicurezza.
L’attuale soluzione è composta dalle seguenti componenti logiche:
• Portale Servizi al cittadino: il sistema pagamenti è collocato nella sezione denominata “pagamenti on line” del portale regionale.
• Servizi pagamento on line: è lo strumento a uso dei cittadini per individuare e pagare una posizione debitoria.
• Portale di rendicontazione ente: è il back office riservato agli operatori degli enti per eseguire le operazioni di rendicontazione.
• Gestionale ente: generico applicativo a disposizione dell’Ente, dal quale il sistema pagamenti recupera i dati delle posizioni debitorie.
La soluzione suddetta si concretizza attraverso le seguenti componenti software:
• Modulo per la ricerca dei pagamenti pendenti;
• Modulo per la ricerca dei pagamenti effettuati;
• Modulo per il pagamento dei ticket sanitari;
• Modulo per il pagamento delle mense scolastiche;
• Modulo per il pagamento delle licenze di pesca;
• Modulo per il pagamento generalizzato;
• Modulo di notifica SMS/Email.
Nel corso del 2015 la piattaforma ha subito una importante evoluzione per adeguarsi alle nuove regole introdotte da AGID sul nodo SPC, in moda da consentire il trattamento di nuove entità (IUV, IUBD, …) introdotte in ottemperanza alle regole operative previste e di sostituire parte della piattaforma con una soluzione di mercato.
Più in dettaglio sono state adeguate le componenti di interfaccia verso i cittadini e verso i back-office applicativi degli Enti (Ascot, CUP, ….) mentre sono state sostituite le componenti di interfaccia verso il nodo e di gestione delle transazioni economiche con la soluzione alla base del servizio software acquisito con precedente procedura di affidamento in scadenza a novembre 2016.
Di seguito è riportato uno schema dei principali componenti della soluzione complessiva, in cui sono riportati in colore verde tutti i sistemi gestiti da INSIEL in cui, a vario titolo, vengono create le posizioni debitorie dei cittadini.
Allo stato attuale possiamo individuare:
• i sistemi CUP delle aziende sanitarie per i ticket;
• il sistema per la gestione buoni pasto nell’ambito della ristorazione scolastica;
• il sistema per la gestione delle licenze di pesca e il loro rinnovo
• il sistema tavolare.
In colore arancione sono evidenziati i moduli software legati a PagoPA in capo ad Insiel. Tra questi troviamo:
• PaymentProxy: tale modulo ha la responsabilità di veicolare verso il sistema di pagamento in via di acquisizione tutte le posizioni debitorie provenienti dagli N sistemi verticali e di gestire gli esiti delle operazioni di pagamento effettuate dagli utenti;
• Front end Utente: è rappresentato dall’insieme di servizi di pagamento messi a disposizione del cittadino nel contesto del portale dei servizi (xxxxxxx.xxxxxxx.xxx.xx), al pari di quanto avviene nell’attuale sistema;
• Giornale eventi: è un modulo che permette agli operatori Insiel ed eventualmente agli operatori degli enti coinvolti di verificare nel dettaglio tutte le informazioni inerenti a ogni singola operazione di pagamento effettuata dal sistema.
Questo modello consente di evitare l’implementazione nei diversi applicativi “verticali” INSIEL delle funzioni demandate al Payment Proxy e al Giornale eventi e di garantire, in virtù di possibili futuri cambi di Intermediario verso il nodo, un minor costo della soluzione da acquisire e anche l’indipendenza dalla stessa.
In colore rosso sono evidenziati le macro componenti della soluzione software esterna.
Tra queste troviamo:
• il sistema di pagamento: tale modulo ha la responsabilità di gestire le operazioni di pagamento e dell’interfacciamento con il nodo nazionale dei pagamenti;
• il Back office di rendicontazione: al pari dell’attuale sistema, il back office di rendicontazione permette agli operatori degli enti coinvolti di avere un quadro riassuntivo di quelli che sono i pagamenti che i cittadini hanno effettuato a loro favore;
• il Giornale eventi: è un modulo che permette agli operatori Insiel ed eventualmente agli operatori degli enti coinvolti di verificare nel dettaglio tutte le informazioni inerenti ad ogni singola operazione di pagamento effettuata dal sistema.
Infine in colore blu sono evidenziati il nodo nazionale dei pagamenti e i diversi prestatori di servizi di pagamento (PSP) accreditati presso il nodo stesso.
2.4.1 Modello concettuale dell’attuale sistema
Nello schema seguente è riportato il modello concettuale di funzionamento dell’attuale sistema.
Sotto la voce Stazione appaltante sono indicati i servizi resi disponibili dalla Scrivente, mentre sotto la voce Soluzione fornitore sono riportate le principali componenti della soluzione resa disponibile dall’attuale fornitore; vengono quindi indicate le comunicazioni in essere per l’interazione tra i sistemi della scrivente Stazione appaltante e dell’attuale fornitore:
Figura 1
3 Definizione dell’appalto
3.1 Oggetto
Insiel – Informatica per il Sistema degli Enti Locali S.p.A. per conto della Regione Friuli Venezia Giulia intende dotarsi di un Servizio di pagamento online interoperante con il nodo nazionale SPC dei pagamenti, in linea con le specifiche attuative rilasciate dall’Agenzia per l’Italia Digitale (AgID), per quanto concerne il nodo dei Pagamenti-SPC, e interoperante con il sistema regionale dei pagamenti implementato per la Regione FVG da Insiel.
L’affidatario DEVE fornire tale Servizio, garantendo il suo adeguamento relativamente alla normativa di settore e ai suoi aggiornamenti, e DEVE fornire servizi professionali correlati per 36 mesi, per un numero di Enti del territorio e di servizi applicativi collegati illimitati.
3.2 Durata dell’appalto
La durata del presente appalto decorre dalla data di avvio dell'esecuzione del contratto e termina dopo 36 (trentasei) mesi dalla data di avvio in esercizio del sistema risultato vincitore. La data di avvio dell'esecuzione del contratto sarà comunicata all’Appaltatore dal Direttore dell'esecuzione nominato dalla Società Appaltante, fermo restando che l’avvio dell’esecuzione dovrà avvenire entro e non oltre 30 (trenta) giorni naturali e consecutivi dalla data di stipula del contratto tra l’Aggiudicatario e la Società Appaltante, salvo diverso accordo scritto tra le Parti. In ogni caso, il Direttore dell’esecuzione redigerà apposito verbale di avvio dell'esecuzione del contratto, in contraddittorio con l'Appaltatore.
3.3 Caratteristiche del Servizio
L’Affidatario si impegna a fornire il Servizio applicativo di pagamento online interoperante con il nodo nazionale SPC dei pagamenti, comprensivo dei servizi professionali correlati di cui all’Oggetto, che garantisca:
1. completa interoperabilità con il nodo nazionale dei Pagamenti-SPC - con riferimento alle "Linee guida per l'effettuazione dei pagamenti elettronici a favore delle pubbliche amministrazioni e dei gestori di pubblici servizi";
2. supporto delle modalità di pagamento:
a. con esecuzione immediata,
b. con esecuzione differita
c. con esecuzione presso il PSP;
3. corretta gestione del pagamento del carrello di RPT;
4. servizi per il colloquio con il Modulo di interfacciamento, che colloquia con i sistemi degli Enti del FVG ed è gestito dall’intermediario tecnologico, ossia la scrivente Stazione Appaltante, in particolare (vedi Figura 1):
a. Richiesta IUV;
b. Verifica RPT;
c. Invio RPT;
d. Invio avviso di pagamento;
e. Richiesta RT;
f. Verifica validità @e.bollo
5. gestione POS fisico e contanti;
6. servizio @x.xxxxx, interoperante con componente trasversale realizzato dall’intermediario tecnologico per i sistemi applicativi degli Enti del territorio regionale che prevedano il pagamento di un bollo da parte dell’utenza esterna, realizzato coerentemente con i seguenti documenti:
• Agenzia delle Entrate :
Provvedimento del 19/09/2014 - pdf - Modalità di pagamento in via telematica dell'imposta di bollo dovuta per le istanze e per i relativi atti e provvedimenti trasmessi in via telematica ai sensi dell’art. 1, comma 596, della legge 27 dicembre 2013, n. 147 – servizio @e.bollo (Pubblicato il 19/09/2014);
• Agenzia per l’Italia Digitale:
Marca da bollo digitale - Linee guida per pubbliche amministrazioni e prestatori di servizi di pagamento - Art. 6, Comma 2, Provvedimento del Direttore dell’Agenzia delle Entrate del 19 Settembre 2014 - Release 1.0 Febbraio 2015 con particolare riferimento agli allegati del documento:
Allegato 1 - Documento ‘Analisi dei Requisiti/Specifica di Intervento’; Allegato 2 - Specifiche tecniche Rendicontazione IUDB venduti da PSP a AE;
Allegato 3 - Specifiche tecniche Rendicontazione Marche da Bollo Digitali da PA a AE; Allegato 4 - Specifiche Applicazione di controllo Marca da Bollo.
7. backoffice per gli operatori degli Enti con i seguenti requisiti:
a. accesso sicuro dell’utente per mezzo di autenticazione username e password;
b. interoperabilità con il Sistema Pubblico per la gestione dell'Identità Digitale – SPID;
c. piena autonomia, a valle della prima attivazione di ciascun Ente, degli operatori dell’Ente stesso nella gestione delle utenze abilitate al back office (creazione, modifica, cancellazione, abilitazione e disabilitazione);
d. possibilità di ricercare tutte le transazioni effettuate dagli utenti in un dato intervallo di tempo e per un dato servizio di pagamento (mense scolastiche, ticket sanitari, …);
e. possibilità di accedere ai dati di dettaglio di ogni transazione, comprensivi almeno dei seguenti dati:
i. IUV
ii. ente creditore,
iii. soggetto titolare della posizione debitoria,
iv. soggetto che ha effettuato il pagamento,
x. xxxxxxx xxx xxxxxxxxx,
xx. ricevuta di pagamento in formato pdf,
vii. RT in formato xml
viii. Stato del pagamento (comprensivo di stato e sua descrizione, qualora esista, data e cronologia degli stati);
f. possibilità di scaricare i flussi di rendicontazione recepiti dal Nodo dei pagamenti in formato xls o equivalente.
g. configurazione e scarico dei flussi di quadratura.
h. possibilità di gestire le operazioni di storno, seppur non utilizzate in una prima fase di erogazione del servizio e qualora siano previste dalla normativa.
8. Giornale eventi con log completo delle transazioni e possibilità di parametrizzazione delle funzioni per l’intermediario tecnologico,
9. Disponibilità di un ambiente di test capace di processare i pagamenti avviati sulla piattaforma offerta, secondo il protocollo stabilito dall’AGID per i PSP, in particolare con il modello dei pagamenti immediati
10. Servizi professionali correlati:
a. consulenza tecnica all’intermediario tecnologico per lo start-up del servizio complessivo;
b. assistenza specifica ai tecnici dell’intermediario tecnologico, in particolare in fase di attivazione di un nuovo Ente;
c. assistenza di secondo livello;
d. manutenzione adeguativa del servizio applicativo a nuove norme e regole eventualmente emanate dalle Autorità competenti.
11. SLA:
a. Copertura servizio di assistenza di secondo livello da lunedì al venerdì dalle 8:00 alle 18:00;
b. Periodo di disponibilità del servizio in rapporto alla totalità del tempo >=99,00%;
c. Tempo totale di completamento dell’intervento IMAC:
Gravità | 1 | 2 | 3 |
bloccante | 4h | 24h | 72h |
limitante | 24h | 72h | 140h |
non limitante | 72h | 140h | 240h |
Gravità 1: Grave indisponibilità del servizio che ha un serio impatto sulle attività degli utenti e non può essere aggirata;
Gravità 2: Parziale interruzione del servizio e non può essere aggirata;
Gravità 3: Servizio degradato, il disservizio può essere temporaneamente aggirato.
3.4 Uniformità del Layout della pagine WEB
Insiel intende fornire al cittadino un sistema user friendly con l’insieme delle pagine che compongono il Servizio il più uniformi possibile sia dal punto di visto grafico che di navigazione.
Per questo motivo Insiel aderisce al progetto xxxxxx.xxxxxx.xx .
All’indirizzo xxxx://xxxxxx.xxxxxx.xx/xxxxx-xxxxx/xx-xxxxxxxx/ AGID ha pubblicato le Linee guida di design per i siti web della PA.
AGID attraverso questo documento vuole promuovere un percorso condiviso e partecipato per rendere le amministrazioni pubbliche più moderne e per facilitare l’accesso ai servizi da parte di cittadini e imprese.
Le linee guida sono finalizzate a costruire un’identità visiva e un design coerente per tutti i siti web delle pubbliche amministrazioni.
Il documento presente sul sito AGID richiama i principi cardine nella progettazione e nello sviluppo dei siti web istituzionali degli enti pubblici:
• la centralità dell’utilizzatore (utente della PA o cittadino o impresa);
• la chiarezza;
• la facilitazione delle procedure;
• l’inclusività.
• Il disegno coerente, non uniforma.
Le linee guida approfondiscono i profili di usabilità e di accessibilità dei siti web in coerenza con la normativa e i precedenti documenti emanati dal Dipartimento della Funzione Pubblica.
La progettazione dei siti web istituzionale costituisce la pietra angolare per sviluppare, migliorare la consultazione dei servizi digitali a favore di cittadini e imprese.
Ogni sito web della PA rappresenta uno strumento che:
• agevola eabilita i servizi all’utenza;
• favorisce erealizza la trasparenza amministrativa;
• consente diraggiungere i cittadini ecostruire un nuovo rapporto di partecipazione, ascolto e condivisione.
Attraverso la piattaforma, sono messi a disposizione molteplici strumenti tecnici e interattivi (stringhe di codici html per la progettazione di elementi grafici e architetturali) per proporre osservazioni sul design e sui codici, segnalando anche criticità ed errori.
Insiel ha deciso che tutti i nuovi siti che verranno realizzati saranno progettati e realizzati secondo tali linee guida; inoltre nel tempo effettuerà analogo restyling dei siti web già in produzione mediante una loro manutenzione evolutiva.
I partecipanti alla gara non hanno l’obbligo di aderire agli standard previsti nelle linee guida AGID nell’ambito dei loro Servizi, ma nelle offerte ricevute relative al presente capitolato, verrà considerato dalla Stazione Appaltante un elemento premiante il fatto che le interfacce web del partecipante al bando rispondano alle Linee Guide AGID in termini di:
1. Usabilità
2. Principi
3. Misurazione
4. Accessibilità
5. Gestione contenuti
6. Architettura dell'informazione
7. Header
8. Footer
9. Layout
10. Tipografia
11. Colori
12. Bottoni
13. Form
14. Iconografia
15. Componenti
(vedi : xxxx://xxxxxx.xxxxxx.xx/xxxxx-xxxxx/xxxxxxxxx/ e, sulla singola voce, verificare se le proprie interfaccia rispondono al ‘SI DEVE’).
Il partecipante DOVREBBE indicare brevemente per ogni punto se la soluzione proposta è compliant alla direttiva, laddove questa impatta con il Servizio oggetto di Gara.
3.5 Ulteriori Obblighi dell’Affidatario
• L’Affidatario in quanto PSP già operativo e abilitato sulla piattaforma AGID, DEVE accettare di svolgere il ruolo di PSP pilota in produzione, in modo da poter supportare i modelli dei pagamenti previsti dalla normativa e, laddove previsto, quello di @e.bollo, così da garantire un avvio in produzione con pagamenti canalizzati sul PSP stesso, al fine di effettuare una sperimentazione più completa prima di aprire ai PSP i diversi Enti.
• L’Affidatario si impegna a garantire l’autenticazione degli operatori degli Enti coinvolti con credenziali SPID.
3.6 Modalità di attivazione ed erogazione del servizio
Il Servizio con le caratteristiche sopra indicate dovrà essere attivato a partire dalla stipula del contratto, rispettivamente:
▪ in ambiente di test entro 15 giorni ;
▪ in ambiente di esercizio entro un mese.
Sarà effettuata una sperimentazione per un periodo di due mesi per una tipologia di pagamento già attivato presso gli Enti della Regione FVG.
La sperimentazione riguarderà anche l’uniformazione delle pagine web Insiel e di quelle dell’affidatario come previsto in § 3.4.
A valle del periodo di sperimentazione il servizio di pagamento online dovrà essere erogato fino allo scadere dei 36 mesi dalla stipula del contratto per tutti gli Enti del territorio regionale del Friuli Venezia Giulia – 216 Comuni, 18 UTI, 4-5 Enti Regionali, 5 Aziende sanitarie e 2 IRCCS -, che ne facciano richiesta e per qualsiasi tipologia di pagamento, senza limiti alla numerosità.
3.7 Demo
Insiel, in fase di valutazione delle offerte, potrà richiedere al concorrente di:
• presentare una demo di funzionamento del sistema presso la sede Insiel di Trieste;
• presentare documentazione su applicazioni precedenti di successo in contesti operativi omogenei con riscontro da parte dell’utilizzatore finale.
4 Servizi professionali correlati
4.1 Consulenza tecnica per lo start up
Il concorrente DEVE prevedere un piano di start up dettagliato e completo, comprensivo di consulenza tecnica al personale dello scrivente intermediario tecnologico, mirata a garantire il corretto colloquio con i sistemi degli Enti del territorio attraverso le interfacce di cui al § 3.3, e il corretto supporto nella fase di test complessivo del servizio.
In fase di offerta il concorrente DEVE descrivere il percorso di start up più opportuno per rispondere ai requisiti sopra indicati, illustrando modalità, contenuti e durata.
L’attività di consulenza tecnica PUO’ essere svolta presso le sedi degli operatori, DEVE essere effettuata in date ed orari concordati con la scrivente stazione appaltante e DEVE permettere ai soggetti interessati di raggiungere la completa padronanza degli strumenti disponibili e il loro pieno sfruttamento ai fini del processo di servizio.
Il concorrente per garantire il corretto servizio di consulenza PUO’ organizzare, in accordo con il cliente, workshop tecnici tenuti da relatori esperti e riunioni specifiche.
4.2 Assistenza specifica
L’aggiudicatario DEVE garantire un servizio di assistenza specifica, mirato a supportare e collaborare con l’intermediario tecnologico per tutta la durata del contratto, in particolare nella fase di sperimentazione e nelle fasi di attivazione di un Ente o di un nuovo servizio di pagamento.
4.3 Assistenza di secondo livello
Il servizio di Help Desk DEVE essere erogato direttamente dalla Società Appaltante attraverso il proprio Centro di Supporto: il Centro di Supporto della società Appaltante rappresenta il Centro responsabile della gestione dei processi operativi a supporto di tutti i servizi erogati da INSIEL.
L’aggiudicatario DEVE garantire un servizio di assistenza di secondo livello per un periodo di 36 (trentasei) mesi dall’attivazione del Servizio applicativo.
L’Appaltatore DEVE rendere disponibile il servizio tutti i giorni feriali, dal lunedì al venerdì, dalle ore
8.00 alle ore 18.00.
L’assistenza di II livello DEVE essere garantita attraverso i seguenti canali:
• telefono;
• fax;
• e-mail;
• web-form.
Il servizio di assistenza di secondo livello PUO’ essere contattato in generale per:
• segnalazione di malfunzionamenti nel servizio applicativo fornito;
• richiesta di aiuto per la soluzione di problemi procedurali, o di chiarimenti sull’utilizzo delle procedure da parte di referenti dell’utenza;
• supporto tecnico per l'individuazione di eventuali risposte applicative a esigenze non coperte dall’informatizzazione corrente.
Con riferimento al servizio, nel corso del periodo contrattuale. l’Appaltatore DEVE prevedere e rendere disponibile, anche in formato digitale elaborabile, la seguente documentazione:
• Rapporto sull’attività (trimestrale),
comprensivo di schede informative di sintesi dei casi gestiti nel periodo, con, per ciascun caso, gli elementi identificativi e significativi dell’utente chiamante, del problema, della risoluzione:
🢭 numero interventi effettuati;
🢭 tipo degli interventi;
🢭 analisi di SLA;
🢭 dettaglio di ogni singolo intervento:
🢭 identificativo dell’intervento;
🢭 modalità di ricezione richiesta (telefono, internet, fax, mail, ecc.) ;
🢭 elementi identificativi della richiesta;
🢭 descrizione;
🢭 orario di inizio e fine intervento;
🢭 esito dell’intervento.
• Rendicontazione di consuntivo sull’operatività del servizio (report trimestrale),
che DEVE riportare informazioni statistiche sulle richieste di assistenza evase, sulla distribuzione dei problemi riscontrati, sui servizi interessati dai problemi, ecc..
4.4 Manutenzione adeguativa
L’aggiudicatario DEVE garantire un costante servizio di manutenzione adeguativa ed eventualmente evolutiva, del servizio applicativo offerto alle nuove norme e regole che dovessero venire emanate dalle Autorità competenti nel periodo contrattuale o agli eventuali aggiornamenti di norme e regole esistenti, garantendo la tempestività degli adeguamenti e la continuità del servizio.
5 Caratteristiche generali del sistema applicativo a supporto del Servizio
5.1 Accessibilità ed usabilità
Il sistema applicativo DEVE rispettare le norme di accessibilità così come stabilito dalla Legge 9 gennaio 2004 n. 4 (c.d. “legge Stanca”) e del successivo Decreto del Presidente della Repubblica, 1 marzo 2005, n. 75 “Regolamento di attuazione della legge 9 gennaio 2004, n. 4 per favorire l'accesso dei soggetti disabili agli strumenti informatici”. In particolare, DEVONO essere rispettate tutte le indicazioni riportate nel Decreto Ministeriale 8 luglio 2005 (G.U. 8 agosto 2005, n. 183): “Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici”.
5.2 Protezione dati personali
Il sistema applicativo DEVE prevedere meccanismi di autenticazione, autorizzazione e profilatura per l’accesso alle funzionalità previste, ai dati ed ai file trattati. Per il trattamento dei dati personali anche di natura sensibile il sistema DEVE inoltre prevedere tutti gli adempimenti a tutela della riservatezza e della sicurezza dei dati, pertanto DEVE essere rispettata la normativa in materia di protezione dei dati personali di cui al Decreto legislativo 30 giugno 2003, n. 196 e successive modificazioni ed integrazioni.
5.3 Requisiti di qualità
Per quanto riguarda il monitoraggio qualitativo del risultato finale, sia in termini di funzionalità che di efficacia, sarà applicato il modello per la qualità delle forniture ICT predisposto dal CNIPA (Manuale 6
2.1 del 19/01/2006). Tale modello si compone di 10 caratteristiche di qualità e 27 sottocaratteristiche, tutte riportate nella tabella a seguire.
CARATTERISTICA | DESCRIZIONE | SOTTOCARATTERISTICHE ASSOCIATE |
Funzionalità | Nel servizio/prodotto sono presenti le funzioni che, con le relative proprietà, gli conferiscono la capacità di soddisfare le esigenze dell’utente | - adeguatezza (funzioni appropriate per i compiti specificati); - accuratezza (risultati corretti e precisi); - interoperabilità (con sistemi specificati); - sicurezza (protezione dei dati dai non autorizzati); - conformità (rispetto di standard e normative) |
Affidabilità | Capacità di mantenere un determinato livello di operatività in determinate condizioni di utilizzo | - maturità (puntualità nell’erogazione); |
- tolleranza (livello minimo di prestazioni in caso di malfunzionamenti); - ripristinabilità (ripristino di un livello adeguato di prestazioni); - conformità (rispetto a standard o regole su affidabilità) | ||
Usabilità | Capacità del servizio/prodotto di essere compreso, imparato, usato ed essere attraente per l’utilizzatore, quando sia usato in condizioni specificate | - comprensibilità (capacità di mettere l’utente in grado di utilizzarlo); - apprendibilità (capacità di impararlo); - operabilità (mettere in grado l’utente di controllare l’avanzamento di una richiesta); - attrattività (capacità di essere attraente, comodo); - conformità (rispetto di standard o regole inerenti l’usabilità) |
Efficienza | Capacità del servizio/prodotto di fornire appropriate prestazioni relativamente alla quantità di risorse usate, in condizioni stabilite | - temporale (rispondere tempestivamente); - utilizzo delle risorse (usare quantità e tipi appropriati di risorse); - conformità (rispetto di standard e convenzioni sull’efficienza) |
Manutenibilità | Capacità del servizio/prodotto di essere modificato. Le modifiche possono includere interventi sull’organizzazione, le risorse e gli strumenti a fronte di cambiamenti di ambiente, e di requisiti e specifiche funzionali | - analizzabilità (capacità di diagnosticare deficienze); - modificabilità (capacità di modificare); - stabilità (capacità di evitare effetti inattesi); - testabilità (capacità di validare); - conformità (capacità di rispettare standard o regole di manutenibilità) |
Efficacia | Capacità di mettere in grado gli utenti di raggiungere obiettivi specificati con accuratezza e completezza in un contesto d’uso specificato | |
Produttività | Capacità di mettere in grado gli utenti di impiegare quantità di risorse appropriate in relazione all’efficacia ottenuta in un contesto d’uso specificato | |
Salvaguardia | Capacità di ottenere livelli di rischio accettabili |
per danni alle persone, all’azienda, al software, alla proprietà o all’ambiente in uno specifico contesto d’uso | ||
Soddisfazione | Capacità di soddisfare gli utenti in uno specificato contesto d’uso (la soddisfazione è la risposta dell’utente all’interazione con il servizio) |
6 Disposizioni contrattuali
6.1 Referente per l’affidamento
INSIEL designerà il responsabile dell’esecuzione del contratto, che fungerà da unica interfaccia verso l’Aggiudicatario per le attività oggetto del presente documento.
L’Aggiudicatario dovrà designare un proprio referente, che risulti unica interfaccia nei confronti di INSIEL per l’oggetto del presente documento. Il referente dell’Aggiudicatario avrà inoltre il compito di far osservare al personale impiegato nel servizio i compiti e le funzioni previste nel presente documento.
Il responsabile dell’esecuzione del contratto verrà nominato all’atto della stipulazione del contratto con l’Aggiudicatario e dovrà verificare il corretto svolgimento della fornitura.
Il nominativo e i riferimenti (numero di telefono, fax, email) del referente dell’Aggiudicatario dovranno essere comunicati in sede di compilazione dell’offerta tecnica.
6.2 Verifica di conformità
Il presente affidamento è soggetto a verifica di conformità, al fine di accertarne la regolare esecuzione, rispetto alle condizioni ed ai termini stabiliti nel contratto.
La verifica di conformità dei servizi oggetto del presente contratto sarà trimestrale.
La prima verifica di conformità sarà avviata entro il termine di 10 giorni dalla fine del trimestre seguente l’avvio dell’esecuzione del servizio. Insiel provvederà a dare tempestivo avviso all’Aggiudicatario sul giorno in cui si procederà alla verifica di conformità, affinché l’Aggiudicatario possa intervenire. In sede di verifica di conformità verrà redatto un verbale che dovrà essere sottoscritto da tutti i soggetti intervenuti. Successivamente verrà emesso il Certificato di verifica di conformità che sarà trasmesso per la sua accettazione all’Aggiudicatario, il quale dovrà firmarlo entro il termine di 15 giorni dal ricevimento dello stesso.
Nel caso di contestazione da parte di Insiel, l’Aggiudicatario dovrà a sua cura e spese provvedere all’eliminazione di vizi, dei difetti o delle carenze riscontrate entro il termine di 7 giorni lavorativi successivi a quello dell’invio della contestazione.
6.3 Fatturazione e pagamento
A seguito della positiva verifica di conformità di cui al precedente paragrafo 6.2 “Verifica di conformità” ossia in seguito all’emissione del Certificato di conformità, L’Aggiudicatario potrà emettere fattura per
un valore pari ad un dodicesimo dell’importo contrattuale.
I pagamenti delle fatture avverranno a 30 gg. fine mese, dalla data di protocollazione delle fatture in Insiel, purché le stesse siano emesse in conformità a quanto espresso nel presente documento e fatti salvi i tempi richiesti per le verifiche imposte dalla normativa al riguardo.
Le fatture emesse saranno accettate ai sensi del D.M. n. 55 del 3 aprile 2013 solo se emesse nel formato previsto dal suddetto decreto mediante inoltro al Sistema di Interscambio (SdI). Il Codice Univoco Ufficio di Insiel è 5Q9X3U. Le fatture vs Insiel non sono soggette a split payment.
Il pagamento avverrà mediante versamento sul conto corrente bancario intestato all’Aggiudicatario; gli estremi del conto corrente dovranno essere riportati nelle relative fatture e comunicati per iscritto ad INSIEL nel rispetto dell’art. 3 comma 7 della legge n. 136 del 13 agosto 2010.
Tutti i documenti, comprese le fatture, dovranno riportare chiaramente il numero CIG del lotto in questione, il numero di contratto Insiel, la seguente descrizione “GE 05-16 SERVIZI DI PAGAMENTO ONLINE COMPLIANT CON IL NODO SPC” e dovrà essere allegata copia del certificato di conformità di cui al paragrafo 6.2 “Verifica di conformità”. Non saranno accettate fatture o altre comunicazioni prive dei suddetti riferimenti.
6.4 Penali
Penali sui ritardi relativi alla risoluzione dei malfunzionamenti (guasti)
Fatto salvo il maggior danno, a garanzia del corretto e tempestivo adempimento degli obblighi dell’Aggiudicatario, INSIEL potrà applicare, nelle ipotesi di inadempimento parziale ovvero di ritardato adempimento, le penali previste e descritte di seguito.
Qualora la percentuale di chiamate che hanno avuto risposta nei tempi previsti nel trimestre risulti inferiore a quella prevista per qualsiasi livello di servizio indicato al paragrafo 2.2, punto 11 “SLA” relativamente a detti scostamenti ( percentuale rilevata – percentuale prevista dal livello di servizio) potrà essere applicata una penale il cui importo verrà determinato con le seguenti modalità:
(percentuale prevista dal livello di servizio – percentuale rilevata) x corrispettivo dovuto nel trimestre di riferimento, fino ad un importo massimo corrispondente al 20% del corrispettivo trimestrale.
Insiel, nel caso di segnalazioni non risolti entro il tempo di risoluzione massimo accettabile, notificherà all’Aggiudicatario, mediante comunicazione scritta, l’applicazione della penale.
I termini sopra indicati terranno conto delle eventuali migliorie presentate dall’Aggiudicatario in sede di offerta.
L’importo delle penalità potrà essere detratto in sede di liquidazione della fattura e/o potrà essere recuperato mediante escussione della garanzia presentata.
6.5 Obblighi di tracciabilità dei flussi finanziari – Legge n. 136/2010
L’aggiudicatario assume tutti gli obblighi di tracciabilità dei flussi finanziari di cui all’articolo 3 della legge 13 agosto 2010, n. 136 e successive modifiche.
L’aggiudicatario si impegna a comunicare ad INSIEL gli estremi dei conti correnti bancari o postali dedicati, anche non in via esclusiva, al presente appalto nonché le generalità ed il codice fiscale delle persone delegate ad operare su di essi. L’aggiudicatario si impegna a comunicare ad INSIEL ogni modifica relativa ai dati trasmessi.
Qualora le operazioni finanziarie relative al presente appalto siano state eseguite senza avvalersi del bonifico bancario o postale ovvero degli altri strumenti idonei a consentirne la piena tracciabilità, il contratto si intenderà risolto di diritto.
6.6 Esecuzione in danno
In caso di risoluzione del presente affidamento sia ai sensi dell’art. 1662 che ai sensi dell’art. 1456 c.c. INSIEL si riserva il diritto di affidare a terzi l’esecuzione di quanto necessario al regolare completamento delle attività oggetto del presente affidamento, con addebito dell’eventuale maggior costo all’Aggiudicatario.
Nei suddetti casi, Insiel avrà inoltre facoltà di differire il pagamento delle somme dovute al momento della risoluzione, al fine di quantificare il danno che l’Aggiudicatario è eventualmente tenuto a risarcire, nonché di operare le opportune compensazioni tra tali importi.
L’eventuale esecuzione in danno non esime l’Aggiudicatario dalle responsabilità civili, penali e amministrative in cui lo stesso può incorrere a norma di legge.
6.7 Risoluzione e Clausola risolutiva espressa
Nel caso in cui INSIEL accerti che l’esecuzione del contratto da parte del Fornitore non proceda secondo le condizioni nel medesimo stabilite, concederà al Fornitore, previa formale comunicazione (eseguibile anche con la Posta Elettronica Certificata PEC), un preavviso di almeno 15 (quindici) giorni per porre fine all’inadempimento; trascorso inutilmente detto termine il contratto si riterrà risoluto, salvo il diritto di INSIEL al risarcimento del danno ai sensi dell’art. 1662 c.c..
Oltre a quanto previsto dall’art. 108 del D.Lgs. 50/2016, INSIEL si riserva il diritto di risolvere il contratto nel caso in cui l’ammontare complessivo delle penali, derivanti dall’applicazione singola o ripetuta delle clausole previste dal paragrafo 6.4 Penali, superi il 10% del valore del contratto, ovvero nel caso di gravi inadempienze agli obblighi contrattuali da parte dell’appaltatore. In tal caso INSIEL avrà la facoltà di incamerare la cauzione definitiva, nonché di procedere all’esecuzione in danno del Fornitore. Resta salvo il diritto al risarcimento dell’eventuale maggior danno.
Fermo restando quanto sopra, INSIEL potrà dichiarare la risoluzione di diritto ai sensi dell’art. 1456 del codice civile, da comunicarsi a mezzo P.E.C. nelle ipotesi di:
a) accoglimento di una domanda o di un ricorso nei confronti del Fornitore, ai sensi della Legge Fallimentare o di altra legge applicabile in materia di procedure concorsuali, che determini lo scioglimento, la liquidazione, la composizione amichevole, la ristrutturazione dell’indebitamento o il concordato con i creditori, ovvero nel caso in cui venga nominato un liquidatore, curatore, custode o soggetto avente simili funzioni, il quale entri in possesso dei beni o venga incaricato della gestione degli affari del Fornitore;
b) mancato rispetto degli obblighi contrattuali e di legge nei confronti del personale e di mancata copertura assicurativa dei rischi da responsabilità civile, in ordine allo svolgimento di tutte le attività contrattuali, per l’intera durata del Contratto;
c) violazione dell’obbligo del segreto d’ufficio da parte del personale del Fornitore su fatti e circostanze di cui venga a conoscenza nell’espletamento dei propri compiti ovvero comportamenti diretti a influire sul regolare e programmato svolgimento dell’attività di INSIEL;
d) conferimento, in qualsiasi forma, di procure all’incasso; cessione, totale o parziale, diretta o indiretta, del Contratto, oppure cessione non autorizzata dei crediti da quest’ultimo derivanti;
e) azioni giudiziarie per violazioni di diritti di brevetto e/o di autore ed in genere di privativa altrui, intentate contro INSIEL in ragione del presente contratto.
f) qualora nei confronti del Fornitore sia intervenuta l'emanazione di un provvedimento definitivo che dispone l'applicazione di una o più misure di prevenzione di cui all'articolo 6, del D. Lgs. 159/2011, ed e ai titoli I e II del Libro I “Le misure di prevenzione” del D. Lgs. 159/2011, ovvero sia intervenuta sentenza di condanna passata in giudicato per delitti contro la Pubblica Amministrazione, l’ordine pubblico, la fede pubblica o il patrimonio, per frodi nei riguardi di INSIEL, di subappaltatori, di lavoratori o di altri soggetti comunque interessati all’appalto, nonché per violazione degli obblighi attinenti alla sicurezza sul lavoro.
6.8 Recesso
Insiel ha diritto di recedere dal contratto per sopravvenuti motivi di pubblico interesse, previa formale comunicazione (eseguibile anche con la Posta Elettronica certificata PEC) al Fornitore con preavviso di almeno 20 (venti) giorni. In tal caso INSIEL, ai sensi dell’art. 109 del D.Lgs. 50/2016, sarà tenuta al pagamento:
- delle sole prestazioni eseguite e ritenute regolari al momento in cui viene comunicato l’atto di recesso, così come attestate dal verbale di verifica redatto da INSIEL;
- delle spese sostenute dal Fornitore;
- di un decimo dell’importo del servizio non eseguito calcolato sulla differenza tra l’importo dei 4/5 del prezzo contrattuale e l’ammontare netto delle prestazioni eseguite.
Dalla data di comunicazione del recesso, il Fornitore dovrà cessare tutte le prestazioni contrattuali, assicurando che tale cessazione non comporti alcun danno ad INSIEL.
INSIEL si riserva la facoltà di recedere dal contratto ex art. 1 comma 13 della legge 7 agosto 2012, n. 135, previa formale comunicazione (eseguibile anche con la Posta Elettronica certificata PEC) al Fornitore con preavviso di almeno 20 (venti) giorni e previo pagamento delle prestazioni già eseguite oltre al decimo delle prestazioni non ancora eseguite, nel caso in cui, tenuto conto delle prestazioni non ancora eseguite, qualora i parametri delle convenzioni stipulate da Consip S.p.A., ai sensi dell’articolo 26, comma 1, della legge 23 dicembre 1999, n. 488 successivamente alla stipula del predetto contratto, siano migliorativi rispetto a quelli del presente contratto e il Fornitore non acconsenta ad una modifica, proposta da Consip S.p.A., delle condizioni economiche tale da rispettare il limite di cui all’articolo 26, comma 3 della legge 23 dicembre 1999, n. 488.
6.9 Subentro nel contratto
L’Aggiudicatario riconosce alla Regione Autonoma Friuli Venezia Giulia, in ogni momento e per l’intera durata del contratto, la facoltà di subentrare ad INSIEL nel rapporto contrattuale. Tale cessione sarà efficace a seguito di mera comunicazione da parte del soggetto cessionario e la medesima avverrà senza alcun onere aggiuntivo per il soggetto cessionario rispetto a quanto già corrisposto o da corrispondere e con effetto pienamente liberatorio per INSIEL.
INSIEL si impegna a dare tempestiva comunicazione scritta all’Aggiudicatario, in merito all’intenzione da parte della Regione Autonoma Friuli Venezia Giulia di esercitare la facoltà di cui al precedente comma, mediante lettera raccomandata con avviso di ricevimento. L’Aggiudicatario si impegna, ora per allora, a compiere, in tale ipotesi, tutte le relative formalità nei tempi e nei modi richiesti dalla Regione Autonoma Friuli Venezia Giulia.
6.10 Documento Unico di Regolarità Contributiva (D.U.R.C.)
La stazione appaltante provvederà a richiedere agli Istituti Competenti il D.U.R.C. (Documento Unico di Regolarità Contributiva) dell’Aggiudicatario così come previsto ai sensi dell’art. 16-bis, comma 10, della legge 2/2009 di conversione del d.l. 185/2008.
6.11 Revisione dei corrispettivi
E’ prevista la revisione del corrispettivo.
La revisione del corrispettivo, su motivata richiesta dell’aggiudicatario, è concessa sulla base di una istruttoria condotta da INSIEL. La revisione avrà effetto a decorrere dalla data della sua comunicazione all’aggiudicatario.
6.12 Cessione dei crediti
È esclusa la cessione dei crediti nascenti dal presente appalto,