SZCZEGÓŁOWY OPIS PRZEMIOTU ZAMÓWIENIA
Załącznik Nr 1 Do SIWZ
SZCZEGÓŁOWY OPIS PRZEMIOTU ZAMÓWIENIA
Nazwa zamówienia modernizacja, rozbudowa i wdrożenie nowych systemów informatycznych
z uruchomieniem e-usług z dostawą niezbędnego sprzętu i oprogramowania w ramach
realizowanego projektu pn. „Modernizacja i rozbudowa systemów informatycznych samorządów województwa lubelskiego w celu podniesienia jakości usług publicznych” współfinansowanego ze środków UE w ramach RPO WL 2014-2020, Oś priorytetowa 2 Cyfrowe Lubelskie,
Działanie 2.1 Cyfrowe Lubelskie.
ZAMAWIAJĄCY:
Zamawiający 1C: | Gmina Chełm |
Zamawiający 1L: | Gmina Łopiennik Górny |
Zamawiający 1P: | Gmina Piaski |
Zamawiający 1U: | Gmina Ulan-Majorat |
Zamawiający 1K: | Powiat Krasnostawski |
Pełnomocnik Zamawiających:
NAZWA | Fundacja Fundusz Lokalny im. Xxxx XXX Xxxxxxxxxxx |
ADRES XXXXXXXX | Xxxxxxxxxxx 0, 00-000 Xxxxxxx |
ADRES DO XXXXXXXX | Xxxxxxxx 00, 00-000 Xxxxxx |
Spis treści
Wymagania ogólne dla przedmiotu zamówienia 9
Wymagania ogólne dla wdrożeń Oprogramowania Aplikacyjnego 14
Ogólne wymogi związane z dostępnością treści 19
Ogólne wymogi w zakresie tworzenia formularzy ePUAP 22
Część 1C. Modernizacja, rozbudowa i wdrożenie nowych systemów informatycznych z
uruchomieniem e-usług w gminie Chełm z dostawą niezbędnego sprzętu i oprogramowania 26
1.1. #01# Modernizacja systemów dziedzinowych z uruchomieniem dedykowanego portalu e- należności 26
1.1.1. Modernizacja systemów dziedzinowych 27
1.1.2. System informacji internetowej o stanie należności urzędu z tytułu podatków i opłat z możliwością dokonywania płatności elektronicznych (e-należności) 55
1.2. #02# Dostosowanie formularzy e-usług 61
1.3. #01# Broker integracyjny 62
Informacje dotyczące integracji systemów 63
1.4. #01# Modernizacja systemu EZD 65
1.4.2. Dokumenty przychodzące i wychodzące 66
1.4.3. Integracja z platformą ePUAP 70
1.4.4. Obsługa spraw i dokumentów – dokumenty przychodzące 71
1.4.5. Obsługa spraw i dokumentów - akceptacje dokumentów 72
1.4.6. Obsługa spraw i dokumentów – wszczynanie i prowadzenie spraw 72
1.4.7. Obsługa dokumentów wewnętrznych 74
1.4.9. Podpis elektroniczny 76
1.4.10. Wzory dokumentów i korespondencja seryjna 76
1.4.12. Automatyzacja procesów biznesowych 77
1.4.14. Komunikaty i powiadomienia 78
1.4.16. Urlopy i zastępstwa 80
1.4.18. Raportowanie i monitorowanie 80
1.4.19. Administracja systemem 81
1.5. #02# Zaprogramowanie procesów w EZD 84
1.6. #01# System obsługi zamówień publicznych 84
1.8. #06# Macierz dyskowa (1 szt.) 90
1.9. #07# Oprogramowanie monitorujące 92
Część 1L. Modernizacja, rozbudowa i wdrożenie nowych systemów informatycznych z
uruchomieniem e-usług w gminie Łopiennik Górny z dostawą niezbędnego sprzętu i oprogramowania
............................................................................................................................................................... 94
2.1. #09# Modernizacja systemów dziedzinowych z uruchomieniem dedykowanego portalu e- należności 94
2.1.1. Modernizacja systemów dziedzinowych 95
2.1.2. System informacji internetowej o stanie należności urzędu z tytułu podatków i opłat z możliwością dokonywania płatności elektronicznych (e-należności) 119
2.2. #10# Dostosowanie formularzy e-usług 126
2.3. #09# Broker integracyjny 127
Informacje dotyczące integracji systemów 128
2.4. #09# Modernizacja systemu EZD 130
2.4.1. Wymagania ogólne 130
2.4.2. Dokumenty przychodzące i wychodzące 131
2.4.3. Integracja z platformą ePUAP 135
2.4.4. Obsługa spraw i dokumentów – dokumenty przychodzące 136
2.4.5. Obsługa spraw i dokumentów - akceptacje dokumentów 137
2.4.6. Obsługa spraw i dokumentów – wszczynanie i prowadzenie spraw 137
2.4.7. Obsługa dokumentów wewnętrznych 139
2.4.8. Interesanci 140
2.4.9. Podpis elektroniczny 141
2.4.10. Wzory dokumentów i korespondencja seryjna 141
2.4.11. Umowy 142
2.4.12. Automatyzacja procesów biznesowych 142
2.4.13. Komunikator 143
2.4.14. Komunikaty i powiadomienia 143
2.4.15. Kalendarz 143
2.4.16. Urlopy i zastępstwa 145
2.4.17. Archiwum zakładowe 145
2.4.18. Raportowanie i monitorowanie 145
2.4.19. Administracja systemem 146
2.4.20. Bezpieczeństwo 148
2.5. #10# Zaprogramowanie procesów w EZD 149
2.6. #09# System do planowania i zarządzania budżetem 149
2.7. #10# Uruchomienie e-usług budżetowych 160
2.8. #09# System obsługi zamówień publicznych 161
2.9. #09# System obsługi rady gminy 165
2.10. #13# Serwery (2 szt.) 172
2.11. #13# Serwer - typ 2 (1 szt.) 174
2.12. #17# Wdrożenie usług katalogowych 177
2.13. #14# Zasilacz awaryjny do serwera (1 szt.) 178
2.14. #14# Macierz NAS (1 szt.) 179
2.15. #14# Macierz NAS typ 2 (1 szt.) 179
2.16. #14# Macierz NAS typ 3 (2 szt.) 180
2.17. #16# Oprogramowanie do backupu 180
2.18. #16# Oprogramowanie monitorujące 182
2.19. #14# Urządzenie UTM (1 szt.) 191
2.20. #14# Urządzenie UTM typ 2 (4 szt.) 196
2.21. #14# Switch zarządzalny typ 1 (1 szt.) 201
2.22. #14# Switch zarządzalny typ 2 (1 szt.) 202
2.23. #14# Zestaw urządzeń do obsługi EZD w kancelarii (1 kpl.) 203
Część 1P. Modernizacja, rozbudowa i wdrożenie nowych systemów informatycznych z
uruchomieniem e-usług w gminie Piaski z dostawą niezbędnego sprzętu i oprogramowania 205
3.1. #19# Uruchomienie e-usług podatkowych z modernizacją systemów dziedzinowych 205
3.1.1. Modernizacja systemów dziedzinowych 206
3.1.2. System informacji internetowej o stanie należności urzędu z tytułu podatków i opłat z możliwością dokonywania płatności elektronicznych (e-należności) 231
3.2. #19# Broker integracyjny 237
Informacje dotyczące integracji systemów 238
3.3. #20# Opracowanie procedur dla e-usług, dostosowanie lub wykonanie formularzy,
oprogramowanie procesów w EZD 240
3.4. #19# System do planowania i zarządzania budżetem 242
3.5. #20# Uruchomienie e-usług budżetowych 253
3.6. #19# Modernizacja systemu EZD 254
3.7. #19# System obsługi zamówień publicznych 282
3.8. #19# System obsługi rady gminy 287
3.9. #23# Serwery (2 szt.) 294
3.10. #24# Macierz NAS (1 szt.) 296
3.11. #26# Serwerowy system operacyjny (2 szt.) 297
3.12. #26# Licencje dostępowe do serwerowego systemu operacyjnego (15 szt.) 297
3.13. #26# Oprogramowanie monitorujące 298
Część 1U. Modernizacja, rozbudowa i wdrożenie nowych systemów informatycznych z
uruchomieniem e-usług w gminie Ulan-Majorat z dostawą niezbędnego sprzętu i oprogramowania
............................................................................................................................................................. 299
4.1. #28# Uruchomienie e-usług podatkowych z modernizacją systemów dziedzinowych 299
4.1.1. Modernizacja systemów dziedzinowych 300
4.1.2. System informacji internetowej o stanie należności urzędu z tytułu podatków i opłat z możliwością dokonywania płatności elektronicznych (e-należności) 326
4.2. #29# Opracowanie procedur dla e-usług, dostosowanie lub wykonanie formularzy,
oprogramowanie procesów w EZD 332
4.3. #28# Broker integracyjny 334
Informacje dotyczące integracji systemów 335
4.4. #28# System do planowania i zarządzania budżetem 337
4.5. #29# Uruchomienie e-usług budżetowych 348
4.6. #28# Modernizacja systemu EZD 349
4.6.1. Wymagania ogólne 349
4.6.2. Dokumenty przychodzące i wychodzące 349
4.6.3. Integracja z platformą ePUAP 354
4.6.4. Obsługa spraw i dokumentów – dokumenty przychodzące 355
4.6.5. Obsługa spraw i dokumentów - akceptacje dokumentów 355
4.6.6. Obsługa spraw i dokumentów – wszczynanie i prowadzenie spraw 356
4.6.7. Obsługa dokumentów wewnętrznych 358
4.6.8. Interesanci 358
4.6.9. Podpis elektroniczny 359
4.6.10. Wzory dokumentów i korespondencja seryjna 360
4.6.11. Umowy 360
4.6.12. Automatyzacja procesów biznesowych 361
4.6.13. Komunikator 361
4.6.14. Komunikaty i powiadomienia 362
4.6.15. Kalendarz 362
4.6.16. Urlopy i zastępstwa 363
4.6.17. Archiwum zakładowe 363
4.6.18. Raportowanie i monitorowanie 364
4.6.19. Administracja systemem 364
4.6.20. Bezpieczeństwo 366
4.7. #28# System obsługi zamówień publicznych 367
4.8. #28# System obsługi rady gminy 371
4.9. #34# Serwery (2 szt.) 379
4.10. #35# Macierz NAS (1 szt.) 381
4.11. #37# Oprogramowanie monitorujące 381
4.12. #35# Urządzenie UTM (1 szt.) 382
Część 1K. Wdrożenie nowych systemów informatycznych z uruchomieniem e-usług w powiecie
krasnostawskim 388
5.1. #39# System do planowania i zarządzania budżetem 388
5.2. #40# Uruchomienie e-usług budżetowych 412
5.3. #39# Modernizacja systemu EZD 413
5.4. #40# Opracowanie procedur dla e-usług, dostosowanie lub wykonanie formularzy,
oprogramowanie procesów w EZD 442
5.5. #39# System obsługi zamówień publicznych 443
5.6. #39# System obsługi rady powiatu 448
5.7. #44# Urządzenie UTM (1 szt.) 458
5.8. #44# Macierz NAS (1 szt.) 463
5.9. #44# Switch 1Gbit (3 szt.) 464
5.10. #44# Macierz dyskowa (1 szt.) 465
5.11. #43# Serwer (2 szt.) 466
5.12. #46# Serwerowy system operacyjny - licencje serwerowe (3 szt.) 468
5.13. #46# Serwerowy system operacyjny - licencje dostępowe (59 szt.) 469
5.14. #46# Oprogramowanie do wirtualizacji (1 szt.) 469
5.15. #46# Oprogramowanie do backupu na potrzeby wirtualizacji (2 szt.) 471
5.16. #46# Oprogramowanie monitorujące 474
W celu wspólnej realizacji projektu „Modernizacja i rozbudowa systemów informatycznych
samorządów województwa lubelskiego w celu podniesienia jakości usług publicznych” ustanowione zostało partnerstwo, które tworzą Fundacja Fundusz Lokalny im. Xxxx XXX Xxxxxxxxxxx (partner
wiodący) oraz partnerzy - samorządy województwa lubelskiego:
• Gmina Chełm,
• Gmina Łopiennik,
• Gmina Piaski,
• Gmina Ulan-Majorat,
• Powiat Krasnostawski.
Celem projektu jest podniesienie jakości świadczenia usług publicznych przez ww. jednostki
realizujące projekt poprzez udostępnienie nowych e-usług i informatyzację procedur wewnętrznych. W ramach projektu przewiduje się m. in. modernizację i rozbudowę systemów teleinformatycznych poszczególnych jednostek, w tym:
1. Modernizację i rozbudowę systemów dziedzinowych,
2. Dostosowanie i wdrożenie formularzy na ePUAP dla planowanych e-usług ,
3. Integrację systemów dziedzinowych z systemami elektronicznego obiegu dokumentów (EZD),
4. Zaprogramowanie procesów związanych z e-usługami w EZD,
5. Modernizację i rozbudowę EZD - w tym integrację z ePUAP,
6. Uruchomienie portalu e-należności dla każdej z jednostek,
7. Zakup i wdrożenie systemu do planowania i zarządzania budżetem (w wybranych
jednostkach),
8. Zakup i wdrożenie systemu do obsługi rady gminy/powiatu(w wybranych jednostkach),
9. niezbędną dla realizacji ww. zadań modernizację infrastruktury sprzętowej i sieciowej i zapewnienie bezpieczeństwa teleinformatycznego w poszczególnych jednostkach.
Dzięki realizacji zadań, zostaną uruchomione e-usługi 3, 4 i 5 poziomu (stopniu) dojrzałości.
Przewiduje się osiągnięcie ponad 10 tys. uruchomień e-usług w ciągu roku od zakończenia realizacji
projektu.
Projekt skierowany jest do mieszkańców woj. lubelskiego – interesantów jednostek samorządu
terytorialnego realizujących projekt oraz ich kierownictw i pracowników.
Wykonawca musi mieć na uwadze cele projektu i wycena powinna uwzględniać przedmiot zamówienia jako system powiązanych elementów mających umożliwić zamawiającemu realizację ww. celów.
Wymagania ogólne dla przedmiotu zamówienia
Niniejsze wymagania obowiązują dla każdej części zamówienia i w obrębie danej części.
1. Dostarczane w ramach Zamówienia rozwiązania muszą:
a. mieć możliwość wymiany danych z innymi systemami teleinformatycznymi za pomocą protokołów komunikacyjnych i szyfrujących,
b. umożliwiać integrację z innymi systemami za pomocą usług WebService wykorzystujących protokół SOAP lub w formie pliku xml,
c. wszystkie interfejsy zewnętrzne dostarczanych systemów, jeżeli to możliwe, będą oparte na standardowych rozwiązaniach - w obszarach stosowalności standardów wymienionych w
Rozporządzeniu w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych
wymagań dla systemów teleinformatycznych (Dz. U. z 2012r., poz. 526), a w pozostałych obszarach będą stosowane powszechnie stosowane standardy (w szczególności standardy otwarte); w żadnym wypadku nie mogą być stosowane specyfikacje, których publikacja,
wykorzystanie, implementacja, rozszerzanie/adaptacja podlega ograniczeniom związanym z prawami autorskimi lub pokrewnymi,
d. jeżeli oprogramowanie dostarczone/wytworzone przez Wykonawcę będzie posiadać strukturę modułową, realizującą poszczególne grupy funkcjonalności za pomocą
autonomicznych komponentów, funkcja integracji tych komponentów musi być realizowana za pośrednictwem zestandaryzowanych interfejsów zgodnie z Rozporządzeniem Rady
Ministrów z dnia 12 kwietnia 2012 w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych,
e. w przypadku rozwiązań front-office: wykorzystywać mechanizmy dostępne w aplikacjach centralnych, w tym w celu identyfikacji użytkowników mechanizmy SSO (Single Sign-On) udostępnione na platformie ePUAP,
f. umożliwiać udostępnienie zasobów informacyjnych (w stosownym zakresie) co najmniej w jednym z formatów wymienionych w Załączniku nr 2 Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności,
g. zawierać mechanizmy / narzędzia, które umożliwią Zamawiającemu monitorowanie
i raportowanie wskaźników projektu:
• pobrań/uruchomień aplikacji opartych na ponownym wykorzystaniu informacji sektora publicznego i e-usług publicznych,
• liczby pobrań/odtworzeń dokumentów zawierających informacje sektora publicznego,
h. zawierać mechanizmy / narzędzia, które umożliwią Zamawiającemu monitorowanie udostępnianych w ramach projektu e-usług pod kątem dostępności, użyteczności i
intuicyjności graficznych interfejsów dla wszystkich interesariuszy, ciągłości działania i
powszechności wykorzystania,
i. w przypadku rozwiązań front-office: uwzględniać możliwości i potrzeby osób
niepełnosprawnych, w tym postanowienia WCAG 2.0 (z uwzględnieniem poziomu AA) tj. wytycznych dotyczących dostępności treści internetowych zgodnie z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych 4/102 i wymiany informacji w postaci
elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. 2012r.,
poz. 526),
j. w przypadku systemów przetwarzających dane osobowe: uwzględniać wymagania
wynikające z Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 29
kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy
informatyczne służące do przetwarzania danych osobowych. W szczególności dostarczone rozwiązania muszą umożliwiać:
i. Określenie daty pierwszego wprowadzenia danych do systemu. Każde wejście do systemu musi być logowane, login użytkownika jest zapisywany w przypadku
wprowadzenia danych osobowych i danych finansowych, jak również ich modyfikacji. Razem z loginem zapisywana będzie data wprowadzenia z dokładnością do sekundy.
ii. Odnotowanie identyfikatora użytkownika wprowadzającego dane osobowe do systemu. Każde wejście do systemu będzie logowane, login użytkownika jest zapisywany w przypadku wprowadzenia danych osobowych i danych finansowych jak i ich modyfikacji.
iii. Odnotowanie informacji o odbiorcach w rozumieniu art. 4 pkt 9 Ogólnego rozporządzenia o ochronie danych (RODO) , którym dane osobowe zostały
udostępnione, dacie i zakresie tego udostępnienia. Dane te będą odnotowywane zarówno na poziomie danej osoby fizycznej lub prawnej, której dane zostały udostępnione z zapisem w jakim zakresie, komu i w jakim celu oraz z uwzględnieniem operatora udostępniającego dane i czasu udostępnienia a także poprzez wykonanie
rejestru udostępnień.
iv. W zakresie wymagań określonych w § 7 ust. 2 ww. rozporządzenia zostaną spełnione wymagania poprzez: (a) odnotowanie informacji, o których mowa w pkt i. i ii., w sposób automatyczny po zatwierdzeniu przez użytkownika operacji wprowadzenia danych oraz (b) zapewnienie dla każdej osoby, której dane osobowe są przetwarzane w systemie informatycznym, sporządzenia i wydrukowania raportu zawierającego w powszechnie zrozumiałej formie informacji, o których mowa w pkt iii.
v. W każdym z elementów Systemu przeznaczonych dla użytkowników wewnętrznych (pracowników jednostki Zamawiającego) będą stosowane metody i środki uwierzytelnienia oraz procedury związane z ich zarządzaniem i użytkowaniem:
• każdy z użytkowników loguje się do programu używając swojej nazwy oraz hasła
lub PKI,
• każdorazowo hasło jest weryfikowane w systemie,
• po wykorzystaniu maksymalnej ilości prób wprowadzania nieprawidłowego hasła nastąpi blokada konta zgodnie z zasadami wykorzystywanymi na platformie e- PUAP,
• przed okresem podanego czasu ważności hasła użytkownicy są o tym informowani i mogą dokonać zmiany hasła.
2. Zamawiający wymaga aby wyspecyfikowane elementy zamówienia były ze sobą kompatybilne oraz stanowiły zintegrowaną całość, w szczególności wymagane jest, żeby:
a. Wnioski, deklaracje, informacje składane przez interesantów przy wykorzystaniu e-usług udostępnionych w ramach zamówienia były automatycznie rejestrowane w EZD, a następnie ich treść była zaczytywana przez odpowiednie systemy dziedzinowe (SD)
funkcjonujące w jednostce Zamawiającego (integracja z SD wymagana w zakresie
koniecznym dla realizacji e-usług planowanych do uruchomienia w ramach Zamówienia).
b. Decyzje i informacje podatkowe generowane przez SD były automatycznie rejestrowane w EZD, a EZD musi zapewnić możliwość wysyłki tych dokumentów przez ePUAP.
c. System e-należności musi pobierać z SD i prezentować informacje dotyczące interesanta, w szczególności związane z jego stanem zobowiązań wobec jednostek Xxxxxxxxxxxxx z tytułu podatków i opłat (w zakresie określonym w dalszej części niniejszego dokumentu).
d. System komunikacji elektronicznej ma zapewnić możliwość przesyłania spersonalizowanych komunikatów do interesantów urzędu generowanych na podstawie zdarzeń występujących w SD.
e. System EZD musi umożliwić zapis protokołów z posiedzeń rady oraz projektów uchwał
utworzonych w Systemie obsługi rady gminy/powiatu w formie dokumentu wewnętrznego
wraz z opisującymi go metadanymi.
3. Jeżeli więcej niż jeden z systemów wyspecyfikowanych w niniejszym OPZ przetwarza ten sam typ dokumentu, Wykonawca – o ile jest to możliwe i racjonalne - na etapie Analizy zaprojektuje, a potem wykona integrację systemów w sposób taki, aby dana informacja lub dokument były rejestrowane tylko raz, w jednym systemie i mogły być potem przetwarzane/procedowane w
innych systemach wchodzących w zakres zamówienia. W kolejnych systemach uzupełniane byłyby metadane dotyczące dokumentu, jeśli rejestry przewidziane dla danego dokumentu w różnych systemach zawierają różne zakresy metadanych.
Przykładowe dokumenty, informacje i rejestry, których dotyczy powyższe wymaganie to: faktury i umowy (rejestrowane i przetwarzane w systemach: EZD, SD, planowania i zarządzania
budżetem), dane interesanta/kontrahenta (rejestrowane i przetwarzane w systemach: EZD, SD, planowania i zarządzania budżetem), rejestr zamówień publicznych (rejestrowany i przetwarzany w systemach: obsługi zamówień publicznych, planowania i zarządzania budżetem). Powyższe zdanie ma charakter przykładu i nie stanowi listy zamkniętej.
4. Wymagania zawarte w dalszej części OPZ, jednoznacznie określające sposoby współpracy systemów, jeśli takie sposoby wskazano, mają pierwszeństwo przed wymaganiem ust. 3.
5. Dostarczone rozwiązania muszą:
a. działać w dowolnej sieci komputerowej TCP/IP,
b. być poprawnie obsługiwane z dowolnego komputera, na którym zainstalowany jest system Windows lub Linux, z wykorzystaniem popularnych przeglądarek internetowych –
wymagana obsługa przez co najmniej trzy spośród wymienionych przeglądarek: Google Chrome, Mozilla Firefox, Opera, Internet Explorer, Microsoft Edge w wersjach aktualnych (wspieranych przez producentów) na dzień składania oferty lub nowszych (wymaganie dotyczy Oprogramowania Aplikacyjnego; obsługa przez przeglądarkę internetową nie jest wymagana w stosunku do systemów dziedzinowych),
c. umożliwiać pracę jedno i wielostanowiskową oraz zapewniać jednokrotne wprowadzanie danych tak, aby były one widoczne dla wszystkich użytkowników,
d. umożliwiać wykorzystanie bezpiecznego protokołu komunikacji pomiędzy stacją roboczą a serwerem, na którym są zainstalowane, w celu zabezpieczenia poufności danych (w zakresie właściwym dla poszczególnych systemów).
e. Dla zastosowań, o których mowa w punkcie powyżej, Wykonawca dostarczy certyfikaty SSL klasy co najmniej DV (Domain Validation) i zapewni ich ważność co najmniej na okres zaoferowanej gwarancji na Oprogramowanie Aplikacyjne.
6. Dokumentacja użytkownika Oprogramowania Aplikacyjnego musi:
a. zawierać opis funkcji programu, wyjaśniać zasady pracy z programem, oraz zawierać opisy przykładowych scenariuszy pracy,
b. być dostępna z poziomu oprogramowania w postaci elektronicznej (pliki PDF lub DOC lub
RTF).
7. Zamówienie obejmuje dostawę infrastruktury sprzętowo - systemowej dla dostarczanego i
wdrażanego przez Wykonawcę oprogramowania, w zakresie odpowiednim dla każdej części Zamówienia. Wykonawca zaoferuje i dostarczy sprzęt o parametrach zapewniających wydajną, stabilną i bezpieczną eksploatację oprogramowania będącego przedmiotem zamówienia, w
rodzaju i ilości nie mniejszej niż określona w dalszej części niniejszego dokumentu i o
parametrach technicznych równych bądź wyższych niż wymagania minimalne określone w dalszej
części niniejszego dokumentu. W szczególności Zamawiający wymaga aby:
a. Całość dostarczanego sprzętu informatycznego była kompatybilna z wdrażanymi w ramach zamówienia systemami informatycznymi oraz ze wszystkimi aplikacjami niezbędnymi do ich uruchomienia.
b. Wykonawca zainstalował wymagane oraz wyspecyfikowane przez Zamawiającego aplikacje niezbędne do działania wdrażanych systemów informatycznych na dostarczanym przez siebie sprzęcie informatycznym.
c. Wykonawca skonfigurował w sposób optymalny, bezpieczny i wydajny środowisko pracy dla wdrażanych systemów informatycznych na dostarczanym przez siebie sprzęcie informatycznym.
d. Wykonawca jest zobowiązany do uwzględnienia w cenie oferty i dostarczenia listw zasilających i kabli umożliwiających zainstalowanie i uruchomienie infrastruktury sprzętowo
– systemowej będącej przedmiotem zamówienia. Powyższe nie obejmuje modyfikacji
okablowania strukturalnego i sieci elektrycznej.
e. Rodzaj Oprogramowania Wspomagającego - w szczególności zarządzającego (w tym systemy operacyjne) i bazodanowego - był dostosowany do wymagań dostarczanych przez Wykonawcę wdrażanych systemów informatycznych przy zachowaniu parametrów
minimalnych określonych w niniejszym załączniku oraz umożliwiał zgodne z ich licencją
wykorzystanie podzespołów sprzętowych (np. procesory) dostarczanego przez Wykonawcę sprzętu informatycznego.
f. Wykonawca skonfigurował dostarczone przez siebie urządzenia sieciowe (switche, urządzenia UTM) w sposób umożliwiający prawidłowe wykorzystanie dostarczanych
systemów informatycznych, w szczególności – świadczenie planowanych do uruchomienia
e-usług.
g. Wykonawca opracował procedury tworzenia kopii zapasowych danych przetwarzanych przez Oprogramowanie Aplikacyjne będące przedmiotem zamówienia oraz wdrożył je z wykorzystaniem dostarczanej infrastruktury sprzętowo – systemowej.
h. Wykonawca skoordynował proces dostaw sprzętu informatycznego, jego instalacji, a następnie wdrożeń systemów informatycznych dostarczanych w taki sposób, by był on racjonalny, efektywny i możliwy do realizacji zgodnie z harmonogramem realizacji zamówienia.
8. Wykonawca udzieli gwarancji na System, w tym na Oprogramowanie Aplikacyjne, na okres
wskazany w ofercie. Minimalny wymagany przez Zamawiającego okres gwarancji na System, w tym na Oprogramowanie Aplikacyjne wynosi 60 miesięcy.
W niniejszym dokumencie stosuje się pojęcia zdefiniowane w Załączniku nr 7 do SIWZ – Wzór
umowy.
Wymagania ogólne dla wdrożeń Oprogramowania Aplikacyjnego
Wdrożenie oprogramowania back-office (systemy dziedzinowe, broker integracyjny, system EZD, system do planowania i zarządzania budżetem, system obsługi zamówień publicznych w zakresie dostępnym dla użytkowników wewnętrznych, system obsługi rady gminy/powiatu) obejmie:
1. Instalację na sprzęcie serwerowym będącym przedmiotem zamówienia wraz z konfiguracją i optymalizacją dostarczanego oprogramowania i oferowanej bazy danych. W ramach
wdrożenia oferowane oprogramowanie zostanie zainstalowane i skonfigurowane na ww. sprzęcie oraz – w przypadku systemów desktop (dotyczy systemów dziedzinowych) - także na wskazanych przez zamawiającego stacjach roboczych. W przypadku oprogramowania
będącego przedmiotem modernizacji i/lub rozbudowy i/lub integracji analogicznie wymaga
się przeniesienia tych systemów na infrastrukturę sprzętowo – systemową będącą przedmiotem zamówienia.
2. Instruktaże oraz asystę stanowiskową dla użytkowników i administratorów systemu polegającą na:
a. przeprowadzeniu instruktażu obsługi całego systemu bądź jego części
wspomagającego obsługę obszarów działalności urzędu dla wskazanych przez urząd pracowników;
b. przeprowadzeniu we współpracy z każdym wskazanym przez urząd pracownikiem analizy stanowiskowej zadań realizowanych w systemie charakterystycznych dla konkretnych merytorycznych stanowisk pracowniczych;
c. przeprowadzeniu instruktażu w zakresie zarządzania użytkownikami i uprawnieniami, zabezpieczania i odtwarzania danych systemu dla osób pełniących obowiązki
administratorów systemu wskazanych przez urząd;
d. przeprowadzeniu instruktażu dla administratorów w zakresie administracji
i konfiguracji systemu bazodanowego obejmujące 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.
3. Przeprowadzenie testów penetracyjnych systemu polegających na:
a. przeprowadzeniu testów przeprowadzonych ze stacji roboczej podłączonej do systemu informatycznego z zewnątrz (poprzez urządzenie łączące system
informatyczny), mających na celu zidentyfikowanie możliwości przeprowadzenia włamania z zewnątrz;
b. badaniu luk dostarczanych systemów informatycznych;
c. identyfikację podatności systemów i sieci na ataki typu: DoS, DDoS, Sniffing, Spoffing,
XSS, Hijacking, Backdoor, Flooding, Password, Guessing;
d. sporządzeniu raportu zawierającego minimum: opis stanu faktycznego bezpieczeństwa wdrażanego systemu informatycznego, opis wyników
przeprowadzonych testów, rekomendacje dla przyszłych działań związanych
z użytkowaniem wdrażanego systemu w kontekście bezpieczeństwa systemu.
Wdrożenie systemów front-office (system e-należności, system obsługi zamówień publicznych w zakresie dostępnym dla użytkowników zewnętrznych) obejmie:
1. Instalację i konfigurację rozwiązań na infrastrukturze sprzętowo – systemowej zapewnionej przez
Wykonawcę. Wykonawca zapewni wysoką dostępność tej infrastruktury w okresie gwarancji.
Parametry infrastruktury zapewnionej przez Wykonawcę muszą umożliwić stabilne, wydajne i
bezpieczne korzystanie przez interesantów jednostki Zamawiającego z udostępnionych w efekcie realizacji Zamówienia e-usług. W szczególności wydajność i dostępność infrastruktury musi stworzyć możliwość techniczną osiągnięcia wskaźników rezultatu zaplanowanych w Projekcie dla jednostki Zamawiającego.
2. Publikację aplikacji do mobilnego dostępu na ogólnodostępnych platformach do ich pobierania dla wszystkich systemów operacyjnych na których mają być one dostępne.
3. W przypadku usług płatności wykonawca zintegruje system e-należności z systemem płatności wybranym przez Zamawiającego na podstawie możliwych rozwiązań oferowanych przez
Wykonawcę (minimum dwa systemy płatnościowe spełniające wymogi określone dla systemu e- należności).
4. Instruktaże oraz asystę stanowiskową dla użytkowników i administratora systemu polegająca na:
a. przeprowadzeniu instruktażu obsługi całego systemu bądź jego części wspomagającego obsługę obszarów działalności urzędu dla wskazanych przez urząd pracowników;
b. przeprowadzeniu we współpracy z każdym wskazanym przez urząd pracownikiem analizy stanowiskowej zadań realizowanych w systemie charakterystycznych dla konkretnych merytorycznych stanowisk pracowniczych;
c. przeprowadzeniu instruktażu w zakresie zarządzania użytkownikami i uprawnieniami, zabezpieczania i odtwarzania danych systemu dla osób pełniących obowiązki
administratorów systemu wskazanych przez urząd.
5. Przeprowadzenie testów penetracyjnych systemu polegających na:
a. przeprowadzeniu testów przeprowadzonych ze stacji roboczej podłączonej do systemu
informatycznego z zewnątrz (poprzez urządzenie łączące system informatyczny), mających na celu zidentyfikowanie możliwości przeprowadzenia włamania z zewnątrz;
b. badaniu luk dostarczanych systemów informatycznych;
c. identyfikację podatności systemów i sieci na ataki typu: DoS, DDoS, Sniffing, Spoffing, XSS,
Hijacking, Backdoor, Flooding, Password, Guessing;
d. sporządzeniu raportu zawierającego minimum: opis stanu faktycznego bezpieczeństwa wdrażanego systemu informatycznego, opis wyników przeprowadzonych testów,
rekomendacje dla przyszłych działań związanych z użytkowaniem wdrażanego systemu w kontekście bezpieczeństwa systemu.
6. Opracowanie wzorów regulaminów świadczenia usług dla mieszkańców oraz odpowiednich dla
nich instrukcji korzystania z oferowanych e-usług.
Oferowane przez Wykonawcę rozwiązania muszą być na dzień odbioru zgodne z aktami prawnymi regulującymi pracę urzędów administracji publicznej oraz usług urzędowych realizowanych drogą elektroniczną. Oferowane rozwiązania muszą być zgodne w szczególności z następującymi przepisami:
1. Rozporządzenie Prezesa Rady Ministrów z dnia 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz.U. 2011 r. Nr 14 poz. 67).
2. Ustawa z dnia 14 czerwca 1960 r. Kodeks postępowania administracyjnego (Dz.U. 2017r. poz. 1257 z późn. zm.).
3. Ustawa z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (Dz.U. 2018 poz. 217).
4. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r.
w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz.U. 2006 r. Nr 206
poz. 1517).
5. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r.
w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz.U. 2006 r. Nr 206 poz. 1518).
6. 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. 2006 r. Nr 206 poz. 1519).
7. Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych (Dz.U. 2018 poz. 1000).
8. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne
rozporządzenie o ochronie danych).
9. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w
sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i
organizacyjnych, jakim powinny odpowiadać urządzenia i Systemy informatyczne służące do
przetwarzania danych osobowych (Dz.U. 2004 r. Nr 100 poz. 1024).
10. Ustawa z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz.U. 2016 r. poz. 1167).
11. Ustawa z dnia 5 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej (Dz.U. 2016 poz. 1579).
12. Ustawa z dnia 6 września 2001 r. o dostępie do informacji publicznej (Dz.U. 2016 poz. 1764).
13. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 18 stycznia 2007 r. w
sprawie Biuletynu Informacji Publicznej (Dz.U. 2007 r. Nr 10 poz. 68).
14. Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 910/2014 z dnia 23 lipca 2014 r. w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji
elektronicznych na rynku wewnętrznym oraz uchylające dyrektywę 1999/93/WE.
15. Rozporządzenie Ministra Cyfryzacji z dnia 5 października 2016 r. w sprawie profilu zaufanego elektronicznej platformy usług administracji publicznej (Dz.U. 2016 poz. 1633).
16. Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną ( Dz.U. 2017 poz. 1219).
17. Ustawa z dnia 17 lutego 2005 r. o informatyzacji podmiotów realizujących zadania publiczne
(Dz.U. 2017 poz. 570).
18. Rozporządzenie Rady Ministrów z dnia 6 października 2016 r. zmieniające rozporządzenie
w sprawie sposobu, zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym
(Dz.U. 2016 poz. 1634 z późn. zm.).
19. Ustawa z dnia 10 stycznia 2014 r. o zmianie ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne oraz niektórych innych ustaw (Dz. U. 2014 poz. 183).
20. Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram
Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2017, poz. 2247).
21. Rozporządzenie Prezesa Rady Ministrów z dnia 8 maja 2014 r. zmieniające rozporządzenie
w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (Dz.U. 2014 poz. 590).
22. Rozporządzenie Ministra Administracji i Cyfryzacji w sprawie wzoru i sposobu prowadzenia
metryki sprawy z dnia 6 marca 2012 r. (Dz.U. z 2012 r. poz. 250). lub innymi, które zastąpią ww. w dniu wdrożenia rozwiązania.
23. Ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz.U. 2017 poz. 2077).
24. Ustawa z dnia 21 lutego 2014 r. o funduszu sołeckim (Dz.U. 2014 poz. 301).
Ogólne wymogi związane z dostępnością treści
Wszystkie rozwiązania wdrażane w ramach projektu w tzw. części publicznej (tzn. udostępnionej poprzez sieć Internet mieszkańcom - użytkownikom niebędącym pracownikami jednostek organizacyjnych partnerów projektu) muszą spełniać wymagania standardu WCAG 2.0 w
przedmiotowym zakresie wynikające z Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w
sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i
wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych, a w szczególności:
1. W zakresie zasady postrzegania:
a. wykorzystanie technik, dzięki którym wszelkie elementy nietekstowe, umieszczone na stronie
internetowej, takie jak: zdjęcia, obrazki ozdobne, ikony, wykresy, animacje itp. będą
przetworzone przez oprogramowanie użytkownika i dostarczą komplet informacji, jakie ze sobą niosą;
b. dla wszystkich nagranych (nietransmitowanych na żywo) materiałów dźwiękowych i wideo, publikowanych na stronie, takich jak np. podcasty dźwiękowe, pliki mp3, itd. zapewniona zostanie transkrypcja opisowa nagranego dźwięku;
c. dla materiałów wideo (nietransmitowanych na żywo), które nie zawierają ścieżki dźwiękowej zapewniony zostanie opis tekstowy lub dźwiękowy, aby użytkownicy niewidomi także mieli dostęp do prezentowanej informacji;
d. wszystkie opublikowane na stronie materiały wideo (nietransmitowane na żywo) udostępnione na stronie (np. wideo) będą posiadać napisy, które przedstawiają nie tylko dialogi, ale prezentują również ważne informacje dźwiękowe.
e. dla mediów zmiennych w czasie zapewniona będzie alternatywa, dla nagrań wideo
w multimediach zsynchronizowanych będzie zapewniona audiodeskrypcja;
f. zastosowanie znaczników semantycznych, skrótów klawiaturowych interpretowanych przez programy czytające do nawigacji po stronie internetowej;
g. opisanie stron internetowych w plikach CSS;
h. zastosowanie w kodzie HTML logicznej i intuicyjnej sekwencji nawigacji oraz czytania;
i. instrukcje i komunikaty nie będą zależeć od kształtu, lokalizacji wizualnej, miejsca, dźwięku;
j. kolor nie będzie używany jako jedyna metoda do przekazywania treści i rozróżniania elementów wizualnych;
k. zapewniony zostanie mechanizm, dzięki któremu użytkownik zatrzyma dźwięki, spauzuje, wyciszy lub zmieni głośność;
l. kontrast pomiędzy tekstem lub grafikami tekstowymi a tłem będzie w stosunku 4,5:1 oraz zostaną zapewnione kontrolki , które przełączą serwis w wysoki kontrast;
m. udostępnienie na stronie internetowej mechanizmu polegającego na stopniowym powiększaniu rozmiaru tekstu przy zachowaniu czytelności i funkcjonalności strony internetowej przy powiększeniu wartości do minimum 200 %;
n. zakaz używania grafiki do przedstawiania tekstu, jeśli ta sama prezentacja wizualna może być zaprezentowana jedynie przy użyciu tekstu.
2. W zakresie zasady funkcjonalności:
a. zapewnienie dostępu do każdej funkcjonalności przy użyciu skrótów klawiaturowych, które nie będą wchodzić w konflikt z istniejącymi w przeglądarce czy programie czytającym;
b. zapewnienie poruszania się po wszystkich elementach nawigacyjnych strony używając
jedynie klawiatury;
c. brak nakładanych limitów czasowych na wykonanie czynności na stronie;
d. zostanie zapewniony mechanizm pauzy, zatrzymania, ukrycia dla informacji, które są
automatycznie przesuwane, przewijane lub mrugające;
e. nie zostaną utworzone treści, które migają więcej niż 3 razy na sekundę;
f. zapewnienie, że pierwszą informacją „wyświetloną” przez przeglądarkę będzie menu służące do przechodzenia, bez przeładownia strony, do istotnych treści serwisu za pomocą kotwic;
g. określenie każdej podstrony serwisu internetowego przez unikalny i sensowny tytuł;
h. zapewnienie logicznej i intuicyjnej kolejności nawigacji po linkach, elementach formularzy
itp.;
i. określenie wszystkich elementów aktywnych, takich jak linki, przyciski formularza, czy obszary aktywne map odnośników z perspektywy swojego celu, bezpośrednio z linkowanego tekstu lub w pewnych przypadkach - z linku w swoim kontekście;
j. zapewnienie znalezienia innych stron w serwisie na wiele sposobów, tj. spis treści, mapa
xxxxxxx, wyszukiwarka;
k. zapewnienie jednoznacznego opisu nagłówków i etykiet;
l. zapewnienie, że nie będą dublowane nagłówki i etykiety;
m. zapewnienie widoczności zaznaczenia przy obsłudze strony internetowej z klawiatury.
3. W zakresie zasady zrozumiałości:
a. główny język strony oraz zmiana języka będzie określona za pomocą atrybutu lang i/lub
xml:lang w znaczniku HTML;
b. zapewnienie, że elementy zaznaczenia (focus) nie spowodują zmiany kontekstu na stronie;
c. zakaz automatycznego wysyłania formularzy, przeładowania strony itp.;
d. zakaz stosowania mechanizmów, które powodują przy zmianie ustawień jakiegokolwiek komponentu interfejsu użytkownika automatyczną zmianę kontekstu;
e. zapewnienie, że wszystkie mechanizmy nawigacji, które powtarzają się na podstronach, będą pojawiały się w tym samym względnym porządku za każdym razem, gdy będą ponownie
prezentowane i będą w spójny sposób identyfikowane;
f. zapewnienie, że informacja o błędzie będzie skuteczna, intuicyjna i przede wszystkim dostępna dla wszystkich użytkowników, bez względu na to, czy posiadają dysfunkcje czy nie oraz pozwoli użytkownikowi jednoznacznie na zidentyfikowanie błędu oraz na łatwe
rozwiązanie problemu i powtórne przesłanie danych z formularza;
g. zapewnienie, by w miejscach, w których konieczne będzie wprowadzanie informacji przez użytkownika zawierano czytelne etykiety oraz instrukcje;
h. zapewnienie, że po błędzie użytkownika przy wprowadzaniu danych, przedstawione zostaną użytkownikowi sugestie, które mogą rozwiązać problem;
i. zostaną zapewnione mechanizmy pozwalające na przywrócenie poprzednich danych,
weryfikacje lub potwierdzenie.
4. W zakresie zasady kompatybilności:
a. zostanie przeprowadzona weryfikacja kodu HTML i CSS pod kątem błędu przy wykorzystaniu walidatorów oraz poprawa strony internetowej, tak by była wolna od błędów i poprawna semantycznie.
b. zapewnienie, że wszystkie komponenty interfejsu użytkownika, stworzone w takich
technologiach, jak np. flash, silverlight, pdf, które mają wbudowane mechanizmy wspierania dostępności, będą jednoznacznie identyfikowane poprzez nadanie im nazw, etykiet, przeznaczenia.
5. Zamawiający wymaga by wszystkie dostarczane systemy informatyczne w części publicznej (opublikowane w sieci Internet) miały jeden, wspólny i spójny interfejs graficzny użytkownika. W szczególności systemy muszą spełniać minimum następujące wymogi łącznie:
a. Jedna, wspólna kolorystyka.
b. Spójny wygląd formularzy.
c. Podobne operacje muszą być realizowane w ten sam sposób.
d. Informacje zwrotne muszą być prezentowane w ten sam sposób.
e. Polecenia systemu i menu muszą mieć ten sam format.
Ogólne wymogi w zakresie tworzenia formularzy ePUAP
1. Formularze stosowane na ePUAP powinny być tworzone z wykorzystaniem języka XForms oraz
XPath.
2. Wykonawca opracuje formularze elektroniczne (zgodnie z właściwymi przepisami prawa) na podstawie przekazanych przez Xxxxxxxxxxxxx kart usług z formularzami w formacie edytowalnym.
3. 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 edytowalnym.
4. Pola wskazane przez Xxxxxxxxxxxxx jako pola obowiązkowe w formularzach w formacie
edytowalnym, musza zostać polami obowiązkowymi również w formularzach elektronicznych.
5. Układ graficzny wszystkich formularzy powinien być w miarę możliwości jednolity.
6. Wizualizacja formularzy elektronicznych nie musi być identyczna ze wzorem w formacie
edytowalnym, ale musi zawierać dane w układzie niepozostawiającym wątpliwości co do treści
i kontekstu zapisanych informacji, w sposób zgodny ze wzorem.
7. Przygotowując formularze Wykonawca musi dążyć do maksymalnego wykorzystania słowników.
8. W budowanych formularzach należy wykorzystać mechanizm automatycznego pobierania
danych z profilu zaufanego – celem uzupełnienia danych o wnioskodawcy.
9. Formularze muszą zapewniać walidację wprowadzonych danych po stronie klienta i serwera zgodnie z walidacją zawartą w schemacie dokumentu.
10. Jeśli w formularzu elektronicznym występują pola PESEL, REGON lub kod pocztowy, to pola te
muszą być walidowane pod kątem poprawności danych wprowadzanych przez wnioskodawcę.
11. Każdy opracowany przez Wykonawcę formularz (w postaci pliku XML) musi zostać przekazany Zamawiającemu na okres 7 dni roboczych w celu dokonania sprawdzenia i wykonania testów na formularzu.
12. Po okresie testów, o których mowa w wymaganiu poprzednim, Zamawiający przekaże Wykonawcy ewentualne poprawki i uwagi dotyczące poszczególnych formularzy, które Wykonawca usunie w ciągu 7 dni.
13. Wykonawca przygotuje wzory dokumentów elektronicznych zgodnie ze standardem ePUAP
w formacie XML zgodnym z formatem Centralnego Repozytorium Wzorów Dokumentów.
14. Zamawiający dopuszcza możliwość wykorzystania przez Wykonawcę wzorów, które są już opublikowane w CRWD po akceptacji Zamawiającego.
15. Wygenerowane dla poszczególnych formularzy wzory dokumentów elektronicznych, składające
się z plików:
a. Wyróżnik (wyroznik.xml)
b. Schemat (schemat.xml)
c. Wizualizacja (styl.xsl)
muszą zostać dostosowane do wymogów formatu dokumentów publikowanych w CRWD i spełniać założenia interoperacyjności.
16. 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 CRWD.
17. Wykonawca udzieli wsparcia Zamawiającemu w przejściu procesu publikacji na ePUAP.
18. Bazując na przygotowanych wzorach dokumentów elektronicznych oraz opracowanych na platformie ePUAP formularzach elektronicznych Wykonawca przygotuje instalacje aplikacji w środowisku ePUAP.
19. Aplikacje muszą być zgodne z architekturą biznesową ePUAP oraz architekturą systemu
informatycznego ePUAP.
20. Przygotowane aplikacje muszą zostać zainstalowane przez Wykonawcę na koncie ePUAP Zamawiającego.
21. Zainstalowane aplikacje muszą spełniać wymogi ePUAP oraz pozytywnie przechodzić przeprowadzone na ePUAP walidacje zgodności ze wzorami dokumentów.
22. Na czas realizacji projektu Zamawiający zapewni Wykonawcy dostęp do części administracyjnej platformy ePUAP konta JST z uprawnieniami do konsoli administracyjnej Draco, ŚBA i usług.
23. W przypadku zwłoki w publikacji wzorów dokumentów CRWD realizowanej przez Ministerstwo
Cyfryzacji (administrator ePUAP) dopuszcza się dokonanie odbioru tej części zamówienia w
ramach lokalnej publikacji w CRWD z zastrzeżeniem, że Wykonawca dokona przekonfigurowania aplikacji po pomyślnej publikacji CRWD przez Ministerstwo Cyfryzacji.
24. Zamawiający przekaże Wykonawcy opisy usług w formacie edytowalnym.
25. Zamawiający dopuszcza, aby Wykonawca wykorzystał opis usług, które są umieszczone na platformie ePUAP po akceptacji opisu usługi przez Zamawiającego.
26. Zadaniem Wykonawcy jest odpowiednie powiązanie opisów usług zamieszczonych na ePUAP z odpowiednimi usługami.
27. 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.
28. 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.
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 sprzętu lub rozwiązań
równoważnych pod warunkiem, że zapewnią uzyskanie parametrów technicznych nie gorszych niż wymagane przez Zamawiającego w dokumentacji przetargowej. Zamawiający informuje, że w takiej sytuacji przedmiotowe zapisy są jedynie przykładowe i stanowią wskazanie dla Wykonawcy jakie
cechy powinny posiadać składniki użyte do realizacji przedmiotu zamówienia. Zamawiający zgodnie z art. 29 ust. 3 ustawy, dopuszcza oferowanie materiałów lub urządzeń równoważnych. Materiały lub urządzenia pochodzące od konkretnych producentów określają minimalne parametry jakościowe i cechy użytkowe, a także jakościowe (x.xx.: wymiary, skład, zastosowany materiał, kolor, odcień,
przeznaczenie materiałów i urządzeń, estetyka itp.) jakim muszą odpowiadać materiały lub urządzenia oferowane przez Wykonawcę, aby zostały spełnione wymagania stawiane przez Zamawiającego. Operowanie przykładowymi nazwami producenta ma jedynie na celu
doprecyzowanie poziomu oczekiwań Zamawiającego w stosunku do określonego rozwiązania.
Posługiwanie się nazwami producentów/produktów ma wyłącznie charakter przykładowy. Zamawiający, wskazując oznaczenie konkretnego producenta (dostawcy), konkretny produkt lub materiały przy opisie przedmiotu zamówienia, dopuszcza jednocześnie produkty równoważne o parametrach jakościowych i cechach użytkowych co najmniej na poziomie parametrów wskazanego produktu, uznając tym samym każdy produkt o wskazanych lub lepszych parametrach. 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 Zamawiającego, jest obowiązany wykazać, że oferowane przez niego dostawy spełniają wymagania określone przez Xxxxxxxxxxxxx. W takiej sytuacji Zamawiający wymaga złożenia stosownych dokumentów,
uwiarygodniających te rozwiązania.
Przedmiot zamówienia – kody CPV
• 48.00.00.00-8 Pakiety oprogramowania i systemy informatyczne
• 48.42.20.00-2 Zestawy pakietów oprogramowania
• 48.44.20.00-8 Pakiety oprogramowania do systemów finansowych
• 48.60.00.00-4 Pakiety oprogramowania dla baz danych i operacyjne
• 72.00.00.00-5 Usługi informatyczne: konsultacyjne, opracowywania oprogramowania, internetowe i wsparcia
• 72.21.10.00-7 Usługi programowania oprogramowania systemowego i dla użytkownika
• 72.26.30.00-6 Usługi wdrażania oprogramowania
• 72.25.32.00-5 Usługi w zakresie wsparcia systemu
• 72.42.00.00-5 Usługi w zakresie rozwijania Internetu
• 48.82.00.00-2 Serwery
• 48.90.00.00-7 Różne pakiety oprogramowania i systemy komputerowe
• 30.23.30.00-1 Urządzenia do przechowywania i odczytu danych
1.1. #01# Modernizacja systemów dziedzinowych z uruchomieniem dedykowanego
portalu e-należności
W ramach zamówienia wykonawca:
• zrealizuje rozbudowę i modernizację systemów dziedzinowych w celu obsługi przez te systemy nowych procesów związanych z realizacją planowanych w ramach projektu e-usług,
• dostarczy i wdroży system informacji internetowej o stanie należności urzędu z tytułu podatków i opłat z możliwością dokonywania płatności elektronicznych (system „e- należności”).
Ww. systemy i usługi, łącznie z elementami zamówienia opisanymi w pozostałych rozdziałach
niniejszego dokumentu, muszą m. in. umożliwić Zamawiającemu świadczenie na rzecz mieszkańców
nw. e-usług na 4. lub wyższym poziomie dojrzałości:
• Rozłożenie należności na raty, odroczenie terminu, umorzenie zaległości, umorzenie odsetek;
• Obsługa podatku rolnego / Deklaracja na podatek rolny;
• Obsługa podatku leśnego /Deklaracja na podatek leśny;
• Obsługa podatku od nieruchomości / Deklaracja na podatek od nieruchomości;
• Informacja w sprawie podatku rolnego;
• Informacja w sprawie podatku leśnego;
• Informacja w sprawie podatku od nieruchomości;
• Zwrot podatku akcyzowego zawartego w cenie oleju napędowego wykorzystywanego do
produkcji rolnej;
• Obsługa podatku od środków transportowych / Deklaracja na podatek od środków
transportowych;
• Obsługa opłaty za gospodarowanie odpadami komunalnymi / Deklaracja o wysokości opłaty;
• Usługa e-należności.
1.1.1. Modernizacja systemów dziedzinowych
Wykonawca zrealizuje modernizację systemów dziedzinowych w celu obsługi przez te systemy nowych procesów związanych z realizacją planowanych w ramach projektu e-usług.
Zadanie może być zrealizowane poprzez dostawę i wdrożenie nowych systemów dziedzinowych lub poprzez rozbudowę i aktualizację wybranych systemów funkcjonujących w jednostce Zamawiającego (Urzędzie Gminy Chełm), w tym poprzez dostawę nowych modułów tj.:
• systemów obsługujących podatki i opłaty lokalne – firmy Usługi Informatyczne INFO-SYSTEM Roman i Xxxxxxx Xxxxxxx sp.j,
• systemu firmy ARISCO Sp. z o.o. obsługującym opłaty za gospodarowanie odpadami
komunalnymi,
• systemu obsługującego księgowość firmy "WIZARD" S.C. Xxxxxxxx Xxxxxxxx , Xxxxxxxx
Xxxxxxxx,
• systemu obsługującego ewidencję ludności - Centralny Ośrodek Informatyki.
Systemy dziedzinowe po modernizacji i rozbudowie muszą być oparte o jednolitą wspólną platformę bazodanową (bazę danych SQL).
Systemy dziedzinowe muszą posiadać budowę modułową oraz zapewniać pełną wymianę informacji pomiędzy poszczególnymi modułami systemu. Zamawiający nie narzuca sposobu podziału systemów dziedzinowych na moduły, czy ich liczby. Z punktu widzenia Zamawiającego istotnym jest spełnienie przez systemy dziedzinowe wszystkich wskazanych w dalszej części funkcjonalności.
Wdrożenie systemów obejmie co najmniej czynności wskazane w punkcie „Wymagania ogólne dla wdrożeń Oprogramowania Aplikacyjnego”.
Systemy dziedzinowe muszą po rozbudowie i modernizacji realizować co najmniej funkcje wyszczególnione poniżej.
Wspólna baza interesantów
System musi posiadać wspólną dla wszystkich modułów bazę interesantów, spełniającą następujące
wymagania funkcjonalne:
1. System musi umożliwiać rejestrację w odrębnych kartotekach osób fizycznych i organizacji (osoby pozostałe).
2. System musi pozwalać na wyszukiwanie osób/organizacji po niżej wymienionych kryteriach:
a. dla osób fizycznych: nazwisko, nazwisko, imię, nr XXXXX/NIP, danych adresowych
(miejscowość, ulica, numer budynku/lokalu);
b. dla organizacji pozostałych: nazwa/REGON/PESEL/NIP, , danych adresowych (miejscowość, ulica, numer budynku/lokalu), grupa kontrahencka.
3. System musi umożliwiać wprowadzanie osób/organizacji w zakresie podstawowych danych osobowych, adresowych oraz możliwość dokonywania zmian/poprawek na wprowadzonych danych.
4. Dla zarejestrowanej osoby (fizycznej/pozostałej) system musi umożliwiać wprowadzanie:
a. kilku różnych typów adresów,
b. konta bankowych, ze wskazaniem głównego konta w celu wystawiania przelewów,
c. danych dot. skrytki ePUAP,
d. rodzajów działalności.
5. System musi umożliwiać przechowywanie pełnej historii osób z uwzględnieniem kiedy, jakie dane były zmieniane i przez jakiego operatora.
6. Z poziomu kartoteki osób/organizacji moduł musi zawierać informacje o „pochodzeniu danego rekordu” – czy dana organizacja/osoba pochodzi np. z importu danych, z ewidencji ludności/podmiotów gospodarczych, czy została dopisana w aplikacji.
7. System musi posiadać funkcję administracyjną (dostępną tylko dla wybranych użytkowników) pozwalającą na sklejanie osób/organizacji w przypadkach gdy są kilkakrotnie wprowadzone do systemu z różnymi danymi lub pojawiły się w systemie z importu z systemów
zewnętrznych. Po scaleniu dane aktualne powinny być wyświetlane w systemach
dziedzinowych.
8. System musi posiadać możliwość odszukania osoby, która ma być doklejona do osoby głównej.
9. System musi umożliwiać tworzenie profili dla poszczególnych użytkowników aplikacji w zakresie dostępu do informacji znajdujących się w systemie dotyczących osób/organizacji – winna być możliwość - jeśli zaistnieje taka potrzeba – aby pewne informacje nie były dostępne dla danego użytkownika (np. dane kadrowe, finansowe, dane uzupełniające itp.).
10. System musi umożliwiać konfigurację pieczątki wykorzystywanej w korespondencji.
11. Moduł musi zawierać słowniki: krajów, miejscowości, ulic, imion, adresów, rodzajów
organizacji, typów dokumentów, klasyfikacji EKD/PKD, pozwalające dopisywać nowe dane i poprawiać uprzednio wprowadzone.
12. Moduł musi posiadać funkcję importu danych z TERYTU systemu zewnętrznego (import danych terytorialnych dotyczących nazw miejscowości, ulic, kodów pocztowych). Na podstawie zaimportowanych słowników uzupełnia się bazę adresową w Urzędzie.
13. Moduł musi posiadać funkcję importu danych z systemów zewnętrznych - Import SWDE – po
jego zastosowaniu następuje uzupełnienie bazy danymi dot. ewidencji gruntów i budynków.
14. Kartoteka interesantów systemów dziedzinowych musi być wspólna dla wszystkich modułów oferowanego systemu oraz powinna zawierać mechanizmy jej integracji (powiązań) z
kartoteką systemu EZD, w szczególności w zakresie aktualizacji danych oraz wprowadzania nowych podmiotów.
15. System musi współpracować z systemem e-należności oraz aplikacją mobilną za pośrednictwem serwisu komunikacyjnego w zakresie informacji danych ewidencyjnych podatników.
16. Komunikacja z systemem EZD odbywa się za pośrednictwem brokera integracyjnego z wykorzystaniem usługi Web Service.
17. System musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji.
Obsługa podatku rolnego, leśnego i od nieruchomości
1. System musi zapewnić ewidencjonowanie kart podatkowych z uwzględnieniem podziału na sołectwa/obręby podatkowe i stosować odpowiednią numerację uwzględniającą ten podział.
2. System musi rozdzielać ewidencję osób fizycznych i prawnych.
3. Użytkownik musi mieć możliwość wyszukania kart w zakresie sposobu opodatkowania (podatek rolny, leśny, od nieruchomości, łączne zobowiązanie zarówno dla osób fizycznych jak i prawnych).
4. System musi umożliwiać tworzenie podmiotów grupowych.
5. System powinien umożliwić prowadzenie ewidencji działek i musi uwzględniać możliwość wprowadzenia przy nich informacji o udziałach z uwzględnieniem historii zmian.
6. System musi umożliwiać wprowadzanie wielu adresów związanych z danym podatnikiem
(adres zamieszkania, korespondencyjny).
7. System musi posiadać możliwość wprowadzania zarówno ulg i zwolnień ustawowych jak i wprowadzonych uchwałą Rady Gminy.
8. System musi uwzględniać możliwość naliczania podatku rolnego wg. hektarów fizycznych i
przeliczeniowych. Zmiana sposobu opodatkowania w roku podatkowym powinna wymagać
m. in. wprowadzenia daty, od której ma nastąpić zmiana sposobu jego naliczania.
9. System w naliczaniu wymiaru podatku musi wyliczyć odpowiednie kwoty z uwzględnieniem podziału na poszczególne rodzaje zobowiązań (rolny, leśny i od nieruchomości) oraz raty z uwzględnieniem obowiązujących terminów płatności.
10. Naliczanie wymiaru powinno być dokonywane w trybie zbiorczym dla całości podatników lub wybranego sołectwa/obrębu podatkowego.
11. System musi umożliwiać naliczanie zmian w wysokości podatku i wydawanie stosownych
decyzji.
12. System musi umożliwiać drukowanie odpowiednich decyzji z uwzględnieniem wydruków
zbiorczych i dla pojedynczych kart.
13. System musi umożliwiać generowanie decyzji elektronicznych i wysyłanie ich przez ESP za pośrednictwem modułu integrującego do systemu EZD. Rejestracja w systemie EZD musi uwzględniać rejestracją sprawy zgodnie z konfiguracją systemu w zakresie jednolitego
rzeczowego wykazu, kartoteki kontrahentów, dat i typów.
14. System musi umożliwiać wczytywanie do systemu deklaracji i załączników złożonych przez podatnika za pomocą platformy ePUAP.
15. System musi posiadać funkcjonalność modyfikacji standardowych wzorów wydruków oraz możliwość wprowadzania nowych wzorów. Musi także uwzględniać możliwość tworzenia
wydruków w formacie RTF z uwzględnieniem automatycznego wypełniania wydruku danymi z programu. System musi umożliwiać generowanie wydruków na podstawie tych wzorców i zapisywanie ich w systemie obiegu dokumentów EZD w profilu użytkownika z
uwzględnieniem typów dokumentów w nim zdefiniowanych. W szczególności dotyczy to wydruku zaświadczeń wg wzorców opracowanych przez użytkownika.
16. System musi umożliwiać drukowanie zaświadczeń do pliku PDF i wysyłanie ich przez ESP za pośrednictwem modułu integrującego i systemu EZD.
17. System musi umożliwić wydawanie zaświadczeń z wielu kart na jednym wydruku. Użytkownik musi mieć możliwość oznaczenia kart, z których chce wydać zaświadczenie.
18. System musi posiadać rejestr wydanych zaświadczeń.
19. System musi umożliwiać wydruk blankietów dowodów wpłat, potwierdzeń odbioru decyzji z możliwością drukowania w/w dokumentów łącznie z decyzjami wymiarowymi. System musi umożliwiać drukowanie w/w dokumentów do pliku PDF i wysyłanie ich przez ESP za pośrednictwem modułu integrującego i systemu EZD.
20. System musi umożliwiać oznaczanie wydruków kodem kreskowym identyfikującym daną
kartę podatkową celu integracji z systemami bankowymi w zakresie obsługi indywidualnych rachunków bankowych dla płatności masowych.
21. Wszystkie dokonane wydruki decyzji wymiarowych i zmieniających wymiar muszą być
gromadzone na karcie podatnika. W każdym momencie użytkownik musi mieć możliwość podglądu i wydruku na nowo takiej decyzji.
22. System musi posiadać możliwość generowania wydruków wybranych pism (decyzji) do
formatu RTF z możliwością ich edycji i zapisu do karty podatnika i wysyłania ich przez ESP za pośrednictwem modułu integrującego i systemu EZD.
23. System musi umożliwiać prowadzenie (wydruk) rejestru wymiarowego oraz rejestru przypisów i odpisów. Wydruki te powinny mieć możliwość zapisu duplik atu rejestru
wymiarowego do pliku PDF oraz zapisanie go za pośrednictwem modułu integrującego w
systemie EZD.
24. System musi posiadać możliwość wielopłaszczyznowej analizy wprowadzanych danych i możliwość ich raportowania w postaci wydruków. W szczególności wymagane będą
zestawienia z uwzględnieniem podziału na sołectwa/okręgi podatkowe uwzględniające wysokość poszczególnych podatków, szczegółową analizę ulg i zwolnień oraz skutków obniżenia stawek w podatku rolnym i od nieruchomości. Zestawienia te muszą dawać też możliwość uzyskania informacji o łącznej ilości przedmiotów opodatkowania oraz o
wysokości podstawy ich wymiaru.
25. System musi umożliwiać przegląd historii właścicieli nieruchomości.
26. System musi uwzględniać możliwość wydruku indywidualnych numerów rachunków
bankowych na które będą dokonywać wpłaty podatnicy. System musi uwzględniać możliwość
dostosowania w/w rozwiązania do wymogów bankowych płatności masowych.
27. System musi dawać możliwość wydruku odpowiednich danych w postaci kodu kreskowego na blankiecie dowodu wpłaty z możliwością wprowadzenia w nim identyfikacji zobowiązania.
28. System musi współpracować z systemem informacji internetowej o stanie należności urzędu z tytułu podatków i opłat z możliwością dokonywania płatności elektronicznych (dalej: system „e-podatki”) oraz aplikacją mobilną za pośrednictwem serwisu komunikacyjnego w zakresie informacji dotyczących zobowiązań, danych ewidencyjnych kartoteki podatnika oraz podglądu dokumentów (decyzji, zaświadczeń) wystawianych przez system.
29. Komunikacja z systemem EZD odbywa się za pośrednictwem brokera integracyjnego z wykorzystaniem usługi Web Service.
30. System musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji.
Obsługa podatku od środków transportu
W zakresie obsługi podatku od środków transportu System musi spełniać następujące wymagania
funkcjonalne:
1. System musi posiadać możliwość wprowadzania danych pojazdów i dokonywania
zmian/poprawek (zgłoszenie wyrejestrowania, zmiana parametrów technicznych itp.) w
zakresie umożliwiającym prawidłowe naliczenie kwot podatku.
2. System musi umożliwiać obsługę słowników takich jak: słownik stawek podatków na poszczególne lata, słownik terminów płatności, rodzajów pojazdu).
3. System musi umożliwiać wyszukiwanie podatnika po minimum wymienionych kryteriach: nazwa/nazwisko, numer rejestracyjny pojazdu, numer karty kontowej podatnika.
4. System musi umożliwiać rejestrację decyzji uznaniowych (np. umorzenie odsetek lub ich części, odroczenie terminów płatności, rozłożenie płatności na raty).
5. System musi umożliwiać tworzenie raportów i zestawień w minimalnym zakresie zdefiniowanym poniżej:
a. Zestawienie wg typu pojazdu.
b. Zestawienie ubyłych podatników.
c. Zestawienie deklaracji.
d. Wykaz płatników podatku.
e. Zestawienie decyzji.
f. Zestawienie decyzji uznaniowych.
6. System musi umożliwiać rejestrowanie elektronicznych deklaracji DT-1 złożonych przez podatnika za pośrednictwem platformy ePUAP. Pobieranie i wczytywanie do systemu
deklaracji i załączników złożonych przez podatnika za pomocą platformy ePUAP dokonywane ma być bezpośrednio z systemu EZD za pośrednictwem mechanizmów integrujących z
uwzględnieniem odpowiednich typów dokumentów zdefiniowanych w systemie obiegu dokumentów.
7. System musi umożliwiać weryfikację błędnie wprowadzonych deklaracji i odesłanie zwrotnej elektronicznej informacji za pomocą systemu EZD poprzez ESP do podatnika na jego konto na platformie ePUAP.
8. System musi współpracować z systemem e-należności oraz aplikacją mobilną za
pośrednictwem serwisu komunikacyjnego w zakresie informacji dotyczących zobowiązań, danych ewidencyjnych pojazdów oraz podglądu dokumentów wystawianych przez system.
9. System musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji.
Obsługa ewidencji zwrotu podatku akcyzowego zawartego w paliwie
1. System musi w pełni realizować wymogi ustawy z dnia 10 marca 2006 o zwrocie podatku akcyzowego zawartego w cenie oleju napędowego wykorzystywanego do produkcji rolnej poprzez następujące funkcje:
2. Ewidencja wniosków o zwrot podatku akcyzowego wraz z załącznikami.
3. Kartoteka wniosków i decyzji.
4. System musi umożliwiać rejestrację wniosku poprzez wczytanie e-formularza wniosku
przesłanego z platformy ePUAP w formacie XML. Po wczytaniu wniosku system musi
wygenerować dokument potwierdzający prawidłowość i kompletność lub stosowne braki do jego uzupełnienia. Informacja ta poprzez moduł integrujący musi zostać przekazana do system EZD, a następnie po podpisaniu podpisem elektronicznym referenta wysłana do wnioskodawcy.
5. Wydanie (wydruk) decyzji musi umożliwiać jego rejestrację w repozytorium dokumentów systemu EZD za pośrednictwem modułów komunikacyjnych.
6. System musi zapewniać obsługę dwóch typów list: KASA lub BANK. Wnioskodawca podczas składania wniosku, decyduje o formie wypłaty: gotówka lub rachunek bankowy, jeżeli
wybierze gotówkę, wówczas naliczone pieniądze do zwrotu mogą być umieszczone wyłącznie na liście typu KASA, z drugiej strony, jeżeli wskaże rachunek bankowy, wówczas naliczone
pieniądze trafią na listę wypłat typu BANK.
7. Sprawozdawczość systemu musi umożliwiać generowanie wydruków: Wniosek o dotacje, Okresowe sprawozdanie, Roczne sprawozdanie, Okresowe rozliczenie, Roczne rozliczenie. System musi umożliwiać drukowanie duplikatów ww. dokumentów do pliku PDF i ich zapis w systemie EZD za pośrednictwem modułu integrującego.
8. System musi zapewniać kontrole powierzchni gruntów na podstawie ewidencji podatkowej. Ze względu na to, że dane z wniosków należy porównać z ewidencją gruntów, musi istnieć możliwość weryfikacji danych o gruntach z modułu podatkowego lub innego rejestru
zawierającego dane EGIB.
Obsługa opłat za gospodarowanie odpadami komunalnymi
1. System w zakresie obsługi opłat za gospodarowanie odpadami komunalnymi musi umożliwiać prowadzenie szczegółowej ewidencji płatników.
2. System musi dokonywać okresowych rozliczeń należności z tytułu wywozu nieczystości.
3. System musi posiadać wszystkie funkcje związane z naliczaniem opłat, podziałem na raty i przypisaniem należności w systemie (w module księgowym).
4. System musi mieć możliwość edycji formy i treści informacji o wysokości opłaty oraz decyzji ustalającej wysokość opłaty.
5. System musi mieć możliwość wydruku informacji o wysokości opłaty lub decyzji ustalającej jej wysokość oraz pozostałych pism generowanych w module i przekazanie ich do systemu EZD za pośrednictwem modułu (brokera) integrującego.
6. System musi umożliwiać wczytywanie do systemu deklaracji i załączników złożonych przez podatnika za pomocą platformy ePUAP pobranych z systemu EZD za pośrednictwem modułu (brokera) integrującego z uwzględnieniem typów dokumentów funkcjonujących w systemie obiegu dokumentów. Dane z deklaracji elektronicznej powinny zostać automatycznie
przepisane do systemu dziedzinowego. System powinien umożliwić wprowadzanie zarówno
nowych deklaracji jak i rejestracje korekty zeznania.
7. System musi zapewniać wyszukiwanie podatników wg nazwiska lub numeru karty oraz adresu podatnika i posesji z której odbierane są odpady.
8. System musi generować wydruki na drukarkę, na ekran lub do pliku PDF.
9. System musi umożliwić drukowanie i obsługę kodów kreskowych w oparciu o druk
termotransferowy umożliwiających znakowanie odpadów i otrzymanie zwrotnej informacji dotyczącej daty dokonania wywozu, numeru kodu kreskowego, rodzaju odpadu.
10. System musi zapewnić integrację z systemami bankowymi w zakresie płatności masowych.
11. System musi współpracować z systemem e-należności oraz aplikacją mobilną za
pośrednictwem serwisu komunikacyjnego w zakresie informacji dotyczących zobowiązań,
danych ewidencyjnych kartoteki podatnika.
12. Komunikacja z systemem EZD odbywa się za pośrednictwem brokera integracyjnego z wykorzystaniem usługi Web Service.
13. System musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji.
Obsługa niepodatkowych wpływów budżetowych
1. System musi zapewniać możliwość pracy wg grup należności, dla których będą tworzone kartoteki opłat, w szczególności:
a. wieczyste użytkowanie,
b. dochody z najmu i dzierżawy,
c. przekształcenie prawa własności,
d. decyzje administracyjne,
e. inne dochody.
2. System musi mieć możliwość 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 , ustawienie sposobu fakturowania (od netto/od brutto), termin
płatności.
3. W skład modułu musi wchodzić kartoteka opłat zawierająca informacje niezbędne do zidentyfikowania płatnika oraz do naliczenia wartości opłaty tworzona na podstawie dokumentów źródłowych takich jak umowa najmu, dzierżawy, decyzji itp;
4. System musi umożliwiać wprowadzanie dokumentów przez użytkowników komórek organizacyjnych z przypisaną do ich kompetencji funkcjonalnością.
5. System po stronie finansów i księgowości 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.
6. System musi umożliwiać automatyczne wystawianie dokumentu (np. Faktury VAT).
7. System musi umożliwiać wysyłanie faktur VAT w formacie PDF poprzez ESP łącznie z profilem zaufanym użytkownika.
8. System 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.
9. System musi umożliwiać ręczne wystawianie dokumentów oraz ich kopiowanie z
automatycznym wprowadzeniem do rejestru VAT.
10. System musi umożliwiać wyszukiwanie kontrahenta wg wielu kryteriów (ich fragmentów), w
szczególności: nazwisko, imię, adres, NIX, PEXXX.
11. System musi umożliwiać przeksięgowanie nadpłat na inną należność, możliwość zwrotu nadpłaty kontrahenta.
12. System musi umożliwiać anulowanie upomnień i tytułów wykonawczych.
13. System musi umożliwiać uzupełnienie oraz poprawianie daty doręczenia dla wystawionych pism (np. upomnień).
14. System musi posiadać wbudowany kalkulator odsetkowy.
15. System musi pozwalać wykonać i wydrukować rejestr wystawionych pism, np. rejestrów tytułów wykonawczych.
16. System musi umożliwiać wykonywanie operacji zbiorowych na kartotekach opłat takich jak:
a. naliczenie cyklicznej opłaty,
b. wystawienie faktury do naliczonych opłat.
17. System musi umożliwiać drukowanie duplikatu dokumentu do pliku PDF i wysyłanie ich przez ESP za pośrednictwem brokera integracyjnego i systemu EZD.
Obsługa dodatków mieszkaniowych i dodatku energetycznego
1. System musi umożliwiać kompleksową obsługę zadań w zakresie naliczania i wypłat dodatków mieszkaniowych oraz dodatku energetycznego.
2. System umożliwi proces rejestracji wniosków wraz z wydaniem (wydrukiem) decyzji w oparciu o dane wprowadzone we wniosku z weryfikacją ich na zgodności z obowiązującymi przepisami.
3. System zapewni obsługę procesu przyznawania i przekazania do wypłaty dodatku
energetycznego.
4. System zapewni zbieranie informacji określonych w ustawach, niezbędnych do wydania właściwej decyzji.
5. System zapewni możliwość tworzenia raportów i zestawień.
6. System zapewni generowanie odpowiednich list wypłat dodatków.
7. System zapewni szybki dostęp do danych zgromadzonych w bazie danych.
8. Wprowadzania kolejnych wniosków lub decyzji powinno być oparte o możliwość skorzystania z danych już zgromadzonych.
9. System umożliwi wyliczanie sprawozdania z realizacji zadań z zakresu obsługi dodatków
mieszkaniowych.
10. System powinien posiadać rozbudowany mechanizm tworzenia szablonów treści
dokumentów, takich jak uzasadnienia, pouczenia, podstawy prawne. Dodatkowo powinien być wyposażony w standardowe zestawienia i raporty z możliwością wyboru parametrów zestawienia.
Obsługa koncesji na sprzedaż wyrobów alkoholowych
1. System musi umożliwić ewidencjonowanie podmiotów wraz z danymi lokalizacji w których prowadzona jest sprzedaż napojów alkoholowych na terenie gminy.
2. Ewidencjonowanie powinna obejmować wnioski o zezwolenia na sprzedaż napojów alkoholowych wraz z danymi wydawanych pozwoleń na sprzedaż napojów alkoholowych (sprzedaż jednorazowa/detal/gastronomia/ organizacja przyjęć).
3. System powinien umożliwić prawidłowe naliczanie opłaty oraz zapewnić ewidencjonowanie wpłat.
4. W systemie powinna być możliwość odnotowania wpłat wraz z możliwością naliczania opłaty dodatkowej za nieterminową zapłatę oraz sprawdzenia kwot zaległości.
5. System powinien umożliwić ewidencjonowanie oświadczeń o wysokości osiągniętej sprzedaży.
6. W zakresie generowania raportów system udostępni standardowy zestaw raportów. W szczególności dostępny musi być wydruk sprawozdania: listy punktów sprzedaży i liczba zezwoleń.
7. System powinien umożliwić współpracę z systemem księgowym zapewniającym prawidłowe
ewidencjonowanie i egzekucję należności z tytułu wydanych pozwoleń.
Obsługa opłaty za posiadanie psa
1. System musi zapewnić ewidencjonowanie kart płatników.
2. System powinien umożliwić prowadzenie ewidencji płatników z uwzględnieniem danych właściciela psa oraz kartotek posiadanych psów obejmujących dane w zakresie rasy psa, nazwy itp.
3. System musi posiadać możliwość wprowadzania ulg i zwolnień wynikających z uchwał Rady
Gminy.
4. System musi uwzględniać możliwość naliczania opłaty wg. obowiązujących na terenie gminy stawek oraz zapewnić podział opłaty na zdefiniowane w systemie raty.
5. Naliczać opłaty powinno być dokonywane w trybie zbiorczym dla wszystkich zobowiązanych lub wybranego sołectwa/obrębu podatkowego jak i indywidualnie dla wybranej kartoteki
płatnika.
6. System musi umożliwiać naliczanie zmian w wysokości opłaty.
7. System musi umożliwiać drukowanie odpowiednich decyzji i pism z uwzględnieniem wydruków zbiorczych i dla pojedynczych kart.
8. System musi umożliwiać generowanie wydruków i zapisywanie ich w systemie obiegu dokumentów EZD z uwzględnieniem typów dokumentów w nim zdefiniowanych.
9. System musi umożliwiać prowadzenie (wydruk) rejestru opłat oraz rejestru przypisów i odpisów.
10. System musi posiadać możliwość wielopłaszczyznowej analizy wprowadzanych danych i
możliwość ich raportowania w postaci wydruków.
11. System musi uwzględniać możliwość wydruku indywidualnych numerów rachunków
bankowych na które będą dokonywać wpłaty podatnicy. System musi uwzględniać możliwość dostosowania w/w rozwiązania do wymogów bankowych płatności masowych.
12. System musi dawać możliwość wydruku odpowiednich danych w postaci kodu kreskowego na blankiecie dowodu wpłaty z możliwością wprowadzenia w nim identyfikacji płatnika,
kwoty wpłaty, identyfikacji zobowiązania.
13. System musi współpracować z systemem informacji internetowej o stanie należności urzędu z tytułu opłaty za posiadanie psa z możliwością dokonywania płatności elektronicznych oraz aplikacją mobilną za pośrednictwem serwisu komunikacyjnego w zakresie informacji
dotyczących wysokości zobowiązań.
14. Komunikacja z systemem EZD odbywa się za pośrednictwem modułów szyny danych i brokera integracyjnego z wykorzystaniem usługi Web Service.
Obsługa księgowości podatkowej
W zakresie księgowości podatkowej System musi spełniać następujące wymagania funkcjonalne:
1. Ewidencja kart kontowych zgodna z ustawą o rachunkowości oraz ordynacją podatkową z uwzględnieniem podziału na sołectwa/okręgi podatkowe.
2. Poszczególnym kartom opłat z wymiaru odpowiadają konta w systemie księgowym.
3. System musi umożliwiać przeglądanie karty kontowej podatnika oraz zawartych na niej
wszelkich zapisów księgowych wraz z wydrukiem takiej karty i możliwością jej przekazania do systemu EZD za pośrednictwem brokera integracyjnego.
4. System musi umożliwiać automatyczne rejestrowanie wpływów zaksięgowanych w module
kasowym na konta podatników.
5. System musi umożliwiać rozksięgowanie wpłat z wyciągu bankowego z możliwością:
a. zarachowania od najstarszej zaległości,
b. zarachowania na wskazaną należność,
c. automatycznego wyliczenia i pobrania odsetek.
6. System musi umożliwiać przeksięgowanie nadpłat na inną należność podatkową, na inny rodzaj podatku lub zwrot nadpłaty podatnikowi.
7. System musi umożliwiać anulowanie upomnień i tytułów wykonawczych.
8. System musi umożliwiać uzyskanie informacji o zaległościach w rozbiciu na należność główną, odsetki na wybrany dzień.
9. System musi umożliwiać tworzenie wydruków, w szczególności:
a. Zestawienie bilansowe;
b. Zestawienie zawierające podsumowanie okresu;
c. Zestawienie zawierające salda wpływów;
d. Informacja o aktualnym stanie zadłużenia na koncie oraz o wysokości należnych odsetek na dany dzień.
10. Zapisy księgowe grupowane są w obrębie odpowiedniego typu księgowania (np. rejestr wymiarowy, raport kasowy, wyciąg bankowy, itp.).
11. Możliwość wprowadzania umorzeń należności głównej i odsetek.
12. Możliwość wprowadzania rozłożenia należności na raty oraz przesunięcia terminów płatności. - z poziomu modułów wymierzających podatek lub opłaty.
13. Księgowanie wpłat z uwzględnieniem automatycznego księgowania na najstarsze należności i
automatyczne dzielenie kwoty wpłaty na należność główną, odsetki.
14. Wydruki postanowień o zarachowaniu wpłaty.
15. Możliwość wydruków upomnień i tytułów wykonawczych oraz prowadzenie ich ewidencji. Wzory tytułu wykonawczego mogą być modyfikowane przez użytkownika.
16. Eksport danych do sprawozdania RB-27 oraz RBN na podstawie zapisów dokonanych na poszczególnych kontach.
17. Wielopłaszczyznowa analiza wprowadzanych danych i możliwość ich raportowania w postaci wydruków.
18. Możliwość zablokowania zapisów księgowych do wybranej daty w przypadku uzgodnienia danego okresu obliczeniowego.
19. Wydruk dziennika obrotów.
20. Automatyczne księgowanie wpłat na podstawie elektronicznego wyciągu bankowego przy uruchomieniu indywidualnych rachunków bankowych w systemie.
21. Współpraca z czytnikiem kodów kreskowych w zakresie identyfikacji podatnika i
automatycznego wprowadzania dowodów wpłat sygnowanych kodami kreskowymi.
22. Integracja z modułem finansowo-księgowym w zakresie przesyłania noty księgowej do
systemu finansowo-księgowego z zastosowaniem formatu XML lub inną metodą.
23. System musi umożliwiać drukowanie duplikatów ww. dokumentów do pliku PDF i wysyłanie ich za pośrednictwem brokera integracyjnego do systemu EZD.
24. System musi współpracować z systemem e-należności oraz aplikacją mobilną za
pośrednictwem serwisu komunikacyjnego w zakresie informacji dotyczących wysokości
należnych kwot zobowiązań uwzględniając w szczególności wysokość kwoty należności głównej, należnych odsetek, terminów płatności, dokonanych wpłat.
25. Komunikacja z systemem EZD odbywa się za pośrednictwem brokera integracyjnego z wykorzystaniem usługi Web Service.
26. System musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji.
Obsługa planowania, zmian i wykonania budżetu
1. Odpowiedni moduł powinien być dostępny we wszystkich wydziałach urzędu oraz dla
wszystkich jednostek organizacyjnych.
2. System 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.
3. Dla jednostek organizacyjnych system powinien umożliwiać aktualizowani planu dochodów i wydatków poprzez import sprawozdań budżetowych Rb-27S i Rb-28S.
4. System do planowania budżetu powinien być dostępny poprzez przeglądarkę internetową.
5. System do planowania budżetu powinien umożliwiać projektowanie budżetu w układzie:
6. klasyfikacji budżetowej - Dział/Rozdział/Paragraf/Analityka(tytuły wydatków i dochodów)
7. zadań budżetowych Wydział/Zadanie/Rodzaj(bezpośrednie, pośrednie, inwestycyjne, dochodowe/Kategoria (własne, zlecone, powierzone, porozumienie, porozumienie JST).
8. 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, rezerw itp.
9. Planowanie powinno być podzielone na prognozę i na projekt budżetu, który następnie będzie weryfikowany przez służby Skarbnika.
10. System musi prezentować budżet w układzie wieloletnim, tzn. jednocześnie prezentuje budżet bieżący, budżety z lat ubiegłych i prognozowane wydatki przedsięwzięć wieloletnich na lata kolejne.
11. System powinien umożliwiać automatyczne tworzenie projektu budżetu gminy, poprzez agregowanie w jeden budżet JST projektów planów finansowych dysponentów urzędu, poszczególnych jednostek organizacyjnych (podległych i nadzorowanych) w układzie zadaniowym i tradycyjnym.
12. Wszystkie jednostki organizacyjne zarządzające budżetami muszą mieć możliwość pracy w systemie online przez przeglądarkę internetową, a przeliczanie budżetu po wprowadzeniu danych powinno odbywać się w czasie rzeczywistym.
13. System musi umożliwiać dzielenie budżetu jednostki zgodnie ze strukturą organizacyjną
jednostki, przy czym:
a. liczba poziomów struktury organizacyjnej nie może być ograniczona;
b. struktura organizacyjna może ulegać zmianom w czasie zarówno w zakresie
tworzenia i likwidacji jednostek oraz ich nazewnictwa;
c. system musi prezentować budżet JST przed zmianą struktury organizacyjne i po jej
zmianie.
14. System powinien umożliwiać kosztorysowanie zadań budżetowych. Kosztorys zadania może składać się z co najmniej jednej pozycji kosztowej. Pozycja kosztorysowa powinna składać się z następujących elementów: nazwa, ilość, jednostki miary, cena/koszt jednostkowy, wartość pozycji kosztorysowej.
15. System powinien umożliwiać rejestrowanie przez wnioskodawcę wniosków o zmiany w budżecie na poziomie budżetu gminy, jednostek organizacyjnych i dysponentów urzędu.
16. System powinien umożliwiać rozproszone projektowanie zmian do budżetu w układzie
zadaniowym i klasyfikacyjnym przez urząd i jednostki organizacyjne podległe.
17. Automatyczne bilansowanie zmian w obu układach budżetu w trybie rzeczywistym.
18. Automatyczne agregowanie zmian budżetów urzędu i jednostek podległych w zmiany budżetu gminy w trybie rzeczywistym.
19. Wszystkie dokumenty generowane przez system muszą być eksportowane do innych plików rtf, xls z możliwością ich edycji.
20. System powinien mieć możliwość ustawienia statusu dostępu w zależności od nadania uprawnień.
21. System powinien umożliwiać opracowanie projektu budżetu i możliwości eksportu do systemu bestia. Powinien również zawierać możliwość przygotowania projektu uchwały budżetowej, jak również różnych innych wydruków (załączników do uchwały budżetowej) według wzorów wprowadzonych przez jednostkę.
22. Przygotowanie budżetu powinno opierać się o słowniki dochodów i 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.
Finanse i księgowość
1. W zakresie obsługi finansowo – księgowej jednostki System powinien posiadać
funkcjonalności odpowiadające za realizacje następujących obszarów: finanse i budżet, rejestry VAT, rejestr umów, obsługa wydatków.
W zakresie obsługi finansów i budżetu system musi realizować nw. funkcjonalności:
2. System musi spełniać wymagania określone przepisami ustawy o finansach publicznych, o
rachunkowości, o wydatkach strukturalnych, o sprawozdawczości budżetowej.
3. System musi posiadać możliwość kontekstowego trybu pracy tj. definiowalna struktura jednostek organizacyjnych oraz dzienników dostosowana do zakresu obowiązków
pracowników.
4. System musi posiadać możliwość definiowania dostępu do poszczególnych opcji menu oraz elementów struktury organizacyjnej (jednostka/dziennik), tak aby odpowiadało to zakresowi obowiązków (podgląd/edycja /administrowanie).
5. System 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.
6. System 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.
7. System musi posiadać warstwę prezentacyjną pozwalającą na swobodne przeglądanie stanu wykonania budżetu z uwzględnieniem wartości:
a. planu, realizacji, % realizacji (stosunek plan/realizacja), różnicy plan – realizacja,
b. kosztów, % kosztów (stosunek plan/koszty),
c. zaangażowania środków RB, różnicy plan – zaangażowanie RB , % zaangażowania RB (stosunek plan/zaangażowanie RB) ,
d. zaangażowania środków LN,
8. System powinien pozwalać na prowadzenie analiz wg. kryteriów:
a. dział, rozdział, dział/rozdział/ paragraf, dział/rozdział/paragraf/analityka,
b. wydział, jednostka organizacyjna, zadanie,
c. dział/rozdział/paragraf/analityka – zadanie,
d. dzxxxxxx,
e. okres rozliczeniowy.
9. System musi pozwalać na wprowadzanie i księgowanie jednostkowych sprawozdań z wykonania wydatków oraz dochodów budżetowych (import plików).
10. System musi mieć możliwość definiowania oraz sporządzania zestawień wynikowych takich
jak:
a. zestawienie zmian funduszu,
b. rachunek zysków i strat,
c. bilans jednostki,
d. bilans skonsolidowany.
11. System musi realizować obsługę sprawozdań budżetowych w zakresie:
a. dochodów budżetowych,
b. wydatków budżetowych
c. nadwyżki lub deficytu budżetowego,
d. stanu zobowiązań i należności.
12. System musi pozwalać na przeglądanie stanów i obrotów kont, oraz ich wydruk w formie
kont syntetycznych i analitycznych w formacie A4.
13. System musi posiadać możliwość importu uchwał budżetowych z modułu planowania budżetu.
14. System 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 i ESP.
15. System musi pozwalać na generowanie raportów sprawozdawczych dla RIO (Rb-27S, Rb-27zz, Rb-28S, Rb-30, Rb-30S, Rb-34S, Rb-50,Rb-Nds, RB-ZN, RB-UZ, RB-UN, RB-PDP) z możliwością ich eksportu do programu BeSTi@.
16.
17. System 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).
18. Funkcjonalność sprawozdawczości budżetowej powinna zwierać również możliwość:
a. agregacji sprawozdań jednostkowych do sprawozdania zbiorczego,
b. tworzenia zestawień różnicowych – wykonanie budżetu za miesiąc,
c. generowanie dokumentów księgowych na podstawie danych sprawozdań różnicowych (wykonanie budżetu za miesiąc).
19. System musi posiadać moduł kontroli informujący o przekroczeniach zaplanowanego budżetu w zakresie klasyfikacji budżetowej, zadań oraz umów. Rodzaje przekroczeń które muszą podlegać analizie:
a. plan na paragrafie / wydatki;
b. plan na paragrafie / koszty;
c. plan na paragrafie / zaangażowanie RB;
d. wydatki / zaangażowanie RB;
e. plan na zadaniu / wydatki;
f. plan na zadaniu / koszty;
g. plan na zadaniu / zaangażowanie RB.
20. System musi umożliwiać przygotowanie zestawień i ich wydruk:
a. o przekroczeniu wykonania wydatków ponad plan,
b. o zobowiązaniach przekraczających plany wydatków,
c. o zaangażowaniu przekraczającym plany wydatków,
d. planu oraz wykonania kosztów i wydatków wg klasyfikacji budżetowej,
e. o wydatkach przekraczających zaangażowanie wynikające z umowy,
f. o zobowiązaniach, należnościach wymagalnych.
21. System musi pozwalać na wprowadzanie bilansu otwarcia (generowanie B.O. automatycznie) z możliwością:
a. ręcznego i automatycznego wprowadzania,
b. tworzenia roboczego zbioru BO, który może być modyfikowany przed ostatecznym zamknięciem lub możliwość innego korygowania BO,
c. generowania łącznego BO, BZ dla kilku jednostek organizacyjnych,
d. generowania i drukowania zestawienia BO, BZ w formacie A4.
e. Zbiory BO, BZ (salda dwustronne).
22. System 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.
23. System musi umożliwiać rejestrację operacji gospodarczych w dziennikach z możliwością:
a. storna czarnego i czerwonego,
b. generowania i drukowania dziennika w formacie A4
c. wprowadzenia dokumentu księgowego i jego zapłaty w rozbiciu na źródła
finansowania a zarazem uzyskania łącznej kwoty na danym koncie analitycznym.
24. Prowadzenie planu kont z możliwością:
a. korekty definicji konta,
b. usuwania konta z planu,
c. blokady konta,
d. generowania i drukowania planu kont w formacie A4
e. tworzenia o dowolnej głębokości analityki, z wykorzystaniem zarówno cyfr jak i liter
przy jego budowie.
25. System musi umożliwiać automatyczne i ciągłe numerowanie dowodów księgowych.
26. System 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).
27. System musi zapewniać możliwość rejestracji różnych typów dokumentów dochodowych,
przychodowych, rozchodowych i wydatkowych, w tym x.xx.:
a. polecenie księgowania,
b. nota księgowa,
c. raport kasowy,
d. dotacji,
e. subwencji,
f. rachunków do umów zleceń,
g. rachunków do umów o dzieło,
h. faktur VAT,
i. delegacji, listę środków dla jednostek, zaliczek, rozliczeń zaliczek,
j. listę dotacji,
k. ryczałtów samochodowych,
l. zaliczek stałych.
28. System musi zapewniać możliwość samodzielnego definiowania kolejnych rodzajów dokumentów.
29. System musi zapewniać dekretację zarejestrowanych dokumentów zarówno w zakresie zapisów księgowych jak i klasyfikacji budżetowej.
30. System musi umożliwiać prowadzenie centralnego rejestru dowodów księgowych na
poziomie wydziału finansowego jak również wydziałów merytorycznych.
31. System musi umożliwiać automatyczne tworzenie paczek przelewów na podstawie zarejestrowanych wydatków.
32. System musi umożliwiać automatyczne księgowanie wyciągów bankowych w zakresie
zarejestrowanych wydatków.
33. System powinien posiadać mechanizmy integracyjne pozwalające na pobieranie danych z systemów zewnętrznych takich jak:
a. naliczonych list płac oraz rozliczenie podatków i składek na ubezpieczenie społeczne.
b. Import księgowań z systemów rozliczeń analitycznych takich jak: księgowość podatków, księgowość gospodarki odpadami.
W zakresie rejestrowania sprzedaży i zakupów system musi realizować nw. funkcjonalności:
34. System powinien zapewnić możliwość prowadzenia centralnego rejestru sprzedaży uwzględniającego możliwość wystawienia dokumentów następujących typów: faktura
sprzedaży, korekta faktury sprzedaży (tryb automatyczny i ręczny), faktura do paragonu, paragon sprzedaży faktura wewnętrzna, nota obciążeniowa, rachunek.
35. System 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ące sprzedaży opodatkowanej i zwolnionej.
36. System powinien umożliwić wybór sposobu odliczenia podatku (wariant częściowy): przy pomocy wskaźnika, prewskaźnika lub iloczynu tych dwóch wartości.
37. System po stronie finansów i księgowości powinien umożliwić przyporządkowanie do dokumentu zakupu klasyfikacji budżetowych celem dokonania analizy odliczeń PTU z uwzględnieniem tego kryterium.
38. System po stronie finansów i księgowości powinien umożliwić dokonywania automatycznych dekretacji dokumentów handlowych (sprzedaż i zakup) za pomocą wcześniej zdefiniowanych schematów księgowań.
39. System powinien umożliwić sporządzania deklaracji VAT- 7 (na podstawie wprowadzonych
dokumentów handlowych).
40. System powinien umożliwiać tworzenie zbiorów JPK w zakresach wymaganych przez ustawodawcę.
41. System powinien umożliwić wysyłkę deklaracji VAT z użyciem podpisu kwalifikowanego.
42. System powinien umożliwić zapis dokumentów wychodzących (sprzedaż) do EZD za pośrednictwem serwisu komunikacyjnego (Web Service).
W zakresie prowadzenia rejestru umów:
43. System musi umożliwiać katalogowanie dokumentów w przynajmniej czterech kartotekach:
a. Dokumenty dochodowe,
b. Dokumenty wydatkowe,
c. Dokumenty mieszane (dochodowo-wydatkowe),
d. Dokumenty bezkwotowe.
44. Moduł prowadzący rejestr umów musi być powiązany integralnie z modułami obsługującymi finanse i budżet w zakresie wspólnych słowników kontrahentów, paragrafów i zadań;
kartoteka powinna umożliwić analizę stanu realizacji umowy w zakresie zaksięgowanych pozycji zaangażowania, kosztów, wydatków – powiązanie dekretacji wprowadzanych w module finanse i budżet z listą umów;
45. System musi umożliwić rejestrację zaangażowania środków przeznaczonych na finansowanie zadań budżetowych przez dysponentów środków, w tym:
a. rejestrację dokumentów powodujących zaangażowanie (umów, aneksów do umów, faktur, zleceń itp.);
b. kontrolowanie statusów wprowadzanych dokumentów (projekt dokumentu, dokument kontrasygnowany, dokument podpisany itp.);
c. blokowanie rejestracji dokumentu zaangażowania powodującego przekroczenie wartości planu.
46. Kontrolowanie i rejestrowanie kontrasygnat wykonywanych przez skarbnika.
47. Rejestracja faktur (transz, rat itp.) do umów oraz blokowanie rejestracji dokumentu powodującego przekroczenie wartości umowy.
48. Przy rejestracji dokumentu zaangażowania, pobieranie danych o kontrahencie z bazy danych kontrahentów systemu FK a w przypadku braku kontrahenta w bazie:
a. z referencyjnej baz danych CEIDG (osoby prowadzące działalność gospodarczą i spółki cywilne);
b. z referencyjnej baz danych KRS – Krajowego Rejestru Sądowego (spółki prawa
handlowego i stowarzyszenia);
c. z referencyjnej baz danych GUS REGONBIR – baza internetowa REGON Głównego Urzędu Statystycznego.
49. Dla każdego zadania budżetowego system musi wyświetlać informacje o stanie:
a. wolnych środkach możliwych do zaangażowania;
b. sumie zaangażowania ogółem;
c. sumie zaangażowań będących w przygotowaniu;
d. sumie zaangażowań zatwierdzonych do realizacji;
e. sumie zaangażowań pozostałych do zrealizowania;
f. sumie zaangażowań anulowanych/wycofanych z realizacji;
g. sumie zaangażowań zamkniętych/zrealizowanych;
h. aktualnych zobowiązaniach na podstawie zarejestrowanych faktur do zaangażowań;
i. aktualnym wykonaniu na podstawie faktur już zapłaconych;
j. wartości środków na podstawie faktur pozostałych do realizacji.
50. Automatyczne generowanie wykazu zawartych umów, zawierającego co najmniej następujący zestaw danych: liczba porządkowa; numer umowy; rok zawarcia umowy;
podmiot umowy; przedmiot umowy; czy umowa dotyczy dotacji (tak/nie); wartość umowy; okres na jaki umowa została zawarta.
51. Prezentacja danych o zaangażowaniu w układzie:
a. Uchwała budżetowa;
b. Plan po zmianach;
c. Wykonanie;
d. Zaangażowanie;
e. Wolne środki.
52. System musi umożliwiać udostępnienie rejestru umów do w celu publikacji na BIP.
53. System 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 itp. oraz definiowania schematu numeracji umów / dokumentów.
54. Moduł powinien współpracować z EZD (za pośrednictwem serwisu komunikacyjnego) w zakresie pobierania informacji o zarejestrowanych umowach: kontrahent, wartość, treść dokumentu itp.
55. System musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji.
W zakresie obsługi wydatków:
56. System musi zapewniać możliwość rejestracji różnych typów dokumentów rozchodowych i
wydatkowych, w tym x.xx.:
a. rachunków do umów zleceń umożliwiając ich automatyczne składkowanie,
b. rachunków do umów o dzieło,
c. faktur VAT,
d. delegacji, listę środków dla jednostek, zaliczek, rozliczeń zaliczek,
e. listę dotacji,
f. ryczałtów samochodowych,
g. zaliczek stałych.
57. System musi zapewniać możliwość samodzielnego definiowania kolejnych rodzajów dokumentów i rejestrów.
58. System musi zapewniać dekretację zarejestrowanych dokumentów zarówno w zakresie zapisów księgowych, jak i klasyfikacji budżetowej.
59. System musi umożliwiać prowadzenie centralnego rejestru dowodów księgowych na poziomie wydziału finansowego jak również wydziałów merytorycznych.
60. W przypadku faktur VAT, system 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.
61. System musi umożliwić eksport rejestrów VAT cząstkowych z systemów innych jednostek podległych nie będących zintegrowanymi z urzędem.
62. System 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.
63. System 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.
64. Procedura tworzenia paczek eksportu do systemu bankowego Zamawiającego powinna zawierać możliwość selekcji dokumentów niezapłaconych.
65. System 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.
66. System powinien umożliwić import wyciągu bankowego (ze zbioru plikowego dostarczanego przez system bankowy Zamawiającego), analizę jego danych oraz powiązanie poszczególnych wydatków z dokumentami kosztowymi na podstawie których zostały wygenerowane
przelewy bankowe. Tak przygotowane dane powinny podlegać automatycznej dekretacji stosownie do podziałki budżetowej (paragrafy i zadania).
67. System powinien na etapie księgowania wyciągu bankowego analizować stan wykonania budżetu i wyświetlać stosowną informację dotycząca wychwyconego przekroczenia w zakresie planu budżetu jak i planu zawartych umów z kontrahentami.
Obsługa centralnego składania deklaracji VAT
1. System musi umożliwić jednostkom podległym Zamawiającego (Gminy Chełm) procedurę dostarczania deklaracji cząstkowych VAT wraz z załącznikami ze szczególnym
uwzględnieniem rejestrów zakupów i sprzedaży w formacie JPK.
2. Jednostka nadrzędna (Urząd Gminy Chełm) musi mieć możliwość kontroli nad przesyłanymi dokumentami obejmującą sprawdzenie ich zgodności z obowiązującymi schematami oraz zgodność w zakresie kwot podanych w deklaracji z danymi zapisanymi w plikach JPK.
3. System powinien zapewnić nadzór nad skompletowaniem wszystkich wymaganych dokumentów od jednostek podrzędnych a następnie połączenie ich w jednej wspólnej deklaracji i agregację plików JPK w jeden plik obejmujący całą sprzedaż i zakupy.
4. Oferowane rozwiązanie (dalej zwane Modułem) powinno być bezpośrednio powiązane z modułem obsługującym deklarację VAT w systemach dziedzinowych, tzn. że dane powinny być przetwarzane w obrębie modułu finansowo – księgowego lub za pośrednictwem innego modułu obsługującego jednostkę centralną odpowiedzialną za złożenie deklaracji do urzędu skarbowego .
5. Moduł powinien udostępniać dane zalogowanemu użytkownikowi tylko w zakresie jego uprawnień nadanych przez administratora.
6. Moduł powinien umożliwić (jednostkom organizacyjnym JST) złożenie stosownych
dokumentów niezbędnych do naliczenia zbiorczej deklaracji VAT-7, minimum w zakresie
deklaracji cząstkowej VAT-7 (formularz dostępny w Systemie/dedykowanym module
wypełniany ręcznie lub pobierany poprzez import z pliku) wraz z niezbędnymi załącznikami: 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.
7. Moduł powinien dokonywać walidacji składanej deklaracji VAT-7 z dołączanymi rejestrami w
formacie JPK.
8. Moduł powinien posiadać zaimplementowane mechanizmy umożliwiające automatyzację
wymiany danych pomiędzy jednostkami a modułem centralnym odpowiedzialnym za wysyłkę deklaracji do Urzędu Skarbowego. Udostępnianie danych użytkownika następuje po zalogowaniu się po jego zalogowaniu na indywidualne konto.
Ewidencja środków trwałych
W zakresie ewidencji środków trwałych System musi spełniać następujące wymagania funkcjonalne:
1. System musi pozwalać na szczegółową rejestrację, ewidencjonowanie posiadanego majątku w postaci: środków trwałych, wartości niematerialnych i wyposażenia.
2. System musi posiadać przejrzyste menu poprzez które można sprawnie wprowadzać nowe
informacje.
3. System musi posiadać rozbudowany panel filtru pozwalający na szybkie wybranie danych z interesującego zakresu.
4. System 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.
5. System musi pozwalać na przyjęcie środka trwałego do ewidencji z uwzględnieniem następujących danych: numer inwentarzowy, nazwa środka. Do każdej kartoteki powinna być przypisywana faktyczna lokalizacja oraz odpowiednia klasyfikacja środka trwałego z podziałem na grupy, podgrupy.
6. System musi pozwalać na wprowadzanie danych dotyczących stopy amortyzacji, wartości umorzenia, data przyjęcia, rok produkcji lub oddania do eksploatacji, nazwisko osoby materialnie odpowiedzialnej, uwagi itp.
7. System 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.: 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.
8. System musi pozwalać na automatyczne naliczanie na cały rok kwot amortyzacji miesięcznych w układzie liniowym.
9. System 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.
10. System musi pozwalać na aktualizację danych z automatycznym uwzględnianiem wpływu
tych zmian na naliczanie amortyzacji i umorzenia.
11. System 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.
12. System musi pozwalać na likwidację środka.
13. System musi pozwalać na zakończenie roku i naliczenie bilansu otwarcia na rok następny.
14. System musi pozwalać na automatyczne naniesienie na kartoteki dokumentów amortyzacji na cały rok ewidencyjny – wykonywane podczas operacji zamknięcia roku.
15. System musi umożliwiać prowadzenie ewidencji przedmiotów w użytkowaniu w sposób ilościowy lub ilościowo – wartościowy, dodatkowym atutem jest mechanizm cech, który 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, itp. wydruki: karty środka trwałego, listy środków zlikwidowanych lub przyjętych do ewidencji w danym roku, arkusz spisu z natury, wydruk zestawienia rocznego dla wszystkich grup (wartości inwentarzowe, amortyzacja i umorzenia , zwiększenia, zmniejszenia ). ewidencji do archiwum.
Ewidencja mienia komunalnego (nieruchomości gminne)
W zakresie ewidencji mienia komunalnego gminy system musi spełniać następujące wymagania
funkcjonalne:
1. System powinien umożliwiać prowadzenie rejestru działek będących we władaniu gminy,
2. System powinien posiadać rozbudowane możliwości wyszukiwania i selekcji gruntów według
dowolnego kryterium,
3. 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,
4. 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.),
5. System powinien umożliwić prowadzenie ewidencji budynków i lokali (zabudowa działek),
6. System powinien umożliwiać sporządzanie wydruku dokumentów typu: umów dzierżawnych, pism, korespondencja z dzierżawcami itp.,
7. 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,
8. System umożliwi wystawianie faktur VAT i rachunków za czynsze dzierżawne wraz z dodatkowymi opłatami (media itp.),
9. System powinien posiadać rozbudowany system tworzenia własnych zestawień i raportów.
Obsługa kasy
1. System musi umożliwiać kompleksową obsługę zadań w zakresie prowadzenia kasy urzędu.
2. System musi w szerokim zakresie wykorzystywać możliwości środowiska Windows (przejrzyste wydruki graficzne, czytelnia forma prezentacji, rozbudowane metody selekcji danych, przyjazny interfejs itp.).
3. System musi umożliwiać przyjmowanie wpłat i wypłat na wybrane raporty kasowe, wydawanie dokumentów KP, KW.
4. System musi umożliwiać dwukierunkową współpracę z pozostałymi modułami rozliczającymi dochody budżetowe.
5. System musi umożliwiać generowanie raportów kasowych oraz zestawień z dowodów
kasowych.
6. System musi posiadać obsługę kodów kreskowych umieszczanych na wydrukach z systemów rozliczających dochody budżetowe (np. nakazy płatnicze w systemie podatkowym).
7. System musi pozwalać na identyfikację płatnika za pomocą czytnika kodów kreskowych.
8. System musi pozwalać na współpracę zarówno z tradycyjnymi drukarkami igłowymi jak i
drukarkami atramentowymi czy laserowymi.
9. System musi pozwalać na integrację z wszystkimi modułami księgowymi umożliwiając automatyczną obsługę kasową płatności zobowiązań.
10. System musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji.
Kadry i płace
W zakresie obsługi kadr System musi spełniać następujące wymagania funkcjonalne:
1. System musi umożliwiać definiowanie struktury jednostki z uwzględnieniem podziału kadrowego oraz podziału księgowego.
2. System musi umożliwiać ewidencjonowanie danych osobowych pracownika.
3. System musi umożliwiać ewidencjonowanie umów o pracę, aneksów, angaży.
4. System musi umożliwiać gromadzenie szczegółowego przebiegu pracy pracownika z
uwzględnieniem poprzedniego zatrudnienia i ukończonych szkół w celu automatycznego naliczania dodatku stażowego, uprawnień urlopowych i nagród jubileuszowych.
5. System musi umożliwiać prowadzenie ewidencji wszystkich rodzajów nieobecności w pracy.
6. System musi współpracować z elektronicznymi zwolnieniami lekarskimi e-ZLA.
7. System musi umożliwiać rejestrację badań lekarskich, dodatkowych badań lekarskich, szkoleń, ryczałtów samochodowych i kar.
8. System musi umożliwiać wydruk angażu, skierowania na badania lekarskie, świadectwa pracy i wielu innych dokumentów.
9. System musi umożliwiać tworzenie raportu urlopów według stanu na rok i z różnych kryteriów wyszukiwania.
10. System musi umożliwiać wydruk zestawień i sprawozdań.
11. System musi umożliwiać dowolne wyszukanie i zestawienie danych zgromadzonych w
zapisach bazy danych w formie wydruku.
12. System musi umożliwiać wprowadzanie i przechowywanie danych osobowych pracownika, które pozwolą jednoznacznie określić osobę oraz przyśpieszyć wprowadzanie danych zapobiegając ich dublowaniu. Do danych osobowych muszą zaliczać się:
a. podstawowe informacje (nazwisko, imię, obywatelstwo, miejsce i datę urodzenia,
NIP, pesel, nr dowodu osobistego, urząd skarbowy),
b. adresy pobytu stałego, zameldowania i do korespondencji,
c. informacje o członkach rodziny, kontach bankowych, odbytych szkoleniach,
kwalifikacjach, szkoleniach, przynależności do organizacji i znajomości języków,
d. historia poprzedniego zatrudnienia.
13. System musi pozwalać na definiowanie wielu płatników składek, a w ich obrębie wiele miejsc pracy z dowolną strukturą organizacyjną Dodatkowo, oprócz podstawowych danych takich jak adres musi zawierać informacje o NIPie, kontach bankowych Struktura wynikająca z umowy musi odzwierciedlać komórki w jakich są zatrudnieni pracownicy.
14. System 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.
15. System musi pozwalać na zdefiniowanie dowolnej ilości kalendarzy i przypisanie ich do
pracowników. 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. Kalendarze muszą mieć postać graficzną, z wyszczególnieniem absencji w postaci określonego koloru oraz skrótu literowego.
16. System musi umożliwiać ewidencjonowanie bieżącego i zaległego urlopu wypoczynkowego oraz ilość urlopu wypoczynkowego na żądanie.
17. System musi umożliwiać generowanie dokumentów ZUS w formacie KEDU kompatybilnych z programem PŁATNIK. Dostępne muszą być następujące formularze:
a. ZUA - zgłoszenie do ubezpieczeń / zgłoszenie zmiany danych osoby ubezpieczonej
b. ZUS ZZA - zgłoszenie do ubezpieczenia zdrowotnego / zgłoszenie zmiany danych
c. ZUS ZIUA - zgłoszenie zmiany danych identyfikacyjnych osoby ubezpieczonej
d. ZUS ZCNA - zgłoszenie danych o członkach rodziny, których adres zamieszkania nie jest zgodny z adresem zamieszkania ubezpieczonego, dla celów ubezpieczenia zdrowotnego
e. ZUS ZWUA - wyrejestrowanie z ubezpieczeń
18. System musi umożliwiać automatyczne przenoszenie na powyższe formularze danych
płatnika składek i osoby ubezpieczanej, tak aby maksymalnie uprościć wprowadzanie danych.
19. Komunikacja z systemem EZD odbywa się za pośrednictwem brokera integracyjnego z wykorzystaniem usługi Web Service.
W zakresie obsługi płac System musi spełniać następujące wymagania funkcjonalne:
20. System musi posiadać gotowe składniki płacowe podzielone na grupy tematyczne: płaca brutto, składniki dodatkowe, socjalne, przerwy w pracy, potrącenia dobrowolne i inne.
21. System musi posiadać gotowe sposoby wyliczenia wynagrodzeń dla grup pracowników.
22. System musi posiadać możliwość zdefiniowania dowolnego systemu wynagrodzeń oraz możliwość jego modyfikacji indywidualnie przez przeszkolonego administratora systemu.
23. System musi posiadać możliwość tworzenia wielu rodzajów list płac w dowolnych okresach rozliczeniowych.
24. System musi posiadać możliwość grupowania pracowników na listach płac według dowolnych kryteriów.
25. System musi posiadać możliwość uwzględniania różnych sposobów wynagradzania takich jak: umowa o pracę, umowa o dzieło, umowa zlecenia, wypłaty komisji, diet.
26. System musi posiadać możliwość tworzenia wielu rodzajów list płac takich jak: lista
podstawowa, listy dodatkowe, lista wyrównująca, lista korygująca itd.
27. System musi posiadać możliwość zbiorczego wprowadzania składników płacowych dla wybranych pracowników np. diety, nagrody itp.
28. System musi posiadać możliwość zadeklarowania automatycznych dodatkowych wypłat między innymi takich jak: wypłaty diet, wynagrodzeń za posiedzenia komisji itp.
29. System musi posiadać możliwość konfiguracji parametrów płacowych określających sposób wyliczania wynagrodzenia z uwzględnieniem regulaminu wynagradzania danej jednostki.
30. System musi posiadać możliwość zdefiniowania podstaw do wyliczenia wynagrodzeń za czas nieobecności pracownika (chorobowe, macierzyńskie itp.).
31. System musi posiadać możliwość zdefiniowania podstaw do wyliczenia godzin nadliczbowych oraz „trzynastki”.
32. System musi posiadać zestaw parametrów potrzebnych do wyliczeń (parametry składek ZUS, progi podatkowe itp., kalendarze) uzupełnianych w trakcie aktualizacji.
33. System musi posiadać możliwość odwzorowania struktury organizacyjnej jednostki (dział,
stanowisko itp.).
34. System musi umożliwiać konfigurację pod względem praw dostępu użytkownikom systemu. Administrator systemu musi mieć możliwość określenia zakresu danych, do których jest upoważniony dany użytkownik.
35. System musi umożliwiać prowadzenie ewidencji danych osobowych pracowników oraz
innych osób, dla których prowadzimy wypłaty (radni, umowy cywilnoprawne, nauczycielei
itp.)
36. System musi umożliwiać prowadzenie ewidencji danych dotyczących przebiegu zatrudnienia oraz wynagrodzenia. W gromadzonych danych musi być odzwierciedlony angaż pracownika czyli między innymi podstawowe dane związane z zatrudnieniem, wymiarem czasu pracy,
kodem tytułu ubezpieczenia, rodzajem kosztów, należną ulgą podatkową oraz stałe składniki płacowe wraz z potrąceniami dobrowolnymi.
37. System musi umożliwiać prowadzenie archiwum pracowników.
38. System musi umożliwiać automatyczne naliczanie płac.
39. System po stronie finansowo-księgowej musi zawierać mechanizm automatycznego
rozksięgowania listy płac na podstawie struktury klasyfikacji budżetowej prowadzonej przez jednostkę.
40. System musi zawierać mechanizm automatycznego przesłania rozksięgowanych list płac do
systemu finansowo-księgowego.
41. System po stronie finansów i księgowości musi zawierać możliwość prawidłowego zaksięgowania naliczonego dodatkowego wynagrodzenia rocznego („trzynastki”), które nie zostało jeszcze wypłacone.
42. System musi automatycznie tworzyć deklaracje PIT.
43. System musi umożliwiać tworzenie korekt deklaracji PIT.
44. System musi mieć możliwość wygenerowania, modyfikacji, podpisania elektronicznego oraz wysłania następujących deklaracji PIT: PIT 11, PIT R, PIT 8C, PIT 4R, PIT 8AR.
45. System musi mieć możliwość wyboru i zaznaczenia domyślnego numeru identyfikacyjnego wykorzystanego przy tworzeniu osobowych deklaracji PIT (NIP, PESEL).
46. System musi mieć wpisane i skonfigurowane w słowniku wszystkie Urzędy Skarbowe w
Polsce.
47. System musi mieć możliwość generowania i drukowania comiesięcznej informacji o
naliczonym i zapłaconym podatku na poczet zaliczki wynikającej z deklaracji: PIT 8AR, PIT 4R.
Prowadzenie rejestru mieszkańców gminy
1. System powinien posiadać moduł wspierający przegląd rejestru aktualnych i byłych mieszkańców gminy.
2. Moduł powinien umożliwiać wyszukiwanie kartotek co najmniej wg parametrów: dokument tożsamości, XXXXX, nazwisko, imię, płeć, data urodzenia, miejscowość, adres.
3. Moduł musi wspierać wpisywanie znaków diakrytycznych w celu wyszukiwania cudzoziemca.
4. Moduł powinien umożliwić przegląd wyszukanych danych i wykaz co najmniej poniższych danych: adres stały, adres czasowy, dane urodzenia, stan cywilny, obywatelstwo, dane cudzoziemca, dane dot. zgonu, dane historyczne, w tym nazwiska, xxxxxx, nr PESEL, historia zameldowania.
5. Moduł powinien umożliwić również tworzenie, modyfikację i usuwanie danych historycznych mieszkańca.
6. W przypadku rejestru mieszkańców moduł powinien umożliwiać pobieranie danych z SRP.
7. Moduł musi umożliwiać przegląd listy nowych zmian, które przyszły z SRP.
8. W ramach kontroli importowanych danych system powinien umożliwiać generowanie
raportu ze zmian danych mieszkańca (porównanie danych z różnych okresów importu danych dla danego mieszkańca).
9. Moduł powinien umożliwiać prowadzenie rejestru cudzoziemców, w tym przynajmniej:
a. rejestrację pobytu czasowego cudzoziemca,
b. rejestrację pobytu stałego cudzoziemca,
c. tworzenie danych historycznych cudzoziemca,
d. modyfikację danych historycznych cudzoziemca,
e. usuwanie danych historycznych cudzoziemca,
f. przeglądanie danych historycznych cudzoziemca.
10. Moduł powinien umożliwiać wykonanie wydruków dla mieszkańców:
a. aktu pełnomocnictwa do głosowania,
b. pełnego odpisu przetwarzanych danych mieszkańca lub cudzoziemca,
c. odpowiedzi na wniosek o udostępnienie danych osobowych,
d. zaświadczenia o zameldowaniu na pobyt stały,
e. zaświadczenia o zameldowaniu na pobyt czasowy,
f. zaświadczenia o wymeldowaniu z pobytu stałego,
g. zaświadczenia o wymeldowaniu z pobytu czasowego,
h. zawiadomienia do szkoły (zawiadomienie o zmianach),
i. zawiadomienia dla rejestru wyborców o wymeldowaniu z pobytu stałego.
11. Moduł powinien również umożliwiać wykonanie pozostałych wydruków i zestawień:
a. rejestru osób objętych rejestracją (do kwalifikacji wojskowej),
b. listy stawiennictwa osób do kwalifikacji wojskowej,
c. logów z czynności użytkowników w module,
d. protokołu z pracy systemu,
e. zestawienia dowodów osobistych do unieważnienia,
f. listy mieszkańców wg dowolnych parametrów,
g. listy do szkół - względem wieku i obszaru,
h. listy zgonów dla Urzędu Skarbowego,
i. listy miejscowości i ulic obsługiwanych przez jednostkę,
j. raportu z brakujących dat wymeldowania i zameldowania w adresach historycznych,
k. raportu po aktualizacji przeterminowanych pobytów czasowych cudzoziemca.
12. Moduł powinien umożliwić prowadzenie rejestru złożonych wniosków o udostępnienie danych, w tym usuwanie wniosku z rejestru złożonych wniosków o udostępnienie danych.
13. Moduł powinien umożliwiać automatyczne wymeldowanie z pobytu czasowego cudzoziemca
po przekroczeniu deklarowanego terminu pobytu.
14. Moduł powinien umożliwiać konwersję niepełnych dat (np. tylko rok) na daty pełne.
15. Powinna istnieć możliwość określanie formatu adresu na wydrukach poprzez przygotowanie
szablonu adresu.
16. Moduł powinien być zintegrowany ze wspólnym modułem do obsługi kontrahentów i umożliwiać przekazywanie aktualnych danych kontrahenta w zakresie.
17. Dane osobowe mieszkańca powinny być możliwe do przekazania do modułu obsługi
interesantów gminy w sposób automatyczny (aktualizacja kontrahenta po dokonaniu zmian w danych mieszkańca) lub ręczny, czyli poprzez wywołanie aktualizacji ręcznie przez
użytkownika systemu.
18. Aktualizacja powinna być możliwa do wykonania również w sposób masowy na żądanie użytkownika systemu po stronie modułu do obsługi interesantów.
19. System pod tym kątem powinien udostępniać raport z aktualizacji danych kontrahentów danymi z ewidencji ludności.
20. Minimalny zakres danych, jakie są przekazywane do modułu obsługi interesantów to:
a. dane podstawowe, tj. XXXXX, XXX, nazwisko, imię,
b. dane adresowe, tj. miejscowość, ulica, nr domu, nr lokalu, kod pocztowy,
c. dane dot. zgonu,
d. pozostałe dane, takie jak nazwisko xxxxxx, imię matki i ojca, data urodzenia, miejsce
urodzenia.
21. Moduł powinien umożliwiać wsparcie wyborów poprzez tworzenie i wydruk spisów głównych i dodatkowych, w tym wygenerowania spisów w postaci pliku XML.
22. Moduł powinien wyszukiwanie kart rejestru dodatkowego wg. zadanych parametrów.
23. Powinna istnieć możliwość utworzenia edycji i usunięcia kart rejestru dodatkowego, a także podglądu listy kart rejestru dodatkowego w formie wydruku.
24. Moduł musi umożliwiać wykonanie wydruków:
a. zawiadomienia o dopisaniu do rejestru wyborców,
b. skreśleniu z rejestru wyborców,
c. aktu pełnomocnictwa,
d. masowych zawiadomień o dopisaniu do spisu wyborców,
e. decyzji o dopisaniu do rejestru wyborców,
f. rejestru niegłosujących,
g. zaświadczenia o prawie do głosowania,
h. statystyka wydanych zaświadczeń.
25. Moduł powinien wspierać wyszukiwanie kart rejestru niegłosujących wg. zadanych parametrów, a także tworzenie, edycję i usunięcie kart rejestru niegłosujących.
26. Rejestr wyborców powinien umożliwiać filtrowanie danych wg szerokiego zakresu kryteriów.
27. Możliwość zarządzania listą wyborów dodawanie, edycja, usuwanie oraz zatwierdzanie listy wyborów.
28. Możliwość wykreślania i usuwania pozycji ze spisu wyborczego.
29. Możliwość określania i edycji przyczyny dopisania lub wykreślenia ze spisu wyborczego.
30. Możliwość tworzenia, edycji, usuwania i weryfikacji geografii wyborczej.
31. Wydruk protokołu pracy systemu.
32. Tworzenie meldunku o:
a. stanie rejestru wyborców w gminie/mieście,
b. stanie rejestru wyborców w stałych okręgach wyborczych i obwodach głosowania.
33. Moduł powinien umożliwiać tworzenie i zarządzanie rejestrem uprawnionych do glosowania izb rolniczych na podstawie baz danych ewidencji ludności, ewidencji podatników i
współwłaścicieli oraz podatników spoza gminy.
34. Spis członków izby rolniczej powinien umożliwiać:
a. określanie parametrów spisu,
b. dodawanie i edycja pozycji spisu członków uprawnionych do głosowania,
c. generowanie pozycji w spisie członków na podstawie danych podatkowych
zgromadzonych w module do obsługi podatki od osób fizycznych.
35. Moduł powinien wspierać tworzenie i zarządzanie spisem przedstawicieli członków izb
rolniczych:
a. określanie parametrów spisu,
b. dodawanie i edycja pozycji spisu przedstawicieli uprawnionych do głosowania,
c. generowanie pozycji w spisie przedstawicieli na podstawie danych podatkowych
zgromadzonych w module do obsługi podatków od osób prawnych.
36. Możliwość usuwania niezatwierdzonych spisów.
37. Wydruk spisów.
38. Możliwość wykonania szeregu wydruków / zestawień statystycznych, w tym co najmniej:
a. statystyki pod wskazanym adresem,
b. lista lokali w budynku,
c. danych ogólnych dotyczących płci, obywatelstwa, rocznika, stanu cywilnego oraz dokumentu tożsamości,
d. ilości domów i lokali pod wskazanym adresem,
e. struktury wiekowa mieszkańców,
f. ludności w miejscowościach,
g. DW1, DW2, DW3 wg. zadanych parametrów,
h. zestawienia użytkownika definiowanego przez użytkownika – wg szerokiego zakresu
kryteriów.
39. Możliwość wygenerowania plików DW1, DW2, DW3 przekazywanych do GUS.
Wdrożenie systemu obejmie co najmniej czynności wskazane w punkcie „Wymagania ogólne dla wdrożeń Oprogramowania Aplikacyjnego”.
1. Dostęp do systemu 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).
2. System musi funkcjonować na ogólnodostępnym serwerze internetowym i udostępniać swoją treść przy wykorzystaniu przeglądarek WWW. Budowa strony internetowej powinna spełniać ogólnie przyjęte standardy kodowania WWW. Wyświetlanie danych dokonywane
jest za pomocą przeglądarki internetowej i nie może wymagać instalacji dodatkowego
oprogramowania po stronie użytkownika.
3. System powinien umożliwiać wykorzystanie bezpiecznego protokołu komunikacji pomiędzy stacją roboczą a serwerem, na którym jest zainstalowany, w celu zabezpieczenia poufności danych.
4. System musi posiadać stronę główną umożliwiającą dodanie nazwy adresu, znaku
graficznego jednostki Zamawiającego, ustawienie głównych funkcji, do których szybko mogą dotrzeć interesanci Zamawiającego.
5. 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.
6. 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.
7. System zapewnia administratorowi podgląd listy użytkowników, którym udostępniono dostęp do portalu systemu, wraz z danymi dotyczącymi, nazwy, identyfikatora profilu zaufanego, daty utworzenia konta, statusu oraz metody logowania.
8. 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.
9. Integracja z systemami dziedzinowymi - 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 oparta o technologię web service.
10. Wymagana jest 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.
11. System musi umożliwiać pozyskiwanie z systemów dziedzinowych do konta użytkownika danych o aktualnych zobowiązaniach zalogowanego interesanta z uwzględnieniem należności dodatkowych tj. odsetki i inne koszty na bieżącą datę logowania w zakresie:
a. podatku od nieruchomości od osób fizycznych,
b. podatku od nieruchomości od osób prawnych,
c. podatku leśnego (od osób fizycznych i osób prawnych),
d. podatku rolnego (od osób fizycznych i osób prawnych),
e. podatek od środków transportowych (od osób fizycznych i osób prawnych),
f. opłaty za gospodarowanie odpadami komunalnymi.
12. Udostępnianie danych użytkownika następuje po zalogowaniu się użytkownika na jego
indywidualne konto. Dane udostępniane są tylko w odniesieniu do konta danego podatnika i po jego uwierzytelnieniu, także za pośrednictwem profilu zaufanego.
13. Po zalogowaniu na swoje konto użytkownik musi mieć możliwość:
a. wyświetlenia informacji o wszystkich swoich należnościach wobec gminy Zamawiającego pobranych z SD w zakresie wskazanym w pkt 11.
b. wyszukiwania i wyświetlenia konkretnej należności według rodzaju (np. podatek od środków transportowych, podatek rolny itd.), daty, terminu płatności itp.
c. wyświetlania historii wszystkich interakcji finansowych mieszkańca z urzędem, jakie zostały zrealizowane poprzez system,
d. podglądu dokumentów (deklaracji, decyzji, innych pism) dotyczących karty podatkowej danego podatnika z możliwość ich automatycznego pobrania,
e. wyświetlenia stanu posiadania podatnika (dla podatku rolnego, leśnego, od nieruchomości),
f. wyświetlenia wykazu pojazdów zgodnie ze złożoną deklaracją.
14. System musi 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.
15. System musi pozwalać na wnoszenie opłat za pośrednictwem systemu płatności
elektronicznych w różny sposób tzn. przez wygenerowanie płatności na wybraną należność i opłacenie, lub na zaznaczenie kilku należności i zapłacenie je jednym przelewem.
16. Możliwość ustawienia sortowania wyświetlanych danych rosnąco lub malejąco względem dowolnego z wyświetlanych parametrów należności.
17. Jeśli należność jest płatna w ratach (np. należności podatkowe, należności rozłożone przez urząd na raty) System winien również przedstawiać klientowi informację, którą ratę kwota płatności stanowi.
18. System musi posiadać mechanizmy kontroli i bezpieczeństwa chroniące użytkowników przed kilkukrotnym wniesieniem płatności z tego samego tytułu.
19. System musi generować komunikaty informujące i/lub ostrzeżenia wizualne dla użytkownika podczas próby ponownego zlecenia płatności dla należności, dla których płatność została
zlecona za pośrednictwem por-talu, a transakcja jeszcze jest przetwarzana.
20. Możliwość wydrukowania wypełnionego polecenia przelewu bankowego lub pocztowego, dla
zaznaczonej jednej lub zaznaczonych wielu należności.
21. Możliwość wysyłania przypomnień o terminie płatności za pośrednictwem systemu
komunikacji elektronicznej z interesantem, w tym:
22. możliwość zaznaczenia, ile dni przed terminem płatności powinna być wysłana informacja przypominająca do użytkownika,
23. możliwość wyboru kanału komunikacji realizowanej przez moduł komunikacji elektronicznej
(np. email, sms).
24. Wygenerowane płatności zlecone za pośrednictwem systemu, ale jeszcze nie zaksięgowane
powinny zawierać informacje takie jak: nr konta bankowego na które została przelana płatność, kwota i data zlecenia, status zlecenia oraz data wykonania.
25. Możliwość ustawienia sortowania wyświetlanych danych rosnąco lub malejąco względem dowolnego z wyświetlanych parametrów.
26. Możliwość wyszukiwania lub filtrowania należności według co najmniej: konta bankowego na które została przelana płatność, rodzaju należności, kwoty, typu płatności, stanu zlecenia, daty zlecenia.
27. Możliwość przeglądu operacji księgowych już zrealizowanych tzn. opłaconych (wpłaty, zwroty, przeksięgowania).
28. Przegląd operacji księgowych już zrealizowanych na należnościach (wpłaty, zwroty,
przeksięgowania) z wyszczególnionym dla każdej operacji co najmniej: jej rodzaju, konta bankowego na którym została za-księgowana operacja, identyfikator, rok, rata, kwota, vat, odsetki, kwota zapłacona faktycznie, data i godzina przelewu.
29. Możliwość ustawienia sortowania wyświetlanych danych rosnąco lub malejąco względem dowolnego z wyświetlanych parametrów.
30. Możliwość ukrycia wyświetlania wybranych parametrów operacji.
31. System musi umożliwiać zalogowanemu użytkownikowi dostęp do danych z systemów dziedzinowych w ww. opisanym zakresie z możliwością dokonywania zapłat za
pośrednictwem systemu płatnościowego, również na urządzeniach mobilnych. Wymaganie
to może być zrealizowane przez responsywny interfejs i/lub aplikację mobilną.
32. System musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji.
33. System musi umożliwiać komunikację elektroniczną z interesantem przy wykorzystaniu modułu elektronicznej komunikacji (rozumianego jako grupa funkcjonalności systemu e- należności bądź odrębny moduł zintegrowany z tym systemem) oraz aplikacji moblinej.
W zakresie komunikacji elektronicznej z interesantem:
34. System powinien umożliwiać integrację z ePUAP.
35. System powinien umożliwiać wysyłanie drogą elektroniczną wiadomości o ważnych wydarzeniach i przedsięwzięciach realizowanych przez jednostkę Zamawiającego, zagrożeniach, czy indywidualnych sprawach związanych z obsługą obywateli.
36. System powinien 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.
37. System w zakresie obsługi komunikacji elektronicznej z interesantem powinien być dostępny tylko dla zalogowanych użytkowników, pracowników urzędu.
38. System powinien umożliwiać tworzenie dowolnej liczby kont użytkowników wewnętrznych (pracowników urzędu) z oznaczeniem administratorów portalu, którzy posiadają rozszerzone uprawnienia x.xx. do publikacji artykułów i aktualności oraz administrowania systemem.
39. System powinien umożliwiać zarządzanie danymi interesantów zarejestrowanych w
systemie.
40. System powinien umożliwiać wysyłanie wiadomości do odbiorców poprzez pocztę e-mail, sms (system powinien umożliwiać integrację z zewnętrznym dostawcą usług bramki sms) oraz aplikację mobilną.
41. System powinien umożliwiać tworzenie wiadomości, z określeniem co najmniej: kategorii wiadomości, jej tematu i treści.
42. System powinien umożliwiać wybór jednego lub wielu kanałów dystrybucji wiadomości dla jednej wiadomości.
43. System powinien umożliwiać tworzenie szablonów wiadomości.
44. System powinien umożliwiać zarządzanie grupami mieszkańców, do których mają być wysłane wiadomości (tworzenie, edycja i usuwanie).
45. System powinien umożliwiać wysyłanie wiadomości do grupy osób lub do jednej, wybranej
osoby.
46. W przypadku wysyłania wiadomości do wielu odbiorców, system powinien umożliwiać tworzenie grup osób w oparciu o lokalizację.
47. System powinien umożliwiać tworzenie i zapisywanie grup odbiorców.
48. System powinien umożliwiać wysyłanie wiadomości natychmiast lub w dowolnie określonym terminie późniejszym.
49. System powinien umożliwiać modyfikację niewysłanych wiadomości lub wstrzymanie ich wysyłki.
50. System powinien obsługiwać dziennik zdarzeń, w którym zapisywane będą minimum następujące zdarzenia:
a. dodawanie, edycja i usuwanie danych mieszkańców,
b. dodawanie, edycja i usuwanie danych użytkowników systemu,
c. reset hasła użytkowników systemu,
d. zmiana uprawnień użytkownika systemu,
e. dodawanie, edycja i usuwanie wiadomości,
f. dodawanie, edycja i usuwanie grup odbiorców,
g. archiwizacja dziennika zdarzeń i komunikacji.
51. System powinien obsługiwać dziennik komunikacji, w którym zapisywane będą informacje związane z wysyłką komunikatów.
52. Integracja z ePUAP:
a. system powinien umożliwiać integrację z dedykowaną skrytką urzędu,
b. system powinien umożliwiać skonfigurowanie komunikacji z ePUAP (skrytka,
certyfikat i hasło),
c. system powinien automatycznie pobierać, z dedykowanej skrytki ePUAP, dane z
wypełnionych przez rejestrujące się osoby formularzy i rejestrować je w bazie, tylko w przypadku, kiedy dane formularza zostały podpisane profilem zaufanym,
d. system powinien umożliwiać wysyłkę wiadomości, podpisanych profilem zaufanym, na konta ePUAP zarejestrowanych osób, które podały swój adres skrytki ePUAP.
e. Integracja z dziedzinowym systemem podatkowym:
f. system powinien udostępniać niezbędne mechanizmy komunikacji dwustronnej
(interfejs API), umożliwiające wymianę informacji z systemem dziedzinowym,
g. system powinien umożliwiać wyświetlanie informacji podatkowych generowanych przez podatkowy system dziedzinowy przez obywatela, przy czym informacja taka musi trafić do właściwej, zarejestrowanej w systemie osoby, która w trakcie procesu rejestracji podała PESEL i/lub NIP (parametr identyfikacyjny),
h. system powinien automatycznie weryfikować zgodność parametru identyfikacyjnego
z systemu dziedzinowego z przechowywanym w swoim rejestrze obywateli,
i. system powinien obsługiwać przekazanie informacji dot. minimum następujących typów danych z podatkowego systemu dziedzinowego:
j. Informacja o wystawionej decyzji
k. Informacja o zbliżającym się terminie płatności
l. Informacja o zaległości
m. Wezwanie do złożenia deklaracji
n. cała komunikacja pomiędzy systemem dziedzinowym, a systemem powinna być zabezpieczona przed nieautoryzowanym dostępem,
o. system powinien udostępniać dziedzinowemu systemowi podatkowemu informacje
o statusie dokonanej opłaty.
53. Aplikacja mobilna:
a. powinna umożliwiać odbieranie wiadomości wysyłanych przez jednostkę Zamawiającego,
b. powinna wyświetlać wiadomości z podziałem na kategorie wiadomości,
c. powinna obsługiwać kod autoryzacji, który służyć będzie jednoznacznej identyfikacji obywatela, przy czym, każdy zarejestrowany w systemie obywatel, musi
automatycznie otrzymać określonym kanałem komunikacji (ePUAP, email, sms) lub w przypadku rejestracji w urzędzie, w formie pisemnej, wygenerowany przez system kod,
d. powinna umożliwiać wybór określonych grup komunikatów przez autoryzowanych użytkowników aplikacji mobilnej, którymi jest on zainteresowany,
e. aplikacja mobilna powinna pracować na systemach co najmniej Android i iOS w wersjach aktualnych (wspieranych przez producentów/wydawców) na dzień składania oferty lub nowszych,
f. aplikacja mobilna powinna zostać udostępniona na powszechnie dostępnych
serwisach do ich pobierania,
g. aplikacja mobilna powinna dawać możliwość zmiany kontrastu i wielkości liter prezentowanych treści.
Wdrożenie systemu obejmie co najmniej czynności wskazane w punkcie „Wymagania ogólne dla wdrożeń Oprogramowania Aplikacyjnego”.
1.2. #02# Dostosowanie formularzy e-usług
Zadanie obejmuje elektronizację następujących usług publicznych świadczonych przez jednostkę Zamawiającego na 4. i 5. poziomie dojrzałości:
1. Rozłożenie należności na raty, odroczenie terminu, umorzenie zaległości, umorzenie odsetek;
2. Obsługa podatku rolnego / Deklaracja na podatek rolny;
3. Obsługa podatku leśnego /Deklaracja na podatek leśny;
4. Obsługa podatku od nieruchomości / Deklaracja na podatek od nieruchomości;
5. Informacja w sprawie podatku rolnego;
6. Informacja w sprawie podatku leśnego;
7. Informacja w sprawie podatku od nieruchomości;
8. Zwrot podatku akcyzowego zawartego w cenie oleju napędowego wykorzystywanego do produkcji rolnej;
9. Obsługa podatku od środków transportowych / Deklaracja na podatek od środków
transportowych;
10. Obsługa opłaty za gospodarowanie odpadami komunalnymi / Deklaracja o wysokości opłaty;
11. Usługa e-należności
oraz następujących usług publicznych świadczonych przez jednostkę Zamawiającego - na 3. poziomie
dojrzałości:
12. Wniosek o udostępnienie informacji publicznej;
13. Zezwolenie na sprzedaż napojów alkoholowych;
14. Zezwolenie na zajęcie pasa drogowego;
15. Zezwolenie na umieszczenie ciała obcego w pasie drogowym;
16. Wniosek o lokalizację zjazdu;
17. Przyznanie dodatku mieszkaniowego;
18. Zryczałtowany dodatek energetyczny.
Dla ww. usług Wykonawca zrealizuje:
1. wskazanie odpowiednich aktów prawnych jako źródeł wytycznych i ograniczeń dotyczących
dokumentów odnoszących się do danej elektronizowanej usługi publicznej,
2. identyfikację w treści dokumentów zapisów wymagających modyfikacji w wyniku elektronizacji usług publicznych,
3. opracowanie na podstawie danych przekazanych przez Zamawiającego opisów i karty e-usług w formie zgodnej z platformą ePUAP,
4. 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,
5. 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 lub w przypadku jeżeli nie będzie
możliwości wykorzystania dla e-usługi publicznej formularzy dostępnych w CRWDE prace obejmą przygotowanie i zgłoszenie formularzy ePUAP dla każdej z wybranych e-usług publicznych, w tym:
a. przygotowanie i uruchomienie e-formularzy w formatach XML na platformie ePUAP oraz uzgodnienie ich z właściwym ministerstwem (jeśli dotyczy),
b. opracowanie wzorów e-formularzy w formatach PDF, które muszą zgodnie z prawem zostać przekazane do repozytorium dokumentów wdrożonego systemu EZD,
c. pomoc w przygotowaniu merytorycznym wniosków niezbędnych do umieszczenia opracowanych e-formularzy w Centralnym Repozytorium Wzorów Dokumentów zgodnie z obowiązującymi przepisami
przy uwzględnieniu wymagań wskazanych w rozdziale „Ogólne wymogi w zakresie tworzenia formularzy ePUAP”.
6. wykonanie stosownych rozwiązań technicznych zapewniających integrację z systemami dziedzinowymi i EZD, w tym szczególnie dla e-usług ukierunkowanych na obsługę spraw podatkowych.
Wykonawca przeprowadzi instruktaże pracowników obsługujących procesy związane z obsługą e- usług w odpowiednich systemach (dziedzinowych, EZD oraz innych, jeśli będzie to konieczne).
Zamówienie obejmuje dostawę i wdrożenie brokera integracyjnego - modułu integrującego systemy dziedzinowe z pozostałymi systemami dostarczanymi w ramach zamówienia w zakresie
umożliwiającym spełnienie wymagań ogólnych (wskazanych w punkcie „Wymagania ogólne dla
przedmiotu zamówienia”) oraz szczegółowych wskazanych w opisach dotyczących poszczególnych systemów. Moduł integrujący musi spełniać nw. wymagania:
1. 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.
2. Moduł musi zapewniać integrację systemów dziedzinowych z innymi systemami (m. in. systemem EZD). Musi być możliwość automatycznego przekazywania dokumentów
tworzonych w tych systemach wraz z możliwością pobrania danych niezbędnych do utworzenia teczek spraw bezpośrednio w systemach obiegu dokumentów.
3. Moduł musi zapewniać synchronizację kartotek kontrahentów na poziomie systemów dziedzinowych zapewniając dwukierunkową wymianę danych.
4. Moduł musi udostępniać metody komunikacyjne niezbędne do funkcjonowania systemu e- należności 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.
5. 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.
6. Moduł musi umożliwiać administratorom tworzenie nowych oraz zarządzanie udostępnianymi usługami i interfejsami.
7. 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.
Wdrożenie modułu obejmie co najmniej czynności wskazane w punkcie „Wymagania ogólne dla
wdrożeń Oprogramowania Aplikacyjnego”.
Informacje dotyczące integracji systemów
1. Zgodnie z wymaganiami przedstawionymi w rozdziale „Wymagania ogólne dla przedmiotu
zamówienia” oraz w szczegółowych wymaganiach dla poszczególnych systemów, w celu realizacji zamówienia konieczna jest integracja pomiędzy dostarczanymi oraz
rozbudowywanymi, funkcjonującymi w jednostce Zamawiającego systemami.
2. Systemy funkcjonujące w jednostce Zamawiającego obsługujące procesy podlegające informatyzacji w ramach zamówienia to:
a. system Elektronicznego Obiegu Dokumentów firmy R-Soft Studio Sp. z o.o.
b. systemy obsługujące podatki lokalne, podatek transportowy oraz zwrot podatku akcyzowego – firmy Usługi Informatyczne INFO-SYSTEM Roman i Xxxxxxx Xxxxxxx sp.j,
c. system obsługujący finanse i księgowość firmy "WIZARD" S.C. Xxxxxxxx Xxxxxxxx ,
Xxxxxxxx Xxxxxxxx,
d. system firmy ARISCO Sp. z o.o. obsługujący opłaty za gospodarowanie odpadami
komunalnymi,
e. system obsługujący ewidencję ludności - Centralny Ośrodek Informatyki
3. Nawiązanie współpracy i zawarcie ewentualnych umów z autorami i/lub dostawcami ww. systemów funkcjonujących w jednostce Zamawiającego, jeżeli jest to konieczne do
wykonania przedmiotu zamówienia, jest zadaniem Wykonawcy.
4. Rozpoznanie w zakresie możliwości technicznych przeprowadzenia prac integracyjnych jest zadaniem Wykonawcy. Zamawiający nie dysponuje dokumentacją umożliwiającą integrację
tych systemów, nie posiada informacji o interfejsach API udostępnianych przez ww. systemy. Zamawiający nie posiada praw autorskich do ww. systemów, które umożliwiałyby ich modyfikację.
5. Koszty rozbudowy i/lub modernizacji SD i EZD koniecznych do zintegrowania tych systemów z systemami wdrażanymi w ramach niniejszego zamówienia muszą być uwzględnione przez
Wykonawcę w cenie oferty.
6. Jeśli Wykonawca w ramach zamówienia dokonuje wymiany systemów dziedzinowych i EZD funkcjonujących w jednostce Zamawiającego:
a. Koszt dostarczenia i wdrożenia rozwiązań zastępujących systemy dotychczas funkcjonujące u Zamawiającego musi zostać wkalkulowany w cenę ofertową, z zachowaniem warunków licencjonowania dla Oprogramowania Aplikacyjnego opisanych we Wzorze umowy (Załącznik nr 7 do SIWZ).
b. Nowe rozwiązania muszą posiadać w pełni odpowiadać wymaganiom określonym dla poszczególnych systemów w niniejszym dokumencie.
c. Wykonawca przeprowadzi instruktaże stanowiskowe i będzie świadczył asystę
techniczną w zakresie i wymiarze czasowym umożliwiającym pracownikom jednostki zamawiającego płynną obsługę systemów.
d. W przypadku systemów dziedzinowych Wykonawca przeprowadzi migrację danych w zakresie wskazanym przez Zamawiającego na swój koszt z uwzględnieniem
postanowień ust. od 7 do 13.
7. Ewentualna wymiana systemów może objąć wszystkie systemy będące przedmiotem
integracji, wskazane w ust. 2, bądź tylko wybrane.
8. Dla systemów dziedzinowych Wykonawca przeprowadzi analizę dotychczasowego sposobu organizacji pracy w obszarach poszczególnych SD ze wskazaniem źródeł danych do migracji. Efektem analizy będzie opracowanie Specyfikacji migracji. Musi ona zawierać co najmniej:
a. listę systemów i modułów, dla których dokonywany będzie proces migracji;
b. zakres danych podlegający procesowi migracji automatycznej;
c. zakres danych wymagający konfiguracji ręcznej;
d. kolejność dostarczania modułów i systemów migrowanych, uwzględniająca zależności międzysystemowe wymagane do działania nowych SD w połączeniu z dostarczanymi systemami – spójnie z Harmonogramem Ramowym;
e. rekomendowane terminy cząstkowe, umożliwiające osiągniecie wdrożenia
docelowego – spójnie z Harmonogramem Ramowym;
f. listę wymaganych czynności wykonywanych po stronie Zamawiającego zawierającą co najmniej terminy, w których Zamawiający powinien dostarczyć dane wymagane
do migracji; powinien dokonać czynności weryfikujących migracje wstępne; powinien umożliwić dostęp fizyczny do miejsca instalacji sprzętu.
9. Minimalny zakres procesu migracji dla SD to: kartoteki interesantów, właściciele
nieruchomości, przedmioty opodatkowania, adresy nieruchomości, nr ewidencyjne, saldo BO na koniec roku (w zakresie danych księgowych systemów podatkowych), bilans otwarcia na przełomie roku, rozrachunki, kontrahentów. Migracja danych w zakresie systemów podatkowych powinna dodatkowo objąć także okres 5 lat wstecz wraz z danymi dotyczącymi
naliczonych podatków oraz wystawionych decyzji podatkowych, tak aby umożliwić
wystawianie decyzji zmieniających za lata ubiegłe oraz prawidłowe ich ujęcie w sprawozdaniu dotyczącym skutków obniżenia stawek podatków.
10. W przypadku EZD migracji podlegają kartoteki personalne, wykazy akt oraz struktura organizacyjna.
11. Wykonawca może zastosować dowolny wybrany przez siebie sposób przeniesienia danych z systemu źródłowego tj. systemu użytkowanego przez Zamawiającego do nowego systemu, w tym:
a. Migrację automatyczną, czyli przeniesienie danych przy pomocy oprogramowania,
bez stosowania ręcznego przenoszenia danych,
b. Migrację półautomatyczną, czyli ręczne przenoszenie danych ze wspomaganiem
oprogramowania do migracji,
c. Migrację ręczną, czyli ręczne przenoszenie danych bez wspomagania
oprogramowania do migracji.
12. Za przeniesienie danych z systemu źródłowego do nowego odpowiada Wykonawca.
13. Za merytoryczną weryfikację danych po migracji odpowiada Zamawiający. Celem weryfikacji danych jest uzyskanie wystarczającej, to jest umożliwiającej rozpoczęcie użytkowania systemu, jakości danych w docelowym Systemie.
1.4. #01# Modernizacja systemu EZD
Wymagana jest modernizacja (rozumiana jako dostawę nowych modułów rozbudowujących jego funkcjonalność) systemu EZD funkcjonującego w jednostce Zamawiającego - Urzędzie Gminy Chełm (system firmy R-Soft Studio Sp. z o.o.) lub wymiana systemu na zasadach opisanych w rozdziale
„Broker integracyjny”. System po modernizacji lub wymianie musi posiadać zakres nw. funkcjonalny:
1. Oprogramowanie musi przechowywać wszystkie dane w postaci bazy danych. Dopuszcza się przechowywanie poza bazą danych plików w postaci repozytorium dyskowego. Ich
integralność z systemem musi być zapewniona przez metadane opisujące poszczególne pliki.
2. System powinien być zbudowany w architekturze trójwarstwowej, złożonej z:
a. kodu generowanego do interpretacji przez przeglądarkę internetową,
b. serwera aplikacji (pośredniczącego między żądaniami programu klienckiego, a
motorem bazy danych),
c. motoru bazy danych, zarządzającego SQL-ową bazą danych.
3. Oprogramowanie musi działać w środowiskach systemowych bazujących na systemach
operacyjnych dostarczanych w ramach zamówienia.
4. System musi być w pełni skalowalny. Skalowalność ma występować pod kątem zwiększania się ilości danych, jak i zmian funkcjonalności wynikających ze zmian prawnych i warunków praktycznych.
5. System musi posiadać widok indywidualny. Użytkownik ma wgląd tylko do modułów, do których posiada uprawnienia.
6. System musi posiadać pomoc kontekstową, umożliwiającą wyświetlanie zdefiniowanych okien z pomocnymi informacjami dotyczącymi najważniejszych obszarów systemu.
7. System musi zapewniać udostępnienie danych innym systemom w formie i zakresie
ustalonym w trakcie wdrożenia, w sposób automatyczny lub na żądanie operatora w
określonym czasie, wykorzystując jeden ze standardowych formatów wymiany danych x.xx. csv, xml, txt, xls, rtf, html. Format powinien być zgodny z wymaganiami rozporządzenia Rady Ministrów z dn. 12 kwietnia 2012 o Krajowych Ramach Interoperacyjności.
8. System powinien posiadać funkcje współpracy na stanowiskach klientów z popularnymi
programami biurowymi.
1.4.2. Dokumenty przychodzące i wychodzące
1. System musi umożliwiać prowadzenie rejestru korespondencji przychodzącej umożliwiający
co najmniej:
a. sortowanie zawartości rejestru,
b. filtrowanie łączne (wynik wyszukiwania musi spełniać łącznie wszystkie wybrane kryteria) i rozdzielne (wynik wyszukiwania musi spełniać przynajmniej jedno z wybranych kryterium),
2. Filtrowanie powinno umożliwiać określenie parametrów niezbędnych do wyszukania
dokumentu takich jak:
a. Dane dokumentu: identyfikator, numer dokumentu, zakresy numeracji, tytuł oraz
rodzaj dokumentu, sposób dostarczenia, znak sprawy, etc.,
b. Informacje o dekretacjach: użytkownik dekretujący, na kogo zadekretowano, przypisani użytkownicy, działy, daty dekretacji, przedziały dat dekretacji.
c. Okresie wprowadzania dokumentów: data na piśmie, data nadania, data wpływu przesyłki, data rejestracji, przedziały dat, osoba rejestrująca dokument, etc.,
d. Danych interesanta: dane adresowe, dane identyfikacyjne.
3. System musi umożliwić wyświetlanie danych rejestru korespondencji przychodzącej wg co najmniej następujących widoków:
a. Wszystkich pozycji rejestru,
b. Dokumentów bez dekretacji,
c. Dokumentów zwróconych,
d. Dzisiaj zarejestrowanych,
e. Usuniętych.
4. System musi pozwalać na drukowanie całości rejestru korespondencji przychodzącej lub wybranych pozycji. System musi mieć możliwość przygotowania wydruku rejestru
przekazanej korespondencji z miejscem na złożenie podpisu przez pracownika odbierającego
dokument.
5. System musi umożliwiać wykonywanie akcji grupowych na dokumentach:
6. możliwość zaznaczania wybranych lub wszystkich pozycji rejestru oraz dekretacji,
7. możliwość zaznaczania wybranych pozycji rejestru oraz umieszczenie ich w dodatkowych
rejestrach.
8. System musi obsługiwać rejestrację dokumentów przychodzących zarówno w formie
papierowej, jak i w formie elektronicznej (przekazywanych za pośrednictwem: ePUAP oraz
poczty elektronicznej).
9. Formularz rejestracji przesyłki wpływającej musi pozwalać na wprowadzenie co najmniej następujących danych: interesant, data nadania przesyłki, data wpływu przesyłki, rodzaj dokumentu, tytuł dokumentu, znak przesyłki, sposób dostarczenia, typ danych, opis
dokumentu, słowa kluczowe usprawniające wyszukiwanie korespondencji.
10. Wybór interesanta podczas rejestracji przesyłki musi uwzględniać nw. możliwości:
a. wybranie interesanta znajdującego się w bazie danych,
b. wprowadzenie do bazy danych nowego interesanta znajdującego bez konieczności
opuszczania formularza rejestracji,
c. możliwość edycji istniejącego interesanta poprzez aktualizację lub korektę pozycji
znajdującej się w bazie danych bez konieczności opuszczania formularza rejestracji,
d. możliwość przypisania kilku interesantów do danego dokumentu.
11. System musi umożliwiać odebranie poczty elektronicznej za pomocą wbudowanego klienta pocztowego POP3 oraz SMTP i umożliwić rejestrację w rejestrze przesyłek wpływających lub bezpośrednie dołączenie wiadomości z załącznikami do akt sprawy. Klient pocztowy
powinien składać się, co najmniej z następujących elementów: skrzynka odbiorcza – z której
poziomu musi istnieć możliwość rejestracji wiadomości w rejestrze korespondencji
przychodzącej lub dołączanie dokumentów do istniejącej sprawy, kopie robocze, elementy wysłane elementy usunięte, spam, książka adresowa.
12. System musi umożliwiać skanowanie, z wykorzystaniem interfejsu, np. HTML5,
poszczególnych dokumentów, wchodzących w skład przesyłki wpływającej (jedna przesyłka może składać się z wielu dokumentów). Interfejs do skanowania powinien posiadać, co najmniej następujące narzędzia edycji:
a. obrót obrazu o dowolny kąt,
b. przerzucania obrazu (poziomo-pionowo),
c. zamiany kolejności stron,
d. zapis do PNG, PDF, JPEG,
e. zmiana kontrastu,
f. wybór rozdzielczości,
g. usuwania stron,
h. wybór skanowania dwustronnego.
13. System musi umożliwiać korzystanie z wielu skanerów jednocześnie, użytkownik musi mieć możliwość wyboru urządzenia skanującego.
14. System musi posiadać wbudowany mechanizm masowego, zautomatyzowanego skanowania zarejestrowanej korespondencji umożliwiający użytkownikowi szybką rejestrację korespondencji:
a. mechanizm musi rozpoznawać kody kreskowe, które zostały wcześniej
wygenerowane i naklejone na dokument, a które pełnią rolę separatorów,
b. mechanizm musi przypisywać zeskanowane grupowo dokumenty do odpowiednich, wcześniej zdefiniowanych metadanych,
c. operacja automatycznego przypisania dokumentów do metadanych może odbywać się podczas skanowania (w tle) lub po zeskanowaniu grupy dokumentów.
15. Dla dokumentów papierowych nie podlegających skanowaniu oraz dla dokumentów na nośnikach elektronicznych niepodlegających kopiowaniu do systemu musi być możliwość stworzenia metryki, z co najmniej takimi danymi, jak: tytuł, identyfikator, opis dokumentu.
16. Podczas rejestracji korespondencji, system musi umożliwiać wybór interesanta z bazy
Interesantów oraz musi umożliwiać dodanie nowego Interesanta w przypadku jego braku w bazie danych.
17. System musi umożliwiać dodanie jednego lub więcej interesantów dotyczących danej przesyłki.
18. EZD musi umożliwiać generowanie i drukowanie naklejek z kodami kreskowymi na
dokumenty papierowe oraz nośniki i odnajdywanie na podstawie zeskanowanej nalepki
odwzorowania cyfrowego bądź metryki danego dokumentu.
19. System musi umożliwiać generowanie potwierdzenia przyjęcia przesyłki wpływającej przez punkt kancelaryjny, w ramach potwierdzenia musi występować kod kreskowy przesyłki oraz oznaczenie nadawcy (imię i nazwisko/nazwa, adres zamieszkania/siedziba), numer z
dziennika korespondencji przychodzącej, data wpływu oraz ilość załączników.
20. System musi pozwalać na rejestrację zwrotów przesyłek w przypadku ich niedoręczenia oraz pocztowych potwierdzeń odbioru (zwrotek).
21. System musi pozwalać na prowadzenie wielu punktów kancelaryjnych rejestrujących przesyłki.
22. System musi posiadać wbudowany mechanizm pozwalający na sprawdzenie, czy otrzymane pismo nie zostało już zarejestrowane. Mechanizm ten musi weryfikować, co najmniej znak dokumentu oraz dane nadawcy.
23. System w momencie rejestracji dokumentu musi umożliwiać wybór rodzaju dokumentu ze słownika konfigurowalnego w Systemie.
24. System musi umożliwiać przypisanie rejestrowanego dokumentu do składu
chronologicznego.
25. System musi posiadać możliwość wypożyczania nośnika ze składu chronologicznego.
26. System pozwala na wprowadzenie informacji o lokalizacji dokumentu papierowego/nośnika.
27. System umożliwia umieszczenie przesyłki w dodatkowym rejestrze co pozwala na
segregowanie tematyczne przesyłek.
28. System musi posiadać funkcjonalność OCR umożliwiającą w szybki sposób przeniesienie
danych z zeskanowanego pisma do formularza rejestracji pole po polu.
29. System musi posiadać opcje dekretacji dokumentu z poziomu kancelarii.
30. System musi posiadać możliwość wybrania osoby dekretującej.
31. System musi umożliwiać określenie osoby odpowiedzialnej za ostateczne załatwienie sprawy.
32. System musi umożliwiać na etapie dekretacji wprowadzenie uwag. Odbiorca dokumentu będzie mógł zapoznać się z wprowadzoną uwagą.
33. System musi pozwalać na zarejestrowanie przesyłki przychodzącej bez konieczności
wykonania dekretacji. Zarejestrowany dokument można zadekretować w późniejszym czasie.
34. W module przesyłek wpływających muszą znajdować się widoki w których będą znajdowały się określone dokumenty, co najmniej: Wszystkie, bez dekretacji, zwrócone, zarejestrowane dzisiaj, usunięte.
35. System musi umożliwiać sprawdzenie historii dokumentu. Każdy wpis w historii dokumentu musi zawierać co najmniej datę zmiany, imię, nazwisko pracownika dokonującego zmiany oraz opis zmiany.
36. Użytkownik po dodaniu wpisu musi mieć możliwość jego edycji oraz zarządzania dostępnością.
37. Dekretacja może odbywać się na pojedynczego użytkownika lub na kierownika komórki organizacyjnej lub na kilku użytkowników/kilka komórek organizacyjnych, z określeniem użytkownika (komórki) wiodącego i współpracujących.
38. System musi umożliwiać dekretację hurtową, tj. zaznaczenie wielu dokumentów w jednym
widoku i zadekretowanie każdego z nich do różnych komórek/użytkowników.
39. System pozwala na wysyłkę powiadomień e-mail.
40. System pozwala na określenie terminu realizacji dla dekretowanego dokumentu.
41. System umożliwia eksport do druku listy przesyłek wpływających.
42. System umożliwia anulowanie błędnie dodanego dokumentu z poziomu kancelarii.
43. System umożliwia zeskanowanie kodu kreskowego nadanego w Systemie i naklejonego na
dokument w celu jego szybkiego wyszukania.
44. System musi umożliwiać prowadzenie rejestru kancelaryjnego przesyłek wychodzących.
45. System musi umożliwiać oznaczenie dokumentu do wysłania jako wysłanego.
46. System musi zapewnić możliwość drukowania kopert, zwrotek, książki pocztowej zgodnie z wymaganiami Poczty Polskiej lub wzorami będącymi załącznikami do umowy z Pocztą Polską. System musi pozwalać na hurtowy wydruk danego rodzaju dokumentu dla wielu przesyłek jednocześnie.
47. System musi pozwolić na łączenie wielu przesyłek wychodzących w jedną kopertę, w przypadku, gdy użytkownik stwierdzi, że dotyczą one tego samego adresata.
48. System musi umożliwiać cofnięcie przesyłki z przesyłek wychodzących.
49. System musi umożliwiać sporządzenie pocztowej książki nadawczej do zróżnicowanych wymagań występujących w różnych urzędach pocztowych.
50. System umożliwia eksport do druku listy przesyłek wychodzących .
51. System musi posiadać możliwość dołączenia kopii wysyłanego dokumentu do składu
chronologicznego.
52. System musi posiadać funkcjonalność pozwalającą na odnotowywanie i przechowywanie w
Systemie informacji o odebraniu przez adresata korespondencji wychodzącej. Taka informacja musi być łatwo dostępna dla nadawcy korespondencji.
53. Rejestr korespondencji wychodzącej powinien umożliwiać filtrowanie oraz sortowanie zawartości rejestru.
54. Filtrowanie rejestru powinno umożliwiać określenie parametrów niezbędnych do wyszukania
dokumentu takich jak:
a. Dane dokumentu: identyfikator, zakres identyfikatorów numer w rejestrze, zakresy numeracji, tytuł oraz rodzaj dokumentu, etc.,
b. Informacje o wysyłającym, sposobie wysyłki.
c. Okresie wprowadzania dokumentów:, data nadania, data wysyłki, przedziały dat,
etc.,
d. Danych interesanta: dane adresowe, dane identyfikacyjne.
55. System musi umożliwiać wyświetlanie danych rejestru korespondencji wychodzącej wg co
najmniej następujących widoków:
a. wszystkich pozycji rejestru,
b. wysłane,
c. niewysłane,
d. koperty.
56. System musi pozwalać na drukowanie całości rejestru korespondencji wychodzącej lub
wybranych pozycji.
57. System musi pozwalać na wykonywanie akcji grupowych na dokumentach:
a. możliwość zaznaczania wybranych lub wszystkich pozycji drukowanie kopert,
b. możliwość zaznaczania wybranych lub wszystkich pozycji dodawanie do książki
nadawczej,
c. możliwość zaznaczania wybranych lub wszystkich pozycji dodawanie wysyłanie przesyłek.
1.4.3. Integracja z platformą ePUAP
1. Integracja z platformą ePUAP powinna być umożliwiona w co najmniej następującym
zakresie:
a. możliwości automatycznego odbierania oraz wysyłania dokumentów na platformę ePUAP bezpośrednio z poziomu EZD,
b. pełnej komunikacji z ePUAP bez konieczności logowania się na platformie ePUAP,
c. pobierania dokumentów wraz z UPP (Urzędowe Poświadczenie Przedłożenia) lub UPD (Urzędowe Poświadczenie Doręczenia) ze skrzynki ePUAP z rozdzieleniem na skrytki zdefiniowane w obrębie skrzynki (konta)
d. pobierane dokumenty z platformy ePUAP powinny trafiać na listę dokumentów oczekujących na rejestrację w dedykowanym rejestrze, bądź rejestrować się automatycznie w we wskazanym dzienniku po zastosowaniu odpowiedniego schematu mapowania dla formularza ePUAP,
e. EZD powinien posiadać mechanizm automatycznego wyszukiwania w swojej bazie
interesantów informacji o tym czy dany podmiot znajduje się już w bazie. Jeśli tak – dane opisujące nadawcę są automatycznie wypełnione na etapie rejestracji dokumentu lub scalane w przypadku aktualizacji,
f. automatycznego dołączania UPO do odebranych/wysyłanych wiadomości bez konieczności rejestracji w rejestrze pism wpływających,
g. podpisania dokumentów/formularzy profilem zaufanym
h. podpisania dokumentów/formularzy podpisem kwalifikowanym
i. możliwość utworzenia sprawy na podstawie odebranego dokumentu,
j. automatycznego odesłania odpowiedzi na pismo wpływające z ePUAP do wszystkich
stron zainteresowanych w prowadzonej w systemie sprawie,
k. obsługi kilku skrytek ePUAP Zamawiającego.
1.4.4. Obsługa spraw i dokumentów – dokumenty przychodzące
1. System musi posiadać rejestr dokumentów zadekretowanych na użytkownika.
2. System umożliwia założenie sprawy z dokumentu otrzymanego przez użytkownika.
3. System pozwala na dołączenie otrzymanego dokumentu do już prowadzonej sprawy.
4. System musi umożliwiać zwrócenie dokumentu, jeżeli nastąpiła pomyłka w dekretacji.
5. System musi umożliwiać dalsze przekazanie otrzymanego dokumentu.
6. System musi umożliwiać odłożenie dokumentu jako nie tworzącego akt sprawy.
7. System umożliwia eksport do druku listy przesyłek przychodzących zadekretowanych na użytkownika.
8. Rejestr dokumentów zadekretowanych na użytkownika powinien umożliwiać co najmniej filtrowanie (łączne i rozdzielne) oraz sortowanie zawartości rejestru.
9. Filtrowanie powinno umożliwiać określenie parametrów niezbędnych do wyszukania
dokumentu takich jak:
a. Dane dokumentu: identyfikator, numer, opis dokumentu, data pisma, data nadania, data wpływu, data rejestracji, znak obcy, typ dokumentu, typ danych, sposób dostarczenia, lokalizacja etc.
b. Informacje o dekretacjach: użytkownik dekretujący, rejestrujący dokument, przypisana komórka.
c. Okresie wprowadzania dokumentów: data pisma, data nadania, data wpływu przesyłki, data rejestracji, przedziały dat, osoba rejestrująca dokument, etc.
d. Danych interesanta: dane adresowe, dane identyfikacyjne.
10. Wyświetlanie danych w rejestrze musi być możliwe wg co najmniej następujących widoków:
a. Wszystkich pozycji rejestru,
b. dokumenty wewnętrzne,
c. dokumenty zewnętrzne,
d. dokumenty nietworzące akt sprawy.
11. System musi pozwalać na drukowanie całości rejestru lub wybranych pozycji.
12. Wykonywanie akcji grupowych na dokumentach:
a. możliwość zaznaczania wybranych lub wszystkich pozycji rejestru dołączenie
dokumentów do istniejącej sprawy.
b. możliwość zaznaczania wybranych lub wszystkich pozycji rejestru przekazanie dokumentów do innych pracowników lub grup pracowników.
1.4.5. Obsługa spraw i dokumentów - akceptacje dokumentów
1. System musi pozwalać użytkownikowi na akceptacje/odrzucenie dokumentu lub akceptację z
podpisem po przekazaniu do niego dokumentu do zaakceptowania.
2. System musi umożliwiać wieloetapową akceptację dokumentu.
3. Użytkownik powinien mieć możliwość swobodnego definiowania ścieżek akceptacji, co
najmniej:
a. akceptacja przez jednego użytkownika,
b. przesłanie dokumentu do wielu użytkowników ,akceptacja wielostopniowa; dokument po zaakceptowaniu przez jednego pracownika przekazywany jest dalej do akceptacji do kolejnej osoby zgodnie ze ścieżką akceptacji obowiązującej w danej jednostce.
4. System musi pozwalać na stworzenie ścieżki akceptacji - kolejna osoba może zaakceptować dokument dopiero wtedy, gdy poprzednia osoba w ścieżce go zaakceptowała.
5. System musi posiadać możliwość podpisania akceptacji dokumentu przez akceptującego.
6. System powinien wyświetlać w widocznym miejscu liczbę pism do akceptacji oraz liczbę plików, które należy podpisać.
7. W przypadku usunięcia wszystkich plików pisma, musi zostać ono usunięte z listy pism do
akceptacji.
1.4.6. Obsługa spraw i dokumentów – wszczynanie i prowadzenie spraw
1. System musi umożliwiać wszczynanie, prowadzenie i załatwianie spraw, przechowywanie akt sprawy i prowadzenie spisów spraw zgodnie z obowiązującymi przepisami.
2. Sprawa może być otwierana z dokumentu lub z urzędu.
3. System musi automatycznie nadawać znak spraw i zapewniać zgodność prowadzonej sprawy
z wymogami instrukcji kancelaryjnej.
4. System musi umożliwiać numerację i klasyfikację spraw w oparciu o JRWA zgodnie z instrukcją kancelaryjną.
5. System musi umożliwiać opisywanie spraw i akt sprawy zgodnie z obowiązującymi
przepisami.
6. System musi umożliwiać podgląd historii sprawy, musi przechowywać co najmniej dane w
zakresie:
a. daty oraz godziny wprowadzonej modyfikacji,
b. tytułu sprawy,
c. oznaczenia osoby wykonującej czynność,
d. określeniu wykonywanej czynności,
e. wskazanie identyfikatora dokumentu.
7. System musi zapewnić prowadzenie, podgląd oraz wydruk metryki sprawy zgodnie z obowiązującymi przepisami.
8. System musi umożliwiać określenie liczby dni potrzebnych na rozpatrzenie sprawy.
9. EZD musi umożliwiać użytkownikowi podgląd przypisanych do niego spraw i korespondencji z możliwością sortowania, filtrowania i przeszukiwania.
10. System musi umożliwiać udostępnianie sprawy innym pracownikom bezpośrednio z poziomu sprawy. Użytkownik prowadzący sprawę powinien posiadać możliwość różnicowania
poziomu uprawnień do sprawy.
11. System musi umożliwiać wysyłkę dokumentu do wybranych osób, jeżeli w sprawie występuje więcej niż jeden interesant. Taki dokument można później wysłać do pozostałych
interesantów.
12. System musi umożliwiać użytkownikowi wgląd do spraw z poziomu dokumentu oraz wgląd do dokumentów z poziomu spraw.
13. System musi posiadać część nadzorczą, która umożliwia przełożonym pełen wgląd do dokumentów, spraw i projektów pracowników podległych.
14. System musi pozwalać na określenie statusu sprawy oraz na jego modyfikację w trakcie postępowania.
15. System musi pozwalać na założenie sprawy w wybranej grupie spraw do której użytkownik posiada dostęp.
16. System musi pozwalać na określenie dostępu do sprawy podlegającej publikacji w Biuletynie
Informacji Publicznej.
17. System musi umożliwiać określenie rodzaju sprawy.
18. System musi pozwalać na dołączenie dokumentu do sprawy co najmniej jako:
a. przesyłka wychodząca / wewnętrzna,
b. akt sprawy (niebędący przesyłką).
19. System musi umożliwiać udostępnienie dokumentu innym pracownikom.
20. System musi umożliwiać określenie rodzaju dokumentu.
21. System musi pozwalać na określenie preferowanego sposobu wysyłki.
22. System musi zapewnić możliwość dodania załącznika do dokumentu z następujących źródeł:
a. szablon dokumentu,
b. plik z dysku,
c. skan dokumentu,
d. utworzenie dokumentu z poziomu zakładania sprawy.
23. System musi umożliwiać wersjonowanie dokumentów wraz z zaznaczeniem różnic pomiędzy wersjami. Użytkownik może przywrócić poprzednią wersję pliku i korzystać z niej jako aktualnej, przy czym dokument jest rozumiany jako załącznik i zbór metadanych.
24. System musi klasyfikować sprawy które powinny zostać zarchiwizowane i przenieść je do widoku ,,Do archiwum’’.
25. System musi posiadać możliwość tworzenia raportu spraw z możliwością określenia co najmniej następujących parametrów:
a. wybór komórki organizacyjnej,
b. wyboru symbolu klasyfikacyjnego sprawy,
c. rok założenia sprawy,
d. określenia przedziału czasowego (od dnia do dnia),
e. wyboru użytkownika,
f. wyboru statusu sprawy
26. Zestawienie powinno składać się minimum z następujących elementów:
a. numer sprawy,
b. tytuł sprawy,
c. nazwa podmiotu, od którego dotyczy sprawa,
d. znak przesyłki wszczynającej,
e. data wszczęcia sprawy,
f. data ostatecznego załatwienia sprawy,
g. pracownik prowadzący sprawę,
h. uwagi dotyczące sposobu załatwienia sprawy.
27. System musi posiadać możliwość tworzenia spisu spraw zgodnego z instrukcją kancelaryjną.
28. System musi umożliwiać przekazywanie uwag/komentarzy dotyczących sprawy i przygotowywanych dokumentów.
1.4.7. Obsługa dokumentów wewnętrznych
1. System musi umożliwiać umieszczanie komentarzy w pismach nietworzących akt sprawy.
2. System musi umożliwiać przeprowadzenie wielopoziomowego procesu akceptacji pism wewnętrznych nie tworzących akt sprawy oraz ich późniejszą wysyłkę do interesanta.
3. System musi umożliwiać wieloetapową akceptację dokumentu (zgodnie z instrukcją kancelaryjną podmiotu).
4. System musi umożliwiać przekazanie pisma do komórki merytorycznej.
5. System musi umożliwiać stworzenie szablonu dokumentów.
6. System musi pozwalać na określenie rodzaju dokumentu.
7. System musi umożliwiać przekazanie pisma do uzupełnienia.
8. System musi pozwalać na anulowanie pisma.
9. System musi pozwalać na usunięcie pisma.
10. System musi umożliwiać prowadzenie pism nietworzących akt sprawy umożliwiający co najmniej filtrowanie oraz sortowanie zawartości rejestru.
11. Filtrowanie powinno umożliwiać określenie parametrów niezbędnych do wyszukania
dokumentu takich jak:
a. dane dokumentu: identyfikator, zakres identyfikatorów, tytuł, rodzaj oraz opis
dokumentu, etc.,
b. danych interesanta: dane adresowe, dane identyfikacyjne
12. Możliwość wyświetlania danych w rejestrze wg co najmniej następujących widoków:
a. wszystkie pozycje rejestru,
b. nowe,
c. zaakceptowane,
d. odrzucone,
e. zwrócone,
f. przekazane do wysyłki,
g. wysłane.
13. System musi pozwalać na drukowanie całości rejestru lub wybranych pozycji.
1. System musi posiadać bazę Interesantów i możliwość ich grupowania w listy.
2. Baza interesantów musi umożliwiać dodanie zarówno osób fizycznych jak i instytucji/firm.
3. Przy wprowadzaniu nowego Interesanta powinna być możliwość wprowadzenia minimum następujących danych:
a. imię i nazwisko osoby/nazwa instytucji,
b. dane adresowe (możliwość dodania kilku lokalizacji),
c. dane kontaktowe (e-mail, telefon, fax, itp. – z możliwością przypisania preferowanej
formy kontaktu),
d. możliwość przypisania skrytki ePUAP.
4. System musi posiadać możliwość współpracy z systemem GUS – TERYT i umożliwiać korzystanie ze słownika TERYT.
5. System musi pozwalać na poszerzenie standardowego formularza wprowadzania interesanta.
6. System musi odnotowywać następujące informacje związane z interesantem:
a. historia kontaktów będąca ewidencją takich czynności jak: spotkanie, wysyłka korespondencji czy ewidencja rozmów telefonicznych.
b. dokumenty otrzymane od Interesanta, z możliwością przejścia do zawartości
dokumentu (pod warunkiem, że osoba wyszukująca ma uprawnienia do wglądu),
c. informację, którzy użytkownicy mieli wgląd w dane osobowe interesanta z wskazaniem daty, od której interesant otrzymał dostęp do dokumentów.
d. informację na temat odbiorców, którym dane zostały udostępnione.
7. System musi pozwalać na filtrowanie oraz sortowanie Interesantów wprowadzonych do
systemu.
8. System musi umożliwiać określenie kraju pochodzenia interesanta.
9. System musi umożliwiać sprawdzenie historii zmian danych interesanta:
a. datę wprowadzenia zmiany – co najmniej data i godzina operacji,
b. opis zmiany – zawierający informację o użytkowniku, który wprowadził zmianę wraz ze szczegółowym opisem dokonanej zmiany tzn. wskazanie elementów, które zostały zmienione oraz elementów na jakie zostały zmienione,
c. możliwość przywracania wpisów – powinna być możliwość powrotu do każdej pozycji
historii,
10. System musi umożliwiać dokonanie korekty lub aktualizacji danych Interesanta w zależności
od rodzaju zmiany.
Wdrożenie systemu obejmie co najmniej czynności wskazane w punkcie „Wymagania ogólne dla wdrożeń Oprogramowania Aplikacyjnego”.
1. System musi posiadać mechanizm podpisywania dokumentów kwalifikowanym podpisem elektronicznym. W przypadku podpisanego dokumentu musi umożliwiać weryfikację podpisu.
2. System musi pozwalać na podpisywanie dokumentów wychodzących do ePUAP profilem
zaufanym.
1.4.10. Wzory dokumentów i korespondencja seryjna
1. System musi umożliwiać dokumentowanie wypożyczenia dokumentacji ze składu chronologicznego lub ze składu informatycznych nośników danych.
2. System musi umożliwiać tworzenie szablonów dokumentów.
3. System musi pozwalać na wprowadzenie w ramach szablonu dokumentów, co najmniej następujących znaczników umożliwiających zautomatyzowane uzupełnianie dokumentów danymi wprowadzonymi w procesie rejestracji dokumentu:
a. dla Interesantów - dane osobowe, dane adresowe,
b. dla użytkowników - dane użytkownika,
c. dla dokumentów – numeracji dokumentów, identyfikatorów, dat związanych z
dokumentami, elementów opisujących dokumenty takich jak tytuł opis dokumentu
itp.,
d. spraw – numeracji spraw, dat związanych ze sprawą (np. data wszczęcia, zakończenia, zawieszenia, unieważniona) informacji o statusie, elementów opisujących sprawy (np. tytuł, opis), informacje o statusie,
e. inne dostępne w bazie danych systemu – takie jak kod kreskowy, numer strony, aktualna data itp.
4. System musi posiadać wbudowane repozytorium dokumentów, umożliwiające przechowywanie szablonów dokumentów.
5. System musi umożliwiać obsługę repozytorium dokumentów elektronicznych, w szczególności wytworzonych w pakietach MS Office i OpenOffice.
6. System musi umożliwiać integracje z pakietami MS Office i OpenOffice, co najmniej w
zakresie:
a. edycji dokumentów wychodzących dołączanych przez użytkowników do spraw bezpośrednio w pakiecie MS Office lub OpenOffice,
b. edycji szablonów z poziomu repozytorium szablonów bezpośrednio w MS Office lub
OpenOffice.
c. dodawania dokumentów do spraw za pośrednictwem pakietu MS Office lub
OpenOffice,
d. wykorzystania w szablonach dokumentów znaczników generowanych przez system EZD, w tym automatyczne zasilanie dokumentów danymi z systemu EZD.
1. System musi posiadać moduł, w którym będą rejestrowane umowy cywilnoprawne
podpisane przez jednostkę Zamawiającego.
2. System musi informować o bliskim terminie zakończenia umowy.
3. System musi umożliwiać wpisanie terminu płatności przy wprowadzaniu umowy.
4. System musi umożliwiać prowadzenie ewidencji przedmiotów umów.
5. System musi posiadać historię zmian umowy. Wpis musi posiadać datę zmiany, opis zmiany oraz informację o pracowniku dokonującym zmiany.
6. System musi umożliwiać eksport rejestru umów do BIP uwzględniając co najmniej następujący zakres danych:
a. identyfikator umowy nadany przez podmiot prowadzący rejestr,
b. data zawarcia umowy,
c. dane identyfikujące kontrahenta: nazwa (firma) wraz z numerem NIP, jeżeli go posiada albo imię i nazwisko kontrahenta,
d. przedmiot umowy,
e. data początkowa i końcowa okresu realizacji umowy,
f. tryb zawarcia umowy.
1.4.12. Automatyzacja procesów biznesowych
1. System musi posiadać mechanizm definiowania procesów biznesowych w oparciu o rodzaj dokumentu lub/i kategorię JRWA.
2. Modelowanie musi się odbywać w graficznym narzędziu i nie wymagającym znajomości
technik programistycznych.
3. Modeler musi umożliwiać określenie: zadań, warunków łącznych i rozłącznych, podprocesów oraz zakończeń. Dodatkowo przed publikacją musi zostać dokonana weryfikacja zamodelowanego rozwiązania.
4. System musi posiadać wbudowany moduł wspomagania przepływu dokumentów umożliwiający, co najmniej:
a. wersjonowanie ścieżek przepływu pracy,
b. definiowanie ścieżek przepływu pracy w oparciu o strukturę organizacyjną jednostki,
c. procedowanie i dekretacje dokumentów oraz pism z wykorzystaniem mechanizmu procedowania według definiowalnych ścieżek zgodnie z instrukcją kancelaryjną,
d. możliwość dynamicznej modyfikacji osób/grup przydzielonych do zadania bez potrzeby redefiniowania przepływu,
e. możliwość wysyłania zdefiniowanych powiadomień mailowych w dowolnym momencie czasu przepływu.
5. System musi umożliwiać zablokowanie oraz odblokowanie procesów.
6. System musi umożliwiać dodanie zadania pozwalającego przekazać pismo z nadzoru nad
dokumentami automatycznie do obsługi spraw.
1. System musi być wyposażony w funkcjonalność komunikatora tekstowego. Komunikator nie może pozwalać na komunikację z zewnętrznymi ogólnodostępnymi komunikatorami.
2. System musi dostarczać narzędzia komunikacji asynchronicznej pomiędzy użytkownikami.
3. System musi dostarczać narzędzia tekstowej komunikacji synchronicznej pomiędzy użytkownikami.
4. System posiada mechanizm powiadomień dla użytkowników o nowo nadesłanych do nich
komunikatach.
5. System musi umożliwiać przeglądanie wszystkich rozmów archiwalnych, prowadzonych przez danego użytkownika – zarówno w formie synchronicznej, jak i asynchronicznej.
6. System musi pozwalać na wysłanie wiadomości do wielu użytkowników jednocześnie.
7. System musi umożliwiać pobranie i zapisanie rozmowy do pliku tekstowego.
1.4.14. Komunikaty i powiadomienia
1. System musi generować automatyczne komunikaty takie jak:
a. powiadomienia o przekazaniu dokumentów,
b. powiadomienia o przekazaniu dokumentów do akceptacji,
c. powiadomienia o zaakceptowaniu dokumentu,
d. powiadomienia o dekretacji dokumentu.
1. System musi posiadać funkcjonalność obsługi kalendarzy.
2. Użytkownik powinien mieć możliwość wprowadzenia różnych typów zdarzań. Każdy typ zdarzeń powinien być uzupełniany z wykorzystaniem formularza dedykowanego dla danego typu zdarzenia. System powinien posiadać możliwość sprowadzania następujących typów zdarzeń:
a. zwykły wpis umożliwiający co najmniej:
i. określenie przedziału czasowego lub oznaczenie zdarzenia jako całodobowe,
ii. wprowadzenie tytułu zdarzenia wraz z jego opisem,
iii. definiowania czasu przed zdarzeniem, kiedy ma wyświetlić się
powiadomienie,
iv. definiowanie cykliczności zdarzenia wraz z parametryzacją okresu, w którym zdarzenia mają być wyświetlane,
v. rezerwacje zasobów,
vi. wiązanie zdarzeń z dokumentami wprowadzonymi do systemu,
vii. wiązanie zdarzeń z interesantami (zdarzenia powinny być odznaczanie w raporcie dla interesantów),
viii. dodanie pliku do zdarzenia,
ix. przypisywanie innym użytkownikom lub grupom użytkowników uprawnień do wprowadzanego zdarzenia. Uprawnienia powinny być definiowane co najmniej w zakresie: odczyt oraz odczyt i zapis.
b. Zadanie - wpis umożliwiający co najmniej:,
i. określenie przedziału czasowego lub oznaczenie zdarzenia jako całodobowe,
ii. wprowadzenie tytułu zdarzenia wraz z jego opisem,
iii. określenie statusu zadania,
iv. definiowania czasu przed zdarzeniem, kiedy ma wyświetlić się
powiadomienie,
v. rezerwacje zasobów,
vi. wiązanie zdarzeń z dokumentami wprowadzonymi do systemu,
vii. dodanie pliku do zdarzenia,
c. Spotkanie - wpis umożliwiający co najmniej,,
i. określenie przedziału czasowego lub oznaczenie zdarzenia jako całodobowe,
ii. wprowadzenie tytułu zdarzenia wraz z jego opisem,
iii. definiowania czasu przed zdarzeniem, kiedy ma wyświetlić się
powiadomienie,
iv. rezerwację zasobów,
v. definiowanie cykliczności zdarzenia wraz z parametryzacją okresu, w którym zdarzenia mają być wyświetlane,
vi. wiązanie zdarzeń z dokumentami wprowadzonymi do systemu,
vii. dodanie pliku do zdarzenia,
viii. dodawanie agendy spotkania,
ix. określenie lokalizacji spotkania,
d. rozmowa telefoniczna wpis umożliwiający co najmniej:
i. określenie czasu zdarzenia,
ii. określenie czasu trwania rozmowy,
iii. wprowadzenie tematu rozmowy wraz z jej opisem,
e. notatka wpis umożliwiający co najmniej:.
i. określenie czasu zdarzenia,
ii. wprowadzenie tematu rozmowy wraz z jej opisem.
3. Użytkownik powinien mieć również możliwość definiowania zdarzeń całodniowych i dłuższych oraz cyklicznych.
4. Użytkownik powinien mieć możliwość wprowadzania zdarzeń z dokładnością do 15 minut.
5. W Systemie musi istnieć funkcja grupowania zasobów (np. grupa „Pojazdy”, w której znajdują się wszystkie pojazdy należące do Zamawiającego). System musi informować o braku dostępności zasobu w przypadku gdy jest on zarezerwowany przez innego użytkownika.
6. Każdy terminarz musi być możliwy do przeglądania co najmniej w trybie dziennym, tygodniowym i miesięcznym.
1. System musi uwzględniać urlopy i zastępstwa.
2. W trakcie trwania zastępstwa System musi informować o zastępowaniu jednego użytkownika
przez drugiego.
3. Operacje wykonane w zastępstwie muszą być zapisywane w Systemie w sposób pozwalający na jednoznaczne określenie, kto daną operację wykonał.
4. System powinien zapisywać elementy w historii dokumentu, na których zastępca wykonał jakiekolwiek operacje, by zastępowany mógł je zweryfikować po powrocie z nieobecności.
1. System musi zapewniać automatyczną segregację dokumentów spełniających warunki przekazywania do archiwum zakładowego.
2. System musi posiadać dedykowane funkcje do udostępniania i wycofywania dokumentacji z
archiwum zakładowego.
3. System musi umożliwiać wypożyczanie sprawy z archiwum, podgląd informacji o sprawie.
4. System musi realizować brakowanie akt elektronicznych oraz przekazanie akt do archiwum państwowego oraz sporządzanie i przechowywanie odpowiedniej dokumentacji.
5. System musi umożliwiać tworzenie co najmniej następujących spisów:
a. spisy do archiwum państwowego,
b. spisy do brakowania,
c. spisy nie przeznaczone do brakowania,
d. spisy ekspertyzy,
e. spisy zdawczo-odbiorcze nośników.
6. System musi wspomagać użytkownika w przygotowaniu paczki archiwalnej dla Archiwum
Państwowego poprzez przygotowywanie automatycznych spisów zdawczo-odbiorczych,
wykazu akt, oraz zapisanie spraw w strukturze wymaganej przez Archiwum Państwowe. Po skutecznym przekazaniu spraw do Archiwum Państwowego System powinien automatycznie usunąć dane spraw na podstawie potwierdzenia otrzymanego z Archiwum Państwowego.
1.4.18. Raportowanie i monitorowanie
1. System musi posiadać dodatkowy moduł raportów umożliwiający, co najmniej:
a. utworzenie raportu oraz zestawień na podstawie dowolnych danych
przechowywanych w bazie danych Systemu,
b. eksport raportów, do co najmniej następujących formatów: doc, docx, xls, xlsx, pdf,
ppt, pptx, odp, ods, odt.,
c. definiowanie grup raportów.
1.4.19. Administracja systemem
1. System musi posiadać wyodrębniony moduł administracyjny, do którego dostęp będą posiadać jedynie osoby o odpowiednich uprawnieniach.
2. Funkcjonowanie systemu powinno obywać się w oparciu wielopoziomową o strukturę
organizacyjną. Administrator powinien mieć możliwość zarządzania struktura co najmniej w
zakresie:
a. wprowadzenie danych instytucji,
b. dodawanie oraz usuwanie komórek organizacyjnych w tym określanie symbolu komórki niezbędnego do prawidłowego oznaczania spraw,
c. definiowania domyślnych ról systemowych przypisanych do danej komórki
organizacyjnej,
d. wprowadzenie danych adresowych, danych kontaktowych oraz dodatkowych danych
identyfikujących komórkę organizacyjna,
e. przypisywanie użytkowników do poszczególnych komórek organizacyjnych z określeniem stanowisk jakie zajmują,
f. możliwość konfigurowania skrytek ePUAP,
g. możliwości reorganizacji struktury organizacyjnej urzędu (bez konieczności ręcznego przenoszenia pojedynczych pism i spraw oraz uprawnień bez konieczności
angażowania samych użytkowników) np. w przypadku zmiany stanowiska pracownika lub w przypadku zmian kadrowych,
h. obsługi co najmniej dwóch rodzajów reorganizacji tj. zmiana stanowiska wraz ze
zmianą komórki organizacyjnej oraz trwałe przejęcie dokumentacji pracownika przez innego użytkownika.
3. System powinien umożliwiać wprowadzanie nowych użytkowników w tym:
a. wprowadzenie danych indentyfikacyjnych użytkownika w tym login i hasło, skrót nazwy użytkownika, etc.,
b. powinna istnieć możliwość przypisywania ról oraz przypisywać do grup użytkowników,
c. powinna istnieć możliwość przypisania kilku stanowisk do jednego użytkownika,
d. powinna istnieć możliwość przypisania kalendarzy z możliwością ograniczenia zadań
do wybranego zakresu czasowego,
e. przypisanie kont pocztowych w konfiguracji POP3 lub IMAP. Powinna istnieć możliwość sprawdzenia poprawności połączenia bezpośrednio z okna dodawania konta,
f. powinna istnieć możliwość blokowania użytkowników jak i ich odblokowywania,
g. powinna istnieć możliwość śledzenia historii zmian dokonywanych na użytkownikach,
h. administrator powinien mieć możliwość wylogowania użytkowników z systemu EZD.
4. Role i uprawnienia:
a. System musi umożliwiać definiowanie uprawnień do poszczególnych elementów systemu oraz grupowanie uprawnień w role w celu ułatwienia administracji systemem.
b. System musi posiadać zdefiniowaną domyślną pule ról, użytkownik musi posiadać możliwość dodawania kolejnych przez łączenie szczegółowych uprawnień do akcji w systemie.
c. System musi pozwalać na stworzenie grup użytkowników oraz przypisanie do nich wybranych uprawnień.
d. System musi umożliwiać przeglądanie domyślnych ról i uprawnień oraz pozwalać na stworzenie własnych ról z uprawnieniami do systemu.
5. System musi posiadać możliwość zarządzania słownikami pozwalający na ich swobodne
rozszerzanie o nowe wartości. System powinien posiadać co najmniej następujące słowniki:
a. rodzaje dokumentów, spraw,
b. sposobów wysyłania, dostarczania korespondencji, etc..
6. Zastępstwa:
a. system musi umożliwiać definiowanie, zarządzanie zastępstwami, na czas
nieobecności pracownika, polegających na udzieleniu pełnomocnictwa innemu użytkownikowi do wykonywania czynności w imieniu użytkownika nieobecnego.
b. po upłynięciu czasu zastępstwa System musi odbierać uprawnienia do wykonywania czynności w imieniu użytkownika nieobecnego.
7. System musi pozwalać na konfigurowanie automatycznych powiadomień w systemie w
zakresie:
a. włączania bądź wyłączania powiadomień,
b. częstotliwości automatycznych powiadomień,
c. na ile dni przed terminem mają pojawiać się powiadomienia,
d. po ilu dniach po terminie sprawa ma być oznaczona jako przeterminowana.
8. System musi umożliwiać zdefiniowanie struktury numerów dokumentów oraz spraw co
najmniej w zakresie:
a. unikatowego w systemie EZD identyfikatora dokumentu,
b. numeru dokumentu wychodzącego,
c. symbolu dokumentu w rejestrze przesyłek wpływających,
d. symbolu dokumentu w rejestrze przesyłek wychodzących,
e. symbolu pisma wewnętrznego,
f. znaku sprawy.
9. Zarządzenie korespondencją:
a. system musi pozwalać na rejestrację pism z datą przyszłą,
b. system musi pozwalać na wysyłkę kilku dokumentów w jednej kopercie.
10. Zarządzanie sprawami:
a. system musi pozwalać zdefiniować kto określa termin załatwienia sprawy,
b. system musi pozwalać określić domyślny termin załatwienia sprawy.
c. system musi umożliwiać dodawanie i edycję poszczególnych kategorii JRWA z uwzględnieniem kategorii archiwalnych,
d. system musi posiadać opcję konfiguracyjną która pozwoli na tworzenie kategorii
JRWA 5-go rzędu.
11. System musi pozwalać na określenie w jaki sposób mają być pobierane liczniki dokumentów:
a. pobieranie danych ze wszystkich lat,
b. pobieranie danych z bieżącego roku.
12. System musi posiadać mechanizm informujący o wprowadzonych zmianach w aplikacji.
1. Hasła w Systemie muszą być przechowywane w formie zaszyfrowanej. Nie ma możliwości ich
odtworzenia, lecz jedynie zresetowania. Po zresetowaniu hasła użytkownik przy pierwszym logowaniu jest proszony o wprowadzenie nowego hasła.
2. System musi zabezpieczać dane przed przypadkowym nadpisaniem w przypadku równoczesnego korzystania danych w Systemie.
3. System automatycznie zamyka sesje po określonym czasie bezczynności.
4. Użytkownik może indywidualnie zmienić hasło dostępowe do swojego konta.
5. System musi umożliwiać swobodne definiowanie polityki uwierzytelniania i blokowania kont w oparciu o następujące parametry:
a. minimalna długość nazwy użytkownika i hasła,
b. ilość dużych liter, cyfr i znaków specjalnych w haśle,
c. długość cyklu wymuszania zmiany hasła (w miesiącach),
d. ilość nieudanych prób logowania, po których następuje blokada konta,
e. czas blokady konta,
f. wymuszanie cyklicznej zmiany hasła,
g. wymagana liczba cykli zmiany hasła,
h. długość cyklu monitorowania o zmianę hasła użytkownika.
6. System musi posiadać rejestr zdarzeń rejestrujący akcje użytkowników w Systemie, co
najmniej takie jak:
a. udane próby logowania,
b. nieudane próby logowania,
c. błędy aplikacji.
7. System musi rejestrować czynności dostępu do usług i zasobów w Systemie, w tym co
najmniej informacje o:
a. operacjach na dokumentach,
b. operacjach na danych osobowych,
c. zdarzeniach uwierzytelniania (udane logowanie, wylogowanie, nieudane logowanie),
d. zdarzeniach autoryzacji (udane/nieudane operacje),
e. zdarzeniach administracyjnych,
f. zapisywanie danych identyfikujących musi obejmować, co najmniej:
g. identyfikator/nazwa użytkownika, który daną czynność wykonał.
h. czas (data) występowania.
8. System musi pozwalać na logowanie z wykorzystaniem co najmniej: nazwy użytkownika i hasła, usług katalogowych.
Wdrożenie systemu obejmie co najmniej czynności wskazane w punkcie „Wymagania ogólne dla wdrożeń Oprogramowania Aplikacyjnego”.
1.5. #02# Zaprogramowanie procesów w EZD
Zadanie obejmuje:
1. Oprogramowanie procesów związanych z obsługą uruchamianych e-usług w EZD (w tym automatyzacja dekretacji korespondencji związanej z obsługą danej sprawy), w zakresie ustalonym z Zamawiającym i przedstawionym w Analizie. Minimalny zakres dla usług
elektronizowanych na 3. poziomie dojrzałości to automatyzacja obiegu składanych wniosków i deklaracji. Dla usług elektronizowanych na 4. i 5. poziomie dojrzałości dodatkowo zakres
minimalny obowiązuje automatyzację w zakresie obsługi decyzji/odpowiedzi będących efektem załatwienia sprawy.
2. Opracowanie szablonów odpowiedzi/decyzji w procesach w formie elektronicznej (utworzenie repozytorium wzorów dokumentów w sprawach) na podstawie projektów szablonów przekazanych przez Zamawiającego.
3. Integracja wykonanych szablonów z EZD.
1.6. #01# System obsługi zamówień publicznych
Zamówienie obejmuje dostarczenie licencji i wdrożenie systemu obsługi zamówień publicznych spełniającego nw. wymagania minimalne:
1. System powinien umożliwiać przeprowadzenie procedury zamówienia publicznego w sposób zgodny z obowiązującymi przepisami, w szczególności z Ustawa z dnia 29 stycznia 2004 r. – Prawo zamówień publicznych (tj. Dz. U. z 2017 r. poz. 1579), dalej zwaną „Ustawą PZP”.
2. System ze względu na przechowywanie i przetwarzanie zwykłych danych osobowych Interesantów będzie zapewniał bezpieczeństwo przetwarzania danych.
3. System musi posiadać możliwość przypisania do użytkownika uprawnień pozwalających na realizację oraz kontrolę biegu postępowania o udzielenie Zamówienia Publicznego.
4. System musi posiadać mechanizmy uwierzytelniania użytkowników: login i hasło, profil zaufany, podpis kwalifikowany. Użytkownik może uwierzytelniać się jedną z w/w metod.
5. System musi obsługiwać dwie grupy użytkowników – wewnętrznych (pracowników jednostki Zamawiającego) i zewnętrznych (Wykonawców), o odpowiednio zróżnicowanych uprawnieniach.
6. System musi umożliwiać samodzielną rejestrację użytkownika zewnętrznego przy użyciu profilu zaufanego lub loginu i hasła. W przypadku rejestracji poprzez login i hasło system wysyła link aktywacyjny na podany przy rejestracji adres e-mail.
7. Konta użytkowników wewnętrznych muszą być zakładane przez administratora.
8. Dopuszcza się realizację funkcjonalności przewidzianych wyłącznie dla użytkowników wewnętrznych za pomocą systemu EZD. W takim przypadku system EZD musi spełniać
funkcje przewidziane w tym opisie dla użytkowników wewnętrznych i być zintegrowany z systemem obsługującym pozostałe funkcjonalności.
9. System musi pozwalać na tworzenie planu zamówień i pozycji w ramach planu dla konkretnych lat.
10. System musi umożliwiać edycję planu oraz monitorowanie zgodności udzielonych zamówień
z planem.
11. Plan musi umożliwić przypisywanie kodów CPV w poszczególnych postępowaniach i analizę planu pod kątem łącznej wartości zamówień o określonym kodzie CPV (z uwzględnieniem drzewiastej struktury kodu CPV).
12. System musi posiadać mechanizm synchronizacji planu zamówień z planem zamówień prowadzonym przez system planowania i zarządzania budżetem.
13. System musi umożliwiać podpisywanie zbiorczych planów przed publikacją za pomocą
podpisu kwalifikowanego lub profilem zaufanym
14. System musi zapewniać możliwość prowadzenia i wypełniania Protokołu postępowania o udzielenie zamówienia publicznego.
15. System musi umożliwiać generowanie edytowalnego Protokołu na każdym etapie postępowania.
16. System musi uwzględniać chronologię czynności wynikającą z danego etapu postępowania o udzielenie zamówienia publicznego i zapewniać odzwierciedlenie tej chronologii w generowanym, edytowalnym Protokole.
17. System musi zapewnić monitorowanie przygotowania załączników do Protokołu wraz z generowaniem tych załączników. System musi zapewnić monitorowanie terminów
związanych z prowadzeniem postępowania o udzielenie zamówienia publicznego.
18. System musi umożliwiać wsparcie w przygotowaniu dokumentacji zamówienia poprzez możliwość wprowadzania do systemu danych, które raz wprowadzone będą zasilały
generowane dokumenty jak np. wprowadzony krótki opis przedmiotu zamówienia, warunki udziału, kryteria oceny ofert, informacje na temat Zamawiającego, wadium etc. Zakres tych dokumentów zostanie określony w czasie analizy przedwdrożeniowej.
19. System musi wspierać użytkowników w akceptacji oraz wprowadzaniu zmian w SIWZ. System powinien wersjonować SIWZ.
20. System musi umożliwiać komunikację pomiędzy Zamawiającym a potencjalnymi Wykonawcami. Korespondencja musi być przypisywana do wykonawcy jak i do postępowania, którego dotyczy.
21. System musi pozwalać na oznaczenie, które dokumenty generowane przez Zamawiającego/otrzymywane od Wykonawcy mają być publikowane w części dostępnej dla Wykonawców.
22. System musi umożliwiać zarządzanie komisjami przetargowymi: określanie składu komisji wraz z przypisanie członkom czynności związanych z przygotowaniem postepowania.
23. System musi zapewnić skuteczne wsparcie komisji przetargowej na etapie oceny ofert /
wniosków o dopuszczenie do udziału w postępowaniu umożliwiającym ocenę i porównanie ofert według wprowadzonych kryteriów, przy czym System musi zapewniać możliwość
wprowadzenia algorytmów oceny przez Użytkowników, co najmniej w zakresie wyliczania
punktów dla poszczególnych kryteriów.
24. System musi pozwalać na badanie oraz weryfikację kompletności ofert (spełnienia warunków udziału w postępowaniu, weryfikacji braku podstaw do wykluczenia). Członkowie komisji muszą posiadać możliwość wskazywania brakujących dokumentów co będzie podstawą do
wygenerowania wezwania do ich uzupełnienia lub udzielenia wyjaśnień, co powinno być uzależnione od zastosowanego szablonu dokumentu.
25. System musi pozwalać na wykorzystywanie pozycji z wbudowanego Wspólnego Słownika Zamówień (CPV) oraz przypisanie numerów do prowadzonych postępowań o udzielenie zamówienia publicznego.
26. System musi nadawać oznaczenie sprawy zamówieniom i umowom według zdefiniowanych szablonów opartych o JRWA.
27. System musi pozwalać na generowanie niezbędnych dokumentów na podstawie
zdefiniowanych szablonów odpowiednich dla poszczególnych trybów postępowania, niezbędnych do wszczęcia i prowadzenia postępowania o udzielenie zamówienia publicznego. Zakres szablonów zostanie określony w trakcie Analizy.
28. System musi umożliwiać stworzenie i modyfikację zdefiniowanych szablonów oraz tworzenie
nowych. Wykonawca opracuje i zaimplementuje w systemie szablony wszystkich
dokumentów określonych jako niezbędne w trakcie Analizy.
29. System będzie posiadał API wysyłające odpowiedni zakres dokumentów na stronę internetową Jednostki Zamawiającego.
30. System musi umożliwiać wprowadzenie przez upoważnionych Użytkowników nowych wzorów ogłoszeń i protokołów z postępowania, a także ich edycję.
31. System musi umożliwiać tworzenie protokołów z posiedzeń komisji przetargowej i ich ewidencję.
32. System musi weryfikować proponowaną wysokość wadium w kontekście przekroczenia limitów wynikających z Ustawy z dnia 29.01.2004 r. Prawo zamówień publicznych.
33. System musi umożliwiać obsługę zamówień uzupełniających.
34. System musi umożliwiać obsługę zamówień w ramach procedury odwróconej.
35. System musi umożliwiać obsługę zamówień podzielonych na części wraz z uwzględnieniem specyfiki zastosowania tego rozwiązania.
36. Przy wprowadzaniu wartości zamówienia system musi umożliwiać wprowadzanie zarówno
kwot netto, stawki podatku VAT oraz kwot brutto z automatycznym przeliczaniem.
37. System musi umożliwiać ewidencję wniesionych środków ochrony prawnej. Ponadto
wskazywać powiązane z tym terminy oraz uwzględniać okres zawieszenia biegu terminów.
38. System musi umożliwiać ewidencję czynności powtórzonych wraz z uzupełnieniem Protokołu.
39. System musi ewidencjonować rozeznania rynku.
40. System musi umożliwiać ewidencję udzielonych zamówień zapewniając możliwość
grupowania według kryteriów: rodzaju zamówienia (usługi, dostawy, roboty budowlane), kwot, wykonawców, dat udzielenia zamówienia.
41. System musi umożliwiać wyszukanie zamówień/dokumentów co najmniej według kryteriów: rodzaju zamówienia (usługi, dostawy, roboty budowlane), wykonawcy, kwot, daty udzielenia, nazwy postępowania.
42. System musi umożliwiać generowanie własnych zestawień i raportów dla zamówień zarówno aktywnych jak i zakończonych przez użytkowników na podstawie zgromadzonych danych i informacji.
43. Wykonawca po podpisaniu umowy na etapie planu realizacji projektu, zaproponuje i
przedłoży do akceptacji po wykonaniu Analizy co najmniej 5 przykładowych i najczęściej wykorzystywanych przez zamawiającego zestawień i raportów.
44. System musi umożliwiać obsługę profilu zaufanego i kwalifikowanego podpisu
elektronicznego w tym opatrywanie dokumentów podpisem oraz jego weryfikację.
45. System powinien zakładać możliwość współpracy z innymi systemami, w tym EZD, co
najmniej w zakresie wymiany korespondencji, dokumentów tworzących sprawy.
46. System musi zapewniać archiwizację dokumentów elektronicznych lub musi współpracować z modułem archiwum zakładowego systemu EZD.
47. Obieg dokumentów związanych z postępowaniem przetargowym ma być realizowany przy
wykorzystaniu x.xx.:
a. Uwierzytelniania użytkowników aby zabezpieczyć dane przed nieprawidłowym dostępem,
b. Dekretacji dokumentów i pism,
c. Mechanizmu akceptacji dokumentów,
d. Podpisu elektronicznego lub parafowania dokumentów.
48. System musi być skalowalny, przez co będzie możliwość łatwego dostosowania do zmian
prawnych.
49. System musi umożliwiać składanie ofert przez Wykonawców w poszczególnych postępowaniach,
50. System musi posiadać mechanizm zabezpieczania złożonej oferty przed terminem otwarcia za pomocą asymetrycznych algorytmów kryptograficznych RSA.
51. Wykonawca musi mieć możliwość wycofania swojej oferty wysłanej wcześniej za pomocą
systemu.
52. System musi mieć możliwość anulowania oferty o wcześniejszym terminie wpłynięcia, w przypadku wpłynięcia kolejnej oferty od tego samego Wykonawcy.
53. System pozwoli na oznaczenie oferty jako „Zawierającej tajemnicę przedsiębiorstwa”. W takim przypadku użytkownicy ze strony Wykonawców, nawet jeżeli oferty zostaną udostępnione do wglądu na portalu, nie będą mieli wglądu w część jej szczegółów.
Integracje z innymi Systemami:
54. System musi posiadać mechanizm pozwalający na integrację z Biuletynem Zamówień
Publicznych i TED.
55. System musi posiadać API pozwalające na komunikację z Centralną Platformą e-Zamówień co najmniej z następującymi modułami Centralnej Platformy eZamówienia;
• Centralnym Repozytorium Danych CRD, - wymiana ustrukturyzowanych danych
• Modułem Przyjmowania, Zabezpieczania i Udostępniania ofert / wniosków – odbieranie,
rejestracja ofert wniosków ofert / wniosków.
56. Powyższa lista modułów nie jest listą zamkniętą; ostateczny zakres integracji musi umożliwiać zgodną z Ustawą obsługę zamówień publicznych i zostanie uzgodniony między Wykonawcą a Zamawiającym po uruchomieniu Centralnej Platformy eZamówienia.
57. W przypadku, jeśli Centralna Platforma eZamówienia zostanie uruchomiona później niż na 3 miesiące przed dniem zakończenia realizacji Umowy, Wykonawca wykona prace
integracyjne, o których mowa powyżej, w ramach gwarancji. W sytuacji tej brak wykonania
prac integracyjnych nie wstrzymuje Odbioru Końcowego.
Wdrożenie systemu obejmie co najmniej czynności wskazane w punkcie „Wymagania ogólne dla
wdrożeń Oprogramowania Aplikacyjnego”.
Wymagania minimalne:
1. Obudowa rack o wysokości maksymalnie 1U z możliwością instalacji do 8 dysków 3.5" wraz z kompletem wysuwanych szyn umożliwiających montaż w szafie rack. Przedni panel z LCD zamykany na klucz.
2. Płyta główna z możliwością zainstalowania minimum dwóch procesorów. Chipset
dedykowany przez producenta procesora do pracy w serwerach dwuprocesorowych
3. Zainstalowane dwa procesory ośmio-rdzeniowe klasy x86 dedykowane do pracy z zaoferowanym serwerem umożliwiające osiągnięcie wyniku nie mniej niż 95 pkt. w testach wersji 2017 (base) organizacji SPEC dla oferowanego typu serwera - dostępnym na stronie xxx.xxxx.xxx dla dwóch procesorów. W opisie składanym na wezwanie Zamawiającego
należy wskazać producenta i model oferowanych procesorów. Na wezwanie zamawiającego należy załączyć wydruk ze strony potwierdzający osiągnięty wynik dla oferowanego modelu serwera.
4. Pamięć RAM: zainstalowane 128GB DDR4 RDIMM 2666MT/s. Płyta główna powinna obsługiwać do 512TB pamięci RAM.
5. Wbudowane minimum 2 porty typu Gigabit Ethernet Base-T.
6. Zainstalowana jedna karta dwuportowa FC8 Gb/s.
7. Możliwość instalacji dysków SATA, SAS, SSD. Zainstalowane 2 szt. dysków SAS 10k z interfejsem min. 12Gb/s o pojemności co najmniej 500GB każdy.
8. Sprzętowy kontroler dyskowy, możliwe konfiguracje poziomów RAID: 0, 1, 5, 10, 50.
9. Wbudowany napęd DVD+/-RW
10. Wbudowane co najmniej: 3 porty USB, w tym 2 porty USB 3.0, 2 porty RJ45, 2 porty VGA (1 na przednim panelu obudowy, drugi na tylnym), 1 port RS232.
11. Zintegrowana karta graficzna umożliwiająca wyświetlenie rozdzielczości min. 1920x1200.
12. Wentylatory redundantne.
13. Zasilacze redundantne, Hot-Plug maksymalnie 550W.
14. Bezpieczeństwo: zintegrowany z płytą główną moduł TPM; wbudowany czujnik otwarcia obudowy współpracujący z BIOS i kartą zarządzającą.
15. Panel LCD umieszczony na froncie obudowy, umożliwiający wyświetlenie informacji o stanie procesora, pamięci, dysków, BIOS’u, zasilaniu oraz temperaturze.
16. Karta zarządzania, niezależna od zainstalowanego na serwerze systemu operacyjnego, posiadająca dedykowany port RJ-45 Gigabit Ethernet umożliwiająca:
• zdalny dostęp do graficznego interfejsu Web karty zarządzającej,
• zdalne monitorowanie i informowanie o statusie serwera,
• szyfrowane połączenie (SSLv3) oraz autentykacje i autoryzację użytkownika,
• wsparcie dla IPv6,
• wsparcie dla SNMP; IPMI2.0, VLAN tagging, Telnet, SSH,
• integracja z Active Directory,
• możliwość obsługi przez dwóch administratorów jednocześnie,
• wsparcie dla dynamic DNS,
• wysyłanie do administratora maila z powiadomieniem o awarii lub zmianie konfiguracji sprzętowej,
• możliwość podłączenia lokalnego poprzez złącze RS-232 lub USB.
• możliwość zdalnego monitorowania w czasie rzeczywistym poboru prądu przez serwer,
• możliwość zdalnego ustawienia limitu poboru prądu przez konkretny serwer.
17. Dodatkowe oprogramowanie umożliwiające zarządzanie poprzez sieć, spełniające minimalne wymagania:
• Wsparcie dla serwerów, urządzeń sieciowych oraz pamięci masowych,
• Możliwość zarządzania dostarczonymi serwerami bez udziału dedykowanego agenta,
• Wsparcie dla protokołów– WMI, SNMP, IPMI, Linux SSH,
• Możliwość uruchamiania narzędzi zarządzających w poszczególnych urządzeniach,
• Szybki podgląd stanu środowiska,
• Integracja z service desk producenta dostarczonej platformy sprzętowej,
• Możliwość przejęcia zdalnego pulpitu,
• Możliwość podmontowania wirtualnego napędu,
• Automatyczne zaplanowanie akcji dla poszczególnych alertów w tym automatyczne tworzenie zgłoszeń serwisowych w oparciu o standardy przyjęte przez producentów oferowanego sprzętu,
• Kreator umożliwiający dostosowanie akcji dla wybranych alertów,
• Możliwość importu plików MIB,
• Możliwość definiowania ról administratorów,
• Możliwość zdalnej aktualizacji sterowników i oprogramowania wewnętrznego serwerów,
• Możliwość instalacji sterowników i oprogramowania wewnętrznego bez potrzeby
instalacji agenta,
• Możliwość automatycznego generowania i zgłaszania incydentów awarii bezpośrednio do centrum serwisowego producenta serwerów,
• Możliwość automatycznego przywracania ustawień serwera ,kart sieciowych, BIOS, wersji firmware w przypadku awarii i wymiany któregoś z komponentów (w tym kontrolera RAID, kart sieciowych, płyty głównej).
18. Zainstalowany system operacyjny odpowiedni dla oprogramowania aplikacyjnego i
wspomagającego (w tym bazodanowego) zaoferowanego przez Wykonawcę. Wymagane dostarczenie licencji dostępowych na 50 użytkowników, o ile producent danego systemu operacyjnego wymaga takiego licencjonowania.
19. Oferowany serwer musi posiadać certyfikat producenta oferowanego systemu operacyjnego. Na wezwanie zamawiającego należy załączyć wydruk ze strony producenta oferowanego systemu operacyjnego potwierdzający posiadanie ww. certyfikatu przez oferowany model serwera. Dopuszcza się wydruk w języku angielskim.
20. 5-letnia gwarancja producenta realizowana w miejscu instalacji sprzętu, z czasem reakcji do następnego dnia roboczego od przyjęcia zgłoszenia, możliwość zgłaszania awarii w trybie 365x7x24 poprzez ogólnopolską linię telefoniczną producenta. W przypadku awarii dyski
twarde pozostają własnością zamawiającego.
21. Możliwość telefonicznego sprawdzenia konfiguracji sprzętowej serwera oraz warunków gwarancji po podaniu numeru seryjnego bezpośrednio u producenta lub jego przedstawiciela.
22. Zamawiający wymaga dokumentacji w języku polskim lub angielskim.
1.8. #06# Macierz dyskowa (1 szt.)
Wymagania minimalne:
1. Obudowa do instalacji w standardowej szafie rack 19”. Wysokość maksymalnie 2U wraz z
kompletem szyn do montażu w szafie rack z możliwością instalacji minimum 24 dysków 2.5”
Hot Plug.
2. Dwa kontrolery posiadające łącznie minimum osiem portów FC minimum 8 Gb/s wraz z czterema wkładkami SFP do podłączenia serwerów, pracujące w trybie active-active. Wymagane poziomy zabezpieczenia RAID: 0,1,5,6,10.
3. Minimum 4GB na kontroler, pamięć cache zapisu mirrorowana między kontrolerami, z opcją zapisu na dysk lub inną pamięć nieulotną lub podtrzymywana bateryjnie przez min. 72h w razie awarii.
4. Zainstalowane 9 dysków o pojemności minimum 600GB SAS 10k RPM Hot-Plug 2.5” każdy,
skonfigurowane w RAID 6.
5. Możliwość rozbudowy przez dokładanie kolejnych dysków/półek dyskowych, możliwość obsługi łącznie minimum 64 dysków, wydajnych dysków SAS,SSD, ekonomicznych dysków
typu SATA (lub NearLine SAS), możliwość mieszania typów dysków w obrębie macierzy oraz półki.
6. Oprogramowanie zarządzające macierzą w tym powiadamianie mailem o awarii, umożliwiające maskowanie i mapowanie dysków. Możliwość rozbudowy o licencję umożliwiającą utworzenie minimum 512 LUN’ów oraz 32 kopii migawkowych na LUN.
Licencja zaoferowanej macierzy powinna umożliwiać podłączanie minimum 5 hostów bez konieczności zakupu dodatkowych licencji.
7. Zarządzanie macierzą poprzez minimum oprogramowanie zarządzające lub przeglądarkę internetową.
8. Dodatkowe oprogramowanie umożliwiające wspólne zarządzanie oferowanym serwerem oraz oferowaną macierzą poprzez sieć spełniające minimalne wymagania:
a. Wsparcie dla serwerów, urządzeń sieciowych oraz pamięci masowych
b. Możliwość zarządzania dostarczonymi serwerami bez udziału dedykowanego agenta
c. Szczegółowy opis wykrytych systemów oraz ich komponentów
d. Możliwość uruchamiania narzędzi zarządzających w poszczególnych urządzeniach
e. Szybki podgląd stanu środowiska
f. Podsumowanie stanu dla każdego urządzenia
g. Szczegółowy status urządzenia/elementu/komponentu
h. Generowanie alertów przy zmianie stanu urządzenia
i. Integracja z service desk producenta dostarczonej platformy sprzętowej
j. Możliwość przejęcia zdalnego pulpitu
k. Możliwość podmontowania wirtualnego napędu
l. Automatyczne zaplanowanie akcji dla poszczególnych alertów w tym automatyczne tworzenie zgłoszeń serwisowych w oparciu o standardy przyjęte przez producentów oferowanego w tym postępowaniu sprzętu
m. Kreator umożliwiający dostosowanie akcji dla wybranych alertów
n. Możliwość zdalnej aktualizacji sterowników i oprogramowania wewnętrznego serwerów
o. Aktualizacja oparta o wybranie źródła bibliotek (lokalna, on-line producenta
oferowanego rozwiązania)
p. Możliwość instalacji sterowników i oprogramowania wewnętrznego bez potrzeby
instalacji agenta
q. Możliwość automatycznego generowania i zgłaszania incydentów awarii bezpośrednio do centrum serwisowego producenta serwerów
r. Moduł raportujący pozwalający na wygenerowanie następujących informacji: nr seryjne sprzętu, konfiguracja poszczególnych urządzeń, wersje oprogramowania wewnętrznego, obsadzenie slotów PCI i gniazd pamięci, informację o maszynach wirtualnych, aktualne informacje o stanie gwarancji, adresy IP kart sieciowych
9. Bezpieczeństwo: ciągła praca obu kontrolerów nawet w przypadku zaniku jednej z faz zasilania. Zasilacze, wentylatory, kontrolery RAID redundantne. Fizyczne zabezpieczenie dedykowane przez producenta serwera uniemożliwiające wyjęcie dysków twardych umieszczonych na froncie obudowy przez nieuprawnionych użytkowników.
10. 5-letnia gwarancja producenta realizowana w miejscu instalacji sprzętu, z czasem reakcji do następnego dnia roboczego od przyjęcia zgłoszenia, możliwość zgłaszania awarii w trybie 365x7x24 poprzez ogólnopolską linię telefoniczną producenta. W przypadku awarii dyski
twarde pozostają własnością zamawiającego.
11. Możliwość sprawdzenia statusu gwarancji poprzez stronę producenta podając unikatowy numer urządzenia, oraz pobieranie uaktualnień mikrokodu oraz sterowników nawet w
przypadku wygaśnięcia gwarancji macierzy.
12. Zamawiający wymaga dokumentacji w języku polskim lub angielskim.
1.9. #07# Oprogramowanie monitorujące
Wymagania minimalne:
1. Oprogramowanie musi posiadać budowę modułową, składać się z serwera zarządzającego oraz modułów zdalnych.
2. Moduły muszą umożliwiać kompleksowy monitoring sieci oraz monitoring sprzętu
komputerowego.
3. Konsola dostępna poprzez przeglądarkę www.
4. W zakresie obsługi sieci program musi pozwalać na wyświetlenie konfiguracji oraz jej
prezentację.
5. Program musi umożliwiać monitorowanie nielimitowanej liczby urządzeń sieciowych.
6. Program musi posiadać możliwość monitorowania stanu systemów i wysyłania
powiadomienia (do wskazanych osób kontaktowych) w razie gdy przestały one odpowiadać lub gdy monitorowane ważne parametry znajdują się poza określonym zakresem zdefiniowanym przez administratora.
7. Monitorowanie komponentów serwerowych (przełączniki, routery, czujniki temperatury i wilgotności, etc.).
8. Monitorowania serwerów WWW i adresów URL.
9. Monitorowanie usług sieciowych (SMTP, POP3, http, NNTP, ping). Musi umożliwiać monitorowanie czasu ich odpowiedzi i procent utraconych pakietów.
10. Monitor usług działających w ramach systemów operacyjnych będących przedmiotem Zamówienia.
11. Monitorowanie zasobów hosta (obciążenie CPU, użycie dysku, itp).
12. Monitorowanie wydajności systemów operacyjnych będących przedmiotem Zamówienia (obciążenie CPU, pamięci, zajętości dysków).
13. Obsługa urządzeń SNMP (przełączniki, routery, drukarki sieciowe).
Licencja musi obejmować instalację i użytkowanie systemu na sprzęcie dostarczanym w ramach zamówienia oraz pozostałej Infrastrukturze Zamawiającego.
Przedmiot zamówienia – kody CPV
• 48.00.00.00-8 Pakiety oprogramowania i systemy informatyczne
• 48.42.20.00-2 Zestawy pakietów oprogramowania
• 48.44.20.00-8 Pakiety oprogramowania do systemów finansowych
• 48.60.00.00-4 Pakiety oprogramowania dla baz danych i operacyjne
• 72.00.00.00-5 Usługi informatyczne: konsultacyjne, opracowywania oprogramowania, internetowe i wsparcia
• 72.21.10.00-7 Usługi programowania oprogramowania systemowego i dla użytkownika
• 72.26.30.00-6 Usługi wdrażania oprogramowania
• 72.25.32.00-5 Usługi w zakresie wsparcia systemu
• 72.42.00.00-5 Usługi w zakresie rozwijania Internetu
• 48.82.00.00-2 Serwery
• 48.90.00.00-7 Różne pakiety oprogramowania i systemy komputerowe
• 30.23.30.00-1 Urządzenia do przechowywania i odczytu danych
• 32.42.00.00-3 Urządzenia sieciowe
2.1. #09# Modernizacja systemów dziedzinowych z uruchomieniem dedykowanego
portalu e-należności
W ramach zamówienia wykonawca:
• zrealizuje rozbudowę i modernizację systemów dziedzinowych w celu obsługi przez te systemy nowych procesów związanych z realizacją planowanych w ramach projektu e-usług,
• dostarczy i wdroży system informacji internetowej o stanie należności urzędu z tytułu podatków i opłat z możliwością dokonywania płatności elektronicznych (system „e- należności”).
Ww. systemy i usługi, łącznie z elementami zamówienia opisanymi w pozostałych rozdziałach
niniejszego dokumentu, muszą m. in. umożliwić Zamawiającemu świadczenie na rzecz mieszkańców
nw. e-usług na 4. lub wyższym poziomie dojrzałości:
• Rozłożenie należności na raty, odroczenie terminu, umorzenie zaległości, umorzenie odsetek;
• Obsługa podatku rolnego / Deklaracja na podatek rolny;
• Obsługa podatku leśnego /Deklaracja na podatek leśny;
• Obsługa podatku od nieruchomości / Deklaracja na podatek od nieruchomości;
• Informacja w sprawie podatku rolnego;
• Informacja w sprawie podatku leśnego;
• Informacja w sprawie podatku od nieruchomości;
• Zwrot podatku akcyzowego zawartego w cenie oleju napędowego wykorzystywanego do produkcji rolnej;
• Obsługa podatku od środków transportowych / Deklaracja na podatek od środków
transportowych;
• Obsługa opłaty za gospodarowanie odpadami komunalnymi / Deklaracja o wysokości opłaty;
• Usługa e-należności.
2.1.1. Modernizacja systemów dziedzinowych
Wykonawca zrealizuje modernizację systemów dziedzinowych w celu obsługi przez te systemy nowych procesów związanych z realizacją planowanych w ramach projektu e-usług.
Zadanie może być zrealizowane poprzez dostawę i wdrożenie nowych systemów dziedzinowych lub poprzez rozbudowę i aktualizację wybranych systemów funkcjonujących w jednostce Zamawiającego (Urzędzie Gminy Łopiennik Górny), w tym poprzez dostawę nowych modułów tj.:
• systemów obsługujących: podatki i opłaty lokalne finanse i księgowość oraz kadry i płace – firmy Usługi Informatyczne INFO-SYSTEM Roman i Xxxxxxx Xxxxxxx sp.j,
• systemu firmy ARISCO Sp. z o.o. obsługującym opłaty za gospodarowanie odpadami
komunalnymi.
Systemy dziedzinowe po modernizacji i rozbudowie muszą być oparte o jednolitą wspólną platformę bazodanową (bazę danych SQL).
Systemy dziedzinowe muszą posiadać budowę modułową oraz zapewniać pełną wymianę informacji pomiędzy poszczególnymi modułami systemu.
Wdrożenie systemów obejmie co najmniej czynności wskazane w punkcie „Wymagania ogólne dla wdrożeń Oprogramowania Aplikacyjnego”.
Systemy dziedzinowe muszą po rozbudowie i modernizacji realizować co najmniej funkcje wyszczególnione poniżej.
Wspólna baza interesantów
System musi posiadać wspólną dla wszystkich modułów bazę interesantów, spełniającą następujące
wymagania funkcjonalne:
1. System musi umożliwiać rejestrację w odrębnych kartotekach osób fizycznych i organizacji (osoby pozostałe).
2. System musi pozwalać na wyszukiwanie osób/organizacji po niżej wymienionych kryteriach:
a. dla osób fizycznych: nazwisko, imię, nr PESEL/NIP, danych adresowych (miejscowość, ulica, numer budynku/lokalu), data urodzenia, imię ojca, matki, typ i numer
dokumentu, nr tel. komórkowego, konto email, informacja o posiadaniu konta na
platformie ePUAP i posiadaniu profilu zaufanego;
b. dla organizacji pozostałych: nazwa/REGON/KRS/NIP po numerze konta bankowego, danych adresowych (miejscowość, ulica, numer budynku/lokalu), nr tel.
komórkowego, konto email, informacja o posiadaniu konta na platformie ePUAP i
posiadaniu profilu zaufanego;
c. dla obydwu grup: po identyfikatorze, będącym indywidualnym numerem przyporządkowanym tylko dla danej osoby.
3. System musi umożliwiać wprowadzanie osób/organizacji w zakresie podstawowych danych osobowych, adresowych i dokumentów oraz możliwość dokonywania zmian/poprawek na wprowadzonych danych.
4. Dla zarejestrowanej osoby (fizycznej/pozostałej) system musi umożliwiać wprowadzanie:
a. kilku różnych typów adresów,
b. osób powiązanych z daną osobą (np.: dla osób fizycznych – małżonka, dla osoby
pozostałej – filie, właściciele),
c. dla osób pozostałych – kody PKD – funkcja zintegrowana z aplikacjami windykacyjnymi w celu stworzenia sprawozdania PKD,
d. kilku numerów kont bankowych, ze wskazaniem głównego konta w celu wystawiania przelewów w aplikacjach windykacyjnych,
e. Urzędu Skarbowego, pod który podlega osoba,
f. Zakładu Ubezpieczeń Społecznych, do którego są odprowadzane są składki.
5. System musi umożliwiać przechowywanie pełnej historii osób z uwzględnieniem kiedy, jakie dane były zmieniane i przez jakiego operatora.
6. System musi umożliwiać wyszukiwanie i wybór osób ze stanem archiwalnym oraz
wprowadzanie zmian archiwalnych.
7. System musi posiadać funkcję administracyjną (dostępną tylko dla wybranych użytkowników) pozwalającą na sklejanie osób/organizacji w przypadkach gdy są kilkakrotnie wprowadzone do systemu z różnymi danymi (aktualnymi i archiwalnymi) lub pojawiły się w systemie z
importu z systemów zewnętrznych. Po scaleniu dane aktualne powinny być wyświetlane w
systemach dziedzinowych.
8. System musi posiadać możliwość odszukania osoby, która została doklejona/ do osoby głównej, uwzględniając jej poprzednie stany.
9. System musi umożliwiać tworzenie profili dla poszczególnych użytkowników aplikacji w zakresie dostępu do informacji znajdujących się w systemie dotyczących osób/organizacji – winna być możliwość - jeśli zaistnieje taka potrzeba – aby pewne informacje nie były dostępne dla danego użytkownika (np. dane adresowe, dokumenty, numer NIP/REGON/PESEL, informacje o kontach bankowych itp.).
10. System musi zawierać słowniki pieczątek/znaków graficznych wykorzystywanych w korespondencjach w zintegrowanym module podatku od nieruchomości.
11. Kartoteka interesantów systemów dziedzinowych musi być wspólna dla wszystkich modułów
oferowanego systemu oraz powinna zawierać mechanizmy jej integracji (powiązań) z
kartoteką systemu EZD, w szczególności w zakresie aktualizacji danych oraz wprowadzania nowych podmiotów.
12. System musi współpracować z systemem e-należności oraz aplikacją mobilną za pośrednictwem serwisu komunikacyjnego w zakresie informacji danych ewidencyjnych podatników.
13. Komunikacja z systemem EZD odbywa się za pośrednictwem brokera integracyjnego z wykorzystaniem usługi Web Service.
14. System musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji.
Obsługa podatku rolnego, leśnego i od nieruchomości
1. System musi zapewnić ewidencjonowanie kart podatkowych z uwzględnieniem podziału na sołectwa/obręby podatkowe i stosować odpowiednią numerację uwzględniającą ten podział.
2. Ewidencja kart podatkowych dla osób fizycznych musi być wspólna dla wszystkich rodzajów podatków.
3. System musi rozdzielać ewidencję osób fizycznych i prawnych.
4. Użytkownik musi mieć możliwość wyboru grup kart w zakresie sposobu opodatkowania (podatek rolny, leśny, od nieruchomości, łączne zobowiązanie zarówno dla osób fizycznych jak i prawnych).
5. System musi umożliwiać łączenie kart podatkowych i scalanie ich automatycznie. Karta po scaleniu musi zawierać przedmioty opodatkowania znajdujące się na wszystkich powiązanych kartach. Użytkownik określa nadrzędną kartę do której będą przeniesione dane z kart
podrzędnych.
6. System powinien umożliwić prowadzenie ewidencji działek i musi uwzględniać możliwość wprowadzenia przy nich informacji o udziałach z uwzględnieniem historii zmian.
7. System musi umożliwiać wprowadzanie wielu adresów związanych z danym podatnikiem
(adres zamieszkania, korespondencyjny).
8. System musi posiadać możliwość wprowadzania zarówno ulg i zwolnień ustawowych jak i
wprowadzonych uchwałą Rady Gminy.
9. System musi uwzględniać możliwość naliczania podatku rolnego wg. hektarów fizycznych i przeliczeniowych. Zmiana sposobu opodatkowania w roku podatkowym nie może wymuszać założenia nowej karty, a jedynie wprowadzenia daty od której ma nastąpić zmiana sposobu jego naliczania.
10. System w naliczaniu wymiaru podatku musi wyliczyć odpowiednie kwoty z uwzględnieniem podziału na poszczególne rodzaje zobowiązań (rolny, leśny i od nieruchomości) oraz raty z uwzględnieniem obowiązujących terminów płatności.
11. Naliczanie wymiaru powinno być dokonywane w trybie zbiorczym dla całości podatników lub wybranego sołectwa/obrębu podatkowego.
12. System musi umożliwiać naliczanie zmian w wysokości podatku i wydawanie stosownych
decyzji.
13. System musi umożliwiać drukowanie odpowiednich decyzji z uwzględnieniem wydruków
zbiorczych i dla pojedynczych kart.
14. System musi umożliwiać generowanie decyzji elektronicznych i wysyłanie ich przez ESP za pośrednictwem modułu integrującego do systemu EZD. Rejestracja w systemie EZD musi uwzględniać rejestracją sprawy zgodnie z konfiguracją systemu w zakresie jednolitego
rzeczowego wykazu, kartoteki kontrahentów, dat i typów.
15. System musi umożliwiać wczytywanie do systemu deklaracji i załączników złożonych przez podatnika za pomocą platformy ePUAP.
16. System musi posiadać funkcjonalność modyfikacji standardowych wzorów wydruków oraz możliwość wprowadzania nowych wzorów. Musi także uwzględniać możliwość tworzenia
wydruków w formacie RTF z uwzględnieniem automatycznego wypełniania wydruku danymi z programu. System musi umożliwiać generowanie wydruków na podstawie tych wzorców i zapisywanie ich w systemie obiegu dokumentów EZD w profilu użytkownika z
uwzględnieniem typów dokumentów w nim zdefiniowanych. W szczególności dotyczy to
wydruku zaświadczeń wg wzorców opracowanych przez użytkownika.
17. System musi umożliwiać drukowanie zaświadczeń do pliku PDF i wysyłanie ich przez ESP za pośrednictwem modułu integrującego i systemu EZD.
18. System musi posiadać rejestr wydanych zaświadczeń.
19. System musi umożliwiać wydruk blankietów dowodów wpłat, potwierdzeń odbioru decyzji z możliwością drukowania w/w dokumentów łącznie z decyzjami wymiarowymi. System musi umożliwiać drukowanie w/w dokumentów do pliku PDF i wysyłanie ich przez ESP za pośrednictwem modułu integrującego i systemu EZD.
20. System musi umożliwiać oznaczanie wydruków kodem kreskowym identyfikującym daną
kartę podatkową oraz kodów kreskowych identyfikujących poszczególne raty zobowiązania w
celu integracji z systemami bankowymi w zakresie obsługi indywidualnych rachunków bankowych dla płatności masowych.
21. Wszystkie dokonane wydruki decyzji wymiarowych i zmieniających wymiar muszą być zapisywane do bazy danych i gromadzone na karcie podatnika. W każdym momencie użytkownik może podglądnąć i wydrukować na nowo taką decyzją w niezmienionym formacie.
22. System musi posiadać możliwość generowania wydruków wybranych pism (decyzji) do
formatu RTF z możliwością ich edycji i zapisu do karty podatnika i wysyłania ich przez ESP za pośrednictwem modułu integrującego i systemu EZD.
23. System musi umożliwiać prowadzenie (wydruk) rejestru wymiarowego oraz rejestru przypisów i odpisów. Wydruki te powinny mieć możliwość zapisu duplik atu rejestru
wymiarowego do pliku PDF oraz zapisanie go za pośrednictwem modułu integrującego w
systemie EZD.
24. System musi posiadać możliwość wielopłaszczyznowej analizy wprowadzanych danych i możliwość ich raportowania w postaci wydruków. W szczególności wymagane będą
zestawienia z uwzględnieniem podziału na sołectwa/okręgi podatkowe uwzględniające wysokość poszczególnych podatków, szczegółową analizę ulg i zwolnień oraz skutków
obniżenia stawek w podatku rolnym i od nieruchomości. Zestawienia te muszą dawać też możliwość uzyskania informacji o łącznej ilości przedmiotów opodatkowania oraz o
wysokości podstawy ich wymiaru.
25. System musi umożliwiać przegląd historii właścicieli nieruchomości.
26. System musi uwzględniać możliwość wydruku indywidualnych numerów rachunków
bankowych na które będą dokonywać wpłaty podatnicy. System musi uwzględniać możliwość dostosowania w/w rozwiązania do wymogów bankowych płatności masowych.
27. System musi dawać możliwość wydruku odpowiednich danych w postaci kodu kreskowego na blankiecie dowodu wpłaty z możliwością wprowadzenia w nim identyfikacji płatnika,
kwoty wpłaty, identyfikacji zobowiązania.
28. System musi współpracować z systemem informacji internetowej o stanie należności urzędu z tytułu podatków i opłat z możliwością dokonywania płatności elektronicznych (dalej: system „e-podatki”) oraz aplikacją mobilną za pośrednictwem serwisu komunikacyjnego w zakresie informacji dotyczących zobowiązań, danych ewidencyjnych kartoteki podatnika oraz podglądu dokumentów (decyzji, zaświadczeń) wystawianych przez system.
29. Komunikacja z systemem EZD odbywa się za pośrednictwem brokera integracyjnego z wykorzystaniem usługi Web Service.
30. System musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji.
Obsługa podatku od środków transportu
1. W zakresie obsługi podatku od środków transportu System musi spełniać następujące
wymagania funkcjonalne:
2. System musi posiadać możliwość wprowadzania danych pojazdów i dokonywania
zmian/poprawek (zgłoszenie sprzedaży, zmiana właściciela, zmiana parametrów technicznych itp.) w zakresie umożliwiającym prawidłowe naliczenie kwot podatku.
3. System musi umożliwiać obsługę słowników takich jak: słownik stawek podatków na poszczególne lata, słownik terminów płatności, rodzajów i marki pojazdu).
4. System musi umożliwiać wyszukiwanie podatnika po minimum wymienionych kryteriach: nazwa/nazwisko, numer rejestracyjny pojazdu, adresu zamieszkania/siedziby, numer karty kontowej podatnika.
5. System musi umożliwiać rejestrację decyzji uznaniowych (np. umorzenie odsetek lub ich części, odroczenie terminów płatności, rozłożenie płatności na raty).
6. System musi umożliwiać tworzenie raportów i zestawień w minimalnym zakresie zdefiniowanym poniżej:
a. Zestawienie podatników z naliczonym wymiarem.
b. Zestawienie podatników bez naliczonego wymiaru.
c. Zestawienie przypisów i odpisów.
d. Rejestr pism.
e. Rejestr decyzji uznaniowych.
f. Statystyka właścicieli pojazdów.