OPIS PRZEDMIOTU ZAMÓWIENIA CZĘŚĆ I
Załącznik nr 2A do SIWZ
OPIS PRZEDMIOTU ZAMÓWIENIA
CZĘŚĆ I
SPIS TREŚCI
2. Zakres licencji na dostarczane w ramach zamówienia oprogramowanie 5
4. Ogólne zasady równoważności rozwiązań 9
5. CZĘŚĆ I - DOSTAWA WRAZ Z WDROŻENIEM SYSTEMÓW DZIEDZINOWYCH 11
Minimalne wymagania ogólne: 11
III. Biuletyn Informacji Publicznej zintegrowany z systemem EZD 21
V. Zintegrowany System Płatności Elektronicznych e-płatności 40
VI. Baza danych oraz niezbędne oprogramowanie 42
VII. Uruchomienie i oznakowanie Punktu Potwierdzania Profili Zaufanych 42
VIII. Integracja systemów dziedzinowych umożliwiających obsługę systemów e-usług 53
A) System finansowo- księgowy 55
B) System kadrowo – płacowy wraz z portalem pracowniczym 73
C) System obsługi nieruchomości – ewidencja mienia komunalnego 87
X. Aplikacja mobilna zintegrowana z platformą usług publicznych 90
Prognoza finansowa – wymagania minimalne: 93
XII. System do podpisu elektronicznego – 5 kpl. 94
XIII. Szkolenia pracowników 95
6. CZĘŚĆ 2 - DOSTAWA WRAZ Z WDROŻENIEM SPRZĘTU KOMPUTEROWEGO 98
I. Serwer dla Elektronicznego Obiegu Dokumentów – 1 szt. 99
III. Czytnik kodów wraz z drukarką kodów – 4 kpl. 111
VI. Jednostki robocze z monitorem – 50 szt. 117
Wstęp
Niniejszy dokument określa minimalne wymagania dla przedmiotu zamówienia (Część 1), polegającego na Dostawie wraz z wdrożeniem systemów dziedzinowych i sprzętu komputerowego dla Powiatu Lwóweckiego w ramach realizacji projektu pn.: „Dalszy rozwój e-usług w Powiatach Lubańskim, Lwóweckim, Zgorzeleckim, Bolesławieckim i Gminie Miejskiej Lubań”.
Projekt jest współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Dolnośląskiego na lata 2014-2020.
Zakres licencji na dostarczane w ramach zamówienia oprogramowanie
Wykonawca, stosownie do ustawy o prawie autorskim i prawach pokrewnych z 4 lutego 1994 r. (tekst jednolity Dz.U. 2019 poz. 1231) oświadcza, że z momentem ukończenia prac nad wdrożeniem aplikacji, udzieli Starostwu Powiatowemu w Lwówku Śląskim oraz jednostkom podległym (w niezbędnym zakresie) nieodpłatnej i nieograniczonej w czasie licencji niewyłącznej na korzystanie z wdrożonych aplikacji, na następujących polach eksploatacji:
wyświetlania, odtwarzania, przekazywania, udostępniania i stosowania
wielokrotnego wprowadzania do pamięci komputerów,
dokonywania wszelkich modyfikacji programowych w zakresie korzystania z niego w celach pierwotnych,
rozpowszechniania w sieciach zamkniętych w obrębie pracowników Licencjobiorcy.
Licencja będzie niewyłączna i zostanie udzielona nieodpłatnie.
Licencja zostanie udzielona na czas nieoznaczony.
Licencjodawca udostępni Licencjobiorcy wszelkich informacji dotyczących programu.
Licencjobiorca nie będzie miał prawa do publicznego rozpowszechniania, wprowadzania do obrotu, w tym najmu, sprzedaży lub dzierżawy programu oraz kopii oprogramowania. Licencjobiorca nie będzie miał prawa przenosić praw wynikających z licencji.
Udzielona licencja musi obejmować całość dostarczanego rozwiązania. Jeśli w ramach licencji konieczne jest udzielenie licencji na jakąkolwiek część systemu przez inny podmiot to wymaga się jej udzielenia Zamawiającemu. Udzielona w ten sposób sublicencja nie może w żaden sposób ograniczać pozostałych warunków licencjonowania.
Licencja musi obejmować także działania oprogramowania narzędziowego (systemy operacyjne, bazy danych i inne).
W ramach postepowania Wykonawca ma dostarczyć licencję na poniższe oprogramowanie na potrzeby:
Starostwa Powiatowego w Lwówku Śląskim z siedzibą przy ulicy xx. Xxxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx:
Portal zgodny z WCAG 2.0, wraz z wdrożeniem i integracją platform usług publicznych, aplikacją mobilną, BIP,
System Biuletynu Informacji Publicznej zintegrowany z systemem EZD,
System Elektronicznego Zarządzania Dokumentacją (EZD) wraz z elektronicznym archiwum zakładowym dla Starostwa Powiatowego,
Zintegrowany System Płatności Elektronicznych e-płatności,
Baza danych oraz niezbędne oprogramowanie,
Punkt Potwierdzania Profili Zaufanych,
Integracja systemów dziedzinowych umożliwiających obsługę systemów e-usług,
Szyna usług integrująca usługi e-PUAP, EZD i systemy dziedzinowe wraz z bokerem integracyjnym,
Platforma usług publicznych udostępniaja dane z systemów dziedzinowych wraz z Systemem Elektronicznego Biura Obsługi Interesanta (EBOI)
Aplikacja mobilna zintegrowana z platformą usług publicznych,
Scentralizowany system służący do planowania i realizacji budżetu w trybie zadaniowym dla wszystkich jednostek,
System do podpisu elektronicznego,
Jednostki Podległe zgodnie z wykazem:
Scentralizowany system do planowania i realizacji budżetu w trybie zadaniowym
Wykaz jednostek podległych:
Zespół Placówek Edukacyjno - Wychowawczych w Lwówku Śląskim, xx. Xxxxxxx 0, 00-000 Xxxxxx Xxxxxx
Zespół Szkół Ekonomiczno - Technicznych im. Kombatantów Ziemi Lwóweckiej w Rakowicach Wielkich, Xxxxxxxx Xxxxxxx 00, 00-000 Xxxxxx Xxxxxx
Zespół Szkół Ogólnokształcących i Zawodowych we Lwówku Śląskim, xx. Xxxxxxx Xxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx
Zespół Szkół Ogólnokształcących i Zawodowych im. Xxxx Xxxxx XX w Gryfowie Śląskim, xx. Xxxxxxxx xx 00, 00-000 Xxxxxx Xxxxxx
Zarząd Dróg Powiatowych w Lwówku Śląskim, xx. Xxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx
Dom Pomocy Społecznej w Nielestnie, Xxxxxxxxx 00x, 00-000 Xxxx
Dom Pomocy Społecznej w Mirsku, xx. Xxxxxxx 00, 00-000 Xxxxx
Szkolne Schronisko Młodzieżowe w Łupkach, Łupki 22, 59-610 Wleń,
Powiatowe Centrum Pomocy Rodzinie w Lwówku Śląskim, xx. Xxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx
Powiatowy Ośrodek Rozwoju Edukacji w Lwówku Śląskim, xx. Xxxxxxx Xxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx
Komenda Powiatowa Państwowej Straży Pożarnej, xx. Xx. Xxxxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx
Powiatowy Inspektorat Nadzoru Budowlanego W Lwówku Śląskim, Xx. Xxxxxx Xxxxxxxxx 00x, 00-000 Xxxxxx Xxxxxx
Powiatowy Urząd Pracy w Lwówku Śląskim, xx. Xxxxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx
Zarząd Dróg Powiatowych w Lwówku Śląskim z siedzibą przy ulicy xx. Xxxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx:
Dostawa i wdrożenie systemu Elektronicznego Zarządzania Dokumentacją (EZD) wraz z elektronicznym archiwum zakładowym dla 1 Jednostki Organizacyjnej,
Minimalne wymagania w zakresie: gwarancji, asysty technicznej (opieki serwisowej), asysty wdrożeniowej na dostarczane w ramach zamówienia oprogramowanie dziedzinowe
Gwarancja – minimalne wymagania:
Warunki ogólne
Wykonawca zobowiązany jest do udzielenia Zamawiającemu gwarancji na przedmiot Umowy i zobowiązuje się świadczyć serwis gwarancyjny w okresie nie krótszym niż 60 miesięcy.
Okres świadczenia gwarancji rozpoczyna się z dniem podpisania przez Strony Protokołu Odbioru Końcowego.
Zdalne usuwanie usterek i awarii oprogramowania w terminach ustalonych z Zamawiającym.
Zdalne (a w razie konieczności w siedzibie Starostwa oraz jednostek podległych) usuwanie błędów baz danych (w tym brak spójności i integralności danych, itp.) niepolegające na błędnej obsłudze.
Skonfigurowanie lub udzielenie pomocy technicznej przy instalacji i konfiguracji oprogramowania systemowego serwera produkcyjnego, zgodnie z wytycznymi Zamawiającego.
Udostępnienie aktualizacji systemu w miarę modyfikacji i ulepszania własnych aplikacji. Bezpłatne aktualizacje.
Informowanie Urzędu/Jednostek o dostępnych aktualizacjach/poprawkach oprogramowania istotnych dla bezpieczeństwa i właściwego funkcjonowania systemu.
Zdalne (a w razie konieczności w siedzibie Starostwa oraz jednostek podległych) instalowanie powyższych aktualizacji / poprawek (jeżeli oprogramowanie komercyjne dopuszcza pobranie aktualizacji w ramach licencji).
Błędy i awarie oprogramowania w okresie gwarancji będą usuwane na koszt dostawcy aplikacji.
Zapewnienie następujących priorytetów i maksymalnych czasów usunięcia wad i usterek (Czasy naprawy) w okresie gwarancji, liczone od momentu zgłoszenia Wady przez Starostwo lub jednostki podległe:
dla zgłoszeń o priorytecie Krytycznym, oznaczającym przerwę w pracy systemu lub jego wdrożonej funkcjonalności – 24 godziny
dla zgłoszeń o priorytecie Wysokim, oznaczającym ograniczenie wydajności systemu lub jego funkcjonalności, pozwalające jednak na dalszą pracę w systemie oraz w modułach/systemach połączonych interfejsami –72 godziny
dla pozostałych zgłoszeń, określonych jako zgłoszenia o priorytecie Pozostałe – 7 dni.
Przy czym kategoryzacja zgłoszeń zostanie ustalona każdorazowo z osobami uprawnionymi ze strony Zamawiającego.
Zapewnienie rekonfiguracji bądź ponownej instalacji systemu i przywrócenie danych z kopii po awarii sprzętu w ciągu maksymalnie 72 godzin od zgłoszenia gotowości ze strony Zamawiającego.
Czas naprawy oprogramowania użytkowego odnosi się do oprogramowania użytkowego dostarczonego, do którego dostawca oprogramowania posiada możliwość prawną i techniczną ingerencji w kod źródłowy.
Przedstawienie w trakcie odbioru końcowego pełnej dokumentacji powykonawczej obejmującej:
opis użytych bibliotek (funkcji, parametrów), przed podpisaniem protokołu końcowego
szczegółowy schemat baz danych systemu, uwzględniający powiązania i zależności między tabelami
opis techniczny procedur aktualizacyjnych
dostarczenie wszelkich niezbędnych materiałów uzupełniających do powyższej dokumentacji powykonawczej, które są konieczne do właściwej eksploatacji systemu.
Ewentualne rekonfiguracje systemu w celu zapewnienia właściwego dalszego działania, zgodnie z wytycznymi Zamawiającego, we wspólnie ustalonym terminie.
informowania Zamawiającego o dostępnych aktualizacjach / poprawkach Oprogramowania.
Asysta techniczna (opieka serwisowa)
Wykonawca zobowiązany jest świadczyć usługę Asyty Technicznej dla Oprogramowania dziedzinowego.
Okres asysty technicznej – co najmniej 24 miesiące od daty podpisania bez zastrzeżeń końcowego protokołu odbioru
Celem świadczenia usług Asysty technicznej jest bezpłatne wsparcie techniczne w używaniu Oprogramowania, do którego Zamawiający uzyskał licencję na podstawie niniejszego postępowania. Zamawiający przekaże Wykonawcy imienną listę osób uprawnionych ze strony Zamawiającego do korzystania z Asysty technicznej.
Wykonawca zobowiązany jest świadczyć bezpłatną Asystę techniczną przez okres zgodnie
z Ofertą. Okres i zakres Asysty technicznej rozpoczyna się z dniem podpisania przez Strony Protokołu Odbioru Końcowego.Wykonawca zapewni świadczenie Asysty technicznej w języku polskim.
Wykonawca zagwarantuje świadczenie usługi Asysty technicznej wyłącznie przez wykwalifikowany personel, przez co rozumie się osobę/osoby z doświadczeniem, posiadające odpowiednie kwalifikacje merytoryczne i wiedzę na temat Oprogramowania, po odpowiednim przeszkoleniu, cechujące się odpowiednimi predyspozycjami do kontaktu z Użytkownikiem Końcowym tj. komunikatywnością, dobrą dykcją, odpornością na stres, cierpliwością, pozytywnym nastawieniem do Użytkownika Końcowego. Personel Wykonawcy świadczący usługę Asysty technicznej musi posiadać umiejętności pracy z „trudnym użytkownikiem” np. zdenerwowanym, niecierpliwym, zadającym niejasne pytania lub udzielającym niejasnych odpowiedzi – nieobeznanym w temacie
Przedmiotem usługi Asysty technicznej świadczonej przez Wykonawcę na rzecz Zamawiającego jest:
gotowość do świadczenia konsultacji telefonicznych,
gotowość do świadczenia zdalnej pomocy użytkownikom Oprogramowania poprzez szyfrowane połączenia do komputera użytkownika za zgodą i pod nadzorem Zamawiającego,
gotowość do ewentualnego uruchomienia niezbędnej i koniecznej obsługi danych poprzez szyfrowane kanały dostępowe pomiędzy Wykonawcą a Zamawiającym,
wykonanie dodatkowych, a nieprzewidzianych w SIWZ funkcjonalności w Oprogramowaniu, po zaakceptowaniu przez obie strony warunków realizacji (w tym pracochłonności) w ramach Asysty Technicznej,
usuwaniu uszkodzeń danych zawartych w bazie danych oraz ich skutków powstałych w wyniku nieprawidłowego działania oprogramowania,
aktualizacji struktur bazy danych wymaganych przez nowe wersje oprogramowania lub nowe przepisy prawne lub związanych z ogólnym rozwojem oprogramowania,
tworzeniu w bazie danych nowych struktur, które stanowią zabezpieczenie przed wprowadzaniem błędnych danych, powielaniem danych, naruszeniem integralności danych, skasowaniem danych, nadmiernym przyrostem danych i innymi niepożądanymi zjawiskami obniżającymi jakość bazy danych,
modyfikacji lub rozszerzaniu systemu o podmoduły zwiększające jego funkcjonalność i użyteczność, a będących w zakresie działań realizowanych przez Starostwo oraz jednostki podległe,
udzielanie konsultacji pracownikom wskazanym przez Starostwo oraz jednostki podległe w zakresie obsługi oprogramowania we wspólnie ustalonych terminach,
udostępnienie Helpdesku w godzinach roboczych pracy Starostwa i jednostek podległych w formie portalu www,
usunięcie negatywnych skutków będących wynikiem modyfikacji wprowadzonych przez producenta oprogramowania w ramach asysty technicznej, zgodnie z kategoryzacją Zamawiającego.
Asysta Wdrożeniowa
Wykonawca zobowiązany jest świadczyć usługę Asyty Wdrożeniowej dla Oprogramowania.
Celem świadczenia usług Asysty Wdrożeniowej jest wsparcie techniczne w zakresie instalacji, konfiguracji, parametryzacji oraz początkowej eksploatacji Oprogramowania, do którego Zamawiający uzyskał licencję na podstawie niniejszego postępowania w siedzibie Zamawiającego podczas etapu instalacji lub wdrażania Oprogramowania.
Zakres Asysty Wdrożeniowej: min. 25 dni Asysty po 6 godzin jednego dnia.
Świadczenie Asysty Wdrożeniowej rozpoczyna się z dniem podpisania przez Strony Protokołu Odbioru Końcowego.
Wykonawca zapewni świadczenie Asysty Wdrożeniowej w języku polskim.
Wykonawca zagwarantuje świadczenie usługi Asysty Wdrożeniowej wyłącznie przez wykwalifikowany personel, przez co rozumie się osobę/osoby z doświadczeniem, posiadające odpowiednie kwalifikacje merytoryczne i wiedzę na temat Oprogramowania, po odpowiednim przeszkoleniu, cechujące się odpowiednimi predyspozycjami do kontaktu z Użytkownikiem Końcowym tj. komunikatywnością, dobrą dykcją, odpornością na stres, cierpliwością, pozytywnym nastawieniem do Użytkownika Końcowego. Personel Wykonawcy świadczący usługę Asysty Wdrożeniową musi posiadać umiejętności pracy z „trudnym użytkownikiem” np. zdenerwowanym, niecierpliwym, zadającym niejasne pytania lub udzielającym niejasnych odpowiedzi – nieobeznanym w temacie
Przedmiotem usługi Asysty Wdrożeniowej świadczonej przez Wykonawcę na rzecz Zamawiającego w siedzibie Zamawiającego jest:
świadczenie konsultacji w siedzibie Zamawiającego,
gotowość do świadczenia zdalnej pomocy użytkownikom Systemów poprzez szyfrowane połączenia do komputera użytkownika za zgodą i pod nadzorem Zamawiającego,
gotowość do ewentualnego uruchomienia niezbędnej i koniecznej obsługi danych poprzez szyfrowane kanały dostępowe pomiędzy Wykonawcą a Zamawiającym,
Każdorazowa usługa realizacji Asysty Wdrożeniowej prowadzona jest na podstawie zlecenia usługi oraz zakończona Protokołem Odbioru opisującym czas trwania usługi i jej zakres.
W ramach okresu Asysty Wdrożeniowej Zamawiający będzie miał do wykorzystania pulę 25 bloków/dni po 6 roboczogodzin każdych przeznaczonych na:
świadczenie wsparcia technicznego Użytkownikom Końcowym,
świadczenie konsultacji oraz zdalnej pomocy Użytkownikom Końcowym.
Zarejestrowany czas pracy poświęcony na Asystę Wdrożeniową będzie sukcesywnie pomniejszać wielkość puli dla Asysty Wdrożeniowej aż do jej wyczerpania.
Zamawiający
wymaga, by Wykonawca, w terminie do 5 dni roboczych pod każdym
bloku/dniu realizacji Asysty Wdrożeniowej, dostarczył Zamawiającemu
w formie elektronicznej Raport z wykonanych prac
w ramach
Asysty Wdrożeniowej dla danego dnia/bloku.
Ogólne zasady równoważności rozwiązań
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 nie wpł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.
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 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 Musi posiadać składniki użyte do realizacji przedmiotu zamówienia. 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. 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. 30 ust. 1-3 ustawy, zgodnie z art. 30 ust. 4 ustawy dopuszcza rozwiązania równoważne opisywanym. Zgodnie z art. 30 ust. 5 ustawy – Wykonawca, który powołuje się na rozwiązania równoważne opisywanym przez Xxxxxxxxxxxxx, jest obowiązany wykazać, że oferowane przez niego oprogramowanie/sprzęt spełniają wymagania określone przez Zamawiającego. W takiej sytuacji Zamawiający wymaga złożenia stosownych dokumentów, uwiarygodniających te rozwiązania.
CZĘŚĆ I - DOSTAWA WRAZ Z WDROŻENIEM SYSTEMÓW DZIEDZINOWYCH
Portal zgodny z WCAG 2.0, wraz z wdrożeniem i integracją platformy usług publicznych, aplikacją mobilną, BIP
Minimalne wymagania ogólne:
Przedmiotem zadania jest zaprojektowanie, wykonanie oraz wdrożenie serwisu WWW Starostwa Powiatowego w Lwówku Śląskim - portalu internetowego opartego na systemie CMS (content management system) – dalej zwanego Portalem, wraz z migracją danych z istniejących stron Starostwa.
Portal musi być wykonany w architekturze trójwarstwowej, zapewniającym separację warstwy prezentacji od warstwy bazodanowej i silnika.
Portal musi spełniać wymagane standardy: W3C w kontekście struktury dokumentu HTML5 lub XHTML 1.0; W3C w kontekście wyglądu i struktury layoutu CSS 2.0 lub nowszej; spełniać wytyczne i wymagania „organic SEO”
Portal musi być poprawnie wyświetlany przez najpopularniejsze przeglądarki internetowe: Chrome 30+, Internet Explorer 9+, Firefox 12+, Safari 8+, Opera 9.1+., przeglądarki mobilne Android, iOS, Chrome Mobile.
Kodowanie znaków w standardzie utf-8.
Portal musi posiadać szatę graficzną dostosowaną do treści. Szata graficzna musi być wykonana w postaci szablonu. Wymagane jest dostarczenie min. 3 różnych szablonów: codzienny, żałobny, świąteczny.
Portal musi posiadać wbudowane zabezpieczenia, w tym:
ochronę przed próbami nieautoryzowanego dostępu do panelu administracyjnego,
odporność na próby uzyskania dostępu poprzez znane formy włamań,
odporność na zmiany treści za pomocą specjalnych skryptów i manipulacji w zapytaniach do bazy danych (np. sql injection, htmlspecialchars),
stosować wyrażenia regularne w formularzach,
stosować bezpieczne połączenia oparte o protokół SSL, tam gdzie jest to możliwe (np. panel administracyjny).
Dostęp do portalu musi się odbywać na dwóch poziomach:
Poziom publiczny – dostęp dla wszystkich zainteresowanych do strony głównej oraz podstron.
Poziom administracyjny – zastrzeżony dostęp dla administratorów i redaktorów portalu.
Wszystkie podstrony portalu muszą korzystać z jednej bazy oraz jednego panelu administracyjnego.
Zarządzanie treścią musi być możliwe bez konieczności pracy na otwartym kodzie HTML (za pomocą edytora WYSIWYG), z możliwością przełączenia na kod HTML.
Portal musi umożliwiać dodawanie kolejnych podstron.
Portal musi posiadać budowę modułową – możliwość dodawania nowych funkcjonalności (modułów) bez całościowej przebudowy portalu.
Portal musi posiadać menu, oraz umożliwiać dowolne hierarchizowanie i kategoryzowanie treści (w tym co najmniej grupowanie, wyróżnianie, łączenie, dodawanie, usuwanie, modyfikowanie). Treść musi być pogrupowana logicznie, być podzielona x.xx. na paragrafy i bloki.
Każda treść musi posiadać możliwość oznaczania ją słowami kluczowymi.
Każdy artykuł musi dawać możliwość dodania komentarza pod jego treścią bez konieczności logowania na stronie lub na forum.
Portal musi posiadać wyszukiwarkę z przynajmniej jednym polem formularza, która będzie w stanie przeszukać całą zawartość treści portalu pod kątem podanego hasła, a wyniki podać w formie linków do poszczególnych podstron spełniających kryteria wyszukiwania.
CMS musi zapewniać system uprawnień umożliwiające przypisywanie praw do grup i użytkowników, do poszczególnych działów, kategorii, artykułów, galerii, katalogów z plikami itd.
CMS musi zapewniać możliwość tworzenia nieograniczonej liczby nowych użytkowników i przypisanie im wybranych funkcji administracyjnych oraz edycji określonych części serwisu.
Panel administracyjny musi posiadać moduł statystyk, min. najczęściej oglądanych stron.
Zarządzanie treścią musi odbywać się przez przeglądarkę internetową.
Możliwość zasilania danymi portalu z zewnętrznych aplikacji/portali poprzez web services (np. z systemu EZD).
Mechanizm automatycznego tworzenia i publikacji mapy serwisu.
Możliwość tworzenia wstępów do artykułów w postaci tekstu i/lub zdjęcia i możliwość swobodnego definiowania, w których częściach serwisu mają pojawiać się wstępy, a w których całe artykuły.
Możliwość publikacji załączników min. w postaci plików doc, xls, ppt, rtf, odt, plików tekstowych, plików pdf, jpg, gif, png, swf, mpg, mp3, avi, wmv, zip, rar, opatrzonych odpowiednimi ikonkami, oraz innych plików dowolnego formatu opatrzonych właściwą dla nich wspólną ikonką (dotyczy wgrywania na serwer plików z rozszerzeniami zapisanymi małymi i wielkimi literami).
Mechanizm umożliwiający widok w panelu administracyjnym pełnej listy artykułów w wybranym dziale (z informacjami o terminach publikacji, opcjonalnie artykułów z archiwum).
Możliwość tworzenia galerii zdjęć w poszczególnych artykułach.
Możliwość dodawania i edytowania ankiet.
Portal musi udostępniać syntezator mowy, umożliwiający czytanie treści publikowanych w portalu. Mechanizm ma pozwalać na czytanie całej zawartości strony lub tylko zaznaczonych fragmentów.
Minimalne funkcjonalności zgodne z WCAG 2.0:
Zgodność na poziomie AA zgodnie z zał. 4 do Rozporządzenia o KRI
Wszystkie elementy graficzne muszą mieć adekwatny do pełniącej funkcji opis alternatywny lub możliwość ustawienia takiego tekstu przez redaktora.
Odtwarzacze publikowanych treści audio i wideo muszą być dostępne dla osób niepełnosprawnych – dostępność również pod kątem osób korzystających wyłącznie z klawiatury oraz niewidomych użytkowników czytników ekranu.
Publikowane materiały audio-wideo powinny zawierać transkrypcje lub napisy, o ile zawartość tego wymaga.
Wszystkie strony powinny mieć możliwość stosowania nagłówków w prawidłowej hierarchii.
Serwis nie może być zbudowany na bazie tabel, traktowanych jako element konstrukcji układu serwisu.
Mechanizmy nawigacyjne jak np. grupy odnośników powinny być przedstawione za pomocą list.
Kolejność nawigacji oraz czytania, określona za pomocą kolejności w kodzie HTML musi być logiczna i intuicyjna.
Architektura informacji powinna być logiczna, przejrzysta, spójna i przewidywalna.
Elementy nawigacyjne oraz komunikaty nie mogą polegać tylko na charakterystykach zmysłowych jak np.: kształt, lokalizacja wizualna, miejsce lub dźwięk.
Odnośniki zamieszczone w treściach artykułów muszą odróżniać się od pozostałego tekstu nie tylko kolorem, ale i dodatkowym wyróżnieniem np. podkreśleniem.
Po wczytaniu strony www dźwięk nie może być automatycznie odtwarzany.
Kontrast treści w stosunku do tła musi wynosić co najmniej 4,5:1. Jeśli nie jest to możliwe, np. ze względu na utrzymanie identyfikacji wizualnej instytucji serwis powinien posiadać wersję kontrastową posiadającą taką samą zawartość i funkcjonalność jak wersja graficzna, przy czym:
Przycisk przełączenia na wersję kontrastową powinien być dobrze widoczny i spełniać minimalne wymagania kontrastu.
W wersji kontrastowej powinien być dobrze widoczny przycisk powrotu do pierwotnej kolorystyki.
Nie należy zapominać o użytkownikach korzystających z trybów dużego kontrastu dostępnych np. w systemie operacyjnym MS Windows. Wówczas również wszystkie informacje, elementy nawigacyjne i formularze muszą być widoczne.
Typografia tekstów i kontrasty muszą być zaprojektowane pod kątem czytelności.
Po powiększeniu w przeglądarce rozmiaru czcionki do 200% nie może nastąpić utrata zawartości lub funkcjonalności serwisu. Jeśli powiększenie czcionki następuje poprzez zaimplementowany na stronie mechanizm, wówczas:
Przycisk powiększenia powinien zmieniać nie tylko tekst artykułu, ale również wielkość tekstu nawigacji i innych bloków treści strony.
Wybrany rozmiar czcionki powinien zostać zapamiętany w obrębie wszystkich podstron przynajmniej na czas trwania sesji użytkownika.
Przyciski powiększenia powinny być widoczne.
Przyciski powiększenia powinny być dostępne z poziomu klawiatury.
Treści nie mogą być przedstawione za pomocą grafiki, jeśli ta sama prezentacja wizualna może być zaprezentowana jedynie przy użyciu tekstu. Wyjątkiem jest tekst, który jest częścią logo lub nazwy własnej produktu.
Nawigacja w serwisie powinna być również możliwa używając tylko klawiatury (bez użycia myszki).
Fokus powinien być widoczny, a najlepiej wzmocniony i spełniać minimalne wymagania kontrastu.
Wszystkie informacje, które będą automatycznie przesuwane i widoczne dłużej niż 5 sekund lub automatycznie się aktualizują, muszą posiadać mechanizm, który pozwoli na ich zatrzymanie lub ukrycie.
Nie mogą być prezentowane treści zwiększające ryzyko napadu padaczki, czyli takie, które migają więcej niż 3 razy na sekundę i zawierają dużo czerwieni.
Pierwszym elementem w kodzie HTML powinno być menu służące do przeskoczenia, bez przeładownia strony, do istotnych treści serwisu za pomocą kotwic („skip links").
Wszystkie strony serwisu muszą mieć unikalne tytuły.
Odnośniki będące częścią nawigacji jak np. rozwinięcia artykułów („więcej", „czytaj więcej") muszą być uzupełnione tak, aby były zrozumiałe i jednoznacznie informowały użytkownika, dokąd go zaprowadzą lub jaką akcję wykona.
Poza standardową nawigacją muszą być jeszcze inne sposoby odnalezienia informacji jak np. mapa strony i wyszukiwarka.
Musi być zdefiniowany główny język dokumentu adekwatny do wersji językowej. Mechanizm edycji treści musi mieć możliwość definiowania języka dla poszczególnych treści zamieszczonych na podstronach (atrybut „LANG").
Nie mogą być stosowane mechanizmy, które powodują przy zmianie ustawień jakiegokolwiek komponentu interfejsu użytkownika, automatyczną zmianę kontekstu.
Serwis powinien zawierać mechanizm pozwalający na ostrzeganie o otwieraniu się wybranych stron w nowym oknie. Tego rodzaju rozwiązanie np. w postaci uzupełnienia w samym odnośniku należy wdrożyć w algorytmie serwisu.
Dynamiczne zmiany treści jak np. komunikaty w okienkach dialogowych, ostrzeżenia, itp. (odbywające się bez przeładowania strony) powinny być opatrzone odpowiednimi atrybutami ARIA.
Wszystkie pola formularzy muszą być opatrzone etykietami. Muszą jednoznacznie informować o błędach lub sukcesie po ich wypełnieniu. W przypadku wystąpienia błędów system powinien sugerować jego rozwiązanie.
Jako zabezpieczenie formularzy nie może być zastosowane rozwiązanie CAPTCHA, bazujące tylko na charakterystykach zmysłowych, jak wzrok czy słuch. Dozwolone są inne metody jak np. proste zadanie matematyczne.
Całkowita zgodność ze standardami HTML całego serwisu (zarówno szablonów, jak i kodu generowanego z edytora treści, w którym pracuje redaktor).
Powyższy wykaz funkcji nie zwalnia Wykonawcy z obowiązku analizy funkcjonalności Portalu pod kątem zgodności WCAG 2.0 na poziomie AA zgodnie z zał. 4 do Rozporządzenia o Krajowych Ramach Interoperacyjności. Wykonawca zapewni pełną zgodność z wytycznymi, o których mowa w pkt. 2. Wymagań ogólnych, zgodnie ze stanem prawnym w dniu odbioru.
Pozostałe wymagania minimalne:
Wykonawca wprowadzi do Portalu treści przekazane przez Xxxxxxxxxxxxx, w tym wskazane przez Xxxxxxxxxxxxx treści z istniejących stron www (migracja dowolną metodą).
Portal zostanie zainstalowany na infrastrukturze serwerowej zapewnionej przez Zamawiającego i w domenie zapewnionej przez Zamawiającego. Wykonawca będzie odpowiedzialny za współpracę w tym zakresie z usługodawcą realizującym hosting strony, w tym również w zakresie uruchomienia Portalu pod właściwym adresem.
Wykonawca zobowiązuje się do wykazania na każde wezwanie Zamawiającego legalności kodu źródłowego portalu i prawa do jego używania.
Korzystanie z portalu musi być możliwe w sposób nieograniczony czasowo bez ponoszenia jakichkolwiek dodatkowych opłat (w tym cyklicznych, o charakterze abonamentu), wyłącznie na podstawie raz zakupionej licencji komercyjnej lub na podstawie licencji otwartej (wymaganie nie dotyczy kosztów hostingu).
Przeniesienie niezbędnych wymaganych przez Zamawiającego treści z obecnych stron internetowych Urzędu zostanie wykonane przez Wykonawcę.
Wykonawca przeprowadzi instruktaż z obsługi portalu (w tym systemu CMS) dla administratorów portalu w siedzibie Zamawiającego.
Zamawiający do czasu uruchomienia portalu, może zgłaszać zmiany do projektu graficznego, które Wykonawca zobowiązany jest wprowadzić.
Platforma usług publicznych udostępniająca dane z systemów dziedzinowych wraz z Systemem Elektronicznego Biura Obsługi Interesanta (EBOI)
Portal ma stanowić dedykowaną platformę dla klientów Starostwa Powiatowego w Lwówku Śląskim, którymi mogą być zarówno mieszkańcy, przedsiębiorcy czy inne osoby mające zobowiązania wobec Starostwa. Portal musi zostać zintegrowany z systemami dziedzinowymi Starostwa wspomagającymi realizację zadań ustawowych. Oferowane w ramach portalu usługi muszą być równoważne, co do wykonywanych usług w standardowym trybie, jednakże cały proces ma się odbywać automatycznie z wykorzystaniem rozwiązań informatycznych bez konieczności wizyty interesanta w siedzibie Starostwa. Portal ma udostępniać usługi informacji spersonalizowanych przeznaczone dla konkretnych podmiotów i obywateli, gdzie informacje będą udostępniane po ich uwierzytelnieniu. W ramach portalu ma być możliwość skierowania interesanta do dedykowanych formularzy elektronicznych udostępnionych na platformie elektronicznych usług publicznych ePUAP. Portal ma mieć również możliwość dokonywania płatności elektronicznych za wybrane wierzytelności.
Wymagania minimalne, niefunkcjonalne systemu/portalu EBOI:
System powinien umożliwiać pracę na bazie typu Open Source bądź na komercyjnym systemie bazodanowym.
System w warstwie serwera aplikacji i bazy danych powinien mieć możliwość uruchomienia min. w środowiskach opartych na systemach operacyjnych z rodziny Windows oraz w środowiskach opartych na systemie Linux.
System w warstwie klienckiej powinien poprawnie działać w różnych środowiskach z minimum 5 najbardziej popularnymi przeglądarkami w Polsce (zgodnie ze statystyką prowadzoną na stronie xxxx://xx.xxxxxxxxxxx.xxx/ za okres 6 miesięcy poprzedzających miesiąc ogłoszenia postępowania określoną dla komputerów stacjonarnych „desktop”).
System powinien realizować wszystkie czynności przez przeglądarkę internetową.
System powinien być skalowalny, poprzez możliwość dołączenia dodatkowych stanowisk komputerowych, zwiększenie zasobów obsługujących warstwę aplikacyjną, zwiększenie zasobów obsługujących warstwę bazy danych.
System powinien umożliwiać logowanie do portalu za pośrednictwem konta ePUAP z wykorzystaniem mechanizmu pojedynczego logowania SSO.
System powinien zapewniać spójność przechowywanych danych w bazie danych.
System powinien umożliwiać okresowe wykonywanie, w sposób automatyczny, pełnej kopii aplikacji i danych systemu.
System powinien posiadać funkcjonalność zarządzania dostępem do aplikacji:
administrator systemu powinien mieć możliwość tworzenia, modyfikacji oraz dezaktywacji kont użytkowników;
administrator systemu powinien móc nadawać uprawnienia użytkownikom;
administrator systemu powinien mieć możliwość przypisywać użytkowników do grup;
system zapewniać powinien podgląd listy użytkowników, którym udostępniono dostęp do portalu, wraz z danymi dotyczącymi nazwy, identyfikatora profilu zaufanego, daty utworzenia konta, statusu oraz metody logowania;
administrator powinien mieć podgląd do informacji o próbach logowania do systemu ze wskazaniem identyfikatora, daty, adresu IP z którego nastąpiło połączenie do portalu.
system pozwalać powinien na zmianę danych uwierzytelniających użytkownika.
System powinien posiadać możliwość określenie maksymalnej liczby nieudanych prób logowania, po przekroczeniu której użytkownik zostaje zablokowany.
System powinien się komunikować z systemami zewnętrznymi w sposób zapewniający poufność danych.
System powinien być odporny na znane techniki ataku i włamań, typowe dla technologii, w której został wykonany.
Docelowo system powinien być zintegrowany z modułami finansowo-księgowymi i podatkowymi w zakresie niezbędnym do realizacji funkcjonalności e-usług oraz systemem elektronicznego obiegu spraw i dokumentów.
System powinien prowadzić dziennik zdarzeń (w postaci logów systemowych) i dostępu do obiektów danych, dokumentów, operacji na słownikach umożliwiający odtwarzanie historii aktywności poszczególnych użytkowników systemu.
Wszystkie zadania administracyjne w ramach systemu powinny być wykonywane przez graficzny interfejs użytkownika, dostępny przez przeglądarkę www.
System powinien być zintegrowany z systemem dziedzinowym - wczytanie (import) danych na podstawie plików w formacie XML przekazanych z systemów dziedzinowych (systemy rozliczające opłaty, system rozliczający opłaty za gospodarowanie odpadami komunalnymi, system FK oraz systemy podatkowe funkcjonujące w urzędzie). Wymiana danych musi przebiegać poprzez bezpieczne, szyfrowane połączenie za pośrednictwem serwisów komunikacyjnych. Komunikacja z systemami dziedzinowymi powinna być oparta o technologię web service.
System powinien zawierać mechanizmy polegające na automatyzacji wymiany danych pomiędzy portalem a systemem dziedzinowym. Dostępność aktualnych danych nie może dodatkowo angażować operatorów systemów dziedzinowych.
W zakresie administrowania kontem system musi zapewnić generowanie haseł startowych dla użytkowników - hasła i konta użytkowników muszą być edytowane, dodawane tylko przez Administratora. W celu wygenerowania hasła dla użytkownika Portalu wymagane są co najmniej: typ identyfikatora (PESEL) oraz identyfikator, po wykryciu zalogowania się przez użytkownika po raz pierwszy system musi wymagać podania nowego hasła wraz z automatyczną dezaktywacją hasła startowego.
Wymagania minimalne, funkcjonalne systemu/portalu EBOI:
System powinien udostępniać wszystkie informacje dotyczące realizowanych e-usług bez konieczności zalogowania w systemie, w tym musi być możliwość pobrania formularzy przeznaczonych do wydruku.
Przy rejestracji elektronicznej do portalu system musi umożliwiać wyświetlenie regulaminu portalu i wymagać jego podpisania za pośrednictwem profilu zaufanego użytkownika.
System powinien umożliwiać uruchomienie e-usługi (poprzez złożenie wypełnionego e-formularza w ramach ustalonej procedury) tylko zarejestrowanym użytkownikom po zalogowaniu.
System powinien umożliwiać przekierowanie użytkownika do formularzy eusług, które zostały uruchomione na ePUAP.
System powinien umożliwiać zalogowanym użytkownikom dostęp do następujących funkcjonalności:
wypełnienie udostępnionego formularza, dołączenie załączników i wysłanie go do urzędu, otrzymując w odpowiedzi urzędowe poświadczenie przedłożenia;
wypełnienie formularza i jego wydrukowanie bez podpisywania podpisem elektronicznym;
podpisanie wysyłanych dokumentów profilem zaufanym ePUAP lub podpisem elektronicznym weryfikowanym przez certyfikat kwalifikowany;
uzyskanie informacji o zdarzeniach, które zaszły w związku ze złożonymi wnioskami;
podgląd decyzji lub postanowienia;
zapoznanie się z należnościami, a także odebrać odpowiednie dokumenty w postaci elektronicznej (potwierdzenie odbioru, wpłaty, treść wezwania);
uzyskanie informacji o stanie spraw i korespondencji, którą złożył do urzędu, a także o innych istotnych okolicznościach dotyczących przesyłanej do urzędu korespondencji i prowadzonych spraw (złożone i wymagane opłaty wraz z terminami wniesienia, informacja o pozytywnej lub negatywnej weryfikacji podpisu elektronicznego, okres procedowania sprawy, data odbioru dokumentu z decyzją administracyjną);
uzyskanie informacji o historii dokonywanych w skrzynce kontaktowej operacji (dostęp do logu operacji wraz z czasem ich wykonania);
zapoznanie się z metryką sprawy opisującą cały przebieg procedury, pobrać załączniki do wypełnienia na lokalnym komputerze;
wydrukowanie druku wpłaty do banku lub przelewu na blankiecie akceptowanym przez banki i Pocztę Polską;
dokonanie usunięcia własnego konta;
możliwość wydruku formularzy formacie pdf (przeznaczone do ręcznego wypełniania).
System powinien umożliwiać prezentację należności i rozrachunków dla zalogowanego użytkownika. System powinien umożliwiać wizualizację danych za pomocą tabel i pól informacyjnych pogrupowanych ze względu na obszary, których dotyczą dla każdej kartoteki w obszarach powiązanych z wdrażanymi e-usługami.
Dane do wizualizacji pobierane powinny być automatycznie z bazy systemów dziedzinowych za pośrednictwem usług serwisu SOAP uruchomionego w siedzibie Urzędu. Dostęp do portalu powinien być szyfrowany i zabezpieczony certyfikatem. Dane powinny być udostępniane tylko w odniesieniu do konta danego podatnika i po jego uwierzytelnieniu za pośrednictwem profilu zaufanego.
System powinien umożliwiać wnoszenie opłat z wykorzystaniem płatności elektronicznych.
System powinien umożliwiać użytkownikowi wskazanie płatności, które mają być uregulowane.
System powinien umożliwiać zalogowanemu użytkownikowi prezentację statusów należności.
System powinien umożliwiać dla należności objętych tytułami egzekucyjnymi, wobec których prowadzi egzekucję organ egzekucyjny, wskazywania jako rachunek właściwego do opłacenia należności rachunek organu egzekucyjnego.
System powinien umożliwiać wykorzystanie formularzy archiwalnych.
System powinien być zintegrowany co najmniej z dwoma systemami płatniczymi. Systemy płatnicze powinny posiadać zezwolenie Komisji Nadzoru Finansowego na świadczenie usług płatniczych w charakterze krajowej instytucji płatniczej lub realizować bezpośrednie płatności z konta płatnika na rachunek urzędu.
System musi posiadać przejrzystą prezentację należności z uwzględnieniem sald poszczególnych rat, terminów ich płatności oraz wysokości odsetek wraz z kosztami upomnień.
System musi zapewniać wyliczanie ogólnej kwoty należności.
System musi generować automatycznie informacje z systemów dziedzinowych o dokonanych wpłatach i przypomnieniach o zbliżających się terminach zapłaty należności do osób wyrażających zgodę na otrzymywanie takich informacji.
System musi umożliwiać dokonywanie wpłat zarówno dla użytkowników zalogowanych jak i tych którzy nie posiadają konta w systemie. W przypadku użytkowników niezalogowanych identyfikacja powinna być dokonywana na podstawie numeru z dokumentu ustalającej dane zobowiązanie i system wypełnia dowód wpłaty tylko w zakresie opisu należności i podania odpowiedniego konta na które należy dokonać zapłatę.
Użytkownik powinien mieć możliwość określić zakres powiadamiań (włączanie, wyłączanie usługi, konfigurowanie terminarza, określenie kanału powiadomień, określenie zakresu tematyki powiadomień)
Przesyłanie powiadomień dokonuje się wybranym przez użytkownika kanałem z uwzględnieniem wybranej przez niego tematyki i terminarza odbywa się automatycznie.
Dostęp do portalu powinien być zapewniony także z aplikacji mobilnych zarówno w zakresie dostępu do informacji o zobowiązaniach, dokonywania płatności jak i w zakresie otrzymywania powiadomień (metoda push).
Koniecznym do prawidłowego funkcjonowania systemu jest wykonanie prac w części back-office istniejących systemów dziedzinowych w urzędzie tak by moduł zapewnił obsługę e-usług w zakresie niezbędnym do ich realizacji, tj. zapewniał automatyzację następujących procesów:
Faktury przychodzące rejestrowane w systemie EZD muszą być kierowane bezpośrednio do modułu FK zapewniając jednokrotne wprowadzanie danych.
Umowy rejestrowane w systemie EZD kierowane są bezpośrednio do modułu Rejestr Umów zapewniając jednokrotne wprowadzanie danych.
Dokumenty elektroniczne dotyczące wszystkich typów deklaracji podatkowych (wypełnionych na ePUAP) muszą być przekazywane poprzez EZD do modułów podatkowych zapewniając pobierania metadanych z plików XML w systemie dziedzinowym.
Dokumenty elektroniczne dotyczące deklaracji za gospodarowania odpadami komunalnymi (wypełnionych na ePUAP), muszą być przekazywane poprzez EZD do modułów podatkowych zapewniając czytywanie metadanych z plików XML w dedykowanym module dziedzinowym.
Moduł komunikacji (stosowany przy wykorzystaniu urządzeń mobilnych) – wymagania minimalne:
Moduł musi umożliwiać wysyłanie drogą elektroniczną wiadomości o ważnych wydarzeniach i przedsięwzięciach realizowanych przez Urząd, zagrożeniach, czy indywidualnych sprawach związanych z obsługą obywateli.
Moduł musi umożliwiać wysyłanie wiadomości tylko do osób, które wyrażą na to zgodę pisemną i zostaną zarejestrowane w bazie odbiorców lub zarejestrują się osobiście w bazie odbiorców wiadomości za pośrednictwem platformy ePUAP i dedykowanego formularza.
Moduł musi być dostępny tylko dla zalogowanych użytkowników, pracowników urzędu.
Moduł musi być stworzony w technologii Web.
Moduł musi mieć interfejs użytkownika w całości w języku polskim.
Moduł musi umożliwiać tworzenie dowolnej liczby kont użytkowników pełniących minimum następujące role: 1) administratora systemu; 2) operatora wiadomości.
Moduł musi umożliwiać pracę dowolnej liczbie użytkowników jednocześnie.
Moduł musi umożliwiać zarządzanie danymi obywateli zarejestrowanych w systemie. W szczególności musi umożliwiać:
dodawanie, edytowanie i usuwanie danych obywateli zarejestrowanych w systemie;
czasowe wyłączenie konta mieszkańca;
resetowanie kodu walidacyjnego wykorzystywanego w aplikacji mobilnej.
Moduł musi umożliwiać wysyłanie wiadomości do odbiorców następującymi kanałami:
poczta email;
ePUAP,
sms (system musi umożliwiać integrację z zewnętrznym dostawcą usług bramki sms);
Moduł e-usług – wymagania minimalne:
Moduł musi umożliwiać wdrożenie wszystkich e-usług, które obejmie:
Odwzorowanie zaprojektowanych procesów biznesowych w systemach informatycznych wspierających świadczenie e-usług publicznych na 4 poziomie dojrzałości.
Wskazanie odpowiednich aktów prawnych jako źródeł wytycznych i ograniczeń dotyczących dokumentów odnoszących się do danej elektronizowanej usługi publicznej,
Identyfikację w treści dokumentów zapisów wymagających modyfikacji w wyniku elektronizacji usług publicznych.
Opracowanie kart usług zawierające podstawowe informacje dotyczące specyfiki danej usługi publicznej.
Opracowanie zbioru danych, które będą określać zestaw, sposób oznaczania, wymagalność elementów treści i metadanych dokumentu elektronicznego dla każdej e-usługi publicznej.
Analizę dostępności formularzy elektronicznych w Centralnym Repozytorium Wzorów Dokumentów Elektronicznych pod kątem możliwości ich wykorzystania w celu świadczenia wdrażanych w ramach projektu e-usług publicznych. W przypadku jeżeli nie będzie możliwości wykorzystania dla e-usługi publicznej formularzy dostępnych w CRWD prace obejmą przygotowanie i zgłoszenie formularzy ePUAP dla każdej z wybranych e-usług publicznych zgodnie z zapisami niniejszego załącznika.
Lista e-usług podlegających wytworzeniu – wymagania minimalne:
Wykonawca w ramach zamówienia wykona i uruchomi dla Powiatu Lwóweckiego formularze elektroniczne ePUAP , celem wdrożenia e-usług zgodnie z poniższą tabelą.
W ramach projektu Wykonawca zapewni poprawne działanie formularzy elektronicznych 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 Wykonawcę w okresie realizacji umowy. Wykonawca przeszkoli wskazanych pracowników Zamawiającego w zakresie wprowadzania nowych formularzy na platformę ePUAP.
Lp. |
E-USŁUGI |
Poziom dojrzałości usługi |
|
Obsługa zobowiązania z tytułu dzierżawy |
4 poziom |
|
Obsługa zobowiązania z tytułu wieczystego użytkowania |
4 poziom |
|
Uzyskanie zezwolenia na zajęcie pasa drogowego |
4 poziom |
|
Wydanie zaświadczenia |
4 poziom |
|
Zgłaszanie wniosków o informację publiczną z rejestru zawartych umów |
4 poziom |
W ramach projektu Wykonawca zapewni poprawne działanie formularzy elektronicznych 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 Wykonawcę w okresie realizacji umowy. Wykonawca przeszkoli wskazanego pracownika Zamawiającego w zakresie wprowadzania nowych formularzy na platformę ePUAP. Wykonawca zapewni aktualność uruchomionych formularzy elektronicznych przez okres trwania gwarancji i asysty technicznej.
Lp. |
Opis minimalnych wymagań dla oprogramowania/formularzy |
|
Formularze stosowane na ePUAP tworzone są z wykorzystaniem języka XForms oraz XPath. |
|
Wykonawca opracuje formularze elektroniczne (zgodnie z właściwymi przepisami prawa) na podstawie przekazanych przez Xxxxxxxxxxxxx kart usług z formularzami w formacie MS Word. |
|
Wszystkie formularze elektroniczne Wykonawca przygotuje z należytą starannością tak, aby pola do uzupełnienia w tych formularzach zgadzały się z polami formularzy w formacie MS Word. |
|
Pola wskazane przez Xxxxxxxxxxxxx jako pola obowiązkowe w formularzach w formacie MS Word, musza zostać polami obowiązkowymi również w formularzach elektronicznych. |
|
Układ graficzny wszystkich formularzy powinien być w miarę możliwości jednolity. |
|
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. |
|
Przygotowując formularze Wykonawca musi dążyć do maksymalnego wykorzystania słowników. |
|
W budowanych formularzach należy wykorzystać mechanizm automatycznego pobierania danych z profilu – celem uzupełnienia danych o wnioskodawcy. |
|
Formularze muszą musi zapewniać walidację wprowadzonych danych po stronie klienta i serwera zgodnie z walidacją zawartą w schemacie dokumentu. |
|
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ę. |
|
Po okresie testów, o których mowa w wymaganiu poprzednim, Zamawiający przekaże Wykonawcy ewentualne poprawki i uwagi dotyczące poszczególnych formularzy, które Wykonawca usunie bez zbędne zwłoki. |
|
Wykonawca przygotuje wzory dokumentów elektronicznych w CRD zgodnie ze standardem ePUAP w formacie XML zgodnym z formatem Centralnego Repozytorium Wzorów Dokumentów. |
|
Zamawiający dopuszcza możliwość wykorzystania przez Wykonawcę wzorów, które są już opublikowane w CRD. |
|
Wygenerowane dla poszczególnych formularzy wzory dokumentów elektronicznych, składające się z plików:
muszą zostać dostosowane do wymogów formatu dokumentów publikowanych w CRD i spełniać założenia interoperacyjności. |
|
W ramach projektu Wykonawca przygotuje i przekaże Zamawiającemu wszystkie wzory dokumentów elektronicznych w celu złożenia wniosków o ich publikację w CRD. |
|
Wykonawca udzieli wsparcia Zamawiającemu w przejściu procesu publikacji na ePUAP. |
|
Bazując na przygotowanych wzorach dokumentów elektronicznych oraz opracowanych na platformie ePUAP formularzach elektronicznych Wykonawca przygotuje instalacje aplikacji w środowisku ePUAP. |
|
Aplikacje muszą być zgodne z architekturą biznesową ePUAP oraz architekturą systemu informatycznego ePUAP. |
|
Zainstalowane aplikacje muszą spełniać wymogi ePUAP oraz pozytywnie przechodzić przeprowadzone na ePUAP walidacje zgodności ze wzorami dokumentów. |
|
Na czas realizacji umowy Zamawiający zapewni Wykonawcy dostęp do części administracyjnej platformy ePUAP konta Zamawiającego z uprawnieniami do konsoli administracyjnej Draco, ŚBA i usług. |
|
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. |
|
Zamawiający przekaże Wykonawcy opisy usług w formacie MS Word. |
|
Zamawiający dopuszcza, aby Wykonawca wykorzystał opisy usług umieszczone na platformie ePUAP. |
|
Zadaniem wykonawcy jest odpowiednie powiązanie opisów usług zamieszczonych na ePUAP z odpowiednimi usługami opracowanymi przez JST. |
|
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. |
|
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. |
|
Zadaniem Wykonawcy jest udostępnienie na platformie ePUAP listy formularzy dla e-usług określonych w tabeli powyżej. |
Biuletyn Informacji Publicznej zintegrowany z systemem EZD
Przedmiotem zamówienia jest modernizacja obecnego lub dostawa nowego systemu Biuletynu Informacji Publicznej spełniającego wymagania prawne określone dla BIP. System/biuletyn musi realizować integracje założone w pozostałych punktach OPZ:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Serwis musi być wyposażony w wyszukiwarkę, która pozwala na szybkie odnalezienie dokumentów zawierających interesujące użytkownika wyrazy lub wyrażenia. |
|
Zastosowany musi być wspólny dla wszystkich dokumentów układ i struktura. |
|
Użytkownik musi mieć możliwość wydrukowania dokumentów za pomocą jednego „kliknięcia” lub ściągnięcia ich na lokalny dysk. Załączone druki i formularze powinny być możliwe do wydrukowania i wypełnienia ręcznego lub bez konieczności posiadania jakiegokolwiek edytora tekstów wypełnienia na komputerze i wydrukowania. Aktualizowane pola mają być zaznaczone na wydrukowanym dokumencie. |
|
Z systemem BIP musi współpracować aplikacja EZD, która realizuje, poza biuletynem ewidencję dokumentów i spraw. Jedną z opcji programu musi być eksport spraw z ewidencji programu i zasilenie bazy danych w BIP. |
|
Dostawa, wdrożenie i hosting systemu BIP dla Zamawiającego na podstawie następującego scenariusza:
|
|
Wykonawca musi zapewnić:
|
|
Wymagania funkcjonalne serwisu BIP: Kreator – czyli sekcja, gdzie można kreować nowe elementy serwisu WWW. Sekcja ta musi dzielić się na następujące pozycje:
|
|
Sekcja Administrator – zawiera narzędzia administracyjne:
|
|
Sekcja Kontrola musi zawierać następujące działy:
|
|
Import dokumentów z systemu EZD. |
|
Możliwość personalizacji publikowanych dokumentów. |
|
Możliwość określenia terminów publikacji. |
|
Publikacja spraw z systemu EZD. |
|
Możliwość zagnieżdżania szablonów. |
|
Możliwość składania dokumentu z wielu szablonów. |
|
Możliwość definiowania dla każdego dokumentu indywidualnej funkcji prezentacji. |
|
Możliwość określenia funkcji wykonawczej/prezentacyjnej dla każdej pozycji w menu. |
|
Rozdział treści od aplikacji. |
|
Rozdział prezentacji od kodu |
|
System potwierdzeń publikacji dla ich autorów i administratora |
|
Przyporządkowanie historii zmian do określonego dokumentu. |
|
Dostęp do aplikacji w części administracyjnej możliwy jest po podaniu właściwego identyfikatora oraz hasła dostępu. |
System Elektronicznego Zarządzania Dokumentacją (EZD) wraz z elektronicznym archiwum zakładowym dla Starostwa Powiatowego oraz 1 jednostki organizacyjnej:
Minimalne wymagania technologiczne:
EZD musi być zbudowany w architekturze trójwarstwowej, złożonej z:
programu klienckiego (kod generowany dla przeglądarki internetowej);
serwera aplikacji (kod zarządzający aplikacją, wykonujący funkcje z zakresu logiki biznesowej, pośredniczący między żądaniami programu klienckiego a funkcjami udostępnianymi przez motor bazy danych);
motoru bazy danych, zarządzającego bazą danych.
EZD musi umożliwiać pracę na minimum jednej bazie komercyjnej oraz jednej bazie typu Open Source.
EZD musi posiadać interfejsy wykorzystujące jako technologię komunikacyjną usługi sieciowe (ang. Web-services) pozwalające na pobieranie danych oraz zasilanie danymi zewnętrznych systemów.
EZD musi posiadać możliwość rozbudowy, w szczególności umożliwiające wygodną implementację wszelkich procesów obiegów dokumentów i spraw zachodzących u Zamawiającego (dotyczy to rozszerzenia o integrację: OCR, SMS, oraz workflow).
EZD musi posiadać interfejs oparty na przeglądarce internetowej.
W ramach interfejsu Użytkownik musi posiadać możliwość korzystania ze wszystkich funkcjonalności EZD, które są dla niego udostępnione zgodnie z przypisanymi mu uprawnieniami.
Dopuszczalne formaty przetwarzanych plików nie mogą być ograniczone przez technologię Systemu.
Wszystkie dostarczane komponenty oprogramowania w ramach EZD muszą tworzyć jednolity system informatyczny, w szczególności poprzez:
wykorzystanie jednej wspólnej bazy danych (struktura tabel musi być jedna, wspólna dla wszystkich komponentów), w szczególności wszystkie dane muszą być zapisywane i odczytywane z jednej bazy danych;
wykorzystanie wspólnego interfejsu użytkownika;
wykorzystanie przez poszczególne komponenty wspólnych kartotek wspomagających (kartoteka interesantów, struktura organizacyjna oraz rejestry Zamawiającego);
wykorzystanie wspólnego i spójnego systemu uprawnień;
jedno miejsce logowania się do poszczególnych komponentów EZD.
Baza danych, w którym przechowywane są dokumenty powinna być ograniczona jedynie zasobami sprzętowymi serwera, system operacyjny serwera powinien zapewnić kontrolowany dostęp do zasobów bazy danych.
EZD musi być niezależny od wyboru pakietów biurowych (edytor tekstów, arkuszy kalkulacyjny itp.) służących do tworzenia i uaktualniania poszczególnych dokumentów przez pracowników Zamawiającego.
EZD musi cechować się interfejsem użytkownika opartym na rozwiązaniach typu: menu, listy, formularze, przyciski, referencje (linki) itp.
EZD musi umożliwiać rejestrację i nadzorowanie obiegu korespondencji wewnętrznej Zamawiającego (pomiędzy pracownikami i komórkami organizacyjnymi).
EZD musi umożliwiać rozproszoną rejestrację korespondencji wpływającej wraz z załącznikami oraz jej automatyczne numerowanie.
EZD musi rejestrować czynności związane z poszczególnym dokumentem (np. dekretacji) w postaci historii, przypisując jednoznacznie odpowiedzialność za każdą czynność i dając możliwość szybkiego odczytania tych informacji.
EZD musi zapewniać jednoznaczne przypisanie odpowiedzialności za każdy z dokumentów.
EZD musi posiadać możliwość nadawania terminów realizacji związanych ze sprawą, korespondencją, zadaniem.
EZD musi posiadać wbudowany moduł archiwalny, w pełni obsługujący wszystkie podstawowe procesy związane z archiwizacją dokumentów (w tym: tworzenie spisów zdawczo-odbiorczych, brakowanie, przekazywanie do Archiwum Państwowego).
EZD musi być w pełni zgodny z obowiązującymi procedurami postępowania z materiałami archiwalnymi i dokumentacją niearchiwalną.
Musi być możliwość rejestracji wybranych wiadomości e-mail jako pism w module.
Środowisko systemu powinno umożliwiać udostępnianie usług WebService.
System powinien posiadać API umożliwiające integracje z dowolnym systemem zewnętrznym.
EZD musi zapewniać wysoki stopień bezpieczeństwa i poufności dla zgromadzonych dokumentów oraz danych, w tym zapewniać ochronę zawartości dokumentów przed nieautoryzowanymi zmianami.
Poziom zabezpieczeń danych musi być zgodny z ustawodawstwem i odpowiedni dla ochrony danych osobowych.
EZD musi zapewniać szyfrowanie w stopniu uniemożliwiającym odczytanie przez osoby postronne wszystkich danych wymienianych między pracownikami Zamawiającego oraz między Zamawiającym a Interesantem.
EZD musi zapewniać bezpieczeństwo przesyłanych danych (przesyłanie danych z użyciem protokołu SSL).
EZD musi umożliwiać jednoczesny dostęp do danych wielu użytkownikom przy zapewnieniu ochrony tych danych przed utratą spójności lub zniszczeniem.
EZD musi posiadać hierarchię uprawnień oraz granulację dostępu do jego zasobów.
Każdy użytkownik EZD musi dysponować indywidualnym identyfikatorem, który umożliwi korzystanie z udostępnionych zasobów i usług. Dostępne mechanizmy oraz procedury muszą zapewnić rozliczalność zarejestrowanych w module użytkowników.
W module musi być przechowywany skrót hasła wyliczony za pomocą bezpiecznej do zastosowań kryptograficznych jednokierunkowej funkcji mieszającej. Hasło użytkownika utrwalone w bazie danych nie może być zapisane otwartym tekstem. EZD musi przechowywać postać hasła po przetworzeniu algorytmem bezpiecznej do zastosowań kryptograficznych jednokierunkowej funkcji mieszającej (np. MD5 lub SHA).
EZD musi zapewniać możliwość:
narzucenia minimalnej długości hasła oraz obowiązku wykorzystania różnych rodzajów znaków w haśle (np. liter, cyfr i znaków specjalnych);
ustalenia czasu obowiązywania hasła, hasła powinny być szyfrowane.
EZD musi zapewnić blokowanie dostępu określonych użytkowników do zasobów Systemu.
EZD ma zapewniać autoryzację wszystkich operacji wprowadzania, modyfikowania i usuwania danych. EZD ma umożliwiać identyfikację osoby, która wykonała powyższe operacje oraz czas ich wykonania.
EZD musi zapewnić ochronę dokumentów przed nieautoryzowanymi zmianami.
Każda czynność wykonywana w module musi być zapisywana , tak aby możliwa była identyfikacja osoby wykonującej czynność, obiektów których dotyczyła czynność oraz czasu wykonania czynności.
EZD ma zapobiegać możliwości wprowadzenia i uruchomienia złośliwego kodu do aplikacji działających na serwerach.
EZD powinien być skalowalny, tzn. umożliwiać dołączenie dodatkowych stanowisk (zwiększenie liczby użytkowników) oraz zwiększenie i rozbudowę zasobów komputerowych poprzez rozbudowę warstwy aplikacyjnej (zwiększenie zasobów komputerów obsługujących warstwę poprzez rozbudowę pamięci, zwiększenie liczby procesorów oraz zwiększanie liczby maszyn) oraz rozbudowę warstwy bazodanowej (zwiększenie zasobów komputerów obsługujących warstwę poprzez rozbudowę pamięci, zwiększenie liczby procesorów, zwiększenie pojemności pamięci masowych).
Wykonawca powinien dostarczyć narzędzie służące do wykonywania automatycznej oraz ręcznej kopii zapasowej EZD. Przy kopii automatycznej administrator ma mieć możliwość zdefiniowania konkretnego terminu wykonania kopii lub terminu powtarzającego się cyklicznie. Narzędzie to ma umożliwiać wykonywanie co najmniej dwóch rodzajów kopii:
pełną kopię bezpieczeństwa (kopia, która umożliwia przywrócenie systemu wraz z wszystkimi ustawieniami, z bazą danych oraz dokumentami);
różnicową kopię (aktualizuje kopię pełną o dane, które uległy zmianie).
Minimalne wymagania ogólne:
Wszystkie dostarczone elementy zamówienia musza być kompletne, posiadać wszystkie wymagane do poprawnego eksploatowania instrukcje, licencje i gwarancje.
Interfejs użytkownika systemu musi być w całości polskojęzyczny, podobnie jak instrukcje obsługi. W języku polskim muszą być również wyświetlane wszystkie komunikaty przekazywane przez system, włącznie z komunikatami o błędach.
EZD musi posiadać dwa rodzaje interfejsów graficznych menu: tekstowy i ikonowy. Musi być możliwe jednoczesne ich użycie.
System musi być wyposażony w pomoc kontekstową – na każdym z ekranów musi być możliwość zobaczenia instrukcji przeznaczonej wyłącznie dla danego ekranu,
EZD musi umożliwić tworzenie i prowadzenie rejestrów, wprowadzanie korespondencji: pism wpływających, wychodzących, wewnętrznych, prowadzenie spraw i zapisywanie dokumentów.
System musi zapewniać wsparcie dla trybu tradycyjnego wykonywania czynności kancelaryjnych, dokumentowania przebiegu załatwiania spraw, gromadzenia i tworzenia dokumentacji w postaci nieelektronicznej oraz umożliwiać wskazanie go jako systemu EZD, podstawowego sposobu dokumentowania przebiegu i rozstrzygania spraw.
EZD musi zapewnić wyświetlanie danych nt. wielu spraw, dokumentów jednocześnie.
EZD musi zapewnić zgodność obiegu dokumentów z wymogami instrukcji kancelaryjnej.
EZD musi zapewniać jednoznaczne przypisanie odpowiedzialności za każdy z dokumentów.
EZD musi posiadać możliwość nadawania terminów realizacji związanych z daną dekretacją/zadaniem, pismem wpływającym, sprawą.
EZD musi posiadać wbudowany moduł archiwalny, w pełni obsługujący wszystkie podstawowe procesy związane z archiwizacją dokumentów (w tym: tworzenie spisów zdawczo-odbiorczych, brakowanie, przekazywanie do Archiwum Państwowego).
EZD musi być w pełni zgodny z obowiązującymi procedurami postępowania z materiałami archiwalnymi i dokumentacją niearchiwalną.
EZD musi umożliwić druk zestawień i raportów oraz definiowanie szablonów raportów dla danych zgromadzonych w modułach EZD.
EZD musi umożliwiać rozproszoną rejestrację wszelkiej korespondencji każdego typu wpływającej/wychodzącej Zamawiającego wraz z załącznikami oraz jej automatycznym numerowaniem i asygnowaniem w postaci kodu kreskowego.
EZD musi zapewniać obieg dokumentów zarówno tych wprowadzonych drogą elektroniczną, jak i zeskanowanych dokumentów papierowych.
EZD musi zapewniać obsługę dokumentów zgodną z JRWA Zamawiającego.
EZD musi umożliwiać prowadzenie co najmniej następujących ewidencji:
ewidencję struktury organizacyjnej Zamawiającego;
ewidencję pracowników i stanowisk pracy;
ewidencję rejestrowanych dokumentów z podziałem na co najmniej: ewidencja pism wpływających, ewidencja pism wychodzących, ewidencja pism wewnętrznych;
ewidencję spraw;
ewidencję dokumentów archiwalnych.
Każda z ewidencji musi zapewniać możliwość dostępu do danych w różnych widokach (np. "Rejestr spraw zakończonych", "Rejestr moich spraw", "Rejestr spraw w dziale") dostępnych dla użytkowników zgodnie z uprawnieniami.
EZD musi umożliwić dostęp do dokumentów i danych w sposób uporządkowany i szybki np. Ustaw, Wewnętrznych Aktów Normatywnych takich jak: zarządzenia, umowy, faktury, protokoły;
EZD musi umożliwić tworzenie grup dokumentów podręcznych.
System powinien umożliwiać skanowanie masowe z automatycznym przyporządkowaniem zeskanowanych załączników do odpowiednich dokumentów.
EZD musi rejestrować każdą czynność związaną z poszczególnym dokumentem, np. w postaci historii, przypisując jednoznacznie odpowiedzialność za każdą czynność i dając możliwość szybkiego odczytania tych informacji.
Historia musi pokazywać upływ czasu pomiędzy wykonaniem poszczególnych czynności.
EZD musi zapewniać możliwość przekazywania pojedynczych dokumentów dostępną z poziomu „metryczki” dokumentu/sprawy jak i możliwość przekazywania zbiorczego z automatycznie tworzonym wydrukiem z przekazywanych dokumentów do pokwitowania.
EZD powinien zapamiętywać profile pracy poszczególnych użytkowników w każdym z modułów i udostępniać je po zalogowaniu na dowolnej stacji roboczej, powinien stale wyświetlać na ekranie informację o osobie zalogowanej lub pracy w zastępstwie.
EZD musi być wyposażony w funkcjonalność komunikatora tekstowego. Komunikator musi być wewnętrznym oprogramowaniem dla Zamawiającego i nie może umożliwiać komunikacji z zewnętrznymi komunikatorami dostępnymi publicznie. Komunikator musi być wyposażony w system powiadomień o istotnych zdarzeniach systemowych co najmniej w zakresie:
powiadomienia o przekazaniu dokumentów;
powiadomienia o przekazaniu dokumentu do akceptacji;
powiadomienia o zaakceptowaniu dokumentu;
powiadomienia o dekretacji dokumentu.
Komunikator ma służyć tylko do komunikacji wewnątrz jednostki. Przekazywanie komunikatów musi być możliwe również wtedy, gdy użytkownik nie ma uruchomionego EZD na swojej stacji roboczej. Musi być możliwe zapisanie treści w formie notatki, bezpośrednio z poziomu poleceń komunikatora (również tych z konferencji).
Komunikator musi być wyposażony w automatyczne:
dodawanie użytkowników z podziałem na grupy zgodnie ze strukturą organizacyjną zdefiniowaną w module;
integrację danych użytkowników (login, nazwa pełna, dane opisowe) z bazą użytkowników systemu module;
usuwanie użytkowników z komunikatora w przypadku zablokowania użytkownika w module.
Uwierzytelnienie klienta w serwerze komunikatora ma być możliwe za pomocą zaszyfrowanych haseł.
Musi być możliwe wysyłanie komunikatów do grup odbiorców, przesyłania plików, zrzutów z ekranu.
Komunikator EZD musi umożliwiać użytkownikowi skonfigurowanie otrzymywania powiadomień systemowych co najmniej o następujących zdarzeniach:
otrzymaniu nowych dokumentów;
przydzielenie nowego zadania;
zaakceptowane pisma, których jest referentem;
odrzucone pisma, których jest referentem;
niedoręczenie pisma.
EZD powinien umożliwiać zarządzanie czasem i spotkaniami za pomocą kalendarza oraz listy zadań do wykonania.
EZD powinien umożliwiać dowolne katalogowanie, wyszukiwanie i analizowanie wprowadzanych informacji.
EZD powinien umożliwiać wielopoziomowe ustawienia uprawnień.
EZD powinien posiadać mechanizm umożliwiający swobodne korzystanie z kwalifikowanego i powszechnego podpisu elektronicznego bez konieczności posiadania fachowej wiedzy.
Funkcja podpisu elektronicznego musi umożliwiać podpisywanie jednego elementu systemu przez wielu użytkowników. Podpis musi być opisany w formacie XAdES preferowany przez MSWiA. Informacja o podpisie musi być prezentowana użytkownikowi.
Funkcja podpisu elektronicznego musi umożliwiać poprawne wykorzystanie certyfikatów kwalifikowanych pochodzących od wszystkich certyfikowanych wystawców.
EZD musi umożliwiać sygnalizowanie, że dany dokument jest podpisany elektronicznie, bez konieczności otwierania tego dokumentu,
EZD musi umożliwiać podpisywanie plików podpisem elektronicznym z poziomu EZD (bez konieczności ręcznego uruchamiania dodatkowego oprogramowania), musi umożliwiać podpisywanie dokumentów przygotowanych w dowolnym formacie.
EZD musi umożliwiać weryfikację podpisu elektronicznego z poziomu EZD (bez konieczności ręcznego uruchamiania dodatkowego oprogramowania).
EZD musi umożliwiać podpisywanie dokumentów profilem zaufanym.
EZD musi umożliwiać weryfikację podpisu profilem zaufanym.
EZD musi umożliwiać definiowanie obok dokumentów również obiektów typu: zdarzenia, posiedzeń rady, wyjazdów służbowych, kontroli i prowadzenia ich rejestrów.
EZD musi umożliwiać zarządzanie zastępstwami w przypadku choroby lub urlopu.
EZD musi umożliwiać druk zestawień i raportów oraz definiowanie szablonów raportów dla wszelkich danych zgromadzonych w systemie.
EZD musi umożliwiać eksport wydruku do formatów minimum PDF, ODT, DOC, DOCX, XML, XLS, XLSX, TXT, CSV, RTF.
EZD musi posiadać centralną numerację dokumentów, gwarantującą unikalność numeracji w całym systemie. EZD musi nadawać automatycznie numer wszystkim zidentyfikowanym rodzajom dokumentów.
W module musi być możliwe zarządzanie dostępem użytkowników zarówno do odpowiedniego typu dokumentów (grup dokumentów, teczek), jak i funkcji systemu.
Obsługa wyszukiwania – wymagania minimalne:
EZD musi być wyposażony w wyszukiwarkę umożliwiającą wyszukanie odpowiednich dokumentów (i innych obiektów) oraz interesantów według predefiniowanych atrybutów (kryteriów wyszukiwania).
EZD musi generować zestawianie wykazów wyszukanych dokumentów wraz ze wskazaniem wystąpień poszukiwanych fraz.
EZD musi umożliwiać identyfikowanie i wyszukiwanie dokumentów na podstawie sygnowania w module np. poprzez kod kreskowy.
EZD musi umożliwiać przeszukiwanie bazy interesantów.
EZD musi umożliwiać zapisywanie w celu ponownego użycia zdefiniowanych warunków wyszukiwania.
EZD musi umożliwiać wyszukiwanie w bazie interesantów pozycji powiązanych (pracownicy, instytucje powiązane).
EZD musi umożliwiać wyszukiwanie obiektów po wszystkich opisujących je metadanych, w szczególności EZD musi zapewnić wyszukiwanie dokumentów po nr JRWA, nadawcy, numerze pisma, dacie rejestracji pisma itp.
Obsługa kontrahentów – wymagania minimalne:
EZD musi posiadać jedną, dla całego systemu w ramach jednostki, bazę kontrahentów, dostępną dla wszystkich osób pracujących w module.
Dopisywanie nowych adresatów i ich edycja musi być możliwe do ograniczenia tylko dla określonej grupy użytkowników.
EZD musi umożliwiać przypisanie dla jednego dokumentu wielu adresatów oraz umożliwiać wybór adresatów z bazy.
EZD musi umożliwiać automatyczne podpowiadanie nadawcy/odbiorcy korespondencji na podstawie wbudowanego w module słownika - książki adresowej.
EZD musi umożliwiać automatyczne sprawdzenie poprawności wprowadzanych danych typu NIP, PESEL, REGON.
EZD musi zachowywać dane adresowe historyczne w dokumentach z jednoczesną możliwością ich aktualizacji.
EZD musi posiadać mechanizm ostrzegania zapobiegający dublowaniu wpisów w bazie adresowej, oraz mechanizm umożliwiający porządkowanie bazy, dający możliwość zastąpienia nieprawidłowo wpisanych danych wpisem prawidłowym – informacja nt. wykonania takiego scalenia i informacje kto i jakie dane scalił musi się znaleźć w historii adresata.
Scalanie danych adresowych nie może powodować zmian w już zarejestrowanych dokumentach, a jedynie usunięcie scalonej pozycji z bazy adresowej i brak możliwości jej ponownego wykorzystania.
EZD musi umożliwiać zastrzeżenie danych osób prowadzących jednoosobową działalność gospodarczą.
Obsługa korespondencji przychodzącej – wymagania minimalne:
EZD musi zapewniać pełną obsługę obiegu wewnętrznego korespondencji:
wielopoziomowe dekretowanie i przekazywanie pism (oryginałów) do podległych komórek organizacyjnych i pracowników;
wycofywanie niewłaściwie zadekretowanej i przekazanej korespondencji;
dekretowanie i przekazywanie kopii pism kierowanych „do wiadomości” pracowników i komórek organizacyjnych, przekazywanie na dowolną osobę, możliwość przekazywania oryginału z zachowaniem kopii u użytkownika przekazującego.
EZD musi umożliwiać dekretację z metryczki pojedynczych pism oraz dekretację wykonywaną ze zbiorczych zestawień korespondencji, gdzie pisma są dekretowane na wybrany wcześniej wydział bądź pracownika, już tylko przez zaznaczenie wierszy zawierających dane kolejnych pism.
EZD musi zapewniać zwrot pisma błędnie zadekretowanego, tzw. wycofanie, tą samą ścieżką jaką pismo dotarło na stanowisko.
EZD musi zapewniać odnotowanie powodu zwrotu korespondencji.
EZD musi umożliwiać jednoczesne przekazywanie pism na stanowiska.
EZD musi umożliwiać wraz z przekazywaniem pism na stanowiska zwroty korespondencji jeżeli zestawienie pism dekretowanych np. przez kierownika zawierało pisma zwracane.
EZD musi zapewniać możliwość rejestracji korespondencji przychodzącej w dowolnie zdefiniowanych dziennikach (rejestrach), na wielu stanowiskach równocześnie.
EZD musi zapewniać przeglądanie danych, rejestrację nowych pism i modyfikowanie zarejestrowanych. Nie może pozwalać na fizyczne usuwanie wcześniej zarejestrowanych pism, a jedynie na ich oznaczenie jako skasowanych.
EZD musi umożliwiać pracownikowi kancelarii oznaczenie, że pismo zwrócone z komórki zostało już fizycznie odebrane w kancelarii.
EZD musi zapewniać rejestrację papierowej korespondencji przychodzącej wraz z załącznikami i wielostronicowe skanowanie jej z poziomu systemu do postaci elektronicznej.
EZD musi umożliwiać zapisanie daty wpływu do organizacji Zamawiającego, oraz daty nadania. Dodawanie dat powinno być umożliwione poprzez wybór daty z kalendarza lub wypełnienie pola. Wszystkie pola daty powinny zawierać zdefiniowane maski odpowiadające wymaganym formatom daty. Pole z datą wpływu do Zamawiającego powinno być wypełniane automatycznie i podlegać możliwość edycji.
EZD musi zapewniać przeprowadzenie rejestracji pisma z użyciem „myszki” oraz za pomocą tylko klawiatury.
EZD musi zapewniać wydruk potwierdzenia przyjęcia korespondencji ze wskazaniem na: numer pisma, datę wpływu pisma, ilość (wykaz) załączników a także unikalny identyfikator (numer) pod którym zostało zarejestrowane we właściwym rejestrze, dane interesanta oraz kod kreskowy zawierający numer, identyfikujący dokument i umożliwiający sprawdzenie stanu załatwienia sprawy przez petenta.
EZD musi zapewniać drukowanie pieczęci wpływu i sygnowanie korespondencji np. za pomocą drukarki etykiet samoprzylepnych, znakowanych kodem kreskowym, również po przekazaniu pisma na stanowisko, identyfikację za pomocą czytnika kodów kreskowych.
EZD musi zapewniać zmianę wielkości etykiety oraz orientacji wydruku.
W każdym z rejestrów EZD musi zapewniać możliwość dostępu do danych w różnych widokach (np. "nowe", "zadekretowane", "wszystkie") dostępnych dla użytkowników, musi umożliwiać sortowanie widoków wszystkich wyświetlanych rejestrów poprzez kliknięcie nagłówka kolumny (data wpływu, numer, nadawca, termin, dysponent).
EZD w czasie rejestracji dokumentu musi automatycznie nadawać kolejny numer korespondencji zgodnie z Instrukcją Kancelaryjną.
EZD musi zapewniać drukowanie pokwitowania przekazania pism do komórek organizacyjnych i pracowników, w układzie odzwierciedlającym kolejność rejestracji i z podziałem na komórki/pracowników (pisma dla komórki/pracownika zsumowane na odrębnym wydruku pokwitowania).
EZD musi umożliwiać klasyfikowanie (kategoryzowanie) pism wg dowolnie zdefiniowanego przez użytkownika słownika.
Dostęp do szczegółów obiektów ma być możliwy z poziomu ekranów przeglądania pism (dzienników korespondencji wpływającej).
Automatyczne rejestrowanie historii życia pisma od momentu zarejestrowania go oraz drogi obiegu pomiędzy komórkami organizacyjnymi i pracownikami jednostki oraz czasów zatrzymania.
Współpracę z systemem GUS – TERYT.
Przy stosowaniu słowników TERYT musi istnieć możliwość globalnego dla całego systemu uaktywnienia słownika bądź wyłączenia.
Ustalanie terminów rozpatrywania i załatwiania spraw związanych z pismem.
Definiowanie formatek dla pism napływających masowo, o powtarzających się tematach, terminach realizacji, usprawniających rejestrację i zwierających gotowe dane (minimum: tematy, terminy, dekretacja).
Zestawianie statystyk i raportów dotyczących korespondencji przychodzącej oraz drukowanie tych raportów.
EZD ma umożliwiać tworzenie składów chronologicznych, wraz z ewidencją: zwrotów, wycofań, szukanie po kodzie kreskowym, ewidencję i historię wypożyczeń.
EZD musi zapewnić archiwizację zawartości składów chronologicznych.
W przypadku niezgodności danych z pisma z danymi nadawcy znajdującymi się w bazie interesantów system musi zapewniać możliwość x.xx. zmiany danych w bazie adresowej.
EZD posiadać powinien możliwość przechowywania danych historycznych (poprzednich adresów).
EZD musi opisywać dokumenty za pomocą formularza (metryki) zawierającego najważniejsze informacje (np. dane teleadresowe) o danym dokumencie, w przypadku dokumentów elektronicznych odpowiednie pola są wypełnione automatycznie.
Metryka korespondencji przychodzącej musi zawierać między innymi pola określające: dysponenta, osoby które otrzymały pismo do wiadomości, data wpływu, nadawca, termin załatwienia, listę załączników elektronicznych, odnośnik do sprawy w której pismo zostało umieszczone (musi być możliwe ograniczenie umożliwiające użytkownikom nie będącym dysponentami pism wpływających blokowanie dostępu do szczegółów sprawy).
EZD musi umożliwić dołączanie pism do spraw będących w procedowaniu.
Obsługa korespondencji wychodzącej – wymagania minimalne:
EZD powinien wspomagać pracę kancelarii jednostki w zakresie adresowania i ekspedycji pism wychodzących. Powinien generować wykazy pism poleconych i dostarczanych przez gońców.
EZD musi umożliwiać zdefiniowanie wielu kancelarii/sekretariatów odpowiedzialnych za wysyłkę korespondencji.
EZD musi umożliwiać tworzenie i wydruk zestawień korespondencji poleconej, zwykłej, w formatach wymaganych przez operatora pocztowego – książka nadawcza.
EZD musi umożliwiać rejestrację pism wychodzących na każdym stanowisku.
EZD musi umożliwiać wysyłkę e-maili bezpośrednio z systemu.
EZD musi umożliwiać rejestrację w systemie maili wysłanych z programu pocztowego z automatycznym umieszczaniem: danych adresowych, tematu, załączników w dedykowanych polach systemu.
Metryka korespondencji wychodzącej musi zawierać między innymi pola określające: dysponenta, datę, adresata, lista załączników elektronicznych, data i sposób wysyłki, odnośnik do sprawy w której pismo zostało umieszczone (musi być możliwe ograniczenie umożliwiające użytkownikom nie będącym dysponentami pism wychodzących blokowanie dostępu do szczegółów sprawy).
EZD musi umożliwiać dołączanie: plików, skanów, uwag do pisma w dedykowanym polu.
EZD musi umożliwiać wersjonowanie pism.
EZD musi umożliwiać klasyfikację pism wg dowolnie zdefiniowanego przez użytkownika słownika, co najmniej w zakresie: rodzaju pisma (decyzja, umowa, itd.) oraz hasłowo, czego dotyczy korespondencja.
EZD musi umożliwiać zaznaczenie różnych sposobów wysyłki (lista sposobów wysyłki edytowalna dla administratora) dla pisma wychodzącego kierowanego jednocześnie do strony postępowania i stron zainteresowanych.
EZD musi umożliwiać zmianę sposobu wysyłki korespondencji w sekretariacie.
EZD musi umożliwiać podczas wydruku etykiet w kancelarii dodanie przez kancelarię zwrotu grzecznościowego, np. Sz.P. do etykiety.
Przy rejestracji korespondencji z poziomu konkretnej sprawy automatycznie musi podpowiadać domyślnego adresata, czyli nadawcę pisma wiodącego, umożliwiać zmianę oraz umożliwiać wybór adresatów określonego typu (wewnętrzny, zewnętrzny, ePUAP, e-mail, etc).
EZD musi umożliwiać generowanie treści pism wychodzących i załączników w oparciu o zdefiniowane szablony z automatycznym uzupełnianiem danymi pochodzącymi z bazy danych co najmniej pól: nr pisma wychodzącego, nr sprawy, temat, data utworzenia, dane adresowe strony postępowania (minimum: nazwisko, imię, instytucję, kod pocztowy, nazwę miejscowości, nazwę ulicy, numer domu i lokalu, NIP, REGON, PESEL), dane adresowe stron zainteresowanych (pola jak dla stron), pole uwagi, dane autora dokumentu, jego stanowisko, nazwa komórki, lokalizacja, sposób wysyłki, kod kreskowy.
Obsługa akceptacji pism – wymagania minimalne:
EZD musi umożliwiać podpisywanie pism i załączników podpisem elektronicznym kwalifikowanym i niekwalifikowanym z poziomu aplikacji, z możliwością wielokrotnego podpisywania dokumentu przez osoby akceptujące.
EZD musi umożliwiać ustalenie przez pracownika, w jaki sposób chce skierować korespondencję do adresata i przekazać ją do Kancelarii w celu wysłania – wybór sposobu wysyłki min.: poczta (polecony, zwykły, ze zwrotką), osobiście, goniec, kancelaria, e-mail, ePUAP.
EZD musi umożliwiać generowanie i wydruk kopert i zwrotek z adresatami, zarówno w kancelarii, jak i na stanowiskach użytkowników.
EZD musi umożliwiać zaznaczenie powrotu zwrotki z poziomu obsługi pism wychodzących w kancelarii jak i z poziomu pracownika.
EZD musi umożliwiać drukowanie adresów za pomocą drukarki etykiet samoprzylepnych, drukowanie adresów wraz z kodem kreskowym.
EZD musi umożliwiać wydruk pism w formacie umożliwiającym stosowanie kopert z okienkiem.
Wysyłka dokumentów przez kancelarię wychodzącą powinna wspierać agregację przesyłek do jednego adresata.
EZD musi umożliwiać określenie parametrów przesyłki (w tym, x.xx.: forma przesyłki, gabaryty przesyłki). Wybór parametrów tam gdzie to możliwe powinien odbywać się z list słownikowych (listy słownikowe powinny podlegać edycji).
EZD musi umożliwiać dokonywanie nadruków kodów kreskowych na zwrotkach.
W przypadku wysyłek wysyłanych za zwrotnym poświadczeniem odbioru (zwrotka) EZD umożliwiać powinien wyszukanie przesyłki po kodzie kreskowym ze zwrotki lub numerze sprawy oraz odnotowanie faktu doręczenia, daty odbioru, bądź faktu nie doręczenia przesyłki.
EZD musi umożliwiać wpisanie numeru r-ki.
EZD musi umożliwiać rejestrowanie oraz powiązanie z odpowiednim dokumentem potwierdzenia dostarczenie pisma adresatowi (tzw. Zwrotka).
EZD musi umożliwiać skanowanie zwrotek pism z poziomu ekranu rejestracji zwrotki.
EZD musi umożliwiać zmianę sposobu wysyłki, zaznaczenie braku doręczenia pisma wraz z możliwością wpisania powodu nie doręczenia, (z jednoczesnym zapisem tych informacji w historii pisma) ponowne skierowanie do wysyłki z jednoczesną możliwością zmiany sposobu wysyłki z poziomu kancelarii.
EZD musi umożliwiać zaznaczenie odebrania osobistego pisma (z zapisem daty odbioru osobistego) z poziomu pracownika jak i z poziomu kancelarii, z możliwością skierowania pisma do wysyłki pocztą w przypadku braku odbioru osobistego.
EZD musi umożliwiać łączenie/wyłączanie kilku pism w koperty/paczki w celu wspólnej wysyłki do jednego adresata, po utworzeniu wspólnej koperty wpisanie nr r-ki i daty z tzw. „zwrotki” dla wspólnej koperty ma skutkować aktualizacją zapisów na poszczególnych pismach wchodzących w skład koperty.
EZD musi umożliwiać automatyczny wydruk książki nadawczej co najmniej w formacie graficznym akceptowanym przez Pocztę Polską.
Musi być możliwe wyszukiwanie pism po kodzie kreskowym widocznym na etykiecie, po nr r-ki, po sposobie doręczenia i etapie doręczania: wysłane, nie doręczone, skierowane do ponownej wysyłki.
W przypadku wysyłki za zwrotnym potwierdzeniem odbioru możliwość przeglądania na zbiorczym zestawieniu wszystkich dat odebrania poszczególnych dokumentów z możliwością ich sortowania: rosnąco, malejąco.
Obsługa spraw, obiegu zadań oraz obiegu korespondencji wewnętrznej – wymagania minimalne:
W zakresie obsługi spraw system musi umożliwiać:
procedowanie sprawy zgodnie z obiegiem;
przygotowanie pism wychodzących;
gromadzenie pism w sprawie;
wprowadzenie uwag przez uprawnione osoby do dokumentów;
akceptację pism w sprawie.
EZD musi umożliwiać prowadzenie spraw w oparciu o system kancelaryjny, zgodny z obowiązującą Instrukcją kancelaryjną, jednolitą i uporządkowaną ewidencję akt spraw.
EZD musi umożliwiać tworzenie akt spraw w oparciu o dokumenty otrzymane lub wytworzone w komórce organizacyjnej, wszczynanie spraw na wniosek i z urzędu. Musi wyświetlać informację o piśmie wszczynającym postępowanie.
EZD powinien zapewniać utworzenie wielu spraw w oparciu o jeden dokument, oraz dołączenie jednego dokumentu do wielu spraw.
EZD musi umożliwiać sygnalizowanie spraw o określonym terminie załatwienia (dla których upłynął termin załatwienia, termin załatwienia upływa w dniu bieżącym, termin załatwienia upłynie za jakiś czas itp.).
EZD musi umożliwiać definiowanie systemu numerowania spraw w sposób odpowiadający jednostce i automatyczną numerację zakładanych spraw, / automatyczne rozpoczęcie numerowania spraw w teczce z każdym nowym rokiem.
EZD musi umożliwiać nadawanie numerów startowych dla spisów spraw w teczkach i podteczkach.
EZD musi umożliwiać definiowanie, na którym poziomie struktury organizacyjnej będzie zdefiniowana numeracja spraw (czy sprawy mają się numerować na poziomie najniższej komórki, najwyższej, czy położonej w środku struktury organizacyjnej) dla każdej z gałęzi struktury organizacyjnej odrębnie.
EZD musi zawierać mechanizm umożliwiający jednocześnie prowadzenie bieżących spraw z zastosowaniem numeracji automatycznej i z zastosowaniem numeracji ręcznej uzupełnianie spisów spraw z lat poprzednich (sprzed daty rozpoczęcia prowadzenia spisu spraw w formie elektronicznej w systemie) z możliwością wprowadzania spraw w dowolnej kolejności i tylko spraw „wybranych”.
EZD musi umożliwiać tworzenie podteczek w ramach teczek aktowych.
EZD musi umożliwiać dołączanie do jednej sprawy wielu pism.
EZD musi umożliwiać rejestrację sprawy bez pisma, tzw. rezerwację numeru.
EZD musi umożliwiać przeglądanie spisów spraw dla poszczególnych teczek, z możliwością zmiany widoku (jednocześnie dla zawartości całej teczki) na: rozwiń również zawartość wszystkich podteczek w danej teczce (wyświetlenie wykazu wszystkich spraw w teczce wraz z jednoczesnym otwarciem wykazów wszystkich spraw w podteczkach, bez rozwijania odrębnie każdej z pozycji spisu spraw dla podteczki), zwiń zawartość podteczek w danej teczce (czyli system pokazuje pozycje spisu spraw będące podstawą do wydzielenia podteczek, ale bez spraw w podteczce i bez potrzeby zwijania odrębnie zawartości każdej podteczki).
EZD musi umożliwiać generowanie nowych dokumentów z poziomu sprawy (pism wychodzących, notatek, pism wewnętrznych itp.).
EZD musi umożliwiać filtrowanie dokumentów w sprawie z możliwością określenia daty dokumentu, jego rodzaju (przychodząca, wychodząca) oraz użytkownika który go dołączył.
EZD musi umożliwiać przeniesienie akt spraw do innej teczki bądź dołączania konkretnego dokumentu do różnych spraw w różnych teczkach (nie dopuszcza się kopiowania pliku fizycznego).
EZD musi umożliwiać/posiadać mechanizm uniemożliwiający powtórne wykorzystanie tego samego znaku sprawy.
EZD musi umożliwiać poprzez system uprawnień, dla zdefiniowanych pracowników, dostęp do akt spraw z możliwością edycji bądź wyłącznie do podglądu.
EZD musi umożliwiać przenoszenie spraw pomiędzy teczkami/podteczkami oraz ich usuwanie (usuwanie możliwe po nadaniu uprawnień przez administratora), klasyfikację spraw wg słowników definiowanych przez administratora, ułatwiające wykonywanie prac pracownikom, dołączanie zadań, nadawanie statusów.
EZD musi umożliwiać tworzenie grup pracowników współpracujących przy realizacji spraw z możliwością definiowania uprawnień każdego z użytkowników w poszczególnych sprawach.
EZD musi umożliwiać przeszukiwanie spraw wg kryteriów dowolnie definiowanych przez użytkownika.
EZD musi umożliwiać wersjonowanie sprawy wraz z informacją o liczbie wersji oraz dostępem do wszystkich wersji, automatyczne tworzenie historii sprawy.
EZD musi umożliwiać bezpośredni dostęp ze spisu spraw do szczegółów każdej z nich w trybie edycji lub podglądu. Wydruk spisu spraw, metryki sprawy, oraz opisu teczki aktowej.
EZD musi umożliwiać nadzorowanie przebiegu realizacji sprawy przez właściciela sprawy oraz jego przełożonych: kierownika komórki organizacyjnej (na podstawie uprawnień).
EZD musi posiadać możliwość ustawienia wymaganego terminu załatwienia sprawy, musi być możliwa edycja terminu załatwienia sprawy.
Historia sprawy musi zawierać informację kto i kiedy zmienił termin załatwienia sprawy.
EZD musi mieć:
możliwość uzyskania informacji, kto i kiedy czytał w przeszłości akta sprawy;
możliwość uzyskania informacji, kto i kiedy edytował w przeszłości dokument;
możliwość uzyskania informacji kto i kiedy usunął/dodał dokument do sprawy.
EZD musi umożliwiać przekazywanie uwag dotyczących sprawy i przygotowywanego dokumentu.
EZD musi umożliwiać zamykanie spraw, musi istnieć możliwość jednoczesnego zamykania wybranych spraw ze wspólną datą zamknięcia.
EZD musi umożliwiać kontynuowanie pracy nad sprawą w kolejnym roku.
EZD musi umożliwiać wznawianie spraw zakończonych.
EZD musi umożliwiać pracę grupową w konkretnych sprawach, tj. dysponent sprawy ustala osoby współpracujące w sprawie i zakresy ich uprawnień.
EZD musi umożliwiać zdefiniowanie „szablonu” usprawniającego nadawanie uprawnień do współpracy grupowej nad sprawą dla określonego użytkownika.
EZD powinien umożliwiać wyszukanie spraw przeterminowanych oraz niezakończonych.
EZD musi umożliwiać generowanie zadań do wykonania w określonej sprawie.
EZD musi umożliwiać przydzielanie zadania (wraz ze skojarzonymi z nimi dokumentami/sprawami) dla poszczególnych osób (również sobie), co ułatwia monitorowanie sposobów i terminów realizacji zadań.
EZD musi umożliwiać zarządzanie pismami wewnętrznymi – przesyłanymi między komórkami organizacyjnymi/pracownikami.
Rejestracja pism wewnętrznych musi odbywać się analogicznie do obsługi korespondencji wychodzącej, z możliwością rejestracji: załączników, skanowania, akceptacji, generowaniem treści pism i załączników z szablonów, możliwością podpisywania pism i załączników podpisem elektronicznym kwalifikowanym i niekwalifikowanym z poziomu aplikacji, z możliwością wielokrotnego podpisywania dokumentu przez osoby akceptujące.
EZD musi umożliwiać kierowanie pism jednocześnie do wielu pracowników i komórek organizacyjnych, bez potrzeby zaznaczania każdego pracownika oddzielnie.
EZD musi umożliwiać śledzenie historii pisma od momentu zarejestrowania w systemie oraz drogi jego obiegu pomiędzy pracownikami i komórkami organizacyjnymi.
EZD musi umożliwiać ewidencjonowanie i udostępnianie historii zmian dokumentu.
Obsługa ewidencji dokumentów wewnętrznych – wymagania minimalne:
EZD powinien posiadać moduł ewidencji (rejestrów) dokumentów powstających i gromadzonych przez organizację, które nie są kierowane do określonych adresatów (interesantów bądź kontrahentów) takich jak regulaminy, statuty, uchwały, protokoły itp. EZD musi wspomagać pracę organów stanowiących i wykonawczych jednostki (np. biura obsługi zarządu). Musi umożliwiać rejestrowanie i nadzorowanie dokumentów gromadzonych w segregatorach, teczkach i podteczkach. EZD powinien realizować typowe funkcje kancelaryjne wykonywane w związku z obsługą dokumentacji jednostki. EZD powinien posiadać następujące funkcje: definiowanie i prowadzenie rejestrów dokumentów: uchwał, protokołów, zarządzeń itp., ewidencjonowanie i nadzorowanie dokumentów wewnętrznych jednostki wraz z ich stanami i wersjami; musi istnieć możliwość odtworzenia stanu (wersji) dokumentu obowiązującej w danym dniu, jeżeli dokument w systemie zmienił wersję/stan. System musi zawsze udostępniać dokumenty w aktualnej wersji i sygnalizować pracę na nieaktualnej wersji.
EZD musi umożliwiać określenie, do wybranych typów pól, czy jest to pole obowiązkowe.
Minimalny zestaw atrybutów modułu przy definiowaniu ewidencjonowanych w rejestrach dokumentów musi obejmować: definiowalny zakres danych opisujących dokument (opisy, daty, słownik, liczby itp.), definiowalne parametry pól danych opisujących (długość pól, wymagalność, wartości domyślne, kolejność wyświetlania itp.), definiowalną maskę numeru dokumentu (z parametrami kontroli unikalności numeru, numeracji automatycznej bądź ręcznej itp. i możliwością użycia elementów słownikowych), domyślne szablony, nr teczki JRWA.
EZD musi umożliwiać śledzenie historii życia dokumentu od chwili zarejestrowania w module oraz wszystkich czynności wykonywanych na dokumencie przez pracowników.
EZD musi umożliwiać przeszukiwanie dokumentów wg kryteriów dowolnie definiowanych przez użytkownika.
EZD musi umożliwiać generowanie dokumentów na podstawie zdefiniowanych szablonów, analogicznie jak w przypadku obsługi korespondencji wychodzącej i wewnętrznej.
EZD musi umożliwiać tworzenie powiązań pomiędzy dokumentami tak, że z poziomu dokumentów powiązanych można przejść do przeglądania dokumentu powiązanego – dwustronne wskazanie na dokument.
EZD musi umożliwiać sygnowanie dokumentów kodem kreskowym.
EZD musi umożliwiać identyfikowanie dokumentów przy pomocy czytnika kodów kreskowych.
EZD musi umożliwiać skanowanie dokumentów z poziomu modułu oraz zapisywanie ich formy elektronicznej w formacie wielostronicowym.
EZD musi umożliwiać posiadać moduł skanowania, niezależny od producenta skanera. EZD powinien współpracować z dowolnym skanerem obsługującym interfejs XXXXX. Moduł skanowania powinien pozwalać na ustawienie podstawowych parametrów skanowania.
Funkcjonalności pomocnicze wymagane w systemie – wymagania minimalne:
1. Moduł tworzenia katalogów pomocniczych musi zapewniać tworzenie dowolnej struktury drzewiastej katalogów nie związanych z JRWA. Musi być możliwość umieszczania w tak utworzonych katalogach: dokumentów, dołączania osób ze struktury urzędu wraz z określeniem funkcji w jednostce i poza jednostką.
Moduł umożliwiający gromadzenie informacji o dodatkowych zdarzeniach mających miejsce w jednostce jak np. odnotowywanie rozmów telefonicznych, spotkań czasu ich trwania oraz wskazania interesanta z bazy których dotyczyły. System musi umożliwiać wyświetlenie użytkownikowi wszystkich zdarzeń z podziałem na zdefiniowanie rodzaje. System musi posiadać słownik umożliwiający definiowanie rodzajów zdarzeń. Zdarzenia muszą być wyświetlane w odrębnym rejestrze.
System musi umożliwiać rejestrację różnego rodzaju zadań związanych z prowadzonymi sprawami oraz bez powiązania ze sprawami. System musi umożliwiać wyświetlanie zadań w odrębnym rejestrze, z możliwością przeglądania odrębnie zadań w różnych statusach (etapach realizacji), co najmniej: otrzymanych do realizacji, skierowanych do realizacji, zrealizowanych.
System musi w odrębnym słowniku umożliwiać grupowanie zadań w listy opisane nazwami/tytułami. System musi umożliwiać przesuwanie kolejności zadań na liście. System musi umożliwiać dołączenie do sprawy na dowolnym etapie jej realizacji listy przez wskazanie jej nazwy. Wybranie tytułu/nazwy listy z poziomu sprawy, musi skutkować dołączeniem wszystkich zadań z listy do sprawy.
System musi umożliwiać tworzenie notatek, w sprawie i bez powiązania ze sprawą oraz przeglądanie wszystkich notatek w odrębnym rejestrze.
System musi umożliwiać prowadzenie rezerwacji np. sal konferencyjnych i innych dowolnych zasobów jednostki. Musi być możliwe ustalanie listy osób mających dostęp do rezerwacji określonego zasobu.
Obsługa archiwum zakładowego – wymagania minimalne:
EZD powinien posiadać funkcjonalności odpowiedzialne za obsługę składów chronologicznych dla dokumentów papierowych.
EZD powinien umożliwiać prowadzenie składów chronologicznych korespondencji wpływającej oraz elementów spraw z podziałem na:
dokumenty odwzorowane w całości;
dokumenty odwzorowane w części lub nie odwzorowane;
skład nośników.
EZD powinien posiadać wbudowane archiwum, w pełni obsługujące wszystkie podstawowe procesy związane archiwizacją dokumentów, w tym: przekazywanie akt do archiwum zakładowego, tworzenie spisów zdawczo-odbiorczych oraz wykazu spisów zdawczo-odbiorczych, brakowanie, przekazywanie dokumentacji do właściwego archiwum państwowego (w postaci paczki archiwalnej).
EZD powinien zapewniać mechanizmy brakowania akt w archiwum elektronicznym.
Po zakończeniu procedury brakowania, EZD powinien zapewniać automatyczne usunięcie dokumentacji z systemu. Usunięcie danych następuje po upływie okresów przechowalnictwa danych i jest kontrolowane przez archiwistę, który posiada zgodę komórek organizacyjnych oraz zgodę Archiwum Państwowego na wybrakowanie materiałów niearchiwalnych. Usunięcie danych z panelu archiwum zakładowego powinno być możliwe tylko przez ściśle określone osoby, np. przez archiwistę, tzn. że pracownik nie posiadający uprawnień archiwisty nie może ingerować w zasób.
EZD powinien umożliwiać tworzenie paczki archiwalnej dla wybranego roku.
EZD powinien umożliwiać określenie, że sprawa została założona w wyniku pomyłki i podczas zamykania nadać kategorię archiwalną.
EZD powinien umożliwiać generowanie niezbędnych dokumentów, w tym spisów zdawczo-odbiorczych zgodnie z Instrukcją w sprawie organizacji i zakresu działania archiwum zakładowego.
EZD powinien umożliwiać generowanie spisu zdawczo-odbiorczego na podstawie przygotowanej paczki archiwalnej zgodnie z przepisami: Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. z 2014 r. poz. 1114) wraz z aktami wykonawczymi; Ustawa z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (Dz. U. z 2011 r., Nr 123, poz. 698 z późn. zm.) wraz z aktami wykonawczymi; Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 r w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych (Dz. U. z 2006r., Nr 206, poz. 1519 z późn. zm).
Podczas przekazywania dokumentacji do archiwum zakładowego, EZD umożliwiać powinien przekazanie archiwiście uprawnień do dysponowania dokumentacją, pozostawiając przekazującemu prawo do wglądu do dokumentacji.
EZD powinien umożliwiać zarządzanie zawartością archiwum elektronicznego.
EZD powinien umożliwiać przekazywanie do archiwum zakładowego spraw zakończonych zbiorczo z całej komórki organizacyjnej.
EZD powinien umożliwiać weryfikację, czy wszystkie sprawy w teczce są zamknięte. Musi uniemożliwiać przekazanie do elektronicznego archiwum teczek, spraw niezamkniętych oraz brakujących.
EZD powinien zapewniać zgodność formatu metadanych eksportowanych dokumentów ze standardem tzw. „paczki archiwalnej” opracowanym przez Naczelną Dyrekcję Archiwów Państwowych.
EZD powinien uniemożliwiać przekazanie do archiwum teczek zawierających niezamknięte sprawy (zgodnie z informacją umieszczoną we właściwych rejestrach).
EZD powinien pozwalać na wyszukiwanie w bazie całych sformułowań ale również ich części z możliwością zawężenia do wybranego parametru np.: daty, komórki organizacyjnej, nr JRWA, jednostki archiwalnej / sprawy / wszystko haseł tematycznych.
Obsługa struktury organizacyjnej – wymagania minimalne:
EZD musi umożliwiać definiowanie struktury organizacyjnej opartej o stanowiska do których przypisani są pracownicy. Struktura organizacyjna ma uwzględniać powiązania podległościowe poszczególnych komórek organizacyjnych.
EZD musi umożliwiać tworzenie tzw. wakatów.
EZD musi umożliwiać odwzorowanie rzeczywistej struktury organizacyjnej Zamawiającego wraz z zakresem uprawnień.
EZD musi umożliwiać modyfikowanie struktury.
EZD musi umożliwiać tworzenie dowolnej ilości jednostek podrzędnych.
EZD musi udostępniać widok całej struktury jak i wybranych fragmentów i elementów.
EZD musi umożliwiać zarządzanie strukturą (dodawanie elementów, edycja itp.).
EZD musi umożliwiać tworzenie grup użytkowników o określonych uprawnieniach.
EZD musi umożliwiać blokowanie oraz odblokowywanie kont użytkowników.
EZD musi umożliwiać wielopoziomowy mechanizm zarządzania uprawnieniami (użytkownicy, role, grupy uprawnień).
EZD musi umożliwiać przyporządkowanie pracownika do wielu stanowisk (możliwość pracy na wielu stanowiskach).
Obsługa zastępstw – wymagania minimalne:
Kierownik komórki organizacyjnej musi posiadać możliwość wskazania osoby, początku oraz końca okresu, w którym podległy pracownik będzie zastępowany.
EZD musi umożliwiać wyznaczenie więcej niż jednej osoby zastępującej dla osoby zastępowanej.
EZD musi umożliwiać zastępstwo z ograniczonymi uprawnieniami (pracę w imieniu).
Wszystkie operacje wykonywane przez zastępcę w module muszą zostać odnotowane i zapisane w historii zdarzeń oraz umożliwiać identyfikację osoby, która je wykonała.
EZD musi umożliwiać modyfikację (zmianę) osoby zastępującej.
Obsługa raportów – wymagania minimalne:
EZD musi umożliwiać parametryzację raportów i tworzenie raportów odpowiadających potrzebom użytkownika.
EZD musi umożliwiać tworzenie raportów bez znajomości technologii bazodanowych takich jak język SQL.
EZD musi umożliwiać na stanowiskach kancelaryjnych/w sekretariatach wydruk dziennika korespondencji przychodzącej.
EZD musi umożliwiać wygenerowanie co najmniej raportów lub zestawień typu:
wykaz akt spraw z danej teczki/podteczki;
liczba akt spraw ogółem na pracownika, w ramach teczki JRWA;
liczba korespondencji wysłanej przez Zamawiającego wg sposobu wysyłki;
liczba korespondencji wysłanej przez Zamawiającego wg typu przesyłki;
sumaryczne zestawienie akt spraw: w toku, załatwionych, przeterminowanych;
liczba pism na pracownika (obciążenie pracownika);
pocztowa książka nadawcza;
książka adresowa.
Obsługa edytora procesów workflow – wymagania minimalne:
EZD powinien zapewnić możliwość rozbudowania o mechanizm do prowadzenia procesów zarówno w oparciu o ścieżki workflow (zgodnie z ustalonymi procedurami i kolejnością) jak i poza workflow (swobodny obieg dokumentów i spraw zgodny z nadawanymi użytkownikom uprawnieniami).
EZD musi umożliwiać definiowanie dowolnej liczby procesów za pomocą wbudowanego w dostarczony system modułu graficznego edytora procesów.
EZD musi umożliwiać śledzenie poszczególnych etapów procesu oraz stan ich realizacji przez uprawnionych użytkowników.
EZD musi prezentować graficzną wizualizację przebiegu procesu wg ścieżki jego faktycznego wykonania.
EZD musi umożliwiać przerwanie procesu i dalszego załatwiania sprawy poza schematem w nim opisanym.
EZD musi umożliwiać określenia czasu realizacji procesu i każdego z jego etapów oraz nadzór nad terminowością realizacji.
EZD musi umożliwiać automatyczne przydzielanie zadania użytkownikom wynikających z realizacji procesu workflow.
EZD musi umożliwiać nadawanie terminów realizacji zadań w edytorze procesów.
EZD musi umożliwiać równoległe wykonywanie niezależnych ścieżek w edytorze procesów.
EZD musi umożliwiać dynamiczne określenie osoby przypisanej w edytorze procesów (na podstawie zmiennych z procesu).
Administracja systemem – wymagania minimalne:
EZD musi posiadać panel administracyjny, do którego dostęp mają jedynie uprawnieni użytkownicy (administratorzy).
Panel administracyjny EZD musi umożliwiać zdefiniowanie i prowadzenie rejestrów wszystkich typów dokumentów z zakresu działalności Zamawiającego zgodnie z wymaganiami prawnymi dotyczącymi tych dokumentów (np. ewidencja decyzji, zaświadczeń itd.).
Panel administracyjny EZD musi umożliwiać podgląd osób, które są zalogowane w aplikacji.
Panel administracyjny EZD musi umożliwiać przeglądanie historii logowania użytkowników.
Panel administracyjny EZD musi umożliwiać zarządzanie kontami użytkowników, co najmniej w zakresie:
edycji uprawnień konta użytkownika;
zarządzanie złożonością haseł do EZD i określanie co najmniej: maksymalnej i minimalnej długości hasła, czasu ważności hasła;
ustawienia praw dostępu dla użytkownika.
EZD powinien umożliwiać dodawanie, usuwanie i modyfikowanie szablonów dokumentów w celu wykorzystania ich z poziomu aplikacji (np. dla pism wychodzących, wewnętrznych i innych dokumentów), z możliwością wstawiania do treści pisma znaczników, których zawartość jest automatycznie odczytywana z bazy danych dokumentów i interesantów.
EZD powinien umożliwiać dowolną edycję Jednolitego Rzeczowego Wykazu Akt w przypadku zmiany Instrukcji kancelaryjnej z wszystkimi konsekwencjami z tego wynikającymi (zmiany w oznaczaniu akt sprawy i teczek spraw, numeracji).
EZD powinien umożliwiać zarządzanie słownikami, co najmniej następującego typu: kontrahenci, rejestry, rodzaje zasobów itp.
EZD powinien umożliwiać definiowanie uprawnień każdego z pracowników w zakresie: dostępu do dokumentów i spraw oraz uprawnień do aktualizacji i przeglądania ich zawartości
EZD powinien umożliwiać kopiowanie uprawnień użytkowników.
Obsługa integracji z ePUAP – wymagania minimalne:
EZD musi zintegrowany z ePUAP, który pełni rolę Elektronicznej Skrzynki Podawczej.
Współpraca EZD z platformą ePUAP musi odbywać się poprzez konto organizacji na ePUAP.
EZD powinien umożliwiać wystawianie urzędowego poświadczenia odbioru (UPO w trybie przedłożenia) zgodnego z rozporządzeniem Prezesa Rady Ministrów z dnia 29 września 2005 r. (Dz. U. Nr 200, poz. 1651). Funkcjonalność ta może zostać zrealizowana przez mechanizmy platformy ePUAP.
W module powinna istnieć możliwość podglądu treści przesłanego dokumentu elektronicznego oraz weryfikacji bezpiecznego podpisu elektronicznego złożonego na dokumencie.
EZD powinien zapewniać ewidencjonowanie i archiwizację doręczonych do dokumentów elektronicznych oraz wygenerowanych Urzędowych Poświadczeń Odbioru (Urzędowych Potwierdzeń Przedłożenia).
EZD powinien zapewniać ewidencjonowanie i archiwizację doręczonych do klienta dokumentów elektronicznych oraz wygenerowanych (i podpisanych przez klienta) Urzędowych Poświadczeń Odbioru (Urzędowych Potwierdzeń Doręczenia).
EZD powinien zapewniać obsługę (wizualizacja i weryfikacja podpisu) dokumentów otrzymywanych z ePUAP-u i możliwość wysyłania dokumentów na platformę ePUAP.
EZD powinien zapewniać przesłanie decyzji/odpowiedzi w formie dokumentu elektronicznego na platformę ePUAP oraz wygenerowanie (podpisanie) Urzędowego Poświadczenia Doręczenia.
EZD powinien zapewniać przekazywanie dokumentów przygotowanych w module bezpośrednio do skrzynek wnioskodawców na platformie ePUAP.
EZD powinien zapewniać wysyłkę pisma/pism do wielu odbiorców na adresy skrytek ePUAP zdefiniowane w słowniku kontrahentów EZD (korespondencja seryjna).
EZD powinien zapewniać odbiór i przechowanie informacji zawierających Urzędowe Poświadczenie Przedłożenia (UPP) i Urzędowe Poświadczenie Doręczenia (UPD) powiązane z dokumentami, których one dotyczą.
EZD powinien rejestrować wszystkie wysyłki elektroniczne odnotowywane w rejestrze korespondencji wychodzącej.
EZD musi umożliwiać automatyczne przesyłanie UPO do nadawcy dokumentu elektronicznego / interesanta. Funkcjonalność ta może zostać zrealizowana przez mechanizmy platformy ePUAP.
EZD musi umożliwiać odczytanie UPO przez interesanta oraz zapisanie go na wybranym nośniku danych. Funkcjonalność ta może zostać zrealizowana przez mechanizmy platformy ePUAP.
EZD musi realizować długookresowe (po wygaśnięciu okresu ważności certyfikatu nadawcy) archiwizowanie dokumentów.
EZD musi udostępniać możliwość przesyłania informacji zwrotnej dotyczącej danej sprawy w postaci publikacji statusu sprawy automatycznie generowanego w module na każdym etapie procesu rozpatrywanej sprawy.
EZD musi zapewniać możliwość przesłania dodatkowych dokumentów dotyczących danej sprawy.
EZD musi umożliwiać przesłanie decyzji/odpowiedzi w formie dokumentu elektronicznego na ePUAP oraz wygenerowanie (podpisanie) Urzędowego Poświadczenia Doręczenia.
EZD musi odbierać i przechowywać informacje zawierające Urzędowe Poświadczenie Przedłożenia (UPP) i Urzędowe Poświadczenie Doręczenia (UPD) powiązane z dokumentami, których one dotyczą.
EZD musi umożliwiać przesyłanie dużych plików (do 40 MB) przez ePUAP.
Integracja z BIP – wymagania minimalne:
EZD powinien zostać zintegrowany z systemem BIP w zakresie:
automatycznego (tj. bez udziału użytkownika/operatora) przesyłania statusów spraw prowadzonych w systemie EZD,
automatycznego przesyłania rejestrów i ich zawartości prowadzonych w systemie EZD.
EZD w zakresie przesyłania statusów spraw musi:
automatycznie przesyłać wraz z unikalnym identyfikatorem spraw także status systemowy (krok prowadzącego sprawę, dane prowadzącego sprawę i dbać o właściwą prezentacje danych na stronie przedmiotowej BIP).
EZD w zakresie przesyłania rejestrów i ich zawartości musi:
umożliwiać umieszczenie rejestru w BIP bez udostępniania widoczności dla osób niezalogowanych, publikację rejestru,
pozwalać na wskazanie dowolnie wybranych kolumn rejestru podlegających publikowaniu w BIP,
pozwalać na wskazanie dowolnej liczby rejestrów, z których dane są prezentowane w BIP oraz wskazanie miejsca w strukturze menu BIP w którym znajdzie się rejestr,
pozwalać na przeszukiwanie w systemie BIP zawartości rejestrów.
Obsługa podpisu elektronicznego i profilu zaufanego – wymagania minimalne:
EZD powinien zapewniać podpisywanie dokumentów niekwalifikowanym i kwalifikowanym podpisem elektronicznym (weryfikowanym certyfikatami wszystkich centrów kwalifikowanych działających w Polsce na dzień składania oferty) z poziomu aplikacji.
EZD powinien zapewniać możliwość wykorzystania podpisu elektronicznego na każdym etapie pracy z dokumentami.
EZD powinien umożliwić podpisywanie kolejnych decyzji (np. akceptacji) bezpiecznym podpisem elektronicznym z użyciem certyfikatu kwalifikowanego lub podpisu wewnętrznego.
EZD powinien umożliwić obsługę podpisu elektronicznego zgodnego ze standardem XML Advanced Electronic Signature (XAdEs).
EZD powinien umożliwić weryfikację podpisu elektronicznego i wyświetlania dla danego dokumentu informacji o tym, czy podpis jest poprawny czy nie.
EZD powinien umożliwić pobranie podpisu i certyfikatu, którym został podpisany dokument.
W ramach zamówienia Wykonawca powinien dostarczyć wszelkie niezbędne komponenty programowe potrzebne do obsługi podpisu elektronicznego.
System musi umożliwiać podpisywanie dokumentów zarówno podpisem elektronicznym jak i profilem zaufanym.
Komunikacja z jednostkami organizacyjnymi – wymagania minimalne:
System dla jednostek podległych musi być zbudowany w architekturze trójwarstwowej, złożonej z:
programu klienckiego (kod generowany dla przeglądarki internetowej);
serwera aplikacji (kod zarządzający aplikacją, wykonujący funkcje z zakresu logiki biznesowej, pośredniczący między żądaniami programu klienckiego a funkcjami udostępnianymi przez motor bazy danych);
motoru bazy danych, zarządzającego bazą danych.
Komunikacja pomiędzy jednostkami podległymi a jednostką nadrzędną powinna odbywać się za pomocą usług webowych typu SOAP.
System powinien umożliwiać wysyłanie korespondencji wychodzącej wewnętrznej między jednostkami podległymi i/oraz jednostką nadrzędną.
Wysyłka korespondencji wewnętrznej powinna być możliwa do wielu pracowników z różnych jednostek podległych, wysyłka na wydział i jednostkę podległą.
System powinien umożliwiać automatyczną dekretację na pracownika korespondencji przychodzącej w przypadku wysyłki dokumentu na jednostkę podległą (lub nadrzędną). Konfiguracja pracownika do dekretacji powinna być konfigurowalna w panelu administracyjnym.
System powinien umożliwiać podgląd pełnej struktury organizacyjnej tylko dla wybranych, widocznych jednostek podległych w procesie tworzenia korespondencji wychodzącej wewnętrznej. Definiowanie widocznych struktur powinno być dostępne z panelu administracyjnego systemu.
Wysyłka korespondencji wychodzącej wewnętrznej powinna odbywać się przez usługę webową rejestrującą pismo przychodzące (z załącznikami jeżeli występują) w systemie jednostki podległej (lub nadrzędnej).
System powinien rejestrować odebrane od jednostek podległych (lub nadrzędnej) korespondencję jako korespondencję przychodzącą której dysponentem jest wybrany podczas wysyłki pracownik jednostki podległej, wydział lub jednostka podległa.
System powinien umożliwiać administrowanie globalne lub lokalne systemem.
Administrowanie lokalne powinno być możliwe tylko dla danej jednostki. Administratorem lokalnym może zostać dowolny pracownik z wybranej jednostki poprzez nadanie odpowiednich uprawnień.
System powinien posiadać oddzielny EZD umożliwiający administrowanie globalne wszystkimi systemami jednostek podległych. Administratorem globalnym może zostać dowolny pracownik z jednostki nadrzędnej poprzez nadanie odpowiednich uprawnień.
Administracja globalna powinna być możliwa tylko z jednostki nadrzędnej systemu.
Administrator globalny powinien mieć możliwość konfiguracji jednostek podległych (nadanie nazw urzędów, wprowadzenia adresów usług web systemu jednostek podległych, wprowadzenia adresów systemu jednostek podległych) oraz konfiguracji systemów w poszczególnych jednostkach podległych w sytuacji gdy jednostka podległa nie posiada administratora lokalnego.
System musi posiadać interfejsy wykorzystujące jako technologię komunikacyjną usługi sieciowe (ang. Web-services) pozwalające na pobieranie danych oraz zasilanie danymi zewnętrznych systemów.
System musi posiadać możliwość rozbudowy, w szczególności umożliwiającą wygodną implementację wszelkich procesów obiegów dokumentów i spraw zachodzących u Zamawiającego (dotyczy to rozszerzenia o integrację z ePUAP, OCR, SMS, workflow oraz integrację z jednostkami podległymi).
System musi posiadać interfejs oparty na przeglądarce internetowej. W warstwie klienckiej musi poprawnie działać w środowisku systemu operacyjnego.
W ramach interfejsu Użytkownik musi posiadać możliwość korzystania ze wszystkich funkcjonalności systemu, które są dla niego udostępnione zgodnie z przypisanymi mu uprawnieniami.
System dostarczany dla jednostki podległej musi posiadać pełną funkcjonalność, jak dla jednostki nadrzędnej, tj. Powiatu Lwóweckiego.
System musi umożliwiać w przypadku gdy jednostka podległa nie jest użytkownikiem systemu zdefiniowanie w swojej strukturze organizacyjnej jednostek podległych w celu odnotowywania przekazywania korespondencji na ich konta.
Migracja danych z obecnego systemu EZD. Wykonawca dokona migracji zawartości dzienników pism przychodzących, wychodzących, rejestrów spraw. Migracja musi dotyczyć zawartości wszystkich pól opisujących dane w obecnym systemie, historii pism, spraw oraz odwzorowań cyfrowych. Przed wykonaniem migracji Wykonawca dokona analizy zawartości obecnego EZD i w uzgodnieniu z Zamawiającym zmigruje również zawartość pozostałych rejestrów i danych, jeżeli były prowadzone w systemie. Wykonawca przed wykonaniem migracji przygotuje dokument analizu zawierający zestawienia ilościowe poszczególnych danych. Po migracji zostanie sporządzony dokument powykonawczy z dokonanej migracji.
Zintegrowany System Płatności Elektronicznych e-płatności
Integracja – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Dostęp do modułu musi być możliwy poprzez bezpieczne logowanie z użyciem identyfikatora i zaszyfrowanego hasła oraz przez autoryzację z wykorzystaniem powszechnie dostępnego profilu zaufanego (xxxxx://xx.xxx.xx). |
|
Wymiana danych powinna zostać zabezpieczona za pomocą transmisji z wykorzystaniem tokenu oraz znacznika czasu. Przy nieprawidłowych dodatkowych danych metoda nie powinna się wykonać i powinien zostać zwrócony stosowny komunikat z błędem. |
|
Przy rejestracji elektronicznej do portalu system musi umożliwiać wyświetlenie regulaminu portalu i wymagać jego podpisania za pośrednictwem profilu zaufanego użytkownika. |
|
System powinien zapewnić zarządzanie i administrowanie kontami użytkowników przez wbudowany panel administratora dostępny po zalogowaniu się za pomocą loginu oraz hasła. |
|
W zakresie administrowania kontem system musi zapewnić generowanie haseł startowych dla użytkowników - hasła i konta użytkowników muszą być edytowane, dodawane tylko przez Administratora. W celu wygenerowania hasła dla użytkownika Portalu Klienta wymagane są co najmniej: typ identyfikatora (PESEL) oraz identyfikator, po wykryciu zalogowania się przez użytkownika po raz pierwszy system musi wymagać podania nowego hasła wraz z automatyczną dezaktywacją hasła startowego. |
|
System musi zapewniać podgląd listy użytkowników, którym udostępniono dostęp do Portalu, wraz z danymi dotyczącymi, nazwy, identyfikatora profilu zaufanego, daty utworzenia konta, statusu oraz metody logowania. |
|
Administrator ma podgląd do informacji o próbach logowania do systemu ze wskazaniem identyfikatora, daty, adresu IP z którego nastąpiło połączenie do portalu. |
|
Moduł musi funkcjonować na ogólnodostępnym serwerze internetowym i udostępniać swoją treść przy wykorzystaniu przeglądarek WWW. Budowa strony internetowej musi spełniać ogólnie przyjęte standardy kodowania WWW oraz zgodność z normą WCAG 2. |
|
Wyświetlania danych dokonywane jest za pomocą przeglądarki internetowej bez konieczności instalacji dodatkowego oprogramowania, po stronie użytkownika. |
|
Integracja z systemem dziedzinowym - wczytanie (import) danych na podstawie plików w formacie XML przekazanych z systemów dziedzinowych (system rozliczający opłaty, system FK). Wymiana danych musi przebiegać poprzez bezpieczne, szyfrowane połączenie za pośrednictwem serwisów komunikacyjnych. |
|
Komunikacja z systemami dziedzinowymi oparta o technologię web service. |
|
Implementacja mechanizmów polegających na automatyzacji wymiany danych pomiędzy modułem a systemem dziedzinowym. Dostępność aktualnych danych nie może dodatkowo angażować operatorów systemów dziedzinowych. |
|
Udostępnianie danych użytkownika musi następować po zalogowaniu się użytkownika na jego indywidualne konto. |
|
System musi posiadać przejrzystą prezentację należności z uwzględnieniem sald poszczególnych rat, terminów ich płatności oraz wysokości odsetek wraz z kosztami upomnień. |
|
Moduł musi generować automatycznie informacje z systemów dziedzinowych o dokonanych wpłatach i przypomnieniach o zbliżających się terminach zapłaty należności do osób wyrażających zgodę na otrzymywanie takich informacji. |
|
System musi umożliwiać dokonywanie wpłat zarówno dla użytkowników zalogowanych jak i tych którzy nie posiadają konta w systemie. W przypadku użytkowników niezalogowanych identyfikacja ich dokonywana jest na podstawie numeru z dokumentu ustalającej dane zobowiązanie i system musi wypełniać dowód wpłaty tylko w zakresie opisu należności i podania odpowiedniego konta na które należy dokonać zapłatę. |
|
System musi być zintegrowany co najmniej z dwoma systemami płatniczymi posiadającymi zezwolenie Komisji Nadzoru Finansowego na świadczenie usług płatniczych w charakterze krajowej instytucji płatniczej. |
|
Użytkownik musi mieć możliwość określenia zakresu powiadamień (włączanie, wyłączanie usługi, konfigurowanie terminarza, określenie kanału powiadomień, określenie zakresu tematyki powiadomień). |
|
Przesyłanie powiadomień musi dokonywać się wybranym przez użytkownika kanałem z uwzględnieniem wybranej przez niego tematyki i terminarza odbywa się automatycznie |
|
Dostęp do portalu płatniczego powinien być zapewniony także z aplikacji mobilnych zarówno w zakresie dostępu do informacji o zobowiązaniach, dokonywania płatności jaki w zakresie otrzymywania powiadomień (metoda push). |
|
System musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji. |
Baza danych oraz niezbędne oprogramowanie
Wykonawca na etapie realizacji dostarczy wraz z oprogramowaniem dziedzinowym niezbędną bazę danych, o wydajności umożliwiającej prawidłową pracę systemów. Zamawiający dopuszcza zarówno rozwiązania Open Source jak i bazy komercyjne, przy założeniu, że Wykonawca dostarczy bazę w ramach kosztów wdrożenia oprogramowania dziedzinowego. Licencja bazy danych musi objąć wszystkich użytkowników oprogramowania dziedzinowego.
Uruchomienie i oznakowanie Punktu Potwierdzania Profili Zaufanych
W ramach działania zostaną przeprowadzone następujące działania mające na celu uruchomienie Punktu Potwierdzania Profilu Zaufanego w Urzędzie, tj.:
Dostosowanie procedur związanych z profilami zaufanymi oraz stworzenie projektów oświadczeń załączanych do wniosku – wymagania minimalne:
Zgodnie z ustawą z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne, „Punkt potwierdzający profil zaufany ePUAP dokonuje potwierdzenia profilu zaufanego ePUAP, które polega na weryfikacji zgodności danych zawartych w profilu użytkownika ze stanem faktycznym oraz nadaniu uprawnień wynikających z posiadania profilu zaufanego ePUAP, jak również dokonuje przedłużenia ważności i unieważnienia profilu zaufanego ePUAP”. Do pełnienia funkcji punktu potwierdzającego wymagane jest uzyskanie zgody ministra właściwego ds. informatyzacji.
W ramach usługi objętej działaniem muszą zostać przygotowane załączniki do wniosku o utworzenie punktu potwierdzającego profil zaufany ePUAP, o których mowa w „Rozporządzeniu Ministra Cyfryzacji z dnia 10 września 2018 r. w sprawie profilu zaufanego i podpisu zaufanego”. Przygotowany musi zostać także dodatkowy załącznik zgodnie z „Procedurą utworzenia Punktu Potwierdzającego” zamieszczoną na ePUAP: projekt oświadczenia potwierdzającego stosowanie instrukcji kancelaryjnej ustanowionej na podstawie ustawy z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach.
Procedura zarządzania profilami zaufanymi ePUAP musi zawierać wszystkie zapisy występujące we wzorze zamieszczonym w BIP na stronie podmiotowej ministra, a ponadto musi zostać uzupełniona o dodatkowe zapisy, które będą charakteryzowały działanie punktu potwierdzającego profil zaufany ePUAP w Urzędzie. Zapisy te muszą określać x.xx.: sposób porządkowania i oznaczania dokumentacji z uwzględnieniem instrukcji kancelaryjnej, umiejscowienie punktu potwierdzającego w siedzibie Urzędu, sposób oznaczenia punktu potwierdzającego, sposób dostępu do punktu potwierdzającego klientów, czasu pracy punktu potwierdzającego, wymagania kompetencyjne osób uprawnionych do pracy w punkcie potwierdzającym – umiejętność pracy z przeglądarką internetową, znajomość platformy ePUAP, znajomość procedury zarządzania profilami zaufanymi ePUAP oraz sposobu sprawdzania tożsamości osoby wnioskującej, osoby odpowiedzialne za poprawną pracę pracowników i utworzenie warunków niezbędnych do potwierdzenia profilu zaufanego ePUAP. Tak przygotowana procedura zarządzania profilami zaufanymi ePUAP zostanie wniesiona zarządzeniem i formalnie przyjęta do stosowania jako „Procedura zarządzania profilami zaufanymi ePUAP”.
Procedura nadawania uprawnień do potwierdzania, przedłużania ważności i unieważniania profili zaufanych ePUAP musi zawierać wszystkie zapisy występujące we wzorze zamieszczonym w BIP na stronie podmiotowej ministra, a ponadto musi zostać uzupełniona o dodatkowe zapisy, które będą charakteryzowały działanie punktu potwierdzającego w Urzędzie. Procedura zostanie wniesiona zarządzeniem Starosty i formalnie przyjęta do stosowania jako „Procedura nadawania uprawnień do potwierdzania, przedłużania ważności i unieważniania profili zaufanych ePUAP”.
Pozostałe dokumenty po przygotowaniu przez Wykonawcę i zatwierdzeniu projektów zostaną podpisane przez Starostę.
Wszystkie wymagane dokumenty zostaną następnie przygotowane do złożenia wraz z wnioskiem o utworzenie punktu potwierdzającego profil zaufany ePUAP zgodnie z „Procedurą utworzenia Punktu Potwierdzającego” zamieszczoną na platformie ePUAP.
Stworzenie projektów aktualizacji wewnętrznych procedur i regulaminów – wymagania minimalne:
Utworzenie i funkcjonowanie punktu potwierdzania profilu zaufanego Epuap musi zostać uregulowane w wewnętrznych procedurach i regulaminach Urzędu, w szczególności w zakresie regulaminu organizacyjnego Urzędu. Powyższe musi zostać zrealizowane w ramach przedmiotowej usługi. Aktualizacja musi obejmować w szczególności zapisy dotyczące obowiązku bezpośredniego nadzoru nad poprawną pracą pracowników dokonujących potwierdzenia profilu zaufanego Epuap (w zakresie zadań i kompetencji wyznaczonego pracownika Urzędu) oraz zapisy dotyczące odpowiedzialności za właściwe przechowywanie dokumentacji papierowej związanej z obsługą wniosków w zakresie profilu zaufanego Epuap. Po przygotowaniu projektów dokumentów zostaną one przyjęte zgodnie z procedurą właściwą dla danego dokumentu.
Wykonawca musi zapewnić oznakowanie stanowiska pracy osoby prowadzącej punkt potwierdzania profilu zaufanego oraz dostawę jednostki roboczej (zestaw komputerowy) o minimalnych wymaganiach:
|
Typ |
Komputer stacjonarny. Typu All in One, komputer wbudowany w monitor. |
|
Zastosowanie |
Komputer będzie wykorzystywany dla potrzeb aplikacji biurowych, aplikacji edukacyjnych, aplikacji obliczeniowych, dostępu do Internetu oraz poczty elektronicznej, jako lokalna baza danych. |
|
Procesor |
Procesor, który powinien osiągać w teście wydajności PassMark PerformanceTest (wynik dostępny: xxxxx://xxx.xxxxxxxxxxxx.xxx/xxx_xxxx.xxx) co najmniej wynik 7 500 punktów Passmark CPU Mark. |
|
Pamięć RAM |
Min. 8 GB typu DDR4 2666 MHz Minimum 2 złącza SODIMM z obsługą do 32 GB DDR4 pamięci RAM. Konstrukcja komputera musi umożliwiać beznarzędziowy montaż i demontaż obu modułów pamięci |
|
Pamięć masowa |
Min. 256 GB SSD NVMe, zawierający partycję RECOVERY umożliwiającą odtworzenie systemu operacyjnego fabrycznie zainstalowanego na komputerze po awarii bez dodatkowych nośników |
|
Karta graficzna |
Zintegrowana |
|
Ekran |
Konstrukcja komputera powinna umożliwić demontaż stopy ekranu i powieszenie komputera np. na ścianie za pomocą standardowego złącza VESA (100x100 |
|
Wyposażenie multimedialne |
Karta dzwiękow Zintegrowana z płytą główną, zgodna z High Definition |
|
Obudowa |
Typu All-in-One zintegrowana z monitorem min. 23,8”. Obudowa musi umożliwiać zastosowanie zabezpieczenia fizycznego np. w postaci linki metalowej. Blokada ma uniemożliwiać otwarcie obudowy. Demontaż standu musi odbywać się bez użycia narzędzi, mocowanie standu opatrzone w przycisk zwalniający. Demontaż tylnej pokrywy musi odbywać się również bez użycia narzędzi, nie dopuszcza się stosowania śrub motylkowych, radełkowych czy zwykłych wkrętów. Możliwość zainstalowania komputera na ścianie przy wykorzystaniu ściennego systemu montażowego VESA 100x100. Każdy komputer powinien być oznaczony niepowtarzalnym numerem seryjnym umieszonym na obudowie, oraz musi być wpisany na stałe w BIOS. Wbudowany czujnik otwarcia obudowy współpracujący z oprogramowaniem zarządzająco – diagnostycznym. Wbudowany zasilacz o mocy maksymalnej 170 W pracujący w sieci 230V 50/60Hz prądu zmiennego i efektywności min. 90%, przy 50-procentowym obciążeniu. Zasilacz z certyfikatem 80plus GOLD. Obudowa musi mieć możliwość zabezpieczenia wnętrza komputera oraz wszystkich slotów znajdujących się z tyłu obudowy przed niepowołanym odstępem za pomocą kłódki lub linki typu Kensington. Ciężar komputera nie powinien przekraczać 10 kg. A suma wymiarów nie powinna być większa niż 1300 mm.) |
|
Zgodność z systemami opwracyjnymi i standardami |
Oferowany model komputera musi posiadać certyfikat Microsoft, potwierdzający poprawną współpracę z systemem operacyjnym Windows Pro 10 64bit |
|
System operacyjny |
Microsoft Windows 00 Xxx XX, zainstalowany system operacyjny Microsoft Windows 10 Pro niewymagający aktywacji za pomocą telefonu lub Internetu w firmie Microsoft. Dołączony nośnik z oprogramowaniem, sterownikami dla systemów Windows 10, płyty Recovery umożliwiające instalacje systemu wersji 64 bitowej.
|
|
Porty |
Microsoft Windows 00 Xxx XX, zainstalowany system operacyjny Microsoft Windows 10 Pro niewymagający aktywacji za pomocą telefonu lub Internetu w firmie Microsoft. Dołączony nośnik z oprogramowaniem, sterownikami dla systemów Windows 10, płyty Recovery umożliwiające instalacje systemu wersji 64 bitowej.
|
|
Karta sieciowa |
10/100/1000 Ethernet RJ 45, zintegrowana z płytą główną, wspierająca obsługę WoL (funkcja włączana przez użytkownika) |
|
bezpieczeństwo |
Zintegrowany z płytą główną dedykowany układ sprzętowy służący do tworzenia i zarządzania wygenerowanymi przez komputer kluczami szyfrowania. Zabezpieczenie to musi posiadać możliwość szyfrowania poufnych dokumentów przechowywanych na dysku twardym przy użyciu klucza sprzętowego (TPM co najmniej w wersji 2.0)
|
|
BIOS |
- modelu komputera; - modelu płyty głównej; - nr seryjnego komputera; - wersji BIOS (z datą); - modelu procesora wraz z informacjami o prędkości taktowania; - Informacji o ilości i obsadzeniu slotów pamięci RAM wraz z informacją o prędkości taktowania; - Informacji o dysku twardym: model oraz pojemność - MAC adresie zintegrowanej karty sieciowej - temperaturze procesora - temperaturze pamięci - statusie karty sieciowej
- karty sieciowej RJ45 - karty dźwiękowej - karty sieciowej bezprzewodowej i Bluetooth (jeśli zainstalowane) - zintegrowanej kamery (jeśli zainstalowana) - zintegrowanego mikrofonu (jeśli zainstalowany) - portu szeregowego z możliwością ustawienia trybu pracy - sprzętowego wsparcia wirtualizacji - wsparcia wirtualizacji Directed I/O - funkcji regulacji częstotliwości taktowania CPU w zależności od obciążenia (Enhanced SpeedStep) - funkcji Turbo Mode pozwalającej logicznym procesorom CPU osiągać wyższe częstotliwości taktowania od domyślnych w sytuacji gdy pozwalają na to termiczne parametry pracy procesora - kontrolera SATA - możliwość pojedynczego wyłączania poszczególnych portów SATA oraz M.2 - funkcji SMART - modułu TPM wraz z informacją o rodzaju aktualnie zainstalowanego modułu TPM - portów USB w tym: włączenia wszystkich portów, wyłączenia wszystkich portów, włączenia jedynie przednich i wewnętrznych, włączenia jedynie tylnych i wewnętrznych, włączenia jedynie wewnętrznych, włączenia jedynie używanych (system sprawdza przy starcie komputera, w których portach USB jest włączone urządzenie i tylko te aktywuje) - funkcji blokowania używanych portów USB w tym: włączenia wszystkich używanych portów, włączenia jedynie portów do których podłączono klawiaturę i mysz, włączenia wszystkich portów za wyjątkiem portów do których podłączono USB hub lub zewnętrzną pamięć masową. - funkcji Wake-on-LAN
- liczby aktywnych rdzeni procesora - funkcji sterowania prędkością wentylatorów w komputerze w co najmniej trzech trybach: Automatycznym, trybie zwiększonej przepływności powietrza w celu osiągnięcia maksymalnej wydajności procesora, trybie maksymalnej wydajności wszystkich wentylatorów. - trybu pracy karty sieciowej - możliwości aktualizacji BIOS-u w tym co najmniej: całkowite wyłączenie możliwości aktualizacji, możliwość aktualizacji za pomocą narzędzi producenta komputera lub mechanizmu Windows Update, możliwość aktualizacji jedynie za pomocą narzędzi producenta komputera - możliwość ustawienia trybu pracy komputera po przywróceniu zasilania po awarii zasilania w co najmniej trzech trybach: pozostaje wyłączony, zawsze wyłączony, zawsze włączony, przywrócenie stanu z przed awarii
|
|
klawiatura |
USB w układzie QWERTY US |
|
Mysz |
optyczna USB z trzema klawiszami oraz rolką (scroll) |
|
Napęd optyczny |
Nagrywarka DVD |
|
Normy i standardy |
Komputery mają spełniać normy i posiadać deklaracje zgodności (lub inne dokumenty potwierdzające spełnienie norm) w zakresie:
|
|
Warunki gwarancji |
Naprawy gwarancyjne urządzeń muszą być realizowane przez Producenta lub Autoryzowanego Partnera Serwisowego Producenta |
|
Wsparcie techniczne producenta |
|
|
Pakiet biurowy |
Zainstalowany i aktywowany pakiet aplikacji biurowych. Pakiet aplikacji biurowych minimalne wymagania ogólne: •Dostępny w architekturze 64-bitowej i 32-bitowej, •Wymagana polska wersja językowa, •Zgodny z zainstalowanym systemem operacyjnym, •Licencja bezterminowa przypisana do zaoferowane zestawu komputerowego.Pakiet aplikacji biurowych musi spełniać następujące wymagania minimalne: •Pakiet biurowy dostarczony wraz z licencją i nośnikiem. •Wymagania odnośnie interfejsu użytkownika: - Pełna polska wersja językowa interfejsu użytkownika. - Możliwość zintegrowania uwierzytelniania użytkowników z usługą katalogową – użytkownik raz zalogowany z poziomu systemu operacyjnego stacji roboczej ma być automatycznie rozpoznawany we wszystkich modułach oferowanego rozwiązania bez potrzeby oddzielnego monitowania go o ponowne uwierzytelnienie się. •Oprogramowanie musi umożliwiać tworzenie i edycję dokumentów elektronicznych w ustalonym formacie, który spełnia następujące warunki: - posiada kompletny i publicznie dostępny opis formatu, - ma zdefiniowany układ informacji w postaci XML zgodnie z aktualnie obowiązującymi przepisami i wymogami Rozporządzenia Rady Ministrów w sprawie Krajowych Ram Interoperacyjności, - umożliwia wykorzystanie schematów XML, wspiera w swojej specyfikacji podpis elektroniczny zgodnie z aktualnie obowiązującymi przepisami i wymogami Rozporządzenia Rady Ministrów w sprawie Krajowych Ram Interoperacyjności; •Oprogramowanie musi umożliwiać dostosowanie dokumentów i szablonów do potrzeb instytucji oraz udostępniać narzędzia umożliwiające dystrybucję odpowiednich szablonów do właściwych odbiorców. •W skład oprogramowania muszą wchodzić narzędzia programistyczne umożliwiające automatyzację pracy i wymianę danych pomiędzy dokumentami i aplikacjami (język makropoleceń, język skryptowy), •Do aplikacji musi być dostępna pełna dokumentacja w języku polskim. •Pakiet zintegrowanych aplikacji biurowych musi zawierać min.: - Edytor tekstów - Arkusz kalkulacyjny - Narzędzie do przygotowywania i prowadzenia prezentacji - Narzędzie do zarządzania informacją prywatną (pocztą elektroniczną, kalendarzem, kontaktami i zadaniami). •Edytor tekstów musi umożliwiać min.: - Edycję i formatowanie tekstu w języku polskim wraz z obsługą języka polskiego w zakresie sprawdzania pisowni i poprawności gramatycznej oraz funkcjonalnością słownika wyrazów bliskoznacznych i autokorekty. - Wstawianie oraz formatowanie tabel i obiektów graficznych. - Wstawianie wykresów i tabel z arkusza kalkulacyjnego (wliczając tabele przestawne). - Automatyczne numerowanie rozdziałów, punktów, akapitów, tabel, rysunków oraz tworzenie spisów treści. - Formatowanie nagłówków i stopek stron. - Sprawdzanie pisowni w języku polskim. - Śledzenie zmian wprowadzonych przez użytkowników. - Nagrywanie, tworzenie i edycję makr automatyzujących wykonywanie czynności. - Określenie układu strony (pionowa/pozioma). - Wydruk dokumentów. - Wykonywanie korespondencji seryjnej bazując na danych adresowych pochodzących z arkusza kalkulacyjnego i z narzędzia do zarządzania informacją prywatną. - Pracę min. na dokumentach utworzonych przy pomocy Microsoft Word 2003, 2007, 2010 i 2013 z zapewnieniem bezproblemowej konwersji wszystkich elementów i atrybutów Dokumentu. - Zabezpieczenie dokumentów hasłem przed odczytem oraz przed wprowadzaniem modyfikacji. - Wymagana jest dostępność do oferowanego edytora tekstu bezpłatnych narzędzi umożliwiających wykorzystanie go, jako środowiska udostępniającego formularze bazujące na schematach XML z Centralnego Repozytorium Wzorów Dokumentów Elektronicznych, które po wypełnieniu umożliwiają zapisanie pliku XML w zgodzie z obowiązującym prawem. - Wymagana jest dostępność do oferowanego edytora tekstu bezpłatnych narzędzi (kontrolki) umożliwiających podpisanie podpisem elektronicznym pliku z zapisanym dokumentem przy pomocy certyfikatu kwalifikowanego zgodnie z wymaganiami obowiązującego w Polsce prawa. - Wymagana jest dostępność do oferowanego edytora tekstu bezpłatnych narzędzi umożliwiających wykorzystanie go, jako środowiska udostępniającego formularze pozwalające zapisać plik wynikowy w zgodzie z Rozporządzeniem o Aktach Normatywnych i Prawnych. •Arkusz kalkulacyjny musi umożliwiać min.: - Tworzenie raportów tabelarycznych i wykresów liniowych (wraz linią trendu), słupkowych, kołowych. - Tworzenie arkuszy kalkulacyjnych zawierających teksty, dane liczbowe oraz formuły przeprowadzające operacje matematyczne, logiczne, tekstowe, statystyczne oraz operacje na danych finansowych i na miarach czasu. - Tworzenie raportów z zewnętrznych źródeł danych (inne arkusze kalkulacyjne, bazy danych zgodne z ODBC, pliki tekstowe, pliki XML, webservice). - Obsługę „kostek OLAP” oraz tworzenie i edycję kwerend bazodanowych i webowych. Narzędzia wspomagające analizę statystyczną i finansową, analizę wariantową i rozwiązywanie problemów optymalizacyjnych. - Tworzenie raportów tabeli przestawnych umożliwiających dynamiczną zmianę wymiarów oraz wykresów bazujących na danych z tabeli przestawnych. - Wyszukiwanie i zamianę danych. - Wykonywanie analiz danych przy użyciu formatowania warunkowego. - Nazywanie komórek arkusza i odwoływanie się w formułach po takiej nazwie. - Nagrywanie, tworzenie i edycję makr automatyzujących wykonywanie czynności. - Formatowanie czasu, daty i wartości finansowych z polskim formatem. - Zapis wielu arkuszy kalkulacyjnych w jednym pliku. - Zachowanie pełnej zgodności min. z formatami plików utworzonych za pomocą oprogramowania Microsoft Excel 2003, 2007, 2010 i 2013 z uwzględnieniem poprawnej realizacji użytych w nich funkcji specjalnych i makropoleceń. - Zabezpieczenie dokumentów hasłem przed odczytem oraz przed wprowadzaniem modyfikacji. •Narzędzie do przygotowywania i prowadzenia prezentacji musi umożliwiać min.: - Przygotowywanie prezentacji multimedialnych, które będą: a) Prezentowane przy użyciu projektora multimedialnego. b) Drukowane w formacie umożliwiającym robienie notatek. c) Zapisane jako prezentacja tylko do odczytu. - Nagrywanie narracji i dołączanie jej do prezentacji. - Opatrywanie slajdów notatkami dla prezentera. - Umieszczanie i formatowanie tekstów, obiektów graficznych, tabel, nagrań dźwiękowych i wideo. - Umieszczanie tabel i wykresów pochodzących z arkusza kalkulacyjnego. - Odświeżenie wykresu znajdującego się w prezentacji po zmianie danych w źródłowym arkuszu kalkulacyjnym. - Możliwość tworzenia animacji obiektów i całych slajdów. - Prowadzenie prezentacji w trybie prezentera, gdzie slajdy są widoczne na jednym monitorze lub projektorze, a na drugim widoczne są slajdy i notatki prezentera. - Pełna zgodność min. z formatami plików utworzonych za pomocą oprogramowania MS PowerPoint 2003, 2007 2010 i 2013. •Narzędzie do zarządzania informacją prywatną (pocztą elektroniczną, kalendarzem, kontaktami i zadaniami) musi umożliwiać min.: - Pobieranie i wysyłanie poczty elektronicznej z serwera pocztowego. - Filtrowanie niechcianej poczty elektronicznej (SPAM) oraz określanie listy zablokowanych i bezpiecznych nadawców. -Tworzenie katalogów, pozwalających katalogować pocztę elektroniczną. - Automatyczne grupowanie poczty o tym samym tytule. -Tworzenie reguł przenoszących automatycznie nową pocztę elektroniczną do określonych katalogów bazując na słowach zawartych w tytule, adresie nadawcy i odbiorcy. -Oflagowanie poczty elektronicznej z określeniem terminu przypomnienia. - Zarządzanie kalendarzem. - Udostępnianie kalendarza innym użytkownikom. - Przeglądanie kalendarza innych użytkowników. - Zapraszanie uczestników na spotkanie, co po ich akceptacji powoduje automatyczne wprowadzenie spotkania w ich kalendarzach. - Zarządzanie listą zadań. - Zlecanie zadań innym użytkownikom. - Zarządzanie listą kontaktów. - Udostępnianie listy kontaktów innym użytkownikom. - Przeglądanie listy kontaktów innych użytkowników. - Możliwość przesyłania kontaktów innym użytkowników. Oprogramowanie biurowe musi posiadać wszelkie dokumenty potwierdzające jego legalność Zamawiający wymaga fabrycznie nowego oprogramowania biurowego nieużywanego oraz nieaktywowanego nigdy wcześniej na innym urządzeniu. |
Integracja systemów dziedzinowych umożliwiających obsługę systemów e-usług
W ramach niniejszego zamówienia Wykonawca dostarczy oprogramowanie dziedzinowe w celu uruchomienia wymaganych e-usług, a także umożliwi dokonywanie płatności elektronicznych zobowiązań wobec Starostwa Powiatowego w Lwówku Śląskim.
Prace obejmują zadania związane z dostawą i wdrożeniem następujących modułów, realizujących wszystkie założenia projektu:
Integracja systemów dziedzinowych umożliwiających obsługę systemów e-usług
Szyna usług integrująca usługi e-PUAP, EZD i systemy dziedzinowe wraz z brokerem integracyjnym
Platforma usług publicznych udostępniającej dane z systemów dziedzinowych wraz z Systemem Elektronicznego Biura Obsługi Interesanta (EBOI),
Aplikacja mobilna zintegrowana z platformą usług publicznych.
Wykonawca, aby prawidłowo wykonać usługę musi dostarczyć i wdrożyć na rzecz Starostwa Powiatowego w Lwówku Śląskim wymienione w niniejszym rozdziale obszary z zakresu oprogramowania dziedzinowego, dokonać migracji wszystkich niezbędnych elementów a także przeszkolić pracowników zgodnie z wymaganiami.
Migracja zostanie przeprowadzona w siedzibie Zamawiającego pod nadzorem wyznaczonych pracowników Zamawiającego. Zamawiający posiada wsparcie producenta dla posiadanego i aktualnie użytkowanego przez Starostwo oprogramowania ważne zgodnie z poniższymi informacjami,nie posiada dokumentacji technicznej oraz nie przewiduje zawierania odrębnych umów z producentami posiadanych systemów na zapewnienie pomocy w migracji danych do nowego systemu.
SIGID Jednostka, Organ, Płace, Środki trwałe, Wieczyste użytkowanie, Vat – lokalizacja Starostwo Powiatowe w Lwówku Śląskim, licencja ważna do 31.12.2020 r.
Elektroniczny Obieg Dokumentów Xxxxx Xxxx Lublin lokalizacja Starostwo Powiatowe w Lwówku Śląskim, licencja ważna do 30.06.2020 r.
System Planowania i Realizacji Budżetu – Plan B firma DOSKOMP - lokalizacja Starostwo Powiatowe w Lwówku Śląskim i Jednostki Podległe, licencja ważna do 31.12.2020 r.
Rejestr Zaangażowania Środków Budżetowych – Zaangażowanie firma DOSKOMP - lokalizacja Starostwo Powiatowe w Lwówku Śląskim i Jednostki Podległe, licencja ważna do 31.12.2020 r.
Program Płatnik - - lokalizacja Starostwo Powiatowe w Lwówku Śląskim i Jednostki Podległe, licencja ważna darmowa.
W ramach zadania, Wykonawca ma obowiązek świadczenia gwarancji i asysty technicznej na dostarczone rozwiązania, zgodnie z wszystkimi wymaganiami opisanymi w niniejszym załączniku do SIWZ.
Ponadto, zgodnie z nowymi przepisami o obowiązku odbierania ustrukturyzowanych faktur elektronicznych wystawianych w związku z udzielonymi zamówieniami publicznymi, oferowany system musi być przystosowany do odbioru i przetwarzania faktur elektronicznych wystawianych przez wykonawców, w odniesieniu do udzielonych zamówień publicznych. System musi zatem umożliwiać integrację oferowanego systemu finansowo-księgowego z Platformą Elektronicznego Fakturowania (PEF) za pośrednictwem uniwersalnego API, celem usprawnienia procesu obsługi faktur.
Dodatkowo wszystkie dostarczane systemy muszą być zgodne z polityką bezpieczeństwa danych osobowych i muszą spełniać wymagania minimalne:
Każdy użytkownik systemu musi mieć przypisane indywidualne konto w systemie i musi zostać uwierzytelniony co najmniej podczas uruchamiania sesji.
Użytkownik nie może mieć możliwości przeglądania danych bez hasła.
System musi przechowywać hasła kont w postaci zaszyfrowanej.
System musi umożliwiać nadawanie ról/uprawnień użytkowników dla administratora systemu.
System musi rejestrować datę pierwszego wprowadzenia danych osobowych do systemu.
System musi rejestrować kto wprowadził dane osobowe do systemu.
System musi rejestrować kto wprowadził zmiany w danych osobowych w systemie.
System powinien raportować kto/co/kiedy zmienił w danych osobowych.
System finansowo- księgowy
Finanse i księgowość – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
|
|
Moduł finansowo-księgowy wraz z zintegrowanym systemem do obsługi budżetu powinien umożliwiać prowadzenie kartotek i planu budżetowego oraz kontrolę jego wykonania na wszystkich etapach wprowadzania dokumentu stanowiącego podstawę realizacji: umowy, dokumenty zobowiązań finansowych, faktury i inne dokumenty kosztowe, wydatki oraz kompensaty. |
|
Moduł finansowo-księgowy powinien prowadzić ewidencję zapisów finansowych w układzie kont księgi głównej oraz klasyfikacji i zadań budżetowych, a mechanizmy analizy i prezentacji danych powinny umożliwiać wgląd w wykonanie budżetu poprzez warstwę kont syntetycznych (zakładowy plan kont), klasyfikację budżetową (dział, rozdział, paragraf, tytuł wydatków/dochodów), zadania budżetowe (wydział, zadanie, typ, rodzaj). |
|
Moduł finansowo-księgowy powinien posiadać rozbudowane mechanizmy powiązań pomiędzy kontami zakładowego planu kont i analityką budżetową (klasyfikacja budżetowa i powiązane zadania) umożliwiające tworzenie dynamicznych powiązań pomiędzy tymi dwoma zbiorami tzn. wprowadzenie jednorazowe klasyfikacji budżetowej bez potrzeby wiązania ich z kontami syntetycznymi. |
|
Moduł finansowo-księgowy powinien posiadać rejestr umów i zamówień z jednoczesnym odniesieniem ich na konta zaangażowania z uwzględnieniem klasyfikacji i zadań budżetowych. |
|
Moduł finansowo-księgowy powinien posiadać obsługę podatku VAT zgodną z wymogami przepisów o centralizacji rozliczeń VAT w JST, tzn. posiadać warstwę wewnętrzną na potrzeby rozliczeń bieżących jednostki nadrzędnej (agregacja deklaracji cząstkowych) oraz warstwę zewnętrzną (udostępnioną poprzez przeglądarkę internetową dla jednostek organizacyjnych) tworzenie deklaracji cząstkowych wraz z niezbędnymi dokumentami źródłowymi. |
|
Moduł finansowo-księgowy powinien umożliwiać prowadzenie ewidencji środków trwałych i wartości niematerialnych i prawnych oraz środków niskocennych. Ewidencja środków trwałych powinna być powiązana z procesem inwentaryzacji i z innymi programami do obsługi mienia Powiatu i Skarbu Państwa. |
|
Moduł finansowo-księgowy powinien umożliwiać terminowe rozliczanie zobowiązań, w tym zapewnić niezbędną kontrole w zakresie szczegółowości klasyfikacji budżetowej, jak również zapewniać współpracę z systemami bankowości elektronicznej w zakresie generowania poleceń przelewu, jak również automatycznego księgowania wyciągów bankowych. |
|
Moduł finansowo-księgowy powinien współpracować z systemem EZD – współpraca powinna przebiegać online w sposób dwukierunkowy. |
|
Moduł finansowo-księgowy musi zapewniać integrację danych z jednostek organizacyjnych w ramach budżetu powiatu. Muszą umożliwiać automatyczne sporządzanie sprawozdań finansowych i budżetowych oraz współpracę z systemem BeSti@. |
|
Dostęp do systemu powinien być zrealizowany poprzez konto użytkownika zdefiniowane przez administratora systemu. |
|
Konto użytkownika powinno składać się z loginu i hasła oraz parametrów określających typ konta: konto aktywne, konto zablokowane, konto użytkownika nadrzędnego tzw. Administrator. |
|
Moduł powinien umożliwiać integracje konta użytkownika z domeną urzędu. |
|
Moduł powinien umożliwiać integracje konta użytkownika z kontami w innych systemach zewnętrznych takich jak EZD. |
|
Moduł powinien umożliwiać na kreowanie własnej polityki haseł poprzez wykorzystanie parametrów systemowych określających co najmniej:
|
|
Moduł powinien posiadać możliwość zdefiniowania tzw. Czasu bezczynności. |
|
Moduł musi posiadać możliwość kontekstowego trybu pracy tj. definiowalna struktura jednostek organizacyjnych oraz dzienników dostosowana do zakresu obowiązków pracowników. |
|
Moduł musi posiadać możliwość definiowania dostępu do poszczególnych opcji menu funkcyjnego programu oraz elementów struktury organizacyjnej (jednostka/dziennik), tak aby odpowiadało to zakresowi obowiązków (podgląd/edycja /administrowanie). |
|
Moduł musi mieć możliwość wglądu w przetwarzane dane w sposób wynikający z nadanych uprawnień tj. dostęp do informacji wybranego dziennika lub księgi głównej będącej agregacją zapisów wszystkich zdefiniowanych dzienników. |
|
Struktura zakładowego planu konta powinna mieć postać „drzewa elementów” z uwzględnieniem zależności zachodzących pomiędzy elementami (konta nadrzędne i podrzędne). |
|
Moduł powinien umożliwiać dowolne kreowanie zakładowego planu kont zgodnie z wymogami użytkowników tzn. że nie powinien się ograniczać do sztywnego formatu struktury konta na poszczególny gałęziach. |
|
Elementy planu kont powinny posiadać szereg atrybutów określających typ konta i przyporządkowanie:
|
|
W zakresie tworzenia i modyfikacji elementów planu kont moduł powinien posiadać szereg niezbędnych funkcji takich jak:
|
|
Moduł powinien umożliwiać tworzenie planu kont z możliwością:
|
|
Moduł powinien zapewnić przejrzystą prezentację danych w zakresie sald na wybrany dzień na koniec miesiąca, w układzie narastającym oraz miesięcznym. |
|
Moduł z poziomu planu konta dla wybranego elementu powinien umożliwiać przeglądanie wszystkich danych w układzie analitycznym (poszczególne dekretacje) z możliwością selekcji wg atrybutów : stan do miesiąca, stan z miesiąca z zakresu dat dla wybranej klasyfikacji budżetowej i zadania a także obszaru: koszty, wydatki, zaangażowanie. |
|
Moduł z poziomu planu kont powinien umożliwić wydruk (dla dowolnego wybranego elementu struktury – konta):
|
|
Moduł powinien umożliwić z poziomu planu kont na wgląd w stan rozrachunków wynikających z zapisów księgowych. Dane powinny być zebrane w sposób syntetyczny identyfikujący co najmniej takie informacje jak: stan należności, stan nadpłat z tytułu należności, stan zobowiązań, stan nadpłat z tytułu zobowiązań. |
|
Moduł powinien umożliwić wydruk salda konta w układzie rozrachunkowym: Należności / Zobowiązania. |
|
Moduł z poziomu planu kont powinien umożliwić na dokonanie analizy należnych odsetek. |
|
Moduł w obszarze planu kont powinien mieć być wyposażony w wyszukiwarkę działającą w obszarze min. następujących kryteriów:
|
|
Moduł w obszarze planu kont powinien być wyposażony w możliwość tworzenia obiektów przeliczeniowych tzn. zbiorów kont identyfikujących określone wartości np. koszty, przychody. Elementy obiektów muszą podlegać aktualizacji poprzez funkcjonalność dodawania lub odejmowania kolejnych. Dla poszczególnych obiektów system powinien dynamicznie naliczać wartości sald i obrotów a co z tym związane powinien posiadać odpowiednią warstwę prezentacji spójną z prezentacją sald na kontach. |
|
Moduł powinien być wyposażony w mechanizmy definicji danych dla potrzeb sprawozdań RB-N i RB-Z. |
|
Moduł powinien być wyposażony w podgląd grup sprawozdawczych (RB-N/RB-Z) wraz z przyporządkowanymi elementami planu kont. |
|
Moduł powinien umożliwiać przyporządkowanie do wybranej grupy (RB-N/RB-Z) wskazanych kont. |
|
Moduł powinien umożliwiać na zdefiniowanie jaki zakres danych z konta ma zostać przypisany do wybranego obszaru sprawozdania RB-N / Rb-Z tzn. Saldo Wn, Saldo Ma, Saldo, Obroty Wn, Obroty Ma. Na podstawie danych zawartych na kontach rozrachunkowych system powinien automatycznie rozdzielać salda na zaległości i pozostałe należności oraz zobowiązania wymagalne i pozostałe zobowiązania. |
|
Moduł musi pozwalać na przeglądanie stanów i obrotów kont, oraz ich wydruk w formie kont syntetycznych i analitycznych w formacie A4. |
|
Moduł musi być połączony z system geodezyjnym w zakresie automatycznego tworzenia kont kontrahentów. |
|
Moduł musi pozwalać na wprowadzanie bilansu otwarcia (generowanie B.O. automatycznie) z możliwością:
|
|
Moduł musi zapewniać zamknięcie roku z możliwością zachowania na koniec zamykanego roku sald wszystkich kont analitycznych i jednocześnie uzyskania zerowych sald wybranych kont syntetycznych – salda dwustronne. |
|
Moduł musi umożliwiać rejestrację operacji gospodarczych w dziennikach z możliwością:
|
|
Moduł musi umożliwiać księgowanie na bieżąco dowodów księgowych. |
|
Moduł musi umożliwiać automatyczne i ciągłe numerowanie dowodów księgowych. |
|
Moduł musi umożliwiać tworzenie procedur automatycznego dokonywania przeksięgowywań rocznych i miesięcznych, zgodnie z ustawą o rachunkowości (grupy kont 1,2,4,5,7,8 oraz przeksięgowań i wyksięgowań obowiązujących dla rozpoczęcia roku (konta grupy 8 i pozabilansowe wydatków strukturalnych). |
|
Moduł musi zapewniać możliwość rejestracji różnych typów dokumentów dochodowych, przychodowych, rozchodowych i wydatkowych, w tym x.xx.:
|
|
Moduł musi zapewniać możliwość samodzielnego definiowania kolejnych rodzajów dokumentów. |
|
Moduł musi zapewniać dekretację zarejestrowanych dokumentów zarówno w zakresie zapisów księgowych, jak i klasyfikacji budżetowej. |
|
Moduł musi umożliwiać prowadzenie centralnego rejestru dowodów księgowych na poziomie wydziału finansowego jak również wydziałów merytorycznych. |
|
Moduł powinien posiadać mechanizmy integracyjne pozwalające na pobieranie danych z systemów zewnętrznych, w szczególności takich jak:
|
|
Moduł powinien posiadać możliwość dekretacji wg podzielnika kosztowego tj. dekretowanie dokumentu wg ustalonej struktury podziału na wskazane klasyfikacje budżetowe. |
|
Moduł powinien posiadać możliwość kopiowania dekretacji w obrębie wprowadzanego dokumentu. |
|
Moduł powinien posiadać możliwość kopiowania dokumentu wraz z dekretacjami w różnych konfiguracjach:
|
|
W przypadku faktur VAT, moduł powinien zapewnić funkcjonalność umożliwiającą dokonanie odliczeń części lub całości podatku VAT, zgodnie z obowiązującymi w tym zakresie przepisami. |
|
W przypadku częściowego odliczania podatku VAT, powinna być możliwość zdefiniowania wskaźników odliczeń podatku, automatyczne dekretowanie i księgowanie części faktury na zdefiniowane rejestry. |
|
Moduł musi umożliwiać wprowadzenie wskaźników dotyczących podziału faktur oraz szablonów księgowania faktur i umożliwić automatyczne rozksięgowanie faktur wg wpisanych wskaźników i szablonów. |
|
Moduł musi umożliwiać wystawianie faktur według wpisanych szablonów. |
|
Moduł powinien posiadać mechanizmy integracyjne pozwalające na pobieranie danych z systemów zewnętrznych ( systemów dziedzinowych- w tym z opłatomatu) takich jak:
|
|
Moduł powinien współpracować z systemem: Ośrodek w zakresie obsługi kont księgowych dotyczących kontrahentów Wydziału Geodezji, kartografii i katastru ( zakładanie kont, kontrola kont istniejących, wyliczanie należności za asortyment z systemu Ośrodek). |
|
Moduł musi umożliwiać wprowadzanie i identyfikację klientów po NIP i PESEL oraz wyszukiwanie klientów po zadanych kryteriach, za pomocą filtra po zadaniu różnych parametrów np. nazwa kontrahenta, numer faktury, kwota itp. |
|
Moduł musi przygotowywać przelewy bankowe z możliwością eksportu do systemu bankowego. |
|
Moduł musi podpowiadać konta księgowe i konta klasyfikacji budżetowej na podstawie klasyfikacji budżetowej zawartej w numerze konta. |
|
Moduł musi mieć możliwość importu dokumentów w formacie pdf i automatycznego podstawiania danych do księgowanian. Np. import faktur z systemu obiegu dokumentów. |
|
Moduł musi umożliwiać generowanie plików JPK, ich scalanie z innymi plikami i automatyczne wysyłanie za pośrednictwem dedykowanych systemów/portali. Struktury plików musza być zgodne z wytycznymi Ministerstwa Rozwoju i Finansów. |
|
Moduł musi umożliwiać przygotowanie zestawień i ich wydruk według wzorów wprowadzonych przez Zamawiającego. |
|
Moduł musi zapewniać kontrolę dokumentu stanowiącego zobowiązanie, ze stanem realizacji umowy z kontrahentem (jeżeli umowa poprzedza dokument wydatkowy), na podstawie danych zawartych w module rejestr umów i dokumentów, a także kontrolę tego dokumentu z planem finansowym, na każdym jego etapie, rejestracji, oraz kolejnych akceptacji w pełnej szczegółowości określonej w planie budżetu. |
|
Moduł musi zapewnić mechanizmy, które umożliwią rejestrację dokumentu w systemie z wielostopniową akceptacją zgodnie z obowiązującymi zasadami kontroli wewnętrznej:
Organizacja akceptacji musi być przejrzysta i odpowiadać drodze obiegu dokumentu. |
|
Moduł musi zapewniać możliwość generowania na podstawie wprowadzonych dokumentów kosztowych plików zawierających polecenia przelewów do systemu bankowego posiadanego przez Zamawiającego. |
|
Moduł musi zapewniać tworzenie jednego, wspólnego rejestru dokumentów przychodzących. |
|
Moduł musi posiadać możliwość przeniesienia dokumentu do rejestru zakupu VAT. |
|
Moduł musi umożliwić tworzenie rejestrów z uwzględnieniem korekt z różnych okresów rozliczeniowych w tym z lat ubiegłych z uwzględnieniem zachowania archiwalnych wersji poprzednich rejestrów. |
|
W przypadku faktur VAT, moduł musi zapewnić funkcjonalność umożliwiającą dokonanie odliczeń części lub całości podatku VAT, zgodnie z obowiązującymi w tym zakresie przepisami z uwzględnieniem tworzenia rejestru zakupów dotyczących sprzedaży opodatkowanej oraz rejestru dotyczące sprzedaży opodatkowanej i zwolnionej. |
|
Moduł musi umożliwiać prowadzenie centralnego rejestru dowodów księgowych na poziomie wydziału finansowego jak również wydziałów merytorycznych. |
|
Moduł musi zapewniać dekretację zarejestrowanych dokumentów zarówno w zakresie zapisów księgowych jak i klasyfikacji budżetowej. |
|
Moduł musi zapewniać możliwość samodzielnego definiowania kolejnych rodzajów dokumentów. |
|
Moduł musi zapewniać możliwość rejestracji różnych typów dokumentów rozchodowych i wydatkowych, w tym x.xx.:
|
|
Moduł powinien posiadać możliwość importu elektronicznego wyciągu bankowego w co najmniej dwóch standardach np: Home net – xml, MT940 – txt, PBS – xml. |
|
Moduł powinien posiadać obszar funkcjonalny pozwalający na dokonywanie analizy wczytanego wyciągu bankowego i wiązanie go z rozrachunkami dokumentów kosztowych tak aby powstały automatycznie zapisy identyfikujące wydatki budżetowe. |
|
Moduł powinien umożliwiać realizację usługi płatności masowych. |
Analiza budżetu – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł musi pozwalać na prowadzenie ewidencji zaangażowania środków budżetowych w poszczególnych paragrafach klasyfikacji budżetowej na poziomie każdej jednostki organizacyjnej, jak i całego budżetu. |
|
Moduł powinien umożliwiać prowadzenie ewidencji klasyfikacji budżetowej w podziale na: wydatki, dochody, przychody oraz rozchody. |
|
Moduł powinien umożliwiać tworzenie struktury budżetu w układzie dwupłaszczyznowym: klasyfikacja budżetowa i zadania budżetowe. |
|
Moduł powinien umożliwiać budowanie struktury klasyfikacji budżetowej w oparciu o zdefiniowane słowniki w zakresie:
|
|
Moduł powinien umożliwić budowanie struktury zadań budżetowych w oparciu o zdefiniowane słowniki w zakresie:
|
|
Moduł musi pozwalać na prowadzenie ewidencji zaangażowania środków budżetowych w poszczególnych paragrafach klasyfikacji budżetowej na poziomie każdej jednostki organizacyjnej, jak i całego budżetu. |
|
Moduł musi posiadać warstwę prezentacyjną pozwalającą na swobodne przeglądanie stanu wykonania budżetu z uwzględnieniem wartości:
|
|
Moduł powinien pozwalać na prowadzenie analiz wg. kryteriów:
|
|
W zakresie tworzenia i modyfikacji elementów struktury klasyfikacji i zadań budżetowych moduł powinien posiadać szereg niezbędnych funkcji takich jak:
|
|
Moduł umożliwiać tworzenie struktury budżetu przy pomocy par elementów analitycznych: klasyfikacja budżetowa / zadanie tzn. że tylko takie elementy mogą podlegać przetwarzaniu. |
|
Moduł powinien uniemożliwiać tworzenie zapisów księgowych dla elementów budżetu niepowiązanych. |
|
Moduł powinien posiadać możliwość importu uchwał budżetowych z systemu planowania budżetu, opcjonalnie z systemu BeStia@. |
|
Moduł powinien posiadać możliwość eksportu uchwał budżetowych do systemu BeStia@. |
|
Moduł powinien posiadać obszar odpowiedzialny za analizę stanu planu budżetowego w podziale na uchwały i zarządzenia. |
|
Moduł powinien mieć możliwość:
|
|
Moduł powinien być wyposażony w możliwość tworzenia obiektów przeliczeniowych tzn. zbiorów klasyfikacji i zadań budżetowych identyfikujących określone wartości np. jednostka, inwestycja. Elementy obiektów muszą podlegać aktualizacji poprzez funkcjonalność dodawania lub odejmowania kolejnych. Dla poszczególnych obiektów system powinien dynamicznie naliczać wartości stanu wykonania budżetu a co z tym związane powinien posiadać odpowiednią warstwę prezentacji spójną z prezentacją wartości na poszczególnych elementach budżetu. |
|
Moduł musi posiadać moduł kontroli informujący o przekroczeniach zaplanowanego budżetu w zakresie klasyfikacji budżetowej według zadanej daty, zadań oraz umów. Rodzaje przekroczeń które muszą podlegać analizie:
|
|
Moduł musi umożliwiać przygotowanie zestawień i ich wydruk:
|
|
Moduł musi umożliwiać wprowadzanie wzorców wydruków przez Zamawiającego. |
|
Moduł powinien posiadać możliwość tworzenia zestawień w układzie sprawozdawczym RB-27S i RB-28S z uwzględnieniem stanu należności i zobowiązań. |
|
Moduł powinien posiadać możliwość wydruku stanu wykonania budżetu co najmniej w zakresie danych:
|
|
Moduł powinien posiadać możliwość wydruku stanu wykonania budżetu co najmniej w zakresie:
|
|
Moduł powinien posiadać możliwość analizy absorbcji planu budżetowego wynikających z wartości zawieranych umów. |
|
Moduł powinien posiadać możliwość kontroli wartości zawartej umowy ze stanem jej realizacji w poszczególnych klasyfikacjach i zadaniach budżetowych. |
|
Integralną częścią modułu powinien być portal sprawozdawczości budżetowej poprzez który jednostki organizacyjne składają swoje miesięczne sprawozdania z wykonania budżetu: RB-27S i RB-28S. |
|
Portal sprawozdawczości budżetowej powinien:
Poprzez odpowiedni system hierarchiczny powinien umożliwiać, w jednostce nadrzędnej publikację (sprawozdań jednostkowych) na zewnątrz, poprzez odpowiednio sprofilowany portal internetowy – dane powinny być udostępnione do pobrania min. w formacie pdf, xls. |
|
Moduł (w zakresie jednostki nadrzędnej – Organ) powinien posiadać słownik jednostek podległych składających sprawozdania z wykonania budżetu. |
|
Moduł powinien posiadać możliwość pobrania złożonego przez jednostkę sprawozdania (za pośrednictwem usługi web service) i dokonania analizy danych poprzez:
|
Rejestr VAT – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł powinien zapewnić możliwość prowadzenia centralnego rejestru sprzedaży uwzględniającego możliwość wystawienia dokumentów następujących typów:
|
|
Moduł powinien mieć możliwość współpracy z drukarkami fiskalnymi zarówno w standardzie POSNET jak i ELZAB. |
|
Moduł powinien posiadać możliwość definiowania numeratora dokumentów sprzedażowych stosownie do potrzeb wynikających ze specyfiki sprzedaży i wymogów procesu centralizacji rozliczeń VAT w JST. |
|
Moduł powinien posiadać możliwość kopiowania dokumentów sprzedaży. |
|
Moduł powinien posiadać możliwość tworzenia szablonów dokumentów sprzedaży. |
|
Moduł powinien posiadać możliwość wydruku faktur w formie pojedynczego dokumentu oraz w trybie zbiorowym (dla zaznaczonych pozycji). |
|
Moduł powinien posiadać możliwość wydruku koperty do faktury w formie pojedynczego dokumentu oraz w trybie zbiorowym (dla zaznaczonych pozycji). |
|
Moduł powinien posiadać możliwość dokonywania dekretacji faktury przy pomocy zdefiniowanego szablonu rozksięgowania tak aby operator nie musiał wybierać kont i klasyfikacji budżetowej. |
|
Moduł powinien posiadać możliwość dokonywania analizy sprzedaży wg kryterium: stawka VAT, rodzaj sprzedaży. |
|
Moduł powinien umożliwiać generowanie rejestru sprzedaży VAT za wybrany okres rozliczeniowy. |
|
Moduł powinien posiadać możliwość tworzenia zestawień sprzedaży wg różnych kryteriów: typ dokumentu, okres, dokument fiskalny, kontrahent, stawka VAT. |
|
Moduł powinien umożliwić prowadzenie rejestru VAT zakupów z uwzględnieniem odliczeń podatku VAT w zakresie części lub całości, zgodnie z obowiązującymi w tym zakresie przepisami z uwzględnieniem tworzenia rejestru zakupów dotyczących sprzedaży opodatkowanej oraz rejestru dotyczącego sprzedaży opodatkowanej i zwolnionej. |
|
Moduł powinien umożliwić wybór sposobu odliczenia podatku (wariant częściowy): przy pomocy wskaźnika, prewskaźnika lub iloczynu tych dwóch wartości. |
|
Moduł powinien umożliwić przyporządkowanie do dokumentu zakupu wielu klasyfikacji budżetowych celem dokonania analizy odliczeń PTU z uwzględnieniem tego kryterium. |
|
Moduł powinien umożliwić dokonywania automatycznych dekretacji dokumentów handlowych (sprzedaż i zakup) za pomocą wcześniej zdefiniowanych schematów księgowań. |
|
Moduł powinien umożliwić sporządzanie deklaracji VAT-7 (na podstawie wprowadzonych dokumentów handlowych). |
|
Moduł powinien umożliwiać tworzenie zbiorów JPK w zakresach wymaganych przez ustawodawcę. |
|
Moduł powinien umożliwić wysyłkę deklaracji VAT i zbiorów JPK z użyciem podpisu kwalifikowanego. |
|
Moduł powinien umożliwić bezpośredni zapis dokumentów wychodzących (sprzedaż) do modułu EZD za pośrednictwem serwisu komunikacyjnego . |
|
Moduł powinien posiadać funkcjonalność pozwalającą na realizację zadań związanych z centralizacją rozliczeń VAT w JST. Funkcjonalność ta powinna składać się z:
|
|
Portal powinien być dostępny poprzez przeglądarkę internetową. |
|
Portal i mechanizmy w nim zawarte mają służyć standaryzacji procedur, usprawnieniu gromadzenia danych oraz sporządzania deklaracji VAT w JST. |
|
Portal powinien być bezpośrednio powiązany z modułem obsługi deklaracji VAT Systemu finansowo-księgowego tzn., że dane powinny być przetwarzane w jego obrębie. |
|
Dostęp do portalu musi być możliwy poprzez bezpieczne logowanie z użyciem identyfikatora i zaszyfrowanego hasła oraz przez autoryzację z wykorzystaniem powszechnie dostępnego profilu zaufanego (xxxxx://xx.xxx.xx). |
|
Portal powinien udostępniać dane zalogowanemu użytkownikowi tylko w zakresie uprawnień nadanych przez administratora systemu finansowo – księgowego. |
|
Portal powinien umożliwić (jednostkom organizacyjnym JST) złożenie stosownych dokumentów niezbędnych do naliczenia zbiorczej deklaracji VAT.Te dokumenty to: deklaracja cząstkowa VAT-7 wypełniana ręcznie (formularz dostępny w module) lub wypełniana automatycznie poprzez import z pliku oraz niezbędne załączniki: rejestry sprzedaży i zakupów w formacie pdf lub xls, zestawienie obrotów i sald, rejestr sprzedaży i zakupów w formacie JPK. Portal powinien umożliwić komunikację pomiędzy jednostką organizacyjną i JST w zakresie informowania o kompletności dostarczanej dokumentacji. Powinno się to odbywać poprzez system wielostopniowej akceptacji. |
|
Portal powinien dokonywać walidacji składanej deklaracji VAT-7 z dołączanymi rejestrami w formacie JPK. |
|
Wymiana danych powinna zostać zabezpieczona za pomocą transmisji z wykorzystaniem tokenu oraz znacznika czasu. Przy nieprawidłowych dodatkowych danych metoda nie powinna się wykonać i powinien zostać zwrócony stosowny komunikat z błędem. |
|
Moduł musi funkcjonować na ogólnodostępnym serwerze internetowym i udostępniać swoją treść przy wykorzystaniu przeglądarek WWW. Budowa strony internetowej musi spełniać ogólnie przyjęte standardy kodowania WWW oraz zgodność z normą WCAG 2. |
|
Wyświetlanie danych dokonywane jest za pomocą przeglądarki internetowej bez konieczności instalacji dodatkowego oprogramowania, po stronie użytkownika. |
|
Komunikacja z systemem finansowo-księgowym powinna być oparta o technologię web-service, wymiana danych musi przebiegać poprzez bezpieczne, szyfrowane połączenie za pośrednictwem portali komunikacyjnych. |
|
Moduł powinien posiadać zaimplementowane mechanizmy umożliwiające automatyzację wymiany danych pomiędzy modułem a systemem dziedzinowym. Dostępność aktualnych danych nie może dodatkowo angażować operatorów systemów dziedzinowych. |
|
Udostępnianie danych użytkownika następuje po zalogowaniu się użytkownika na jego indywidualne konto. |
Rejestr umów – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł musi umożliwiać katalogowanie dokumentów umów w przynajmniej czterech kartotekach:
|
|
Moduł w zakresie rejestru umów musi być powiązany integralnie z:
|
|
Moduł musi posiadać wbudowane narzędzia administracyjne pozwalające na przypisywanie uprawnień użytkownikom co najmniej w zakresie dostępu do określonego wydziału, rachunku bankowego oraz rodzaju dochodu / wydatku. Możliwość przydzielania dostępu do poszczególnych funkcji modułu np. rejestracji, akceptacji, zakańczania oraz definiowania schematu numeracji umów / dokumentów. |
|
Moduł musi umożliwiać rejestrację wszelkiego rodzaju umów / dokumentów, np.:
|
|
Moduł musi umożliwiać wprowadzenie danych dokumentu w zakresie:
|
|
Moduł powinien posiadać możliwość weryfikacji ustalonego planu finansowania umowy z kwotami planu budżetowego jednostki – sprawdzenie ewentualnych przekroczeń. |
|
Moduł powinien umożliwiać wprowadzanie kolejnych zmian do umowy jako aneksy dokumentu, dane poprzednie powinny pozostać oznaczone jako archiwalne. |
|
Moduł powinien umożliwiać połączenie dokumentu wprowadzonego na zaangażowanie z fakturą i przelewem. |
|
Moduł powinien umożliwiać wyszukiwanie danych wg kryteriów dostępnych w formularzu umowy. |
|
Moduł powinien umożliwiać automatyczną dekretacje zaangażowania środków w podziale na rok bieżący i lata następne. |
|
Do rejestru umów musi być możliwość załączenia scanu umowy i umieszczenie jej w wydzielonym pliku. |
|
Moduł musi umożliwiać generowanie raportów pod kątem zadanych parametrów, np. daty zakończenia umowy, nazwy kontrahenta, zabezpieczenia należytego wykonania umowy, Do rejestru umów musi być możliwość załączenia scanu umowy. |
|
Moduł musi umożliwiać nadawanie ograniczonych uprawnień do wprowadzania danych, przeglądania itp. |
Sprawozdawczość – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł musi mieć możliwość definiowania oraz sporządzania zestawień wynikowych takich jak:
|
|
Moduł powinien posiadać możliwość definiowania algorytmu wyliczenia wartości poszczególnych komórek zestawień wynikowych wymienionych powyżej. |
|
Moduł musi realizować obsługę sprawozdań budżetowych w zakresie:
|
|
Moduł musi pozwalać na generowanie zestawień i ich wydruk w przekroju jednostek organizacyjnych, klasyfikacji budżetowej oraz zadań, zapisywanie tych zestawień do formatu PDF i wysyłanie w formie elektronicznej do jednostek poprzez system EZD. |
|
Moduł musi pozwalać na generowanie raportów sprawozdawczych dla XXX (Xx-00X, Xx-00xx, Xx-00X, Xx-00, Xx-00X, Xx-00X, Xx-00,Xx-Xxx, Xx-X, Rb-N, RB-ZN, RB-UZ, RB-UN, RB-PDP) z możliwością ich eksportu do programu BeSTi@. |
|
Moduł musi pozwalać na generowanie sprawozdania Rb-Wsa zarówno dla wybranego konta (dziennika) jaki zbiorczo dla wszystkich wydatków. |
|
Moduł musi generować w postaci elektronicznej sprawozdania w formacie wymaganym przez RIO i eksportować dane do wymaganego przez RIO systemu sprawozdawczości budżetowej (obecnie system BeSti@ i obowiązujące prawnie systemy sprawozdawcze). |
|
Funkcjonalność sprawozdawczości budżetowej powinna zwierać również możliwość:
|
|
Moduł powinien posiadać mechanizmy definiujące naliczenie poszczególnych wartości w poszczególnych polach sprawozdań budżetowych. |
Obsługa kartoteki opłat – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł musi zapewniać możliwość definiowania kontekstów pracy odpowiadającym grupom należności dla których będą tworzone kartoteki opłat (na podstawie dokumentów źródłowych), w szczególności:
|
|
Konteksty pracy muszą mieć możliwość indywidualnej parametryzacji tzn. przypisania charakterystycznych wartości określających typ opłaty: cykliczność, czy opłata związana jest z potrzebą wystawienia faktury, domyślna stawka VAT, stawka z kartoteki towarów, sposób fakturowania (od netto/od brutto), termin płatności, schemat księgowań. |
|
W skład modułu muszą wchodzić dwa elementy:
|
|
Kartoteka opłat oraz konta księgowe muszą być ze sobą powiązane w ten sposób, aby:
|
|
Moduł musi umożliwiać wprowadzanie dokumentów przez użytkowników komórek organizacyjnych z przypisaną do ich kompetencji funkcjonalnością oraz udostępnianie mechanizmów kontroli. |
|
Moduł musi umożliwiać automatyczną dekretację (poprzez zdefiniowane i przypisane szablony) naliczeń zarówno w zakresie zapisów księgowych jak i klasyfikacji dochodów i wydatków budżetowych – w pełnej szczegółowości planu określonej w module planowania budżetu, będącego przedmiotem wdrożenia. |
|
Moduł musi umożliwiać automatyczne wystawianie dokumentu (np. Faktury VAT) na podstawie danych z modułu rejestr umów i dokumentów. |
|
Moduł musi uniemożliwiać wprowadzenie modyfikacji do faktury, która została zaakceptowana i zadekretowana (system weryfikacji przez akceptację, który nie pozwoli na zmiany). Moduł musi umożliwiać anulowanie faktury w przypadku, gdy nie weszła do obrotu prawnego bądź wystawić fakturę korekta jeśli jest w obrocie prawnym. |
|
Dokumenty wystawione na podstawie danych z modułu rejestr umów i dokumentów muszą być kompletne i nie mogą wymuszać na operatorze ingerencji w dane. Oczywiście na żądanie operatora moduł musi umożliwiać ręczną poprawę danych w dokumencie. |
|
Moduł musi uniemożliwiać wielokrotne wystawianie dokumentu na przypis wynikający z modułu rejestr umów i dokumentów (w przypadku wykorzystania całej kwoty przypisu). |
|
Moduł musi umożliwiać ręczne wystawianie dokumentów oraz ich kopiowanie z automatycznym wprowadzeniem do rejestru VAT. |
|
Moduł musi umożliwiać wyszukiwanie kontrahenta wg wielu kryteriów (ich fragmentów), w szczególności: nazwisko, imię, adres zamieszkania, NIP, PESEL, adres (położenie) przedmiotu opodatkowania. |
|
Moduł musi umożliwiać przeksięgowanie nadpłat na inną należność, możliwość zwrotu nadpłaty kontrahenta. |
|
Moduł musi umożliwiać uzupełnienie oraz poprawianie daty doręczenia dla wystawionych pism (np. upomnień). |
|
Moduł musi posiadać wbudowany kalkulator odsetkowy. |
|
Moduł musi umożliwiać realizację kontroli naliczonych wartości opłat z zapisami księgowymi zadekretowanymi na kontach księgowych np. wyszukanie kart opłat które mają naliczoną opłatę i nie jest ona zadekretowana na koncie księgowym. |
|
Moduł musi pozwalać wykonać i wydrukować rejestr wystawionych pism, np. rejestr wezwań do zapłaty. |
|
Moduł musi umożliwiać wprowadzenie własnych szablonów dokumentów. |
|
Moduł musi umożliwiać wykonywanie operacji zbiorowych na kartotekach opłat takich jak:
zadekretować wykonane naliczenia (wygenerowanie zapisów księgowych na kontach planu kont na podstawie przypisanych szablonów dekretacji). |
|
Moduł musi umożliwiać drukowanie duplikatu dokumentu do pliku PDF i wysyłanie ich przez ESP (Elektroniczną Skrzynkę Podawczą) za pośrednictwem modułu integrującego i systemu EZD. |
|
Moduł musi umożliwiać definiowanie na jakim etapie ściągalności/ windykacji jest należność. |
|
Moduł musi umożliwiać wprowadzanie wysokości różnych odsetek np. ustawowe, ustawowe za opóźnienie, podatkowe |
|
Moduł musi generować raporty o zadanych przez Zamawiającego konfiguracjach na podstawie parametrów dostępnych w module, np. raport zaległości w dniach, raport terminów wpłat, raport przekazania dokumentów do windykacji itp. |
|
Moduł musi pozwalać na integrację z innymi modułami systemu. |
|
Moduł musi umożliwiać generowanie wirtualnych rachunków bankowych i być połączony z systemem bankowym i systemem FK w tym zakresie. |
Obsługa kasy – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł musi umożliwiać kompleksową obsługę zadań w zakresie prowadzenia kasy urzędu. |
|
Moduł musi w szerokim zakresie wykorzystywać możliwości środowiska systemu operacyjnego (przejrzyste wydruki graficzne, czytelnia forma prezentacji, rozbudowane metody selekcji danych, przyjazny interfejs.). |
|
Moduł musi umożliwiać przyjmowanie wpłat i wypłat na wybrane raporty kasowe, wydawanie dokumentów KP, KW, PO, BD. |
|
Moduł musi umożliwiać dwukierunkową współpracę z pozostałymi systemami rozliczającymi dochody budżetowe. |
|
Moduł musi umożliwiać generowanie raportów kasowych oraz okresowych zestawień z możliwością ich dowolnego filtrowania. |
|
Moduł musi posiadać obsługę kodów kreskowych/QR umieszczanych na wydrukach z systemów rozliczających dochody budżetowe (np. nakazy płatnicze w systemie podatkowym). |
|
Moduł musi pozwalać na identyfikację płatnika za pomocą czytnika kodów kreskowych. |
|
Moduł musi pozwalać na współpracę zarówno z tradycyjnymi drukarkami igłowymi jak i drukarkami atramentowymi czy laserowymi. |
|
Moduł musi dawać możliwość samodzielnego tworzenia i modyfikowania wzorów wydruków za pomocą wbudowanego edytora tekstu. |
|
Moduł musi pozwalać na integrację z innymi modułami systemu. |
Ewidencja majątku – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł musi pozwalać na szczegółową rejestrację, ewidencjonowanie posiadanego majątku w postaci: środków trwałych, wartości niematerialnych i prawnych oraz przedmiotów w użytkowaniu (małowartościowe składniki majątku). |
|
Moduł musi posiadać przejrzyste menu poprzez które można sprawnie wprowadzać nowe informacje. |
|
Moduł musi posiadać rozbudowany panel filtru pozwalający na szybkie wybranie danych z interesującego zakresu. |
|
Moduł musi upraszczać wszelkie operacje związane z tworzeniem oraz prowadzeniem ewidencji, eliminując żmudne prace związane z ręcznym sporządzaniem kartotek, zestawień i naliczaniem amortyzacji. |
|
Moduł musi pozwalać na przyjęcie środka trwałego do ewidencji z uwzględnieniem następujących danych: numer inwentarzowy, symbol, nazwa środka. Do każdej kartoteki powinna być przypisywana faktyczna lokalizacja oraz odpowiednia klasyfikacja środka trwałego z podziałem na grupy, podgrupy i rodzaje. |
|
Moduł musi pozwalać na wprowadzanie danych dotyczących stopy amortyzacji, wartości umorzenia, data i numer dowodu przyjęcia, rok produkcji lub oddania do eksploatacji, nazwisko osoby materialnie odpowiedzialnej, uwagi. |
|
Moduł musi pozwalać na ewidencjonowanie wszystkich zdarzeń związanych ze środkami trwałymi i tworzyć dla nich odpowiednie wydruki. Musi odbywać się to w oparciu o stosowne zapisy księgowe tj.: bilans otwarcia, odbiór techniczny, amortyzację miesięczną, modernizację, zmianę miejsca użytkowania, likwidację częściową lub całkowitą, co musi pozwalać na śledzenie wszystkich operacji od zakupu środka trwałego aż do jego likwidacji. |
|
Moduł musi pozwalać na automatyczne naliczanie na cały rok kwot amortyzacji miesięcznych w układzie liniowym. |
|
Moduł musi pozwalać na różne sposoby amortyzacji środków trwałych: liniową, degresywną, na określoną ilość rat, ręczną oraz zamortyzowanie środka trwałego jedną ratą zaraz po jego wprowadzeniu na stan. |
|
Moduł musi pozwalać na aktualizację danych z automatycznym uwzględnianiem wpływu tych zmian na naliczanie amortyzacji i umorzenia. |
|
Moduł musi pozwalać na przecenę (modernizacja lub likwidacja częściowa) środka trwałego, (zmiana wartości inwentarzowej i umorzenia) z aktualizacją zmian naliczeń amortyzacji i umorzenia. |
|
Moduł musi pozwalać na przeszacowanie wartości środków trwałych w wybranej grupie z możliwością przeszacowań przy różnych współczynnikach kolejnych przedziałów lat (w ciągu roku lub na początku roku). |
|
Moduł musi pozwalać na likwidację środka z przeniesieniem do kartoteki środków zlikwidowanych. |
|
Moduł musi pozwalać na zakończenie roku i naliczenie bilansu otwarcia na rok następny. |
|
Moduł musi pozwalać na automatyczne naniesienie na kartoteki dokumentów amortyzacji na cały rok ewidencyjny – wykonywane podczas operacji zamknięcia roku. |
|
Moduł musi umożliwiać prowadzenie ewidencji przedmiotów w użytkowaniu w sposób ilościowy lub ilościowo – wartościowy, dodatkowym atutem obsługi kartoteki przedmiotów w użytkowaniu musi być mechanizm cech, który musi pozwalać na powielanie już istniejących rekordów, co znacznie przyśpiesza wprowadzanie danych, uzyskiwanie na bieżąco dowolnej informacji o wybranym środku trwałym lub o grupie środków – wyświetlanie lub wydruk zestawień dla wybranych grup, działów lub obiektów np.: wykaz środków przyjętych, przekazanych pomiędzy działami lub skreślonych w danym okresie z ewidencji, zestawienie umorzeń i amortyzacji środków w danym okresie. |
|
Moduł musi umożliwiać generowanie wydruków np: karty środka trwałego, rejestru analitycznego, listy środków zlikwidowanych lub przyjętych do ewidencji w danym roku, arkusz spisu z natury, oświadczenia o odpowiedzialności materialnej, wydruk zestawienia rocznego dla wszystkich grup (wartości inwentarzowe, amortyzacja i umorzenia, zwiększenia, zmniejszenia itp), zapis aktualnego stanu ewidencji do archiwum. |
|
Moduł musi współpracować z czytnikiem kodów kreskowych i umożliwiać elektroniczną inwentaryzację. |
|
Moduł musi współpracować z modułem księgowym w zakresie automatycznego księgowania ruchów w ewidencji środków trwałych na kontach księgowych. |
|
Moduł musi współpracować z modułem programu geodezyjnego w zakresie pobierania danych dotyczących ruchu środków trwałych ewidencjonowanych w tym systemie (nieruchomości Skarbu Państwa, nieruchomości Skarbu Państwa w użytkowaniu wieczystym i trwałym zarządzie). Dane powinny być przekazywane w czasie rzeczywistym umożliwiając automatyczne wprowadzanie zmian w wartości i ewidencji nieruchomości. |
|
Moduł musi umożliwiać sporządzenie wydruków. |
Gospodarka materiałowo-magazynowa – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł musi umożliwiać prowadzenie ewidencji materiałów, towarów oraz druków ścisłego zarachowania z uwzględnieniem ewidencji druków i tablic rejestracyjnych w Wydziale Komunikacji. |
|
Moduł musi umożliwiać prowadzenie ewidencji wybraną metodą (ilościowo-wartościową lub ilościową) oraz obsługę inwentaryzacji. |
|
Moduł musi umożliwiać sporządzenie wydruków w szczególności:
|
|
Moduł umożliwia wprowadzenie wybranej przez użytkownika metody wyceny. |
|
Moduł musi być połączony z systemem FK w zakresie konta 330. |
|
Moduł musi umożliwiać sporządzenie JPK zgodnie z wytycznymi Ministerstwa Finansów. |
System kadrowo – płacowy wraz z portalem pracowniczym
Kadry – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł Kadrowy nie może podczas swojej pracy blokować pracę w module Płace. |
|
Moduł musi zapewnić widoczność wszystkich danych dla każdego z uprawnionych użytkowników modułu. |
|
Moduł musi umożliwiać definiowanie struktury jednostki z uwzględnieniem podziału kadrowego oraz podziału księgowego. |
|
Moduł musi zapewnić możliwość edytowania i zmiany zdefiniowanej struktury jednostki. |
|
Moduł musi w formie graficznej przedstawiać strukturę jednostki w formie drzewa. |
|
Moduł musi umożliwiać odnotowanie pełnej i skróconej nazwy płatnika. |
|
Moduł musi umożliwiać odnotowanie adresu płatnika, informacji o nr NIP, nr REGON, kontach bankowych. |
|
Moduł musi posiadać możliwość definiowania formatu numerowania pism z wykorzystaniem jednolitego rzeczowego wykazu akt. |
|
Moduł musi umożliwiać ustawianie domyślnego kalendarza. |
|
Moduł musi umożliwiać odnotowanie danych osoby reprezentującej jednostkę. |
|
Moduł musi domyślnie wyświetlać dane aktualne, zawarte w bieżącym czasookresie. |
|
Moduł musi umożliwiać ewidencjonowanie danych osobowych pracownika. |
|
Moduł musi sprawdzać poprawność naniesionego Nr PESEL. |
|
Moduł musi sprawdzać czy nanoszony nr PESEL już występuje w bazie danych. Jeśli nastąpi powtórzenie nr PESEL system powinien o tym poinformować. |
|
Moduł musi zapewnić możliwość wprowadzenia oraz edycję danych osobowych takich jak:
|
|
Moduł musi zapewnić możliwość wprowadzenia oraz edycję danych adresowych takich jak:
|
|
Moduł musi zapewnić możliwość wprowadzenia oraz edycję danych o członkach rodziny takich jak:
|
|
Moduł musi zapewnić możliwość wprowadzenia oraz edycję informacji o przynależnościach do organizacjach związkowych. |
|
Moduł musi zapewnić możliwość wprowadzenia oraz edycję danych osoby, którą należy powiadomić w razie wypadku. |
|
Moduł musi zapewnić możliwość wprowadzenia oraz edycję danych o stosunku do służby wojskowej. |
|
Moduł musi zapewnić możliwość wprowadzenia oraz edycję danych dotyczących ukończonych szkół, a w szczególności takich jak:
|
|
Moduł musi zapewnić możliwość wprowadzenia oraz edycję danych związanych z poprzednim zatrudnieniem, a w szczególności takich jak:
|
|
Moduł musi wyświetlić na podstawie wprowadzonych poprzednich okresów zatrudnienia wyliczoną informację ile trwało to zatrudnienie w latach, miesiącach i dniach z uwzględnieniem przerw związanych z udzielonym urlopem bezpłatnym. |
|
Moduł musi zapewnić możliwość wprowadzenia oraz edycję informacji o odbytych szkoleniach. |
|
Moduł musi zapewnić możliwość wprowadzenia oraz edycję informacji o nabytych kwalifikacjach. |
|
Moduł musi zapewnić możliwość wprowadzenia oraz edycję informacji o znajomości języków obcych z wyszczególnieniem nazwy języka wraz z określeniem poziomu posługiwania się nim w zakresie: w mowie, w piśmie i czytaniu. |
|
Moduł musi pozwolić na wykorzystanie wprowadzonych danych osobowych przy ponownym zatrudnieniu danego pracownika. |
|
Moduł musi dać możliwość wprowadzenia numeru ewidencyjnego pracownika. |
|
Moduł musi umożliwiać ewidencjonowanie umów o pracę, aneksów, angaży, a w szczególności musi umożliwiać gromadzenie danych takich jak:
|
|
Moduł musi zawierać panel informacyjny, na którym będzie widoczna informacja na temat poprzedniego zatrudnienia raz z bieżącym zatrudnieniem w postaci:
|
|
Moduł musi zapewnić możliwość prowadzenia dowolnych kalendarzy w zakresie danych:
|
|
Tworzenie nowego miesiąca dla kalendarza musi odbywać się na podstawie uprzednio zdefiniowanych domyślnych godzin pracy urzędu lub dowolnego miejsca pracy. |
|
Na podstawie kalendarzy oraz słownika kodów nieobecności musi być tworzony szczegółowy wykaz czasu pracy dla pracownika. |
|
Kalendarze muszą mieć postać graficzną, z wyszczególnieniem absencji w postaci określonego koloru. |
|
Moduł musi zawierać automat przypisujący cechy kalendarza pracownikom lub grupom pracowników. |
|
Moduł musi umożliwiać prowadzenie ewidencji wszystkich rodzajów nieobecności w pracy w zakresie danych:
|
|
Moduł musi posiadać skróty klawiszowe służące do szybkiego nanoszenia nieobecności. |
|
Moduł musi posiadać możliwość naniesienia całego okresu absencji podczas jednego działania użytkownika. |
|
Moduł musi umożliwiać edycję oraz usuniecie naniesionych informacji dotyczących absencji pracownika. |
|
Moduł musi umożliwiać naniesienie wyjść prywatnych pracownika w notacji godzinowej oraz minutowej. |
|
Moduł musi umożliwiać odnotowanie odpracowania wyjścia prywatnego. |
|
Moduł musi umożliwiać odnotowanie godzin nadliczbowych pracownika. |
|
Moduł musi umożliwić zaczytanie wyeksportowanych elektronicznych zwolnień z Platformy Usług Elektronicznych (PUE) min. w formacie pliku .csv |
|
Moduł musi umożliwiać rejestrację oraz ewidencję wraz z kontrolą następujących urlopów w zakresie danych:
|
|
Moduł musi umożliwiać ewidencję następujących urlopów:
|
|
Moduł musi umożliwiać ewidencjonowanie bieżącego i zaległego urlopu wypoczynkowego. |
|
Moduł musi umożliwiać definicję innego typu urlopu. |
|
Moduł musi umożliwiać prowadzenie planu urlopowego. |
|
Musi być możliwość drukowania pustych i wypełnionych formularzy z planowanym urlopem wypoczynkowym. Dodatkowo musi być możliwość śledzenia:
|
|
Moduł musi umożliwiać rejestrację badań lekarskich w zakresie danych:
|
|
Moduł musi umożliwiać rejestrację szkoleń w zakresie danych:
|
|
Moduł musi umożliwiać rejestrację ryczałtów samochodowych, w zakresie danych:
|
|
Moduł musi umożliwiać na podstawie danych o ryczałcie samochodowym wygenerowanie rachunku ryczałtu samochodowego. |
|
Moduł musi umożliwiać rejestrację kar w zakresie danych:
|
|
Moduł musi umożliwiać rejestrację dodatkowych informacji na temat pracownika w formie dowolnych notatek. |
|
Moduł musi umożliwiać rejestrację szkoleń BHP w zakresie danych:
|
|
Moduł musi umożliwiać rejestrację orzeczeń o niepełnosprawności w zakresie danych:
|
|
Moduł musi umożliwiać wydruk kwestionariusza osobowego. |
|
Moduł musi umożliwiać wydruk angażu. |
|
Moduł musi umożliwiać wydruk skierowania na badania lekarskie. |
|
Moduł musi umożliwiać wydruk świadectwa pracy. |
|
Moduł musi umożliwiać wydruk listy obecności pracownika lub pracowników. |
|
Moduł musi umożliwiać wydruk ewidencji czasu pracy w układzie rocznym lub miesięcznym. |
|
Moduł musi umożliwiać tworzenie raportu stanu urlopów na dowolny dzień i z różnych kryteriów wyszukiwania. |
|
Moduł musi umożliwiać wydruk zestawień. |
|
Moduł musi umożliwiać sporządzenie i wydruk obowiązujących sprawozdań do GUS. |
|
Moduł musi umożliwiać sporządzenie i wydruk obowiązujących sprawozdań do PFRON. |
|
Moduł musi umożliwiać dowolne wyszukanie i zestawienie danych zgromadzonych w zapisach bazy danych w formie wydruku. |
|
Moduł musi umożliwiać współpracę z rejestratorami czasu pracy i szczegółowe rozliczanie czasu pracy zatrudnionych na podstawie zdarzeń z rejestratora czasu pracy. |
|
Moduł musi zawierać wszystkie informacje dotyczące kolejnych umów o pracę i aneksów do umowy oraz informację o składnikach wynagrodzenia z uwzględnieniem czasookresów, za który dany składnik przynależy. |
|
Moduł musi zawierać kreator definiowania przez użytkownika dowolnego nowego raportu. Utworzone przez użytkownika nowe szablony dokumentów muszą być poszeregowane według kategorii charakterystycznych dla działu kadr. Użytkownik musi mieć możliwość zakładania swoich kategorii podziału szablonów. Założenie nowego szablonu musi sprowadzać się do:
|
|
Moduł musi posiadać aktówkę pracownika w której umieszczane muszą być wszystkie dokumenty elektroniczne dotyczące pracownika. Dokumenty te muszą być generowane w oparciu o szablony dokumentów. Musi być możliwość pobrania obrazu bezpośrednio ze skanera, np. badania lekarskie, które dostarczył pracownik lub dołączyć dokument znajdujący się na dysku komputera. |
|
Moduł musi umożliwiać generowanie dokumentów ZUS w formacie kompatybilnym z programem PŁATNIK. Dostępne muszą być następujące formularze:
|
|
Moduł musi umożliwiać automatyczne przenoszenie na powyższe formularze danych płatnika składek i osoby ubezpieczanej, tak aby maksymalnie uprościć wprowadzanie danych. |
|
Moduł musi zawierać możliwość prowadzenia ewidencji okresowego rozliczania wydawanych pracownikom środków ochrony indywidualnej (odzież ochronna i robocza ) wraz z możliwością wykonania imiennego zestawienia wydanych środków ochrony indywidulanej. |
|
Moduł musi zawierać możliwość stworzenia zestawienia zapotrzebowania środków ochrony indywidualnej. |
|
Moduł musi umożliwiać ewidencjonowanie okresowej oceny pracowników. |
|
Moduł przy uruchomieniu powinien automatycznie wyszukać pracowników którym:
|
Płace – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł Płace nie może podczas swojej pracy blokować pracę w module Kadry. |
|
Moduł musi zapewnić widoczność wszystkich danych dla każdego z uprawnionych użytkowników modułu. |
|
Moduł musi posiadać gotowe składniki płacowe podzielone na grupy tematyczne: płaca brutto, składniki dodatkowe, socjalne, przerwy w pracy, potrącenia dobrowolne. |
|
Moduł musi posiadać możliwość naliczania różnych sposobów wynagradzania takich jak:
|
|
Moduł musi posiadać możliwość zdefiniowania dowolnego systemu wynagrodzeń oraz możliwość jego modyfikacji indywidualnie przez przeszkolonego administratora systemu. |
|
Moduł musi posiadać możliwość tworzenia wielu rodzajów list płac w dowolnych okresach rozliczeniowych. |
|
Moduł musi posiadać możliwość grupowania pracowników według dowolnych kryteriów. Moduł musi posiadać możliwość uwzględniania różnych sposobów wynagradzania takich jak:
|
|
Moduł musi posiadać możliwość tworzenia wielu rodzajów list płac takich jak:
|
|
Moduł musi posiadać możliwość zbiorczego wprowadzania składników płacowych dla wybranych pracowników takich jak: • Diety,
|
|
Moduł musi posiadać możliwość zadeklarowania automatycznych dodatkowych wypłat między innymi takich jak: wypłaty diet, ryczałtów, wynagrodzeń za posiedzenia komisji. |
|
Moduł musi posiadać możliwość konfiguracji parametrów płacowych określających sposób wyliczania wynagrodzenia z uwzględnieniem regulaminu wynagradzania danej jednostki. |
|
Moduł musi posiadać możliwość zdefiniowania podstaw do wyliczenia wynagrodzeń za czas nieobecności pracownika. |
|
Moduł musi posiadać możliwość zdefiniowania podstaw do wyliczenia godzin nadliczbowych. |
|
Moduł musi posiadać możliwość zdefiniowania podstaw do wyliczenia dodatkowego wynagrodzenia rocznego. |
|
Moduł musi posiadać zestaw parametrów potrzebnych do wyliczeń wynagrodzeń i wypłat uzupełnianych w trakcie aktualizacji. |
|
Moduł powinien posiadać rejestr wprowadzonych parametrów. |
|
Moduł musi umożliwiać dowolną konfigurację pod względem praw dostępu użytkownikom systemu. Administrator systemu musi mieć możliwość określenia dokładnie i jednoznacznie zakresu danych oraz czynności do których jest upoważniony dany użytkownik. |
|
Moduł musi umożliwiać prowadzenie ewidencji potrąceń dobrowolnych. |
|
Moduł musi umożliwiać prowadzenie archiwum pracowników. |
|
Moduł musi umożliwiać automatyczne naliczanie płac. |
|
Moduł musi zawierać mechanizm automatycznego rozksięgowania listy płac na podstawie struktury klasyfikacji budżetowej prowadzonej przez jednostkę. Moduł musi zawierać mechanizm automatycznego przesłania rozksięgowanych list płac do systemu finansowo-księgowego. |
|
Moduł musi zawierać możliwość rozksięgowania list płac kluczem procentowym na zdefiniowane konta księgowe i konta klasyfikacji budżetowej |
|
Moduł musi zawierać możliwość księgowania wypłat umów zlecenia i o dzieło w trzech trybach:
|
|
Moduł musi zawierać możliwość wydruku polecenia księgowania. |
|
Moduł musi zawierać możliwość wydruku polecenia księgowania umów zleceń i o dzieło z dodatkową informacją dotyczącą szczegółów umowy oraz rachunku. |
|
Moduł musi automatycznie naliczać składki ZUS i podatek dochodowy od osób fizycznych. |
|
Moduł musi prawidłowo dokonać naliczeń wynagrodzenia w przypadku pracowników zatrudnionych więcej niż na jeden etat. |
|
Moduł musi zapewnić możliwość wypłat z ZFŚS z uwzględnieniem pomocy rzeczowej, pieniężnej, zapomóg raz pozostałych wypłat. |
|
Moduł musi umożliwić automatyczne sumowanie za cały miesiąc wypłat tak aby prawidłowo naliczyć
|
|
Moduł musi automatycznie kontrolować limit roczny dni zwolnienia chorobowego (14 dni dla osób po 50 roku życia, 33 dni dla pozostałych) i automatycznie naliczać zasiłek chorobowy po przekroczeniu limitu. |
|
Moduł musi automatycznie kontrolować roczny limit zwolnienia zasiłku opiekuńczego. |
|
Moduł musi automatycznie kontrolować roczny limit dni zwolnienia lekarskiego. |
|
Moduł musi generować raporty w formie list płac. |
|
Moduł musi mieć możliwość generowania i wydruk raportów wobec zadeklarowanych przez użytkowników kryteriów. |
|
Moduł musi mieć możliwość generowania i wydruk raportów imiennych. |
|
Moduł musi mieć możliwość generowania i wydruk raportów zbiorczych. |
|
Moduł musi mieć możliwość generowania i wydruk raportów z danych uśrednionych z zadeklarowanego okresu. |
|
Moduł musi mieć możliwość generowania i wydruk raportów sumujących z zadeklarowanego okresu. |
|
Moduł musi mieć możliwość generowania i wydruk zaświadczeń o wynagrodzeniach i zatrudnieniu. Moduł musi mieć możliwość generowania i wydruk karty wynagrodzeń. |
|
Moduł musi mieć możliwość generowania i wydruk karty zasiłkowej. |
|
Moduł musi mieć możliwość generowania i wydruk asygnatki zasiłkowej. |
|
Moduł musi mieć możliwość po wygenerowaniu dowolnego raportu jego zapis w formacie PDF. |
|
Moduł musi automatycznie kontrolować podstawę do wyliczenia składek emerytalnych i rentowych z uwzględnieniem obowiązującego w danym roku limitu. |
|
Moduł musi automatycznie zaprzestać naliczania składki emerytalnej i rentowej w przypadku gdy:
|
|
Moduł musi automatycznie kontrolować obowiązujące progi podatkowe. |
|
Moduł musi umożliwić zastosowanie zwiększonego progu podatkowego w przypadku złożenia przez pracownika oświadczenia. |
|
Moduł musi wygenerować i wydrukować dokument ZUS Z-3. |
|
Moduł musi wygenerować i wydrukować dokument, który może zastąpić wydruk rocznego dokumentu RMUA. |
|
Moduł musi automatycznie naliczać lub nie naliczać składkę na Fundusz Pracy według obowiązujących przepisów. |
|
Moduł musi automatycznie naliczać składkę na Fundusz Emerytur Pomostowych dla wybranych pracowników. |
|
Moduł musi automatycznie nadzorować wykorzystanie kwoty wolnej z ZFŚS. |
|
Moduł musi mieć możliwość poprowadzenia potrąceń komorniczych. |
|
Moduł musi mieć możliwość zmiany oraz usunięcia naniesionych wynagrodzeń dla wybranego pracownika. |
|
Moduł musi ewidencjonować co najmniej dwa stany listy płac:
|
|
Moduł musi zachować pełną funkcjonalność bez względu jaki status ma lista. W przypadku stanu listy ustawionej jako „zamknięta” moduł nie może ponownie przeliczyć, zmienić, zmodyfikować i usunąć danych z tej listy. |
|
Konfiguracja modułu musi zapewnić prawidłowe zastosowanie ulgi podatkowej oraz kosztów podczas wypłaty listy podstawowej. |
|
Moduł musi umożliwić poprowadzenie wypłat pracownika, który jest zatrudniony więcej niż w jednej komórce organizacyjnej. |
|
Moduł musi automatycznie naliczać wynagrodzenie za godziny nadliczbowe. |
|
Moduł musi automatycznie naliczać dodatkowe wynagrodzenie roczne z uwzględnieniem absencji takich jak:
|
|
Moduł podczas naliczania dodatkowego wynagrodzenia rocznego powinien mieć możliwość automatycznego wyboru osób, dla których to wynagrodzenie ma być naliczone. |
|
Moduł musi mieć możliwość generowania przelewu bankowego w postaci wydruku. |
|
Moduł musi mieć możliwość generowania przelewu bankowego w postaci pliku w formacie ELIXIR. |
|
Moduł musi mieć możliwość wykonania następujących przelewów:
|
|
Moduł musi umożliwiać prowadzenie dowolnej ilości kont bankowych jednostki. |
|
Moduł musi, w zależności od oświadczenia pracownika lub zleceniobiorcy mieć możliwość przekazania wypłat na rachunek oszczędnościowo-rozliczeniowy, kasę lub czek. |
|
Moduł musi zapewnić możliwość prowadzenia więcej niż jednego konta bankowego pracownika. |
|
Moduł musi zapewnić możliwość podziału wypłaty wynagrodzenia na rachunek bankowy i do kasy. |
|
Moduł musi zapewnić możliwość poprowadzenia wypłat związanych z realizacją projektów UE/FE. |
|
Moduł musi zapewnić możliwość wygenerowania i wydruku raportów związanych z realizacją projektów UE/FE. |
|
Moduł musi zapewnić możliwość poprawnego zaksięgowania w module Finansowo-Księgowym wypłat związanych z realizacją projektów UE/FE. |
|
Moduł musi umożliwić poprowadzenie każdego projektu UE/FE na oddzielnej liście płac. |
|
Moduł musi umożliwić wygenerowanie oraz wydruk dowolnego raportu z każdego projektu UE/FE oddzielnie. |
|
Moduł musi zapewnić:
|
|
Moduł musi mieć możliwość sporządzania list płac według podziału zadeklarowanego w strukturze organizacyjnej jednostki. Dodatkowy podział możliwy jest poprzez zarządzaniem grupami pracowników, które w dowolny sposób może zdefiniować użytkownik modułu. |
|
Moduł musi zapewnić automatyczne wyliczanie podstawy wynagrodzenia za czas choroby, zasiłku chorobowego i opiekuńczego. |
|
Moduł musi zapewnić automatyczne wyliczanie podstawy zasiłku macierzyńskiego. |
|
Moduł musi zapewnić automatyczne wyliczanie podstawy urlopu wychowawczego. |
|
Moduł musi zapewnić automatyczne wyliczanie podstawy zasiłku rehabilitacyjnego. |
|
Moduł musi automatycznie kontrolować trzymiesięczną przerwę pomiędzy zasiłkami tak aby prawidłowo naliczyć podstawę zasiłku. |
|
Moduł musi automatycznie kontrolować zmianę angażu oraz etatu przy naliczaniu zasiłku. |
|
Moduł musi automatycznie uzupełnić kwotę dodatkowego wynagrodzenia rocznego przy obliczeniu podstawy zasiłku. |
|
Moduł musi automatycznie uzupełnić podstawę zasiłku do wartości minimalnej. |
|
Moduł musi odpowiednio, według ustawionych parametrów podzielić na część składkową i nieskładkową następujące składniki płacowe:
|
|
Moduł musi zapewnić automatyczne generowanie dokumentów rozliczeniowych do programu Płatnik takich jak :
|
|
Moduł musi mieć możliwość skorygowania wypłaconych wynagrodzeń chorobowych oraz zasiłków. |
|
Moduł musi mieć możliwość skorygowania nadpłaconych składek emerytalnej i rentowej. |
|
Moduł musi mieć możliwość poprowadzenia umów cywilno-prawnych dla obcokrajowców przy zastosowaniu zryczałtowanego podatku 20 procentowego. |
|
Moduł musi mieć możliwość poprowadzenia umów cywilno-prawnych z kosztami autorskimi. |
|
Moduł musi mieć możliwość poprowadzenia umów cywilno-prawnych o wartości nieprzekraczającej 200 zł (podatek ryczałtowy). |
|
Moduł musi zapewnić swobodne definiowanie rodzajów umów cywilno-prawnych i parametrów ich naliczania. |
|
Moduł musi mieć możliwość wygenerowania i wydruku formularza umowy cywilno-prawnej. |
|
Moduł musi mieć możliwość wygenerowania i wydruku rachunku formularza umowy cywilno-prawnej. |
|
Moduł musi mieć możliwość wygenerowania i wydruku list wypłat umów cywilno-prawnych z podziałem według klasyfikacji budżetowej. |
|
W przypadku gdy pracownik ma umowę cywilno-prawną ze swoim pracodawcą system powinien uwzględnić ten stan w chwili naliczania składek na ubezpieczenia społeczne i ubezpieczenie zdrowotne. |
|
Moduł musi mieć możliwość wygenerowania, modyfikacji, podpisania elektronicznego oraz wysłania następujących deklaracji PIT:
|
|
Moduł musi mieć możliwość wyboru i zaznaczenia domyślnego numeru identyfikacyjnego wykorzystanego przy tworzeniu osobowych deklaracji PIT (NIP, PESEL). |
|
Moduł musi mieć zadeklarowane w słowniku wszystkie Urzędy Skarbowe w Polsce. Moduł musi mieć możliwość generowania i drukowania comiesięcznej informacji o naliczonym i przelanym podatku na poczet zaliczki wynikającej z deklaracji:
|
|
Moduł musi automatycznie tworzyć deklaracje PIT. |
|
Moduł musi mieć funkcję weryfikującą poprawność danych zawartych w deklaracjach PIT. |
|
Moduł musi umożliwiać tworzenie korekt deklaracji PIT. |
|
Moduł musi zapewnić prowadzenie umów cywilno-prawnych dotyczących pracowników oraz obcych osób fizycznych. |
|
Moduł musi mieć funkcję umożliwiającą poprowadzenie umów cywilno-prawnych, które będą wypłacane z częstotliwością kwartalna lub inną dowolną różniącą się od miesięcznej. |
|
Moduł powinien dla zgłoszonych do składek ZUS umów cywilno-prawnych, dla których w bieżącym miesiącu nie było wypłat wygenerować odpowiednią zerową deklaracją RCA lub RZA. |
|
Moduł musi w pełni zapewnić możliwość prowadzenia wypłat diet dla radnych. |
|
Moduł musi być konfigurowalny w zakresie naliczenia diet w przypadku absencji radnego według obowiązującego regulaminu. |
|
Moduł musi poprawnie nadzorować kwotę wolną przypisaną do działalności radnych. |
|
Moduł musi zapewnić poprawne poprowadzenie wypłat dla osób, które są jednocześnie członkami wielu komisji. |
|
Moduł powinien umożliwić poprowadzenie wypłat świadczenia integracyjnego. |
|
Moduł powinien umożliwić poprowadzenie wypłat dla pracowników robót publicznych i interwencyjnych. |
|
Moduł powinien umożliwić poprowadzenie wypłat stypendium stażowego. |
|
Moduł powinien umożliwić poprowadzenie wypłat stypendium szkolnego. |
|
Moduł powinien umożliwić poprowadzenie wypłat stypendium szkoleniowego. |
|
Moduł powinien umożliwić poprowadzenie wypłat świadczenia osobistego na rzecz obrony. |
|
Moduł powinien umożliwić przyznanie zaliczki na poczet poborów. |
|
Moduł powinien umożliwić poprowadzenie dowolnej ilości podmiotów o charakterze KZP w zakresie:
|
|
Moduł powinien umożliwić poprowadzenie pożyczek udzielanych w ramach ZFŚS w zakresie:
|
Portal pracowniczy – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Portal intranetowy przeznaczony jest dla użytkowników wewnętrznych systemu – pracowników oraz kadry kierowniczej. |
|
Funkcjonalności portalu intranetowego muszą być dostępne wyłącznie dla zalogowanych użytkowników wewnętrznych portalu. |
|
W obrębie Portalu Intranetowego musi być wydzielona dedykowana strefa, panel pracownika z poziomu której będą dostępne spersonalizowane informacje kadrowo-płacowe zalogowanego pracownika. |
|
Portal Intranetowy musi pozwalać kadrze kierowniczej na podgląd danych swoich podwładnych zgodnie z określonymi uprawnieniami kompetencyjnymi wynikającymi z struktury organizacyjnej jednostki. |
|
Panel pracownika powinien być podzielony według następujących tematów:
|
|
Panel kierownika powinien dodatkowo zawierać listę podległych pracowników. |
|
Osoba o przypisanej roli kierownika powinna mieć informację o wymiarze urlopu podległych pracowników. Pozostałe dane pracowników powinny być niedostępne. |
|
W panelu kierownika powinien znajdować się rejestr wniosków urlopowych z podziałem według odpowiednio wybranego kryterium:
|
|
W panelu kierownika musi być funkcjonalność pozwalająca na pracę z wnioskami urlopowymi, taka jak:
|
|
Portal pracowniczy w zakresie danych pracownika powinien zawierać informacje:
Moduł musi wyświetlić na podstawie wprowadzonych poprzednich okresów zatrudnienia informację ile trwało to zatrudnienie w latach, miesiącach i dniach z uwzględnieniem przerw związanych z:
|
|
Portal pracowniczy w zakresie informacji o zatrudnieniu powinien zawierać:
|
|
Element wynagrodzenia powinien zawierać: Wynagrodzenia: informacja o zrealizowanych listach płac wraz z wykazem analitycznym składników płacowych, informacji o naliczonych składkach społecznych i zdrowotnych, naliczonym podatku, zastosowanych kosztach uzyskania przychodu oraz kwoty wolnej, zastosowanych potrąceniach od netto, naliczonym wynagrodzeniu chorobowym oraz wypłat zasiłków, informacja o wynagrodzeniach powinna zostać wyświetlona z uwzględnieniem okresu miesięcznego oraz rocznego, w którym została wypłacona, pracownik powinien mieć możliwość wygenerowania na podstawie wybranej listy płac wydruku w formie paska wynagrodzeń w formacie PDF. Świadczenia socjalne: informacja analityczna o przyznanych świadczeniach socjalnych. Informacja PIT: wykaz deklaracji PIT sporządzonych i wysłanych do Urzędu Skarbowego, pracownik powinien mieć możliwość przeglądnąć wybraną deklarację oraz ją wydrukować. |
|
Element: karta zadłużeń powinien zawierać wykaz systemów pożyczkowych (KZP, ZFŚS), do których przystąpił pracownik wraz z wykazem zadłużeń, stanu wkładów członkowskich, potrącanych składek oraz potrącanej spłaty na rzecz zadłużenia. |
|
Element czas pracy powinien zawierać:
|
|
Moduł powinien pracować na aktualnych danych kadrowo-płacowych. W celu uniknięcia wyświetlenia mylnych informacji, danych które są w edycji, modyfikacji, symulacji wynagrodzeń wyświetlenie powinno nastąpić w przypadku:
|
|
Pracownicy jednostki powinni mieć możliwość podglądu x.xx. wykorzystanego i planowanego urlopu, odbytych szkoleń. |
System obsługi nieruchomości – ewidencja mienia komunalnego
Mienie komunalne – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
System powinien umożliwiać prowadzenie rejestru działek będących we władaniu Powiatu |
|
System powinien posiadać możliwości wyszukiwania i selekcji gruntów według dowolnego kryterium. |
|
System powinien umożliwiać prowadzenie rejestru dzierżawców, użytkowników wieczystych z szybkim ich wyszukiwaniem i kontrolą terminowości naliczania opłat w powiązaniu z rejestrem działek. |
|
System powinien umożliwić śledzenie historii działki od momentu wprowadzenia do ewidencji (informacje dotyczące sposobu nabycia, podziału, zbycia, zabudowy, dzierżawców, toczących się postępowań itp.). |
|
System powinien umożliwić prowadzenie ewidencji budynków i lokali (zabudowa działek). |
|
System powinien umożliwiać sporządzanie wydruku dokumentów typu: umów dzierżawnych, pism, korespondencja z dzierżawcami itp. |
|
System musi umożliwiać naliczanie opłat z tytułu dzierżawy oraz wieczystego użytkowania gruntów i/lub nieruchomości, według odpowiednich algorytmów. |
|
System musi umożliwiać wystawianie faktur VAT i rachunków za czynsze dzierżawne wraz z dodatkowymi opłatami (media itp.). |
|
System powinien posiadać rozbudowany system tworzenia własnych zestawień i raportów. |
|
System powinien umożliwiać wizualizację ewidencjonowanych działek na mapie min. w formacie , prezentowane dane powinny zawierać:
|
Szyna usług integrująca usługi e_PUAP, EZD i systemy dziedzinowe wraz z brokerem integracyjnym
Integracja – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł musi posiadać ustandaryzowane interfejsy zewnętrzne, obejmujące udostępnianie usług integracyjnych (x.xx. wymiany danych), systemom zewnętrznym poprzez: usługi Web Services (w oparciu o standardy SOAP 1.2, WSDL co najmniej 1.1); możliwość komunikacji z wykorzystaniem plików XML zlokalizowanych w strukturach plikowych jednostki, JMS, zgodność ze standardami XML 1.0 i XSD 1.1. |
|
Komunikacja z systemem EZD odbywać się ma za pośrednictwem usług web service. |
|
Moduł musi zapewniać integrację modułów dziedzinowych systemów informatycznych z systemem Elektronicznego Zarządzania Dokumentami. Musi być możliwość automatycznego przekazywania dokumentów tworzonych w tych modułach wraz z automatycznym dodawaniem ich do teczek spraw bezpośrednio w systemie EZD . |
|
Moduł musi zapewniać integrację systemu EZD z systemem finansowo-księgowym. Musi być możliwość przekazywania do systemu FK danych w zakresie niezbędnych do jego zaksięgowania wynikających z wpływających dokumentów finansowych na dziennik podawczy (np. faktury, umowy itp.). |
|
Moduł musi pozwalać na integrację z systemem kadrowym na poziomie obsługi wniosków urlopowych. W e-formularzu (wniosek urlopowy) systemu EZD muszą być wyświetlane dane o wykorzystanych dniach urlopowych dla użytkownika systemu EZD wnioskującego o urlop. |
|
Moduł musi zapewniać synchronizacje kartotek kontrahentów na poziomie modułów dziedzinowych i systemu EZD zapewniając dwukierunkową wymianę metadanych dokumentów przysyłanych z platformy ePUAP. |
|
Moduł musi zapewniać automatyzację następujących procesów:
|
|
Moduł musi umożliwić publikację dowolnych dokumentów na stronie podmiotowej BIP oraz musi umożliwić informowanie o statusie sprawy na stronie podmiotowej BIP (opcjonalnie w SSDIP xxxx://xxxxx.xxx.xxx.xx). |
|
Moduł musi udostępniać metody komunikacyjne niezbędne do funkcjonowania portalu w zakresie udostępnienia odpowiednich danych zapewniając ich wizualizację po stronie www, możliwość dokonania zapłaty za pośrednictwem systemu płatności elektronicznych oraz dostarczania odpowiednich komunikatów do interesantów. |
|
Moduł musi posiadać mechanizm kontroli dostępu do usług pozwalający na dostęp do danej usługi ze względu na użytkownika oraz grupę (jednostkę organizacyjną) do której należy. |
|
Moduł musi umożliwiać administratorom tworzenie nowych oraz zarządzanie udostępnianymi usługami i interfejsami (w tym harmonogramem komunikacji, lokalizacją plików, uprawnieniami do nich) poprzez przyjazny interfejs. Moduł musi umożliwiać wdrażanie nowych interfejsów poprzez import konfiguracji, określającej standardy komunikacji z danym systemem, oraz serię kroków wykonywanych poprzez graficzny interfejs. |
|
Dla danych pozyskiwanych z systemu zewnętrznego moduł musi umożliwiać administratorowi skonfigurowanie transformat oraz automatycznego przesyłania uzyskanych danych jako jednego lub wielu dokumentów do użytkownika lub użytkowników. |
Komunikacja – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł ma zapewnić możliwość przesyłania spersonalizowanych komunikatów do petentów urzędu generowanych na podstawie zdarzeń występujących w systemach dziedzinowych oraz komunikatów wprowadzonych „ręcznie” przez administratora systemu. |
|
System powinien posiadać jedną wspólna kartotekę komunikatów zawierającą informację o treści komunikatu, źródło jego pochodzenia, dacie zapisania do rejestru, identyfikację odbiorcy, datę i godzinę wysłania, datę ważności komunikatu oraz identyfikację kanału którym został on przesłany. |
|
Administrowanie i zarządzanie kontami użytkowników odbywać się będzie z poziomu panelu administratora portalu płatniczego. Jedno konto dla użytkownika z możliwością wyboru przez niego z jakiego zakresu usług będzie korzystał. |
|
Administrator systemu musi mieć dostępny edytor wzorów treści dla określonych typów komunikatów oraz wybranego kanału dystrybucji. |
|
W systemie powinny być dostępne kanały komunikacyjne za pośrednictwem SMS-a, e-maila oraz komunikatu push aplikacji mobilnych. |
|
Wysyłanie komunikatów powinno być wykonywane wg. kryteriów (kalandarzy) określonych przez administratora dla każdego kanału oddzielnie. |
|
System powinien współpracować z modułami dziedzinowymi w zakresie powiadamia co najmniej o:
Dokonanie księgowania na koncie podatnika (zaksięgowanie wpłaty, przeksięgowanie nadpłat, dokonanie przypisu lub odpisu należności, wystawienie upomnienia). |
|
Przesyłanie powiadomień wybranym przez użytkownika kanałem z uwzględnieniem wybranej przez niego tematyki i terminarza odbywa się automatycznie. |
|
System musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji. |
Aplikacja mobilna zintegrowana z platformą usług publicznych
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Aplikacja mobilna powinna być dostępna w wersjach na popularne systemy operacyjne stosowane dla urządzeń mobilnych (min.: Android, , iOS) |
|
Aplikacja powinna być podzielona na strefę ogólnodostępną oraz strefę użytkownika zalogowanego. |
|
Konto użytkownika zalogowanego powinno być wspólne z kontem na platformie/systemie ePłatności (portal płatniczy). Logowanie musi odbywać się za pośrednictwem tego samego loginu i hasła lub profilu zaufanego (xxxxx://xx.xxx.xx). |
|
Pierwsza rejestracja konta użytkownika oraz jego konfiguracja dokonywana będzie na platformie ePłatności. Z poziomu aplikacji mobilnej dla zalogowanego użytkownika dostępne będzie dezaktywacja konta. |
|
Zalogowany użytkownik musi posiadać dostęp do danych z systemów dziedzinowych zgodnie z zakresem wymaganym dla portalu ePłatności z możliwością dokonywania zapłat za pośrednictwem systemu płatnościowego. |
|
Aplikacja musi umożliwić prezentację załączników (dokumentów z systemów dziedzinowych) z wykorzystaniem formatu PDF. |
|
Konto użytkownika powinno mieć możliwość integracji z Facebook, Google+. |
|
Ekran powitalny („O nas”) wizualizować ma dane pobierane z serwera a administrator powinien mieć możliwość aktualizowania i konfigurowania tych danych. |
|
Aplikacja powinna mieć obsługę „Aktualności” dynamicznie pobieranych z list aktualności zarządzanych przez administratora. Obsługa aktualności z poziomu administratora musi umożliwiać zamieszczanie w niej plików graficznych oraz prosty edytor treści. Administrator może dodawać i usuwać wpisy do listy oraz określać typy „Aktualności” a użytkownik może je potem sortować i wybierać według zadanego kryterium. |
|
Aplikacja powinna zapewnić obsługę „Miejsc” dynamicznie pobieranych z listy zarządzanej przez administratora. Obsługa „Miejsc” z poziomu administratora musi umożliwiać zamieszczanie w niej plików graficznych, prosty edytor treści, oraz określenie położenia na mapie – gogle maps. Administrator może dodawać i usuwać wpisy do listy oraz określać typy „Miejsc” a użytkownik może je potem sortować i wybierać według zadanego kryterium. |
|
Aplikacja powinna zawierać obsługę i wizualizację „Galerii” z podziałem na kategorie. Galeria jest dostępna dla użytkowników niezalogowanych. |
|
Aplikacja mobilna musi otrzymywać powiadomienia z systemów dziedzinowych zgodnie z ustawieniami w module e-Płatności i kontem zalogowanego użytkownika. Powiadomienia będą spersonalizowane i wysyłane do konkretnych użytkowników zarejestrowanych w systemie. Zalogowany użytkownik powinien mieć możliwość włączenia lub wyłączenia wybranego typu powiadomienia oraz określenie metody jego dostarczania. |
|
Aplikacja musi umożliwić automatyczne wysłanie e-maili do Powiatu. System musi umożliwić wybranie tematu wiadomości i automatycznie skieruje ją do osoby odpowiedzialnej za dane zadanie. |
|
Aplikacje mobilne na poszczególne sytemy operacyjne powinny być udostępnione na powszechnie dostępnych serwisach do ich pobierania. |
Scentralizowany system służący do planowania i realizacji budżetu w trybie zadaniowym dla wszystkich jednostek
Planowanie – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł do planowania budżetu powinien być dostępny niezależnie od posiadanych systemów finansowo-księgowych w poszczególnych jednostkach, jednocześnie powinien być połączony z systemem finansowo – księgowym jednostki nadrzędnej. |
|
Moduł do planowania budżetu powinien być dostępny poprzez przeglądarkę internetową. |
|
Moduł do planowania budżetu powinien umożliwiać projektowanie budżetu w układzie:
|
|
W systemie powinno być możliwe wprowadzenie limitów środków rzeczowych, limitów na etaty, wyliczenie kosztu roboczogodziny w danej komórce, tworzenie bieżących wydatków, tworzenie wersji zadań bezpośrednich, tworzenie zadań inwestycyjnych, tworzenie zadań dochodowych, tworzenie zadań wydziałowych, wprowadzenie planu przychodów i wydatków funduszy celowych. |
|
Planowanie powinno być podzielone na prognozę i na projekt budżetu, który następnie będzie weryfikowany przez służby Skarbnika. |
|
Podczas planowania powinna być możliwość wprowadzenia szczegółowych danych kalkulacyjnych w obrębie paragrafu. |
|
Wszystkie dokumenty generowane przez system muszą być eksportowane do innych plików min.: doc, xls z możliwością ich edycji. |
|
Moduł powinien mieć możliwość ustawienia statusu dostępu w zależności od nadania uprawnień. |
|
Moduł powinien umożliwiać opracowanie projektu budżetu i możliwości eksportu budżetu i wszystkich załączników do systemu BeSti@ i do Legislatora. Powinien również zawierać możliwość przygotowania projektu uchwały budżetowej, jak również różnych innych wydruków (załączników do budżetu) według wzorów wprowadzonych przez jednostkę. |
|
Moduł powinien współpracować z innymi systemami w zakresie przesyłania danych, jeżeli będzie możliwość to przesyłanie danych z innych systemów powinno być zautomatyzowane, w innym przypadku za pomocą pliku xml. |
|
Przygotowanie budżetu powinno opierać się o słowniki wydatków podpięte pod odpowiednie paragrafy klasyfikacji budżetowej. W przypadku zmiany rozporządzenia dotyczącego klasyfikacji budżetowej system powinien automatycznie uaktualniać słowniki. |
|
Moduł powinien umożliwiać wprowadzanie zmian w budżecie z opcją włączenia jednostek organizacyjnych oraz pracowników merytorycznych w proces wnioskowania o zmianę istotnych parametrów zadania. Wnioski powinny być składane w module i automatycznie zaczytywane do projektu budżetu. |
|
Moduł powinien ewidencjonować wszystkie dokumenty wpływające na zmiany w budżecie. |
|
Prezentacja danych powinna być możliwa w dowolnym układzie, np. układ budżetu, układ wykonawczy, układ Zwiększenia – Zmniejszenia, układ per saldo, budżet Organu w układzie z jednostkami, z rodzajami zadań: własne zlecone, porozumienia, w podziale na grupy paragrafów np. dochody bieżące i majątkowe, układ wg źródeł dochodów oraz źródeł finansowania po wydatkach, przesunięcia na zadaniach inwestycyjnych, zmiany nakładów i finansowania na WPI. |
|
Moduł, po każdej zmianie w budżecie, powinien utworzyć układ wykonawczy dla każdej z jednostek (wydziału) oraz plik w formie elektronicznej w celu rozdysponowania ich do jednostek organizacyjnych ( z podpisem kwalifikowanym). |
|
Moduł powinien być połączony z modułem budżetowym i na bieżąco powinien aktualizować dane dotyczące planu budżetu. |
|
Moduł powinien mieć rozbudowany i elastyczny system słowników, możliwość dowolnego grupowania zadań i paragrafów oraz definiowanie wyglądu wydruku za pomocą zewnętrznych formatek, umożliwiać samodzielne określanie zawartości i postaci wydruków, załączników do uchwał i zarządzeń. |
|
Moduł powinien umożliwiać wyodrębnienie powiatowej części budżetu oraz każdej jednostki budżetowej. |
|
Wieloletnia prognoza finansowa. |
|
Moduł do planowania WPF powinien być dostępny poprzez przeglądarkę internetową. |
|
Moduł do planowania WPF powinien umożliwiać projektowanie WPF w układzie narzuconym przez ustawodawcę. |
|
Dane nanoszone na etapie planowania i zmian budżetu powinny zaczytywać automatycznie do WPF. |
|
Użytkownik powinien mieć możliwość zdefiniowania własnych wskaźników makroekonomicznych dotyczących prognoz dochodów i wydatków oraz własnych słowników na postawie których będzie wprowadzał dane. |
|
Moduł powinien być skonstruowany w taki sposób, aby wprowadzane dane były automatycznie przeliczane i przenoszone do innych pozycji WPF oraz, aby wszystkie wskaźniki były wyliczane automatycznie. |
|
Moduł powinien być skonstruowany w taki sposób, aby wprowadzane dane były automatycznie przeliczane i przenoszone do innych pozycji WPF oraz, aby wszystkie wskaźniki były wyliczane automatycznie. |
|
Moduł powinien umożliwiać kontrolę wprowadzonych danych oraz sygnalizować przekroczenie wymaganych wskaźników. |
|
W module powinno planować się przedsięwzięcia wieloletnie z ich wyszczególnieniem. |
|
Moduł musi być elastyczny, musi umożliwiać samodzielne kreowanie modeli, projekcje prognoz, parametryzację doboru danych, wykorzystanie metod prognostycznych oraz sposobów agregowania szeregów czasowych. |
|
Moduł powinien umożliwiać tworzenie załącznika przedsięwzięć wieloletnich w oparciu o centralny słownik zadań z opcją włączenia jednostek organizacyjnych oraz pracowników merytorycznych w proces wnioskowania o zmianę istotnych parametrów zadania. Wnioski powinny być składane w module. |
|
W module powinna być możliwość stworzenia kilku wariantów/scenariuszy WPF. System powinien automatycznie przenosić dane pomiędzy scenariuszami i umożliwiać automatyczną korektę danych poprzez wprowadzanie wskaźników procentowych lub korektę danych wprowadzoną ręcznie. |
|
W module musi być możliwość nadawania uprawnień użytkownikom. |
|
Moduł powinien umożliwiać generowanie wszystkich niezbędnych załączników i dokumentów tj. uchwały, załącznik WPF, załącznik przedsięwzięć, wnioski o zmianę nakładów, limitów czy źródeł finansowania przedsięwzięcia. |
|
Wszystkie dokumenty generowane przez moduł muszą być eksportowane do innych plików nin.: doc., xls z możliwością ich edycji. |
|
Moduł powinien współpracować z pozostałymi modułami programu finansowo-księgowego i budżetowego oraz programem BeSTi@ w zakresie pobierania i przesyłania danych. |
Prognoza finansowa – wymagania minimalne:
Lp. |
Opis minimalnych wymagań dla oprogramowania |
|
Moduł do planowania WPF (Wieloletnia Prognoza Finansowa) powinien być dostępny poprzez przeglądarkę internetową. |
|
Moduł do planowania WPF powinien umożliwiać projektowanie WPF w układzie narzuconym przez ustawodawcę. |
|
Dane nanoszone na etapie planowania i zmian budżetu powinny być zaczytywane automatycznie do WPF. |
|
Użytkownik powinien mieć możliwość zdefiniowania własnych wskaźników makroekonomicznych dotyczących prognoz dochodów i wydatków oraz własnych słowników na postawie których będzie wprowadzał dane. |
|
Moduł powinien być skonstruowany w taki sposób, aby wprowadzane dane były automatycznie przeliczane i przenoszone do innych pozycji WPF oraz, aby wszystkie wskaźniki były wyliczane automatycznie. |
|
Moduł powinien umożliwiać kontrolę wprowadzonych danych oraz sygnalizować przekroczenie wymaganych wskaźników. |
|
W module powinno planować się przedsięwzięcia wieloletnie z ich wyszczególnieniem. |
|
Moduł musi być elastyczny, musi umożliwiać samodzielne kreowanie modeli, projekcje prognoz, parametryzację doboru danych, wykorzystanie metod prognostycznych oraz sposobów agregowania szeregów czasowych. |
|
Moduł powinien umożliwiać tworzenie załącznika przedsięwzięć wieloletnich w oparciu o centralny słownik zadań z opcją włączenia jednostek organizacyjnych oraz pracowników merytorycznych w proces wnioskowania o zmianę istotnych parametrów zadania. Wnioski powinny być składane w module. |
|
W module powinna być możliwość stworzenia kilku wariantów/scenariuszy WPF. System powinien automatycznie przenosić dane pomiędzy scenariuszami i umożliwiać automatyczną korektę danych poprzez wprowadzanie wskaźników procentowych lub korektę danych wprowadzoną ręcznie. |
|
W module musi być możliwość nadawania uprawnień użytkownikom. |
|
Moduł powinien umożliwiać generowanie wszystkich niezbędnych załączników i dokumentów tj. uchwały, załącznik WPF, załącznik przedsięwzięć, wnioski o zmianę nakładów, limitów czy źródeł finansowania przedsięwzięcia. |
|
Wszystkie dokumenty generowane przez moduł muszą być eksportowane do innych plików min.: doc., xls z możliwością ich edycji. |
|
Moduł powinien współpracować z pozostałymi modułami programu finansowo-księgowego i budżetowego oraz programem BeSTi@ w zakresie pobierania i przesyłania danych. |
System do podpisu elektronicznego – 5 kpl.
Lp. |
Opis minimalnych wymagań dla oprogramowania/urządzęń |
|
Typ: Podpis kwalifikowany z czytnikiem |
|
Wydanie certyfikatów – wymagania minimalne:
Certyfikaty musza być zapisane na kartach kryptograficznych – chipowych. |
|
Oprogramowanie: Wykonawca dostarczy oprogramowanie umożliwiające składanie oraz weryfikację podpisu. Oprogramowanie musi mieć polski interfejs użytkownika. |
|
Wymagania funkcjonalne: • Pamięć 64 kB • Podpisywanie i szyfrowanie XXX 0000 bitów • Wspierane algorytmy DES/3DES i SHA-1, RIPEMD 160 oraz SHA-2 • Wsparcie dla secure messaging Wymaga się wsparcia dla secure messaging • Generowanie kluczy na karcie (RSA,ECC) • Protokoły T=0/T=1 • Wsparcie dla standardów przemysłowych XXXX#00, #00, XX CAPI/CSP, PC/SC • Certyfikowane bezpieczeństwo aplikacji podpisu kwalifikowanego (QES) CC EAL 4+ • Certyfikowana platforma sprzętowa CC EAL 5+ • Aplikacja: wykonawca dostarczy wymaganą aplikację do obsługi karty |
|
Czytnik – wymagania minimalne: • Współpracujący z dostarczanymi kartami • Komunikacja z komputerem USB typu 2.0 • Interfejs karty musi wspierać protokoły Xx0, Xx0, Prędkość komunikacji do 420 Kbps, Częstotliwość do 8 MHz, Obsługa kart procesorowych ISO 7816 oraz EMV 2000 Xxxxx 0, Xxxxxx xxxxx - XX-000 (XXX Xxxx) • API PC/SC, OCF (Open Card Framework), CT-API • Certyfikacje ISO 7816, EMV 2000, Microsoft WHQL, PC/S.C., HBCI, USB Czytnik musi być dostarczony wraz ze sterownikami. |
|
Gwarancja i serwis: min. 60 miesięcy. |
Szkolenia pracowników
Wykonawca w ramach zamówienia wykona prace niezbędne do poprawnego uruchomienia całości oprogramowania dziedzinowego. 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 szczególności Zamawiający oczekuje migracji danych kartoteki kontrahentów skarbu państwa, niezbędnych danych w zakresie systemu kadrowo-płacowego, środków trwałych oraz bilansu otwarcia.
Wykonawca w ramach realizacji całego projektu obejmie szkoleniami oraz doradztwem w zakresie kompetencji cyfrowych z dostarczonych systemów łącznie nie mniej niż 50 osób, zgodnie z poniższą tabelą.
Szkolenia muszą obejmować zakres podstawowych funkcji i usług dostarczanego rozwiązania, których właściwe poznanie jest niezbędne do prawidłowego użytkowania.
Lp. |
Obszar szkolenia |
Liczba osób |
Minimalna ilość godzin szkoleniowych |
1. |
System finansowo- księgowy |
6 |
60 |
2. |
System kadrowo – płacowy |
2 |
30 |
3. |
System obsługi nieruchomości |
4 |
10 |
4. |
Aplikacja mobilna zintegrowana z platformą usług publicznych |
2 |
6 |
5. |
Portal zgodny z WCAG 2.0, wraz z platformą usług publicznych, aplikacją mobilną, BIP oraz systemem Elektronicznego Biura Obsługi Interesanta (EBOI) |
20 |
20 |
6. |
System Biuletyn Informacji Publicznej zintegrowany z systemem EZD |
20 |
10 |
7. |
System Elektronicznego Zarządzania Dokumentacją (EZD) wraz z elektronicznym archiwum zakładowym dla Starostwa Powiatowego |
50 |
45 |
8. |
System Elektronicznego Zarządzania Dokumentacją (EZD) wraz z elektronicznym archiwum zakładowym dla Zarządu Dróg Powiatowych w Lwówku Śląskim |
4 |
18 |
9. |
Zintegrowany System Płatności Elektronicznych e-płatności |
3 |
8 |
10. |
Obsługa Punktu Potwierdzania Profili Zaufanych |
3 |
8 |
11. |
Scentralizowany system służący do planowania i realizacji budżetu w trybie zadaniowym dla wszystkich jednostek |
20 |
20 |
Lp. |
Opis minimalnych wymagań dla szkoleń |
1. |
Szczegółowy plan szkolenia wraz z harmonogramem przygotowany zostanie na etapie planu realizacji projektu. |
2. |
Wykonawca na etapie uzgadniania materiałów szkoleniowych przekaże minimalne wymagania, jakie powinni spełniać oddelegowani przez Xxxxxxxxxxxxx, uczestnicy szkolenia. |
3. |
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. |
4. |
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. Wykonawca w ramach zamówienia dostarczy na potrzeby szkoleń rzutnik oraz ekran. |
5. |
Zamawiający nie dopuszcza przeprowadzania szkoleń typu e-learning w zastępstwie szkoleń tradycyjnych. |
6. |
Zamawiający dopuszcza przeprowadzanie szkoleń grupowych, w grupach do 10 użytkowników oraz szkoleń indywidualnych przy stanowiskowych dla grup jedno-, dwu- lub trzyosobowych. |
7. |
Wykonawca przeszkoli osoby pełniące obowiązki administratorów wskazanych przez Zamawiającego w zakresie zarządzania użytkownikami i uprawnieniami, zabezpieczania i odtwarzania danych. |
8. |
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. |
9. |
Uzgodnieniu pomiędzy stornami 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, - |
10. |
Zamawiający oczekuje, że ilość oraz program szkoleń powinny gwarantować użytkownikom systemu zapoznanie się z wszystkimi funkcjonalnościami jakie system oferuje. |
CZĘŚĆ 2 - DOSTAWA WRAZ Z WDROŻENIEM SPRZĘTU KOMPUTEROWEGO
W ramach realizacji dostaw i wdrożenia sprzętu komputerowego, Zamawiający wymaga dostarczenia poniższego sprzętu do siedziby Starostwa Powiatowego w Lwówku Śląskim oraz do jego Jednostek Podległych, zgodnie z poniższym wykazem:
Lp. |
Miejsce dostawy |
Sprzęt |
Ilość |
1. |
Starostwo Powiatowe w Lwówku Śląskim, xx. Xxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx |
Serwer dla Elektronicznego Obiegu Dokumentów |
1 szt. |
Skaner |
2 szt. |
||
Czytnik kodów wraz z drukarką |
4 szt. |
||
Switch RACK |
1 szt. |
||
UPS RACK |
1 szt. |
||
Jednostki robocze z monitorem |
31 szt. |
||
2. |
Zarząd Dróg Powiatowych w Lwówku Śląskim, xx. Xxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx |
Jednostki robocze z monitorem |
2 szt. |
3. |
Zespół Placówek Edukacyjno - Wychowawczych w Lwówku Śląskim, xx. Xxxxxxx 0, 00-000 Xxxxxx Xxxxxx |
Jednostki robocze z monitorem |
2 szt. |
4. |
Zespół Szkół Ekonomiczno - Technicznych im. Kombatantów Ziemi Lwóweckiej w Rakowicach Wielkich, Xxxxxxxx Xxxxxxx 00, 00-000 Xxxxxx Xxxxxx |
Jednostki robocze z monitorem |
2 szt. |
5. |
Zespół Szkół Ogólnokształcących i Zawodowych we Lwówku Śląskim, xx. Xxxxxxx Xxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx |
Jednostki robocze z monitorem |
2 szt. |
6. |
Zespół Szkół Ogólnokształcących i Zawodowych im. Xxxx Xxxxx XX w Gryfowie Śląskim, xx. Xxxxxxxx xx 00, 00-000 Xxxxxx Xxxxxx |
Jednostki robocze z monitorem |
2 szt. |
7. |
Dom Pomocy Społecznej w Nielestnie, Xxxxxxxxx 00x, 00-000 Xxxx |
Jednostki robocze z monitorem |
2 szt. |
8. |
Dom Pomocy Społecznej w Mirsku, xx. Xxxxxxx 00, 00-000 Xxxxx |
Jednostki robocze z monitorem |
2 szt. |
9. |
Szkolne Schronisko Młodzieżowe w Łupkach, Łupki 22, 59-610 Wleń, |
Jednostki robocze z monitorem |
1 szt. |
10. |
Powiatowe Centrum Pomocy Rodzinie w Lwówku Śląskim, xx. Xxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx |
Jednostki robocze z monitorem |
2 szt. |
11. |
Powiatowy Ośrodek Rozwoju Edukacji w Lwówku Śląskim, xx. Xxxxxxx Xxxxxxxxx 0, 00-000 Xxxxxx Xxxxxx |
Jednostki robocze z monitorem |
2 szt. |
Serwer dla Elektronicznego Obiegu Dokumentów – 1 szt.
Lp. |
Opis minimalnych wymagań dla sprzętu |
|||||||||||||||||||||||||||||||||||||||
|
Obudowa |
Dostarczona wraz z szynami umożliwiającymi pełne wysunięcie serwera z szafy rack. |
||||||||||||||||||||||||||||||||||||||
|
Płyta główna |
Minimum 2 sloty dla dysków M.2 na płycie głównej (lub dedykowanej karcie PCI Express) nie zajmujące klatek dla dysków hot-plug; (Możliwość integracji dedykowanej, wewnętrznej pamięci flash przeznaczonej dla wirtualizatora w slocie M.2 bez zajmowania klatek dyskowych serwera). |
||||||||||||||||||||||||||||||||||||||
|
Procesor |
|
||||||||||||||||||||||||||||||||||||||
|
RAM |
Minimum 24 gniazda pamięci RAM na płycie głównej, obsługa minimum 3072GB pamięci RAM DDR4 2933 Mhz; |
||||||||||||||||||||||||||||||||||||||
|
Kontrolery dyskowe, I/O |
Zainstalowany kontroler SAS 3.0 RAID 0,1,10,5,6,50,60. Kontroler wyposażony w minimum 2GB pamięci podręcznej cache podtrzymywanej bateryjnie. |
||||||||||||||||||||||||||||||||||||||
|
Napędy dyskowe |
Dyski SAS 12G 2,5” o pojemności minimum 1.2TB i prędkości obrotowej 10k – sztuk 12 |
||||||||||||||||||||||||||||||||||||||
|
Inne napędy zintegrowane |
Możliwość instalacji napędu DVD-RW; |
||||||||||||||||||||||||||||||||||||||
|
Porty LAN |
6 x 1Gbit/s. |
||||||||||||||||||||||||||||||||||||||
|
Porty |
Ilość dostępnych złącz VGA i USB nie może być osiągnięta poprzez stosowanie zewnętrznych przejściówek, rozgałęziaczy czy dodatkowych kart rozszerzeń zajmujących jakikolwiek slot PCI Express serwera |
||||||||||||||||||||||||||||||||||||||
|
Zasilanie chłodzące |
|
||||||||||||||||||||||||||||||||||||||
|
Zarządzanie |
|
||||||||||||||||||||||||||||||||||||||
|
Wspieranie XX |
Hyper-V Server 2016 |
||||||||||||||||||||||||||||||||||||||
|
Gwarancja |
Wykonawca wraz z dostawą serwerów przedstawi oświadczenie producenta serwerów, które będzie potwierdzało, że serwery objęte są gwarancją na terenie Polski zgodną z wymaganiami Zamawiającego. Oświadczenie to musi zawierać informację o nr seryjnym serwerów, nr katalogowy serwerów, dane wykonawcy oraz dane klienta końcowego. |
||||||||||||||||||||||||||||||||||||||
|
Dokumentacja, inne |
Możliwość aktualizacji i pobrania sterowników do oferowanego modelu serwera w najnowszych certyfikowanych wersjach bezpośrednio z sieci Internet za pośrednictwem strony www producenta serwera;. |
||||||||||||||||||||||||||||||||||||||
|
System operacyjny |
Systemy wskazane są w tabeli „Systemy operacyjne”. Licencja musi uprawniać do uruchamiania oprogramowania systemowego w środowisku fizycznym i trzech wirtualnych środowisk za pomocą wbudowanych mechanizmów wirtualizacji.
|
||||||||||||||||||||||||||||||||||||||
|
Wdrożenie serwera |
Zamawiający w ramach wdrożenia serwera dla Elektronicznego Obiegu Dokumentów wymaga:
Stworzenia pełnej dokumentacji wdrożonej infrastruktury. |
||||||||||||||||||||||||||||||||||||||
|
Wyposażenie dodatkowe |
Dla poprawnego działania rozwiązania Zamawiający wymaga dostarczenia macierzy dyskowej NAS spełniającej poniżej zestawione parametry minimalne:
|
||||||||||||||||||||||||||||||||||||||
|
Zakres usług |
W ramach postępowania wymagane jest wykonanie następujących usług (dotyczy wyłącznie serwera oraz macierzy dyskowej NAS):
|
Skaner – 2 szt.
Skaner typ I – 1 szt.
Lp. |
Opis minimalnych wymagań dla sprzętu |
|
|
Typ |
Skaner z podajnikiem |
|
Interfejs |
Co najmniej USB 2.0 |
|
Szybkość skanowania jednostronnego mono/kolor |
Co najmniej: 35 str./min. |
|
Rozdzielczość skanowania |
Min. 0000x0000 |
|
Pojemność podajnika |
Min. 50 arkuszy A4 80g/m2 |
|
Obsługiwana gramatura |
Min. 50-200 g/m2 |
|
Obsługiwane nośniki |
papier zwykły, wizytówki, karty plastikowe |
|
Funkcje skanowania |
Automatyczne prostowanie, usuwanie pustych stron |
|
Sterowniki |
TWAIN, WIA |
|
Skanowanie do |
Co najmniej: pliku, OCR, USB |
|
Dobowy cykl pracy |
Min. 3 000 stron |
|
Gwarancja |
Co najmniej 3 lata producenta. |
Skaner typ II – 1 szt.
Lp. |
Opis minimalnych wymagań dla sprzętu |
|
|
Typ |
Skaner z dwustronnym podajnikiem |
|
Rozdzielczość skanowania |
Min. 600 DPI x 600 DPI (poziomo x pionowo) |
|
Minimalny rozmiar dokumentu na ADF |
51 mm x 51 mm (poziomo x pionowo) |
|
Formaty papieru |
X0,X0, X0, X0, X0, X0, Xxxxxx, Pocztówka, Wizytówki, Plastikowe karty, |
|
Ultradźwiękowy czujnik |
Tak |
|
Źródło światła w skanerze |
Technologia diodowa |
|
Prędkość skanowania |
monochromatyczny
70 obrazów/min - Kolor: 70 obrazów/min pomiar za pomocą
Rozmiar: A4 , Rozdzielczość: 200 / 300 dpi, monochromatyczny 35
Str./min. - Kolor: 35 Str./min. pomiar za pomocą Rozmiar: A4 ,
Rozdzielczość: 200 / 300 dpi, ARDF:
min. 80 stron/minutę/SPDF: min. 120(simplex)/240(duplex)
stron/minutę |
|
Gramatura papieru |
Minimum 52 - 300 g/m² |
|
Rodzaj automatycznego podajnika dokumentów |
Skanowanie dwustronne jednoprzebiegowe |
|
Dzienna wydajność niezawodnej pracy |
Min. 4.000 Stron |
|
Automatyczny podajnik dokumentów |
Min.50 stron |
|
Skanowanie dwustronne (dupleks) |
Tak |
|
Funkcje skanowania |
|
|
Formaty edycji |
JPEG, TIFF, Skanowanie do multi-TIFF, PDF, Skanowanie do szukanego PDF, Skanowanie do zabezpieczonego PDF, PDF/A |
|
Pozostałe funkcje urządzenia |
Kopiowanie, drukowanie - monochromatyczne oraz kolorowe. Faks |
|
Typ urządzenia |
Nowe urządzenie wielofunkcyjne, kolorowe, formatu A3, gotowe do pracy |
|
Prędkośc kopiowania |
Minimum 30 kolorowych stron na minutę |
|
Dysk twardy |
Pojemność nie mniejsza niż 320 GB |
|
Pamięć RAM |
Minimum 2 GB |
|
interfejsy |
Ethernet BASE 10/100/1000, USB 2.0 |
|
Obsługiwane Formaty Papieru |
A3, A4, A5, A6, koperty |
|
Czytnik NFC |
Wbudowany czytnik NFC |
|
Podstawa |
Umożliwiająca wygodne przesuwanie urządzenia, spójna kolorystycznie, oryginalna producenta |
|
Pojemność Wejściowa Papieru |
1200 arkuszy |
|
Pojemność Wyjściowa Papieru |
500 arkuszy |
|
Obsługiwane Systemy Operacyjne |
Windows 10, Windows 7, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, MAC OS X 10.13 (High Sierra) |
|
Funkcje kompresji pliku |
Sprzętowa kompresja JPEG, Kompresja TIFF (JPEG(7), CCITT G4, LZW), Kompresja PDF |
|
Zaawansowana integracja dokumentu |
|
|
Przyłącza |
USB 3.0; możliwość rozbudowy o moduł skanera płaskiego oraz możliwość usieciowienia |
|
Obsługiwane protokoły |
TCP/IP, DHCP, DNS, SNMP, SLP |
|
Kompatybilne systemy operacyjne min. |
Linux, Mac OS 10.7.x, Mac OS 10.8.x, Mac OS 10.9.x, Mac OS X, Mac OS X 10.6.8, Windows 10, Windows 7, Windows 7 x64, Windows 8, Windows 8 (32/64 bit), Windows 8 RT, Windows 8.1, Windows 8.1 x64 Edition, Windows Server 2008 (32/64-bitowy), Windows Server 2008 R2, Windows Server 2012 (64bit), Windows Server 2012 R2, Windows Vista, Windows Vista x64, Windows Server 2003 R2, Wersja XP Professional x64 |
|
Wyposażenie |
Sterowniki i programy pomocnicze (CD), Kabel zasilający, Instrukcja montażu, Kabel USB |
|
Gwarancja |
Min. 24 miesięcy |
|
Wdrożenie skanerów |
Wdrożenie skanerów musi obejmować:
|
Czytnik kodów wraz z drukarką kodów – 4 kpl.
Lp. |
Opis minimalnych wymagań dla sprzętu |
|
|
Czytnik kodów |
|
|
Technologia odczytu |
Laserowa |
|
Odczytywane kody |
1D |
|
Maks. odległość odczytu |
Min. 43 cm |
|
Sygnał odczytu |
Świetlny |
|
Źródło światła |
dioda z widocznym laserem 650nm |
|
Prędkość skanowania |
Min. 100 odczytów na sekundę |
|
Odporność na upadek |
Z min. wysokości 1m |
|
Złącza |
Min. 1x USB 2.0 |
|
Dołączone akcesoria |
Podstawka, kabel |
|
Kolor |
Czarny |
|
Gwarancja |
Co najmniej 5 lat producenta |
|
Drukarka do kodów |
|
|
Rozdzielczość |
Min. 300 x 300 dpi |
|
Technologia druku |
Bezpośredni druk termiczny |
|
Interfejs |
Co najmniej:
IEEE 802.11 b/g/n |
|
Standardowa prędkość drukowania |
Min. 110 etykiety na minutę |
|
Maksymalna szerokość etykiety |
Min. 62 mm |
|
Maksymalna szerokość drukowania |
Min. 58 mm |
|
Bluetooth |
tak |
|
Gwarancja |
Min. 3 lata producenta |
|
Wdrożenie czytnika kodów wraz z drukarką |
Wdrożenie czytników kodów wraz z drukarką musi obejmować:
|
Switch rack – 1 szt.
Lp. |
Opis minimalnych wymagań dla sprzętu |
||||||||||||||||||||||||||||
|
Wymagane minimalne parametry techniczne |
|
|||||||||||||||||||||||||||
|
Gwarancja |
Urządzenie musi być objęte serwisem gwarancyjnym producenta przez okres minimum 60 miesięcy, polegającym na naprawie lub wymianie urządzenia w przypadku jego wadliwości. W ramach tego serwisu producent musi zapewniać również dostęp do aktualizacji oprogramowania oraz wsparcie techniczne.
|
|||||||||||||||||||||||||||
|
Wdrożenie switch RACK |
Wdrożenie switch RACK musi obejmować:
|
UPS Rack – 1 szt.
Lp. |
Opis minimalnych wymagań dla sprzętu |
|
|
Moc wyjściowa (pozorna / czynna) |
|
|
Typ obudowy |
|
|
Max. wysokość obudowy |
|
|
Ilość gniazd wyjściowych |
|
|
Zasilanie |
200V – 240V, jednofazowe, przewód zasilający do podłączenia zasilacza do sieci energetycznej. |
|
Zarządzanie |
Karta zdalnego zarządzania z portem Ethernet |
|
Gwarancja / serwis |
Wymagane 5 letnie wsparcie techniczne z możliwością zgłaszania problemów w dni robocze w godzinach 8-16 i z czasem reakcji w następnym dniu roboczym. |
|
Wdrożenie ups rack |
Wdrożenie UPS RACK musi obejmować:
|
Jednostki robocze z monitorem – 50 szt.
|
Typ |
Komputer stacjonarny. Typu All in One, komputer wbudowany w monitor. |
|
Zastosowanie |
Komputer będzie wykorzystywany dla potrzeb aplikacji biurowych, aplikacji edukacyjnych, aplikacji obliczeniowych, dostępu do Internetu oraz poczty elektronicznej, jako lokalna baza danych. |
|
Procesor |
Procesor, który powinien osiągać w teście wydajności PassMark PerformanceTest (wynik dostępny: xxxxx://xxx.xxxxxxxxxxxx.xxx/xxx_xxxx.xxx) co najmniej wynik 7 500 punktów Passmark CPU Mark. |
|
Pamięć RAM |
Min. 8 GB typu DDR4 2666 MHz Minimum 2 złącza SODIMM z obsługą do 32 GB DDR4 pamięci RAM. Konstrukcja komputera musi umożliwiać beznarzędziowy montaż i demontaż obu modułów pamięci |
|
Pamięć masowa |
Min. 256 GB SSD NVMe, zawierający partycję RECOVERY umożliwiającą odtworzenie systemu operacyjnego fabrycznie zainstalowanego na komputerze po awarii bez dodatkowych nośników |
|
Karta graficzna |
Zintegrowana |
|
Ekran |
Konstrukcja komputera powinna umożliwić demontaż stopy ekranu i powieszenie komputera np. na ścianie za pomocą standardowego złącza VESA (100x100 |
|
Wyposażenie multimedialne |
Karta dzwiękow Zintegrowana z płytą główną, zgodna z High Definition |
|
Obudowa |
Typu All-in-One zintegrowana z monitorem min. 23,8”. Obudowa musi umożliwiać zastosowanie zabezpieczenia fizycznego np. w postaci linki metalowej. Blokada ma uniemożliwiać otwarcie obudowy. Demontaż standu musi odbywać się bez użycia narzędzi, mocowanie standu opatrzone w przycisk zwalniający. Demontaż tylnej pokrywy musi odbywać się również bez użycia narzędzi, nie dopuszcza się stosowania śrub motylkowych, radełkowych czy zwykłych wkrętów. Możliwość zainstalowania komputera na ścianie przy wykorzystaniu ściennego systemu montażowego VESA 100x100. Każdy komputer powinien być oznaczony niepowtarzalnym numerem seryjnym umieszonym na obudowie, oraz musi być wpisany na stałe w BIOS. Wbudowany czujnik otwarcia obudowy współpracujący z oprogramowaniem zarządzająco – diagnostycznym. Wbudowany zasilacz o mocy maksymalnej 170 W pracujący w sieci 230V 50/60Hz prądu zmiennego i efektywności min. 90%, przy 50-procentowym obciążeniu. Zasilacz z certyfikatem 80plus GOLD. Obudowa musi mieć możliwość zabezpieczenia wnętrza komputera oraz wszystkich slotów znajdujących się z tyłu obudowy przed niepowołanym odstępem za pomocą kłódki lub linki typu Kensington. Ciężar komputera nie powinien przekraczać 10 kg. A suma wymiarów nie powinna być większa niż 1300 mm.) |
|
Zgodność z systemami opwracyjnymi i standardami |
Oferowany model komputera musi posiadać certyfikat Microsoft, potwierdzający poprawną współpracę z systemem operacyjnym Windows Pro 10 64bit |
|
System operacyjny |
Microsoft Windows 00 Xxx XX, zainstalowany system operacyjny Microsoft Windows 10 Pro niewymagający aktywacji za pomocą telefonu lub Internetu w firmie Microsoft. Dołączony nośnik z oprogramowaniem, sterownikami dla systemów Windows 10, płyty Recovery umożliwiające instalacje systemu wersji 64 bitowej.
|
|
Porty |
Microsoft Windows 00 Xxx XX, zainstalowany system operacyjny Microsoft Windows 10 Pro niewymagający aktywacji za pomocą telefonu lub Internetu w firmie Microsoft. Dołączony nośnik z oprogramowaniem, sterownikami dla systemów Windows 10, płyty Recovery umożliwiające instalacje systemu wersji 64 bitowej.
|
|
Karta sieciowa |
10/100/1000 Ethernet RJ 45, zintegrowana z płytą główną, wspierająca obsługę WoL (funkcja włączana przez użytkownika) |
|
bezpieczeństwo |
Zintegrowany z płytą główną dedykowany układ sprzętowy służący do tworzenia i zarządzania wygenerowanymi przez komputer kluczami szyfrowania. Zabezpieczenie to musi posiadać możliwość szyfrowania poufnych dokumentów przechowywanych na dysku twardym przy użyciu klucza sprzętowego (TPM co najmniej w wersji 2.0)
|
|
BIOS |
- modelu komputera; - modelu płyty głównej; - nr seryjnego komputera; - wersji BIOS (z datą); - modelu procesora wraz z informacjami o prędkości taktowania; - Informacji o ilości i obsadzeniu slotów pamięci RAM wraz z informacją o prędkości taktowania; - Informacji o dysku twardym: model oraz pojemność - MAC adresie zintegrowanej karty sieciowej - temperaturze procesora - temperaturze pamięci - statusie karty sieciowej
- karty sieciowej RJ45 - karty dźwiękowej - karty sieciowej bezprzewodowej i Bluetooth (jeśli zainstalowane) - zintegrowanej kamery (jeśli zainstalowana) - zintegrowanego mikrofonu (jeśli zainstalowany) - portu szeregowego z możliwością ustawienia trybu pracy - sprzętowego wsparcia wirtualizacji - wsparcia wirtualizacji Directed I/O - funkcji regulacji częstotliwości taktowania CPU w zależności od obciążenia (Enhanced SpeedStep) - funkcji Turbo Mode pozwalającej logicznym procesorom CPU osiągać wyższe częstotliwości taktowania od domyślnych w sytuacji gdy pozwalają na to termiczne parametry pracy procesora - kontrolera SATA - możliwość pojedynczego wyłączania poszczególnych portów SATA oraz M.2 - funkcji SMART - modułu TPM wraz z informacją o rodzaju aktualnie zainstalowanego modułu TPM - portów USB w tym: włączenia wszystkich portów, wyłączenia wszystkich portów, włączenia jedynie przednich i wewnętrznych, włączenia jedynie tylnych i wewnętrznych, włączenia jedynie wewnętrznych, włączenia jedynie używanych (system sprawdza przy starcie komputera, w których portach USB jest włączone urządzenie i tylko te aktywuje) - funkcji blokowania używanych portów USB w tym: włączenia wszystkich używanych portów, włączenia jedynie portów do których podłączono klawiaturę i mysz, włączenia wszystkich portów za wyjątkiem portów do których podłączono USB hub lub zewnętrzną pamięć masową. - funkcji Wake-on-LAN
- liczby aktywnych rdzeni procesora - funkcji sterowania prędkością wentylatorów w komputerze w co najmniej trzech trybach: Automatycznym, trybie zwiększonej przepływności powietrza w celu osiągnięcia maksymalnej wydajności procesora, trybie maksymalnej wydajności wszystkich wentylatorów. - trybu pracy karty sieciowej - możliwości aktualizacji BIOS-u w tym co najmniej: całkowite wyłączenie możliwości aktualizacji, możliwość aktualizacji za pomocą narzędzi producenta komputera lub mechanizmu Windows Update, możliwość aktualizacji jedynie za pomocą narzędzi producenta komputera - możliwość ustawienia trybu pracy komputera po przywróceniu zasilania po awarii zasilania w co najmniej trzech trybach: pozostaje wyłączony, zawsze wyłączony, zawsze włączony, przywrócenie stanu z przed awarii
|
|
klawiatura |
USB w układzie QWERTY US |
|
Mysz |
optyczna USB z trzema klawiszami oraz rolką (scroll) |
|
Napęd optyczny |
Nagrywarka DVD |
|
Normy i standardy |
Komputery mają spełniać normy i posiadać deklaracje zgodności (lub inne dokumenty potwierdzające spełnienie norm) w zakresie:
|
|
Warunki gwarancji |
Naprawy gwarancyjne urządzeń muszą być realizowane przez Producenta lub Autoryzowanego Partnera Serwisowego Producenta |
|
Wsparcie techniczne producenta |
|
|
Pakiet biurowy |
Zainstalowany i aktywowany pakiet aplikacji biurowych. Pakiet aplikacji biurowych minimalne wymagania ogólne: •Dostępny w architekturze 64-bitowej i 32-bitowej, •Wymagana polska wersja językowa, •Zgodny z zainstalowanym systemem operacyjnym, •Licencja bezterminowa przypisana do zaoferowane zestawu komputerowego.Pakiet aplikacji biurowych musi spełniać następujące wymagania minimalne: •Pakiet biurowy dostarczony wraz z licencją i nośnikiem. •Wymagania odnośnie interfejsu użytkownika: - Pełna polska wersja językowa interfejsu użytkownika. - Możliwość zintegrowania uwierzytelniania użytkowników z usługą katalogową – użytkownik raz zalogowany z poziomu systemu operacyjnego stacji roboczej ma być automatycznie rozpoznawany we wszystkich modułach oferowanego rozwiązania bez potrzeby oddzielnego monitowania go o ponowne uwierzytelnienie się. •Oprogramowanie musi umożliwiać tworzenie i edycję dokumentów elektronicznych w ustalonym formacie, który spełnia następujące warunki: - posiada kompletny i publicznie dostępny opis formatu, - ma zdefiniowany układ informacji w postaci XML zgodnie z aktualnie obowiązującymi przepisami i wymogami Rozporządzenia Rady Ministrów w sprawie Krajowych Ram Interoperacyjności, - umożliwia wykorzystanie schematów XML, wspiera w swojej specyfikacji podpis elektroniczny zgodnie z aktualnie obowiązującymi przepisami i wymogami Rozporządzenia Rady Ministrów w sprawie Krajowych Ram Interoperacyjności; •Oprogramowanie musi umożliwiać dostosowanie dokumentów i szablonów do potrzeb instytucji oraz udostępniać narzędzia umożliwiające dystrybucję odpowiednich szablonów do właściwych odbiorców. •W skład oprogramowania muszą wchodzić narzędzia programistyczne umożliwiające automatyzację pracy i wymianę danych pomiędzy dokumentami i aplikacjami (język makropoleceń, język skryptowy), •Do aplikacji musi być dostępna pełna dokumentacja w języku polskim. •Pakiet zintegrowanych aplikacji biurowych musi zawierać min.: - Edytor tekstów - Arkusz kalkulacyjny - Narzędzie do przygotowywania i prowadzenia prezentacji - Narzędzie do zarządzania informacją prywatną (pocztą elektroniczną, kalendarzem, kontaktami i zadaniami). •Edytor tekstów musi umożliwiać min.: - Edycję i formatowanie tekstu w języku polskim wraz z obsługą języka polskiego w zakresie sprawdzania pisowni i poprawności gramatycznej oraz funkcjonalnością słownika wyrazów bliskoznacznych i autokorekty. - Wstawianie oraz formatowanie tabel i obiektów graficznych. - Wstawianie wykresów i tabel z arkusza kalkulacyjnego (wliczając tabele przestawne). - Automatyczne numerowanie rozdziałów, punktów, akapitów, tabel, rysunków oraz tworzenie spisów treści. - Formatowanie nagłówków i stopek stron. - Sprawdzanie pisowni w języku polskim. - Śledzenie zmian wprowadzonych przez użytkowników. - Nagrywanie, tworzenie i edycję makr automatyzujących wykonywanie czynności. - Określenie układu strony (pionowa/pozioma). - Wydruk dokumentów. - Wykonywanie korespondencji seryjnej bazując na danych adresowych pochodzących z arkusza kalkulacyjnego i z narzędzia do zarządzania informacją prywatną. - Pracę min. na dokumentach utworzonych przy pomocy Microsoft Word 2003, 2007, 2010 i 2013 z zapewnieniem bezproblemowej konwersji wszystkich elementów i atrybutów Dokumentu. - Zabezpieczenie dokumentów hasłem przed odczytem oraz przed wprowadzaniem modyfikacji. - Wymagana jest dostępność do oferowanego edytora tekstu bezpłatnych narzędzi umożliwiających wykorzystanie go, jako środowiska udostępniającego formularze bazujące na schematach XML z Centralnego Repozytorium Wzorów Dokumentów Elektronicznych, które po wypełnieniu umożliwiają zapisanie pliku XML w zgodzie z obowiązującym prawem. - Wymagana jest dostępność do oferowanego edytora tekstu bezpłatnych narzędzi (kontrolki) umożliwiających podpisanie podpisem elektronicznym pliku z zapisanym dokumentem przy pomocy certyfikatu kwalifikowanego zgodnie z wymaganiami obowiązującego w Polsce prawa. - Wymagana jest dostępność do oferowanego edytora tekstu bezpłatnych narzędzi umożliwiających wykorzystanie go, jako środowiska udostępniającego formularze pozwalające zapisać plik wynikowy w zgodzie z Rozporządzeniem o Aktach Normatywnych i Prawnych. •Arkusz kalkulacyjny musi umożliwiać min.: - Tworzenie raportów tabelarycznych i wykresów liniowych (wraz linią trendu), słupkowych, kołowych. - Tworzenie arkuszy kalkulacyjnych zawierających teksty, dane liczbowe oraz formuły przeprowadzające operacje matematyczne, logiczne, tekstowe, statystyczne oraz operacje na danych finansowych i na miarach czasu. - Tworzenie raportów z zewnętrznych źródeł danych (inne arkusze kalkulacyjne, bazy danych zgodne z ODBC, pliki tekstowe, pliki XML, webservice). - Obsługę „kostek OLAP” oraz tworzenie i edycję kwerend bazodanowych i webowych. Narzędzia wspomagające analizę statystyczną i finansową, analizę wariantową i rozwiązywanie problemów optymalizacyjnych. - Tworzenie raportów tabeli przestawnych umożliwiających dynamiczną zmianę wymiarów oraz wykresów bazujących na danych z tabeli przestawnych. - Wyszukiwanie i zamianę danych. - Wykonywanie analiz danych przy użyciu formatowania warunkowego. - Nazywanie komórek arkusza i odwoływanie się w formułach po takiej nazwie. - Nagrywanie, tworzenie i edycję makr automatyzujących wykonywanie czynności. - Formatowanie czasu, daty i wartości finansowych z polskim formatem. - Zapis wielu arkuszy kalkulacyjnych w jednym pliku. - Zachowanie pełnej zgodności min. z formatami plików utworzonych za pomocą oprogramowania Microsoft Excel 2003, 2007, 2010 i 2013 z uwzględnieniem poprawnej realizacji użytych w nich funkcji specjalnych i makropoleceń. - Zabezpieczenie dokumentów hasłem przed odczytem oraz przed wprowadzaniem modyfikacji. •Narzędzie do przygotowywania i prowadzenia prezentacji musi umożliwiać min.: - Przygotowywanie prezentacji multimedialnych, które będą: a) Prezentowane przy użyciu projektora multimedialnego. b) Drukowane w formacie umożliwiającym robienie notatek. c) Zapisane jako prezentacja tylko do odczytu. - Nagrywanie narracji i dołączanie jej do prezentacji. - Opatrywanie slajdów notatkami dla prezentera. - Umieszczanie i formatowanie tekstów, obiektów graficznych, tabel, nagrań dźwiękowych i wideo. - Umieszczanie tabel i wykresów pochodzących z arkusza kalkulacyjnego. - Odświeżenie wykresu znajdującego się w prezentacji po zmianie danych w źródłowym arkuszu kalkulacyjnym. - Możliwość tworzenia animacji obiektów i całych slajdów. - Prowadzenie prezentacji w trybie prezentera, gdzie slajdy są widoczne na jednym monitorze lub projektorze, a na drugim widoczne są slajdy i notatki prezentera. - Pełna zgodność min. z formatami plików utworzonych za pomocą oprogramowania MS PowerPoint 2003, 2007 2010 i 2013. •Narzędzie do zarządzania informacją prywatną (pocztą elektroniczną, kalendarzem, kontaktami i zadaniami) musi umożliwiać min.: - Pobieranie i wysyłanie poczty elektronicznej z serwera pocztowego. - Filtrowanie niechcianej poczty elektronicznej (SPAM) oraz określanie listy zablokowanych i bezpiecznych nadawców. -Tworzenie katalogów, pozwalających katalogować pocztę elektroniczną. - Automatyczne grupowanie poczty o tym samym tytule. -Tworzenie reguł przenoszących automatycznie nową pocztę elektroniczną do określonych katalogów bazując na słowach zawartych w tytule, adresie nadawcy i odbiorcy. -Oflagowanie poczty elektronicznej z określeniem terminu przypomnienia. - Zarządzanie kalendarzem. - Udostępnianie kalendarza innym użytkownikom. - Przeglądanie kalendarza innych użytkowników. - Zapraszanie uczestników na spotkanie, co po ich akceptacji powoduje automatyczne wprowadzenie spotkania w ich kalendarzach. - Zarządzanie listą zadań. - Zlecanie zadań innym użytkownikom. - Zarządzanie listą kontaktów. - Udostępnianie listy kontaktów innym użytkownikom. - Przeglądanie listy kontaktów innych użytkowników. - Możliwość przesyłania kontaktów innym użytkowników. Oprogramowanie biurowe musi posiadać wszelkie dokumenty potwierdzające jego legalność Zamawiający wymaga fabrycznie nowego oprogramowania biurowego nieużywanego oraz nieaktywowanego nigdy wcześniej na innym urządzeniu. |
|
Wdrożenie jednostek roboczych dostarczonych do Starostwa Powiatowego w Lwówku Śląskim |
Wdrożenie jednostek roboczych musi obejmować:
|
|
Wdrożenie jednostek roboczych dostarczonych dla Zarządu Dróg Powiatowych w Lwówku Śląskim
|
Wdrożenie jednostek roboczych musi obejmować:
|
|
Wdrożenie jednostek roboczych dostarczonych dla pozostałych Jednostek Podległych
|
Wdrożenie jednostek roboczych musi obejmować:
|
|
Wymaganie dodatkowe |
Wykonawca wraz z dostawą komputerów przedstawi oświadczenie producenta komputerów, które będzie potwierdzało, że komputery objęte są gwarancją na terenie Polski zgodną z wymaganiami Zamawiającego. Oświadczenie to musi zawierać informację o nr seryjnych komputerów, nr katalogowych komputerów, dane wykonawcy oraz dane klienta końcowego
|
Systemy operacyjne oraz pakiety biurowe
|
W środowisku Zamawiającego funkcjonują usługi oparte o usługi katalogowe Active Directory oparte o systemy z rodziny Windows Server. Mając ten fakt na uwadze Wykonawca w ramach realizacji zamówienia dostarczy poniższe licencje systemowe celem możliwości stworzenie min. 3 maszyn wirtualnych w tym jedna z Active Directory:
|
Harmonogram realizacji
Wykonawca w ramach zamówienia wykona niezbędne prace instalacyjne oraz wdrożeniowe do poprawnego uruchomienia przedmiotu zamówienia z zachowaniem następujących terminów:
Lp. |
Zakres |
Termin zakończenia prac |
|
Część I |
Dostawa i wdrożenie oprogramowania dziedzinowego oraz sprzętu komputerowego |
||
|
Portal zgodny z WCAG 2.0, wraz z wdrożeniem i integracją platform usług publicznych, aplikacją mobilną, BIP |
31.08.2020 r. |
|
|
System Biuletyn Informacji Publicznej zintegrowany z systemem EZD |
31.08.2020 r. |
|
|
System Elektronicznego Zarządzania Dokumentacją (EZD) wraz z elektronicznym archiwum zakładowym dla Starostwa Powiatowego |
31.08.2020 r. |
|
|
System Elektronicznego Zarządzania Dokumentacją (EZD) wraz z elektronicznym archiwum zakładowym dla 1 Jednostki Organizacyjnej |
31.08.2020 r. |
|
|
Zintegrowany System Płatności Elektronicznych e-płatności |
31.08.2020 r. |
|
|
Baza danych oraz niezbędne oprogramowanie |
31.08.2020 r. |
|
|
Uruchomienie i oznakowanie Punktu Potwierdzania Profili Zaufanych |
31.08.2020 r. |
|
|
Integracja systemów dziedzinowych umożliwiających obsługę systemów e-usług |
31.06.2020 r. |
|
|
Szyna usług integrująca usługi e-PUAP, EZD i systemy dziedzinowe wraz z brokerem integracyjnym |
31.08.2020 r. |
|
|
Platforma usług publicznych udostępniająca dane z systemów dziedzinowych wraz z Systemem Elektronicznego Biura Obsługi Interesanta (EBOI) |
31.08.2020 r. |
|
|
Aplikacja mobilna zintegrowana z platformą usług publicznych, |
31.08.2020 r. |
|
|
Scentralizowanyo system służący do planowania i realizacji budżetu w trybie zadaniowym dla wszystkich jednostek |
31.08.2020 r. |
|
|
System do podpisu elektronicznego |
31.08.2020 r. |
|
|
Szkolenia pracowników |
30.09.2020 r. |
|
|
Dostawa i wdrożenie sprzętu komputerowego |
40 dni od daty podpisania umowy |
Wymagania dodatkowe
Obowiązek zatrudnienia osób wykonujących przedmiot zamówienia na podstawie umowy o pracę zgodnie z art. art. 29 ust. 3a ustawy Pzp.
Wykonawca zobowiązany jest do zatrudnienia w trakcie realizacji zamówienia, na podstawie umowy o pracę w rozumieniu przepisu art. 22 § 1 ustawy z dnia 26 czerwca 1974 r. - Kodeks pracy następujących członków zespołu Wykonawcy:
Specjalista ds. wsparcia technicznego (Help desk) – 1 osoba,
które umożliwią wykonanie umowy zgodnie z jej przedmiotem oraz treścią.
Bezpośrednie czynności jakie będą wykonywane przez tych specjalistów to:
obsługa procesu bezpośredniego wsparcia użytkowników (helpdesk),
zarządzanie zgłoszeniami i rozwiązywanie problemów w zakresie wdrażanych rozwiązań informatycznych,
pomoc w konfiguracji / rekonfiguracji oprogramowania,
zdalne wsparcie użytkowników w zakresie obsługi oprogramowania,
informowanie użytkowników o zmianach dotyczących oprogramowania.
Wymóg zatrudnienia na podstawie umowy o pracę nie dotyczy podwykonawców prowadzących działalność gospodarczą na podstawie wpisu do CEIDG oraz wykonujących osobiście i samodzielnie czynności powierzone im w zakresie realizacji przedmiotu zamówienia.
Obowiązek określony w ust. 1 i 2 ma zastosowanie także do podwykonawców oraz dalszych podwykonawców. Wykonawca ma obowiązek zawrzeć w umowie z podwykonawcą obowiązek zatrudnienia przez podwykonawcę i dalszych podwykonawców osób, o których mowa w ust. 1, na umowę o pracę.
Po podpisaniu umowy, najpóźniej w dniu rozpoczęcia realizacji umowy, wykonawca lub podwykonawca zobowiązany jest przedłożyć oświadczenie pod rygorem odpowiedzialności karnej (art. 271 kk) o spełnieniu obowiązku, o którym mowa w ust. 1.
W trakcie realizacji zamówienia zamawiający uprawniony jest do wykonywania czynności kontrolnych wobec wykonawcy odnośnie spełniania przez wykonawcę lub podwykonawcę wymogu zatrudnienia na podstawie umowy o pracę osób wykonujących wskazane w ust. 1 czynności. Zamawiający uprawniony jest w szczególności do:
żądania oświadczeń i dokumentów w zakresie potwierdzenia spełniania ww. wymogów i dokonywania ich oceny,
żądania wyjaśnień w przypadku wątpliwości w zakresie potwierdzenia spełniania ww. wymogów,
przeprowadzania kontroli na miejscu wykonywania świadczenia.
W trakcie realizacji zamówienia na każde wezwanie zamawiającego w wyznaczonym w tym wezwaniu terminie, wykonawca przedłoży zamawiającemu wskazane poniżej dowody w celu potwierdzenia spełnienia wymogu zatrudnienia na podstawie umowy o pracę przez wykonawcę lub podwykonawcę osób wykonujących wskazane w ust. 1 czynności w trakcie realizacji zamówienia:
oświadczenie wykonawcy lub podwykonawcy o zatrudnieniu na podstawie umowy o pracę osób wykonujących czynności, których dotyczy wezwanie zamawiającego. Oświadczenie to powinno zawierać w szczególności: dokładne określenie podmiotu składającego oświadczenie, datę złożenia oświadczenia, wskazanie, że objęte wezwaniem czynności wykonują osoby zatrudnione na podstawie umowy o pracę wraz ze wskazaniem liczby tych osób, imion i nazwisk tych osób, rodzaju umowy o pracę i wymiaru etatu oraz podpis osoby uprawnionej do złożenia oświadczenia w imieniu wykonawcy lub podwykonawcy;
poświadczoną za zgodność z oryginałem odpowiednio przez wykonawcę lub podwykonawcę kopię umowy/umów o pracę osób wykonujących w trakcie realizacji zamówienia czynności, których dotyczy ww. oświadczenie wykonawcy lub podwykonawcy (wraz z dokumentem regulującym zakres obowiązków, jeżeli został sporządzony). Kopia umowy/umów powinna zostać zanonimizowana w sposób zapewniający ochronę danych osobowych pracowników, zgodnie z przepisami ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (tj. w szczególności bez adresów, nr PESEL pracowników). Imię i nazwisko pracownika nie podlega anonimizacji. Informacje takie jak: data zawarcia umowy, rodzaj umowy o pracę i wymiar etatu powinny być możliwe do zidentyfikowania;
zaświadczenie właściwego oddziału ZUS, potwierdzające opłacanie przez wykonawcę lub podwykonawcę składek na ubezpieczenia społeczne i zdrowotne z tytułu zatrudnienia na podstawie umów o pracę za ostatni okres rozliczeniowy;
poświadczoną za zgodność z oryginałem odpowiednio przez wykonawcę lub podwykonawcę kopię dowodu potwierdzającego zgłoszenie pracownika przez pracodawcę do ubezpieczeń, zanonimizowaną w sposób zapewniający ochronę danych osobowych pracowników, zgodnie z przepisami ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych. Imię i nazwisko pracownika nie podlega anonimizacji.
Za każde stwierdzone niedopełnienie wymogu o którym mowa w ust. 1, wykonawca zapłaci Zamawiającemu karę umowną w wysokości kwoty minimalnego wynagrodzenia za pracę, ustalonego na podstawie przepisów o minimalnym wynagrodzeniu za pracę (obowiązujących w chwili stwierdzenia przez Xxxxxxxxxxxxx niedopełnienia przez wykonawcę lub podwykonawcę wymogu o którym mowa w ust. 1) - za każdą osobę wobec której nie dopełniono obowiązku zatrudnienia na umowę o pracę.
W przypadku uzasadnionych wątpliwości co do przestrzegania prawa pracy przez wykonawcę lub podwykonawcę, zamawiający może zwrócić się o przeprowadzenie kontroli przez Państwową Inspekcję Pracy.
„Dalszy rozwój e-usług w Powiatach Lubańskim, Lwóweckim, Zgorzeleckim,
Bolesławieckim i Gminie Miejskiej Lubań”
Nr projektu: RPDS.02.01.01-IZ.00-00-000/17- konkurs horyzontalny
Projekt jest współfinansowany przez Unię Europejską ze środków EFRR w ramach RPO WD na lata 2014-2020
124