OPIS PRZEDMIOTU ZAMÓWIENIA
Załącznik nr 1 do SWZ
OPIS PRZEDMIOTU ZAMÓWIENIA
dla zamówienia pn.:
„Zakup oprogramowania, wdrożenie e-usług oraz zakup urządzeń do zdalnego odczytu wody na
potrzeby Gminy Michałowice”
Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Mazowieckiego 2014-2020; Działanie 2.1 E-usługi, Poddziałanie 2.1.2 E -usługi dla Mazowsza w ramach ZIT
Michałowice, wrzesień 2021 r.
1.1 Miejsce realizacji dostaw i usług 5
1.2 Termin i Harmonogram Wykonania Zamówienia 6
1.3 Zakres działań do realizacji w ramach zamówienia 7
2 ANALIZA SYTUACJI BIEŻĄCEJ W URZĘDZIE GMINY MICHAŁOWICE 10
2.1 Struktura organizacyjna Urzędu Gminy Michałowice 10
2.2 Opis stanu istniejącego - Infrastruktura techniczna 12
3 OCZEKIWANE ROZWIĄZANIE TECHNOLOGICZNE - OGÓLNE WYMAGANIA DOTYCZĄCE SYSTEMU INFORMATYCZNEGO ORAZ ROZWIĄZAŃ 14
3.1 Wymagania niefunkcjonalne – podstawowe parametry 15
3.2 Wymagania niefunkcjonalne - dostosowanie do obowiązujących norm krajowych
3.3 Wymagania niefunkcjonalne - bezpieczeństwo wdrażanych systemów informatycznych oraz przetwarzania danych 18
3.4 Wymagania niefunkcjonalne - Wymagania wynikające z wytycznych Web Content Accessibility Guidelines 19
3.5 Wykorzystanie technologii chmury obliczeniowej i kompatybilność z urządzeniami mobilnymi 25
4 ZAKUP LICENCJI, URZĄDZEŃ DO ZDALNEGO ODCZYTU WODY ORAZ WDROŻENIE E- USŁUG 26
4.1 Najważniejsze cechy systemu informatycznego 26
4.1.2 Ogólne warunki licencjonowania dostarczonych systemów informatycznych 34
4.1.3 Metody uwierzytelniania 35
4.1.4 Minimalne wymagania w zakresie bazy danych 35
4.2 Szczegółowy zakres i wymagania przedmiotu Zamówienia 40
4.2.1 Portal Systemu (Portal) 40
4.2.2.1 Minimalne wymagania techniczne wodomierzy oraz zestawu inkasenckiego 43
4.2.2.2 Minimalne wymagania funkcjonalne systemu obsługi wody 47
4.2.2.3 Opis e-usług, procesów i podprocesów wymaganych do obsługi dostaw wody 53
4.2.3 System obsługi placówek oświatowych (obsługa rekrutacji) 71
4.2.4 Modernizacja systemów dziedzinowych 78
4.2.4.1 System Podatków i Opłat Lokalnych (SPiOL) i inne 78
4.2.4.2 System Finansowo – Budżetowy (SFB) 87
4.2.4.3 Moduł Backupu Danych Archiwalnych 88
4.2.5 Integracja EZD z systemami dziedzinowymi 90
4.3.2 Szkolenie z wdrażanych rozwiązań 92
4.4.2 Dokumentacja Administratora „Rozwiązania” 100
4.4.3 Dokumentacja użytkownika „Rozwiązania” 100
4.4.4 Dokumentacja powykonawcza „Rozwiązania” 100
4.4.5 Dokumentacja Migracji danych 102
4.5 Gwarancja i Asysta techniczna 103
Opisane poniżej wymagania stanowią zakres minimalnych oczekiwań Zamawiającego
dla dostaw i usług.
OGÓLNE ZASADY RÓWNOWAŻNOŚCI ROZWIĄZAŃ:
1. W celu zachowania zasad neutralności technologicznej i konkurencyjności dopuszcza się rozwiązania równoważne do wyspecyfikowanych, przy czym za rozwiązanie równoważne uważa się takie rozwiązanie, które pod względem technologii, wydajności i funkcjonalności nie odbiega znacząco od technologii funkcjonalności i wydajności wyszczególnionych w rozwiązaniu wyspecyfikowanym, przy czym nie podlegają porównaniu cechy rozwiązania właściwe wyłącznie dla rozwiązania wyspecyfikowanego, takie jak: zastrzeżone patenty, własnościowe rozwiązania technologiczne, własnościowe protokoły itp., a jedynie te, które stanowią o istocie całości zakładanych rozwiązań technologicznych i posiadają odniesienie w rozwiązaniu równoważnym. W związku z tym, Wykonawca może zaproponować rozwiązania, które realizują takie same funkcjonalności wyspecyfikowane przez Zamawiającego w inny, niż podany sposób, za rozwiązanie równoważne nie można uznać rozwiązania identycznego (tożsamego), a jedynie takie, które w porównywanych cechach wykazuje dokładnie tą samą lub bardzo zbliżoną wartość użytkową. Przez bardzo zbliżoną wartość użytkową rozumie się podobne, z dopuszczeniem nieznacznych różnic niewpływających w żadnym stopniu na całokształt systemu, zachowanie oraz realizowanie podobnych funkcjonalności w danych warunkach, dla których to warunków rozwiązania te są dedykowane. Rozwiązanie równoważne musi zawierać dokumentację potwierdzającą, że spełnia wymagania funkcjonalne Zamawiającego, w tym wyniki porównań, testów, czy możliwości oferowanych przez to rozwiązanie w odniesieniu do rozwiązania wyspecyfikowanego. Dostarczenie przez Wykonawcę rozwiązania równoważnego musi być zrealizowane w taki sposób, aby wymiana oprogramowania na równoważne nie zakłóciła bieżącej pracy Urzędu. W tym celu Wykonawca musi do oprogramowania równoważnego przenieść wszystkie dane niezbędne do prawidłowego działania nowych systemów, przeszkolić użytkowników, skonfigurować oprogramowanie, uwzględnić niezbędną asystę pracowników Wykonawcy w operacji uruchamiania oprogramowania w środowisku produkcyjnym itp.
2. Dodatkowo, wszędzie tam, gdzie zostało wskazane pochodzenie (marka, znak towarowy, producent, dostawca itp.) materiałów lub normy, aprobaty, specyfikacje i systemy, o których mowa w ustawie Prawo Zamówień Publicznych, Zamawiający dopuszcza oferowanie sprzętu lub rozwiązań równoważnych pod warunkiem, że zapewnią uzyskanie parametrów technicznych nie gorszych niż wymagane przez Zamawiającego w dokumentacji przetargowej. Zamawiający informuje, że w takiej
sytuacji przedmiotowe zapisy są jedynie przykładowe i stanowią wskazanie dla Wykonawcy, jakie cechy powinny posiadać składniki użyte do realizacji przedmiotu zamówienia. Zamawiający zgodnie z art. 99 ust. 6 ustawy z dnia 24 października 2019
r. Prawo zamówień publicznych, zwanej dalej ustawą, dopuszcza oferowanie materiałów lub urządzeń równoważnych. Materiały lub urządzenia pochodzące od konkretnych producentów określają minimalne parametry jakościowe i cechy użytkowe, a także jakościowe (x.xx.: wymiary, skład, zastosowany materiał, kolor, odcień, przeznaczenie materiałów i urządzeń, estetyka itp.), jakim muszą odpowiadać materiały lub urządzenia oferowane przez Wykonawcę, aby zostały spełnione wymagania stawiane przez Zamawiającego. Operowanie przykładowymi nazwami producenta ma jedynie na celu doprecyzowanie poziomu oczekiwań Zamawiającego w stosunku do określonego rozwiązania. Posługiwanie się nazwami producentów/produktów ma wyłącznie charakter przykładowy. Zamawiający, wskazując oznaczenie konkretnego producenta (dostawcy), konkretny produkt lub materiały przy opisie przedmiotu zamówienia, dopuszcza jednocześnie produkty równoważne o parametrach jakościowych i cechach użytkowych, co najmniej na poziomie parametrów wskazanego produktu, uznając tym samym każdy produkt o wskazanych lub lepszych parametrach.
3. Zamawiający opisując przedmiot zamówienia przy pomocy określonych norm,
aprobat czy specyfikacji technicznych i systemów odniesienia, o których mowa w art.
101 ust. 1-3 ustawy, zgodnie z art. 101 ust.4 ustawy dopuszcza rozwiązania równoważne opisywanym. Zgodnie z art. 101 ust. 5 ustawy – Zamawiający nie może odrzucić oferty tylko dlatego, że oferowane roboty budowlane, dostawy lub usługi nie są zgodne z normami, ocenami technicznymi, specyfikacjami technicznymi i systemami referencji technicznych, do których opis przedmiotu zamówienia się odnosi, pod warunkiem że wykonawca udowodni w ofercie, w szczególności za pomocą przedmiotowych środków dowodowych, że proponowane rozwiązania w równoważnym stopniu spełniają wymagania określone w opisie przedmiotu zamówienia.
1.1 Miejsce realizacji dostaw i usług
Dostawy i usługi będą realizowane w siedzibie Zamawiającego, tj. w Urzędzie Gminy
Michałowice.
Dokładny adres realizacji przedmiotu zamówienia
Urząd Gminy Michałowice
Xx. Xxxxxxxxxx Xxxxxxxx 0
00-000 Xxxxxxxxxxx
Szczegółowy zakres dostaw oraz usług do wykonania zostanie przedstawiony w dalszej części niniejszego załącznika.
1.2 Termin i Harmonogram Wykonania Zamówienia
Wymagany termin wykonania Zamówienia – 180 dni kalendarzowych od dnia podpisania umowy.
Przedmiot Zamówienia musi być wykonany zgodnie z poniższym Harmonogramem. Harmonogram realizacji poszczególnych etapów realizacji zamówienia:
Lp. | Nazwa zadania | Termin realizacji1 |
Etap I | Zakup i dostawa urządzeń do zdalnego odczytu wody. | Sukcesywne dostawy od stycznie do maja 2022 r2. |
Etap II | Dostawa licencji oraz wdrożenie systemów informatycznych objętych zamówieniem | 90 dni od daty podpisania umowy |
Etap III | Szkolenia użytkowników i administratorów oraz uruchomienie wszystkich elementów systemu wraz z uruchomieniem e-usług oraz integracją rozwiązań | 90 dni od daty zakończenia etapu II |
Przedmiot umowy będzie realizowany zgodnie z zatwierdzonym przez Zamawiającego Harmonogramem rzeczowo-finansowym. Wykonawca zobowiązany jest przedłożyć Zamawiającemu do zatwierdzenia Harmonogram rzeczowo-finansowy dla wszystkich Zadań w terminie 7 dni od dnia podpisania umowy. Zamawiający zatwierdzi Harmonogram rzeczowo- finansowy w ciągu 5 dni roboczych od daty jego przedłożenia do zatwierdzenia. Na wniosek każdej ze stron po uzyskaniu wzajemnej akceptacji Harmonogram rzeczowo-finansowy może ulec zmianie pod warunkiem, że termin końcowy realizacji przedmiotu zamówienia przedstawione w Tabeli – Harmonogram realizacji Projektu nie ulegnie zmianie.
1 Wszystkie terminy dotyczą realizacji poszczególnych etapów, oznaczają dni kalendarzowe i są terminami maksymalnymi.
2 Szczegółowy harmonogram dostaw zostanie ustalony z wybranym Wykonawcą w liczbie min. 300 szt. miesięcznie.
1.3 Zakres działań do realizacji w ramach zamówienia
Uruchomienie systemu wymaga podjęcia następujących działań:
Budowa systemu – zakup licencji i wdrożenie e-usług oraz zakup urządzeń do zdalnego odczytu wody w ramach projektu „Poprawa jakości świadczenia usług publicznych w formie elektronicznej w Gminie Michałowice” w tym:
1. Dostawa urządzeń do elektronicznego pomiaru zużycia wody (1490 szt. liczników) wraz z niezbędnym oprogramowaniem oraz sprzętem do zdalnego odczytu, odszyfrowania danych oraz wystawiania dokumentów księgowych (1 zestaw inkasencki);
2. Budowa Portalu Systemu;
3. Modernizacja/wymiana systemów dziedzinowych;
4. Budowa i uruchomienie e-usług:
w zakresie zaopatrzenia mieszkańców w wodę:
1. e-przyłącze – przyłączenie do sieci wodociągowej i kanalizacyjnej w gminie
2. e-rozliczenia za usługę dostarczania wody,
3. e-zgłoszenia w zakresie awarii sieci wod-kan. w zakresie edukacji publicznej:
4. e-rekrutacja do placówek przedszkolnych
5. e-rekrutacja do szkół podstawowych
6. e-rekrutacja do liceum ogólnokształcącego w tym kalkulator szans
edukacyjnych.
W pozostałym zakresie modernizacja i uruchomienie formularzy oraz e-usług związanych z podatkami i opłatami lokalnymi jakie w chwili obecnej są uruchomione na portalu Gminy Michałowice. Modernizacja jest konieczna ze względu na konieczność zaoferowania swoim mieszkańcom oraz przedsiębiorcom jednorodnych funkcjonalnie a przede wszystkim obsługiwanych z jednego miejsca wszystkich oferowanych e-usług.
5. Integracja EZD3 z systemami dziedzinowymi.
6. Przeprowadzenie i wykonanie:
- audytu wydajności,
- audyt bezpieczeństwa,
- audyt spełnienia standardów WCAG 2.1.
3 Możliwość integracji uzależniona jest od zakresu funkcjonalnego API systemu EZD PUW opisanego w dokumentacji technicznej udostępnionej na stronie xxxxx://xxx.xxx.xx/xxx/xxx/xxxxxxxxxx
- testy akceptacyjne (element procedury odbioru realizowany przez pracownika UG).
Budowa Systemu ukierunkowana jest na uruchomienie nowego przebiegu procesów biznesowych realizowanych przez Gminę.
ID | Nazwa procesu/podprocesu |
Obszar zaopatrzenia w wodę | |
1 | E-przyłącze |
1.1 | Złożenie wniosku o przyłącze wod-kan |
1.2 | Wydanie decyzji |
1.3 | Informowanie o statusie sprawy |
1.4 | Możliwość zawarcia umowy zdalnie. |
2 | E-rozliczenia za usługę dostarczania wody |
2.1 | Odczyt oraz gromadzenie danych o zużyciu wody przez użytkowników |
2.2 | Przetwarzanie zgromadzonych danych oraz generowanie dokumentów rozliczeniowych |
2.3 | Realizacja rozliczeń w tym dokonywanie płatności przez użytkowników |
2.4 | Monitorowanie zużycia wody po stronie dostawcy usług i generowanie alertów |
2.5 | Monitorowanie zużycia wody po stronie usługobiorców i generowanie alertów |
3 | E-zgłoszenia awarii sieci |
3.1 | Przekazywanie zgłoszeń o awariach |
3.2 | Informowanie o statusie sprawy |
Obszar rekrutacji do szkół | |
4 | e-rekrutacja do placówek przedszkolnych |
4.1 | Złożenie zgłoszenia o przyjęcie do placówki przedszkolnej |
4.2 | Wydanie decyzji dotyczącej przyjęcia do przedszkola |
5 | e-rekrutacja do szkół podstawowych |
5.1 | Złożenie zgłoszenia o przyjęcie do szkoły podstawowej |
5.2 | Wydanie decyzji dotyczącej przyjęcia do szkoły podstawowej |
6 | e-rekrutacja do liceum ogólnokształcącego w tym kalkulator szans edukacyjnych |
6.1 | Złożenie zgłoszenia o przyjęcie do liceum |
6.2 | Wydanie decyzji dotyczącej przyjęcia do liceum |
Pozostałe procesy | |
7 | Obsługa pozostałych e-usług dostępnych na Portalu Systemu |
7.1 | e-podatki |
7.2 | Umożliwienie dodawania łączy do innych usług elektronicznych uruchomionych lub uruchamianych przez Zamawiającego w tym np.: |
7.3 | Powiadomienia sms |
7.4 | Łącza do e-usług na portalu Wrota Mazowsza |
7.5 | Łącza do e-usług w serwisie xxx.xx |
7.6 | Łącza do EcoHarmonogramu |
7.7 | Dostęp do danych z czujników powietrza |
7.8 | e-opłaty za zobowiązania wobec placówek edukacyjnych |
8 | Administracja i zarządzanie Systemem |
8.1 | Zarządzanie ciągłością działania Systemu |
8.2 | Zarządzanie zmianą Systemu |
8.3 | Zarządzanie uprawnieniami do Systemu |
8.4 | Monitorowanie wykorzystania usług |
8.5 | Rejestracja, weryfikacja tożsamości, identyfikacja użytkowników |
W wyniku wdrożenia opisanego systemu informatycznego (systemów dziedzinowych i innych koniecznych do realizacji e-usług) muszą zostać uruchomione i udostępnione następujące elektroniczne usługi publiczne:
Lp | E-USŁUGA | Poziom dojrzałości usługi |
1 | e-przyłącze – przyłączenie do sieci wodociągowej i kanalizacyjnej w gminie | Poziom 5 - personalizacja |
2 | e-rozliczenia za usługę dostarczania wody | Poziom 5 - personalizacja |
3 | e-zgłoszenia w zakresie awarii sieci wod-kan | Poziom 5 - personalizacja |
4 | e-rekrutacja do placówek przedszkolnych | Poziom 5 - personalizacja |
5 | e-rekrutacja do szkół podstawowych | Poziom 5 - personalizacja |
6 | e-rekrutacja do liceum ogólnokształcącego w tym kalkulator szans edukacyjnych | Poziom 5 - personalizacja |
Jednocześnie w wyniku realizacji przedmiotowego zamówienia wykonawca będzie miał obowiązek umieścić w nowotworzonym portalu e-usługi związane x.xx. z podatkami.
Dodatkowe e-usługi jakie zostaną udostępnione w wyniku realizacji Projektu:
1. e-podatki
2. Umożliwienie dodawania łączy do innych usług elektronicznych uruchomionych lub uruchamianych przez Zamawiającego w tym np.:
3. Powiadomienia sms
4. Łącza do e-usług na portalu Wrota Mazowsza
5. Łącza do e-usług w serwisie xxx.xx
6. Łącza do EcoHarmonogramu
7. Dostęp do danych z czujników powietrza
8. e-opłaty za zobowiązania wobec placówek edukacyjnych.
2 Analiza sytuacji bieżącej w Urzędzie Gminy
Michałowice
2.1 Struktura organizacyjna Urzędu Gminy Michałowice
W Urzędzie Gminy Michałowice system organizacyjny regulowany jest odpowiednimi aktami normatywnymi o charakterze wewnętrznym, tj. Zarządzenia Nr 30/2021 oraz Nr 59/2021 Wójta Gminy Michałowice.
Przeprowadzona identyfikacja kluczowych procesów w Urzędzie pozwala stwierdzić, iż na poziomie stanowisk nie występują istotne konflikty kompetencyjne, zagrażające prawidłowemu wdrożeniu systemu informatycznego.
Urzędem Gminy kieruje Wójt, który jest pracodawcą w rozumieniu prawa pracy dla pracowników w nim zatrudnionych.
W skład Urzędu wchodzą następujące referaty, biura i samodzielne stanowiska:
1) Referat Geodezji i Rolnictwa GR
2) Referat Budżetu i Finansów BF
3) Referat Spraw Obywatelskich SO
4) Referat Gospodarki Komunalnej GK
5) Referat Inwestycji i Remontów IR
6) Referat Funduszy Zewnętrznych FZ
7) Referat Planowania Przestrzennego UA
8) Referat Kultury i Spraw Społecznych KS
9) Biuro Rady RG
10) Z-ca Skarbnika pełniący funkcję Głównego Księgowego Urzędu Gminy BU
11) Wieloosobowe Stanowisko ds. Kadrowo-Administracyjnych i BHP KA
12) Referat Informatyki IT
13) Referat Promocji i Polityki Informacyjnej PR
14) Referat Zamówień Publicznych ZP
15) Stanowisko ds. Obronności i Obrony Cywilnej OC
16) Stanowisko Radca Prawny RP
17) Stanowisko ds. Kontroli Wewnętrznej KW
18) Audytor Wewnętrzny AW
19) Stanowisko ds. Komunikacji i Partycypacji Społecznej PS
20) Referat Organizacyjno-Administracyjny OA
21) Referat Ochrony Środowiska OŚ
22) Stanowisko ds. Sportu SP
23) Stanowisko ds. Architektoniczno-Budowlanych AB
24) Referat Podatków, Opłat Lokalnych i Windykacji POL
Ponadto w Urzędzie powołany jest Pełnomocnik ds. Ochrony Informacji Niejawnych IN.
2.2 Opis stanu istniejącego - Infrastruktura techniczna
E-usługi świadczone aktualnie przez Gminę dostępne są poprzez oficjalną stronę internetową Michałowic (xxxxx://xxx.xxxxxxxxxxx.xx/) oraz portal Wrota Mazowsza (xxxxx://xxx.xxxxxxxxxxxxx.xx/).
Wykaz podstawowych systemów, aplikacji i modułów aktualnie eksploatowanych w Gminie Michałowice, obsługujących dostępne e-usługi:
− portal Gminy Michałowice (strona internetowa w domenie Michałowic wraz z dostępnymi formularzami, hiperłączami do zewnętrznym aplikacji webowych),
− system Elektronicznego Zarządzania Dokumentacją (EZD; projekt xxxxxxxxxxxxx.xx),
− system do obsługi finansów, księgowości, budżetu i podatków (Info-System),
− Informatyczny System Zarządzania Budżetem JST (Besti@),
− system rozliczania opłat wodno-kanalizacyjnych oraz opłat za gospodarowanie
odpadami (Woda Millenium),
− mobilna aplikacja z harmonogramem wywozu odpadów (EcoHarmonogram),
− system Informacji Przestrzennej Gminy Michałowice (GEO-SYSTEM moduły: Planowanie Przestrzenne, Punkty adresowe, Mienie Komunalne),
− moduły wsparcia konsultacji społecznych i budżetu obywatelskiego (Sputnik Software
Sp. z o.o.),
− ewidencje i rejestry,
− systemy bazodanowe.
Obszary obsługiwane przez system finansowo-księgowy (Info-System)
− płace,
− e-Deklaracje,
− księgowość budżetowa z planowaniem,
− wieloletnie prognozy finansowe,
− podatki (w tym od nieruchomości i środków transportu), opłaty lokalne, czynsze,
− kasa urzędu,
− kontrola i egzekucje należności
− informacja podatkowa przez internet
− rejestracja użytkowników sieciowych i przydzielanie praw dostępu,
− administracja danymi osobowymi,
− zezwolenia.
Zamawiający dysponuje odpowiednim zapleczem sprzętowym (serwerownia, serwery, komputery osobiste), które zostaną wykorzystane na potrzeby realizacji Projektu. W szczególności niezbędne będą urządzenia serwerowe do zapewnienia właściwego funkcjonowania E-usług przy współpracy z chmurą obliczeniową.
Dla uruchomienia możliwości świadczenia e-usług na 5 poziomie dojrzałości konieczna jest modernizacja lub wymiana obecnie użytkowanych przez Zamawiającego aplikacji dziedzinowych niezbędnych do realizacji procesów dotyczących ewidencji podatkowych w Urzędzie wraz z wdrożeniem EZD i integracją wszystkich rozwiązań.
Drogą elektroniczną Urząd oferuje także usługi informacyjne – posiada serwis www oraz Biuletyn Informacji Publicznej. Umieszczane są w nich ogólne informacje dla obywateli i podmiotów gospodarczych o załatwianych przez nich sprawach, aktualnych wydarzeniach itp. Ponadto, w Gminie funkcjonuje platforma wrotamazowsza, w ramach której możliwe jest złożenie kilku formularzy. Dodatkowo za pośrednictwem platformy ePUAP również można składać formularze.
Podsumowując, Zamawiający nie posiada zintegrowanego systemu teleinformatycznego, który łączyłby system obsługi klientów z platformą ePUAP, systemami dziedzinowymi, funkcjonującymi w ramach Urzędu, oraz pozwalałby na realizowanie przez klientów płatności wynikających ze swoich zobowiązań wobec Gminy. Niemożliwe jest prezentowanie i przesyłanie do Urzędu odpowiednich elektronicznych formularzy, które obsługiwałyby planowane do wdrożenia e-usługi.
rozwiązanie
technologiczne
-
ogólne wymagania dotyczące systemu
informatycznego oraz rozwiązań
Wykonana analiza stanu w zakresie poziomu informatyzacji w Urzędzie Gminy Michałowice wykazała istniejące utrudnienia w obszarze komunikacji z interesantami. Po przeprowadzonej analizie stanu obecnego oraz sposobów dalszego rozwoju stwierdzono, iż najlepszym (najbardziej długotrwałym oraz ekonomicznym w późniejszej obsłudze) rozwiązaniem jest przeniesienie czynności związanych z obsługą interesantów do systemu on – line wraz z modernizacją i/lub wymianą posiadanych obecnie oprogramowań (systemów dziedzinowych). Przyczyni się to do ujednolicenia posiadanych rozwiązań oraz ułatwienia i skrócenia czasu obsługi klientów, a także pozwoli im (zwłaszcza osobom niepełnosprawnym) w pierwszej kolejności/fazie na skuteczne i szybkie załatwianie spraw związanych z obsługą obszarów: zaopatrzenia w wodę, rekrutacji i pobytu dziecka w przedszkolu oraz szkołach jak również z podatkami i opłatami lokalnymi.
Zintegrowany system teleinformatyczny, jaki będzie wdrożony w Urzędzie Gminy Michałowice będzie specjalistycznym systemem informatycznym, wspomagającym pracę e-usług, procesów administracyjnych. Planowany do wdrożenia system musi spełniać następujące założenia funkcjonalne, tzn. powinien być:
• Funkcjonalny, dostosowany do otoczenia prawno-administracyjnego oraz zgodny z aktualnymi aktami prawnymi regulującymi działalność jednostki. Jednocześnie jest na bieżąco aktualizowany w przypadku zmiany przepisów, a także modernizowany i unowocześniany w odpowiedzi na zmieniające się potrzeby Użytkowników oraz rozwój technologii.
• W pełni zintegrowany, co w praktyce oznacza szybki, uzależniony od nadanych uprawnień dostęp do wszelkiej dokumentacji administracyjnej z wszystkich poziomów, dający komfort pracy w ramach rozbudowanego i kompatybilnego systemu informatycznego.
• Kompleksowy, czyli zapewniający bezpośrednią obsługę wszystkich komórek działających w ramach struktury jednostki.
• Wielomodułowy, a więc pozwalający na dowolne modelowanie i pełne dostosowanie zarówno do aktualnych, jak i przyszłych potrzeb jednostki.
• Ergonomiczny, łączący rozbudowany zakres funkcji użytkowych z prostotą obsługi.
• Przyjazny system dla użytkownika, poprzez x.xx. standaryzację, unifikację oraz dołączenie szeregu narzędzi pozwalających na wyszukiwanie i poprawianie danych.
• Bezpieczny, zaprojektowany z użyciem najnowszych technologii tak, aby zapewnić wysokie bezpieczeństwo i niezawodność oraz spełnić rygory związane z poufnością przetwarzanych i składowanych danych.
Zaoferowane rozwiązanie musi być w pełni zgodne z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych tzw. RODO) |
Rozwiązania dostępne w przeglądarce muszą mieć możliwość działania w oparciu o protokół https. |
Wszystkie programy powinny zapewniać pełną kompatybilność z systemem EZD w kwestii wysyłki korespondencji masowej, wysyłki przez ePUAP oraz umożliwiać wysyłkę wiadomości SMS i drukowanie książek nadawczych oraz naklejek na zwrotki (powinny być też kompatybilne z dostępnymi na rynku urządzeniami do wydruku zwrotek). Ponadto umożliwiać stworzenie systemu na kształt obecnego ePodatki czyli zapewniać założenie podatnikowi konta w serwisie i dawać możliwość wglądu w swoje płatności z tytułu wszystkich opłat oraz dokonywanie tychże płatności przez internet. Konieczna jest też pełna kompatybilność programów w kwestii pobierania i księgowania płatności masowych ze strony banku obsługującego Urząd (obecnie: Bank Spółdzielczy w Raszynie).
3.1 Wymagania niefunkcjonalne – podstawowe parametry
Dostępność Systemu (SLA): 99%.
Standard interfejsów graficznych Portalu Serwisu spełniający kryteria WCAG 2.1.
Budowa Systemu będzie opierać się na zasadzie uniwersalnego projektowania. Uniwersalne projektowanie, to projektowanie produktów oraz otoczenia tak, aby były one dostępne dla wszystkich ludzi, w największym możliwym stopniu, bez potrzeby adaptacji bądź wyspecjalizowanego projektowania. Uniwersalne projektowanie jest strategią normatywną, dostarczającą podstaw do specyfikacji właściwości produktów i otoczenia tak, aby mogły być one użytkowane w równym stopniu przez wszystkich członków społeczeństwa. Jest to sposób projektowania produktów, środowiska, programów i usług, aby służyły jak największej liczbie osób.
Projektowanie zorientowane na użytkownika – badania UX na etapie prac wdrożeniowych.
Realizacja wymagań w zakresie interoperacyjności (spełnienie wymagań Krajowych Ram Interoperacyjności – KRI).
Realizacja powinna uwzględniać:
a) zasady dostępności - regulacje zawarte x.xx. w Ustawie z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych;
b) założenia zasady jednorazowości (patrz np. komunikat „Przyspieszenie transformacji cyfrowej w administracji w UE — plan działania na lata 2016–2020”, xxxxx://xxx- xxx.xxxxxx.xx/xxxxx-xxxxxxx/XX/XXX/?xxxxXXXXXXXX%0X0000000 ).
Opracowanie szczegółowej dokumentacji dla Systemu.
Przeprowadzenie szkoleń dla użytkowników wewnętrznych (w tym zapewnienie platformy e- learningowej).
Opracowanie instrukcji dla użytkowników zewnętrznych.
3.2 Wymagania niefunkcjonalne - dostosowanie do
obowiązujących norm krajowych (interoperacyjność)
Wszystkie systemy teleinformatyczne w ramach zamówienia będą wdrażane zgodnie z wymaganiami dotyczącymi interoperacyjności wynikającymi x.xx. z Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. poz. 526).
Podstawowe usługi publiczne obejmują usługi interoperacyjności (takie, jak usługi uzgadniania i publikowania standardów i rekomendacji interoperacyjności, usługi dostarczania wzorców atrybutów referencyjnych, usługi transformacji danych), usługi rejestrowe (czyli usługi dostępu i przetwarzania zasobów informacyjnych administracji publicznej) oraz usługi zewnętrzne, pochodzące spoza administracji, które są niezbędne dla realizacji zadań publicznych drogą elektroniczną (np. usługi finansowe takie, jak wniesienie opłaty skarbowej, weryfikacja i „kasowanie” poświadczeń dla konkretnej sprawy).
Interoperacyjność systemu zostanie zapewniona na wszystkich trzech wyróżnionych
poziomach:
1. poziom technologiczny , który obejmuje elementy infrastruktury teleinformatycznej takie, jak łącza komunikacyjne, platformy komputerowe wraz z systemami operacyjnymi, oprogramowanie standardowe i narzędziowe w postaci systemów zarządzania bazami danych, oprogramowania do wytwarzania aplikacji, itd.
System będzie zgodny z minimalnymi wymaganiami dla systemów teleinformatycznych, określonymi w rozdziale IV w/w rozporządzenia.
System będzie wykorzystywał jako medium dostępowe otwartą sieć Internet, nie będzie faworyzował żadnego z producentów sprzętu ani oprogramowania, interfejs użytkownika
będzie działał z poziomu dowolnej popularnej przeglądarki internetowej, na dowolnym systemie operacyjnym, bez konieczności instalacji dodatkowego oprogramowania (z wyjątkiem bezpłatnych rozszerzeń przeglądarki internetowej, o ile jest ona dostępna na wszystkie urządzenia i systemy operacyjne), zarówno na komputerach osobistych jak i urządzeniach mobilnych.
Przy projektowaniu systemu uwzględnione zostanie istniejące i planowane wyposażenie teleinformatyczne Urzędu Gminy Michałowice tak, aby zachować kompatybilność rozwiązań i uniknąć dodatkowych kosztów wdrożenia systemu.
2. poziom systemowy, który obejmuje dane pamiętane w dowolnych bazach danych, oprogramowanie aplikacyjne, oprogramowanie i obiekty (np. formatki ekranowe) prezentacji danych.
System będzie umożliwiał poprawną prezentację interfejsu użytkownika i samych danych niezależnie od metody dostępu w oparciu o otwarte standardy, niezależnie od rodzaju urządzenia (komputer, tablet, smartfon). Stosowane struktury danych i znaczenia danych zawartych w tych strukturach będą zgodne z minimalnymi wymaganiami dla rejestrów publicznych i wymiany informacji w postaci elektronicznej zawartymi w w/w rozporządzeniu Rady Ministrów. W rejestrach prowadzonych przez Urząd Gminy będą stosowane odwołania do rejestrów zawierających dane referencyjne w zakresie niezbędnym do realizacji zadań. Do opisu protokołów i struktur wymiany danych usługi sieciowej wykorzystywany będzie Web Services Description Language (WSDL). Dla każdego obiektu rejestru, w obrębie danego typu, nadany zostanie unikatowy identyfikator. Kodowanie znaków w dokumentach wysyłanych z systemu odbywać się będzie według standardu Unicode UTF-8.
3. poziom zadaniowy (biznesowy), który obejmuje obiekty i procedury mające bezpośredni związek z rzeczywistymi zadaniami realizowanymi przez podmioty zainteresowane.
Procedury obowiązujące przy załatwianiu spraw drogą elektroniczną będą ustandaryzowane, publikowane i uaktualniane w Biuletynie Informacji Publicznej przez podmiot realizujący zadania publiczne opisów. Informacje te będą dostępne także z poziomu interfejsu użytkownika.
W procesach realizacji zadań projektowanego systemu wykorzystywane będą usługi wymiany danych i dokumentów, które stanowią grupę usług komunikacyjnych wzbogaconą o dodatkowe funkcjonalności wspierające procesy identyfikacji, uwierzytelniania, autoryzacji i rozliczalności (IAAA). Usługi te muszą charakteryzować się wymaganym dla realizacji zadań publicznych poziomem wydajności, jakości, ciągłości działania i poufności przesyłanych danych. System zapewni bezpieczny kanał wymiany danych i dokumentów, zarówno w sieci otwartej Internet, jak i w sieciach wydzielonych (prywatnych). Ponadto musi zapewniać wymagane i zgodne z prawem możliwości podpisu cyfrowego, szyfrowania, rejestrowania (logowania).
Niezależnie od rodzaju kanału dostępu w procesach wymiany danych i dokumentów muszą być dostępne m. in. usługi:
• przekazywania dokumentów pomiędzy usługodawcami i usługobiorcami usług publicznych, w tym usługi identyfikacji i uwierzytelnienia osób, podmiotów i systemów, usługi przekazywania dokumentów w relacji usługodawca / usługobiorca z wykorzystaniem legalnych skrzynek elektronicznych, usługi identyfikacji i powiadamiania nadawców i adresatów, uwierzytelnienia przekazywanych dokumentów, potwierdzenia przedłożenia dokumentów w imieniu organów administracji publicznej, doręczania dokumentów elektronicznych, itd.,
• przekazywania transakcji pomiędzy usługodawcami i usługobiorcami, w tym usługi identyfikacji usługodawców i usługobiorców, uwierzytelnienia i autoryzacji przekazywanych transakcji, usługi przekazywania transakcji asynchronicznych i synchronicznych w relacji usługodawca – usługobiorca (w obie strony) wprost do ich systemów lub z użyciem skrzynek elektronicznych, itd.,
• Udostępnienia pewnego źródła czasu oraz usług znakowania czasem.
wdrażanych
niefunkcjonalne
-
bezpieczeństwo
systemów
informatycznych
oraz
przetwarzania danych
Standardy bezpieczeństwa wdrażanego systemu informatycznego oraz przetwarzania danych
muszą być zgodne z obowiązującym prawem.
Musi zostać zapewniona zgodność zarówno z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych.
Przy projektowaniu oraz wykonaniu systemu uwzględnione muszą być poniższe aspekty bezpieczeństwa w systemach teleinformatycznych:
a) dbałości o aktualizację oprogramowania,
b) minimalizacja ryzyka utraty informacji w wyniku awarii,
c) ochrona przed błędami, utratą, nieuprawnioną modyfikacją,
d) stosowanie mechanizmów kryptograficznych w sposób adekwatny do zagrożeń lub wymogów przepisu prawa,
e) zapewnienie bezpieczeństwa plików systemowych,
f) redukcja ryzyk wynikających z wykorzystania opublikowanych podatności technicznych systemów teleinformatycznych,
g) niezwłoczne podejmowanie działań po dostrzeżeniu nieujawnionych podatności systemów teleinformatycznych na możliwość naruszenia bezpieczeństwa,
h) kontrola zgodności systemów teleinformatycznych z odpowiednimi normami i politykami bezpieczeństwa.
System musi być wykonany tak, aby awaria pojedynczego jego elementu nie powodowała braku dostępności pozostałych funkcjonalności. Wszystkie kluczowe elementy systemu powinny być redundantne.
Zapewniona musi być możliwość tworzenia okresowych kopii bezpieczeństwa systemu oraz ich składowania na zewnętrznym niezależnym od systemu urządzeniu pamięci masowej. Rozwiązanie sprzętowo-aplikacyjne dla wykonywania kopii bezpieczeństwa powinno mieć odpowiednie parametry aby umożliwić odtworzenie systemu w założonym czasie tak, aby uzyskać wymaganą przez użytkowników dostępność.
Aktywność administratorów systemu jak i jego użytkowników musi podlegać wiarygodnemu dokumentowaniu w postaci elektronicznych zapisów w dziennikach systemów (logach). System umożliwi przechowywanie w/w logów przez okres minimum 2 lat bądź dłuższy, o ile wymagają tego przepisy prawa. Zapisy dzienników systemów mogą być składowane na zewnętrznych informatycznych nośnikach danych w warunkach zapewniających bezpieczeństwo informacji.
Całość komunikacji użytkowników z systemem będzie odbywać się wyłącznie z wykorzystaniem bezpiecznego połączenia, np. z wykorzystaniem protokołu HTTPS.
Komunikacja pomiędzy chmurą prywatną a chmurą publiczną także będzie opierać się o
bezpieczne metody, np. HTTPS, VPN.
3.4 Wymagania niefunkcjonalne - Wymagania wynikające
z wytycznych Web Content Accessibility Guidelines
Portal Systemu (i inne), które zostaną uruchomione dzięki realizacji przedmiotowego zamówienia, na których znajdować się będą oferowane e-usługi, będą spełniały wszystkie obowiązkowe wytyczne określone w dokumencie WCAG 2.1. Oznacza to spełnienie wymagań zawartych w specyfikacji Web Content Accessibility Guidelines (WCAG) 2.1 przynajmniej na poziomie AA. Wdrożone systemy będą charakteryzowały się posiadaniem tekstu alternatywnego, brakiem animowanych elementów rozpraszających uwagę. Wszystkie pliki tekstowe będą posiadały transkrypcję tekstową. Do uruchomienia i obsługi multimediów wystarczą jedynie klawisze na klawiaturze, tak by osoby niewidome mogły obsłużyć je samodzielnie. Wszystkie pliki multimedialne będą udostępniane alternatywnie, a pliki PDF, Word i inne będą przygotowane do uzyskania dostępu do nich. Natomiast teksty umieszczone na portalach będą skonstruowane w jak najprostszy sposób, by każda osoba łatwo mogła uzyskać z niej informacje. Będą też tak sformatowane, by zapewnić maksymalną czytelność, teksty będą podzielone na nagłówki.
Wszystkie rozwiązania wdrażane w tzw. części publicznej muszą spełniać wymagania standardu WCAG 2.1 w przedmiotowym zakresie wynikające z Ustawy o dostępności cyfrowej
stron internetowych i aplikacji mobilnych podmiotów publicznych z dn. 4 kwietnia 2019 r.
(Dz.U. 2019 poz. 848), a w szczególności:
1. W zakresie zasady postrzegania:
a. wykorzystanie technik, dzięki którym wszelkie elementy nietekstowe, umieszczone na stronie internetowej, takie jak: zdjęcia, obrazki ozdobne, ikony, wykresy, animacje itp. będą przetworzone przez oprogramowanie użytkownika i dostarczą komplet informacji, jakie ze sobą niosą;
b. dla wszystkich nagranych (nietransmitowanych na żywo) materiałów dźwiękowych i wideo, publikowanych na stronie, takich jak np. podcasty dźwiękowe, pliki mp3, itd. zapewniona zostanie transkrypcja opisowa nagranego dźwięku;
c. dla materiałów wideo (nietransmitowanych na żywo), które nie zawierają ścieżki dźwiękowej zapewniony zostanie opis tekstowy lub dźwiękowy, aby użytkownicy niewidomi także mieli dostęp do prezentowanej informacji;
d. wszystkie opublikowane na stronie materiały wideo (nietransmitowane na żywo) udostępnione na stronie (np. wideo) będą posiadać napisy, które przedstawiają nie tylko dialogi, ale prezentują również ważne informacje dźwiękowe.
e. dla mediów zmiennych w czasie zapewniona będzie alternatywa, dla nagrań wideo w multimediach zsynchronizowanych będzie zapewniona audiodeskrypcja;
f. zastosowanie znaczników semantycznych, skrótów klawiaturowych interpretowanych przez programy czytające do nawigacji po stronie internetowej;
g. opisanie stron internetowych w plikach CSS;
h. zastosowanie w kodzie HTML logicznej i intuicyjnej sekwencji nawigacji oraz czytania;
i. instrukcje i komunikaty nie będą zależeć od kształtu, lokalizacji wizualnej, miejsca, dźwięku;
j. kolor nie będzie używany, jako jedyna metoda do przekazywania treści i rozróżniania elementów wizualnych;
k. zapewniony zostanie mechanizm, dzięki któremu użytkownik zatrzyma dźwięki, spauzuje, wyciszy lub zmieni głośność;
l. kontrast pomiędzy tekstem lub grafikami tekstowymi a tłem będzie w stosunku 4,5:
1;
m. zakaz używania grafiki do przedstawiania tekstu, jeśli ta sama prezentacja wizualna może być zaprezentowana jedynie przy użyciu tekstu,
n. zawartość nie ogranicza swojego widoku i działania do jednej orientacji wyświetlania, takiej jak pionowa lub pozioma, chyba że określona orientacja wyświetlania jest niezbędna,
o. cel każdego pola zbierającego informacje o użytkowniku będzie programowo określony, gdy:
i. Pole zbierające dane służy celowi określonemu w sekcji Przeznaczenie pól danych
w komponentach interfejsu użytkownika; oraz
ii. Treść jest implementowana za pomocą technologii obsługującej określanie w
polach formularza typu oczekiwanych danych.,
p. treść będzie prezentowana bez utraty informacji lub funkcjonalności, bez konieczności przewijania w dwóch wymiarach dla:
i. Pionowego przewijania zawartości o szerokości odpowiadającej 320 pikselom
CSS;
ii. Poziomego przewijania zawartości na wysokości odpowiadającej 256 pikselom
CSSS.
Za wyjątkiem tych części treści, które wymagają dwuwymiarowego układu ze względu na sposób używania lub znaczenie.
q. wizualna prezentacja następujących elementów będzie miała współczynnik kontrastu, co najmniej 3: 1 względem sąsiednich kolorów.
i. Elementy interfejsu użytkownika: Informacje wizualne wymagane do identyfikacji komponentów i stanów interfejsu użytkownika, z wyjątkiem nieaktywnych składników lub gdy wygląd komponentu będzie określony przez agenta użytkownika i nie będzie modyfikowany przez autora;
ii. Obiekty graficzne: Części grafiki wymagane do zrozumienia treści, z wyjątkiem sytuacji, gdy konkretna prezentacja grafiki ma zasadnicze znaczenie dla przekazywanych informacji.
r. w treści zaimplementowanej przy użyciu języków znaczników, które obsługują poniższe właściwości stylu tekstowego, nie następuje utrata treści lub funkcjonalności przez ustawienie wszystkich następujących elementów i przez zmianę żadnej innej właściwości stylu.
i. Wysokość linii (odstęp między wierszami) do co najmniej 1,5-krotności rozmiaru
czcionki;
ii. Rozstaw następujących akapitów co najmniej 2 razy większy od rozmiaru czcionki;
iii. Odstępy między literami (tracking) do co najmniej 0,12-krotności rozmiaru
czcionki;
iv. Odstępy między wyrazami do co najmniej 0,16 wielkości czcionki.
s. tam, gdzie odbieranie, a następnie usuwanie wskaźnika myszy lub fokusa klawiatury powoduje wyświetlenie dodatkowej zawartości, a następnie jej ukrycie, prawdziwe są poniższe stwierdzenia:
i. Odrzucone: Dostępny jest mechanizm umożliwiający odrzucenie dodatkowej zawartości bez przesuwania wskaźnika myszy lub koncentracji na klawiaturze, chyba że dodatkowa treść przekazuje błąd wejściowy lub nie przesłania ani nie zastępuje innej zawartości;
ii. Wskazywane: Jeśli wskaźnik myszy (hover) może wyzwolić dodatkową zawartość, wówczas wskaźnik może zostać przeniesiony na dodatkową zawartość bez znikania dodatkowej zawartości;
iii. Trwałe: Dodatkowa treść pozostaje widoczna do momentu usunięcia wyzwalacza aktywacji lub fokusa, użytkownik odrzuca go lub jego informacje nie są już ważne.
2. W zakresie zasady funkcjonalności:
a. zapewnienie dostępu do każdej funkcjonalności przy użyciu skrótów klawiaturowych, które nie będą wchodzić w konflikt z istniejącymi w przeglądarce czy programie czytającym;
b. zapewnienie poruszania się po wszystkich elementach nawigacyjnych strony
używając jedynie klawiatury;
c. brak nakładanych limitów czasowych na wykonanie czynności na stronie;
d. zostanie zapewniony mechanizm pauzy, zatrzymania, ukrycia dla informacji, które są
automatycznie przesuwane, przewijane lub mrugające;
e. nie zostaną utworzone treści, które migają więcej niż 3 razy na sekundę;
f. nie zostaną utworzone treści, które automatycznie zaczną odtwarzać dźwięk;
g. materiał wideo bez wcześniejszego opisu, że zawiera jaskrawe światło niebieskie i czerwone nie zostanie wyświetlone;
h. zapewnienie, że pierwszą informacją „wyświetloną” przez przeglądarkę będzie menu służące do przechodzenia, bez przeładownia strony, do istotnych treści serwisu za pomocą kotwic;
i. określenie każdej podstrony serwisu internetowego przez unikalny i sensowny tytuł;
j. zapewnienie logicznej i intuicyjnej kolejności nawigacji po linkach, elementach
formularzy itp.;
k. określenie wszystkich elementów aktywnych, takich jak linki, przyciski formularza, czy obszary aktywne map odnośników z perspektywy swojego celu, bezpośrednio z linkowanego tekstu lub w pewnych przypadkach - z linku w swoim kontekście;
l. zapewnienie znalezienia innych stron w serwisie na wiele sposobów, tj. spis treści,
mapa serwisu, wyszukiwarka;
m. zapewnienie jednoznacznego opisu nagłówków i etykiet;
n. zapewnienie, że nie będą dublowane nagłówki i etykiety;
o. zapewnienie widoczności zaznaczenia przy obsłudze strony internetowej z klawiatury, jeśli skrót klawiaturowy jest zaimplementowany w treści przy użyciu tylko litery (w tym wielkich i małych liter), znaków interpunkcyjnych, liczbowych lub symboli, to przynajmniej jedno z poniższych jest prawdziwe:
i. Wyłączanie: Dostępny jest mechanizm wyłączania skrótu;
ii. Mapowanie: Dostępny jest mechanizm zmiany mapowania skrótu w celu użycia
jednego lub więcej niedrukowalnych znaków klawiatury (np. Ctrl, Alt, itp.);
iii. Aktywny tylko po otrzymaniu fokusa: Skrót klawiaturowy dla komponentu interfejsu użytkownika jest aktywny tylko wtedy, gdy ten składnik ma fokus.
p. cała funkcjonalność wykorzystująca gesty wielopunktowe lub oparte na ścieżkach do obsługi będzie obsługiwana za pomocą pojedynczego wskaźnika bez gestu opartego na ścieżce, chyba że niezbędny jest gest wielopunktowy lub oparty na ścieżce,
q. w przypadku funkcji, które można obsługiwać za pomocą pojedynczego wskazania,
co najmniej jedno z poniższych jest prawdziwe:
i. Brak zdarzenia down: Zdarzenie down nie jest wykorzystywane do wykonywania
jakiejkolwiek części funkcji;
ii. Przerwij lub cofnij: Ukończenie funkcji odbywa się na zdarzeniu up i dostępny jest mechanizm do przerwania funkcji przed jej zakończeniem lub cofnięcia funkcji po jej zakończeniu;
iii. Odwrócenie zdarzenia up: Zdarzenie up odwraca każdy wynik poprzedniego
zdarzenia down;
iv. Istotny: Niezbędne jest ukończenie funkcji w zdarzeniu down,
r. w przypadku komponentów interfejsu użytkownika z etykietami zawierającymi tekst lub obrazy tekstu, nazwa zawiera tekst, który jest prezentowany wizualnie,
s. Funkcjonalność, którą można obsługiwać za pomocą ruchu urządzenia lub ruchu użytkownika, można również obsługiwać za pomocą elementów interfejsu użytkownika, a reagowanie na ruch można wyłączyć, aby zapobiec przypadkowemu uruchomieniu, z wyjątkiem sytuacji, gdy:
i. Obsługiwany interfejs: Ruch służy do obsługi funkcjonalności poprzez interfejs obsługiwany przez dostępność ;
ii. Istotny: Ruch jest niezbędny dla funkcji, a to spowodowałoby unieważnienie działania,
3. W zakresie zasady zrozumiałości:
a. główny język strony oraz zmiana języka będzie określona za pomocą atrybutu lang
i/lub xml:lang w znaczniku HTML;
b. zapewnienie, że elementy zaznaczenia (focus) nie spowodują zmiany kontekstu na
stronie;
c. zakaz automatycznego wysyłania formularzy, przeładowania strony itp.;
d. zakaz stosowania mechanizmów, które powodują przy zmianie ustawień jakiegokolwiek komponentu interfejsu użytkownika automatyczną zmianę kontekstu;
e. zapewnienie, że wszystkie mechanizmy nawigacji, które powtarzają się na podstronach, będą pojawiały się w tym samym względnym porządku za każdym razem, gdy będą ponownie prezentowane i będą w spójny sposób identyfikowane;
f. zapewnienie, że informacja o błędzie będzie skuteczna, intuicyjna i przede wszystkim dostępna dla wszystkich użytkowników, bez względu na to, czy posiadają dysfunkcje czy nie oraz pozwoli użytkownikowi jednoznacznie na zidentyfikowanie błędu oraz na łatwe rozwiązanie problemu i powtórne przesłanie danych z formularza;
g. zapewnienie, by w miejscach, w których konieczne będzie wprowadzanie informacji
przez użytkownika zawierano czytelne etykiety oraz instrukcje;
h. zapewnienie, że po błędzie użytkownika przy wprowadzaniu danych, przedstawione zostaną użytkownikowi sugestie, które mogą rozwiązać problem;
i. zostaną zapewnione mechanizmy pozwalające na przywrócenie poprzednich danych,
weryfikacje lub potwierdzenie.
4. W zakresie zasady kompatybilności:
a. zostanie przeprowadzona weryfikacja kodu HTML i CSS WCAG 2.1 na poziomie AA pod kątem błędu przy wykorzystaniu walidatorów oraz poprawa strony internetowej, tak by była wolna od błędów i poprawna semantycznie.
b. zapewnienie, że wszystkie komponenty interfejsu użytkownika, stworzone w takich technologiach, jak np. flash, silverlight, pdf, które mają wbudowane mechanizmy wspierania dostępności, będą jednoznacznie identyfikowane poprzez nadanie im nazw, etykiet, przeznaczenia,
c. w treści zaimplementowanej przy użyciu języków znaczników komunikaty o stanie będą programowo określane poprzez rolę lub właściwości, dzięki czemu będą prezentowane użytkownikowi za pomocą technologii wspomagających bez uzyskiwania ostrości.
Zamawiający wymaga by wszystkie dostarczane systemy informatyczne w części publicznej (opublikowane w sieci Internet) miały jeden, wspólny i spójny interfejs graficzny użytkownika. W szczególności systemy muszą spełniać minimum następujące wymogi łącznie:
a. Jedna, wspólna kolorystyka.
b. Spójny wygląd formularzy.
c. Podobne operacje muszą być realizowane w ten sam sposób.
d. Informacje zwrotne muszą być prezentowane w ten sam sposób.
e. Polecenia systemu i menu muszą mieć ten sam format.
3.5 Wykorzystanie technologii chmury obliczeniowej i
kompatybilność z urządzeniami mobilnymi.
Zarówno wdrażany w ramach zamówienia system przetwarzania danych zużycia wody jak i system obsługujący proces rekrutacji muszą częściowo (lub całkowicie) funkcjonować w oparciu o chmurę obliczeniową. Szczególnie istotne będzie to w odniesieniu do systemu przetwarzania danych zużycia wody. Dane przesyłane z wodomierzy gromadzone będą poprzez zestaw inkasencki lub system telemetryczny (nie objęty niniejszym zamówieniem – do wykonania przez Zamawiającego w przyszłości) do systemu w chmurze skąd transferowane będą do systemu lokalnego Urzędu Gminy. System ma umożliwić obsługę danych pochodzących z innych wodomierzy przesyłanych przez inne urządzenia służące do zbierania i deszyfrowania danych dostarczonych w ramach późniejszych zamówień.
W podobnym hybrydowym modelu planowana jest budowa rozwiązania dotyczącego systemu obsługującego proces rekrutacji. Tu dopuszcza się możliwość (coraz częściej oferowaną przez rynek) umieszczenia całego środowiska w chmurze.
Na etapie opracowania Projektu Systemu (przed sporządzeniem SWZ dla zamówienia na prace programistyczne) zostanie także podjęta decyzja o zasadności umieszczenia w chmurze wyodrębnionej bazy danych, służącej obsłudze modułu typu Business Intelligence.
Ze względu na obecne standardy oraz oczekiwania ze strony odbiorców końcowych w projekcie uwzględniono udostępnienie aplikacji mobilnej (na smartfony i tablety). Dodatkowo portal Systemu zostanie zbudowany w technologii responsywnej.
Tym samym zwiększy się dostępność e-usług, które będą w swojej podstawowej wersji możliwe do uruchomienia na dowolnym komputerze z przeglądarką internetową (najpopularniejszych typów, wspieranych przez producentów) i dostępem do internetu niezależnie od używanej technologii.
4 Zakup licencji, urządzeń do zdalnego odczytu
wody oraz wdrożenie e-usług
Licencje na zakupione oprogramowanie (oraz e-usługi) muszą być udzielone na czas nieokreślony lub nie krótszy niż okres Gwarancji i Asysty Technicznej określony w formularzu oferty składanej przez Wykonawcę. Przez wyżej wymieniony okres Zamawiający nie może być obciążany jakimikolwiek dodatkowymi kosztami związanymi z wdrożonym rozwiązaniem poza ceną zapłaconą za realizację przedmiotowego Zamówienia.
Wykonawca wraz z licencją na oferowany system musi dostarczyć wszelkie wymagane licencje oprogramowania podmiotów trzecich jakie są konieczne do prawidłowego działania zakładanego rozwiązania informatycznego. Powyższe licencje muszą być udzielone na okres nie krótszy niż okres udzielonej Gwarancji i Asysty Technicznej.
4.1 Najważniejsze cechy systemu informatycznego
1) Administrator - osoba posiadająca uprawnienia do dokonywania modyfikacji w ustawieniach i konfiguracji Systemu. Pod pojęciem mieści się Administrator merytoryczny i Administrator techniczny.
2) Aktualizacja - dostarczenie i instalowanie uaktualnień lub nowych wersji Oprogramowania Aplikacyjnego lub jego poszczególnych modułów. Aktualizacja obejmuje udzielenie lub zapewnienie Zamawiającemu licencji na korzystanie z nowych wersji Oprogramowania w ramach wynagrodzenia objętego Umową.
3) Architektura systemu teleinformatycznego – opis składników systemu teleinformatycznego, powiązań i relacji pomiędzy tymi składnikami.
4) Asysta Techniczna (asysta techniczna) - usługa świadczona przez Wykonawcę, polegająca na bieżącym wsparciu Użytkowników Końcowych, pracowników Zamawiającego w zakresie eksploatacji i obsługi Systemu.
5) Asysta Wdrożeniowa - usługa świadczona przez Wykonawcę w siedzibie Zamawiającego, polegająca na bieżącym wsparciu Użytkowników Końcowych, pracowników Zamawiającego w zakresie instalacji, konfiguracji, parametryzacji, eksploatacji i obsługi Systemu w trakcie Etapu wdrożenia Systemu.
6) Asysta Stanowiskowa - Asysta świadczona przez Wykonawcę w siedzibie Zamawiającego.
7) Autor Oprogramowania - podmiot posiadający autorskie prawa majątkowe i obowiązki wynikające z nadzoru autorskiego oraz gwarancji, w stosunku do Oprogramowania dostarczonego w ramach projektu.
8) Awaria - oznacza sytuację, w której nie jest możliwe prawidłowe użytkowanie oprogramowania z powodu uszkodzenia lub utraty spójności danych, struktur danych. Oznacza również stan niesprawności Oprogramowania uniemożliwiający jego funkcjonowanie, powodujący jego unieruchomienie.
9) Baza danych – zbiór danych lub jakichkolwiek innych materiałów i elementów zgromadzonych według określonej systematyki lub metody, indywidualnie dostępnych w
jakikolwiek sposób, w tym środkami elektronicznymi, wymagający istotnego, co, do jakości lub ilości, nakładu inwestycyjnego w celu sporządzenia, weryfikacji lub prezentacji jego zawartości.
10) Błąd - niezgodne z dokumentacją użytkową lub wymaganiami Zamawiającego określonymi w SWZ, z instrukcjami lub innymi dokumentami wytworzonymi w czasie wdrożenia działanie Oprogramowania.
11) Błąd Oprogramowania - nienormalne działanie Systemu / Oprogramowania, tzn. sytuacja, w której zachowanie Systemu / Oprogramowania albo wynik działania jest odmienny od zamierzonego określonego w Dokumentacji Użytkowej Oprogramowania, które nie jest spowodowane niezgodnym z Dokumentacją działaniem Użytkownika Końcowego. W przypadku, gdy powyższa dokumentacja nie opisuje danej sytuacji, Strony przyjmują odwołanie się do wymagań funkcjonalnych określonych w dokumentacji przetargowej.
12) Centralna Baza Danych (CBD) - repozytorium - element Systemu, w którym gromadzi się,
przetwarza, przechowuje Zasoby Informacyjne Systemu.
13) CMS - System zarządzania treścią (ang. Content Management System, CMS) - aplikacja pozwalająca na łatwe utworzenie serwisu WWW oraz jego późniejszą aktualizację i rozbudowę przez redaktorów.
14) CRD – Centralne Repozytorium Wzorów Dokumentów Elektronicznych (zwane również
CRWD lub CRWDE) na ePUAP.
15) Czas Reakcji na Zgłoszenie - czas, jaki jest liczony od momentu zarejestrowania Zgłoszenia w Internetowym Systemie Obsługi Help Desk lub od przekazania Zgłoszenia Wykonawcy do powiadomienia Zgłaszającego o sposobie i terminie realizacji Zgłoszenia.
16) Dane – wartości logiczne, liczbowe, tekstowe, jakościowe lub ich zbiory, które można rozpatrywać w powiązaniu z określonymi zasobami lub w oderwaniu od jakichkolwiek zasobów, podlegające przetwarzaniu w toku określonych procedur.
17) Dokument - urzędowy dokument, zapisany w formacie XML, biorący udział w procesach workflow w Urzędzie.
18) Dokumentacja - wszelkiego rodzaju dokumenty wytworzone w ramach realizacji Projektu. Pojęcie obejmuje Dokumentację Techniczną, Szkoleniową, Użytkową oraz Wdrożeniową oraz inne dokumenty uzgodnione przez Strony.
19) Dokumentacja Techniczna - zestaw dokumentów dotyczących Systemu, w tym co najmniej opis struktury bazy danych, opis zabezpieczeń, opis konfiguracji, opis interfejsów, opis czynności administracyjnych, instrukcje konfiguracji serwera bazy danych Systemu, procedury archiwizacji bazy danych oraz procedur przywracania konfiguracji, opis konfiguracji środowiska Systemowego oraz inne dokumenty uzgodnione przez Strony.
20) Dokumentacja Szkoleniowa - dokument zawierający zestaw ćwiczeń szkoleniowych.
21) Dokumentacja Użytkowa - dokument napisany w języku zrozumiałym dla przeciętnego docelowego użytkownika, opisujący sposób wykorzystania wszystkich funkcji Oprogramowania w trakcie jego eksploatacji, wszelkie instrukcje dotyczące obsługi Systemu w szczególności Instrukcje Użytkownika i instrukcje administratora Systemu.
22) Dokumentacja Wdrożeniowa - dokumentacja powstająca w trakcie realizacji Wdrożenia, obejmująca opis procesu dostosowania Oprogramowania do wymagań Zamawiającego (opis konfiguracji i parametryzacji Oprogramowania), opis interfejsów.
23) Dostępność – właściwość określającą, że zasób systemu teleinformatycznego jest możliwy do wykorzystania na żądanie, w założonym czasie, przez podmiot uprawniony do pracy w systemie teleinformatycznym.
24) Dzień Roboczy - dzień kalendarzowy od poniedziałku do piątku za wyjątkiem dni
ustawowo wolnych.
25) Dzień - dzień kalendarzowy.
26) Edytor WYSYWIG - wizualny edytor WWW działający na zasadzie "Dostajesz to co widzisz" (ang. What You See Is What You Get). Użytkownik edytora obarczony jest jedynie odpowiedzialnością za merytoryczną część przygotowania treści. Kodowanie informacji na język zrozumiały dla komputera jest realizowane przez edytor.
27) ePUAP (elektroniczna Platforma Usług Administracji Publicznej) – ogólnopolska platforma teleinformatyczna służąca do komunikacji obywateli z jednostkami administracji publicznej w ujednolicony, standardowy sposób. Usługodawcami są jednostki administracji publicznej oraz instytucje publiczne (zwłaszcza podmioty wykonujące zadania zlecone przez państwo).
28) ESP – Elektroniczna Skrzynka Podawcza platformy ePUAP, aplikacja do komunikacji elektronicznej, która służy przekazywaniu informacji w formie elektronicznej do podmiotu publicznego przy wykorzystaniu powszechnie dostępnej sieci teleinformacyjnej. ESP umożliwia instytucjom publicznym wywiązanie się z obowiązku, wynikającego z ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne, w zakresie przyjmowania dokumentów w postaci elektronicznej.
29) Etap - faza realizacji przedmiotu Zamówienia, stanowiącą funkcjonalną całość, podlegającą odrębnym odbiorom.
30) EZD (SEOD/EOD) – Elektroniczne Zarządzanie Dokumentami (Elektroniczny Obieg Dokumentów/System Elektronicznego Obiegu Dokumentów) - system teleinformatyczny do elektronicznego zarządzania dokumentacją umożliwiający wykonywanie w nim czynności kancelaryjnych, dokumentowanie przebiegu załatwiania spraw oraz gromadzenie i tworzenie dokumentów elektronicznych.
31) e-usługi (usługi on-line) - usługi, których świadczenie odbywa się za pomocą Internetu, jest zautomatyzowane (może wymagać niewielkiego udziału człowieka) i zdalne. Od usługi w ujęciu tradycyjnym, e-usługę odróżnia brak udziału człowieka po drugiej stronie oraz świadczenie na odległość.
32) e-dojrzałość usługi publicznej – zakres, w jakim dana sprawa może zostać załatwiona przez
Internet, mierzony 5-stopniową skalą:
Informacja - możliwości skorzystania z usługi,
Interakcja - możliwość pobrania formularza,
Dwustronna interakcja - możliwość pobrania i odesłania formularza,
Transakcja - pełne załatwienie sprawy, łącznie z ewentualną płatnością,
Personalizacja - dostosowanie usługi do indywidualnych preferencji, np. przypominająca informacja sms, częściowo wypełnione formularze.
33) e-usługi poziom 3 - dwustronna interakcja – usługi zapewniające możliwość wypełnienia elektronicznego formularza (format XML) na stronie internetowej urzędu (np. portalu podatkowym) lub ePUAP, gdyż usługi połączone są z niezbędnym systemem identyfikacji osoby (mieszkaniec nie musi przychodzić do JST na żadnym etapie załatwiania sprawy; pracownik JST nie musi wydawać formularzy i wyjaśniać jak je wypełniać ani wprowadzać danych do systemu dziedzinowego, ale musi weryfikować dane z formularzy).
34) e-usługi poziom 4 - transakcja – usługi transakcyjne, udostępniane w całości poprzez sieć, włączając podejmowanie decyzji oraz jej dostarczanie (nie jest potrzebna forma papierowa na żadnym etapie realizacji usługi; mieszkaniec nie musi przychodzić do JST na
żadnym etapie załatwiania sprawy, a pracownik JST nie musi wydawać formularzy, wyjaśniać jak je wypełniać ani ręcznie wprowadzać danych do systemu dziedzinowego; system informatyczny automatycznie weryfikuje dane z formularzy). Na poziomie 4 e- usługi często połączone są z elektroniczną płatnością.
35) e-usługi poziom 5 - personalizacja - usługi spersonalizowane, udostępniane w całości poprzez sieć, włączając podejmowanie decyzji oraz jej dostarczanie (nie jest potrzebna forma papierowa na żadnym etapie realizacji usługi; mieszkaniec nie musi przychodzić do JST na żadnym etapie załatwiania sprawy, a pracownik JST nie musi wydawać formularzy, wyjaśniać jak je wypełniać ani ręcznie wprowadzać danych do systemu dziedzinowego; system informatyczny automatycznie weryfikuje dane z formularzy, są to usługi dostosowane do indywidualnych preferencji, np. przypominająca informacja sms).
36) Formularz - schemat, na którego podstawie tworzone są dokumenty urzędowe, pozwala na tworzenie dokumentów XML w oparciu o schematy danych XSD oraz style XSL.
37) GIS / SIP - system informacji przestrzennej dotyczący danych geograficznych; termin ten w liczbie mnogiej - systemy informacji geograficznej - stosowany jest również, jako nazwa dziedziny zajmującej się geoinformacją oraz metodami i technikami GIS.
38) Godziny Robocze Zamawiającego - godziny zegarowe w ramach Dnia Roboczego:
- poniedziałek od 9.00 do 18.00;
- wtorek-czwartek od 8.00 do 17.00;
- piątek od 8.00 do 14.00.
39) Gwarancja Jakości - świadczenia realizowane przez Wykonawcę na warunkach opisanych
rozdziale 4.5 oraz umowie z wykonawcą.
40) GML – język znaczników geograficznych, oparty na formacie XML, o którym mowa w przepisach wydanych na podstawie art. 18 pkt 1 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne, przeznaczony do zapisu danych przestrzennych w celu ich wymiany między systemami informatycznymi.
41) Help Desk - część organizacji Wykonawcy (dział, sekcja, zespół lub wyznaczona grupa osób) odpowiedzialna za przyjmowanie Zgłoszeń od osób uprawnionych do ich dostarczania oraz kontrolę ich rozwiązania. Godziny przyjęć zgłoszeń telefonicznych 8:00
– 16:00 w Dni Robocze.
42) Hurtownia - patrz Hurtownia Danych.
43) Hurtownia Danych - element Systemu, miejsce składowania i integrowania wybranych danych pochodzących z CBD oraz zewnętrznych źródeł danych.
44) Incydent - każde Zdarzenie występujące po stronie Systemu lub po stronie prawidłowej obsługi i użytkowania Systemu, niebędące częścią normalnego działania Systemu, w szczególności działanie Systemu niezgodne z wymaganiami Zamawiającego określonymi w SWZ i Dokumentacji.
45) Informacja – dane, które dostarczają opisu właściwości lub stanu wybranych obiektów lub opisują relacje pomiędzy obiektami lub wartościują poszczególne obiekty lub opisują stan układu obiektów należących do pewnego zbioru w odniesieniu do innego układu.
46) Infrastruktura Sprzętowa - serwery oraz inne urządzenia będące w posiadaniu
Zamawiającego przeznaczone przez Zamawiającego na potrzeby realizacji Projektu.
47) Integralność – właściwość polegającą na tym, że zasób systemu teleinformatycznego nie został zmodyfikowany w sposób nieuprawniony.
48) Interoperacyjność – zdolność różnych podmiotów oraz używanych przez nie systemów teleinformatycznych i rejestrów publicznych do współdziałania na rzecz osiągnięcia wzajemnie korzystnych i uzgodnionych celów, z uwzględnieniem współdzielenia
informacji i wiedzy przez wspierane przez nie procesy biznesowe realizowane za pomocą wymiany danych za pośrednictwem wykorzystywanych przez te podmioty systemów teleinformatycznych.
49) Istotna Funkcja Oprogramowania - funkcja, której brak uniemożliwia wykorzystanie danego modułu Oprogramowania Aplikacyjnego i uniemożliwia działanie Zamawiającego w zakresie funkcjonalnym tego modułu Oprogramowania.
50) ITIL (ang. Information Technology Infrastructure Library) - zbiór zaleceń dotyczących efektywnego i skutecznego zarządzania usługami informatycznymi w wersji III opublikowanej w 2007 roku.
51) Kierownik Projektu – patrz Kierownik Projektu Zamawiającego.
52) Kierownik Projektu Wykonawcy - osoba z ramienia Wykonawcy uprawomocniona do jego reprezentowania w zakresie realizacji Umowy odpowiedzialna za jej prawidłową realizację.
53) Kierownik Projektu Zamawiającego - osoba reprezentująca Zamawiającego w zakresie realizacji Umowy, odpowiedzialna za jej prawidłową realizację.
54) Kod Źródłowy - słowniki, skrypty, definicje, pliki źródłowe bazy danych, jak również biblioteki, algorytmy oraz jakiekolwiek inne symboliczne lub konwencjonalne przedstawienie zapisu informacji, niezbędne do kompilacji, wykonania i utrzymania, funkcjonowania i utrzymania Systemu, z wyłączeniem Oprogramowania Systemowego.
55) KRI - Krajowe Ramy Interoperacyjności – zestaw wymagań semantycznych, organizacyjnych oraz technologicznych dotyczących interoperacyjności systemów teleinformatycznych i rejestrów publicznych, określonych w Rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2017 r. poz. 2247 z późn. zm.).
56) Moduł - część Systemu tworząca logiczną całość, dostarczająca zbiór funkcjonalności określony w OPZ.
57) Modyfikacja - każda proponowana zmiana Systemu lub jego funkcjonalności, odbiegająca od stanu i funkcjonalności Systemu opisanego w SIWZ i Dokumentacji, zgłoszona przez Użytkownika Końcowego w formie Zgłoszenia.
58) Modyfikacja kodu źródłowego - każda zmiana kodu źródłowego Standardowego Oprogramowania Aplikacyjnego, dokonana przez Wykonawcę w ramach wykonywania obowiązków wynikających z realizacji zamówienia.
59) Naprawa - spowodowanie przez Wykonawcę Normalnego Działania Systemu, w tym usunięcie zgłoszonych Błędów, Awarii, Wad na zasadach określonych w treści Specyfikacji Warunków Zamówienia.
60) Nienormalne Działanie Systemu - stan Systemu lub jego działanie w sposób nie zgodny z SWZ i Dokumentacją.
61) Normalne Działanie Systemu - stan Systemu lub jego działanie w sposób zgodny z SWZ i Dokumentacją.
62) Obsługa standardów OGC - możliwość publikowania usług internetowych, takich jak
mapa, rastry, lokalizator, geoprzetwarzanie, KML, WMS, WCS, WFS, WFS- T, REST i SOAP.
63) Okienko serwisowe - czas wyznaczony na zgłaszanie Błędów oraz Awarii jak również korzystania z Asysty Technicznej. Okienko serwisowe obowiązuje w godzinach w Dni Robocze: w godz. od 8:00 do 16:00.
64) Oprogramowanie - Oprogramowanie Aplikacyjne lub Oprogramowanie Osób Trzecich.
65) Oprogramowanie Aplikacyjne - Standardowe Oprogramowanie Wykonawcy wraz z Modyfikacjami Wykonawcy.
66) Oprogramowanie Osób Trzecich - Oprogramowanie komputerowe inne niż Oprogramowanie Aplikacyjne, wchodzące w skład Systemu z wyłączeniem Oprogramowania Narzędziowego oraz Oprogramowania Systemowego
67) Oprogramowanie Narzędziowe - Oprogramowanie i licencje dostępowe niezbędne do prawidłowego funkcjonowania Oprogramowania lub zarządzania zainstalowanymi urządzeniami lub do usprawniania i modyfikowania Oprogramowania Systemowego potrzebne do działania Systemu zgodnie z wymaganiami Zamawiającego określonymi w treści Specyfikacji Istotnych Warunków Zamówienia.
68) Oprogramowanie Systemowe - odpowiednie Oprogramowanie i licencje dostępowe realizujące funkcje niezbędne do uruchomienia i działania urządzeń, na których zostało zainstalowane.
69) OPZ - Opis Przedmiotu Zamówienia zawarty w niniejszym Załączniku nr 1 do SWZ.
70) Plan realizacji projektu - szczegółowy zakres zadań dla Wykonawcy i Zamawiającego związanych z zarządzaniem Projektem zgodnie z założeniami Metodyki PRINCE2. Plan realizacji projektu zostanie przygotowany przez Wykonawcę i uszczegółowiony w zakresie dotyczącym: osób funkcyjnych i ich zakresu odpowiedzialności, komunikacji w projekcie pomiędzy stronami, obiegu dokumentów, zarządzania zmianami i ryzykiem.
71) Problem - nieznana przyczyna Incydentu.
72) Produkt - produkt zarządczy, produkt specjalistyczny lub usługa - rozumiane w myśl metodyki Prince2, który ma być dostarczony przez Wykonawcę w ramach Zamówienia zgodne z SWZ, w szczególności Oprogramowanie oraz Oprogramowanie Narzędziowe, Dokumentacja, a także wszelkie materiały i informacje, w tym niepodlegające ochronie prawa autorskiego, stworzone lub opracowane przez Wykonawcę i dostarczone Zamawiającemu w ramach realizacji Przedmiotu Zamówienia.
73) Profil zaufany – bezpłatna metoda potwierdzania tożsamości obywatela w systemach elektronicznej administracji – odpowiednik bezpiecznego podpisu elektronicznego, weryfikowanego certyfikatem kwalifikowanym. Wykorzystując profil zaufany obywatel może załatwić sprawy administracyjne (np. wnoszenie podań, odwołań, skarg) drogą elektroniczną bez konieczności osobistego udania się do urzędu.
74) Projekt - projekt pn.: „Poprawa jakości świadczenia usług publicznych w formie elektronicznej w Gminie Michałowice” współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Mazowieckiego na lata 2014-2020, Poddziałanie
2.1.2 „E-usługi dla Mazowsza w ramach ZIT”.
75) Propozycja zmian Systemu (Modyfikacja) - każda proponowana zmiana Systemu lub jego funkcjonalności, odbiegająca od stanu i funkcjonalności Systemu opisanego w SIWZ i Dokumentacji, zgłoszona przez Użytkownika Końcowego w formie Zgłoszenia.
76) Protokół Odbioru - Protokół Odbioru Etapu lub Protokół Odbioru Produktu lub Protokół Odbioru Końcowego.
77) Protokół Odbioru Końcowego - protokół potwierdzający realizację wszystkich zadań.
78) Protokół Odbioru Zadania/Etapu - protokół potwierdzający realizację wskazanych w OPZ zadań do wykonania.
79) Pytania Wykonawców i odpowiedzi Zamawiającego - zbiór wszystkich zapytań i odpowiedzi do Opisu Przedmiotu Zamówienia udzielonych w trakcie postępowania przetargowego.
80) Rejestr – uporządkowany, wyposażony w system identyfikatorów wykaz zasobów wraz z
atrybutami.
81) Rejestr publiczny - rejestr, ewidencja, wykaz, lista, spis albo inna forma ewidencji, służące do realizacji zadań publicznych, prowadzone przez podmiot publiczny na podstawie odrębnych przepisów ustawowych.
82) Rozbudowa – udoskonalenie, rozbudowa funkcjonującego w JST systemu informatycznego, modułu lub aplikacji, bądź całkowita wymiana na inny system, moduł wraz z kompletnym przeniesieniem (migracją) wszystkich danych z obecnych struktur bazodanowych w celu zapewnienia ciągłości prac w urzędzie.
83) SWZ - Specyfikacja Warunków Zamówienia.
84) System - spójna całość wszystkich wdrożonych elementów składających się na Przedmiot Zamówienia, tj. „Zakup licencji, wdrożenie i uruchomienie e-usług oraz szkolenia w ramach projektu pn.: „Poprawa jakości świadczenia usług publicznych w formie elektronicznej w Gminie Michałowice””, udostępniający funkcjonalność oferowaną przez Wykonawcę, na który składają się w szczególności Oprogramowanie oraz Oprogramowania Narzędziowe, wraz z Zasobem Informacyjnym zgromadzonym w Systemie.
85) System dziedzinowy - samodzielny i niezależny system informatyczny, stworzony do świadczenia usług dla określonego obszaru danej jednostki. Nie stanowi on części innego systemu dziedzinowego, ale może być z nim powiązany i zintegrowany. System dziedzinowy może być źródłem informacji dla innych systemów dziedzinowych, (czyli bazą referencyjną) np. System Ewidencja Ludności może być słownikiem dla innych systemów w zakresie bazy mieszkańców. System może być związany z prowadzeniem rejestru lub ewidencji z danej dziedziny.
86) System informacyjny – system, którego elementami są informacje i układy służące do zarządzania nimi.
87) System informatyczny – system informacyjny, zarządzający informacją z wykorzystaniem narzędzi informatycznych.
88) System tradycyjny — system wykonywania czynności kancelaryjnych, dokumentowania przebiegu załatwiania spraw, gromadzenia i tworzenia dokumentacji w postaci nieelektronicznej, z możliwością korzystania z narzędzi informatycznych do wspomagania procesu obiegu dokumentacji w tej postaci.
89) System Rejestracji Zgłoszeń - spójny system procedur, narzędzi informatycznych mający na celu zrealizowanie wszystkich wymagań Zamawiającego dotyczących przyjmowania i Rozwiązywania Zgłoszeń, w szczególności uruchomienie usługi Internetowego System Obsługi Help Desk w ramach Asysty i Gwarancji Jakości.
90) Szkolenia - spójny, zorganizowany, dostarczony przez Wykonawcę system dedykowanych dla Zamawiającego szkoleń, o których mowa w SIWZ, przeprowadzony w sposób umożliwiający samodzielne użytkowanie oraz samodzielną obsługę i utrzymanie całego Systemu i jego wszystkich elementów przez Zamawiającego Projektu zgodnie z Załącznikiem nr 1 do SIWZ.
91) Środki komunikacji elektronicznej - środki komunikacji elektronicznej w rozumieniu art. 2 pkt 5 ustawy z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz.U. 2017 poz. 1219).
92) Urządzenie - element Infrastruktury Sprzętowej.
93) Urządzenie teleinformatyczne - element Infrastruktury Sprzętowej.
94) Usterka - każdy stan lub działanie Systemu lub Produktu, w tym działanie w trybie
awaryjnym, niezgodne z SIWZ i Dokumentacją.
95) Utwór - wykonane w ramach realizacji Przedmiotu Zamówienia przez Wykonawcę wszelkie projekty koncepcje, opracowania, bazy danych, programy komputerowe oraz wszelkie inne utwory w rozumieniu przepisów ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (tj. Dz. U. z 2018 r., poz. 1191z późn. zm.)
96) Uwaga - opis niezgodności Produktu z wymaganiami Zamawiającego opisanymi w SWZ i Załącznikach do SWZ stanowiących jego integralną część, w szczególności każda Wada, Błąd lub Usterka.
97) Użytkownik Końcowy - Użytkownik lub inny system informatyczny bezpośrednio eksploatujący funkcje Systemu.
98) Wada - zakłócenie działania oprogramowania polegające na nienależytym działaniu jego części, nie ograniczające działania całego oprogramowania; nie mające istotnego wpływu na zastosowanie oprogramowania i nie będące Awarią lub Błędem.
99) Wdrożenie - całokształt prac wykonanych przez Wykonawcę w celu umożliwienia samodzielnej eksploatacji Oprogramowania przez pracowników Zamawiającego, a w szczególności czynności takich jak: dostawa, instalacja, konfiguracja oprogramowania, przygotowanie danych testowych, wykonanie testów weryfikacyjnych i wydajnościowych, przygotowanie szablonów oraz scenariuszy testowych, współudział w testach akceptacyjnych, opracowanie i dostarczenie dokumentacji technicznej i użytkownika, przeprowadzenie migracji i ładowanie danych, przeprowadzenie prezentacji funkcjonalności Systemu, szkolenie pracowników Zamawiającego oraz świadczenie usług asysty technicznej na etapie uruchomienia Modułów Systemu celem doprowadzenia do normalnej, prawidłowej eksploatacji Systemu zgodnie z zapisami SIWZ oraz załączników.
100) Wiodące Przeglądarki WWW – pięć najpopularniejszych, stabilnych przeglądarek internetowych wg serwisu xxx.xxxxxxx.xx na dzień złożenia oferty.
101) Wykonawca - oznacza osobę fizyczną, osobę prawną albo jednostkę organizacyjną nieposiadającą osobowości prawnej, która zostanie wyłoniona w niniejszym postępowaniu o udzielenie zamówienia publicznego.
102) Zamawiający – Gmina Michałowice.
103) Zapytanie - rodzaj Zgłoszenia polegający na zdefiniowaniu pytania do Wykonawcy dotyczącego Systemu jego obsługi i funkcjonowania przez Użytkownika Końcowego.
104) Zarządzanie Incydentem - efektywna działalność Wykonawcy mająca na celu przywrócenie Normalnego Działania Systemu w możliwie jak najkrótszym czasie, minimalizując zakłócenia w pracy w taki sposób, aby zapewnić osiągnięcie możliwie najwyższego poziomu dostępności Systemu.
105) Zarządzanie Problemem - efektywna działalność Wykonawcy mająca na celu znalezienie przyczyny Incydentu i sposobu na przywrócenie poprawnego działania Systemu poprzez usunięcie przyczyny Incydentu.
106) Zasoby Informacyjne (Zasoby Informacyjne Systemu) - obiekty, którymi są dane i informacje oraz zbiory tych obiektów, gromadzone, jako rejestry, ewidencje, dokumenty oraz zbiory dokumentów lub inna informacja przechowywana i przetwarzana w Systemie będących własnością Zamawiającego.
107) Zdarzenie - Zapytanie, Modyfikacja oraz każde nienormalne działanie Systemu, które ma negatywny wpływ na działanie Systemu, jego elementów lub funkcjonalności, tzn. sytuacja, w której zachowanie Oprogramowania albo wynik działania jest odmienny od
zamierzonego określonego w Dokumentacji Użytkowej Oprogramowania, które nie jest
spowodowane niezgodnym z Dokumentacją działaniem Użytkownika Końcowego.
108) Zespół Wdrożeniowy Wykonawcy - zespół pracowników Wykonawcy posiadający niezbędną wiedzę i doświadczenie z zakresu poszczególnych aplikacji Systemu oferowanego przez Wykonawcę oraz usług związanych z ich wdrożeniem.
109) Zespół Wdrożeniowy Zamawiającego - zespół składający się z pracowników Zamawiającego posiadających merytoryczną, gospodarczą i ekonomiczną wiedzę w zakresie każdego z wdrażanych Systemów oraz ewentualnie pracowników działów informatyki, oddelegowanych decyzją Zamawiającego do zadań związanych z Wdrożeniem Systemu.
110) Zgłoszenie - Incydent lub Problem zgłoszony przez Użytkownika Końcowego dotyczący Systemu. W szczególności Zgłoszeniem mogą być również Modyfikacje, Zapytania oraz Zmiany Konfiguracji Systemu.
111) Zmiana Konfiguracji Systemu - jakakolwiek zmiana parametrów Systemu wobec
zdefiniowanych w SIWZ i Dokumentacji.
112) XML - Format XML (Extensible Markup Language) jest to obecnie powszechnie uznany standard publiczny, umożliwiający wymianę danych między różnymi systemami, standard zgodny z KRI.
113) XSD - Język definicji schematu XML (XML Schema Definition) służy do definiowania struktury dokumentów XML. Jego podstawowym zadaniem jest umożliwianie aplikacjom takiego opisywania dokumentów XML, aby inne aplikacje używające tych dokumentów mogły zakładać, że dokument jest zgodny z przewidzianą strukturą. Język XSD, popierany przez konsorcjum World Wide Web Consortium (W3C), zawiera dziesiątki definicji i poleceń deklaracyjnych, które umożliwiają opis struktury dokumentów.
114) XSLT i XSL - XSL (ang. Extensible Stylesheet Language) - opisuje sposób prezentacji i przekształceń dokumentów zapisanych w XML. XSLT (ang. Extensible Stylesheet Language: Transformations) jest podzbiorem XSL. Język XSL jest używany do definiowania formatowania dokumentów XML, a język XSLT zawiera szablony i polecenia służące do manipulowania strukturą danych.
4.1.2 Ogólne warunki licencjonowania dostarczonych systemów
informatycznych
1) Licencjobiorcą wszystkich licencji będzie Gmina Michałowice.
2) Licencja musi być udzielona na czas nieograniczony.
3) Oferowane licencje muszą pozwalać na użytkowanie oprogramowania zgodnie z
przepisami prawa.
4) Licencja oprogramowania nie może ograniczać prawa licencjobiorcy do rozbudowy, zwiększenia liczby serwerów obsługujących oprogramowanie, przeniesienia danych na osobny serwer aplikacji, osobny serwer plików.
5) Licencja oprogramowania musi być licencją bez ograniczenia liczby użytkowników, komputerów, serwerów, na których można zainstalować i używać oprogramowanie.
6) Licencja na oprogramowanie nie może w żaden sposób ograniczać sposobu pracy użytkowników końcowych (np. praca w sieci LAN, praca zdalna poprzez Internet).
7) Licencja oprogramowania nie może ograniczać prawa licencjobiorcy do wykonania
kopii bezpieczeństwa oprogramowania w liczbie, którą uzna za stosowną.
8) Licencja oprogramowania nie może ograniczać prawa licencjobiorcy do instalacji użytkowania oprogramowania na serwerach zapasowych uruchamianych w przypadku awarii serwerów podstawowych.
9) Licencja oprogramowania nie może ograniczać prawa licencjobiorcy do korzystania z oprogramowania na dowolnym komputerze klienckim (licencja nie może być przypisana do komputera/urządzenia).
Uwierzytelniane lub podpisywane elektronicznych dokumentów w modułach (aplikacjach) uruchomionych w ramach przedmiotowego zamówienia będzie realizowane poprzez profil zaufany e-PUAP oraz za pośrednictwem Węzła krajowego xxxxx.xxx.xx jak również loginu i hasła nadawanego przez Urząd Gminy Michałowice.
Klient będzie mógł zalogować się do systemu dopiero po otrzymaniu w Urzędzie „gminnego loginu” lub też poprzez tzw. „profil zaufany” na platformie ePUAP lub xxxxx.xxx.xx - wówczas nie będzie konieczne staranie się o lokalny, gminny login. Powyższe metody uwierzytelniania danych są adekwatne do celów i zakresu projektu - dzięki profilowi zaufanemu ePUAP oraz xxxxx.xxx.xx lub „gminnemu loginowi” obywatel będzie mógł załatwić sprawy administracyjne drogą elektroniczną, bez konieczności wychodzenia z domu, 24 godziny na dobę, z dowolnego miejsca.
4.1.4 Minimalne wymagania w zakresie bazy danych
Wykonawca odpowiada za sprawne i wydajne działanie całego rozwiązania na bazie danych.
Poniższy opis należy traktować jako minimalny, ponieważ Wykonawca musi zapewnić odpowiednie parametry i warunki np. liczbę licencji. Dopuszczalne jest zastosowanie mechanizmów wirtualizacji.
System bazodanowy (SBD) musi spełniać następujące wymagania poprzez wbudowane
mechanizmy:
Lp. | Opis minimalnych wymagań: |
1. | Możliwość wykorzystania SBD jako silnika relacyjnej bazy danych, analitycznej, wielowymiarowej bazy danych, platformy bazodanowej dla wielu aplikacji. Powinien zawierać serwer raportów, narzędzia do: definiowania raportów, wykonywania analiz biznesowych, tworzenia procesów ETL. |
2. | Zintegrowane narzędzia graficzne do zarządzania systemem – SBD musi dostarczać zintegrowane narzędzia do zarządzania i konfiguracji wszystkich usług wchodzących w skład systemu (baza relacyjna, usługi analityczne, usługi raportowe, usługi transformacji danych). |
Narzędzia te muszą udostępniać możliwość tworzenia skryptów zarządzających systemem oraz automatyzacji ich wykonywania. | |
3. | Zarządzanie serwerem za pomocą skryptów - SBD musi udostępniać mechanizm zarządzania systemem za pomocą uruchamianych z linii poleceń skryptów administracyjnych, które pozwolą zautomatyzować rutynowe czynności związane z zarządzaniem serwerem. |
4. | Dedykowana sesja administracyjna - SBD musi pozwalać na zdalne połączenie sesji administratora systemu bazy danych w sposób niezależny od normalnych sesji klientów. |
5. | Możliwość automatycznej aktualizacji systemu - SBD musi umożliwiać automatyczne ściąganie i instalację wszelkich poprawek producenta oprogramowania (redukowania zagrożeń powodowanych przez znane luki w zabezpieczeniach oprogramowania). |
6. | SBD musi umożliwiać tworzenie klastrów niezawodnościowych. |
7. | Wysoka dostępność - SBD musi posiadać mechanizm pozwalający na duplikację bazy danych między dwiema lokalizacjami (podstawowa i zapasowa) przy zachowaniu następujących cech: - bez specjalnego sprzętu (rozwiązanie tylko programowe oparte o sam SBD), - niezawodne powielanie danych w czasie rzeczywistym (potwierdzone transakcje bazodanowe), - klienci bazy danych automatycznie korzystają z bazy zapasowej w przypadku awarii bazy podstawowej bez zmian w aplikacjach, |
8. | Kompresja kopii zapasowych - SBD musi pozwalać na kompresję kopii zapasowej danych (backup) w trakcie jej tworzenia. Powinna to być cecha SBD niezależna od funkcji systemu operacyjnego ani od sprzętowego rozwiązania archiwizacji danych. |
9. | Możliwość automatycznego szyfrowania kopii bezpieczeństwa bazy danych przy użyciu między innymi certyfikatów lub kluczy asymetrycznych. System szyfrowania musi wspierać następujące algorytmy szyfrujące: AES 256, Triple DES. Mechanizm ten nie może wymagać konieczności uprzedniego szyfrowania bazy danych. |
10. | Możliwość zastosowania reguł bezpieczeństwa obowiązujących w przedsiębiorstwie - wsparcie dla zdefiniowanej w przedsiębiorstwie polityki bezpieczeństwa (np. automatyczne wymuszanie zmiany haseł użytkowników, zastosowanie mechanizmu weryfikacji dostatecznego poziomu komplikacji haseł wprowadzanych przez użytkowników), możliwość zintegrowania uwierzytelniania użytkowników z usługą katalogową. |
11. | Możliwość definiowania reguł administracyjnych dla serwera lub grupy serwerów - SBD musi mieć możliwość definiowania reguł wymuszanych przez system i zarządzania nimi. Przykładem takiej reguły jest uniemożliwienie użytkownikom tworzenia obiektów baz danych o zdefiniowanych przez administratora szablonach nazw. Dodatkowo wymagana jest możliwość rejestracji i raportowania niezgodności działającego systemu ze wskazanymi regułami, bez wpływu na jego funkcjonalność. |
12. | Rejestrowanie zdarzeń silnika bazy danych w czasie rzeczywistym - SBD musi posiadać możliwość rejestracji zdarzeń na poziomie silnika bazy danych w czasie rzeczywistym w celach diagnostycznych, bez ujemnego wpływu na wydajność rozwiązania, pozwalać na selektywne wybieranie rejestrowanych zdarzeń. Wymagana jest rejestracja zdarzeń: - odczyt/zapis danych na dysku dla zapytań wykonywanych do baz danych (w celu wychwytywania zapytań znacząco obciążających system), - wykonanie zapytania lub procedury trwające dłużej niż zdefiniowany czas (wychwytywanie długo trwających zapytań lub procedur), - para zdarzeń zablokowanie/zwolnienie blokady na obiekcie bazy (w celu wychwytywania długotrwałych blokad obiektów bazy). |
13. | Zarządzanie pustymi wartościami w bazie danych - SBD musi efektywnie zarządzać pustymi wartościami przechowywanymi w bazie danych (NULL). W szczególności puste wartości wprowadzone do bazy danych powinny zajmować minimalny obszar pamięci. |
14. | Definiowanie nowych typów danych - SBD musi umożliwiać definiowanie nowych typów danych wraz z definicją specyficznej dla tych typów danych logiki operacji. |
Jeśli np. zdefiniujemy typ do przechowywania danych hierarchicznych, to obiekty tego typu powinny udostępnić operacje dostępu do „potomków” obiektu, „rodzica” itp. Logika operacji nowego typu danych powinna być implementowana w zaproponowanym przez Dostawcę języku programowania. Nowe typy danych nie mogą być ograniczone wyłącznie do okrojenia typów wbudowanych lub ich kombinacji. | |
15. | Wsparcie dla technologii XML - SBD musi udostępniać mechanizmy składowania i obróbki danych w postaci struktur XML. W szczególności musi: - udostępniać typ danych do przechowywania kompletnych dokumentów XML w jednym polu tabeli, - udostępniać mechanizm walidacji struktur XML-owych względem jednego lub wielu szablonów XSD, - udostępniać język zapytań do struktur XML, - udostępniać język modyfikacji danych (DML) w strukturach XML (dodawanie, usuwanie i modyfikację zawartości struktur XML), - udostępniać możliwość indeksowania struktur XML-owych w celu optymalizacji wykonywania zapytań. |
16. | Wsparcie dla danych przestrzennych - SBD musi zapewniać wsparcie dla geometrycznych i geograficznych typów danych pozwalających w prosty sposób przechowywać i analizować informacje o lokalizacji obiektów, dróg i innych punktów orientacyjnych zlokalizowanych na kuli ziemskiej, a w szczególności: - zapewniać możliwość wykorzystywania szerokości i długości geograficznej do opisu lokalizacji obiektów, - oferować wiele metod, które pozwalają na łatwe operowanie kształtami czy bryłami, testowanie ich wzajemnego ułożenia w układach współrzędnych oraz dokonywanie obliczeń takich wielkości, jak pola figur, odległości do punktu na linii, itp., - obsługa geometrycznych i geograficznych typów danych powinna być dostępna z poziomu języka zapytań do systemu SBD, - typy danych geograficznych powinny być konstruowane na podstawie obiektów wektorowych, określonych w formacie Well-Known Text (WKT) lub Well-Known Binary (WKB), (powinny być to x.xx. takie typy obiektów jak: lokalizacja (punkt), seria punktów, seria punktów połączonych linią, zestaw wielokątów, itp.). |
17. | Możliwość tworzenia funkcji i procedur w innych językach programowania - SBD musi umożliwiać tworzenie procedur i funkcji z wykorzystaniem innych języków programowania, niż standardowo obsługiwany język zapytań danego SBD. System musi umożliwiać tworzenie w tych językach x.xx. agregujących funkcji użytkownika oraz wyzwalaczy. Dodatkowo musi udostępniać środowisko do debuggowania. |
18. | Możliwość tworzenia rekursywnych zapytań do bazy danych - SBD musi udostępniać wbudowany mechanizm umożlwiający tworzenie rekursywnych zapytań do bazy danych bez potrzeby pisania specjalnych procedur i wywoływania ich w sposób rekurencyjny. |
19. | Obsługa błędów w kodzie zapytań - język zapytań i procedur w SBD musi umożliwiać zastosowanie mechanizmu przechwytywania błędów wykonania procedury (na zasadzie bloku instrukcji TRY/CATCH) – tak jak w klasycznych językach programowania. |
20. | Raportowanie zależności między obiektami - SBD musi udostępniać informacje o wzajemnych zależnościach między obiektami bazy danych. |
21. | Mechanizm zamrażania planów wykonania zapytań do bazy danych - SBD musi udostępniać mechanizm pozwalający na zamrożenie planu wykonania zapytania przez silnik bazy danych (w wyniku takiej operacji zapytanie jest zawsze wykonywane przez silnik bazy danych w ten sam sposób). Mechanizm ten daje możliwość zapewnienia przewidywalnego czasu odpowiedzi na zapytanie po przeniesieniu systemu na inny serwer (środowisko testowe i produkcyjne), migracji do innych wersji SBD, wprowadzeniu zmian sprzętowych serwera. |
22. | System transformacji danych - SBD musi posiadać narzędzie do graficznego projektowania transformacji danych. Narzędzie to powinno pozwalać na przygotowanie definicji |
transformacji w postaci pliku, które potem mogą być wykonywane automatycznie lub z asystą operatora. Transformacje powinny posiadać możliwość graficznego definiowania zarówno przepływu sterowania (program i warunki logiczne) jak i przepływu strumienia rekordów poddawanych transformacjom. Powinna być także zapewniona możliwość tworzenia własnych transformacji. Środowisko tworzenia transformacji danych powinno udostępniać x.xx.: - mechanizm debuggowania tworzonego rozwiązania, - mechanizm stawiania „pułapek” (breakpoints), - mechanizm logowania do pliku wykonywanych przez transformację operacji, - możliwość wznowienia wykonania transformacji od punktu, w którym przerwano jej wykonanie (np. w wyniku pojawienia się błędu), - możliwość cofania i ponawiania wprowadzonych przez użytkownika zmian podczas edycji transformacji (funkcja undo/redo) - mechanizm analizy przetwarzanych danych (możliwość podglądu rekordów przetwarzanych w strumieniu danych oraz tworzenia statystyk, np. histogram wartości w przetwarzanych kolumnach tabeli), - mechanizm automatyzacji publikowania utworzonych transformacji na serwerze bazy danych (w szczególności tworzenia wersji instalacyjnej pozwalającej automatyzować proces publikacji na wielu serwerach), - mechanizm tworzenia parametrów zarówno na poziomie poszczególnych pakietów, jak też na poziomie całego projektu, parametry powinny umożliwiać uruchamianie pakietów podrzędnych i przesyłanie do nich wartości parametrów z pakietu nadrzędnego, - mechanizm mapowania kolumn wykorzystujący ich nazwę i typ danych do automatycznego przemapowania kolumn w sytuacji podmiany źródła danych. | |
23. | Wbudowany system analityczny - SBD musi posiadać moduł pozwalający na tworzenie rozwiązań służących do analizy danych wielowymiarowych (kostki OLAP). Powinno być możliwe tworzenie: wymiarów, miar. Wymiary powinny mieć możliwość określania dodatkowych atrybutów będących dodatkowymi poziomami agregacji. Powinna być możliwość definiowania hierarchii w obrębie wymiaru. Przykład: wymiar bLokalizacja Geograficzna. Atrybuty: miasto, gmina, województwo. Hierarchia: Województwo->Gmina. |
24. | Wbudowany system analityczny musi mieć możliwość wyliczania agregacji wartości miar dla zmieniających się elementów (członków) wymiarów i ich atrybutów. Agregacje powinny być składowane w jednym z wybranych modeli (MOLAP – wyliczone gotowe agregacje rozłącznie w stosunku do danych źródłowych, ROLAP – agregacje wyliczane w trakcie zapytania z danych źródłowych). Pojedyncza baza analityczna musi mieć możliwość mieszania modeli składowania, np. dane bieżące ROLAP, historyczne – MOLAP w sposób przezroczysty dla wykonywanych zapytań. Dodatkowo powinna być dostępna możliwość drążenia danych z kostki do poziomu rekordów szczegółowych z bazy relacyjnych (drill to detail). |
25. | Wbudowany system analityczny musi pozwalać na dodanie akcji przypisanych do elementów kostek wielowymiarowych (np. pozwalających na przejście użytkownika do raportów kontekstowych lub stron www powiązanych z przeglądanym obszarem kostki). |
26. | Wbudowany system analityczny musi posiadać narzędzie do rejestracji i śledzenia zapytań wykonywanych do baz analitycznych. |
27. | Wbudowany system analityczny musi obsługiwać wielojęzyczność (tworzenie obiektów wielowymiarowych w wielu językach – w zależności od ustawień na komputerze klienta). |
28. | Wbudowany system analityczny musi udostępniać rozwiązania Data Mining, x.xx.: algorytmy reguł związków (Association Rules), szeregów czasowych (Time Series), drzew regresji (Regression Trees), sieci neuronowych (Neural Nets oraz Naive Bayes). Dodatkowo system musi udostępniać narzędzia do wizualizacji danych z modelu Data Mining oraz język zapytań do odpytywania tych modeli. |
29. | Tworzenie głównych wskaźników wydajności KPI (Key Performance Indicators - kluczowe czynniki sukcesu) - SBD musi udostępniać użytkownikom możliwość tworzenia wskaźników KPI (Key Performance Indicators) na podstawie danych zgromadzonych w strukturach wielowymiarowych. W szczególności powinien pozwalać na zdefiniowanie takich elementów, jak: wartość aktualna, cel, trend, symbol graficzny wskaźnika w zależności od stosunku wartości aktualnej do celu. |
30. | System raportowania - SBD musi posiadać możliwość definiowania i generowania raportów. Narzędzie do tworzenia raportów powinno pozwalać na ich graficzną definicję. Raporty powinny być udostępnianie przez system protokołem http (dostęp klienta za pomocą przeglądarki), bez konieczności stosowania dodatkowego oprogramowania po stronie serwera. Dodatkowo system raportowania musi obsługiwać: - raporty parametryzowane, - cache raportów (generacja raportów bez dostępu do źródła danych), - cache raportów parametryzowanych (generacja raportów bez dostępu do źródła danych, z różnymi wartościami parametrów), - współdzielenie predefiniowanych zapytań do źródeł danych, - wizualizację danych analitycznych na mapach geograficznych (w tym import map w formacie ESRI Shape File), - możliwość opublikowania elementu raportu (wykresu, tabeli) we współdzielonej bibliotece, z której mogą korzystać inni użytkownicy tworzący nowy raport, - możliwość wizualizacji wskaźników KPI, - możliwość wizualizacji danych w postaci obiektów sparkline |
31. | Środowisko raportowania powinno być osadzone i administrowane z wykorzystaniem mechanizmu Web Serwisów (Web Services). |
32. | Wymagane jest generowanie raportów min. w formatach: XML, PDF, Microsoft Excel, Microsoft Word, HTML, TIFF. Dodatkowo raporty powinny być eksportowane w formacie Atom data feeds, które można będzie wykorzystać jako źródło danych w innych aplikacjach. |
33. | SBD musi umożliwiać rozbudowę mechanizmów raportowania x.xx. o dodatkowe formaty eksportu danych, obsługę nowych źródeł danych dla raportów, funkcje i algorytmy wykorzystywane podczas generowania raportu (np. nowe funkcje agregujące), mechanizmy zabezpieczeń dostępu do raportów. |
34. | SBD musi umożliwiać wysyłkę raportów drogą mailową w wybranym formacie (subskrypcja). |
35. | Wbudowany system raportowania musi posiadać rozszerzalną architekturę oraz otwarte interfejsy do osadzania raportów oraz do integrowania rozwiązania z różnorodnymi środowiskami IT. |
36. | W celu zwiększenia wydajności przetwarzania system bazy danych musi posiadać wbudowaną funkcjonalność pozwalającą na rozszerzenie cache’u przetwarzania w pamięci RAM o dodatkową przestrzeń na dysku SSD. |
37. | System bazy danych, w celu zwiększenia wydajności, musi zapewniać możliwość asynchronicznego zatwierdzania transakcji bazodanowych (lazy commit). Włączenie asynchronicznego zatwierdzania transakcji powinno być dostępne zarówno na poziomie wybranej bazy danych, jak również z poziomu kodu pojedynczych procedur/zapytań. |
38. | W celu zwiększenia bezpieczeństwa i niezawodności system bazy danych musiudostępniać komendę pozwalającą użytkownikowi na utrwalenie na dysku wszystkich zatwierdzonych asynchronicznych transakcji (lazy commit). |
39. | System dziedzinowy oraz EZD muszą wykorzystywać wyspecyfikowany system bazodanowy. |
Zamawiający posiada bazę danych Microsoft SQL Serwer 2017 Standard licencjonowaną „na procesor” (licencja obejmuje 4 rdzenie procesora) bez limitu ilości użytkowników. W ramach posiadanej licencji można wydzielić dodatkowe konta i bazy na potrzeby systemów
wdrażanych w ramach realizacji zamówienia. Jeśli dostawca systemu potrzebuje innej licencjonowanej bazy danych musi dostarczyć ją wraz z systemem.
Zamówienia
zakres
i
wymagania
przedmiotu
Oferowany system informatyczny ani rozwiązanie w dniu składania ofert nie może być przeznaczony przez producenta do wycofania z produkcji, sprzedaży lub z wsparcia technicznego przez okres min. 5 lat od daty odbioru końcowego przedmiotu niniejszego Zamówienia.
Kluczowym elementem zamówienia będzie Portal Systemu (Portal) koncentrujący e-Usługi uruchamiane w ramach niniejszego postępowania. Poniżej specyfikacja minimalnych wymagań dla rozwiązania wraz z charakterystyką e-Usług oraz minimalnymi wymaganiami dla systemów zasilających e-Usługi.
Lp. | Opis minimalnych wymagań: |
1. | Portal musi wykorzystywać elementy architektury opartej na usługach (ang. Service-Oriented Architecture, SOA). |
2. | Portal musi być zgodny ze standardem WCAG 2.1.AA |
3. | Portal musi zapewniać komunikację z ESP (Elektroniczna Skrzynka Podawcza) ePUAP oraz wykorzystywać usługę ESP platformy ePUAP. Mieszkaniec raz zalogowany do Portal danymi ePUAP nie powinien musieć logować się ponownie do platformy ePUAP. |
4. | Portal musi umożliwiać założenie konta Mieszkańca także poprzez system EZD. Konto powinno być wykorzystywane w celu uwierzytelniania Mieszkańca, celem dostępu np. do informacji na temat sprawy. |
5. | Portal musi pozwalać na udostępnienie (po uwierzytelnieniu Mieszkańca) informacji o prowadzonej sprawie. Portal winien dostarczać co najmniej następujących informacji: • status sprawy • znak sprawy • osoba prowadząca • dokumenty w sprawie |
6. | Portal musi pozwalać rozróżniać Mieszkańców na osoby fizyczne, osoby prawne i podmioty gospodarcze (firmy). |
7. | Portal musi pozwalać weryfikować adres e-mail Mieszkańca poprzez link weryfikujący. |
8. | Portal musi pozwalać na ponowne wysłanie linku weryfikującego na konto e-mail Mieszkańca (z poziomu panelu administratora). |
9. | Portal musi pozwalać na zablokowanie konta Mieszkańca (z poziomu panelu administratora). |
10. | Portal musi pozwalać na odzyskanie dostępu do konta Mieszkańca. |
11. | Portal musi pozwalać na zmianę hasła z poziomu konta Mieszkańca. |
12. | Portal musi pozwalać na wyszukiwanie po nazwie usługi. |
13. | Portal musi pozwalać na pobranie dokumentów powiązanych z kartami usług np. wniosków do pobrania. |
14. | Portal musi integrować się z platformą ePUAP (pobieranie e-usług ePUAP, synchronizacja formularzy ePUAP). |
15. | Portal musi umożliwiać bezpieczne logowanie/uwierzytelnianie poprzez mechanizmy Węzła Krajowego oraz za pomocą loginu i hasła. |
16. | Portal musi pozwalać na grupowanie e-usług na poziomie lokalnym (Urząd i Jednostki Organizacyjne). |
17. | Portal powinien współpracować z relacyjną bazą danych SQL w wersji komercyjnej oraz darmowej. |
18. | System musi zapewniać ochronę danych osobowych i informacji stanowiących tajemnicę skarbową zgodnie z obowiązującymi w tym zakresie przepisami oraz musi być zgodny z postanowieniami WCAG 2.1 tj. wytycznych dotyczących dostępności treści internetowych zgodnie z ustawą z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848). |
19. | Portal musi pozwalać na obsługę danych dla Mieszkańców w zakresie korzystania z e-usług: a) e-przyłącze – przyłączenie do sieci wodociągowej i kanalizacyjnej w gminie b) e-rozliczenia za usługę dostarczania wody oraz zrzut ścieków c) e-zgłoszenia w zakresie awarii sieci wod-kan d) e-rekrutacja do placówek przedszkolnych e) e-rekrutacja do szkół podstawowych f) e-rekrutacja do liceum ogólnokształcącego w tym kalkulator szans edukacyjnych. |
20. | Portal musi pozwalać na obsługę danych (dla zalogowanych Mieszkańców) dla następujących e-Usług e-podatki, w tym: a) e-podatki - os. fizyczne, b) e-podatki - os. prawne, c) e-podatki - śr. transportowe os. fizyczne, d) e-podatki - śr. transportowe os. prawne, e) e-podatki - odpady. |
21. | e-podatki xx. xxxxxxxx |
00. | Płatności przez Internet za zobowiązania z tytułu podatku od nieruchomości osób fizycznych. Indywidualne dane finansowe: globalne kwoty należności i wpłat, harmonogram płatności, realizacja płatności i przeterminowanie, indywidualne dane majątkowe: wykaz nieruchomości wraz ze składnikami i ich danymi wpływającymi na wymiar podatku, informacja o tytule płatności, rozrachunkach z urzędem (dane dotyczące przypisów i zrealizowanych płatności). |
23. | e-podatki os. prawne |
24. | Płatności przez Internet za zobowiązania z tytułu podatku od nieruchomości osób prawnych. Indywidualne dane finansowe: globalne kwoty należności i wpłat, harmonogram płatności, realizacja płatności i przeterminowanie. Indywidualne dane majątkowe: wykaz nieruchomości wraz ze składnikami i ich danymi wpływającymi na wymiar podatku |
25. | e-podatki śr. transportowe xx. xxxxxxxx |
00. | Płatności przez Internet za zobowiązania z tytułu podatku od środków transportu. Indywidualne dane finansowe: globalne kwoty należności i wpłat, harmonogram płatności, realizacja płatności i przeterminowanie indywidualne dane ilościowe: lista pojazdów z ich danymi wpływającymi na wymiar podatku. |
27. | e-podatki śr. transportowe os. prawne |
28. | Płatności przez Internet za zobowiązania z tytułu podatku od środków transportu. Indywidualne dane finansowe: globalne kwoty należności i wpłat, harmonogram płatności, realizacja płatności i przeterminowanie indywidualne dane ilościowe: lista pojazdów z ich danymi wpływającymi na wymiar podatku. |
29. | e-podatki odpady |
30. | Płatności przez Internet za zobowiązania z tytułu wywozu odpadów komunalnych. Indywidualne dane finansowe: globalne kwoty należności i wpłat, harmonogram płatności, realizacja płatności i przeterminowanie Indywidualne dane ilościowe: wykaz nieruchomości objętych opłatą, wybrane dane ze złożonej deklaracji |
31. | e-formularze |
32. | W ramach zamówienia Wykonawca musi dostarczyć wszystkie e-formularze ePUAP niezbędne do zrealizowania usług wymienionych powyżej. Specyfikacja e-formularzy została określona w części dotyczącej wdrożenia rozwiązania. |
33. | e-płatności |
34. | e-płatności muszą pozwalać na wykorzystanie min. następujących Instrumentów Płatniczych: a) przelewy Pay-by-link (PBL); b) płatności automatyczne BLIK; c) karty płatnicze (VISA, MasterCard); d) szybkie przelewy (dla banków nieposiadających płatności PBL). |
35. | moduł e-płatności musi prezentować Historie Płatności. Historia Płatności musi w prosty sposób (lista) prezentować wszystkie opłaty wniesione przez Interesanta. Minimalny zakres danych to: |
a) Tytuł płatności; b) Kwota; c) Data wniesienia opłaty; d) Status. | |
36. | e-płatności powinien umożliwiać zdefiniowanie prowizji za obsługę płatności w tym przeniesienie prowizji na Urząd Gminy. |
37. | e-płatności muszą umożliwiać rozliczenie transakcji w postaci kilku przelewów i przekazanie ich do Odbiorcy na wskazane subkonta. |
38. | e-płatności muszą umożliwiać przekazywanie dodatkowego opisu dla każdej realizowanej transakcji. |
39. | e-płatności muszą pozwalać na zastosowanie mechanizmu generującego przypomnienia o zbliżających/zaległych płatnościach za pomocą wiadomości SMS. |
40. | system powiadamiania |
41. | system powiadamiania musi być zintegrowany z Portalem na potrzeby realizacji masowych powiadomień (np. SMS, e-mail, komunikator itp.) |
42. | Opłata skarbowa |
43. | Portal musi umożliwiać zapłatę opłaty skarbowej za załatwienie indywidualnych spraw urzędowych, czyli wydanie zaświadczeń/zezwoleń/pozwoleń/koncesji oraz niektórych dokumentów (np. sporządzenie aktu małżeństwa, udzielenie pełnomocnictwa itp.). |
Obsługa pozostałych e-usług dostępnych na Portalu Systemu - ePodatki
e-Podatki adresowane są do mieszkańców gminy, chcących posiadać wgląd do swoich zobowiązań podatkowych wobec Gminy. Usługa wyświetli informacje dotyczące bieżących rozliczeń podatków i opłat oraz umożliwia bezpośrednio z poniżej opisanych systemów zasilających, regulację zobowiązań podatkowych wobec gminy, w tym za pomocą szybkich płatności elektronicznych.
Usługa zostanie zintegrowana z Portalem w taki sposób aby korzystanie z funkcjonalności e- podatki było możliwe po zalogowaniu do Portalu, bez konieczności dodatkowego logowania do usługi.
Zamawiający nie posiada autorskich praw majątkowych do funkcjonującego w urzędzie oprogramowania, nie posiada kodów źródłowych oprogramowania, a licencja posiadanego oprogramowania nie umożliwia mu modyfikacji kodów źródłowych, zatem Zamawiający nie
jest w stanie zapewnić Wykonawcy, że udostępni mu stałe, niezmienne interfejsy integracyjne umożliwiające pełną wymianę danych z nowo uruchamianymi rozwiązaniami.
Wykonawca odpowiedzialny jest za dostawę w pełni funkcjonujących rozwiązań opisanych w niniejszym załączniku, w tym jeżeli jest konieczne, pozyskanie niezbędnych informacji do realizacji zamówienia, zawarcie koniecznych umów itp.
Mając na uwadze powyższe, w przypadku jeżeli Wykonawcy nie mają możliwości uzyskania odpowiedniego do realizacji dostępu do oprogramowania firm trzecich, w celu zapewnienia zasady konkurencyjności postępowania, Zamawiający dopuszcza wymianę systemu dziedzinowego na jedno zintegrowane rozwiązanie pod warunkiem, że:
1. Rozwiązania zastępujące dotychczas funkcjonujące u Zamawiającego systemy Wykonawca dostarcza i wdraża na swój koszt,
2. Wykonawca przeprowadzi niezbędną migrację danych na swój koszt.
3. Wymiana systemu nie może zakłócić bieżącej pracy Zamawiającego oraz musi zapewnić ciągłość pracy wynikającą z obowiązujących terminów, przepisów prawa i stosowanych procedur. W szczególności dotyczy to wymiaru podatków i opłat, ewidencji księgowej oraz sprawozdawczości budżetowej.
4. Szczegółowe parametry funkcjonalne jakie muszą spełniać po modernizacji Systemy
Dziedzinowe opisano w rozdziale 5.2.4.
4.2.2.1 Minimalne wymagania techniczne wodomierzy oraz zestawu inkasenckiego
W ramach przedmiotowego Zamówienia Wykonawca ma obowiązek dostarczyć zamawiającemu 1.490 szt. (słownie: tysiąc czterysta dziewięćdziesiąt) wodomierzy koniecznych do zdalnego odczytu zużycia wody oraz jedno urządzenie inkasenckie konieczne do zdalnego odczytu wskazań wodomierzy.
LP. | Minimalne wymagania techniczne wodomierzy |
1. | wodomierz statyczny, ultradżwiękowy do wody zimnej DN15; DN20; |
2. | klasa metrologiczna wg. MID minimum R250 w każdej pozycji montażu potwierdzona certyfikatem z akredytowanego laboratorium |
3. | liczydło hermetyczne - stopień ochrony IP 68 potwierdzony certyfikatem z akredytowanego laboratorium |
4. | korpus: zapewniający odpowiednią trwałość i posiadający stosowne atesty z akredytowanego laboratorium |
5. | Każdy dostarczony wodomierz winien być fabrycznie nowy i posiadać aktualną cechę legalizacyjną, którą nadano nie wcześniej niż w roku dostawy wodomierzy do Zamawiającego (cecha legalizacyjna powinna wskazywać rok kolejnej legalizacji jako 2027). |
6. | Numer wodomierza musi być trwale naniesiony na liczydle lub obudowie urządzenia. |
7. | Wszystkie wodomierze objęte niniejszym zamówieniem muszą pochodzić od jednego producenta ze względu na łatwą późniejszą eksploatację, reklamacje oraz serwis a także muszą stanowić jednorodną partię w rozumieniu Rozporządzenia Ministra Przedsiębiorczości I Technologii z dnia 22 marca 2019 r. w sprawie prawnej kontroli metrologicznej przyrządów pomiarowych (Dz.U.2019.759 z dnia 2019.04.26) tak aby było możliwe dokonanie legalizacji ponownej za pomocą metody statystycznej. |
8. | Wodomierze muszą posiadać zgodność z Dyrektywą 2014/32/EU Parlamentu Europejskiego i Rady Europy. |
9. | Wodomierze muszą być zgodne z Rozporządzeniem Ministra Gospodarki z dnia 23 października 2007r. w sprawie wymagań, którym powinny odpowiadać wodomierze oraz szczegółowego zakresu sprawdzeń wykonywanych podczas prawnej kontroli metrologicznej tych przyrządów pomiarowych (Dz. U. z 2007 r. nr 209, poz. 1513). |
10. | Wodomierze muszą posiadać aktualny atest higieniczny PZH. |
11. | Wymagany jest statyczny układ pomiarowy wodomierza, nieposiadający części ruchomych lub wirujących. Wodomierz podczas normalnej pracy nie może generować hałasu. |
12. | Wymagane jest liczydło w postaci elektronicznego wyświetlacza, objętość wyświetlana musi być wskazywana z dokładnością do 0,001 m3 |
13. | Xxxxxxxxxx powinny posiadać hermetycznie zamknięte liczydło klasy IP 68, odporne na zanieczyszczenia i zaparowanie (zaroszenie). |
14. | Wodomierze muszą posiadać wbudowane rejestry pamięci umożliwiające wykonanie rejestrów dobowych i miesięcznych. |
15. | Zamawiający nie określa minimalnej liczby rejestrów dobowych ani minimalnej liczby rejestrów miesięcznych. Rejestr logów zmiany nastawów urządzenia, w tym daty zmiany, parametrów i id urządzenia do zmiany danych (inkasenckiego). |
16. | Xxxxxxxxx musi wykrywać przepływ wsteczny i zapisywać go w rejestrze. |
17. | Wodomierze muszą być odporne na działanie silnego zewnętrznego pola magnetycznego (m. in. odporność na magnesy neodymowe). |
18. | Wodomierze muszą być przystosowane do montażu bez wymogu stosowania odcinków prostych. |
19. | Transmisja radiowa winna spełniając wymagania Rozporządzenia Ministra Administracji i Cyfryzacji z dnia 12 grudnia 2014 r. w sprawie urządzeń radiowych nadawczych lub nadawczo- odbiorczych, które mogą być używane bez pozwolenia radiowego (Dz. U. z 2017 r. poz. 96). |
20. | Dopuszczalne maksymalne ciśnienie robocze 1,6 MPa. |
21. | Wodomierze nie mogą być dłuższe niż L=190 mm, tak aby były zgodne z konsolami, w których będą mocowane. Dopuszcza się wodomierze o mniejszej długości. Wodomierze będą montowane w konsolach zakupionych w odrębnym postępowaniu. Zarówno zakup, jak i montaż konsol nie są przedmiotem niniejszego postępowania. |
22. | Gwarancja na wodomierze – min. 36 miesięcy – lub dłużej zgodnie ze złożoną ofertą. |
Wymagania dotyczące modułów radiowych: | |
23. | muszą być zaprogramowane oraz zintegrowane z oferowanymi wodomierzami. |
24. | muszą obsługiwać protokół LoRaWAN Class A oraz ewentualnie dodatkowo inny otwarty protokół komunikacyjny. |
25. | Wymagany system dwukierunkowej komunikacji między wodomierzem, a urządzeniem komunikacyjnym (zestawem inkasenckim). |
26. | muszą działać w otwartym kanale transmisyjnym niewymagającym koncesji. |
27. | Żywotność baterii w module musi wynosić minimum 13 lat tj. trzy okresy legalizacyjne wodomierzy w tym jeden statystyczny. |
28. | muszą informować o alarmach min. o: wycieku, nieprawidłowej pracy urządzenia, słabej baterii, przepływie wstecznym. |
29. | Wymagana jest automatyczna rejestracja stanu wodomierza w module minimum 1 raz na dobę. |
30. | Cała konstrukcja musi mieć stopień ochrony IP68. |
31. | Moduł musi posiadać certyfikat zgodności CE. |
32. | Zamawiający wymaga udostępnienia charakterystyki ramki danych wysyłanych przez moduły radiowe (payload) oraz następujących kluczy szyfrujących: - DevAddr (Adres Urządzenia) |
- AppSKey (Klucz Sesji Aplikacji) - NetSKey (Klucz Xxxxx Xxxxxxxxx) | |
33. | Wymagane jest dostarczenie pliku z kluczami szyfrującymi powiązanymi z numerem seryjnym modułu radiowego oraz jej DevAddr, format pliku CSV. |
34. | Zamawiający wymaga przeprowadzenia szkolenia w siedzibie Zamawiającego w wymiarze minimum 6 godzin zegarowych z zakresu montażu i eksploatacji wodomierza i modułu radiowego oraz szkolenia w terenie w trakcie praktycznego montażu i konfiguracji 3 urządzeń. Przed szkoleniem wymagane jest dostarczenie dokumentacji technicznej wodomierza i modułu radiowego w języku polskim. Dopuszcza się dokumentację przesłaną w wersji elektronicznej, bądź papierowej lub przy użyciu innego nośnika pamięci. |
35. | Każdy z wodomierzy musi zostać oznakowany wodoodporną, trudno usuwalną, kolorową naklejką o wymiarach właściwych dla umieszczenia na urządzeniu oraz zgodnie z wytycznymi dotyczącymi współfinansowania ze środków UE4. |
LP | Minimalne parametry techniczne zestawu inkasenckiego (urządzenia do sczytywania) |
WSKAZANIA ZDALNE | |
1. | Zestaw inkasencki do zdalnego odczytu zużycia wody musi być w pełni kompatybilny i prawidłowo współpracować z licznikami opisanymi w tabeli powyżej. |
2. | Wymagana klasa szczelności modułu: IP68 |
3. | Zasilanie modułu: bateria umożliwiająca ponowne ładowanie o żywotności powyżej 10 lat |
4. | Funkcje modułu radiowego: ❖ Podanie aktualnego wskazania wodomierza w momencie odczytu, ❖ Podanie informacji o alarmach, w tym min. o: ▪ użyciu magnesu neodymowego, ▪ demontażu modułu radiowego, ▪ przecieku z podaniem liczby dni w miesiącu, ▪ stanie baterii, ▪ przepływie wstecznym, ❖ Aktualna data i godzina odczytu (z uwzględnieniem czasu letniego i zimowego oraz lat przestępnych), ❖ Podanie informacji o przepływach wstecznych, ❖ Rejestr wskazań licznika z poprzednich 24 miesięcy (wskazanie, przepływ wsteczny) ❖ Historia alarmów z 24 miesięcy |
5. | Funkcje programowalne modułu: ❖ Aktualna data i godzina, ❖ Aktualne wskazanie wodomierza, ❖ W przypadku transmisji jednokierunkowej (oraz dwukierunkowej): interwał czasowy pomiędzy kolejnymi transmisjami radiowymi, programowalne miesiące, dni, godziny w których moduł radiowy dokonuje transmisji danych, ❖ Próg alarmu przepływu wstecznego, ❖ Próg alarmu wycieku. |
URZĄDZENIA DO ODCZYTU I KONFIGURACJI MODUŁÓW RADIOWYCH: | |
6. | Odbiornik radiowy zintegrowany na stałe z urządzeniem odczytującym lub komunikujący się za pośrednictwem łącza Bluetooth. |
7. | Możliwość podłączenia do odbiornika radiowego dodatkowej anteny samochodowej w celu polepszenia odbioru sygnału i możliwości realizacji odczytów w układzie drive by. |
8. | Urządzenie do odczytu z systemem Android 11 lub wyższym. |
4xxxxx://xxx.xxxxxxxxxxxxxxxxxxx.xxx.xx/xxxxxx/x-xxxxxxxxxx/xxxxxxxxx/xxxxxxxxxx-xxxxxxxxxxxx-x-xxxxxxxxxxxx-
9. | Optyczna głowica do konfiguracji i odczytu zaprogramowanych parametrów modułu radiowego. |
10. | Jedno oprogramowanie do odczytu i konfiguracji modułów radiowych. Logi wszystkich operacji wykonanych urządzeniem. |
11. | Gwarancja na urządzenie – min. 36 miesięcy – lub dłużej zgodnie ze złożoną ofertą |
12. | Urządzenie musi zostać oznakowane wodoodporną, trudno usuwalną, kolorową naklejką o wymiarach właściwych dla umieszczenia na urządzeniu oraz zgodnie z wytycznymi dotyczącymi współfinansowania ze środków UE.5 |
OPROGRAMOWANIE: | |
13. | Dostęp do oprogramowania za pomocą portalu WEB |
14. | Oprogramowanie w języku polskim, |
15. | Możliwość importu i eksportu plików w formacie .csv; .xml; .txt |
16. | Możliwość integracji z systemem rozliczeniowo – księgowym ZAMAWIAJĄCEGO w układzie wymiany plików, |
17. | Informacja o odczytanych i nieodczytanych licznikach, |
18. | Możliwość kreowania wzoru eksportu plików, |
19. | Archiwizacja pomiarów z okresu 10 lat |
INTERAKTYWNA MAPA XXXXXXXXX | |
00. | Funkcjonalność zobrazowania przeprowadzanych w terenie odczytów urządzeń rejestrujących zużycie wody, w czasie rzeczywistym. |
21. | Możliwość samodzielnej zmiany położenia punktu na mapie, celem zoptymalizowania zasięgu |
22. | Automatyczne wskazywanie punktów (adresów, nr działek, itp.) nieuwzględnione w istniejących mapach |
23. | Możliwość zapisania współrzędnych położenia modułu radiowego na mapie, w trakcie montażu |
24. | Możliwość wyznaczania najkrótszej, optymalnej trasy dla inkasenta |
25. | Podgląd alarmów oraz stanu wodomierzy w trakcie odczytu |
26. | Pełna kompatybilność z wszystkimi modułami RADIO / LORAWAN |
27. | Możliwość wydruku faktur w terenie z wykorzystaniem danych pozyskanych czasie rzeczywistym |
XXXXXXXX | |
00. | Metoda druku: druk termiczny, głowica liniowa 384 punkty grzejne |
29. | Rozdzielczość: 8 punktów / mm w poziomie i w pionie |
30. | Szerokość druku: 104 mm |
31. | Wyświetlacz LCD |
32. | Drukarka wyświetla następujące informacje: • czas rzeczywisty • status Bluetooth • stan naładowania akumulatora • status gotowości do pracy lub rodzaj błędu • wersje firmware • długość papieru do końca rolki – w metrach |
33. | Średnia prędkość druku: 75 mm/s |
34. | Niezawodność: MTBF 5000 h, MCBF100 mln pkt lub min. 50 km wydruku (25% wypełnienie drukiem) |
35. | Urządzenie musi zostać oznakowane wodoodporną, trudno usuwalną, kolorową naklejką o wymiarach właściwych dla umieszczenia na urządzeniu oraz zgodnie z wytycznymi dotyczącymi współfinansowania ze środków UE6. |
5xxxxx://xxx.xxxxxxxxxxxxxxxxxxx.xxx.xx/xxxxxx/x-xxxxxxxxxx/xxxxxxxxx/xxxxxxxxxx-xxxxxxxxxxxx-x-xxxxxxxxxxxx-
6 J.w.
4.2.2.2 Minimalne wymagania funkcjonalne systemu obsługi wody
Wykonawca ma obowiązek dostarczyć, zainstalować i wdrożyć zintegrowany systemu do zarządzania usługami wodno-ściekowymi wraz z przeszkoleniem pracowników Zamawiającego z obsługi systemu oraz importem baz danych z dotychczasowego systemu na którym pracuje Zamawiający.
Funkcjonalność ogólna Systemu Obsługi Wody (dalej SOW)
1. Oferowany system SZS musi pracować w środowisku 64-bit.
2. Wszystkie moduły oprogramowania SOW muszą być dostosowane do aktualnych przepisów prawa, a w szczególności do:
⮚ Ustawy o ochronie danych osobowych,
⮚ Ustawy o podatku od towarów i usług VAT,
⮚ Ustawy o podatku dochodowym od osób prawnych,
⮚ Ustawy o rachunkowości,
⮚ Ustawy o zbiorowym zaopatrzeniu w wodę i zbiorowym odprowadzeniu ścieków.
3. SOW musi być oparty o relacyjną bazę danych, zapewniającą pełną ochronę danych, archiwizację i wielodostęp.
4. SOW musi być wyposażony w graficzny, czytelny „spolonizowany” interfejs użytkownika.
5. Interfejs powinien zapewnić elastyczne metody wyszukiwania danych, sortowanie tabel
po dowolnym polu bazy danych.
6. System SOW musi umożliwiać użytkownikowi samodzielne tworzenie różnego typu raportów i zestawień, dotyczących np. : sprzedaży usług wodno-ściekowych.
7. System SOW musi umożliwiać eksport wszelkich zestawień, sprawozdań czy raportów do formatów czytanych przez programy Excel i Word oraz do formatu PDF.
8. System SOW musi być oparty o wspólną dla wszystkich modułów, dostępną wszystkim uprawnionym użytkownikom systemu bazę danych słownikowych (np. słowniki: ulic, miejscowości, ujęć, wodomierzy, płatników, banków, pracowników, itp.). Słowniki ulic i miejscowości powinny być zintegrowane z baza TERYT a w szczególnych przypadkach (np. brak nazwy w bazie TERYT) administrator ma mieć możliwość wprowadzenia nazwy.
9. SOW musi zapewnić zarządzanie hasłem użytkownika pozwalając jednocześnie na jednoznaczną jego identyfikację. Przez zarządzanie hasłem rozumie się: definiowanie liczby znaków w haśle, okresu ważności hasła oraz niepowtarzalność hasła.
10. SOW musi przechowywać informacje o użytkowniku dokonującym modyfikacji konkretnego dokumentu, oraz datę i dokładny czas wykonania tej operacji;
11. System musi być wyposażony w kontrolę uprawnień użytkowników do wykonywania określonych funkcji systemu SOW.
12. SOW musi posiadać zabezpieczenia przed skasowaniem danych, które są powiązane z
innymi danymi w systemie.
13. System SOW musi być wyposażony w filtry pozwalające na budowanie i zapisywanie dowolnych kryteriów logicznych selekcji danych umożliwiać zapisywanie wykonanych zestawień w celu ich późniejszego wydruku.
14. SOW musi mieć możliwość dokonywania pełnej kopii zapasowej systemu pozwalającej na całościowe jego odtworzenie wg stanu na dany dzień.
I. System bilingowy, fakturowanie.
1. Możliwość elastycznego stosowania taryf cenowych dla poszczególnych grup użytkowników, rozliczanie abonamentu, ryczałtu, itp.
2. Możliwość masowego generowania faktur,
3. Możliwość druku pojedynczych faktur,
4. Możliwość generowania i wysyłki faktur elektronicznych (w tym ustrukturyzowanych),
5. Możliwość rozliczania średniej za dowolny okres,
6. Szacowanie proporcjonalnego zużycia w przypadku zmiany cen,
7. Rozliczanie wielopoziomowych struktur licznik – podlicznik,
8. Możliwość rozliczania zużycia wody/ścieków po wymianie wodomierza z uwzględnieniem wskazań wodomierza zdjętego i nowego,
9. Możliwość procentowego określenia udziału kontrahenta w liczniku (rozliczenia wielu kontrahentów ze wspólnego wodomierza),
10. Kontrola poprawności wprowadzanego odczytu, z sygnalizacją znacznych odchyłek od średniego zużycia za poprzedni okres,
11. Możliwość własnego definiowania numeracji faktur, możliwość wieloczłonowego sposobu numeracji, możliwość kontynuacji istniejącej numeracji,
12. Sygnalizowanie przez system nie rozliczonych punktów rozliczeniowych,
13. Możliwość dopisania do faktur oprócz standardowych informacji wymaganych przepisami prawa innych informacji wg potrzeb Zamawiającego np. stan rozrachunków, informacje o odsetkach, godziny otwarcia Urzędu, itp.
14. Generowanie faktur korygujących,
15. Możliwość wystawiania duplikatów, i drukowania kopii faktur,
16. Możliwość automatycznego dołączania informacji do faktur o zaległościach i odsetkach, dołączanie not odsetkowych,
17. Konfigurowalna szata graficzna faktury,
18. Możliwość umieszczenia na fakturach zdefiniowanego kodu kreskowego,
19. Automatyczna dekretacja na podstawie wzorców księgowań do programu finansowo- księgowego Symfonia,
20. Możliwość tworzenia zestawień sprzedaży według zadanych kryteriów,
21. Kategorie kontrahentów (podmioty prawne, osoby fizyczne, itp.)
22. Wydruk karty danych osobowych kontrahenta
23. Dopisanie dowolnych uwag do kontrahenta
24. Kategoria posesji - podział wg rodzajów grup zdefiniowanych dowolnie przez użytkownika
(np. domki jednorodzinne, bloki mieszkalne, hotele, zakłady pracy, itp.)
25. Trasy inkasenckie przyporządkowane do posesji, numeracja posesji na trasie
26. Punkt rozliczeniowy - podział wg rodzajów grup zdefiniowanych dowolnie przez użytkownika,
27. Przyporządkowanie numeru wodomierza (fabryczny) do punktu rozliczeniowego,
28. Zdefiniowanie daty obowiązywania i rozliczania punktu rozliczeniowego (punkt rozliczany
okresowo),
29. Pełna kontrola (łącznie z ewidencją) nad zmianami danych kontrahenta, posesji i punktu rozliczeniowego, automatyczna rejestracja identyfikatora osoby dokonującej zmian w danych osobowych wraz z informacją o przyczynie wprowadzenia zmian,
30. Pełna historia zmian danych ewidencyjnych,
31. Zesłownikowanie danych potrzebnych do ewidencji kontrahentów, posesji i punktów rozliczeniowych takich jak: algorytmy rozliczania kontrahenta, ulice, banki, stawki VAT, trasy, itp.
32. Filtrowanie i wyszukiwanie kontrahentów, posesji i punktów rozliczeniowych wg dowolnych informacji zawartych w systemie,
33. Możliwość integracji punktów rozliczeniowych/posesji z mapą cyfrową,
34. Definiowanie własnych szablonów umów, szablonów aneksów umów,
35. Powiązanie umów zarówno z odbiorcami jak i posesjami,
36. Możliwość tworzenia załączników do umów, w tym dołączania skanów dokumentów,
37. Pełna modyfikacja treści umów dostępna z poziomu użytkownika.
II. Windykacja
1. Definiowalna procedura windykacyjna,
2. Generowanie wezwań do zapłaty (w tym zgodnie z zasadami doręczeń elektronicznych),
3. Generowanie not odsetkowych (w tym zgodnie z zasadami doręczeń elektronicznych),
4. Możliwość ustalania treści pism windykacyjnych,
5. Uwzględnianie systemu ratalnego płatności,
6. Odnotowywania w programie na jakim etapie jest windykacja.
Windykacja sądowa
7. Wezwania numerowane + ZPO (w tym zgodnie z zasadami doręczeń elektronicznych)
8. Wniosek do prawnika o skierowanie sprawy do sądu (wydruk z programu) – z możliwością przesłania drogą elektroniczną
9. Możliwość utworzenia po zaksięgowaniu WB zestawienia Odbiorców, dla których złożony jest wniosek do Mecenasa o złożenie pozwu do sądu aby móc stwierdzić czy jest konieczność aktualizowania złożonego wniosku
10. Aktualizacja złożonego wniosku do mecenasa w sytuacji częściowej bądź całkowitej spłaty zadłużenia (wydruk z programu)
11. Informacje o przesłanych na wniosek Mecenasa opłat na rzecz Sądu
12. Sądowy Nakaz zapłaty
13. Koszty procesu
14. Postanowienie o nadaniu klauzuli
15. Skierowanie wniosku do Komornika (wydruk z programu)
16. Informacje o przesłanych na wniosek Mecenasa opłat na rzecz Komornika
17. Informacje od Komornika np. o umorzeniu postępowania i naliczeniu kosztów
egzekucyjnych
18. Informacje o zbiegu egzekucji
Odcięcia przyłączy
1. Kwalifikowanie przez program odbiorców do odcięcia na podstawie ustawy o zbiorowym zaopatrzeniu w wodę
2. Wydruk pisma z informacją o odcięciu przyłączy
3. Informacja o ZPO
4. Informacja czy odcięcie doszło do skutku
5. Informacje o składanych wnioskach np. podanie o rozłożenie płatności na raty, o umorzenie.
III. Gospodarka wodomierzowa
1. Kartoteka wodomierzy zawierająca min.: typ wodomierza z dostępem do parametrów technicznych producenta, numer fabryczny, datę produkcji, datę przyjęcia i zdjęcia z ewidencji, datę legalizacji,
2. Zesłownikowanie typów wodomierzy,
3. Zdefiniowanie statusu wodomierza: (w magazynie, u odbiorcy, w naprawie, wysłany do
ekspertyzy, itp.),
4. Informacja o miejscu instalacji wodomierza,
5. Ewidencja historii lokalizacji wodomierzy,
6. Ewidencja gospodarki wodomierzami - kontrola ruchu wodomierzy, data przyjęcia i zdjęcia
z ewidencji,
7. Kontrola, planowanie i wyznaczanie punktów rozliczeniowych do wymiany wodomierzy z możliwości wydruku odpowiednich zestawień,
8. Ewidencja historii odczytów wodomierza,
9. Możliwość szukania po wszystkich polach bazy danych.
IV. Odczyty wodomierzy, zestaw inkasencki.
1. Zestaw inkasencki (w skład wchodzi urządzenie z ekranem pojemnościowym, z zainstalowanym programem inkasenckim). Program musi współpracować z urządzeniami wchodzącymi w skład zestawu inkasenckiego.
Aplikacja zainstalowana na urządzeniu mobilnym musi umożliwiać bezpośrednie wysyłanie odczytów, dokumentów wystawionych przez inkasenta, na serwer Urzędu Gminy za pomocą sieci bezprzewodowej WiFi lub sieci telefonii komórkowej.
Samo urządzenie musi wykorzystywać technologie ekranu pojemnościowego.
2. Możliwość pracy inkasenta za pomocą tego samego urządzenia inkasenckiego zarówno w tradycyjny sposób odczytywania wodomierzy jak i w radiowy sposób odczytu,
3. Współpraca z systemami zdalnego odczytu wiodących producentów wodomierzy wraz z tworzeniem rozliczeń dla poszczególnych gałęzi wodociągowych, wykazywanie strat w sieci, monitoring nielegalnych poborów wody itp.
4. Dokonywanie odczytów według tzw. tras inkasenckich, możliwość sortowania tras wg typu inkasenta, możliwość wyszukiwania ręcznego adresów, nazwisk.
5. Możliwość odczytu pojedynczego modułu radiowego jak i automatyczny odczyt dla
wybranej trasy,
6. Kontrola pracy inkasenta,
7. Wyszukiwanie danych wg zadanych kryteriów: np. kontrahenci, posesje, wodomierze,
8. System zabezpieczeń przed utratą danych w przypadku awarii zestawu inkasenckiego,
9. Wprowadzanie przez inkasenta dowolnej notatki tekstowej dotyczącej kontrahenta,
posesji, punktu rozliczeniowego,
10. Rozliczanie punktu poboru wg wskazania licznika, średniej, ryczałtu,
11. Historia odczytu radiowego.
12. Wizualizacja punktów odbioru usług i tras np. spisywania liczników na mapach GIS.
V. e-BOK (element Portalu Systemu) – wymagania minimalne
1. Możliwość wglądu odbiorcy poprzez sieć internetową (po zalogowaniu) do:
⮚ aktualnych stanów wodomierzy,
⮚ informacji o rozliczeniach,
⮚ stanu zobowiązań,
⮚ umów i innych dokumentów.
2. Możliwość podania przez zalogowanego odbiorcę stanu wodomierza;
3. Możliwość wygenerowania przez zalogowanego odbiorcę faktury (po wprowadzeniu odczytu wodomierza dodatkowego służącego rejestracji wody bezpowrotnie zużytej (ogrodowej) powinien mieć możliwość wystawienia faktury lub zlecenia jej wystawienia przez operatora w Gminie).
VI. System Powiadomień Masowych
1. Baza danych umiejscowiona na serwerze wewnętrznym Urzędu Gminy;
2. Powiadomienia sms i/lub e-mail mogą być wysyłane na dwa sposoby:
⮚ poprzez skonfigurowaną wcześniej bramkę internetową za pośrednictwem lokalnego modemu GSM (od najprostszych modemów USB po rozwiązania przemysłowe) połączonego z jednostką centralną, z zainstalowaną kartą sim wybranego operatora;
⮚ możliwość wykorzystania aplikacji mobilnej do wysyłania powiadomień w tym za
pośrednictwem bramek sms zewnętrznych dostawców.
3. System ma za zadanie:
⮚ wspierać proces windykacji,
⮚ powiadamiać o odczytach, wywozach i innych usługach komunalnych,
⮚ wysyłać komunikaty ostrzegawcze, o zagrożeniach, awariach.
VII. Dodatkowe wymagania
1. Wymagana jest obsługa płatności masowych (możliwość przypisania indywidualnego nr
konta bankowego)
2. Wymagane jest prowadzenie kasy oraz rozrachunków z pozycji systemu.
3. Widok/prezentacja dot. liczby umów ogółem
4. Wydruk dot. liczby umów na samą kanalizację oraz na samą wodę
5. Wydruk o liczbie umów (wodomierzy) na danej ulicy (trasie)
6. Wydruk dot. liczby podpisanych umów z firmami oraz osobami fizycznymi
7. Wydruk o liczbie wodomierzy głównych oraz osobny do uzyskania informacji o ilości podliczników
8. Wydruk dot. liczby wystawionych faktur przez inkasenta
9. Opcja wysyłania SMS z informacjami do mieszkańców
10. Tworzenie opcjonalnych wydruków: wezwania, wszczęcia
11. Tworzenie umów na wodę i ścieki
12. Możliwość tworzenia książek nadawczych
13. Możliwość tworzenia naklejek na zwrotki i generowania w trybie doręczenia
elektronicznego
14. Kompatybilność programu z urządzeniami do wydruku zwrotek (drukarki zwrotek)
15. Pełna kompatybilność programu z licznikami zdalnymi
16. Tworzenie zestawień odczytów i faktur z podziałem na inkasenta oraz pracowników
17. Tworzenie zestawień/raportów do GUS i urzędów administracji państwowej zgodnie z
obowiązującymi przepisami.
4.2.2.3 Opis e-usług, procesów i podprocesów wymaganych do obsługi
dostaw wody
W ramach realizacji Zamówienia Wykonawca będzie miała obowiązek uruchomić system obsługi dostarczania wody obejmujący świadczenie poniżej opisanych e-usług oraz podprocesów obejmujących pełen zakres dostaw wody oraz odbioru ścieków. Klient ma mieć możliwość pobrania, wypełnienia i złożenia drogą elektroniczną opisanych poniżej formularzy dotyczących opisanych poniżej usług i funkcjonalności. System musi umożliwiać dostarczenie informacji związanych ze świadczonymi usługami na konto utworzone w systemie obsługi wody jak również na konto ePUAP oraz możliwość doręczeń elektronicznych w zależności od zgód wyrażonych przez użytkownika systemu.
1. e-przyłącze – przyłączenie do sieci wodociągowej i kanalizacyjnej w gminie Elektroniczny wniosek (5).
1.1. Usługa inicjowana przez użytkownika (klient) Portalu (dalej również e-BOK). Klient (strefa nielogowana i strefa klienta) ma możliwość pobrania, wypełnienia i złożenia formularzy wniosków np. o zawarcie umowy, o wypowiedzenie umowy, o rozłożenie zadłużenia na raty, o zwrot nadpłaty na konto, itp.
1.2. Personalizacja e-Usług (5 poziom dojrzałości) poprzez: automatyczne dostarczanie konkretnemu klientowi spersonalizowanych dla niego eusług i przez niego nie inicjowanych, w tym: oferowanie częściowo wypełnionych formularzy, inicjowanie potrzeby wykonania czynności, poinformowanie Klienta o zbliżającej się potrzebie wykonania danej czynności, ePłatności - np. od Pełnomocnictwa, wynikające z przepisów prawa, system umożliwi też zarządzanie odpowiedziami.
1.3. Opis działania. Usługa jest dostępna w strefie nielogowanej – anonimowej i strefie klienta (zalogowany użytkownik). Użytkownik ma możliwość wybrania, pobrania, wypełnienia i złożenia szeregu formularzy jak np.:
a) Wniosek o zawarcie umowy,
b) Wniosek o wypowiedzenie umowy,
c) Wniosek o rozłożenie zadłużenia na raty,
d) Wniosek o zwrot nadpłaty na konto,
e) itp.
1.4. Mechanizm obsługi funkcjonalności usługi musi pozwalać na dodawanie przez uprawnionego użytkownika (w strefie administratora) dowolnej liczby formularzy/wniosków lub innych dokumentów będących w bieżącym obiegu klientów w związku z usługami świadczonymi klientom Urzędu.
1.5. Obsługiwane typy plików dla dostępnych w usłudze formularze, – co najmniej pdf, doc, docx, xps, odt, jpeg, gif.
2. E-zgłoszenie w zakresie awarii sieci wod-kan. (5).
2.1. Usługa inicjowana przez użytkownika portalu (klient). Klient w strefie logowanej ma możliwość zgłoszenia nieprawidłowości związanych z dostawą wody lub odprowadzaniem ścieków. Użytkownik (mieszkaniec) ma dostęp online do interaktywnego formularza poprzez wskazanie na mapie miejsca/obszaru, dla którego wystąpiła lub występuje czasowo nieprawidłowość w dostawie wody, odbiorze ścieków, możliwym nieprawidłowym działaniu sieci wodociągowo- kanalizacyjnej, urządzenia pomiarowego, kradzieży wody itp.
2.2. Personalizacja eUsług (5 poziom dojrzałości) poprzez: automatyczne dostarczanie konkretnemu klientowi spersonalizowanych dla niego eusług i przez niego nie inicjowanych, w tym: oferowanie częściowo wypełnionych formularzy, inicjowanie potrzeby wykonania czynności, poinformowanie Klienta o zbliżającej się potrzebie wykonania danej czynności, ePłatności - np. od Pełnomocnictwa, wynikające z przepisów prawa, system umożliwi też zarządzanie odpowiedziami.
2.3. Opis działania. Usługa jest dostępna w strefie logowanej –strefie klienta (zalogowany użytkownik). Użytkownik e-usługi ma możliwość przekazania informacji, że we wskazanym przez niego miejscu/obszarze na mapie występują nieprawidłowości w realizowaniu usługi przez Dostawcę lub inne zdarzenia, o których Użytkownik chce poinformować Urząd (słownik zgłoszeń, lub dowolny opis zgłoszenia). E-usługa na podstawie zebranych danych przez interaktywny formularz i adresowi zwrotnemu email zwraca informacje o zarejestrowaniu zgłoszenia i kolejnych podejmowanych przez Gminę działaniach. Użytkownik może wydrukować formularz mapy lub utworzyć plik z mapą. Klient wprowadza informację, którą system przyjmuje i dysponuje dalsze czynności. Przyjęcie do systemu zgłoszenia w zakresie nieprawidłowości dostarczania usług (dostarczenie wody, odprowadzania ścieków, możliwym nieprawidłowym działaniu sieci wodociągowo-kanalizacyjnej, urządzenia pomiarowego, kradzieży wody). Zgłoszenia klasyfikowane mogą być, jako awarie lub planowana obsługa techniczna klienta. Z poziomu systemu e-BOK użytkownik będzie miał dostęp do wykazu wszystkich swoich posesji oraz wodomierzy.
2.4. Funkcjonalność dodatkowa:
a) Wydruk zarejestrowanego wniosku.
3. E-rozliczenia za usługę dostarczania wody (E-woda).
3.1. Usługa inicjowana przez użytkownika Portalu (klient). Klient (strefa logowana klienta) ma możliwość sprawdzenia aktualnej należności za: wodę i/lub ścieki. Poza sprawdzeniem należności będzie można dokonywać elektronicznych płatności (wybierając opcję "zapłać" będzie następowało przekierowanie do strony bankowości
internetowej, w której po zalogowaniu się na swoje konto bankowe, użytkownik będzie posiadał wypełnione automatycznie dane do przelewu).
3.2. Dostępna w strefie klienta (zalogowany użytkownik). Wywołanie usługi wyświetla podstawową informację, jaką jest kwota bieżącej należności za wodę i/lub ścieki (pozycje wnikają z dostępnych dla klienta usług).
3.3. Klient może poprzez zaznaczenie należności za wodę i/lub ścieki może dokonać ich zapłaty. Za każdym razem, jak klient zaznacza pozycję do zapłaty (rodzaj usługi) na ekranie w wyróżnionym polu wyświetlana jest sumaryczna kwota do zapłaty.
3.4. Przy każdej z pozycji jest ikona, której wybranie umożliwia uruchomienie e- usługi
e- płatność, dzięki której klient może przeanalizować swoje należności.
3.5. O zrealizowaniu zapłaty poprzez e-płatność Klient zostanie poinformowany e- mailem lub SMS.
3.6. Ekran usługi powinien umożliwić wywołanie skojarzonych e-usług:
a) Historia płatności
b) E-monit
3.7. Funkcjonalność dodatkowa:
a) Eksport danych do pliku csv, xls/ods lub pdf.
Jednocześnie w ramach przedmiotowego Zamówienia mają zostać wdrożone podprocesy umożliwiające korzystanie z nich przez wszystkich klientów, którzy odbierają wodę i/lub odprowadzają ścieki w Gminie Michałowice. Dodatkowe podprocesy, które mają zostać uruchomione to:
4. Moje dane.
4.1. Podproces inicjowany przez użytkownika Portalu (klient). Klient po zalogowaniu do e- BOK (strefa klienta) ma możliwość przeglądania swoich danych osobowo- adresowych oraz e-mail, ePuap, adres do doręczeń elektronicznych, nr telefonów kontaktowych, w oparciu, o które są mu wysyłane dokumenty i powiadomienia. Ma możliwość przesłania formularza ze zmianą danych osobowo-adresowych.
4.2. Opis działania. Usługa jest dostępna w strefie klienta (zalogowany użytkownik). Klient ma możliwość podglądu swoich danych osobowo-adresowych oraz e-mail, nr telefonów kontaktowych. Klient ma możliwość wysłania formularza zmian danych osobowo-adresowych oraz dołączenia innych załączników do formularza np. potwierdzających zasadność zmiany danych.
4.3. Funkcjonalność dodatkowa:
a) Zapis/wydruk wniosku/formularza zmian danych osobowo-adresowych w formacie pdf.
5. Moje umowy.
5.1. Podproces inicjowany przez użytkownika e-BOK (klient). Klient po zalogowaniu do e- BOK (strefa klienta) ma możliwość przeglądania swoich danych w zakresie zawartych umów w tym aneksów na świadczenie usług przez Zakład w szczególności, na jakie okresy są zawarte i jakie usługi.
5.2. Opis działania. Usługa jest dostępna w strefie klienta (zalogowany użytkownik). Klient ma możliwość podglądu swoich danych w zakresie zawartych umów na świadczenie
usług przez Urząd w szczególności, na jakie okresy są zawarte i jakie usługi. W ramach
parametrów opisujących dane o umowie powinny znaleźć się takie jak:
a) Umowa/Aneks aktywny,
b) Umowa/Aneks zweryfikowany,
c) Propozycja umowy/aneksu,
d) Umowa/Aneks wysłany do klienta/oczekiwanie na zwrot/podpis,
e) Umowa/Aneks zakończony,
f) Umowa/Aneks zarchiwizowany.
5.3. Ekran usługi Moje umowy powinien umożliwić wywołanie skojarzonych e- usług:
a) Moje dane,
b) Moje płatności,
c) Moje zużycia.
5.4. Funkcjonalność dodatkowa:
a) Wydruk kopii dokumentów umów,
b) Eksport dokumentów do pliku pdf.
c) Eksport zestawienia umów do pliku csv, xls/ods lub pdf.
6. Moje zużycia.
6.1. Podproces inicjowany przez użytkownika e-BOK (klient). Klient po zalogowaniu do e- BOK (strefa klienta) ma możliwość przeglądania wszystkich obsługiwanych przez Urząd liczników (punktów rozliczeniowych liczników płatnika). Dla każdego z nich może przeglądać historię zużyć, zarejestrowanych odczytów. Dodatkowo dla każdego z odczytów, jeśli zostały one zafakturowane Klient może wyświetlić zawierającą je fakturę.
6.2. Opis działania. Klient po zalogowaniu do e-BOK (strefa klienta) dostaje możliwość przeglądania rejestru swoich punktów rozliczeniowych – tzn., dla których jest płatnikiem. Rejestr powinien zawierać, co mniej następujące informacje pozwalające na jednoznaczne określenie Płatnika/licznika:
a) Numer ewidencyjny Płatnika,
b) Adres licznika Płatnika (wodomierza -punktu rozliczanego),
c) Lokalizacja (szczegółowe umiejscowienie wodomierza/podwodomierza),
d) Numer fabryczny wodomierza
e) Status – (rozliczany/nierozliczany/zawieszony, itp.)
6.3. Dla każdej pozycji rejestru, jeśli istnieje choćby jedno zdarzenie – odczyt dla zainstalowanego w wybranej lokalizacji wodomierza wyświetlany powinien być znacznik pozwalający po jego kliknięciu na wyświetlenie historii zużyć zarejestrowanych przez wodomierz. Jeśli wybrana lokalizacja nie ma zainstalowanego wodomierza, ale posiada wystawione faktury (rozliczane ilości umowne) to funkcjonalność tej e-usługi powinna wyświetlić je bezpośrednio po kliknięciu odpowiedniego znacznika (inny niż dla odczytów, aktywny tylko dla tej sytuacji).
6.4. Dla lokalizacji z wodomierzem lista odczytów powinna zawierać, co najmniej następujące dane:
a) Numer fabryczny wodomierza,
b) Data odczytu,
c) Wskazanie,
d) Zużycie (pomiędzy odczytami),
e) Zużycie dobowe (pomiędzy odczytami),
f) Uwaga do odczytu (np. opis usterki, uwagi pracownika).
g) Sposób pozyskania odczytu (zdalnie, pracownik, klient),
6.5. Jeśli odczyt zawarty w liście odczytów jest rozliczony – tzn. zawiera się w jakiejkolwiek fakturze to kliknięcie klienta na ten wiersz powinno wyświetlić, co najmniej podstawowe informacje o zawierającej je fakturze takie jak:
a) Numer faktury,
b) Data wystawienia faktury,
c) Miesiąc sprzedaży,
d) Data płatności.
e) Kwota należności (brutto),
f) Kwota długu (lub status zapłacona/niezapłacona).
6.6. Ekran usługi Moje zużycia powinien umożliwić wywołanie skojarzonych e-usług:
a) E-odczyt,
b) Wniosek o wymianę/plombowanie licznika/podurządzenia pomiarowego,
6.7. Funkcjonalność dodatkowa:
a) Prezentacja graficzna bieżącego zużycia dla wodomierzy na wykresie
kolumnowym,
b) Prezentacja graficzna średniej dobowej wartości zużycia dla wodomierzy
na wykresie kolumnowym.
c) Eksport danych do pliku csv, xls/ods lub pdf.
7. E-publikacja Warunków pracy Urzędu w zakresie dostarczania wody i możliwości przyłączenia.
7.1. Podproces dostępny w strefie nielogowanej i strefa klienta. Usługa ma zapewnić klientom dostęp do różnych informacji na temat bieżącego funkcjonowania Urzędu. W tym będzie miał możliwość uzyskania informacji prawnych: wyciągi uchwał, taryfy; bieżących informacji dla klientów, jak też do listy zastępczych punktów dostawy wody. Dodatkowo w strefie logowanej klient będzie mógł zadać pytanie dotyczące interesującego go obszaru, za pośrednictwem wyszukiwarki, w wyniku, czego uzyska odpowiedź systemu w formie gotowych do pobrania materiałów.
7.2. Mechanizm obsługi funkcjonalności usługi musi pozwalać na dodawanie przez uprawnionego użytkownika (w strefie administratora) dowolnej ilości informacji na temat bieżącego funkcjonowania Urzędu lub innych dokumentów będących w bieżącym obiegu klientów w związku z usługami świadczonymi klientom Urzędu (informacji prawnych: wyciągi uchwał, taryfy; listy zastępczych punktów dostawy wody).
8. E-informator - e-komunikator (5).
8.1. Podproces inicjowany przez użytkownika e-BOK (klient) lub pracownika Urzędu
(operator). Klient po zalogowania do e-BOK (strefa klienta), a operator po zalogowani
się, jako pracownik ma możliwość wyboru automatycznego przesyłania informacji sieciowych np. o czasowym braku dostaw wody lub zagrożeniach (np. woda niezdatna do picia) oraz sposobu jej realizacji: SMS-em lub mailem.
8.2. Opis działania. Usługa jest dostępna w strefie klienta (zalogowany użytkownik). Klient ma do dyspozycji mechanizm pozwalający na zdefiniowanie metody i sposobu przesyłania przez Urząd informacji sieciowych np. o czasowym braku dostaw wody lub zagrożeniach (np. woda niezdatna do picia, itp.).
8.3. Personalizacja eUsług (5 poziom dojrzałości) poprzez: automatyczne dostarczanie konkretnemu klientowi spersonalizowanych dla niego eusług i przez niego nie inicjowanych, w tym: oferowanie częściowo wypełnionych formularzy, inicjowanie potrzeby wykonania czynności, poinformowanie Klienta o zbliżającej się potrzebie wykonania danej czynności, ePłatności - np. od Pełnomocnictwa, wynikające z przepisów prawa, system umożliwi też zarządzanie odpowiedziami.
8.4. Usługa pozwala na zdefiniowanie (na osobnym ekranie/okienku) następujących
metod przesyłania informacji:
a) Włączenia/wyłączenia usługi SMS,
b) Włączenia/wyłączenia usługi e-mail,
8.5. Usługa pozwala na zdefiniowanie następujących sposobów dostarczania informacji:
a) Zakresu godzinowego w ciągu dnia, kiedy usługi SMS mogą być realizowane,
b) Listy dni tygodnia, w których usługa SMS może być realizowana,
c) Adresu mailowego, na który system będzie wysyłał informacje, (możliwy inny niż e-mail dla monitów),
d) Nr telefonu komórkowego lub stacjonarnego, (jeśli ma możliwość odbioru sms),
- możliwy inny niż dla monitów.
8.6. Funkcjonalność dodatkowa:
a) Zapis/wydruk ustawień w formacie pdf.
8.7. Inne funkcje Informatora. Informator - eInformator będzie realizował szereg funkcjonalności w powiązaniu z innymi elementami systemu.
a) powiadamianie e-mail.
b) informator SMS.
8.8. Elementem informatora będzie też Profil w którym każdy Klient będzie mógł wskazać jakiego rodzaju informacje go interesują i jakim kanałem komunikacji mają być przekazane. Użytkownicy będą mieli możliwość zmiany ustawień jak i wycofania zgody na otrzymywanie powiadomień.
8.9. Informator będzie miał też możliwość wysłania powiadomienia według kryterium
wybranego przez Administratora, np. powiadomienie o zaległościach, Alerty.
a) Xxxxxxxxxxxxx e-mail:
- funkcjonalność pozwalająca na wysyłanie komunikatów e-mail.
b) Informator SMS.
- wysyłka masowa,
- wgląd w historię powiadomień,
- ustalanie daty wysyłki,
- wysyłanie SMS do Grup:
- grupy stałe strategiczne (np. Radni, Osoby pełniące ważne stanowiska – VIP,
Sołtysi, Komendanci, zastępcy OSP,)
- grupy stałe INNE,
- grupy dynamiczne, np. mieszkańcy danej miejscowości, zdefiniowani w systemie,
turyści.
- wysyłanie SMS według preferencji zdefiniowanych w profilu.
c) Poziomy wiadomości:
- Informacja,
- Ostrzeżenie,
- Alarm,
9. E-powiadomienia Faktura.
9.1. Podproces inicjowany przez użytkownika e-portalu (klient) lub pracownika Urzędu (operator). Klient po zalogowania do e-portalu (strefa klienta), a operator po zalogowani się, jako pracownik Urzędu (strefa administratora) ma możliwość wyboru usługi informowania o fakcie wystawienia e-faktury przez system dziedzinowy mailem. Operator ma możliwość wskazania odbiorców.
9.2. Opis działania. Usługa jest dostępna w strefie klienta (zalogowany użytkownik). Klient ma do dyspozycji mechanizm pozwalający na zdefiniowanie sposobu informowania o fakcie wystawienia e-faktury i gotowości do jej pobrania: SMS-em lub e-mailem.
9.3. Usługa pozwala na zdefiniowanie:
a) Włączenia/wyłączenia usługi SMS,
b) Włączenia/wyłączenia usługi e-mail,
c) Zakresu godzinowego w ciągu dnia, kiedy dla usługi SMS będzie wysyłany
komunikat,
d) Głównego i dodatkowego adresu mailowego, na który system będzie wysyłał powiadomienie, (możliwy inny niż e-mail dla e-faktur),
e) Głównego i dodatkowego nr telefonu komórkowego i stacjonarnego, (jeśli
ma możliwość odbioru sms),
f) Maksymalną liczbę powtórzeń wysłanych komunikatów (dla całego okresu
przypominania)
9.4. Funkcjonalność dodatkowa:
a) Zapis/wydruk ustawień w formacie pdf.
10. E-odczyt w tym:
a) Wprowadzenie za pośrednictwem portalu stanu urządzenia pomiarowego.
b) Udostępnienie wartości odczytu przez Internet.
10.1. Podproces rejestrowania stanów urządzenia pomiarowego (urządzeń pomiarowych), prezentacji aktualnych odczytów stanu urządzenia pomiarowego oraz zlecania dodatkowych usług. Użytkownik (klient Urzędu) ma dostęp online do interaktywnego formularza zgłoszenia stanu urządzenia pomiarowego poprzez wyszukanie lub wskazanie na mapie swojej lokalizacji, Może również zlecić wystawienie faktury uwzględniającej podany stan urządzenia pomiarowego
10.2. Personalizacja eUsług ( 5 poziom dojrzałości ) poprzez: automatyczne dostarczanie konkretnemu klientowi spersonalizowanych dla niego eusług i przez niego nie inicjowanych, w tym: oferowanie częściowo wypełnionych formularzy, inicjowanie potrzeby wykonania czynności, poinformowanie Klienta o zbliżającej się potrzebie wykonania danej czynności, ePłatności - np. od Pełnomocnictwa, wynikające z przepisów prawa, system umożliwi też zarządzanie odpowiedziami.
10.3. Opis działania. Użytkownik (klient) dokonuje odczytu swojego urządzenia pomiarowego a następnie za pomocą interaktywnego formularza przekazuje go wraz z lokalizacją i adresem zwrotnym e-mail do Urzędu. Jeśli użytkownik zostanie pomyślnie zweryfikowany, jako klient zostanie mu dostarczona spersonalizowana lista dostępnych dla niego dodatkowych usług. E-usługa zwraca zweryfikowanemu Użytkownikowi informację o zarejestrowaniu odczytu urządzenia pomiarowego. Użytkownik może również zlecić np. wystawienie faktury uwzględniającej podany stan urządzenia pomiarowego i przesłanie jej na zwrotny adres e-mail lub doręczenie elektroniczne na skrzynkę ePUAP, (jeśli dodatkowym formularzem wyrazi jednorazową lub stałą zgodę na wystawienie faktury elektronicznej). Użytkownik zostanie powiadomiony sms’em o wystawieniu faktury lub zaakceptowaniu odczytu. Procesowanie informacji uzyskanych drogą radiową od klienta. System wysyła sygnał do urządzeń zamontowanych u odbiorców mediów, w ten sposób dokonuje się zdalny odczyt urządzeń rejestrujących przepływ wody. Na tej podstawie system generuje informację o zużyciu, przesyłając odczyt w elektronicznej formie do klienta.
10.4. Ekran e-formularz powinien umożliwić wywołanie skojarzonych e-usług:
a) Wniosek o wymianę /plombowanie licznika/ podurządzenia pomiarowego,
b) Wniosek o montaż urządzenia pomiarowego /podurządzenia pomiarowego,
c) Elektroniczny wniosek e-BOK,
10.5. Funkcjonalność dodatkowa:
a) Zapis wniosku do pliku pdf.
b) Wydruk wniosku.
11. E-wniosek o montaż urządzenia pomiarowego /podurządzenia pomiarowego (5).
11.1. Podproces inicjowany przez użytkownika e-BOK (klient). Klient po zalogowaniu do e- BOK (strefa klienta) ma możliwość przygotowania i przekazania wniosku o montaż urządzenia pomiarowego (wodomierza)/podurządzenia pomiarowego (wodomierza). Po zatwierdzeniu wniosku zgłoszenie jest przekazywane do właściwego systemu dziedzinowego. Klient ma informację zwrotną, dostępną na stronie, ale również jest powiadamiany mailowo (oraz/lub na ePUAP, doręczenia elektorniczne), o terminie realizacji wniosku i jego statusie.
11.2. Personalizacja eUsług ( 5 poziom dojrzałości ) poprzez: automatyczne dostarczanie konkretnemu klientowi spersonalizowanych dla niego eusług i przez niego nie inicjowanych, w tym: oferowanie częściowo wypełnionych formularzy, inicjowanie potrzeby wykonania czynności, poinformowanie Klienta o zbliżającej się potrzebie wykonania danej czynności, ePłatności - np. od Pełnomocnictwa, wynikające z przepisów prawa, system umożliwi też zarządzanie odpowiedziami.
11.3. Opis działania. Usługa jest dostępna w strefie klienta (zalogowany użytkownik). Użytkownik ma możliwość zgłoszenia Wniosku o montaż urządzenia pomiarowego/podurządzenia pomiarowego.
11.4. Klient po wywołaniu tej usługi otrzymuje ekran z listą punktów rozliczeniowych, podstawowymi danymi o nich. Są nimi, co najmniej:
a) Numer ewidencyjny,
b) Adres punktu,
c) Numer umowy.
11.5. Klient po wybraniu punktu rozliczeniowego i naciśnięciu przycisku „Przygotuj Wniosek” otrzymuje do wypełnienia – uszczegółowienia formularz wniosku, w którym może umieścić ewentualne komentarze, opisy, informacje istotne z punktu widzenia zgłoszonego wniosku i jego późniejszej realizacji. Dodatkowo do formularza użytkownik może załączyć pliki graficzne – co najmniej w formacie pdf, doc, docx, jpeg, gif, które mogą pozwolić pracownikom Urzędu na lepszą ocenę sytuacji i podjęcie właściwych decyzji w związku z zgłoszeniem.
11.6. Formularz wniosku musi zawierać:
a) Możliwość wprowadzenia proponowanego przez Klienta terminu realizacji montaży wodomierza.
b) Dane kontaktowe, jeśli są inne niż podstawowe dane klienta.
11.7. Wyświetla informacje o statusie jego aktywnych wniosków o montaż wodomierza (tylko niezałatwionych).
11.8. Po poprawnym zweryfikowaniu danych w formularzu wniosku przez e-usługę, po naciśnięciu przycisku „Wyślij” następuje wysłanie wniosku do systemu dziedzinowego. Po weryfikacji i przyjęciu wniosku do realizacji przez pracownika Urzędu, klient otrzyma SMS lub e-mail z informacją o statusie zgłoszenia.
11.9. Ekran e-usługi „Wniosek o montaż urządzenia pomiarowego/podurządzenia pomiarowego” powinien umożliwić wywołanie skojarzonych e-usług:
a) Wniosek o wymianę/plombowanie licznika/podurządzenia pomiarowego,
b) E-zgłoszenie.
11.10. Funkcjonalność dodatkowa:
a) Zapis wniosku do pliku pdf lub xps.
b) Wydruk wniosku.
12. E-wniosek o wymianę /plombowanie licznika/ podurządzenia pomiarowego (5).
12.1. Podproces inicjowany przez użytkownika e-BOK (klient). Klient po zalogowaniu do e-
BOK (strefa klienta) ma możliwość przygotowania i przekazania wniosku
o wymianę/plombowanie licznika (wodomierza). Klient ma możliwość wskazania z listy posiadanych liczników(wodomierzy) te wodomierze, które zgłasza do wymiany/plombowania. Wprowadza również ewentualne komentarze, opisy, informacje istotne z punktu widzenia zgłoszenia i jego późniejszej realizacji. Po zatwierdzeniu wniosku zgłoszenie jest przekazywane do właściwego systemu dziedzinowego. Klient ma informację zwrotną, dostępną na stronie, ale również jest powiadamiany mailowo, o terminie realizacji wniosku i jego statusie.
12.2. Personalizacja eUsług ( 5 poziom dojrzałości ) poprzez: automatyczne dostarczanie konkretnemu klientowi spersonalizowanych dla niego eusług i przez niego nie inicjowanych, w tym: oferowanie częściowo wypełnionych formularzy, inicjowanie potrzeby wykonania czynności, poinformowanie Klienta o zbliżającej się potrzebie wykonania danej czynności, ePłatności - np. od Pełnomocnictwa, wynikające z przepisów prawa, system umożliwi też zarządzanie odpowiedziami.
12.3. Opis działania. Usługa jest dostępna w strefie klienta (zalogowany użytkownik). Użytkownik ma możliwość zgłoszenia wniosku o wymianę/plombowanie licznika (wodomierza).
12.4. Klient po wywołaniu tej usługi otrzymuje ekran listą/tabelą zawierającą podstawowe dane o zamontowanych dla niego wodomierzach. Są nimi, co najmniej:
a) Numer fabryczny wodomierza,
b) Lokalizacja (minimum adres),
c) Roku ważności legalizacji,
d) Data ostatniego rozliczonego odczytu,
e) Wskazanie ostatniego rozliczonego odczytu,
f) Uwaga do ostatniego rozliczonego odczytu (np. opis usterki).
g) Wskaźnik (graficzny symbol) możliwości zdalnego odczytu.
12.5. Klient po wybraniu wodomierza (zaznacza wiersz) i naciśnięciu przycisku „Przygotuj Wniosek” i otrzymuje do wypełnienia – uszczegółowienia formularz wniosku, w którym może umieścić ewentualne komentarze, opisy, informacje istotne z punktu widzenia zgłoszonego wniosku i jego późniejszej realizacji. Dodatkowo do formularza użytkownik może załączyć pliki graficzne - co najmniej w formacie pdf, doc, docx, xps, odt, jpeg, gif, które mogą pozwolić pracownikom Urzędu na lepszą ocenę sytuacji i podjęcie właściwych decyzji w związku z zgłoszeniem.
12.6. Formularz wniosku musi zawierać:
a) Możliwość wprowadzenia proponowanego przez Klienta terminu realizacji
wymiany/plombowania.
b) Dane kontaktowe, jeśli są inne niż podstawowe dane klienta.
12.7. E-usługa wyświetla informacje o statusie jego aktywnych wniosków
o wymianę/plombowanie (tylko niezałatwionych).
12.8. Po poprawnym zweryfikowaniu danych w formularzu wniosku przez e-usługę, po naciśnięciu przycisku „Wyślij” następuje wysłanie wniosku do systemu dziedzinowego. Po weryfikacji i przyjęciu wniosku do realizacji przez pracownika Urzędu, klient otrzyma SMS lub e-mail z informacją o statusie zgłoszenia.
12.9. Ekran e-usługi „Wniosek o wymianę/plombowanie licznika/podurządzenia pomiarowego” powinien umożliwić wywołanie skojarzonych e-usług:
a) E-zgłoszenie,
12.10. Funkcjonalność dodatkowa:
a) Zapis wniosku do pliku pdf lub xps.
b) Wydruk wniosku.
13. E-faktura.
13.1. Podproces inicjowany przez użytkownika Portalu (klient). Klient po zalogowaniu do e- portalu (strefa klienta) ma możliwość na podstawie pozyskanego poprzez e- usługę zdalnego odczytu lub podanego w formularzu odczytu wodomierza zlecić wygenerowanie e-faktury. Procesowanie formularzy, na podstawie pozyskanych danych rozpoczyna się automatycznie, jeśli klient ma złożoną deklarację/zgodę na wysyłanie faktur drogą elektroniczną (doręczenia elektroniczne) lub musi zostać poprzedzone wypełnieniem online stosownego formularza. System przetwarza uzyskane w ten sposób dane przekazując klientowi fakturę w formie elektronicznej (w tym możliwość generowania faktur ustrukturyzowanych);
13.2. Personalizacja eUsług (5 poziom dojrzałości) poprzez: automatyczne dostarczanie konkretnemu klientowi spersonalizowanych dla niego eusług i przez niego nie inicjowanych, w tym: oferowanie częściowo wypełnionych formularzy, inicjowanie potrzeby wykonania czynności, poinformowanie Klienta o zbliżającej się potrzebie wykonania danej czynności, ePłatności - np. od Pełnomocnictwa, wynikające z przepisów prawa, system umożliwi też zarządzanie odpowiedziami.
13.3. Opis działania. Usługa jest dostępna w strefie klienta (zalogowany użytkownik). Klient po wywołaniu usługi otrzymuje możliwość:
a) Złożenia deklaracji/zgody na wysyłanie faktur drogą elektroniczną,
b) Jeśli zgoda jest odnotowana przez e-sługę – klient zleca wykonanie wystawienia e- faktury na podstawie:
a. Wprowadzonego dla punktu rozliczeniowego (odbiorcy) /wodomierza w podanej lokalizacji odczytu/wskazania wodomierza wraz z datą, kiedy ten odczyt został wykonany,
b. Wykonania zdalnego odczytu – poprzez usługę zdalny odczyt.
c) Wycofania deklaracji/zgody na wysyłanie faktur drogą elektroniczną.
13.4. Wystawienie e-faktury możliwe jest wyłącznie po przyjęciu przez system dziedzinowy poprawnie wypełnionego wniosku. O przyjęciu wniosku i uruchomieniu możliwości wystawiania e-faktur klient zostaje poinformowany e-mailem.
13.5. Wystawienie e-faktury składa się z następujących etapów:
a) Wybór punktu rozliczeniowego z listy aktywnych punktów rozliczanych (PPU)
/wodomierzy
b) Wprowadzenie ważnego odczytu (wskazanie wraz z datą). Musi zostać wykonana minimalna kontrola na podstawie ostatniego rozliczonego odczytu dla wybranego punktu rozliczeniowego na:
c) Datę,
d) Wskazanie, oraz
e) Opcjonalne na podstawie parametru indywidualnego ustawienia – kontrola wielkości zużycia – kontrola w minimalnym zakresie porównywalnego z zapamiętanym w systemie dziedzinowym zużyciem dobowym w poprzednim porównywalnym okresie.
f) Weryfikacja zlecenia e-faktury w systemie dziedzinowym, przetworzenie i generowanie faktury.
g) Publikacja e-faktury poprzez wysłanie maila z informacją do klienta.
13.6. Ekran usługi E-faktura powinien umożliwić wywołanie skojarzonych e-usług:
a) E-usługa zdalny odczyt,
b) Udostępnienie wartości odczytu przez Internet.
14. E-płatność.
14.1. Podproces inicjowany przez użytkownika e-BOK (klient). Klient po zalogowania do e- BOK (strefa klienta) ma możliwość dokonania płatności za otrzymane faktury bezpośrednio z poziomu e-BOK za pośrednictwem systemu e- płatności. Klient ma możliwość wskazania nieopłaconych należności na wyświetlonym zestawieniu i uruchomieniu usługi płatności elektronicznej. Dostawca e-płatności zostanie wybrany przez Zamawiającego.
14.2. Opis działania. Usługa jest dostępna w strefie klienta (zalogowany użytkownik). Wywołanie usługi wyświetla podstawową informację, jaką jest saldo klienta na dzień (jest to data aktualizacji publikacji danych z systemu dziedzinowego).
14.3. Wyświetlona zostaje również zestawienie/tabela nieopłaconych faktur lub not odsetkowych (chronologiczne zestawienie nieopłaconych lub częściowo opłaconych faktur i not odsetkowych.
14.4. Zestawienie/tabela „Nieopłacone faktury” zawiera, co najmniej następujące dane:
a) Rodzaj dokumentu (faktura, nota)
b) Numer dokumentu (pełny numer faktury, noty)
c) Data wystawienia;
d) Termin płatności;
e) Wartość faktury/noty brutto
f) Kwota długu na fakturze/nocie
g) Status zadłużenia (elementem graficznym należy oznaczyć dokumenty, dla których minął termin zapłaty).
14.5. Klient może poprzez zaznaczenie dokumentu wybrać pozycje/dokumenty, dla których będzie chciał dokonać zapłaty. Za każdym razem, jak klient zaznacza dokument na ekranie w wyróżnionym polu wyświetlana jest sumaryczna kwota do zapłaty. Z zastrzeżeniem, że w sytuacji, w której są dokumenty (faktury) dla których minął termin zapłaty płatności będą realizowane w pierwszej kolejności dla tych dokumentów w kolejności od najstarszego.
14.6. Dla wybranych przez Klienta dokumentów, dla których minął termin zapłaty, kwotę należnych odsetek wylicza system dziedzinowy nie e-usługa.
14.7. O zrealizowaniu zapłaty poprzez e-płatność Klient zostanie poinformowany e- mailem lub SMS.
14.8. Ekran usługi E-płatność powinien umożliwić wywołanie skojarzonych e-usług:
a) Historia płatności
b) E-monit
14.9. Funkcjonalność dodatkowa:
a) Eksport danych do pliku csv, xls/ods lub pdf.
15. E-rozliczenia. Historia płatności (5).
15.1. Podproces prezentacji rozrachunków dla użytkownika e-portalu (klient). Klient po zalogowaniu do e-portalu (strefa klienta) ma możliwość wysłania zapytania do systemu dziedzinowego dotyczącego bieżącej informacji – salda rozliczeń, z dostępem do historycznych płatności i stanu swojego konta – po uprzedniej autoryzacji.
15.2. Personalizacja eUsług (5 poziom dojrzałości) poprzez: automatyczne dostarczanie konkretnemu klientowi spersonalizowanych dla niego eusług i przez niego nie inicjowanych, w tym: oferowanie częściowo wypełnionych formularzy, inicjowanie potrzeby wykonania czynności, poinformowanie Klienta o zbliżającej się potrzebie wykonania danej czynności, ePłatności - np. od Pełnomocnictwa, wynikające z przepisów prawa, system umożliwi też zarządzanie odpowiedziami.
15.3. Opis działania. Usługa jest dostępna w strefie klienta (zalogowany użytkownik). Wywołanie usługi wyświetla podstawową informację, jaką jest saldo klienta na dzień (jest to data aktualizacji publikacji danych z systemu dziedzinowego).
15.4. Klient dostaje również możliwość wyświetlenia historii rozrachunków (chronologiczne zestawienie faktur i not odsetkowych) lub zostaje ona bezpośrednio wyświetlona wraz z saldem.
15.5. W zestawieniu/tabeli „Historia rozrachunków” dostępne są, co najmniej następujące
xxxx:
a) Rodzaj dokumentu (faktura, nota, wpłata).
b) Numer dokumentu (pełny numer faktury, noty).
c) Data wystawienia.
d) Termin płatności.
e) Wartość faktury/noty brutto.
f) Kwota wpłaty.
g) Data wpłaty.
15.6. Ekran usługi Historia płatności powinien umożliwić wywołanie skojarzonych e-usług:
a) E-płatność
b) E-monit
15.7. Funkcjonalność dodatkowa:
a) Prezentacja graficzna na wykresie kolumnowym,
b) Eksport danych do pliku csv, xls/ods lub pdf.
16. E-monit (5).
16.1. Podproces inicjowany przez użytkownika E-BOK (klient) lub pracownika Urzędu (operator). Klient po zalogowania do e-BOK (strefa klienta), a operator po zalogowani się, jako pracownik Urzędu (strefa administratora) ma możliwość wyboru usługi informowania o zbliżającej się płatności oraz sposobu jej realizacji: SMS-em lub mailem. Operator ma możliwość wskazania odbiorców lub grup odbiorców.
16.2. Personalizacja eUsług ( 5 poziom dojrzałości ) poprzez: automatyczne dostarczanie
konkretnemu klientowi spersonalizowanych dla niego eusług i przez niego
nie inicjowanych, w tym: oferowanie częściowo wypełnionych formularzy, inicjowanie potrzeby wykonania czynności, poinformowanie Klienta o zbliżającej się potrzebie wykonania danej czynności, ePłatności - np. od Pełnomocnictwa, wynikające z przepisów prawa, system umożliwi też zarządzanie odpowiedziami.
16.3. Opis działania. Usługa jest dostępna w strefie klienta (zalogowany użytkownik). Klient ma do dyspozycji mechanizm pozwalający na zdefiniowanie sposobu informowania o zbliżającej się płatności oraz metody realizacji: SMS-em lub mailem.
16.4. Usługa pozwala na zdefiniowanie:
a) Włączenia/wyłączenia usługi SMS,
b) Włączenia/wyłączenia usługi e-mail,
c) Liczby dni przed terminem płatności dokumentu, kiedy zostanie wysłane
powiadomienie/przypomnienie o zbliżającym się terminie zapłaty,
d) Zakresu godzinowego w ciągu dnia, kiedy dla usługi SMS będzie wysyłany
komunikat,
e) Głównego i dodatkowego adresu mailowego, na który system będzie wysyłał powiadomienie, (możliwy inny niż e-mail dla e-faktur),
f) Głównego i dodatkowego nr telefonu komórkowego i stacjonarnego, (jeśli
ma możliwość odbioru sms),
g) Maksymalną liczbę powtórzeń wysłanych komunikatów (dla całego okresu
przypominania).
16.5. Funkcjonalność dodatkowa:
a) Zapis/wydruk ustawień w formacie pdf.
17. E-wezwanie do zapłaty (5).
17.1. Podproces inicjowany przez pracownika Urzędu – operator e-portalu. Klient po zalogowaniu do e-portalu (strefa klienta) ma możliwość wysłania zapytania do systemu dziedzinowego dotyczącego bieżącej informacji - stanu należności i salda rozliczeń, z dostępem do listy wystawionych faktur i innych dokumentów księgowych jak wezwania do zapłaty i noty odsetkowe – po uprzedniej autoryzacji dostępu. Jeśli zostało wystawione przez system dziedzinowy wezwanie do zapłaty wówczas Klient po zalogowaniu do e-BOK dostaje komunikat o takim zdarzeniu z możliwością automatycznego przejścia do ekranu z zestawieniem/tabelą „Nieopłacone należności” i wskazaniem poprzez wyróżnienie tych należności, które zawiera wezwanie do zapłaty.
17.2. Personalizacja eUsług ( 5 poziom dojrzałości ) poprzez: automatyczne dostarczanie konkretnemu klientowi spersonalizowanych dla niego eusług i przez niego nie inicjowanych, w tym: oferowanie częściowo wypełnionych formularzy, inicjowanie potrzeby wykonania czynności, poinformowanie Klienta o zbliżającej się potrzebie wykonania danej czynności, ePłatności - np. od Pełnomocnictwa, wynikające z przepisów prawa, system umożliwi też zarządzanie odpowiedziami.
17.3. Opis działania. Usługa jest dostępna w strefie klienta (zalogowany użytkownik). Usługa jest aktywowana dla klienta automatycznie poprzez fakt wygenerowania przez system dziedzinowy dokumentu „Wezwanie do zapłaty”. Klient po zalogowaniu
do e- portalu (strefa logowana), dla którego wygenerowano wezwanie do zapłaty, otrzymuje odpowiednio przygotowany komunikat (wraz z elektronicznym doręczeniem – jeśli klient wyraził zgodę na taki sposób) zawierający:
a) Informacje o dacie utworzenia Wezwania.
b) Kwocie wezwania.
c) Wyznaczonym terminie uregulowania zadłużenia.
17.4. Zestawienie/tabela „Nieopłacone należności” zawiera, co najmniej następujące
xxxx:
a) Rodzaj dokumentu (faktura, nota).
b) Numer dokumentu (pełny numer faktury, noty).
c) Data wystawienia.
d) Termin płatności.
e) Wartość faktury/noty brutto.
f) Kwota długu na fakturze/nocie.
17.5. Ekran zawiera również link/ikonę dokumentu Wezwanie do zapłaty, które klient może wydrukować, przeglądać lub pobrać (typ pliku do pobrania, co najmniej pdf, xps).
17.6. Klient może poprzez zaznaczenie dokumentu (wstępnie zaznaczone są przez e-usługę te z wezwania do zapłaty) wybrać te, dla których będzie chciał dokonać zapłaty. Za każdym razem, jak klient zaznacza dokument na ekranie w wyróżnionym polu wyświetlana jest sumaryczna kwota do zapłaty.
17.7. O zrealizowaniu zapłaty poprzez e-płatność Klient zostanie poinformowany e- mailem lub SMS.
17.8. Ekran usługi E-wezwanie do zapłaty powinien umożliwić wywołanie skojarzonych
e- usług:
a) Historia płatności,
b) E-nota odsetkowa,
c) E–monit,
d) Moje płatności,
e) Obsługa faktur.
18. E-nota odsetkowa (5).
18.1. Podproces inicjowany przez pracownika Urzędu – operator e-portalu. Klient po zalogowaniu do e-portalu (strefa klienta) ma możliwość wysłania zapytania do systemu dziedzinowego dotyczącego bieżącej informacji – stanu należności i salda rozliczeń, z dostępem do listy wystawionych faktur i not odsetkowych - po uprzedniej autoryzacji dostępu. Jeśli została wystawiona przez system dziedzinowy nota odsetkowa wówczas Klient po zalogowaniu do e-BOK dostaje komunikat o takim zdarzeniu z możliwością automatycznego przejścia do ekranu z zestawieniem/tabelą
„Zapłacone po terminie” i wskazaniem poprzez wyróżnienie tych należności, dla których naliczono odsetki z tytułu zapłaty po terminie, a kwota tych odsetek została zawarta w nocie odsetkowej.
18.2. Personalizacja eUsług ( 5 poziom dojrzałości ) poprzez: automatyczne dostarczanie
konkretnemu klientowi spersonalizowanych dla niego eusług i przez niego
nie inicjowanych, w tym: oferowanie częściowo wypełnionych formularzy, inicjowanie potrzeby wykonania czynności, poinformowanie Klienta o zbliżającej się potrzebie wykonania danej czynności, ePłatności - np. od Pełnomocnictwa, wynikające z przepisów prawa, system umożliwi też zarządzanie odpowiedziami.
18.3. Opis działania. Usługa jest dostępna w strefie klienta (zalogowany użytkownik). Usługa jest aktywowana dla klienta automatycznie poprzez fakt wygenerowania przez system dziedzinowy dokumentu „Nota odsetkowa”. Dla klienta po zalogowaniu do e- portalu (strefa logowana), dla którego wygenerowano notę odsetkową dostępne są, co najmniej informacje:
a) Data utworzenia noty odsetkowej.
b) Kwota Noty.
c) Wyznaczony termin uregulowania należności odsetkowych.
d) Linku/klawisza do szybkiego przejścia do zestawienia/tabeli „Zapłacone
po terminie”.
wraz z możliwością elektronicznego doręczenia – jeśli klient wyraził zgodę na taki
sposób.
18.4. Zestawienie/tabela „Zapłacone po terminie” zawiera, co najmniej następujące dane:
a) Rodzaj dokumentu (tylko faktura)
b) Numer dokumentu (pełny numer faktury)
c) Data wystawienia;
d) Termin płatności;
e) Wartość faktury brutto,
f) Kwota wpłaty,
g) Data zapłaty,
h) Liczbie dni zwłoki,
i) Kwoty naliczonych odsetek,
j) Zaliczenie faktury do Noty odsetkowej (elementem graficznym należy oznaczyć dokumenty, które znalazły się w bieżącej Nocie odsetkowej).
18.5. Ekran zawiera również link/ikonę dokumentu Nota odsetkowa, po wybraniu, której klient może bieżącą Notę wydrukować, przeglądać lub pobrać (typ pliku do pobrania, co najmniej pdf).
18.6. Klient może poprzez zaznaczenie dokumentu (wstępnie zaznaczone są przez e-usługę te z Noty odsetkowej) wybrać te, dla których będzie chciał dokonać zapłaty odsetek. Za każdym razem, jak klient zaznacza dokument na ekranie w wyróżnionym polu wyświetlana jest sumaryczna kwota odsetek do zapłaty.
18.7. O zrealizowaniu zapłaty poprzez e-płatność Klient zostanie poinformowany e-mailem lub SMS.
18.8. Ekran usługi E-nota odsetkowa powinien umożliwić wywołanie skojarzonych e-usług:
a) Historia płatności,
b) E-nota odsetkowa,
c) E–monit,
d) Moje płatności,
e) Obsługa faktur.
18.9. Funkcjonalność dodatkowa:
a) Eksport danych do pliku csv, xls/ods lub pdf.
19. E-warunki techniczne (5).
19.1. Podproces inicjowany przez użytkownika E-BOK (klient). Klient (strefa nielogowana i strefa klienta) ma możliwość złożenia wniosku o wydanie warunków technicznych i przyłączenie do sieci wodociągowej lub kanalizacyjnej. Użytkownik (mieszkaniec, inwestor) ma dostęp online do interaktywnego formularza wniosku poprzez wskazanie na mapie miejsca/obszaru, dla którego istnieje możliwość przyłączenia się do sieci wod/kan. E-usługa na podstawie zebranych danych przez interaktywny formularz i adresowi zwrotnemu e-mail zwraca informacje o zarejestrowaniu wniosku i kolejnych podejmowanych przez Urząd działaniach wraz z przekazaniem warunków drogą e- mail (i/lub ePUAP oraz zgodnie z doręczeniami elektronicznymi). Przekazuje informacje o możliwości skorzystania z e-zlecenia. Użytkownik może wyświetlić widok (lub wydrukować formularz) mapy lub utworzyć plik z mapą.
19.2. Personalizacja eUsług (5 poziom dojrzałości) poprzez: automatyczne dostarczanie konkretnemu klientowi spersonalizowanych dla niego eusług i przez niego nie inicjowanych, w tym: oferowanie częściowo wypełnionych formularzy, inicjowanie potrzeby wykonania czynności, poinformowanie Klienta o zbliżającej się potrzebie wykonania danej czynności, ePłatności - np. od Pełnomocnictwa, wynikające z przepisów prawa, system umożliwi też zarządzanie odpowiedziami.
19.3. Opis działania. Usługa jest dostępna w strefie logowanej –strefie klienta (zalogowany użytkownik) oraz w strefie nielogowanej. Użytkownik e-usługi ma dostęp do mapy prezentującej zewidencjonowaną sieć wodociągową i kanalizacyjną. Zakres prezentowanej sieci – rodzaj/typ sieci, jej parametry muszą być definiowalne przez użytkownika lub co najmniej uzgodnione na etapie wdrożenia wraz z udostępnieniem odpowiedniej akceptowalnej przez Zamawiającego procedury dokonywania takich zmian. Definicja obszaru, dla którego istnieje możliwość przyłączenia do sieci wodociągowej lub kanalizacyjnej musi być realizowana na zasadzie definiowalnego parametru e-usługi i zostać uzgodniona na etapie wdrożenia z Zamawiającym.
19.4. Dla użytkownika w strefie logowanej użycie formularza do wprowadzenia danych do wniosku nie wymaga podawania danych osobowych (identyfikowany jest poprzez unikalny ID użytkownika).
19.5. Dla użytkownika w strefie nielogowanej użycie formularza do wprowadzenia danych do wniosku musi podlegać, co najmniej minimalnej kontroli poprzez wprowadzenie mechanizmu sprawdzającego, czy dany użytkownik jest nie jest botem (mechanizm ten nie może być uciążliwym dla użytkownika, nie dopuszcza się mechanizmów typu podaj wynik operacji matematycznych lub podobnych oraz nie może wykorzystywać obrazkowego zabezpieczenia ze względu na osoby z dysfunkcjami wzroku).
19.6. Formularz powinien zostać wstępnie wypełniony dla klientów z strefy logowanej. Podstawowe dane, które powinny zostać uwzględnione w formularzu:
a) Dane wnioskodawcy (wypełnione dla strefy logowanej), w tym adres e- mail i telefon kontaktowy,
b) Rodzaj sieci (wodociągowa/kanalizacja sanitarna – wybór przez zaznaczenie (np. check box),
c) Rodzaj budynku (mieszkalny jednorodzinny, mieszkalny wielorodzinny, działka budowlana, obiektu innego /wpisać rodzaj i ilość kondygnacji/ - wybór przez zaznaczenie (np. check box) dla mieszkalnego wielorodzinnego wpisać ilość mieszkań, dla działki umożliwić podanie powierzchni [m2]),
d) Lokalizacja nieruchomości (ulica/nr działki/miejscowość),
e) Dobowe zapotrzebowanie wody:
i. Qśrd [m3/d],
ii. Liczba zamieszkałych/zatrudnionych osób.
f) Dobowa odprowadzanych ścieków:
i. Qśrd [m3/d],
ii. Rodzaj ścieków: Bytowe, przemysłowe*.
g) Wyposażenie sanitarne (podać w szt.)
i. Umywalka,
ii. Wanna,
iii. Natrysk,
iv. Zlewozmywak,
v. Ubikacja,
vi. Inne.
h) Przewidywana wielkość zanieczyszczeń w odprowadzanych ściekach (dotyczy ścieków przemysłowych):
i. PH, BZT5 [mg O2/l], ChZT [mg O2/l], Zawiesina ogólna,
ii. Metale ciężkie (wymienić) [mg/l],
iii. Azot ogólny [mg/l],
iv. Fosfor [mg/l],
v. Chlorki [mg/l],
vi. Siarczany [mg/l].
i) Stan faktyczny obiektu (istniejący, projektowany, w rozbudowie - wybór
przez zaznaczenie (np. check box),
j) Czy obiekt posiada lokalne ujęcie wody (Tak, Nie - wybór przez zaznaczenie
(np. check box),
k) Tytuł prawny do obiektu (własność, użytkowanie, najem, dzierżawa, darowizna
- wybór przez zaznaczenie (np. check box),
l) Proponowany termin rozpoczęcia dostawy wody/odprowadzania ścieków.
m) Xxxxxx odbioru dokumentacji (osobiście, pocztą i e-mail - wybór przez
zaznaczenie (np. check box),
n) Faktura wystawiona na inwestora, pełnomocnika – wola warunkowe pozwalające na wypełnienie danych dla inwestora lub Pełnomocnika,
o) Oświadczanie o wyrażeniu zgody na przetwarzanie danych osobowych - zgoda poprzez zaznaczenie (np. check box),
p) Możliwość dodania plików załączników do wniosku, (co najmniej 10, max.).
i. Obligatoryjne – dla zaznaczonych ścieków technologicznych załącznik 1- Rodzaj ścieków technologicznych, 2-Jakość odprowadzanych ścieków, 3- Urządzenia podczyszczające ścieki.
ii. Wymagane – Dokument określający stan prawny nieruchomości, której
dotyczy wniosek,
iii. Wypis z krajowego rejestru spółek lub rejestry działalności gosp.
iv. Skan Dokumentu zapewnienia dostaw wody.
19.7. Ze względu na wagę podawanych informacji formularz musi obsługiwać mechanizm CAPTCHA (lub inny równoważny w zakresie zabezpieczenia przez tzw. robotami) przed wysłaniem zarejestrowanego wniosku.
19.8. Usługa musi umożliwiać sprawną nawigację po mapie oraz dawać mechanizmy sprawnego wyszukania interesującego użytkownika obszaru sieci oraz ma umożliwiać rysowania/projektowanie na mapie, (co najmniej obiekty liniowe i punktowe wraz z tekstem) a następnie wydrukowania formularza mapy lub utworzenia pliku z mapą, co najmniej do formatu pdf, gif.
obsługi
placówek
oświatowych
(obsługa
rekrutacji)
Projektowany system będzie obsługiwał proces rekrutacji do wszystkich placówek edukacyjnych, których organem prowadzącym jest Gmina Michałowice.
Gminna baza oświaty składa się z następujących szkół i przedszkoli:
• 1 liceum ogólnokształcące,
• 2 przedszkola w 12 oddziałach,
• 3 szkoły podstawowe.
Jednostkami organizacyjnymi prowadzącymi powyższe placówki są:
• Szkoła Podstawowa im. Xxxx Xxxxx XX w Michałowicach przy ul. Xxxxxxxx 00,
• Zespół Szkół Ogólnokształcących im. Xxxxx Xxxxxxxxxxx w Komorowie, ul. Xx. Xxxxx Xxxxxxxxxxx 00/00 (szkoła podstawowa i liceum):
• Zespół Szkolno – Przedszkolny im. Xxxxxxxx Xxxxxxxxx w Nowej Wsi, ul. Główna 96 (szkoła podstawowa i przedszkole),
• Gminne Przedszkole w Michałowicach, ul. Xxxxxxx 00.
W roku szkolnym 2019/20 do gminnych placówek edukacyjnych uczęszczało łącznie 2809 uczniów. W tym do liceum 216 uczniów a do przedszkoli 345 dzieci. W kolejnych latach planowane jest otwarcie przedszkola w miejscowości Reguły.
System musi być tak skonstruowany aby możliwe było dodawanie do niego w przyszłości kolejnych placówek szkolnych i przedszkolnych.
Miejscem dostępowym do systemu będzie profil użytkownika na Portalu Systemu. Wykonawca dokona wdrożenia Systemu w taki sposób, że będzie on dostępny dla pracowników Centrum Usług Wspólnych Gminy Michałowice oraz personelu wszystkich placówek edukacyjnych.
I. | Opis wymagań ogólnych |
1. | System składa się z dwóch rodzajów widoków: a. część publiczna - dla rodziców, dostępna przez przeglądarkę internetową, za pośrednictwem której kandydat rejestruje się do placówki oświatowej, a następnie logując się za pomocą indywidualnego loginu i hasła może śledzić na bieżąco postęp procesu rekrutacji. b. część rekrutacyjna - przeznaczona dla komisji rekrutacyjnych, dostępny przez przeglądarkę internetową bez konieczności instalacji dodatkowych komponentów. – ma umożliwić komisjom obsługę procesu rekrutacji. |
2. | System jest dostępny w przeglądarkach internetowych w najnowszej wersji na dzień złożenia oferty (Safari, Chrome, Firefox, Internet Explorer, Edge i Opera). |
3. | System jest zbudowany w technologii RWD (Responsive Web Design) zapewniając dostęp do platformy z urządzeń mobilnych poprzez przeglądarki internetowe. |
4. | System jest zgodny z WCAG 2.1 AA |
5. | Wykonawca w ramach Zamówienia zapewni infrastrukturę w modelu SaaS posiadającą certyfikację ISO ISO/IEC 27001 oraz ISO/IEC 27018 niezbędną dla eksploatacji systemu co najmniej w okresie gwarancji, umożliwiającą korzystanie przez użytkowników z systemu w trybie ciągłym (24 godz. na dobę, 7 dni w tygodniu). |
6. | System jest zgodny z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE |
7. | System pozwala na autoryzację dwustopniową (email, kod weryfikacyjny SMS) oraz Profil Zaufany / Węzeł Krajowy. |
8. | System pozwala na składanie i podpisywanie wniosków z wykorzystaniem mechanizmów opartych o Profil Zaufany. |
II. | Opis wymagań e-rekrutacje do szkół |
1. | Moduł zapewnia dostęp w części publicznej do prezentacji oferty edukacyjnej szkół objętych elektronicznym systemem rekrutacji, w tym do opisu szkoły. |
2. | Moduł zapewnia dostęp w części publicznej do prezentacji zasad naboru oraz terminarza rekrutacji. |
3. | Moduł zapewnia w części publicznej dostęp do plików i instrukcji obsługi systemu dla kandydatów i ich rodziców. |
4. | Moduł posiada mechanizmy, pozwalające na udostępnienie w części publicznej wyszukiwania szkoły obwodowej na podstawie wybranej ulicy oraz wprowadzonego numeru domu. |
5. | Moduł zapewnia dostęp w części publicznej do komunikatów i aktualności zamieszczanych dla kandydatów i ich rodziców przez pracowników Organu Prowadzącego. |
6. | Moduł umożliwia w części publicznej systemu rejestrację oraz wydruk uzupełnionego zgłoszenia do szkoły obwodowej |
7. | Moduł umożliwia w części publicznej systemu uzupełnienie kryteriów naboru, zgodnych z przyjętymi zasadami rekrutacji (w przypadku uruchomienia naboru dzieci spoza obwodu szkoły). |
8. | Moduł umożliwia złożenie wniosku o przyjęcie dziecka spoza obwodu po zakończonym terminie przyjmowania zgłoszeń od rodziców dzieci obwodowych. |
9. | Moduł umożliwia edycję wniosku lub zgłoszenia w części publicznej systemu przez kandydata lub jego rodzica do czasu zatwierdzenia wniosku/zgłoszenia w placówce(moduł musi umożliwić wycofanie wniosku/zgłoszenia i złożenie ponownie) |
10. | Moduł zapewnia w części publicznej systemu funkcjonalność umożliwiającą przesłanie nowego hasła do konta na wskazany we wniosku/zgłoszeniu adres poczty elektronicznej. |
11. | Moduł umożliwia dostęp w części publicznej do monitorowania statusu wniosku/zgłoszenia w systemie na każdym etapie rekrutacji. |
12. | Moduł zapewnia w części publicznej dostęp do informacji o wynikach rekrutacji zgodnie z harmonogramem, w tym otrzymanie wyników rekrutacji na wskazany we wniosku/zgłoszeniu adres poczty elektronicznej. |
13. | Moduł posiada mechanizmy pozwalające na dokonanie potwierdzenia woli zapisu do placówki kwalifikacji z poziomu konta kandydata/rodzica w części publicznej (w zależności od decyzji Zamawiającego) (w przypadku naboru dzieci spoza obwodu) |
14. | Moduł umożliwia tworzenie przez placówki objęte systemem elektronicznej rekrutacji opisu szkoły oraz opisu oddziałów/grup rekrutacyjnych. |
15. | Moduł zapewnia kontrolę utworzonych oddziałów/grup rekrutacyjnych przez Organ Prowadzący z możliwością podglądu i edycji wprowadzonych przez placówkę informacji. |
16. | Moduł umożliwia wprowadzenie i potwierdzenie wniosków dla dzieci spoza obwodu przez szkołę wskazaną na pierwszym miejscu listy preferencji kandydata. |
17. | Moduł zapewnia obsługę procesu przyjęć kandydatów z obwodu, w szczególności: a. podglądu wprowadzonej listy kandydatów obwodowych, w tym możliwość zaimportowania pliku w formacie pliku arkusza kalkulacyjnego z listą kandydatów obwodowych, b. wprowadzenie w systemie we wniosku/zgłoszeniu przez rodzica/prawnego opiekuna adresu zamieszkania powoduje wskazanie szkoły obwodowej kandydata, c. dostępu do informacji o statusie wniosku kandydata z obwodu placówki, |
18. | Moduł umożliwia przyporządkowanie dzieci posiadających orzeczenie o potrzebie kształcenia specjalnego do oddziałów/grup rekrutacyjnych przeznaczonych dla dzieci z orzeczeniem w drodze indywidualnej decyzji dyrektora placówki |
19. | Moduł posiada mechanizmy pozwalające na ustalenie kolejności przyjęć kandydatów, którzy uzyskali tą samą liczbę punktów w procesie rekrutacji na podstawie potwierdzonych kryteriów. |
20. | Moduł zapewnia utworzenie i przygotowanie do publikacji list kandydatów zakwalifikowanych i list kandydatów niezakwalifikowanych. |
21. | Moduł zapewnia utworzenie i przygotowanie do publikacji list kandydatów przyjętych i list kandydatów nieprzyjętych. |
22. | Moduł zapewnia zamknięcie etapu pracy indywidualnie przez każdą placówkę biorącą udział w elektronicznej rekrutacji. |
23. | Moduł zapewnia obsługę procesu rekrutacji uzupełniającej prowadzonej według zasad naboru, przy czym w zależności od decyzji Zamawiającego: a. rekrutacja może być prowadzona z wykorzystaniem wszystkich mechanizmów wykorzystanych na pierwszym etapie rekrutacji, b. rekrutacja może być wprowadzona przy wsparciu elektronicznego systemu tj. internetowa publikacja liczb wolnych miejsc, aktualizowanych na bieżąco przez Organ Prowadzący. |
24. | Moduł zapewnia pracownikom Organu Prowadzącego wysyłanie komunikatów do wszystkich użytkowników placówek, którzy mają założone konta w systemie elektronicznej rekrutacji. |
25. | Moduł zapewnia pracownikom Organu Prowadzącego pobieranie z systemu raportów w formacie arkusza kalkulacyjnego na każdym etapie procesu rekrutacji, dotyczących: a) Oferowanej liczby miejsc w oddziałach/grupach rekrutacyjnych, b) Liczby kandydatów zamieszkałych w obwodzie placówki, c) Liczby kandydatów uczestniczących w procesie rekrutacji z uwzględnieniem placówki preferencji, statusu wniosku, d) Liczby kandydatów z orzeczeniem o potrzebie kształcenia specjalnego, e) Liczby kandydatów zakwalifikowanych i niezakwalifikowanych, |
f) Liczby kandydatów przyjętych i nieprzyjętych, g) Liczby zgłoszeń kandydatów do szkoły obwodowej, h) Liczby kandydatów do oddziałów/grup rekrutacyjnych, w których wymagane jest dodatkowe postępowanie (sprawdziany predyspozycji językowych, próba sprawności fizycznej), i) Minimalnej, średniej i maksymalnej liczby punktów kandydatów zakwalifikowanych i przyjętych, j) Liczby kandydatów z gminy i spoza gminy. | |
26. | Moduł zapewnia pracownikowi Organu Prowadzącego obsługę procesu symulacji przydziału, w szczególności: a) wyświetlane w czasie przydziału raporty powinny pozwalać na zmianę limitów miejsc w oddziałach/grupach rekrutacyjnych, b) dostęp do informacji o liczbie kandydatów biorących udział w kwalifikacji (w tym obwodowych oraz z pierwszej i kolejnych preferencji), c) dostęp do informacji o liczbie kandydatów zakwalifikowanych i niezakwalifikowanych (w tym obwodowych oraz pierwszej i kolejnych preferencji), d) dostęp do informacji o wyniku punktowym ostatniego zakwalifikowanego kandydata, e) dostępu do informacji o liczbie wolnych miejsc, f) pobranie z widoku symulacji arkusza kalkulacyjnego lub tekstowego z danymi zawartymi w raporcie, z możliwością ograniczenia liczby wyświetlanych danych. |
27. | Moduł umożliwia w toku rekrutacji wprowadzanie korekt w ofertach szkół objętych elektronicznym systemem rekrutacji, w tym dodawanie i usuwanie oddziałów/grup rekrutacyjnych oraz zmiany liczby miejsc w oddziałach/grupach rekrutacyjnych. |
III | Opis wymagań dla rekrutacji do przedszkoli |
1. | Moduł zapewnia dostęp w części publicznej do prezentacji oferty edukacyjnej placówek objętych elektronicznym systemem rekrutacji, w tym do opisu przedszkola, listy i liczby oddziałów. |
2. | Moduł zapewnia dostęp w części publicznej do prezentacji zasad naboru oraz terminarza rekrutacji. |
3. | Moduł zapewnia w części publicznej dostęp do plików i instrukcji obsługi systemu dla rodziców. |
4. | Moduł umożliwia edycję wniosku w części publicznej systemu przez rodzica do czasu zatwierdzenia wniosku w placówce (moduł musi umożliwić wycofanie wniosku i złożenie wniosku ponownie). |
5. | Moduł zapewnia dostęp w części publicznej do komunikatów i aktualności zamieszczanych dla rodziców przez pracowników Organu Prowadzącego. |
6. | Moduł zapewnia w części publicznej systemu funkcjonalność umożliwiającą przesłanie nowego hasła do konta na wskazany we wniosku adres poczty elektronicznej. |
7. | Moduł umożliwia dostęp w części publicznej do monitorowania statusu wniosku w systemie na każdym etapie rekrutacji. |
8. | Moduł zapewnia otrzymanie wyników rekrutacji na wskazany we wniosku adres poczty elektronicznej. Moduł posiada mechanizmy pozwalające na dokonanie potwierdzenia woli zapisu do placówki kwalifikacji z poziomu konta rodzica w części publicznej (w zależności od decyzji Zamawiającego). |
9. | Moduł zapewnia kontrolę utworzonych oddziałów/grup rekrutacyjnych przez Organ Prowadzący z możliwością podglądu wprowadzonych przez placówkę informacji. |
10. | Moduł posiada mechanizmy pozwalające na wprowadzenie dziecka kontynuującego edukację w kolejnym roku szkolnym. |
11. | Moduł pozwalana odnotowanie we wniosku kandydata informacji o odroczeniu obowiązku szkolnego. Brak zaznaczonej informacji o odroczeniu obowiązku szkolnego powinien uniemożliwiać wypełnienie wniosku w rekrutacji do przedszkoli. |
12. | Moduł umożliwia wprowadzenie i potwierdzenie wniosków w systemie przez placówkę wskazaną na pierwszym miejscu listy preferencji kandydata. |
13. | Moduł zapewnia możliwość wprowadzenia zmian w listach preferencji kandydatów zgodnie z zasadami rekrutacji. |
14. | Moduł umożliwia przyporządkowanie dzieci posiadających orzeczenie o potrzebie kształcenia specjalnego do oddziałów/grup rekrutacyjnych przeznaczonych dla dzieci z orzeczeniem w drodze indywidualnej decyzji dyrektora placówki wskazanej przez rodzica na liście preferencji |
15. | Moduł posiada mechanizmy pozwalające na ustalenie kolejności przyjęć dzieci, które uzyskały tę samą liczbę punktów w procesie rekrutacji na podstawie spełnianych przez kandydata kryteriów przyjęć. |
16. | Moduł zapewnia utworzenie i przygotowanie do publikacji list dzieci zakwalifikowanych i list dzieci niezakwalifikowanych. |
17. | Moduł zapewnia utworzenie, przygotowanie oraz wydrukowanie do publikacji list dzieci przyjętych i list dzieci nieprzyjętych w podziale na placówki |
18. | Moduł zapewnia zamknięcie etapu pracy indywidualnie przez każdą placówkę biorącą udział w elektronicznej rekrutacji. |
19. | Moduł zapewnia obsługę procesu rekrutacji uzupełniającej prowadzonej według zasad naboru, przy czym w zależności od decyzji Zamawiającego: a. rekrutacja może być prowadzona z wykorzystaniem wszystkich mechanizmów wykorzystanych na pierwszym etapie rekrutacji, b. rekrutacja może być wprowadzona przy wsparciu elektronicznego systemu tj. internetowa publikacja liczby wolnych miejsc, aktualizowanych na bieżąco. Możliwie jest wprowadzenie przez placówki kandydatów przyjętych. |
20. | Moduł zapewnia pracownikom Organu Prowadzącego wysyłanie komunikatów do wszystkich użytkowników placówek, którzy mają założone konta w systemie elektronicznej rekrutacji. |
21. | Moduł zapewnia pracownikom Organu Prowadzącego pobieranie z systemu raportów w formacie arkusza kalkulacyjnego na każdym etapie procesu rekrutacji, dotyczących: a. oferowanej liczby miejsc w oddziałach/grupach rekrutacyjnych, b. liczby dzieci uczestniczących w procesie rekrutacji z uwzględnieniem preferencji placówki, statusu wniosku, c. liczby kandydatów kontynuujących, d. liczbie dzieci z orzeczeniem o potrzebie kształcenia specjalnego, e. liczbie dzieci zakwalifikowanych i niezakwalifikowanych, f. liczbie dzieci przyjętych i nieprzyjętych, g. informacji o spełnianych kryteriach przez kandydatów. |
22. | Moduł zapewnia obsługę procesu symulacji przydziału miejsc, w szczególności: a. wyświetlane w czasie przydziału raporty powinny pozwalać na zmianę limitów miejsc w oddziałach/grupach rekrutacyjnych, b. dostęp do informacji o liczbie dzieci biorących udział w kwalifikacji (w tym z pierwszej i kolejnych preferencji z uwzględnieniem roczników), c. dostęp do informacji o liczbie dzieci zakwalifikowanych i niezakwalifikowanych (pierwszej i kolejnych preferencji z uwzględnieniem roczników), d. dostęp do informacji o wyniku punktowym ostatniego zakwalifikowanego dziecka, e. dostępu do informacji o liczbie wolnych miejsc. |
23. | Moduł umożliwia w toku rekrutacji wprowadzanie korekt w ofertach placówek objętych elektronicznym systemem rekrutacji, oraz zmiany liczby miejsc w oddziałach/grupach rekrutacyjnych. |
Dodatkowe funkcjonalności systemu do placówek oświatowych | |
1. | System do komunikacji pomiędzy rodzicami i przedszkolami (nauczyciele, administracja) w zakresie pobytu dziecka w placówkach przedszkolnych (x.xx. kontrola czasu pobytu). |
2. | Automatyczna rejestracja wejścia/wyjścia – zwolnienie pracowników placówki z codziennego obowiązku ręcznego rejestrowania obecności, a co za tym idzie uniknięcie błędów zapisu czasu przyprowadzenia i odebrania dziecka z placówki. |
3. | Automatyczne rozliczanie czasu pobytu wg różnych stawek – dostosowanie opłat do uchwały samorządowej z uwzględnieniem dofinansowań. |
4. | Uwzględnianie dofinansowań do pobytu – naliczanie pobytu zgodnie ze zdefiniowanymi w systemie dofinansowaniami – kwotowe lub procentowe. |
5. | Rejestracja wpłat za pobyt dokonanych przez opiekunów dzieci. |
6. | Automatyczne naliczanie odsetek – w zależności od terminu wpłaty przez opiekuna opłat za pobyt i posiłki. |
7. | Generowanie raportów (gotowe do druku) – uniknięcie problemu nieuzasadnionych roszczeń związanych z rozliczaniem czasu pobytu w placówce poprzez opracowanie raportów w formie łatwej do wykorzystania przez pracowników placówki oraz opiekunów dzieci. |
8. | Dostęp do danych poprzez przeglądarkę internetową – możliwość łatwego, szybkiego i wygodnego przeglądania informacji o dzieciach. |
9. | Portal dedykowany placówkom, dzieciom oraz ich opiekunom, dający dostęp do zasobów informacyjnych systemu |
Opis wymagania | |
10. | Platforma udostępniana jest w modelu SaaS na wysokowydajnej infrastrukturze serwerowej zapewniającej odpowiednią wydajność i skalowalność systemu. Dołączanie dodatkowych placówek nie powinno wpływać na wydajność rozwiązania. |
11. | Platforma jest dostępna z poziomu przeglądarek internetowych Safari, Chrome, Firefox, Internet Explorer, Edge i Opera w wersji najnowszej (według stanu na dzień złożenia oferty). Nie dopuszczalne jest stosowanie dodatkowych komponentów wymagających instalacji. |
12. | Platforma jest zgodna ze standardem WCAG 2.1 w wersji AA |
13. | Centrum przetwarzania danych w oparciu o które funkcjonuje platforma jest zgodne z normą ISO 27001 oraz jest zlokalizowane na terytorium UE. |
14. | Komunikacja pomiędzy użytkownikiem a serwerem realizowana jest z wykorzystaniem bezpiecznego protokołu SSL. |
15. | Platforma pozwala na dodawanie osób upoważnionych do odbioru dziecka zarówno z poziomu konta opiekuna prawnego w ramach aplikacji mobilnej. |
16. | Platforma umożliwia wprowadzenie szczegółowych danych dotyczących dziecka: • Zadeklarowane godziny obecności • Zalecenia lekarskie • Uczulenia na pokarmy • Uczulenia na ukąszenia owadów • Uwagi • Zgody • Zaświadczenia • Schematy płatności • Zdjęcie • Dowolne załączniki • Opiekunowie prawni • Osoby upoważnione do odbioru • Obecności, nieobecności • Liczba dni płatnych • Czas pobytu |
17. | Platforma pozwala na rejestrację wejść i wyjść z wykorzystania kart zbliżeniowych lub mechanizm PINów lub innych mechanizm dla opiekunów prawnych, osób odbierających. |
18. | Odbiór dziecka w placówce sygnalizowany jest wiadomością PUSH po stronie opiekuna prawnego bezpośrednio w aplikacji mobilnej. |
19. | Platforma pozwala na prowadzenie kalendarza wydarzeń z możliwością wyświetlania go z poziomu aplikacji mobilnej. Wydarzenia mogą być przypisywanie do wybranych grup lub dzieci. |
20. | Platforma pozwala na tworzenie tablicy ogłoszeń z możliwością wyświetlania jej z poziomu aplikacji mobilnej (w tym powiadomienia PUSH). |
21. | Platforma pozwala na dodawanie zdjęć, załączników do ogłoszeń i wyświetlanie ich z poziomu aplikacji mobilnej. |
22. | Platforma pozwala na zgłaszanie posiłków z poziomu aplikacji mobilnej. |
23. | Platforma pozwala na przeglądanie historii obecności również po stronie rodzica w aplikacji mobilnej. |
24. | Platforma pozwala na zgłaszanie nieobecności dzieci i ich wycofywanie z poziomu aplikacji mobilnej rodzica. |
25. | Platforma pozwala na odłączanie dzieci od grup oraz ich archiwizację. Musi pozwalać na podgląd rozliczeń zarchiwizowanych. |
26. | Platforma pozwala na generowanie rozliczeń zarówno dla dzieci jak i nauczycieli. |
27. | Platforma pozwala na definiowanie uniwersalnych schematów płatności z indywidulanym numerem konta (wyżywienie, pobyt, rada rodziców, zajęcia dodatkowe, opłaty jednorazowe). Musi być możliwość automatycznego i ręcznego przypinania/odpinania schematów płatności do profilu dziecka. |
28. | Platforma obsługuje różne mechanizmy naliczania opłat (z góry, z dołu z uwzględnieniem rabatów i ulg, płatności jednorazowe, rada rodziców). Każda ze schematów płatności może mieć różne numery kont bankowych. |
29. | Platforma umożliwia obsługę 6-latków polegającą na nieodpłatnym pobycie w placówce. |
30. | Platforma umożliwia definiowanie dowolnych ulg. |
31. | Platforma umożliwia definiowanie godzin płatnych i bezpłatnych. |
32. | Platforma pozwala na definiowanie dowolnych szablonów numeracji dla kwitariuszy. |
33. | Platforma pozwala na generowanie raportów niezbędnych do rozliczeń z Jednostką nadrzędną (w formacie pdf i xls lub xml oraz w przypadku takiej możliwości integracji). Raport xls musi pozwalać na wygenerowanie następujących danych: Imię, Nazwisko, poprzednia zaległość, należność bieżąca, odpis, odsetki, ulgi, wpłata przelewem, online, data wpłaty, nadpłaty, wypłaty, opiekun prawny. |
34. | Platforma obsługuję wpłaty gotówkowe, zwykłe przelewy, nadpłaty, wypłaty w kasie wraz z raportowaniem. |
35. | Platforma integruje się z modułem bramki płatności elektronicznych pozwalając na wnoszenie opłat za pomocą Pay-by-Link oraz BLIK (w aplikacji mobilnej oraz w wersji WWW). Zasady pobierania prowizji zostaną ustalone z wykonawcą na etapie realizacji Zamówienia. |
36. | Platforma pozwala na definiowanie dostępu do raportów w zależności od roli. |
37. | Platforma pozwala na definiowanie dni wolnych we wbudowanym kalendarzu. |
38. | Z poziomu platformy istnieje możliwość dwukierunkowej komunikacji bezpośrednio z opiekunem prawnym (dedykowany kanał komunikacji)- chat. |
39. | Platforma posiada dedykowaną wielojęzyczną (polski, angielski, ukraiński) aplikację mobilną dostępną do pobrania w sklepie Google Play i App Store na dzień złożenia oferty. |
40. | Platforma pozwala na generowania kwitariuszy oraz raportów prezentujących planowaną liczbę dzieci w placówce oraz liczbę dzieci ze specjalną dietą. |
41. | Platforma umożliwia dodawanie skanów umów i innych dokumentów bezpośrednio z poziomu konta użytkownika. |
42. | Pozwala na definiowanie dowolnych atrybutów powiązanych z profilem dziecka. |
43. | Platforma posiada funkcjonalności dziennik elektronicznego. |
Płatności za obiady | |
44. | System dający możliwość dokonywania płatności on–line za wyżywienie dzieci w szkołach i przedszkolach, oraz wszelkich innych opłat związanych z publicznymi szkołami i przedszkolami |
45. | Automatyczne rozliczanie należności za posiłki – ewidencjonowanie i naliczanie posiłków dla dzieci. |
46. | Uwzględnianie dofinansowań do posiłków – naliczanie posiłków zgodnie ze zdefiniowanymi w systemie dofinansowaniami – kwotowe lub procentowe. |
47. | Rejestracja wpłat za posiłki dokonanych przez opiekunów dzieci |
48. | Automatyczne naliczanie odsetek – w zależności od terminu wpłaty przez opiekuna opłat za posiłki. |
49. | Dostęp do danych poprzez przeglądarkę internetową – możliwość łatwego, szybkiego i wygodnego przeglądania informacji o dzieciach. |
50. | Portal dedykowany placówkom, dzieciom oraz ich opiekunom, dający dostęp do zasobów informacyjnych systemu. |
4.2.4 Modernizacja systemów dziedzinowych
W ramach zamówienia zakłada się modernizację lub wymianę Systemów Dziedzinowych wykorzystywanych w Urzędzie Gminy, która ma w celu umożliwienie funkcjonowania Portalu Systemu i świadczenie zakładanych e-usług publicznych. Będą to Systemy Dziedzinowe wspomagające pracę Urzędu zgodnie z wykonywanymi zadaniami i stanowiskami pracowniczymi. Funkcjonalności Systemów dziedzinowych powinny być pogrupowane w moduły oprogramowania, przy czym każdy z modułów wspomaga realizację pewnej wydzielonej grupy zadań zgodnie ze strukturą organizacyjną Urzędu Gminy.
W ramach Zamówienia wymagana jest modernizacja lub wymiana systemów dziedzinowych działających wewnątrz Urzędu (w zakresie podanym poniżej). Elektroniczne usługi publiczne, które dostarczają informacje zarówno ogólne, czy też spersonalizowane wymagają rozwinięcia funkcjonalności dotychczas użytkowanych systemów. Dojrzałe usługi elektroniczne, których wykonanie jest założone w projekcie muszą bazować na aktualnych danych przy zapewnieniu bezpieczeństwa i integralności wykorzystywanych danych.
Zamawiający nie posiada autorskich praw majątkowych do funkcjonującego w urzędzie oprogramowania, nie posiada kodów źródłowych oprogramowania, a licencja posiadanego oprogramowania nie umożliwia mu modyfikacji kodów źródłowych, zatem Zamawiający nie jest w stanie zapewnić Wykonawcy, że udostępni mu stałe, niezmienne interfejsy integracyjne umożliwiające pełną wymianę danych z nowo uruchamianymi rozwiązaniami.
Zamawiający dopuszcza wymianę obecnie posiadanych systemów dziedzinowych na systemy spełniające poniżej opisane funkcjonalności konieczne do świadczenia e-usług na min. 4 poziomie dojrzałości.
4.2.4.1 System Podatków i Opłat Lokalnych (SPiOL) i inne
Podatek od Nieruchomości, Rolny i Leśny (PNRL)
Lp. | Opis minimalnych wymagań: |
1. | PNRL musi umożliwiać zarejestrowanie kart podatników z uwzględnieniem: podatników (osoby fizyczne, małżeństwa, podmioty grupowe tzn. wiele osób fizycznych), pełnomocników podatników, właściciel i współwłaścicieli, adresów gospodarstw, przedmiotów opodatkowania (grunty, lasy, nieruchomości), dodatkowych informacji o przedmiocie opodatkowania np. informacji o działkach, budynkach, lokalach, dokumentach własności. |
2. | PNRL musi umożliwiać rejestrowanie zmian - zbywanie/nabywanie przedmiotów opodatkowania w trakcie roku z możliwością kopiowania wszystkich lub wybranych przedmiotów opodatkowania między kartami podatników. |
3. | PNRL musi umożliwiać podział kont na 13 obrębów zgodnie z Rejestrem Gruntów i Budynków Starostwa Powiatowego w Pruszkowie. |
4. | PNRL musi umożliwiać wprowadzenie ulg i zwolnień podmiotowych i przedmiotowych wynikających z prawa krajowego i lokalnego. |
5. | PNRL musi umożliwiać naliczanie podatku rolnego, leśnego i od nieruchomości na podstawie stanu posiadania podatnika oraz naliczanie zmian w podatku w trakcie roku na skutek zmian stanu posiadania. |
6. | PNRL musi umożliwiać wystawianie i wydruk decyzji (lub decyzji zmieniającej do wcześniej wydanej) w sprawie wymiaru podatku rolnego, leśnego, od nieruchomości lub łącznego zobowiązania pieniężnego. |
7. | PNRL musi umożliwiać wygenerowanie i wydruk decyzji pierwotnej i korygującej za lata ubiegłe dla podatku rolnego, leśnego, od nieruchomości oraz łącznego zobowiązania pieniężnego. |
8. | PNRL musi umożliwiać księgowanie decyzji podatkowych z datą doręczenia. |
9. | PNRL musi umożliwiać zawężenie wydruku decyzji wymiarowych przy pomocy zdefiniowanych filtrów: adres zamieszkania/korespondencyjny, adres położenia, sołectwo/rejon, wielkość podatku, rodzaje podatku. |
10. | PNRL musi umożliwiać sortowanie wydruku decyzji wymiarowych według: adresu położenia gospodarstwa, adresu zamieszkania/korespondencyjnego podatnika, podatnika. |
11. | PNRL musi dawać możliwość wyboru zakresu i kolejności wydruku decyzji wymiarowych: decyzja, dowód wpłaty, potwierdzenie odbioru (w jednym ciągu dla danego podatnika). |
12. | PNRL musi pozwalać na drukowanie blankietów potwierdzenia odbioru decyzji, blankietów umożliwiających przelew w banku lub na poczcie, blankietów umożliwiających wpłaty podatku w kasie urzędu, nalepek na potwierdzenie odbioru. |
13. | PNRL musi umożliwiać odnotowanie daty doręczania decyzji o wysokości należnego zobowiązania pieniężnego (w trybie indywidualnym i masowym). |
14. | PNRL musi umożliwiać wykonywanie symulowanych naliczeń na podstawie bazy podatkowej Urzędu z uwzględnieniem stawek ustawowych, gminnych oraz trzech wariantów stawek symulacyjnych. |
15. | PNRL musi umożliwiać obliczenie skutków udzielonych przez Urząd ulg i zwolnień. |
16. | PNRL musi umożliwiać obliczenie skutków obniżenia górnych stawek podatkowych. |
17. | PNRL musi umożliwiać prezentację skutków ulg i zwolnień według rodzajów należności. |
18. | PNRL musi umożliwiać wprowadzenie informacji o działkach dla poszczególnych składników opodatkowania (nr działki, obręb, nr księgi wieczystej, nr jednostki rejestrowej). |
19. | PNRL musi umożliwiać wyszukiwanie według nr kartotek podatników, imion i nazwisk podatników oraz według nr działek, obrębów, jednostki rejestrowej, nr decyzji itp. |
20. | PNRL musi umożliwiać obsługę pełnomocników podatników z możliwością wystawienia decyzji na pełnomocników. |
21. | PNRL musi umożliwiać obsługę kartotek podatników – osób prawnych. |
22. | PNRL musi umożliwiać wydruk wezwania w sprawie złożenia informacji/deklaracji, postanowienia o zapoznaniu się z aktami sprawy, postanowienia o wszczęciu postępowania podatkowego. |
23. | PNRL musi umożliwiać obsługę deklaracji i deklaracji korygujących składanych przez podatników z uwzględnieniem: danych o podatnikach, przedmiotów opodatkowania, ulgach w podatku, adresów nieruchomości, danych o nieruchomościach i działkach. |
24. | PNRL musi umożliwiać naliczenie podatku na podstawie składników deklaracji. |
25. | PNRL musi umożliwiać prowadzenie oraz wydruk ewidencji wydanych decyzji. |
26. | PNRL musi współpracować z czytnikami kodów kreskowych i umożliwiać drukowanie decyzji z kodem kreskowym. |
27. | PNRL musi posiadać możliwość wygenerowania indywidualnych numerów kont bankowych i wysłania odpowiednich zawiadomień do podatników. |
28. | PNRL musi automatycznie przenosić na nowy rok podatkowy przedmioty opodatkowania z deklaracji na podstawie stanu w roku poprzednim do weryfikacji. |
29. | PNRL musi umożliwiać wygenerowanie: zestawienia wydanych decyzji, zestawienia gospodarstw, zestawienia nieruchomości, zestawienia ulg w nieruchomościach, zestawienia działek, zestawienia budynków, zestawienia lokali, rejestru wymiarowego, zestawienia podatników. |
30. | PNRL musi umożliwiać dokonywanie przypisów, odpisów oraz nanoszenie nadpłat bezpośrednio na kontach syntetycznych księgi głównej, ewidencji księgowej urzędu. |
31. | PNRL musi wykorzystywać istniejące urzędowe rejestry TERYT w powiązaniu z bazą PAN (podpowiadany kod pocztowy w zależności od adresu: miejscowość, ulica lub numer domu) i SWDE. |
32. | PNRL musi posiadać wbudowaną bazę niezbędnych słowników, która umożliwia wielokrotne wykorzystywanie i modyfikowanie raz wprowadzonych do systemu danych. |
33. | PNRL ma mieć możliwość edycji treści wystawianych zaświadczeń. |
34. | PNRL musi umożliwiać eksport danych podatkowych do pliku XML. |
35. | PNRL musi umożliwiać wystawianie zaświadczeń o wielkości gospodarstwa rolnego. |
36. | PNRL musi umożliwiać identyfikację i weryfikację podatników min. po numerze NIP, REGON, PESEL. |
37. | PNRL musi umożliwiać identyfikację przedmiotów opodatkowania wykorzystując: nr działki, nr budynku, nr lokalu. |
38. | PNRL musi umożliwiać wydruk spisu członków izby rolniczej uprawnionych do głosowania. |
39. | PNRL musi umożliwiać wydruk rejestru przypisów i odpisów. |
40. | W zakresie podatku rolnego i leśnego oraz łącznego zobowiązania pieniężnego moduł musi automatycznie określać stawki właściwe dla podatku rolnego (w zależności od wielkości opodatkowanych gruntów). |
41. | PNRL musi pozwalać na wprowadzenie aktualnych stawek podatku na podstawie uchwały rady. |
42. | PNRL musi umożliwiać eksport danych widocznych na ekranie do arkusza kalkulacyjnego. |
43. | PNRL musi rejestrować zmiany danych osobowych wraz z wizualizacją zmienianych danych |
44. | PNRL musi umożliwiać zwiększenie liczby gromadzonych informacji na poziomie różnych obiektów (podatnik, konto podatkowe, nieruchomość, działka, budynek, lokal) wykorzystujące definiowalne przez użytkownika atrybuty/cechy (umożliwiając określenie ich wymagalności, użycia słowników), wraz z ich późniejszym wyświetleniem na zestawieniach |
45. | PNRL musi umożliwiać wykorzystanie adresu korespondencyjnego kontrahenta w kontekście każdego konta podatnika |
Podatek od Środku Transportowego (PŚT)
Lp. | Opis minimalnych wymagań: |
1. | PŚT musi umożliwiać obsługę kartotek podatników podatku od środków transportu. |
2. | PŚT musi umożliwiać obsługę deklaracji i deklaracji korygujących składanych przez podatników z uwzględnieniem danych o podatnikach, posiadanych pojazdach oraz ulgach w podatku. |
3. | PŚT musi umożliwiać naliczenie podatku na podstawie składanych deklaracji. |
4. | PŚT musi umożliwiać rejestrowanie zmian - zbywanie/nabywanie przedmiotów opodatkowania w trakcie roku. |
5. | PŚT musi umożliwiać prowadzenie ewidencji pojazdów. |
6. | PŚT musi umożliwiać w zależności od potrzeb użytkownika, wyszukiwanie informacji o pojazdach i właścicielach według różnych kryteriów. |
7. | PŚT musi umożliwiać wykonywanie symulowanych naliczeń na podstawie bazy podatkowej Urzędu z uwzględnieniem stawek ustawowych, gminnych oraz trzech wariantów stawek symulacyjnych. |
8. | PŚT musi umożliwiać obliczenie skutków udzielonych przez Urząd ulg i zwolnień. |
9. | PŚT musi umożliwiać obliczenie skutków obniżenia górnych stawek podatkowych. |
10. | PŚT musi współpracować z czytnikami kodów kreskowych. |
11. | PŚT ma posiadać możliwość wygenerowania indywidualnych numerów kont bankowych i wysłania odpowiednich zawiadomień do podatników. |
12. | PŚT musi automatycznie przenosi na nowy rok podatkowy przedmioty opodatkowania z deklaracji na podstawie stanu w roku poprzednim do weryfikacji. |
13. | PŚT musi umożliwiać dokonywanie przypisów, odpisów oraz nanoszenie nadpłat bezpośrednio na kontach syntetycznych księgi głównej, ewidencji księgowej urzędu. |
14. | PŚT ma być zintegrowany z Rejestr mieszkańców. |
15. | PŚT ma wykorzystywać istniejący urzędowy rejestr TERYT w powiązaniu z bazą PAN (podpowiadany kod pocztowy w zależności od adresu: miejscowość, ulica lub numer domu). |
16. | PŚT ma umożliwiać identyfikację i weryfikację podatników po numerze NIP, REGON, PESEL. |
17. | PŚT ma umożliwiać wydruk rejestru przypisów i odpisów. |
18. | PŚT ma posiadać wbudowaną bazę niezbędnych słowników, która umożliwia wielokrotne wykorzystywanie i modyfikowanie raz wprowadzonych do systemu danych. |
19. | PŚT ma pozwalać na wprowadzenie aktualnych stawek podatku na podstawie uchwały rady. |
20. | PŚT ma posiadać możliwość wprowadzenia czasowego wycofania pojazdu z ruchu. |
21. | PŚT ma umożliwiać eksport danych widocznych na ekranie do arkusza kalkulacyjnego. |
22. | PŚT ma rejestrować zmiany danych osobowych wraz z wizualizacją zmienianych danych. |
23. | PŚT ma umożliwiać zwiększenie liczby gromadzonych informacji na poziomie różnych obiektów (podatnik, konto podatkowe, pojazd) wykorzystujące definiowalne przez użytkownika atrybuty/cechy (umożliwiając określenie ich wymagalności, użycia słowników), wraz z ich późniejszym wyświetleniem na zestawieniach. |
24. | PŚT ma umożliwiać wykorzystanie adresu korespondencyjnego kontrahenta w kontekście każdego konta podatnika. |
Podatek Akcyzowy (PA)
Lp. | Opis minimalnych wymagań: |
1. | PA ma umożliwiać obliczanie limitu zwrotów za cały rok i I transzę. |
2. | PA ma umożliwiać drukowanie decyzji (w tym możliwość generowania i dostarczania decyzji drogą elektroniczną) wg wzorów I transza, II transza, zgodnych z ustawą o zwrocie podatku akcyzowego. |
3. | PA ma umożliwiać raportowanie zestawień wypłat z podziałem na wypłaty w gotówce oraz przelewy na wskazany rachunek bankowy. |
4. | PA ma wykorzystywać istniejący urzędowy rejestr TERYT w powiązaniu z bazą PAN (podpowiadany kod pocztowy w zależności od adresu: miejscowość, ulica lub numer domu). |
5. | PA ma posiadać wbudowaną bazę niezbędnych słowników, która ma umożliwiać wielokrotne wykorzystywanie i modyfikowanie raz wprowadzonych do systemu danych. |
6. | PA ma umożliwiać zawężenie wydruku decyzji przy pomocy zdefiniowanych filtrów: adres zamieszkania, wielkość podatku, rodzaje podatku. |
7. | PA ma umożliwiać sortowanie wydruku decyzji wymiarowych według: adresu zamieszkania podatnika, podatnika. |
8. | PA ma umożliwiać generowanie następujących sprawozdań: Okresowe rozliczenie dotacji celowej z realizacji wypłat, Okresowe sprawozdanie rzeczowo-finansowe z realizacji wypłat, Roczne rozliczenie dotacji celowej z realizacji wypłat, Roczne sprawozdanie rzeczowo- |
finansowe z realizacji wypłat, Sprawozdanie o udzielonej pomocy publicznej w rolnictwie lub rybołówstwie. | |
9. | PA ma umożliwiać sporządzenia wniosku o przekazanie gminie dotacji celowej. |
10. | PA ma umożliwiać generowanie przelewów do systemu bankowego. |
11. | PA ma umożliwiać generowanie zbiorczego zestawienia dotyczące rozdysponowania i przekazania dotacji. |
12. | PA ma umożliwiać wykorzystanie adresu korespondencyjnego kontrahenta w kontekście każdego konta podatnika |
Opłata za gospodarowania odpadami komunalnymi (OGOK)
Lp. | Opis minimalnych wymagań: |
1. | OGOK musi umożliwiać prowadzenie ewidencji danych adresowych, o właścicielach, istniejących urządzeniach, np. zbiornikach bezodpływowych, przydomowych oczyszczalniach ścieków, po nadanych ID. |
2. | OGOK musi umożliwiać rejestrację deklaracji dotyczących opłat za gospodarowanie odpadami komunalnymi. |
3. | OGOK musi umożliwiać wprowadzenie następujących informacji zawartych w deklaracji składanej przez zobowiązanego: nr działki nieruchomości, liczba zamieszkujących osób, zużycie wody, powierzchnia lokalu, liczba i rodzaj pojemników na odpady, informacja o segregowaniu odpadów. |
4. | OGOK musi umożliwiać wyszukiwanie według nr kartotek zobowiązanych, imion i nazwisk zobowiązanych, grup, udzielonych ulgach itp. |
5. | OGOK musi umożliwiać obsługę deklaracji nowych i korygujących składanych przez zobowiązanych (właścicieli nieruchomości) + składanie deklaracji przez ePUAP. |
6. | OGOK musi umożliwiać naliczenie opłaty na podstawie składanych deklaracji. |
7. | OGOK musi posiadać możliwość wygenerowania indywidualnych numerów kont bankowych i wysłania odpowiednich zawiadomień do podatników. |
8. | OGOK musi umożliwiać dokonywanie przypisów, odpisów oraz nanoszenie nadpłat bezpośrednio na kontach syntetycznych księgi głównej, ewidencji księgowej urzędu. |
9. | OGOK musi umożliwiać zmianę stawek w ciągu roku, wraz z obsługą procesu powiadomienia właścicieli o nowej stawce opłaty i zmianie wysokości opłaty. |
10. | OGOK musi umożliwiać zdefiniowanie przyznanych ulg i dopłat (na KDR, Kompostownik i GOPS i innych). |
11. | OGOK musi umożliwiać obliczenie skutków udzielonych przez Urząd ulg i zwolnień. |
12. | OGOK musi generować zestawienia sald i wpłat po kontach dla każdego właściciela indywidualnie. |
13. | OGOK musi wykorzystywać istniejący urzędowy rejestr TERYT w powiązaniu z bazą PAN (podpowiadany kod pocztowy w zależności od adresu: miejscowość, ulica lub numer domu). |
14. | OGOK musi posiadać wbudowaną bazę niezbędnych słowników, która umożliwia wielokrotne wykorzystywanie i modyfikowanie raz wprowadzonych do systemu danych. |
15. | OGOK musi umożliwiać identyfikację i weryfikację zobowiązanych po numerze NIP, REGON, PESEL. |
16. | OGOK musi umożliwiać wygenerowanie: Rejestru decyzji, upomnień, umorzeń, przedawnień. |
17. | OGOK musi umożliwiać wydruk rejestru przypisów i odpisów. |
18. | OGOK musi pozwalać na wprowadzenie aktualnych stawek opłaty za gospodarowanie odpadami na podstawie uchwały Rady Gminy Michałowice wraz z oznaczeniem terminu ich obowiązywania. |
19. | OGOK musi posiadać możliwość wspomagania weryfikacji deklaracji wraz z możliwością korygowania danych i wprowadzania nowych, ujawnionych i zweryfikowanych danych. |
20. | OGOK musi rejestrować zmiany danych osobowych wraz z wizualizacją zmienianych danych |
21. | OGOK musi umożliwiać zwiększenie liczby gromadzonych informacji na poziomie różnych obiektów (podatnik, konto podatkowe, nieruchomość, składnik opodatkowania) wykorzystujące definiowalne przez użytkownika atrybuty/cechy (umożliwiając określenie ich wymagalności, użycia słowników), wraz z ich późniejszym wyświetleniem na zestawieniach |
22. | OGOK musi umożliwiać rejestrację przedsiębiorców prowadzących działalność w obrębie instalacji przetwarzania odpadów, punktów selektywnego zbierania odpadów, stacji zlewnych. |
23. | OGOK musi umożliwiać rejestrację informacji o właścicielach i nieruchomościach posiadających przydomowe oczyszczalnie ścieków lub zbiorniki bezodpływowe. |
24. | OGOK musi umożliwiać prowadzenie ewidencji wpisów do rejestru działalności regulowanej w obrębie odbierania odpadów komunalnych od właścicieli nieruchomości. |
25. | OGOK musi umożliwiać prowadzenie rejestru zezwoleń na opróżnianie zbiorników bezodpływowych, transport nieczystości ciekłych, ochrony przed bezdomnymi zwierzętami, schronisk dla zwierząt. |
26. | OGOK musi umożliwiać rejestrację kwartalnych i półrocznych sprawozdań podmiotów odbierających odpady komunalne oraz podmiotów prowadzących działalność w zakresie opróżniania zbiorników bezodpływowych i transportu nieczystości ciekłych. |
27. | OGOK musi umożliwiać prowadzenie ewidencji danych o miejscach gromadzenia odpadów: instalacja, składowisko, stacja zlewna, punkt selektywnej zbiórki. |
28. | OGOK powinien mieć możliwość wygenerowania raportów do porównania wykazanej w Deklaracjach liczby mieszkańców ze zużyciem wody i danymi z systemu Rekrutacji do szkół i przedszkoli. |
29. | Program musi być dostoswany do obowiązującej na terenie Gminy Michałowice deklaracji za gospodarowanie odpadami komunalnymi, uchwalonej przez Radę Gminy Michałowice. |
Obsługa Dzierżawy (OD)
Lp. | Opis minimalnych wymagań: |
1. | OD musi umożliwiać obsługę umów dzierżaw i najmu poprzez utworzenie kart kontowych płatników. |
2. | OD musi pozwalać na wprowadzenie informacji dotyczących umów dzierżawnych i dzierżawionych nieruchomości. |
3. | OD musi pozwalać na wprowadzenie informacji dotyczących dzierżawców w trybie ręcznym oraz poprzez wykorzystanie danych słownikowych. |
4. | OD musi posiadać wbudowaną bazę niezbędnych słowników, która umożliwia wielokrotne wykorzystywanie i modyfikowanie raz wprowadzonych do systemu danych. |
5. | OD musi pozwalać na naliczanie opłat na każdy rok. |
6. | OD musi wykorzystywać istniejący urzędowy rejestr TERYT w powiązaniu z bazą PAN (podpowiadany kod pocztowy w zależności od adresu: miejscowość, ulica lub numer domu). |
7. | OD musi umożliwiać dokonywanie przypisów, odpisów oraz nanoszenie nadpłat bezpośrednio na kontach syntetycznych księgi głównej, ewidencji księgowej urzędu. |
8. | OD musi umożliwiać wyszukiwanie płatnika min. wg następujących kryteriów: nazwiska, imienia, adresu zamieszkania, numeru PESEL, NIP, REGON, adresu nieruchomości (działki), numeru jednostki rejestrowej, numeru działki, obrębu, księgi wieczystej, numeru karty kontowej. |
9. | OD musi umożliwiać wydruk rejestru przypisów i odpisów. |
10. | OD musi pozwalać na wprowadzenie aktualnych stawek czynszu najmu i dzierżawy na podstawie uchwały rady. |
11. | OD musi posiadać możliwość wygenerowania indywidualnych numerów kont bankowych i wysłania odpowiednich zawiadomień do podatników. |
12. | OD musi umożliwiać eksport danych widocznych na ekranie do arkusza kalkulacyjnego. |
13. | OD musi rejestrować zmiany danych osobowych wraz z wizualizacją zmienianych danych |
14. | OD musi umożliwiać zwiększenie liczby gromadzonych informacji na poziomie różnych obiektów (podatnik, konto podatkowe, składnik opodatkowania) wykorzystujące definiowalne przez użytkownika atrybuty/cechy (umożliwiając określenie ich wymagalności, użycia słowników), wraz z ich późniejszym wyświetleniem na zestawieniach |
15. | OD musi umożliwiać wykorzystanie adresu korespondencyjnego kontrahenta w kontekście każdego konta podatnika |
Obsługa Wieczystego Użytkowania (OWU)
Lp. | Opis minimalnych wymagań: |
1. | OWU musi umożliwiać obsługę umów użytkowania wieczystego poprzez utworzenie kart kontowych płatników. |
2. | OWU musi umożliwiać prowadzenie umów w powiązaniu z danymi pochodzącymi z ewidencji gruntów |
3. | OWU musi umożliwiać wprowadzenie informacji dotyczących użytkowników z możliwością wykorzystania informacji z Rejestrem mieszkańców. |
4. | OWU musi umożliwiać wydruk informacji o wysokości opłaty za użytkowanie wieczyste. |
5. | OWU musi umożliwiać wprowadzenie ulg i bonifikat od opłaty z tytułu użytkowania wieczystego. |
6. | OWU musi umożliwiać wyszukiwanie użytkownika wieczystego min. wg następujących kryteriów: nazwiska, imienia, adresu zamieszkania, numeru PESEL, NIP, XXXXX, adresu nieruchomości (działki), numeru jednostki rejestrowej, numeru działki, obrębu, księgi wieczystej, numeru karty kontowej. |
7. | OWU musi wykorzystywać istniejący urzędowy rejestr TERYT w powiązaniu z bazą PAN (podpowiadany kod pocztowy w zależności od adresu: miejscowość, ulica lub numer domu). |
8. | OWU musi umożliwiać dokonywanie przypisów, odpisów oraz nanoszenie nadpłat bezpośrednio na kontach syntetycznych księgi głównej, ewidencji księgowej urzędu. |
9. | OWU musi umożliwiać generowanie faktur VAT. |
10. | OWU umożliwia wydruk rejestru przypisów i odpisów. |
11. | OWU musi posiadać możliwość wygenerowania indywidualnych numerów kont bankowych i wysłania odpowiednich zawiadomień do podatników. |
12. | OWU musi umożliwiać rozliczenie opłaty rocznej w przypadku w przypadku zbycia prawa użytkowania wieczystego w ciągu roku. |
13. | OWU musi umożliwiać eksport danych widocznych na ekranie do arkusza kalkulacyjnego. |
14. | OWU musi rejestrować zmiany danych osobowych wraz z wizualizacją zmienianych danych |
15. | OWU musi umożliwiać zwiększenie liczby gromadzonych informacji na poziomie różnych obiektów (podatnik, konto podatkowe, składnik opodatkowania) wykorzystujące definiowalne przez użytkownika atrybuty/cechy (umożliwiając określenie ich wymagalności, użycia słowników), wraz z ich późniejszym wyświetleniem na zestawieniach |
16. | OWU musi umożliwiać wykorzystanie adresu korespondencyjnego kontrahenta w kontekście każdego konta podatnika |
Obsługa Księgowości i Windykacji Podatkowej (OKiWP)
Lp. | Opis minimalnych wymagań: |
1. | OKIWP musi umożliwiać obsługę procesu rejestrowania i rozliczania należności z tytułu różnych podatków i opłat dokonywanych przez zobowiązanych na rzecz urzędu. |
2. | OKIWP musi umożliwiać rejestrację operacji finansowych (wpłaty, zwroty, przeksięgowania, nadpłaty, kwoty do wyjaśnienia) i rozliczenia tych operacji na kartotekach płatników. |
3. | OKIWP musi umożliwiać obsługę decyzji o umorzeniu zaległości oraz o rozłożeniu płatności na raty. |
4. | OKIWP musi umożliwiać obsługę decyzji o wygaszeniu w całości rat decyzji o odroczeniu lub rozłożeniu płatności na raty. |
5. | W oparciu o bazę podatników prowadzoną w Urzędzie, moduł musi umożliwiać uzyskanie informacji oraz wydanie zaświadczenia o zaleganiu lub niezaleganiu w płatnościach, osoby wnioskującej o zaświadczenie. |
6. | OKIWP musi współpracować z czytnikami kodów kreskowych i umożliwiać drukowanie upomnień i wezwań do zapłaty z kodem kreskowym do odczytania przez pozostałe moduły oraz mieć możliwość wygenerowania tych dokumentów elektronicznie i dostarczenia ich drogą elektroniczną. |
7. | OKIWP musi umożliwiać automatyczne rozdysponowanie wpłaconej przez podatnika kwoty według przepisu art. 55 § 2 – ustawy – Ordynacja podatkowa. |
8. | OKIWP musi umożliwiać rejestrowanie wpłat z podpowiedzią odsetek w przypadku wpłat po terminie. |
9. | OKIWP musi umożliwiać prowadzenie tzw. “miękkiej“ windykacji (np. w postaci powiadomień SMS). |
10. | OKIWP musi umożliwiać obsługę upomnień oraz wezwań do zapłaty (wystawianie, wydruk, prowadzenie rejestru). |
11. | OKIWP musi umożliwiać drukowanie nalepek dla adresatów upomnień i wezwań do zapłaty wraz z kodem kreskowym. |
12. | OKIWP musi umożliwiać anulowanie upomnienia lub wezwania do zapłaty i kosztów związanych z jego wystawieniem. |
13. | OKIWP musi umożliwiać wystawienie upomnień oraz wezwań do zapłaty pojedynczo lub masowo. |
14. | OKIWP musi umożliwiać wystawienie upomnienia lub wezwania do zapłaty na wybrany dzień księgowy oraz na dowolną liczbę należności. |
15. | OKIWP musi umożliwiać dobór należności dla wystawianych upomnień w oparciu o kryteria czasowe (liczba miesięcy od powstania należności) oraz kryteria kwotowe (saldo pojedynczego rozrachunku lub sumarycznej kwoty na poziomie konta podatnika) |
16. | OKIWP musi umożliwiać naliczanie odsetek dla należności w upomnieniu i wezwaniu do zapłaty na dowolnie wskazany dzień. |
17. | OKIWP musi generować informacje o niezapłaconych kosztach i kwocie należności, jaka pozostała jeszcze do zapłacenia zarówno dla upomnień jak i wezwań do zapłaty. |
18. | OKIWP musi umożliwiać przypisywanie kosztów upomnienia w momencie zarejestrowania daty doręczenia upomnienia lub w momencie dokonania wpłaty na należność objętą doręczonym upomnieniem. |
19. | OKIWP musi umożliwiać rejestrowanie dat doręczenia dla upomnień i wezwań do zapłaty z wykorzystaniem kodów kreskowym przy wyszukiwaniu dokumentu. |
20. | OKIWP podczas rejestracji wpłaty, musi podpowiadać kwotę kosztów upomnienia lub wezwania do zapłaty - użytkownik ma możliwości zdecydowania, czy koszty mają zostać rozliczone. |
21. | OKIWP musi umożliwiać obsługę tytułów wykonawczych (wystawianie - na poszczególne rodzaje należności, wydruk tytułu wykonawczego, rejestry/ewidencja). |
22. | OKIWP musi umożliwiać prowadzenie elektronicznej ewidencji tytułów wykonawczych z uwzględnieniem min. następujących elementów: a. numer tytułu wykonawczego, b. status tytułu wykonawczego, c. zobowiązanego, d. data wystawienia tytułu, e. rok wystawienia tytułu, f. identyfikatora użytkownika systemu wystawiającego tytuł wykonawczy, |
x. xxxxx sumy należności, na którą został wystawiony tytuł wykonawczy. | |
23. | OKIWP musi mieć możliwość tworzenia nowego tytułu do istniejącego już tytułu przy użyciu form: a. zmieniony tytuł wykonawczy, b. dalszy tytuł wykonawczy, x. xxxxxxx tytuł wykonawczy |
24. | Dla tytułu wykonawczego musi być możliwość wydrukowania wniosku o umorzenie oraz zawiadomienia o zmianie należności. |
25. | OKIWP powinien umożliwiać oznaczenie tytułów wykonawczych statusami odpowiadającymi etapom postępowania egzekucyjnego, w szczególności: a. aktualny, b. umorzenie, c. zwrot z organu, d. zrealizowany, e. zbieg egzekucji, x. xxxxxxxxxxx, g. zawieszony, h. wycofany. |
26. | OKIWP musi umożliwiać prowadzenie ewidencji tytułów wykonawczych, pozwalającą na wyszukanie tytułów wykonawczych w oparciu min. o następujące kryteria: a. stopień zaspokojenia (zapłacone całkowicie lub częściowo, niezapłacone), b. status tytułu, c. data wystawienia, d. imieniu, nazwisku, nr PESEL, nr NIP, adresu zobowiązanego, e. kwocie należności, f. numerze tytułu wykonawczego. |
27. | OKIWP musi umożliwiać obsługę należności zahipotekowanych i długoterminowych. |
28. | W systemie musi być umożliwienie rejestrowania wpłaty od dowolnej osoby (lub osób) na należności innych osób lub osoby (zapamiętanie informacji, kto płaci i za kogo płaci). |
29. | OKIWP musi umożliwiać obsługę opłaty prolongacyjnej. |
30. | OKIWP musi umożliwiać określenie daty, do której należy liczyć odsetki w związku z rozpoczęciem postępowania wobec podatnika i jego zobowiązań w celu zabezpieczenia należności przed przedawnieniem. |
31. | OKIWP musi umożliwiać obsługę płatności masowych realizowanych za pośrednictwem banku poprzez automatyczne rozksięgowanie przelewów z indywidualnych kont bankowych. |
32. | OKIWP musi współpracować z platformą biura obsługi interesanta. |
33. | OKIWP musi umożliwiać wykonywanie masowych przeksięgowań. |
34. | OKIWP musi umożliwiać analizę danych (przypisów, odpisów, wpłat, zwrotów, stanów rozrachunków) w oknie programu z uwzględnieniem min. następujących parametrów: a. rodzaju należności, b. terminu płatności, c. roku należności, d. oznaczenia należności, e. należności z upomnieniem, f. należności z wystawionym tytułem wykonawczym, g. kwot zaległości, nadpłat, przypisów, odpisów, wpłat, zwrotów, przeksięgowań, h. dat księgowania, i. rejonów np. przypisanie do sołectwa. |
35. | OKIWP musi umożliwiać tworzenie dzienników częściowych. |
36. | OKIWP musi umożliwiać współpracę z oprogramowaniem do obsługi kasowej. |
37. | OKIWP musi umożliwiać wygenerowanie sprawozdania Rb-27S, wraz z jego wydrukiem oraz wygenerowaniem do pliku XML |
38. | OKIWP musi umożliwiać uzyskanie informacji niezbędnych do wykonania sprawozdania: a. Rb-N, b. o zaległościach przedsiębiorców we wpłatach świadczeń należnych na rzecz sektora finansów publicznych (wg PKD). |
39. | OKIWP musi umożliwiać wydruk postanowienia o przerachowaniu wpłaty. |
40. | OKIWP musi umożliwiać wygenerowanie i wydrukowanie min. następujących zestawień: a. Zestawienie pozycji dokumentów, b. Zestawienie zapisów księgowych, c. Zestawienie rozrachunków. |
41. | OKIWP musi umożliwiać wygenerowanie i wydrukowanie następujących zestawień: a. wydruk kartoteki należności i wpłat dla wybranego podatnika/płatnika (karty kontowej); b. zestawienie obrotów. |
42. | OKIWP musi umożliwiać eksport danych widocznych na ekranie do arkusza kalkulacyjnego. |
43. | OKIWP musi rejestrować zmiany danych osobowych wraz z wizualizacją zmienianych danych. |
Obsługa Pozostałych Opłat Lokalnych (OPOL)
Lp. | Opis minimalnych wymagań: |
1. | OPOL musi umożliwiać zarejestrowanie różnych opłat dla wybranego kontrahenta, wraz z określeniem kwoty do zapłaty oraz terminu lub terminów płatności. |
2. | OPOL musi pozwalać na definiowanie przez użytkownika rodzaju opłaty. |
3. | OPOL musi umożliwiać prowadzenie kartotek płatników uprzednio zdefiniowanej opłaty. |
4. | OPOL musi wykorzystywać istniejący urzędowy rejestr TERYT w powiązaniu z bazą PAN (podpowiadany kod pocztowy w zależności od adresu: miejscowość, ulica lub numer domu). |
5. | OPOL musi umożliwiać wydruk rejestru przypisów i odpisów. |
6. | OPOL musi pozwalać na wprowadzenie aktualnych stawek opłaty na podstawie uchwały rady. |
7. | OPOL musi umożliwiać dokonywanie przypisów, odpisów oraz nanoszenie nadpłat bezpośrednio na kontach syntetycznych księgi głównej, ewidencji księgowej urzędu. |
8. | OPOL musi posiadać wbudowaną bazę niezbędnych słowników, która umożliwia wielokrotne wykorzystywanie i modyfikowanie raz wprowadzonych do systemu danych. |
9. | OPOL musi umożliwiać eksport danych widocznych na ekranie do arkusza kalkulacyjnego. |
10. | OPOL musi rejestrować zmiany danych osobowych wraz z wizualizacją zmienianych danych. |
11. | OPOL musi umożliwiać zwiększenie liczby gromadzonych informacji na poziomie różnych obiektów (podatnik, konto podatkowe, składnik opodatkowania) wykorzystujące definiowalne przez użytkownika atrybuty/cechy (umożliwiając określenie ich wymagalności, użycia słowników), wraz z ich późniejszym wyświetleniem na zestawieniach. |
12. | OPOL musi umożliwiać wykorzystanie adresu korespondencyjnego kontrahenta w kontekście każdego konta podatnika. |
4.2.4.2 System Finansowo – Budżetowy (SFB)
System Obsługi Kasy (SOK)
Lp. | Opis minimalnych wymagań: |
1. | SOK musi umożliwiać ewidencję wpłat i wypłat gotówkowych. |
2. | SOK musi umożliwiać rejestrację oraz druk dowodów wpłat i wypłat. |
3. | SOK musi umożliwiać tworzenie i wydruk raportów kasowych. |
4. | SOK ma mieć możliwość integracji z obszarami z księgowości należności tj. księgowości podatków, dochodów z nieruchomości i księgowości opłat (pobieranie informacji o |
należnościach kontrahentów do zapłaty lub zwrotach nadpłat) w kasie, a także przekazywanie informacji o realizacji do odpowiednich obszarów (windykacja należności). | |
5. | SOK musi umożliwiać automatyczne księgowanie raportów kasowych (po ich zamknięciu) w księgowości jednostki. |
6. | SOK musi dawać możliwość chronologicznego wydruku dokumentów KP i KW za wybrany okres. |
7. | SOK musi umożliwiać generowanie druku odprowadzenia gotówki do banku - druk przelewu. |
8. | SOK musi umożliwiać przyjmowanie wpłat od osoby bez konieczności rejestrowania jej w bazie kontrahentów urzędu (dotyczy sporadycznych wpłat). |
9. | SOK ma mieć możliwość obsługi kilku kas jednocześnie. |
10. | SOK musi współpracować z czytnikami kodów kreskowych. |
11. | SOK musi umożliwiać obsługę słowników modułu. |
Zajęcie pasa drogowego (ZPD)
Lp. | Opis minimalnych wymagań: |
1. | Moduł musi posiadać możliwość wprowadzenia i obsługi wniosku, w tym: • możliwość określenia elementów obcych, które mogą znaleźć się na drodze, • możliwość określenia dróg i rodzajów dróg, • możliwość określenia sposobu płatności, • możliwość określenia wnioskodawcy, • możliwość określenia wykonawcy, • możliwość przypisania drogi do wniosku, • możliwość wskazania powodu zajęcia pasa drogowego: np. umieszczenie przyłączy, reklam, na roboty oraz czas na jaki wydana jest decyzja/ umowa. |
2. | Moduł musi umożliwiać obsługę decyzji: wydania decyzji na podstawie wprowadzonego wniosku, wydruku wydanej decyzji, wystawienie decyzji w postaci elektronicznej i jej przesłanie w drogą elektroniczną (ePuap, doręczenie elektroniczne). |
3. | Na podstawie wydanej decyzji moduł powinien umożliwić wygenerowanie przypisów do modułu księgowości zobowiązań w celu obsługi procesu pobierania opłat. |
4. | Moduł musi umożliwiać obsługę zobowiązań wobec gminy, w tym definiowania zobowiązań, wyszukiwanie wg zadanych kryteriów, np. rodzaju płatności, terminu płatności, zobowiązań z przekroczonym terminem płatności. |
5. | Moduł musi umożliwiać windykację tj. tworzenie wezwań / upomnień oraz kierowanie spraw do Naczelnika Urzędu Skarbowego (tytułów wykonawczych) – w tym w postaci elektronicznej. |
6. | Moduł musi umożliwiać definiowanie rodzaju płatności, np. płatność roczna, jednorazowa. |
4.2.4.3 Moduł Backupu Danych Archiwalnych
Moduł to system służący do przechowywania i uruchamiania aplikacji będących obrazami danych z nieużywanych lub wycofywanych systemów informatycznych danej organizacji. Celem wdrożenia funkcjonalności jest zachowanie dostępu do danych z opcjami wyszukiwania mimo przestarzałej technologii, w jakiej oryginalny system został wytworzony.
Wstępne założenia dla funkcjonalności modułu:
• zawiera wierną kopię źródłowego modelu danych (w myśl zdania: lepiej kopia niż migracja),
• dane merytoryczne tylko do odczytu. Wybrane cechy produktu:
• Wsparcie dla najnowszych wersji przeglądarek: MS Internet Explorer, Mozilla Firefox, Google
Chrome, Apple Safari
• Wspiera standard CSS 3.0
• Spełnia postulaty accessibility
• Spełnia wytyczne najnowszej wersji WCAG 2.0 (Web Content Accessibility Guidelines) w zakresie dostępności dla osób niepełnosprawnych na poziomie AA
• Spełnia wytyczne OWASP (Open Web Application Security Project)
• Szczelny i elastyczny system uprawnień
• Możliwe logowanie za pomocą kont
• Wyszukiwanie pełnotekstowe
• Wyszukiwanie i filtrowanie danych po konkretnych atrybutach
• Zapisywanie wyników wyszukiwania w postaci plików CSV i PDF Kluczowe korzyści:
• Dodatkowe zabezpieczenie - dodatkowa kopia zapasowa danych.
• Bieżący wgląd w dane, nawet dla historycznych systemów.
• Weryfikator migracji - w przypadku wymiany systemów.
• Baza do dalszego przetwarzania.
• “Odmładzanie” przestarzałych technologii.
• Przedłużanie cyklu życia produktu.
• Możliwość rozszerzenia funkcjonalności w stosunku do oryginalnego systemu
informatycznego.
• Otaczanie opieką produktów różnych firm w jednolity sposób. Funkcjonalność zapewnienia kopii zapasowej:
1 | Architektura systemu zapewniającego kopie zapasowe wybranych systemów musi zapewniać odpowiednią separację danych pochodzących z różnych źródeł w celu podziału funkcjonalnego oraz ze względu na uprawnienia. To znaczy, system musi zapewnić możliwość zdefiniowania i zgrupowania funkcjonalności (widoków) w jednej grupie (aplikacji) do tej grupy i do widoków będzie można definiować uprawniania. Takich grup funkcjonalnych (aplikacji) może być dowolna liczba. |
2 | Wyszukiwanie pełnotekstowe działające w ramach przyznanych uprawnień do danych. Wyszukiwanie musi działać równocześnie w wielu grupach funkcjonalnych (aplikacjach). Wyniki wyszukiwania w postaci widoku z pogrupowanymi wynikami w ramach grup funkcjonalnych (aplikacji) oraz ich widoków. |
3 | Funkcjonalność administrowania danymi i grupami funkcjonalnymi. Musi zawierać konsolę wszystkich zdefiniowanych grup funkcjonalnych (aplikacji), listę użytkowników z możliwością definiowania uprawnień, list grup uprawnień z możliwością ich definicji. |
4 | Historia działań użytkowników w postaci widoku z możliwością wyszukiwania danych. |
5 | System uprawnień pozwalający na dowolne definiowanie grup uprawnień. Uprawnienia są zdefiniowane w ramach każdej grupy funkcjonalnej (aplikacji). Użytkownicy mogą mieć dostęp do wielu grup funkcjonalnych (aplikacji) jednocześnie. |
6 | Możliwość raportowania z danego widoku z danymi z uwzględnieniem selekcji i filtrów do postaci pliku CSV oraz raporty do postaci PDF. |
7 | Możliwość wyszukiwania na każdym widoku po każdej kolumnie oraz z sortowaniem oraz przeszukiwanie wszystkich atrybutów jednocześnie. |
4.2.5 Integracja EZD z systemami dziedzinowymi
W celu uproszczenia i ujednolicenia architektury informatycznej Urzędu konieczna jest integracja obecnych i modernizowanych aplikacji dziedzinowych (wykorzystywanych do obsługi e-usług wdrażanych w ramach przedmiotowego zamówienia) z EZD-PUW7. W efekcie powstanie zintegrowany system, oparty o nowoczesne i efektywne technologie, obejmujący wszystkie obszary funkcjonowania Urzędu obejmujące przedmiotowe Zamówienie, w tym realizację elektronicznych usług publicznych i przeznaczony do wspomagania prac wszystkich obszarów zarządzania w Urzędzie. System może być podzielony na dowolną liczbę modułów, tak aby zapewnić łącznie funkcjonalność w następujących obszarach:
• Finansowo-księgowy,
• Obsługa dochodów podatkowych i opłat,
• Ewidencyjny i administracyjny.
Wykonawca w ramach zamówienia wykona prace niezbędne do poprawnego uruchomienia
e-usług.
Prace wdrożeniowe obejmują niezbędny zakres prac instalacyjno-konfiguracyjno- integracyjnych wraz z migracją danych dla obszarów, dla których są konieczne ze względu na ich uwzględnienie w związku z wdrażanymi rozwiązaniami i e-usługami oraz oprogramowaniem.
W chwili obecnej w Urzędzie Gminy Michałowice zainstalowane zostały poniższe
oprogramowania:
⮚ Tabela 1. Zarządzanie dokumentacją.
⮚ Tabela 2. Programy narzędziowe wspomagające pracę komórek merytorycznych.
⮚ Tabela 3. Oprogramowanie wspomagające pracę w obszarach finansów, księgowości, budżetu i podatków.
7 Możliwość integracji uzależniona jest od zakresu funkcjonalnego API systemu EZD PUW opisanego w
dokumentacji technicznej udostępnionej na stronie xxxxx://xxx.xxx.xx/xxx/xxx/xxxxxxxxxx
Tabela 1
Nazwa grupy: Zarządzanie dokumentacją
NR | NAZWA PROGRAMU | OPIS |
1.1 | EZD | System Elektronicznego Zarządzania Dokumentacją PUW |
1.2 | REJESTR UMÓW | Rejestrowanie umów oraz generowanie raportów |
1.3 | REJESTR DECYZJI | Rejestrowanie decyzji oraz generowanie raportów |
1.4 | BUDŻET I KONTROLA WYDATKÓW | Zarządzanie rejestrem wydatków, oprogramowanie wspomagające tworzenie dok. opisowej wydatków |
Tabela 2
Nazwa grupy: Programy narzędziowe wspomagające pracę komórek merytorycznych
NR | NAZWA PROGRAMU | OPIS |
2.1. | BAZA POSESJI | Przeglądarka bazy ewidencji ludności |
2.2. | EWOPIS | Przeglądarka Ewidencji Gruntów i Budynków |
2.3. | EWMAPA | Przeglądarka mapy numerycznej Gminy Michałowice (ewidencja gruntów i budynków) |
2.4. | LEGISTRATOR | Oprogramowania do przygotowywania aktów prawnych |
2.5. | ABC ANON | Oprogramowanie do anonimizacji |
2.6. | VEEAM Backup & Replication | Oprogramowanie do kopii zapasowych w środowiskach Vmware oraz Hyper-V |
2.7. | Pakiet oprogramowania Geuterbruck do obsługi monitoringu | VMS – pakiet do zarządzania systemem kamer |
2.8. | ACCESS PROFESSIONAL EDITION | Zarządzanie użytkownikami kontroli dostępu |
2.9. | EWIDENCJA | Ewidencja działalności gospodarczej |
2.10. | iMPA | Internetowy Menadżer Punktów Adresowych |
2.11. | iRMK | Internetowy Rejestr Mienia Komunalnego |
2.12. | SELWIN | System Ewidencji Ludności |
2.13. | EcoHarmonogram | Mobilna aplikacja z harmonogramem wywozu odpadów |
2.14. | Foris Karta Miejska | Program do obsługi Karty Mieszkańca |
2.15. | Geomapa | Oprogramowanie Systemu Informacji o Terenie |
2.16. | Plan zamówień publicznych | Program do obsługi zamówień publicznych |
2.17. | Ewidencja dróg | Ewidencja dróg, foto-video inwentaryzacja |
2.18. | Localspot | Oprogramowanie do rejestracji i obsługi zgłoszonych przez mieszkańców problemów i pomysłów. |
2.19. | SerwerSMS | Oprogramowanie do masowej wysyłki SMS (bramka SMS) |
Tabela 3
Nazwa grupy: Oprogramowanie wspomagające pracę w obszarach finansów, księgowości, budżetu i podatków
NR | NAZWA PROGRAMU; NAZWA SYSTEMU | OPIS |
3.1 | AUTA | Wymiar podatku od środków transportowych |
3.2 | BO ADMIN | Administracja danymi osobowymi gromadzonymi w systemie Finanse i Księgowość |
3.3 | CZYNSZE | Rejestr oraz zarządzanie czynszami mieszkań komunalnych |
3.4 | EGZEKUCJE+ | System kontroli egzekucji należności |
3.5 | KASA | Kasa urzędu (podatki, dochody) |
3.6 | KBiP | Księgowość jednostek budżetowych |
3.7 | REJESTR VAT | Centralny rejestr VAT (ewidencja zakupów i sprzedaży VAT) |
3.8 | KSZOB | Księgowość zobowiązań płatników na rzecz jednostek administracji lokalnej |
NR | NAZWA PROGRAMU; NAZWA SYSTEMU | OPIS |
3.9 | OPLOK | Ewidencja oraz rozliczenia należności z tytułu opłat lokalnych(podatek od posiadania psów, opłata targów, mandaty, kary administracyjne) |
3.10 | PŁACE | Program kadrowo-płacowy |
3.11 | PODATKI | Prowadzenie ewidencji nieruchomości i podatków |
3.12 | DZIERZAWY | Prowadzenie ewidencji umów drogi wew. oraz najmy |
3.13 | REJOSOB | Przeglądarka danych osobowych systemu księgowo- podatkowego |
3.14 | ST | Środki trwałe |
3.15 | UPK | Uniwersalny program księgujący, umożliwiający automatyczne wczytywanie i księgowanie wyciągów bankowych |
3.16 | WIZJA | Wieloletnie prognozy finansowe |
3.17 | Besti@ | System zarządzania budżetem jednostek |
3.18 | WODA MILLENNIUM | System rozliczania opłat wodno-kanalizacyjnych oraz opłat za gospodarowanie odpadami |
3.19 | PŁATNIK | Oprogramowanie dla płatników składek ZUS. |
3.20 | ZEZWOLENIA | Ewidencja Zezwoleń |
W celu zapewnienia możliwości przeprowadzenia migracji danych Zamawiający zapewni dostęp do baz danych rozwiązań obecnie wykorzystywanych w okresie realizacji Umowy do podpisania protokołu odbioru końcowego (dla wymienionych obszarów podlegających migracji zostaną w szczególności przeniesione: salda niezerowe według stanu na dzień uzgodniony pomiędzy Wykonawca a Zamawiającym, dane podatników, dane nieruchomości, przedmioty opodatkowania). Wykonawca zmigruje dane niezbędne do płynnego uruchomienia wdrażanego rozwiązania. Przed rozpoczęciem wdrażania systemu Wykonawca wspólnie z Zamawiający ustalą jakie dokładnie dane oraz w jakim zakresie będą zmigrowane.
4.3.2 Szkolenie z wdrażanych rozwiązań
Wykonawca przeprowadzi szkolenia w zakresie niezbędnym do uruchomienia wdrażanego rozwiązania dla 22 pracowników Zamawiającego. Szkolenia mogą być przeprowadzane w grupach max 6 osobowych. Wykonawca zapewni szkolenia zarówno dla pracowników merytorycznych jak i administratorów wdrażanego rozwiązania.
Lp. | Opis wymagania |
WSZ1 | Szczegółowy plan szkolenia wraz z harmonogramem przygotowany zostanie na etapie planu realizacji projektu. |
WSZ2 | Wykonawca na etapie uzgadniania materiałów szkoleniowych przekaże minimalne wymagania, jakie powinni spełniać oddelegowani przez Xxxxxxxxxxxxx, uczestnicy szkolenia |
WSZ3 | Do każdego modułu wspomagającego obsługę obszarów działalności Urzędu, Zamawiający wskaże osoby, które Wykonawca przeszkoli |
WSZ4 | Szkolenia będą prowadzone w siedzibie zamawiającego na sprzęcie dostarczonym przez Wykonawcę (laptopy) w godzinach pracy Zamawiającego w terminach uzgodnionych wcześniej. |
WSZ5 | Zamawiający nie dopuszcza przeprowadzania szkoleń typu e-learning w zastępstwie szkoleń tradycyjnych. |
WSZ6 | Zamawiający dopuszcza przeprowadzanie szkoleń grupowych, w grupach do 10 użytkowników oraz szkoleń indywidualnych przy stanowiskowych dla grup jedno-, dwu- lub trzyosobowych. |
WSZ7 | Wykonawca przeszkoli osoby pełniące obowiązki administratorów wskazanych przez Zamawiający w zakresie zarządzania użytkownikami i uprawnieniami, zabezpieczania i odtwarzania danych. |
WSZ8 | Wykonawca zapewni przeszkolenie administratora wskazanego przez Zamawiającego w zakresie administracji i konfiguracji zaoferowanego systemu bazodanowego. Szkolenie musi obejmować co najmniej instalację, konfigurację bazy danych, obsługę narzędzi administratora, architekturę systemu, zagadnienia związane z zachowaniem bezpieczeństwa, integralności i zabezpieczenia przed utratą danych, przywracaniem danych po awarii. |
WSZ9 | Uzgodnieniu pomiędzy stronami podlegają: - Minimalne wymagania dla uczestników szkoleń, - Harmonogram szkoleń grupowych i indywidualnych, - Materiały szkoleniowe dla szkoleń grupowych, - Listy obecności ze szkoleń grupowych i indywidualnych, - Protokoły Odbioru Zadania dot. Szkoleń. |
WSZ10 | Zamawiający oczekuje, że liczba oraz program szkoleń powinny gwarantować użytkownikom systemu zapoznanie się z wszystkimi funkcjonalnościami jakie system oferuje. A także weryfikację przyswojonej wiedzy z zakresu obsługi systemu. |
Wykonawca w ramach zamówienia musi zaimplementować formularze elektroniczne dostępne w ePUAP po uzgodnieniu ostatecznej ich liczby oraz zakresu co do którego mają się odnosić, konieczne do prawidłowego działania wdrażanych i uruchamianych e-usług w liczbie nie większej niż 15 szt.
W ramach zamówienia Wykonawca musi zapewnić poprawne działanie formularzy elektronicznych przez okres udzielonej Gwarancji z wyłączeniem sytuacji za które nie odpowiada (błędy ePUAP, zmiany technologii ePUAP wymagające budowy kompletnie nowych formularzy). Publikacja formularzy na ePUAP realizowana będzie przez oddelegowanego pracownika Zamawiającego.
Część formularzy XML dotycząca danych osobowych podatnika powinna być ujednolicona we
wszystkich formularzach XML.
Lp. | Opis wymagania |
1. | Formularze stosowane na ePUAP tworzone są z wykorzystaniem języka XForms oraz XPath. |
2. | Wykonawca powinien opracować formularze elektroniczne (zgodnie z właściwymi przepisami prawa) na podstawie przekazanych przez JST, których dotyczy przedmiotowe zamówienie, kart usług z formularzami w formacie MS Word. |
3. | Wszystkie formularze elektroniczne Wykonawca musi przygotować z należytą starannością tak, aby pola do uzupełnienia w tych formularzach zgadzały się z polami formularzy w formacie MS Word. |
4. | Pola wskazane przez JST jako pola obowiązkowe w formularzach w formacie MS Word, musza zostać polami obowiązkowymi również w formularzach elektronicznych. |
5. | Układ graficzny wszystkich formularzy powinien być w miarę możliwości jednolity. |
6. | Wizualizacja formularzy elektronicznych nie musi być identyczna ze wzorem w formacie MS Word, ale musi zawierać dane w układzie niepozostawiającym wątpliwości co do treści i kontekstu zapisanych informacji, w sposób zgodny ze wzorem. |
7. | Przygotowując formularze Wykonawca musi dążyć do maksymalnego wykorzystania słowników. |
8. | W budowanych formularzach należy wykorzystać mechanizm automatycznego pobierania danych z profilu – celem uzupełnienia danych o wnioskodawcy. |
9. | Formularze muszą zapewniać walidację wprowadzonych danych po stronie klienta i serwera zgodnie z walidacją zawartą w schemacie dokumentu. |
10. | Jeśli w formularzu elektronicznym występują pola PESEL, REGON lub kod pocztowy, to pola te muszą być walidowane pod kątem poprawności danych wprowadzanych przez wnioskodawcę. |
11. | Każdy opracowany przez Wykonawcę formularz (w postaci pliku XML) musi zostać przekazany JST na okres 7 dni roboczych w celu dokonania sprawdzenia i wykonania testów na formularzu. |
12. | Po okresie testów, o których mowa w wymaganiu poprzednim, JST przekaże Wykonawcy ewentualne poprawki i uwagi dotyczące poszczególnych formularzy, które Wykonawca usunie bez zbędne zwłoki. |
13. | Wykonawca przygotuje wzory dokumentów elektronicznych w CRD zgodnie ze standardem ePUAP w formacie XML zgodnym z formatem Centralnego Repozytorium Wzorów Dokumentów. |
14. | Zamawiający dopuszcza możliwość wykorzystania przez Wykonawcę wzorów, które są już opublikowane w CRD. |
15. | Wygenerowane dla poszczególnych formularzy wzory dokumentów elektronicznych, składające się z plików: • Wyróżnik (wyróżnik.xml), • Schemat (schemat.xml), • Wizualizacja (styl.xsl), muszą zostać dostosowane do wymogów formatu dokumentów publikowanych w CRD i spełniać założenia interoperacyjności. |
16. | W ramach projektu Wykonawca przygotuje i przekaże Zamawiającemu projektu wszystkie wzory dokumentów elektronicznych w celu złożenia wniosków o ich publikację w CRD. |
17. | Wykonawca udzieli wsparcia Zamawiającemu projektu w przejściu procesu publikacji na ePUAP. |
18. | Bazując na przygotowanych wzorach dokumentów elektronicznych oraz opracowanych na platformie ePUAP formularzach elektronicznych Wykonawca przygotuje instalacje aplikacji w środowisku ePUAP. |
19. | Aplikacje muszą być zgodne z architekturą biznesową ePUAP oraz architekturą systemu informatycznego ePUAP. |
20. | Zainstalowane aplikacje muszą spełniać wymogi ePUAP oraz pozytywnie przechodzić przeprowadzone na ePUAP walidacje zgodności ze wzorami dokumentów. |
21. | Na czas realizacji projektu Zamawiający projektu zapewni Wykonawcy dostęp do części administracyjnej platformy ePUAP konta JST z uprawnieniami do konsoli administracyjnej Draco, ŚBA i usług. |
22. | W przypadku zwłoki w publikacji wzorów dokumentów CRD realizowanej przez Ministerstwo Cyfryzacji (administrator ePUAP) dopuszcza się dokonanie odbioru tej części zamówienia w ramach lokalnych publikacji w CRD z zastrzeżeniem, że Wykonawca dokona przekonfigurowania aplikacji po pomyślnej publikacji CRD przez Ministerstwo Cyfryzacji. |
23. | Zamawiający przekaże Wykonawcy opisy usług w formacie MS Word. |
24. | Zamawiający dopuszcza, aby Wykonawca wykorzystał opisu usług umieszczone na platformie ePUAP. |
25. | Zadaniem wykonawcy jest odpowiednie powiązanie opisów usług zamieszczonych na ePUAP z odpowiednimi usługami opracowanymi przez JST. |
26. | Wykonawca przygotuje definicję brakujących opisów usług na ePUAP. Zamawiający zwróci się do Ministerstwa Cyfryzacji w celu akceptacji i umieszczenia ich na platformie ePUAP. |
27. | Wszystkie opisy usług zostaną przyporządkowane do jednego lub więcej zdarzenia życiowego z Klasyfikacji Zdarzeń, a także do Klasyfikacji Przedmiotowej Usług ePUAP. |
Warunkiem koniecznym prawidłowej realizacji niniejszego zamówienia będzie raport (dokument) potwierdzający przeprowadzenie przez niezależny od Wykonawcy podmiot poniższych Audytów i testów.
Przeprowadzenie audytu bezpieczeństwa infrastruktury ICT oraz dokumentacji Systemu Zarządzenia Bezpieczeństwem Informacji i ochrony danych wg stanu obowiązującego prawa, norm ISO 27001, ISO 22301 w celu oceny poziomu bezpieczeństwa, dojrzałości ładu organizacyjnego oraz podatności funkcjonującego systemu ICT.
Ogólne Wymagania Metodologiczne
1. Wykonywanie testów penetracyjnych z wykorzystaniem standardów testowania bezpieczeństwa:
a) OWASP (Open Web Application Security Project) ASVS 4.0 lub równoważnych,
b) Open Source Security Testing Methodology Manual (OSSTMM) lub równoważnych,
c) Penetration Testing Execution Standard (PTES) lub równoważnych.
Za równoważne uznaje się standardy opisujące przebieg procesu testowania bezpieczeństwa systemów IT oraz obszary systemowe, które muszą podlegać weryfikacji
2. Wykorzystania w trakcie audytu znanych zbiorów danych o podatnościach i słabościach bezpieczeństwa systemów teleinformatycznych, w trakcie prac prowadzonych przez zespól audytowy np.
a) SANS Top 20 Critical Security Controls
b) Common Vulnerabilities and Exposures
c) WASC (Web Application Security Consortium) Threat Classification
d) NIST xxxx.xxx - NVD
e) Web Application Security Consortium xxxxxxxxx.xxx lub równoważnych.
Za równoważne uznaje się takie bazy danych, które stanowią aktualne źródło informacji o lukach bezpieczeństwa, są publikowane lub utrzymywane przez uznane powszechnie organizacje działające na rzecz zapewnienia bezpieczeństwa systemów teleinformatycznych.
3. W ramach realizacji audytu bezpieczeństwa do oceny wykorzystywane powinny być listy kontrolne udostępniane przez uznane organizacje pracujące na rzecz bezpieczeństwa systemów IT, tj.:
a) National Security Agency (NSA),
b) Center for Internet Security (CIS)
c) NIST (xxxx.xxx)
d) US-CCU (us- xxx.xx) lub kontrolne listy równoważne do powyższych
Za równoważne uznaje się takie, które stanowią aktualne źródło informacji o bezpiecznej konfiguracji, są publikowane lub utrzymywane przez uznane powszechnie organizacje, działające na rzecz zapewnienia bezpieczeństwa systemów teleinformatycznych.
4. Wykonania w trakcie audytu testów penetracyjnych w celu wykrycia podatności technicznych w oparciu o następujące zasady, dobrane wg analizy ryzyka i próby audytowej:
a) Testy typu „Black box” – tester nie posiada wiedzy dotyczącej testowanego obiektu,
b) Testy typu „Crystal box” – tester posiada pełną wiedzę dotyczącą testowanego
obiektu,
c) Testy typu „Grey box” – tester posiada częściową wiedzę dotyczącą testowanego obiektu.
Wymagania dla realizacji badania infrastruktury IT i wykonania testów penetracyjnych W ramach realizacji badania infrastruktury i testów penetracyjnych obejmować powinny typowe, wymienione niżej zadania (będące elementem każdej metodyki testów penetracyjnych) dobramach zgodnie z analiza ryzyka i próby audytowej:
a) Target Scoping (Zakres Docelowy – ustalenie w porozumieniu z Zamawiającym charakteru i zasięgu testów);
b) Information Gathering (Gromadzenie Informacji – pasywne zbieranie informacji na temat obiektu testów);
c) Target Discovery (Odkrywanie Celu – pół-pasywne zbieranie informacji, poznanie
celów, identyfikacja podsieci, rodzaju architektury, systemów operacyjnych);
d) Enumerating Target (Wyliczanie Elementów – aktywne zbieranie informacji, enumeracja usług, portów, wykrywanie systemów bezpieczeństwa IDS/UPS, FV);
e) Vulnerability Mapping (Mapowanie Podatności – poszukiwanie podatności w
elementach znalezionych w poprzednich fazach);
f) Target Exploitation (Docelowa Eksploatacja – stworzenie wektora inicjalizującego atak, który ma na celu ominąć zabezpieczenia w celu naruszenia poufności, integralności oraz dostępności danych osobowych, przejęcia systemów, odcięcia systemu od sieci zewnętrznej)
g) Privilage Escalation (Eskalacja Uprawnień – zwiększenie uprawnień w przełamanym systemie i przeniesienie kontroli na kolejne usługi lub systemy)
h) Maintaining Access (Utrzymanie Dostępu – utrzymanie dostępu do
skompromitowanego systemu, instalacja tylnych furtek, rootkit-ów.
i) Documentation & Reporting (Dokumentacja i Raportowanie – raport powinien
zawierać informacje o znalezionych podatnościach oraz zauważonych problemach).
W ranach wykonywania testów i badania infrastruktury IT powinny być wykonane zgodnie z
dobrana próbą i analizą ryzyka:
1. Ataki semantyczne na adres URL,
2. Ataki związane z ładowaniem plików,
3. Ataki typu Cross-Site Scripting,
4. Ataki typu Cross-Site Request Forgery,
5. Ataki typu MITM (Man in the Middle),
6. Broken Authentication and Session Management (badanie losowości ID sesji, próba detekcji składni nazywania cookie sesyjnego, sprawdzenie bezpieczeństwa budowy formularza logowania),
7. Authorization Bypass (próby dostępu do zasobów bez uwierzytelnienia Użytkownika),
8. Code Execution (próby wykonania wrogiego kodu na serwerze),
9. Information Leakage (próby detekcji wycieku istotnych informacji – technicznych i biznesowych),
10. Insecure Communications (dostęp do istotnych danych w wyniku braku lub
nieodpowiedniego poziomu szyfrowania),
11. Source Disclosure (próby prowadzące do ujawnienia kodów źródłowych
wykorzystanego oprogramowania),
12. File Inclusion (załączanie plików lub do ich zawartości złośliwej zawartości),
13. Open Redirection (próby nieautoryzowanego przekierowania),
14. Fałszowanie żądania http,
15. Response Splitting (brak prawidłowej walidacji nagłówków http)
16. Ujawnienie danych przechowywanych w bazie,
17. Ujawnianie kodu źródłowego,
18. Przepełnienie bufora lub stosu
19. Badanie luk systemów informatycznych (aplikacji).
20. Badanie luk urządzeń sieciowych.
21. Badanie luk baz danych.
22. Badanie luk komputerów i notebooków.
23. Badanie luk serwerów.
24. Badanie luk sieci WiFi.
25. Inwentaryzację otwartych portów.
26. Analizę bezpieczeństwa stosowanych protokołów.
27. Identyfikację podatności systemów i sieci na ataki typu: DoS, DDoS, Sniffing, Spoffing,
XSS, Hijacking,
28. Backdoor, Flooding, Password, Guessing i inne.
29. Skanowanie aktywnych urządzeń sieci komputerowej, w tym routery, zapory (firewall), przełączniki, serwery i stacje robocze na występowanie luk/podatności w tych urządzeniach oraz błędów w konfiguracji zmniejszających poziom bezpieczeństwa systemów
30. Badanie podatności i błędy w konfiguracji systemów będących w posiadaniu organizacji z uwzględnieniem poziomu ważności ze względu na bezpieczeństwo.
31. Skanowanie z autentykacją w celu potwierdzenia podatności systemu operacyjnego oraz oprogramowania pakietów biurowych i systemu poczty elektronicznej. Badanie bezpieczeństwa funkcji i protokołów specyficznych dla aplikacji /serwera.
32. Badanie mechanizmów bezpieczeństwa (firewalli).
33. Badanie dostępów do urządzeń aktywnychBadanie routingu.
34. Badania zasad filtrowania połączeń.
35. Badania stanu stron informacyjnych pod kątem obowiązku informacyjnego i
utrzymania standardu WCAG 2.1 AA.
Pozostałe wymagania dla obszarów audytowych
Przeprowadzenie badania audytowego w zakresie:
1. Enumeracji i wykorzystania znanych podatności w celu uzyskania nieautoryzowanego dostępu.
2. Możliwości podszywania się pod Użytkowników i uzyskania nieautoryzowanego dostępu do systemu.
3. Możliwości podszywania się pod Użytkowników uprzywilejowanych i uzyskanie dostępu do systemu.
4. Możliwości blokowania/umożliwienia dostępu do systemu wszystkim lub wybranym jej Użytkownikom.
5. Metody uwierzytelnienia dwuskładnikowego - próby podatności, weryfikacja działania, próby ominięcia mechanizmu
6. Weryfikacja podatności systemu informatycznego na ingerencje ze strony osób
trzecich:
a) Przeprowadzenie testów penetracyjnych wykonanych ze stacji roboczej podłączonej do systemu informatycznego lub/i portalów www z sieci Internet możliwości przeprowadzenia włamania z zewnątrz sieci.
b) Przeprowadzenie testów penetracyjnych wykonanych ze stacji roboczej podłączonej do wewnętrznego systemu informatycznego lub/i Portalu w celu zidentyfikowania możliwości przeprowadzenia włamania z wewnątrz sieci.
Wykonawca ma również obowiązek przeprowadzić Audyt dostępności wdrażanych w ramach zamówienia rozwiązań z wymogami WCAG 2.1.
Wykonawca zobowiązany jest do dostarczenia Dokumentacji dotyczącej wdrożonego rozwiązania i e-usługi oraz jej aktualizacji w trakcie trwania Umowy.
1) Dokumentacja musi być sporządzona w języku polskim chyba, że dotyczy kodów źródłowych, języka SQL, fragmentów kodów oprogramowania.
2) Każda Dokumentacja powstała w wyniku realizacji zamówienia i przekazana Zamawiającemu przez Wykonawcę stanowi własność Zamawiającego. Zamawiający ma prawo udostępniać Dokumentację osobom trzecim w sposób nie naruszający praw autorskich.
3) Aktualizacja Dokumentacji następuje po wprowadzeniu przez Wykonawcę zmian w Rozwiązaniu nie rzadziej niż raz na pół roku.
4) Wykonawca dostarczy szczegółową Dokumentację komponentów firm trzecich użytych w dostarczanym Systemie, w tym także dostarczaną przez ich producentów. Dokumentacja ta może występować w języku angielskim, jeśli nie ma tłumaczenia na język polski
5) Dokumentacja musi być dostarczona po jednym egzemplarzu w postaci papierowej i elektronicznej zgodnie z zasadami dostępności (.pdf, .docx) na nośniku