Postępowanie nr 2/2.18/POWER/ZK. Zadanie 1 Zakup i wdrożenie Portalu Interesanta ze szkoleniami dla Gminy Skarżysko Kościelne

Transkrypt

1 Strona1 Załącznik nr 1 Szczegółowa charakterystyka przedmiotu zamówienia Zadanie 1 Zakup i wdrożenie Portalu Interesanta ze szkoleniami dla Gminy Skarżysko Kościelne Zakup będzie obejmował dostawę licencji portalu interesanta. Portal ma stanowić dedykowaną platformę dla klientów Urzędu Gminy w Skarżysku Kościelnym: mieszkańców, przedsiębiorców i innych osób mających zobowiązania wobec Gminy Skarżysko Kościelne. Za pośrednictwem portalu po integracji z systemami płatności elektronicznych i systemem dziedzinowym klienci będą mogli dokonania płatności elektronicznych za wybrane wierzytelności. Wykonawca dostarczy portal zintegrowany z użytkowanym przez Gminę Skarżysko Kościelne systemem dziedzinowym oraz zapewni jego funkcjonowanie w minimalnej funkcjonalności obejmującej: 1. Dostęp do portalu musi być możliwy przez autoryzację z wykorzystaniem powszechnie dostępnego profilu zaufanego ( 2. Portal musi zapewnić zarządzanie i administrowanie kontami użytkowników przez wbudowany panel administratora dostępny po zalogowaniu się za pomocą loginu oraz hasła. 3. Portal musi zapewnić podgląd listy użytkowników, którym udostępniono dostęp do Portalu, wraz z danymi dotyczącymi, nazwy, daty utworzenia konta, statusu. 4. Administrator ma podgląd do informacji o próbach logowania do portalu ze wskazaniem identyfikatora, daty, adresu IP z którego nastąpiło połączenie do portalu. 5. Portal w zakresie obsługi administratora musi posiadać funkcjonalność co najmniej: a. zarządzania kontem / kontami administratora z możliwością osobnego przydzielania uprawnień dla całości portalu oraz procedur i użytkowników. W tym celu musi wymagać co najmniej informacji: rola konta, nazwa użytkownika, hasło, b. podglądu listy użytkowników, którym udostępniono dostęp do Portalu, wraz z podglądem statusu tj. co najmniej identyfikatora, nazwy, daty utworzenia konta oraz informacji czy konto jest aktywne, zawieszone wraz z możliwością określenia statusu na co najmniej (zablokowany, usunięty, aktywny). 6. Portal musi posiadać funkcjonalność zabezpieczenia przed ewentualnym dokonaniem zmian, modyfikacji przez użytkownika, który jest zalogowany na standardowe konto, bez uprawnień administratora. 7. Portal musi udostępniać swoją treść przy wykorzystaniu przeglądarek www. Budowa strony internetowej musi spełniać ogólnie przyjęte standardy kodowania www oraz zgodność z normą WCAG Portal nie może wymagać instalacji dodatkowego oprogramowania, po stronie użytkownika. 9. Portal musi udostępniać dane po zalogowaniu się użytkownika na jego indywidualne konto. 10. Portal musi posiadać funkcjonalność wskazywania, które z publikowanych usług informacyjnych wymagają logowania za pomocą indywidualnego konta użytkownika. 11. Portal musi posiadać funkcjonalność wyświetlania listy dostępnych elektronicznych usług informacyjnych co najmniej w formie listy. 12. Portal musi posiadać funkcjonalność współpracy z relacyjną bazą danych SQL. 13. Portal musi dokonywać wizualizacji danych za pomocą tabel i pól informacyjnych pogrupowanych ze względu na obszary pobierane z obecnie użytkowanego systemu dziedzinowego, których dotyczą dla każdej kartoteki w obszarach: a. Podatek od Środków Transportu, b. Podatki lokalne (rolny, leśny, od nieruchomości), c. Ewidencja Opłat za Gospodarowanie Odpadami Komunalnymi, d. Opłaty Lokalne. 14. Dane do wizualizacji (zawierające indywidualne informacje) muszą być pobierane automatycznie i udostępniane tylko w odniesieniu do konta danego podatnika i po jego uwierzytelnieniu za pośrednictwem profilu zaufanego. 15. Portal musi pobierać dane z poszczególnych użytkowanych obecnie obszarów systemu dziedzinowego obejmując swym zakresem co najmniej: a. Podatek od Środków Transportowych: wykaz pojazdów zgodnie ze złożoną deklaracją, sprawdzenie zobowiązań wobec Urzędu w zakresie opłat za podatek od środków transportowych,

2 Strona2 portal musi być zintegrowany z systemem płatności elektronicznych, który realizuje wpłaty bezpośrednio na rachunek urzędu. b. Podatki wobec gminy: sprawdzenie stanu posiadania podatnika, sprawdzenie naliczonego podatku (wymiar podatku), sprawdzenie zobowiązań wobec Urzędu Gminy, portal musi być zintegrowany z systemem płatności elektronicznych, który realizuje wpłaty bezpośrednio na rachunek urzędu. c. Ewidencja opłat za gospodarowanie odpadami komunalnymi: sprawdzenie danych zawartych umów na wywożenie odpadów, sprawdzenie wystawionych przypisów / kwot do zapłaty, sprawdzenie zobowiązań wobec Urzędu z tytułu rozliczeń za odpady komunalne, portal musi być zintegrowany z systemem płatności elektronicznych, który realizuje wpłaty bezpośrednio na rachunek urzędu d. Opłaty Lokalne: sprawdzenie naliczonych opłat, sprawdzenie zobowiązań wobec Urzędu Gminy, portal musi być zintegrowany z systemem płatności elektronicznych, który realizuje wpłaty bezpośrednio na rachunek urzędu. 16. Portal musi posiadać możliwość podglądu przeprowadzonych (udanych, nieudanych, przerwanych) operacji płatności internetowych z informacją o kwocie, dacie i statusie płatności. 17. Portal musi obsługiwać indywidualne konta bankowe w celu rozróżnienia poszczególnych rodzajów płatności i ich automatycznego księgowania po odnotowaniu na koncie bankowym urzędu, w systemie dziedzinowym odpowiedzialnym za część księgową - rozliczeniową (Portal musi umożliwiać przeprowadzanie płatności internetowych z uwzględnieniem mechanizmów płatności masowych gwarantując identyfikację wpłat z elektronicznych wyciągów bankowych na podstawie indywidualnego numeru rachunku bankowego przypisanego do płatnika i danej należności). 18. Portal musi posiadać przejrzystą prezentację należności z uwzględnieniem sald poszczególnych rat, terminów ich płatności oraz wysokości odsetek wraz z kosztami upomnień. 19. Portal musi zapewniać wyliczanie ogólnej kwoty należności. 20. Portal musi umożliwiać dokonywanie wpłat dla użytkowników zalogowanych. 21. Portal musi być zintegrowany co najmniej jednym systemem płatniczym (PayByNet). System płatniczy musi 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. 22. Dostęp do portalu musi być zapewniony także z urządzeń mobilnych w zakresie dostępu do informacji o zobowiązaniach, dokonywania płatności. 23. Portal musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji. Wdrożenie portalu informacyjno-płatniczego i asysta techniczna Wdrożenie systemu obejmie: 1. instruktaże oraz asystę stanowiskową dla administratora i użytkowników 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 2. 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;

3 Strona3 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. 3. zapewnienie opieki powdrożeniowej systemu w okresie trwania projektu polegającej na: a. świadczeniu pomocy technicznej, b. świadczeniu usług utrzymania i konserwacji dla dostarczonego oprogramowania, c. dostarczaniu nowych wersji oprogramowania będących wynikiem wprowadzenia koniecznych zmian w funkcjonowaniu systemu związanych z wejściem w życie nowych przepisów, d. przekazywaniu w terminach uprzedzających datę wejścia w życie znowelizowanych lub nowych przepisów prawa nowych wersji oprogramowania, włącznie z koniecznym w tym zakresie udzieleniem licencji do nowej wersji systemu, e. dostarczaniu nowych, ulepszonych wersji oprogramowania lub innych komponentów systemu będących konsekwencją wykonywania w nich zmian wynikłych ze stwierdzonych niedoskonałości technicznych, f. dostarczaniu nowych wersji dokumentacji użytkownika oraz dokumentacji technicznej zgodnych co do wersji jak i również zakresu zaimplementowanych i działających funkcji z wersją dostarczonego oprogramowania, g. świadczeniu telefonicznie usług doradztwa i opieki w zakresie eksploatacji systemu. Integracja portalu interesanta z systemem dziedzinowym - prace programistyczne Wykonawca zrealizuje integrację portalu interesanta z użytkowanym przez Gminę Skarżysko Kościelne systemu dziedzinowego autorstwa firmy Korelacja Systemy Informatyczne Sp. z o. o. w celu obsługi nowych procesów związanych z realizacją planowanych w ramach projektu e-usług. Po dokonaniu integracji system musi zachować budowę modułową oraz zapewniać pełną wymianę informacji pomiędzy poszczególnymi użytkowanymi modułami systemu oraz umożliwić udostępnienie danych na potrzeby świadczenia e-usług realizowanych w ramach zamówienia. Dodatkowo w ramach prac integracyjnych należy rozbudować istniejący system dziedzinowy w zakresie obszaru obsługi opłat lokalnych w celu umożliwiania użytkownikom wykorzystania danych w portalu informacyjnopłatniczym oraz tak by zapewnić mu minimalną funkcjonalność przedstawioną poniżej w zakresie: 1. System musi realizować zadania z obszaru rozliczeń dochodów i opłat lokalnych gminy. 2. System musi obsługiwać tworzenie kartotek płatników (podmioty fizyczne, podmioty prawne, podmioty grupowe) z ich danymi szczegółowymi. 3. System musi odnotowywać informacje obejmujące zmiany danych dokonanych na edytowanym podmiocie. 4. System musi umożliwiać tworzenie własnych grup płatników. 5. System musi korzystać ze słowników automatycznie aktualizowanych przy tworzeniu nowych podmiotów i kartotek np. słownika miejscowości, ulic, kodów pocztowych itp. 6. System musi posiadać funkcjonalność zakładania i konfiguracji dowolnych rodzajów należności z zakresu Opłat Lokalnych. 7. System musi posiadać funkcjonalność definiowania przez użytkownika szablonów dla rozliczanych umów. 8. System musi zapewniać szczegółową obsługę umów dla płatników, zawierającą informację co najmniej o datach i terminach wynikających z umowy, okresie obowiązywania, kwotach, liczbie rat. 9. System musi umożliwiać obsługę różnych typów ulg w tym co najmniej (procentowa, roczna, dla raty). 10. System musi posiadać możliwość wprowadzania aneksów dla zawartych umów (i automatycznie po wprowadzaniu i zatwierdzeniu aneksu, dokonywać przeliczeń poszczególnych rat). 11. System musi umożliwiać masowe wystawianie aneksów dla wprowadzonych umów. 12. System musi umożliwiać wprowadzanie stawek zmiennych będącymi podstawą dla naliczania umów, opartych o różne okresy czasowe (miesiąc, kwartał, półrocze, rok). 13. System musi umożliwiać automatyczne przeliczenie umowy w przypadku zmian stawki zmiennej (dotyczy umów zawierających wybraną stawkę zmienną). 14. System musi umożliwiać zmianę sposobu wyliczania i zaokrągleń (wyliczania do miejsc dziesiętnych) przy obsłudze stawek zmiennych stosowanych w szablonach umów. 15. System musi umożliwiać automatyczne naliczanie rat dla wprowadzonych umów w bieżącym roku. 16. System musi rozliczać płatności jednorazowe/ niecykliczne. 17. System musi umożliwiać definiowanie własnych danych dodatkowych dla umów / należności jednorazowych (definiowanie to musi umożliwiać określanie typu definiowanych pól np. liczba, tekst jak i podpięcie słownika już istniejącego bądź nowo zakładanego i tworzonego na potrzeby rozszerzenia części opisowej dla należności).

4 Strona4 18. System musi posiadać moduł administratora umożliwiający określenie zakresu danych widocznych dla poszczególnych użytkowników. 19. System musi obsługiwać wystawianie faktur VAT oraz korekt. 20. System musi umożliwiać wystawianie faktur pojedynczo jak i automatycznie dla wielu płatników/ kontrahentów. 21. System musi posiadać funkcjonalność obsługi i wystawiania faktur cząstkowych. 22. System musi umożliwiać definiowanie przez użytkownika automatycznego generowania kolejnego numeru faktury. 23. System musi dostarczać kompletne dane dotyczące faktur (data wystawienia, data sprzedaży, dane nabywcy, dane podatnika, nazwa towaru, sposób i termin zapłaty, stawka vat, wysokość podatku VAT itd.). 24. System musi obsługiwać automatyczne usuwanie faktur zbiorczo z zadanego przedziału (po uprzednim zaznaczeniu zbiorczego przedziału bądź wybranych faktur przez użytkownika). 25. System musi umożliwiać sprawdzenie wystawionych i nie wystawionych faktur z zadanego przedziału wyszukiwania. 26. System musi umożliwiać automatyczne generowanie Jednolitego Pliku Kontrolnego. 27. System musi umożliwiać import i podgląd danych geodezyjnych oraz ich aktualizację. 28. System musi generować zestawienia wprowadzonych umów, należności, płatników. 29. System musi umożliwiać skróconą/uproszczoną księgową obsługę wprowadzonych kartotek płatników (oraz współpracować z zamawianą w niniejszym postepowaniu częścią księgową). 30. System musi umożliwiać otwarcie nowego roku bez konieczności zamykania roku poprzedniego. 31. System musi umożliwiać przełączanie się między latami obrachunkowymi w celu podglądu danych w nich zawartych. 32. System musi umożliwiać archiwizację nieużywanych kartotek. 33. System musi umożliwiać podgląd danych przeniesionych do archiwum. 34. System musi posiadać możliwość tworzenia co najmniej poniższych typów dokumentów: zwroty, wpłaty, przeksięgowania dochodu, przeksięgowania należności, umorzenia zaległości, przypis, odpis, przedawnienie należności, odroczenia terminu raty, rozłożenia należności/ zaległości na raty, odroczenie terminu zapłaty części raty, wstrzymanie naliczania odsetek w podanych okresie, oraz Bilansu Otwarcia jako nadpłata lub zaległość. 35. System musi mieć możliwość automatycznego rozdysponowania wpłaconej przez podatnika kwoty według zasady: od najstarszego terminu płatności z uwzględnieniem kolejności (najpierw odsetki potem należność główna) lub proporcjonalnej wpłaty na należność główną i odsetki, w zależności od rodzaju i typu opłaty z możliwością ręcznej zmiany przez użytkownika sposobu rozdysponowania zaproponowanego przez system. 36. System musi mieć możliwość obsługi upomnień oraz wezwań do zapłaty (wystawianie, wydruk, prowadzenie rejestru). 37. System musi mieć możliwość anulowania upomnienia i kosztów związanych z jego wystawieniem. 38. System musi mieć możliwość wystawienia upomnienia na zaległości z bieżącego roku, bądź z lat ubiegłych lub uwzględnienie tych dwóch opcji jednocześnie. 39. System umożliwia automatyczne wyliczenie Bilansu Otwarcia. 40. System musi mieć możliwość utworzenia dokumentu przeksięgowania wpłaty pomiędzy poszczególnymi systemami użytkowanymi przez Zamawiającego tj: Podatki rolny, leśny, od nieruchomości, Podatek od Środków Transportu, z możliwością wybrania wpłaty (nadpłaty) z tych systemów. 41. System musi posiadać algorytmy ułatwiające wprowadzanie kwot dokumentów i ich powiązanie z konkretnymi rodzajami/terminami należności. 42. System musi umożliwiać proporcjonalny, nieproporcjonalny, dowolny podział składowych kwoty dla tworzonych dokumentów. 43. System musi umożliwiać przeksięgowanie nadpłaty, części lub całości wpłaty na inne należności na karcie tego samego płatnika, na inne karty kontowe lub na karty kontowe systemów podatkowych użytkowanych obecnie przez Zamawiającego.

5 Strona5 44. System musi umożliwiać wystawianie/drukowanie upomnień dla pojedynczego płatnika oraz jako operacje masowe dla wszystkich bądź wybranej grupie płatników (system umożliwia ograniczenie operacji masowego wystawiania upomnień do należności, dla których nie wystawiono upomnienia, ograniczonych zakresem terminów płatności i wysokością zaległości). 45. System musi umożliwiać wprowadzenie daty doręczenia upomnienia również z możliwością wykorzystaniem kodów kreskowych do wspomagania operacji wprowadzania doręczenia. 46. System musi umożliwiać prezentację listy płatników, którym w zadanym okresie zostały wystawione upomnienia, z możliwością ograniczenia grupy prezentowanych danych. 47. System musi umożliwiać wystawienie tytułu wykonawczego, zmienionego tytułu wykonawczego i dalszego tytułu wykonawczego i ich wydruk. 48. System musi umożliwiać uzyskanie informacji o wystawionych tytułach wykonawczych w postaci szczegółowych lub zbiorczych zestawień. 49. System musi służyć do wystawiania, drukowania i przygotowywania tytułów wykonawczych w formie tradycyjnego (papierowego) dokumentu i w formie elektronicznej przesyłanej z wykorzystaniem funkcjonalności platformy epuap. 50. System musi posiadać wbudowane słowniki klasyfikacji spraw, podstaw prawnych, urzędów skarbowych itp. publikowanych na stronie Izby Skarbowej w Szczecinie: System musi posiadać możliwość dokonywania aktualizacji słowników wykorzystywanych przy tworzeniu tytułów wykonawczych online lub offline w postaci plików zawierających uaktualnione dane 52. System musi posiadać powiązanie z obecnie użytkowanymi systemami podatków i zamawianym w niniejszym postępowaniu systemem opłat lokalnych zapewniające na bieżąco pozyskanie informacji o aktualnym stanie należności i pełnej historii wprowadzonych zapisów księgowych. 53. System musi zapewniać funkcjonalności związane z wystawieniem tytułu wykonawczego, dalszego tytułu wykonawczego i zmienionego tytułu wykonawczego. 54. System musi zapewniać powiązanie tytułu wykonawczego z konkretnym organem egzekucyjnym, pod który podlega dłużnik. 55. System musi umożliwiać podgląd tytułu wykonawczego przed jego wydrukowaniem i jego wydruk. 56. System musi posiadać opcję archiwizacji danych wystawionego tytułu wykonawczego w taki sposób, że jest możliwe sprawdzenie jego relacji do podmiotów i należności pieniężnych, których dotyczy oraz możliwy jest jego ponowny podgląd i wydrukowanie w przyszłości w niezmienionej formie. 57. System musi współpracować z systemem podatków i opłat lokalnych w sposób umożliwiający udostępnianie informacji do danych pochodzących z modułu obsługi elektronicznych tytułów wykonawczych. 58. System musi umożliwiać zapisanie wystawionego tytułu wykonawczego w formacie pliku XML zgodnie ze schematem XSD formatu danych tytułów wykonawczych przekazywanych do organów egzekucyjnych przez środowisko epuap dostępnym na stronie System musi umożliwiać przygotowanie pliku XML zawierającego zbiór wielu tytułów wykonawczych przekazywanych do organu egzekucyjnego przy pomocy środowiska epuap jako jedna przesyłka. 60. System musi umożliwiać podpisanie sporządzonego tytułu (tytułów wykonawczych) podpisem elektronicznym w rozumieniu ustawy z dnia 18 września 2001r. o podpisie elektronicznym (Dz. U. z 2013 r. poz. 262). 61. System musi umożliwiać pogrupowanie przygotowanych tytułów wykonawczych wg właściwych organów egzekucyjnych zarówno na etapie zbiorczych wydruków, informacji o wystawionych tytułach wykonawczych, jak i na etapie przygotowania pliku XML przed przesłaniem go z wykorzystaniem usługi sieciowej platformy epuap. 62. System musi umożliwiać ocenę skuteczności prowadzonych działań związanych z wystawieniem upomnień lub tytułów wykonawczych w postaci informacji o kwotach dokonanych wpłat. 63. System musi umożliwiać rozłożenie wybranych zaległości wraz z odsetkami lub bez na dowolną ilość rat. 64. System musi umożliwiać obsługę odroczenia terminu płatności. 65. System musi automatycznie wyliczać opłatę prolongacyjną oraz należne odsetki na datę podania o rozłożenie na raty lub odroczenie terminu płatności oraz wstrzymuje naliczanie odsetek do upływu nowych terminów płatności. 66. System musi umożliwiać umorzenie zaległości, należności płatnika. 67. System umożliwia pokazywanie wszystkich składowych kwoty dla wprowadzonych dokumentów: kwota należności głównej, koszty egzekucji, opłata prolongacyjna, odsetki. 68. System musi umożliwiać prezentację wszystkich dokumentów w rozbiciu na część netto i VAT, umożliwiać prezentację wynikających z nich należności, nadpłat, zaległości itp. w identycznym rozbiciu, a także odzwierciedlać ten fakt na wydrukach. 69. System posiada wbudowane wymagane kategorie odsetek. 70. System musi wyliczać aktualne saldo płatnika, a także posiadać możliwość przeliczania go na dowolną wskazaną przez użytkownika datę.

6 Strona6 71. System musi umożliwiać sporządzanie wydruków wszystkich typów wprowadzanych dokumentów księgowych z możliwością prezentacji szczegółowej, zbiorczej wszystkich płatników lub grupy płatników. 72. System musi automatycznie wyliczać kwotę należnych odsetek od istniejących zaległości. 73. System musi posiadać wbudowany kalkulator odsetek umożliwiający wyliczenie odsetek od dowolnej kwoty, za podany przedział czasu, według dowolnej kategorii odsetek z uwzględnieniem zaokrąglenia i odsetek minimalnych. 74. System musi posiadać możliwość poprawy/anulowania wprowadzonych dokumentów księgowych. 75. System musi umożliwiać zamknięcie okresu (wprowadzenie blokad) na podany dzień w sposób uniemożliwiający wprowadzanie, edycję, usuwanie danych, czy wykonywanie jakichkolwiek operacji powodujących zmianę danych księgowych w zamkniętym okresie76. System umożliwia wprowadzenie dokumentów bilansowych z lat poprzednich. W kolejnych latach pracy dokumenty bilansowe muszą być wynikiem zamknięcia roku poprzedniego (system musi posiadać mechanizm automatycznego przenoszenia danych bilansowych po otwarciu nowego roku). 77. System umożliwia wielokrotne przeprowadzanie operacji przenoszenia sald księgowych do nowego roku wraz z równoległą pracą na danych starego i nowego roku i zachodzącą tym samym zmianą danych w starym roku, operacja ponownego przeniesienia sald do nowego roku nie usuwa dokumentów już wprowadzonych w nowym roku. 78. System musi posiadać możliwość korekty danych oraz ponowne przeniesienie ich do nowego roku dla pojedynczego płatnika. 79. System musi umożliwiać generowanie zestawień zbiorczych wszystkich wprowadzonych dokumentów księgowych dla wszystkich płatników lub dowolnie ograniczonej ich grupy za dowolnie wskazany przedział czasowy. 80. System musi umożliwiać wygenerowanie sprawozdania Rb27S dla wprowadzonych dokumentów. 81. System musi umożliwiać przygotowanie wydruków zawierających szczegółową, analityczną prezentację wszystkich danych składających się na sprawozdanie RB-27S z dokładnością do płatnika, poszczególnych rodzajów należności, kwot odsetek, upomnień, opłaty prolongacyjnej (działu, rozdziału i paragrafu klasyfikacji budżetowej). 82. System musi umożliwiać wczytanie i przeglądanie dowolnego roku obrachunkowego (system musi udostępniać funkcjonalność szybkiego przełączania pomiędzy poszczególnymi latami). 83. System musi umożliwiać szczegółowe, zbiorcze, z dokładnością do podsumowań dziennych zestawienie wpłat (dochodów) poszczególnych płatników, za dowolny okres czasu z możliwością prezentacji danych w szczegółowości do grupy należności (lub klasyfikacji budżetowej), z podziałem na osoby prawne i fizyczne, miejsce dokonania wpłaty, z podziałem na wpłaty do należności z roku bieżącego i lat poprzednich, z możliwością ograniczenia do należności powstałych w konkretnym roku (latach) lub ograniczonych zakresem terminów płatności. 84. System musi umożliwiać sporządzenie wydruków zawierających informację o stanie należności, zaległości, nadpłat na dowolny dzień dla wszystkich płatników lub grupy, zarówno w sposób szczegółowy jak i zbiorczy. 85. System musi umożliwiać uzyskanie informacji o kwotach zaległości podzielonych na dowolnie zdefiniowane okresy, w których upływał ich termin płatności. 86. System musi umożliwiać wprowadzenie maski konta (wspólnej dla wszystkich kartotek części rachunku bankowego), na podstawie której będą dokonywane wpłaty na subkonta konta podstawowego, umożliwiające identyfikację wpłacającego na podstawie konta, na jakie dokonano wpłaty. 87. System musi umożliwiać automatyczne nadawanie kolejnych kont bankowych zgodnie ze standardem IBAN. System nie wymaga od użytkownika żadnej dodatkowej czynności związanej z nadaniem kolejnego numeru. 88. System musi automatycznie uwzględniać, od chwili uruchomienia modułu płatności masowych, indywidualny numer rachunku bankowego na wszystkich wydrukach zawierających numer rachunku bankowego kierowanych do podatnika. 89. System musi umożliwiać przygotowanie masowej bądź indywidualnej informacji o zmienionym numerze rachunku bankowego. 90. System musi umożliwiać wczytanie i weryfikację pod kątem merytorycznym elektronicznego wyciągu bankowego pochodzącego z systemu bankowego. W przypadku zmiany formatu danych udostępnianych przez bank możliwe jest dostosowanie systemu do nowego formatu. 91. System musi na podstawie numeru konta bankowego przypisywać wpłatę do konta płatnika, od którego pochodzi. W przypadku gdy rozdysponowanie wpłaty na poszczególne należności płatnika jest jednoznaczne, system musi dokonywać automatycznego zadekretowania kwoty.

7 Strona7 Opracowanie i wdrożenie e-usług na platformie epuap W ramach zamówienia Wykonawca zrealizuje usługę polegającą na przygotowaniu i uruchomieniu usług elektronicznych na platformie epuap w tym: opracowanie wzorów dokumentów elektronicznych, przekazanie do publikacji w CRD, budowa formularza na podstawie opublikowanego w CRD wzoru, przygotowanie opisu usługi, przygotowanie karty usługi na 4 poziomie dojrzałości (transakcja). Lista e-usług, które zostaną uruchomione w ramach zadania: 1. Prowadzenie spraw dotyczących podatku od nieruchomości od osób fizycznych. 2. Prowadzenie spraw dotyczących podatku od nieruchomości od osób prawnych. 3. Prowadzenie spraw dotyczących podatku leśnego. 4. Prowadzenie spraw dotyczących podatku rolnego. 5. Prowadzenie spraw dotyczących podatku od środków transportowych. 6. Prowadzenie spraw dotyczących zobowiązań z tytułu odpadów komunalnych. Każda ze zbudowanych usług inicjowana będzie przez Internautę poprzez wypełnienie formularza elektronicznego na platformie epuap, wyświetlenie wizualizacji dokumentu elektronicznego, możliwości podpisania dokumentu profilem zaufanym lub bezpiecznym podpisem kwalifikowanym. Uruchomione eusługi mają być podstawą do świadczenia przez Zamawiającego usług na 4 poziomie dojrzałości (transakcja). Do zadań wykonawcy w ramach zamówienia należeć będzie: 1. Zbudowanie wzoru dokumentu elektronicznego (o ile zaistnieje taka potrzeba) oraz przekazania go Zamawiającemu celem opublikowania w Centralnym Repozytorium Wzorów Dokumentów Elektronicznych lub skorzystanie z istniejącego wzoru w Centralnym Repozytorium Wzorów Dokumentów o ile istnieje. Zamawiający przekaże Wykonawcy wszelkie niezbędne informacje oraz materiały niezbędne do wykonania wzoru dokumentu elektronicznego. Zamawiający dopuszcza by do czasu opublikowania wzoru w Centralnym Repozytorium Wzorów Dokumentów Elektronicznych wzór został zainstalowany w lokalnym repozytorium wzorów dokumentów elektronicznych, 2. Zbudowanie formularza elektronicznego na bazie uprzednio opracowanego wzoru dokumentu elektronicznego, 3. Wybranie opisu usługi z puli istniejących w epuap. W przypadku braku stosownego opisu Zamawiający wystąpi do organu właściwego o jego publikację, 4. Zbudowanie karty usługi na podstawie danych przekazanych przez Zamawiającego, 5. Wprowadzenie informacji o płatnościach i uruchomienie płatności elektronicznych epuap w ramach usługi (w przypadku występowania i po podpisaniu odpowiedniej umowy przez Zamawiającego), 6. Uruchomienie usługi elektronicznej na platformie epuap, w przypadku gdy nie wystąpił czynnik uniemożliwiający wykonanie tego procesu, np. niedostępność platformy epuap. Przygotowanie i przeprowadzenie pakietów szkoleń Szkolenia mają na celu osiągniecie odpowiedniej wiedzy z zakresu używania systemu na odpowiednich stanowiskach służbowych. Przeprowadzenie pakietu szkoleń powinno zostać odpowiednio skoordynowane z przeprowadzeniem procesu wdrożenia. Szczegółowy zakres poszczególnych szkoleń będzie podlegał uzgodnieniu pomiędzy Wykonawcą a Zamawiającym w ramach akceptacji harmonogramu i materiałów szkoleniowych. Wykonawca na etapie uzgadniania materiałów szkoleniowych przekaże minimalne wymagania, jakie powinni spełniać oddelegowani przez Zamawiającego, uczestnicy szkolenia. Do każdego modułu wspomagającego obsługę obszarów działalności urzędu, Zamawiający wskaże osoby, które Wykonawca przeszkoli. Szkolenia będą realizowane w pomieszczeniach i na sprzęcie udostępnionym przez Urząd. Zamawiający nie dopuszcza przeprowadzania szkoleń typu e-learning w zastępstwie szkoleń tradycyjnych. Zamawiający dopuszcza przeprowadzanie szkoleń grupowych, w grupach do 10 użytkowników oraz szkoleń indywidualnych przy stanowiskach dla grup jedno-, dwu- lub trzyosobowych. Wykonawca przeszkoli osoby pełniące obowiązki administratorów wskazanych przez Zamawiającego w zakresie zarządzania użytkownikami i uprawnieniami, zabezpieczania i odtwarzania danych. Wykonawca zapewni przeszkolenie administratora wskazanego przez Zamawiającego w zakresie administracji i konfiguracji zaoferowanego systemu bazodanowego. Szkolenie musi obejmować co najmniej instalację, konfigurację bazy danych, obsługę narzędzi administratora, architekturę systemu, zagadnienia związane z zachowaniem bezpieczeństwa, integralności i zabezpieczenia przed utratą danych, przywracaniem danych po awarii.

8 Strona8 Uzgodnieniu pomiędzy stronami podlegają: - minimalne wymagania dla uczestników szkoleń, - harmonogram szkoleń grupowych i indywidualnych, - materiały szkoleniowe dla szkoleń grupowych, - listy obecności ze szkoleń grupowych i indywidualnych, - protokoły odbioru zadania dot. szkoleń. Zamawiający oczekuje, że ilość oraz program szkoleń powinny gwarantować użytkownikom systemu zapoznanie się z wszystkimi funkcjonalnościami jakie system oferuje. Zamawiający oczekuje przeprowadzenia nie więcej niż: Szkolenie instruktażowe - PORTAL INTERESANTA, czas trwania 16 godz./2 dni robocze, 4 uczestników Szkolenie "Zmiana sposobu świadczenia usług po wdrożeniu nowych funkcjonalności systemów dziedzinowych", czas trwania 6 godz./1 dzień roboczy x 8 uczestników x 2 grupy Szkolenia będą realizowane w Urzędzie Gminy Skarżysko Kościelne, ul. Kościelna 2a Skarżysko Kościelne w godzinach pracy urzędu. Zadanie 2 Zakup i wdrożenie Centralnej Platformy e-usług ze szkoleniami dla Gminy Suchedniów Centralna platforma e-usług to portal integrujący wszystkie dane z innych systemów, informacje o świadczonych e- usługach przez epuap, spersonalizowane dane podatkowe. Jest to główny system funkcjonalny z punktu widzenia mieszkańca działający na styku Petent - Urząd. Dzięki niemu mieszkańcy będą mieli dostęp do wszystkich produktów wytworzonych w ramach projektu. W szczególności system zawierać powinien: 1. Opisy wszystkich usług świadczonych przez urząd na platformie epuap, z których mieszkaniec może skorzystać w sposób elektroniczny. 2. Możliwość śledzenia postępu swoich spraw. 3. Podgląd swoich, spersonalizowanych danych o należnościach i zobowiązaniach z tytułu podatków i opłat lokalnych. 4. Możliwość dokonania płatności z tytułu podatków i opłat lokalnych. 5. Możliwość umówienia się na wizytę w Urzędzie. Szyna Danych umożliwi dostarczenie jednolitego interfejsu do udostępniania usług pomiędzy systemami rozwiązania, jak również do udostępniania treści. Szyna danych umożliwia integrację danych z różnych źródeł oraz dostęp do danych. Wymagania funkcjonalne Centralnej Platformy e-usług: Warstwa administracji i integracji System Usług Elektronicznych musi stanowić moduł całego systemu umożliwiający bezpośredni kontakt z Urzędem. Będzie systemem udostępnionym w sieci Internet dla wszystkich potencjalnych odbiorców. System ten będzie zawierał warstwę publiczną, która będzie dostępna dla wszystkich użytkowników zewnętrznych. W warstwie publicznej będą dostępne informacje statystyczno-analityczne, na udostępnienie których Urząd wyrazi zgodę. Warstwa wymagająca autoryzacji systemu będzie przeznaczona dla mieszkańców do realizacji usług publicznych. Aby móc sprawdzić stan sprawy urzędowej, zapisać się na spotkanie w odpowiednim referacie lub zapłacić online za śmieci, mieszkaniec będzie zobowiązany dokonać autoryzacji m.in. za pomocą profilu zaufanego. System będzie posiadał także obszar administracyjny, przeznaczony dla pracowników urzędu. Obszar ten umożliwi odpowiednie skonfigurowanie Platformy, przegląd statystyk, zarządzanie udostępnianymi danymi. System musi posiadać jedno logowanie przeznaczone dla wszystkich modułów. Użytkownik będzie mógł zalogować się do systemu za pomocą konta epuap. Użytkownik musi być automatycznie zalogowany do systemu, o ile jest zalogowany do epuap. Użytkownik będzie mógł samodzielnie założyć konto w systemie nie posiadając konta na epuap. Użytkownik będzie mógł samodzielnie założyć konto w systemie posiadając konto na epuap. Użytkownik może korzystać z funkcji przypomnij hasło, która umożliwia mu samodzielne odzyskanie hasła do systemu. Funkcja przypomnij hasło wymusza ponowne ustawienie hasła do systemu. System musi wymagać hasła na odpowiednim poziomie bezpieczeństwa, tzn. minimum 8 znaków, w tym przynajmniej jedna duża i mała litera oraz cyfra. System musi być zaprojektowany w architekturze trójwarstwowej.

9 Strona9 Warstwa danych musi być oparta o silnik bazy danych SQL umożliwiający instalację zarówno na systemie operacyjnym Windows jak i Linux. Warstwa serwera aplikacyjnego musi dostarczać logikę biznesową systemu i umożliwiać instalację na systemie operacyjnym Windows i Linux. Warstwa prezentacyjna musi być dostosowana do przeglądarek internetowych w wersjach aktualnych na dzień składania zamówienia. System musi być dostosowany do dostępu dla osób niedowidzących, tj. zgodność z wymogami WCAG 2.0 na poziomie AA. System powinien umożliwiać rejestrację użytkowników: a. zewnętrznych (interesantów Urzędu) z oznaczeniem redaktorów, którzy mają uprawnienia do zgłaszania propozycji artykułów i aktualności; b. wewnętrznych (pracowników Urzędu) z oznaczeniem administratorów portalu, którzy posiadają rozszerzone uprawnienia m.in. do publikacji artykułów i aktualności oraz administrowania systemem. Rejestracja użytkownika musi wymagać podania jego loginu, hasła, imienia, nazwiska, daty urodzenia, a oraz opcjonalnie numeru telefonu (w celu otrzymywania powiadomień sms). Dodatkowo użytkownik musi wyrazić zgodę na przetwarzanie jego danych osobowych oraz potwierdzić zapoznanie się i akceptację regulaminu. Rejestracja użytkowników zewnętrznych musi być możliwa przy pomocy formularza, który może złożyć niezalogowany użytkownik. Taka rejestracja będzie wymagać akceptacji administratora systemu. Rejestracji użytkowników wewnętrznych musi dokonać administrator systemu w ramach funkcjonalności zarządzania użytkownikami. Ze względu na zakładany dostęp do systemu z poziomu urządzeń mobilnych, strony systemu powinny automatycznie dostosowywać się do różnych rozdzielczości ekranu (Responsive Web Design). System w zakresie WWW musi być przygotowany zgodnie ze standardem W3C. Podstawowym językiem obowiązującym w systemie musi być język polski. Jeżeli system będzie korzystał z ciasteczek, wówczas na stronie głównej musi być prezentowana informacja o tym fakcie wraz z możliwością przeglądu polityki wykorzystania ciasteczek. System musi rejestrować operacje tworzenia, edycji i usuwania obiektów (ofert, zabytków, map itp.) wraz z informacją o użytkowniku, dacie i czasie wykonania operacji. Dodatkowo system musi udostępniać funkcjonalność do przeglądu zarejestrowanych operacji. Wykonawca w okresie trwania projektu musi zapewnić usługę wysyłania sms. Usługa ta musi obejmować wysłanie minimum 10 tys. SMS przez okres trwania projektu. Korzystanie z systemu przez użytkowników, oprócz przeglądarki Firefox, Chrome, Internet Explorer, Safari, Opera, które są zgodne ze standardem HTML 5, nie może wymagać instalacji dodatkowego oprogramowania. Przy założeniu, że system będzie udostępniany użytkownikom zewnętrznym, którzy będą posiadać komputery o następujących parametrach minimalnych: a. Procesor dwurdzeniowy; b. Pamięć - 2 GB; c. Łącze - 1Mb/s; czas odpowiedzi serwera na wywołanie URL aplikacji musi wynosić maksymalnie 3 sekundy. Powyższe założenie musi być spełnione przy 100 użytkownikach zalogowanych jednocześnie do systemu. Określony czas nie dotyczy wywołań systemów zewnętrznych. System powinien umożliwiać administratorowi systemu na określenie maksymalnej wielkości pobieranych plików oraz zdjęć. W przypadku zdjęć, których wielkość będzie przekraczać zakładaną wartość, system powinien informować o możliwościach zmiany tej wielkości (np. poprzez zwiększenie kompresji lub zmianę rozdzielczości). System musi umożliwiać administratorowi zarządzanie zadaniami wsadowymi przeznaczonymi do zadań administracyjnych wykonywanych automatycznie. W ramach zarządzania zadaniami wsadowymi administrator ma możliwość skonfigurowania planu wykonywania zadania wsadowego, parametrów jego wywoływania, przeglądu logów z wykonanych zadań wsadowych. System musi umożliwiać zarządzanie przynajmniej następującymi zadaniami wsadowymi: czyszczenie katalogu plików, odbiór dokumentów epuap, pobieranie informacji o stanie płatności z SD, przekazywanie informacji o stanie płatności do SD, weryfikacja stanu wiadomości SMS wysyłanych do użytkowników, usuwanie wygenerowanych raportów z modułu raportowego, wysyłanie powiadomień o należnościach. System musi umożliwiać zarządzanie rejestrem interesantów, gdzie każdego można:

10 Strona10 zidentyfikować minimum takimi danymi jak: typ podmiotu, imię, nazwisko, login, zdjęcie profilowe, dane kontaktowe (telefon, , faks, www, adres korespondencyjny, oraz dowolną liczbę innych form kontaktu), zmienić mu dane podstawowe, zmienić mu dane kontaktowe, powiązać go z interesantem z systemu dziedzinowego, aktywować konto interesanta, przypisać interesanta do grup użytkowników. Ilekroć w systemie jest możliwość dodania dokumentu, zdjęcia lub innego pliku system musi umożliwiać skorzystanie z funkcji Drag-and-Drop i umożliwia przeniesienie pliku z katalogu użytkownika komputera. Ilekroć w systemie jest mowa o danych ze słownika TERYT, system musi prezentować listę rozwijalną z aktualnych danych TERYT. System musi umożliwiać zarządzania słownikiem TERYT z możliwością importu pliku w opcjach: Miejscowości, Podział terytorialny, Nazwy ulic. Ilekroć w systemie wykorzystywany jest element słownika TERYT, system musi prezentować pole automatycznie przeszukiwane według znaków wprowadzanych przez użytkownika. Prezentowana lista musi zawierać w każdym wierszu kilka najistotniejszych elementów m.in. nazwę województwa, powiatu i gminy w przypadku wyszukiwania miejscowości. System musi posiadać wydzieloną funkcję umożliwiającą przeglądnie Interesantów do aktywacji i aktywowanie im kont. System musi umożliwiać zmianę hasła dla zalogowanego użytkownika. System musi umożliwiać zarządzanie odrębnym rejestrem pracowników, w którym każdy pracownik charakteryzowany jest za pomocą imienia, nazwiska (z opcją dodania 2 i 3 członu nazwiska), symbolu (skrótu pracownika), stanowiska pracownika, loginu, zdjęcia profilowego, danych kontaktowych (telefon, , lokalizacja, faks, www, adresu korespondencyjnego, lub jakiejkolwiek innego kontaktu z rozróżnieniem formy tego kontaktu). Zarówno dla interesanta jak i pracownika system musi umożliwiać przeglądanie rejestru czynności wykonywanych przez wybranego użytkownika z wyróżnieniem daty i czasu wykonania czynności oraz obiektu w systemie, którego to dotyczy. System musi posiadać możliwość zarządzania słownikiem kodów pocztowych wraz z importem kodów pocztowych z pliku CSV Poczty Polskiej. System musi posiadać możliwość edycji głównych stron każdego z modułów. Edycja głównej strony modułu umożliwia, co najmniej: ustalenie stylu redagowanego tekstu, pogrubienie, podkreślenie, pochylenie tekstu, wyczyszczenie formatu czcionki, ustalenie kolor czcionki, ustalenie sposobu punktowania, ustalanie wielkości odstępów pomiędzy liniami tekstu, dodanie obrazka, dodanie linka do innej strony, wstawienie tabeli, przegląd redagowanej treści w formie HTML. System musi umożliwiać zarządzanie rolami w systemie, przy czym w momencie dostarczenia powinien posiadać przygotowane, podstawowe role do każdego z modułów systemu. Każda z ról systemu musi posiadać listę uprawnień wraz z opisami uprawnień. Administrator musi mieć możliwość dodania dowolnej roli w systemie i przypisania jej dowolnej listy uprawnień. System ról, uprawnień i użytkowników musi być oparty o mechanizmy LDAP. System ról, uprawnień i użytkowników musi posiadać interfejs użytkownika w ramach SUE, który umożliwia ergonomiczne i efektywne zarządzanie tym zakresem. System musi posiadać funkcję przeładowania uprawnień w trybie rzeczywistym systemu. Przeładowanie uprawnień wymianie listy uprawnień na serwerze aplikacyjnym, co pozwala na zarządzanie dostępami bez konieczności wylogowania użytkowników systemu. System musi posiadać funkcję zarządzania rolami przypisanymi do użytkowników. System musi posiadać miejsce do zarządzania wszelką parametryzacją system, gdzie: pogrupowane są obszary parametryzacji systemu, każdy z parametrów posiada funkcję edycji, każdy z parametrów charakteryzowany jest przez opis, nazwę i wartość. System musi posiadać sparametryzowane m.in.: obsługę SMS, , LDAP, płatności elektroniczne, dane urzędu, dane dostępowe do epuap.

11 Strona11 System musi posiadać obszar zarządzania plikami zaimportowanymi do systemu na potrzeby udostępniania w innych modułach. System musi posiadać możliwość przeglądania rejestru operacji wykonanych w systemie. Przegląd rejestru operacji możliwy jest do przeszukania m.in. według daty i czas od do, użytkownika, który dokonał operacji, typu obiektu i rodzaju operacji wykonywanej (np. aktualizacja danych, błąd, modyfikacja danych, usunięcie danych, import, etc.). System musi mieć możliwość zarządzania strukturą organizacyjną JST w formie prezentacji jako drzewo organizacji, które wyróżnia: Komórkę Organizacyjną, Stanowisko oraz Pracownika na stanowisku. System musi mieć obszar zarządzania zastępstwami w organizacji, gdzie będzie istniała możliwość: dodania zastępstwa charakteryzowanego przez osobę zastępowana, osoba zastępująca, dni od do, zdefiniowania szczegółowego dostępu do danych dla danego zastępstwa, zakończenia zastępstwa. Zarządzanie kontem System musi umożliwiać zarządzanie i przeglądanie danych zautoryzowanego użytkownika oraz użytkownika powiązanego z interesantem z systemu dziedzinowego. Użytkownik zalogowany do systemu musi mieć możliwość przeglądania i zmiany własnych danych: typ podmiotu (podmiot, osoba fizyczna), imię, nazwisko / nazwa, dane kontaktowe standardowe: telefon, , fax, www, adres korespondencyjny, dane kontaktowe dodatkowe. Użytkownik musi mieć możliwość zmiany hasła. Użytkownik musi mieć możliwość powiązania kont z kontem epuap. Użytkownik musi mieć możliwość odłączenia konta od epuap. Użytkownik musi mieć możliwość przeglądu danych z systemu dziedzinowego, o ile jego konto zostało powiązane z kontem kontrahenta systemu dziedzinowego. Dane podstawowe prezentowane w przypadku powiązania konta z kontrahentem SD to co najmniej: Nazwisko Imię / Nazwa, Typ, PESEL, NIP, Data wyrejestrowania lub zgonu (jeśli widnienie w SD). O ile konto powiązane jest z SD, system musi prezentować: dane zameldowania, o ile użytkownik jest zameldowany na terenie JST, listę nieruchomości, gdzie dla każdej nieruchomości prezentowana jest wielkość, typ nieruchomości, typ własności lista opłat i podatków pobieranych z tytułu nieruchomości: m.in.: podatek od osób fizycznych, podatek od osób prawnych, opłaty za śmieci, opłaty za czynsze, wodę, ścieki, listę dzieci, o ile zalogowany użytkownik jest osobą fizyczną posiadającą dzieci do lat 18 zameldowane w tym samym gospodarstwie domowym, listę środków transportu podlegającą opłatom o ile SD użytkownik jest podmiotem prawnym posiadającym opodatkowane środki transportu, listę aktualnych zezwoleń na sprzedaż napojów alkoholowych, o ile zalogowany użytkownik jest podmiotem prawnym, listę psów, listę dokumentów z rozdzieleniem na dokumenty wpływające do JST oraz wychodzące z JST dla zalogowanego użytkownika. Wszystkie dane muszą być pobierane z systemów SD i EZD. Administrator musi mieć możliwość powiązania użytkownika z kontem kontrahenta SD. Elektroniczne Biuro Obsługi Interesanta Moduł będzie stanowił wirtualny punkt przyjęć formularzy elektronicznych stosowanych w urzędzie oraz informacji dotyczących sposobu załatwienia każdej sprawy, którą można zrealizować w urzędzie. Moduł musi być podzielony na część publiczną udostępnianą niezalogowanym użytkownikom oraz część wewnętrzną dla administratora systemu. Część ta prezentuje uprzednio zredagowane karty usług spraw urzędowych świadczonych przez Urząd. Moduł musi posiadać stronę główną umożliwiającą dodanie nazwy adresu, znaku graficznego JST, ustawienie głównych funkcji, do których szybko mogą dotrzeć klienci JST. Moduł w części publicznej musi prezentować pokategoryzowane karty usług pod kątem zdarzeń, wydziałów i innych dodatkowych klasyfikacji. Użytkownik w części publicznej powinien mieć możliwość przejrzenia karty usługi, dla której prezentowane są: opis zredagowany przez administratora,

12 Strona12 dostępne terminy wizyt w urzędzie, możliwość zarezerwowania terminu wizyty w urzędzie, możliwość przejścia do wypełnienia formularza elektronicznego na epuap. Karta usługi powinna być charakteryzowana przynajmniej przez następujące atrybuty: nazwę, opis, do kogo jest skierowana (obywatel czyli usługi typu A2C, przedsiębiorcy czyli usługi typu A2B, instytucji/urzędu czyli usługi typu A2A), liczba czasu obsługi klienta przy okienku dla danego rodzaju sprawy, kategorię (np. Budownictwo i Nieruchomości, Ochrona środowiska etc.). Administrator ma możliwość zdefiniowania karty usługi. Administrator musi mieć możliwość utworzenia wizualizacji karty usług. W przypadku publikowania karty usługi, administrator musi być zobowiązany do podania daty, od kiedy publikacja obowiązuje oraz powodu publikacji. W przypadku zmiany opisu karty usługi, administrator musi być zobowiązany do podania powodu zmiany wizualizacji karty usługi. W przypadku zdejmowania z publikacji kary usługi, administrator musi być zobowiązany do podania powodu zdjęcia z publikacji karty usługi. Dla każdej usługi urząd musi mieć możliwość określenia dni i godzin dyżurów, w których pracownik gminy jest w stanie pomóc mieszkańcom lub odpowiadać na pytania w danym zakresie. Obsługa dyżurów powinna obejmować: ustalenie dyżuru w zakresie (karty usługi lub kilku kart usług, której dotyczy, daty od, okienka godzinnego od do), możliwość ustalenia przerwy w trakcie dyżuru. Podczas dodawania dyżuru użytkownik musi mieć możliwość wykonania automatycznej funkcji ustalenia analogicznego dyżuru powielonego w następnym tygodniu lub miesiącu. Administrator po dodaniu dyżuru musi mieć możliwość ustalenia jego publikacji ze wskazaniem daty obowiązywania od. W przypadku zmiany ustawień dyżuru, usunięcia lub zdjęcia z publikacji administrator musi być zobowiązany do podania powodu zmiany. Pracownicy obsługujący dyżury powinni mieć możliwość przejrzenia grafiku dyżurów wraz z listą osób zapisanych na spotkanie, w szczególności danych: imię, nazwisko, PESEL, , telefon. Zapisania na dyżur powinien móc dokonać zarówno użytkownik zarejestrowany w systemie jak i niezarejestrowany. W przypadku zapisania na spotkanie użytkownika zarejestrowanego, system musi automatycznie podpowiadać dane z karty użytkownika. Użytkownik musi otrzymać mailem informację w celu potwierdzenia spotkania. Moduł e-płatności Moduł zapewniający wgląd w stan rozliczeń z urzędem, zintegrowany z systemami bankowymi oraz umożliwiający uregulowanie należności online. Dostęp do danych dot. płatności będzie możliwy wyłącznie dla zarejestrowanych użytkowników Platformy, dodatkowo posiadających konto powiązane z interesantem systemu dziedzinowego. Po zalogowaniu na swoje konto obywatel lub przedsiębiorca powinien zobaczyć wszystkie swoje należności wobec urzędu pobrane z systemu dziedzinowego niezależnie od tytułu (podatki, opłaty lokalne, opłaty za śmieci, umowy dzierżawy itp.), które są wystawiane w modułach dziedzinowych oraz historię ich płatności. Będzie to przegląd wszystkich zobowiązań finansowych z uwzględnieniem tytułu należności, należności głównej (w tym Vat jeśli wymagany), odsetki, koszty upomnień, wezwań do zapłaty, salda do zapłaty, terminie płatności, kwocie już zapłaconej (w przypadku należności, która została już częściowo spłacona), kwocie zleconej płatności poprzez portal oraz dacie i godzinie zlecenia tej płatności. Każda należność powinna zawierać co najmniej takie informacje jak: numer decyzji, naliczone odsetki oraz koszty upomnień i wezwań, czy był na nią wystawiony tytuł wykonawczy itp. Możliwość prezentowania i wyszukiwania konkretnej należności według rodzaju, daty, terminu płatności itp. Jeżeli należność została dopiero częściowo spłacona to użytkownik musi mieć możliwość otrzymania pełnej informacji w układzie: ile było wpłat na daną należność, kwota każdej płatności, data płatności oraz informację czy płatność została już zaksięgowana czy nie i saldo do zapłaty. Możliwość wyświetlania historii wszystkich interakcji finansowych mieszkańca z urzędem, jakie zostały zrealizowane poprzez system. Aplikacja musi być zintegrowana z systemem bankowym Paybynet (KIR) oraz Przelewy24, w celu umożliwienia uregulowania należności online. Aplikacja 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.