POSTĘPOWANIE O UDZIELENIE ZAMÓWIENIA PUBLICZNEGO PROWADZONE W TRYBIE PRZETARGU NIEOGRANICZONEGO...

Ogłoszenie nr 612222-N-2019 z dnia 2019-10-18 r.

Gmina Pieniężno: POSTĘPOWANIE O UDZIELENIE ZAMÓWIENIA PUBLICZNEGO PROWADZONE W TRYBIE PRZETARGU NIEOGRANICZONEGO Realizacja projektu pn. „Cyfrowe usługi publiczne w Gminie Pieniężno”.
OGŁOSZENIE O ZAMÓWIENIU - Usługi

Zamieszczanie ogłoszenia: Zamieszczanie obowiązkowe

Ogłoszenie dotyczy: Zamówienia publicznego

Zamówienie dotyczy projektu lub programu współfinansowanego ze środków Unii Europejskiej

Tak

Nazwa projektu lub programu
„Cyfrowe usługi publiczne w Gminie Pieniężno”, realizowanego w ramach Regionalnego Programu Operacyjnego Województwa Warmińsko-Mazurskiego na lata 2014-2020, Oś priorytetowa 3. Cyfrowy Region, Działanie 3.1 Cyfrowa dostępność informacji sektora publicznego oraz wysoka jakość e-usług publicznych.

O zamówienie mogą ubiegać się wyłącznie zakłady pracy chronionej oraz wykonawcy, których działalność, lub działalność ich wyodrębnionych organizacyjnie jednostek, które będą realizowały zamówienie, obejmuje społeczną i zawodową integrację osób będących członkami grup społecznie marginalizowanych

Nie

Należy podać minimalny procentowy wskaźnik zatrudnienia osób należących do jednej lub więcej kategorii, o których mowa w art. 22 ust. 2 ustawy Pzp, nie mniejszy niż 30%, osób zatrudnionych przez zakłady pracy chronionej lub wykonawców albo ich jednostki (w %)

SEKCJA I: ZAMAWIAJĄCY

Postępowanie przeprowadza centralny zamawiający

Nie

Postępowanie przeprowadza podmiot, któremu zamawiający powierzył/powierzyli przeprowadzenie postępowania

Nie

Informacje na temat podmiotu któremu zamawiający powierzył/powierzyli prowadzenie postępowania:
Postępowanie jest przeprowadzane wspólnie przez zamawiających

Nie

Jeżeli tak, należy wymienić zamawiających, którzy wspólnie przeprowadzają postępowanie oraz podać adresy ich siedzib, krajowe numery identyfikacyjne oraz osoby do kontaktów wraz z danymi do kontaktów:

Postępowanie jest przeprowadzane wspólnie z zamawiającymi z innych państw członkowskich Unii Europejskiej

Nie

W przypadku przeprowadzania postępowania wspólnie z zamawiającymi z innych państw członkowskich Unii Europejskiej – mające zastosowanie krajowe prawo zamówień publicznych:
Informacje dodatkowe:

I. 1) NAZWA I ADRES: Gmina Pieniężno, krajowy numer identyfikacyjny 53081500000000, ul. ul. Generalska 8 , 14-520 Pieniężno, woj. warmińsko-mazurskie, państwo Polska, tel. 055 237 46 00, e-mail urzad@pieniezno.pl, faks 055 237 46 01.
Adres strony internetowej (URL): www.pieniezno.pl
Adres profilu nabywcy:
Adres strony internetowej pod którym można uzyskać dostęp do narzędzi i urządzeń lub formatów plików, które nie są ogólnie dostępne http://bip.pieniezno.pl/przetarg/4379/in-271-1-4-2019

I. 2) RODZAJ ZAMAWIAJĄCEGO: Administracja samorządowa

I.3) WSPÓLNE UDZIELANIE ZAMÓWIENIA (jeżeli dotyczy):

Podział obowiązków między zamawiającymi w przypadku wspólnego przeprowadzania postępowania, w tym w przypadku wspólnego przeprowadzania postępowania z zamawiającymi z innych państw członkowskich Unii Europejskiej (który z zamawiających jest odpowiedzialny za przeprowadzenie postępowania, czy i w jakim zakresie za przeprowadzenie postępowania odpowiadają pozostali zamawiający, czy zamówienie będzie udzielane przez każdego z zamawiających indywidualnie, czy zamówienie zostanie udzielone w imieniu i na rzecz pozostałych zamawiających):

I.4) KOMUNIKACJA:
Nieograniczony, pełny i bezpośredni dostęp do dokumentów z postępowania można uzyskać pod adresem (URL)

Nie
http://bip.pieniezno.pl/przetarg/4379/in-271-1-4-2019

Adres strony internetowej, na której zamieszczona będzie specyfikacja istotnych warunków zamówienia

Nie
http://bip.pieniezno.pl/przetarg/4379/in-271-1-4-2019

Dostęp do dokumentów z postępowania jest ograniczony - więcej informacji można uzyskać pod adresem

Nie
http://bip.pieniezno.pl/przetarg/4379/in-271-1-4-2019

Oferty lub wnioski o dopuszczenie do udziału w postępowaniu należy przesyłać:
Elektronicznie

Nie
adres

Dopuszczone jest przesłanie ofert lub wniosków o dopuszczenie do udziału w postępowaniu w inny sposób:
Nie
Inny sposób:

Wymagane jest przesłanie ofert lub wniosków o dopuszczenie do udziału w postępowaniu w inny sposób:
Nie
Inny sposób:

Adres:

Komunikacja elektroniczna wymaga korzystania z narzędzi i urządzeń lub formatów plików, które nie są ogólnie dostępne

Nie
Nieograniczony, pełny, bezpośredni i bezpłatny dostęp do tych narzędzi można uzyskać pod adresem: (URL)

SEKCJA II: PRZEDMIOT ZAMÓWIENIA

II.1) Nazwa nadana zamówieniu przez zamawiającego: POSTĘPOWANIE O UDZIELENIE ZAMÓWIENIA PUBLICZNEGO PROWADZONE W TRYBIE PRZETARGU NIEOGRANICZONEGO Realizacja projektu pn. „Cyfrowe usługi publiczne w Gminie Pieniężno”.
Numer referencyjny: IN.271.1.4.2019
Przed wszczęciem postępowania o udzielenie zamówienia przeprowadzono dialog techniczny

Nie

II.2) Rodzaj zamówienia: Usługi
II.3) Informacja o możliwości składania ofert częściowych
Zamówienie podzielone jest na części:

Tak
Oferty lub wnioski o dopuszczenie do udziału w postępowaniu można składać w odniesieniu do:
maksymalnej liczby części 3

Zamawiający zastrzega sobie prawo do udzielenia łącznie następujących części lub grup części:

Maksymalna liczba części zamówienia, na które może zostać udzielone zamówienie jednemu wykonawcy:
3

II.4) Krótki opis przedmiotu zamówienia (wielkość, zakres, rodzaj i ilość dostaw, usług lub robót budowlanych lub określenie zapotrzebowania i wymagań ) a w przypadku partnerstwa innowacyjnego - określenie zapotrzebowania na innowacyjny produkt, usługę lub roboty budowlane: Gmina Pieniężno realizuje przedsięwzięcie pn. „Cyfrowe usługi publiczne w Gminie Pieniężno”, którego celem jest uruchomienie usług e-administracji dla mieszkańców gminy oraz stworzenie warunków technicznych i organizacyjnych, które pozwolą na ich sprawne funkcjonowanie. Realizacja przedsięwzięcia podzielona została na 3 zadania, z czego każde będzie oddzielnie oceniane: • zadanie 1 – dostawa, instalacja i wdrożenie portalu eurząd wraz z oprogramowaniem • zadanie 2 – dostawa, instalacja i uruchomienie sprzętu • zadanie 3 – wykonanie prac adaptacyjnych w pomieszczeniu serwerowni W kolejnych rozdziałach niniejszego dokumentu, Zamawiający zawarł minimalne wymagania, jakie muszą spełnić dostarczone, w ramach przedmiotowego zamówienia, rozwiązania lub wykonane prace. Szczegółowy opis przedmiotu zamówienia znajduje się na stronie internetowej

II.5) Główny kod CPV: 30200000-1
Dodatkowe kody CPV:

Kod CPV

48000000-8

30230000-0

30236000-2

45314300-4

48821000-9

32410000-0

II.6) Całkowita wartość zamówienia (jeżeli zamawiający podaje informacje o wartości zamówienia):
Wartość bez VAT:
Waluta:

(w przypadku umów ramowych lub dynamicznego systemu zakupów – szacunkowa całkowita maksymalna wartość w całym okresie obowiązywania umowy ramowej lub dynamicznego systemu zakupów)

II.7) Czy przewiduje się udzielenie zamówień, o których mowa w art. 67 ust. 1 pkt 6 i 7 lub w art. 134 ust. 6 pkt 3 ustawy Pzp: Nie
Określenie przedmiotu, wielkości lub zakresu oraz warunków na jakich zostaną udzielone zamówienia, o których mowa w art. 67 ust. 1 pkt 6 lub w art. 134 ust. 6 pkt 3 ustawy Pzp:
II.8) Okres, w którym realizowane będzie zamówienie lub okres, na który została zawarta umowa ramowa lub okres, na który został ustanowiony dynamiczny system zakupów:
miesiącach: lub dniach:
lub
data rozpoczęcia: lub zakończenia: 2019-12-31

II.9) Informacje dodatkowe:

SEKCJA III: INFORMACJE O CHARAKTERZE PRAWNYM, EKONOMICZNYM, FINANSOWYM I TECHNICZNYM

III.1) WARUNKI UDZIAŁU W POSTĘPOWANIU

III.1.1) Kompetencje lub uprawnienia do prowadzenia określonej działalności zawodowej, o ile wynika to z odrębnych przepisów
Określenie warunków: Określenie warunków: postępowaniu Zamawiający nie precyzuje szczegółowego opisu sposobu dokonywania oceny spełniania tego warunku. Zamawiający uzna warunek za spełniony, jeżeli Wykonawca potwierdzi spełnianie tego warunku składając odpowiednie oświadczenie - Załącznik nr 5.
Informacje dodatkowe
III.1.2) Sytuacja finansowa lub ekonomiczna
Określenie warunków: Zamawiający nie precyzuje szczegółowego opisu sposobu dokonywania oceny spełniania tego warunku.
Informacje dodatkowe
III.1.3) Zdolność techniczna lub zawodowa
Określenie warunków: Zamawiający uzna warunek za spełniony, jeżeli Wykonawca: 1) w okresie ostatnich trzech lat przed upływem terminu składania ofert, a jeżeli okres prowadzenia działalności jest krótszy w tym okresie zrealizował należycie niżej wymienioną dostawę, przy czym w przypadku wspólnego ubiegania się Wykonawców o zamówienie, niniejszą dostawę zrealizował co najmniej jeden z Wykonawców w odniesieniu: a) [dotyczy, odpowiednio, Zadanie 1]: o 1 (jedną) usługę polegającą na dostawie i wdrożeniu systemu informatycznego obejmującego System Elektronicznego Zarządzania Dokumentacją (w rozumieniu Instrukcji Kancelaryjnej realizującego zadania zgodnie z zapisami Kodeksu Postępowania Administracyjnego) o wartości nie mniejszej niż 200 000.000 zł brutto (wartość ta dotyczy dostawy i wdrożenia systemów i nie obejmuje innych usług lub dostaw, w tym dostaw sprzętu, realizowanych w ramach tego samego zamówienia); o 1 (jedną) usługę polegającą na dostawie i wdrożeniu 1 (jednego) portalu e-usług dla administracji publicznej wraz z uruchomieniem na tym portalu co najmniej 10 e-Usług, o wartości co najmniej 50 000.00 zł brutto (wartość ta dotyczy dostawy i wdrożenia systemu i nie obejmuje innych usług lub dostaw, w tym dostaw sprzętu, realizowanych w ramach tego samego zamówienia). o opracował co najmniej 10 wzorów dokumentów elektronicznych na platformie ePUAP, w ramach jednego lub kilku zamówień b) [dotyczy, odpowiednio, Zadanie 2] co najmniej jedno zamówienie obejmujące dostawę sprzętu komputerowego, serwerów i macierzy na kwotę co najmniej 30 000 zł brutto. c) [dotyczy, odpowiednio, Zadanie 3] co najmniej jedno zamówienie obejmujące realizację wykonanie instalacji elektrycznej oraz instalacji kontroli dostępu. 2) Skieruje do realizacji zamówienia: a) [dotyczy, odpowiednio, Zadanie 1]: o co najmniej 1 (jedną) osobę na stanowisko Kierownika Projektu – posiadającą:  certyfikat potwierdzający posiadaną wiedzę z zakresu metodyki zarządzania projektami Prince2 lub innej równoważnej,  minimum 3 letnie doświadczenie w zarządzaniu projektami informatycznymi, potwierdzone udziałem proponowanego specjalisty na stanowisku Kierownika Projektu lub równoważnym w przynajmniej 1 zakończonym sukcesem (tj. odebranym przez Zamawiającego) projekcie informatycznym polegającym na wdrożeniu lub modyfikacji systemu informatycznego dla jednostki administracji publicznej o wartości nie mniejszej niż 200 000,00 zł brutto. o co najmniej 1 (jedną) osobę na stanowisko Szefa Programistów posiadającą:  wykształcenie wyższe o profilu informatycznym;  posiadającego wiedzę z zakresu zarządzania projektami informatyczki potwierdzoną certyfikatem Prince 2 Foundation Certificate in Project Management lub inny równoważny;  minimum 5 letnie doświadczenie w kierowaniu zespołem programistów bądź wdrożeniowców, potwierdzone udziałem proponowanego specjalisty na stanowisku Szefa Programistów lub równoważnym w przynajmniej 3 (dwóch) zakończonym sukcesem (tj. odebranym przez Zamawiającego) projektach informatycznym polegającym na wdrożeniu lub modyfikacji systemów informatycznych. o co najmniej 1 (jedną) osobę na stanowisko Wdrożeniowca systemów informatycznych, z których każda posiada:  minimum 5-letnie doświadczenie we wdrażaniu systemów elektronicznego zarządzania dokumentacją (w rozumieniu Instrukcji Kancelaryjnej realizującego zadania zgodnie z zapisami Kodeksu Postępowania Administracyjnego) zintegrowanego z platformą ePUAP, o co najmniej 1 (jedną) osobę na stanowisko Programisty systemu EZD, z których co najmniej jedna posiada:  minimum 5 letnie doświadczenie w zakresie programowania systemów klasy EZD (Elektronicznego Zarządzania Dokumentacją w rozumieniu Instrukcji Kancelaryjnej realizującego zadania zgodnie z zapisami Kodeksu Postępowania Administracyjnego).  Minimum dwa certyfikaty potwierdzające umiejętności programistyczne w języku programowania lub środowisku w jakim stworzono system EZD wydane nie dawniej niż 3 lata przed upływem terminu składania ofert. b) [dotyczy, odpowiednio, Zadanie 3]: o co najmniej 1 osobę, Projektant, posiadającą uprawnienia budowlane w specjalności instalacyjnej w zakresie sieci, instalacji oraz urządzeń elektrycznych i elektroenergetycznych – upoważniające do projektowania obiektu budowlanego lub kierowania robotami związanymi z takowym obiektem uwaga: jedna osoba może wystąpić tylko raz w ofercie 8. Wykonawca może w celu potwierdzenia spełniania warunków udziału w postępowaniu, w stosownych sytuacjach oraz w odniesieniu do konkretnego zamówienia, lub jego części, polegać na zdolnościach zawodowych innych podmiotów, niezależnie od charakteru prawnego łączących go z nimi stosunków prawnych. Wykonawca w takiej sytuacji zobowiązany jest udowodnić Zamawiającemu, że realizując zamówienie, będzie dysponował niezbędnymi zasobami tych podmiotów, w szczególności przedstawiając w tym celu zobowiązanie tych podmiotów do oddania mu do dyspozycji niezbędnych zasobów na potrzeby realizacji zamówienia. 9. Zobowiązanie podmiotu trzeciego, o którym mowa w podpunkcie 8, może przyjąć formę dowolnego dokumentu lub dokumentów. Zobowiązanie powinno być skonkretyzowane, jednoznaczne oraz wskazywać na fakt rzeczywistego dysponowania przez Wykonawcę udostępnionymi przez podmiot trzeci zasobami. 10. Wykonawca, który powołuje się na zasoby innych podmiotów, w celu wykazania braku istnienia wobec nich podstaw wykluczenia oraz spełniania, w zakresie, w jakim powołuje się na ich zasoby, warunków udziału w postępowaniu zamieszcza informacje o tych podmiotach wg wzoru na załączniku nr 5 do SIWZ. 11. Zamawiający ocenia, czy udostępniane Wykonawcy przez inne podmioty zdolności techniczne lub zawodowe, pozwalają na wykazanie przez Wykonawcę spełniania warunków udziału w postępowaniu oraz bada, czy nie zachodzą wobec tego podmiotu podstawy wykluczenia, o których mowa w art. 24 ust. 1 pkt 12-23 i ust.5 pkt 1, 2, 4, 8 ustawy. 12. W odniesieniu do warunku dotyczącego doświadczenia Wykonawcy mogą polegać na zdolnościach innych podmiotów, jeśli podmioty te zrealizują dostawy, do realizacji których te zdolności są wymagane. Podmioty te będą więc faktycznymi podwykonawcami. 13. Jeżeli zdolności zawodowe podmiotu trzeciego, o którym mowa w pkt. 8 wyżej, nie potwierdzają spełnienia przez Wykonawcę warunków udziału w postępowaniu lub zachodzą wobec tych podmiotów podstawy wykluczenia, Zamawiający żąda, aby Wykonawca w terminie określonym przez Zamawiającego: 1) zastąpił ten podmiot innym podmiotem lub podmiotami lub 2) zobowiązał się do osobistego wykonania odpowiedniej części zamówienia, jeżeli wykaże zdolności zawodowe, o których mowa w pkt 7.1. 14. W celu oceny czy Wykonawca polegając na zdolnościach lub sytuacji innych podmiotów na zasadach określonych w art. 22a ustawy PZP, będzie dysponował niezbędnymi zasobami w stopniu umożliwiającym należyte wykonanie zamówienia publicznego oraz oceny, czy stosunek łączący Wykonawcę z tymi podmiotami gwarantuje rzeczywisty dostęp do ich zasobów, Zamawiający może żądać dokumentów, które określają w szczególności: 1) zakres dostępnych Wykonawcy zasobów innego podmiotu, 2) sposób wykorzystania zasobów innego podmiotu, przez Wykonawcę, przy wykonywaniu zamówienia publicznego, 3) zakres i okres udziału innego podmiotu przy Wykonywaniu zamówienia publicznego, 4) czy podmiot, na zdolnościach którego Wykonawca polega w odniesieniu do warunków udziału w postępowaniu dotyczących doświadczenia, zrealizuje usługi, których wskazane zdolności dotyczą. 15. Zamawiający żąda od Wykonawcy, który polega na zdolnościach lub sytuacji innych podmiotów na zasadach określonych w art. 22a ustawy PZP, przedstawienia w odniesieniu do tych podmiotów dokumentów wymienionych w rozdziale VII pkt 4 ppkt 3 lit. a-d, w celu potwierdzenia braku podstaw wykluczenia. 16. Zobowiązanie podmiotu trzeciego w zakresie udostępnienia zasobów (Załącznik nr 8) należy dołączyć do oferty, zaś przed udzieleniem zamówienia Zamawiający wzywa Wykonawcę, którego oferta została najwyżej oceniona, do złożenia dokumentów, z których wynikają informacje określone w pkt 15 oraz Zamawiający wzywa Wykonawcę do złożenia dokumentów, z których wynikają informacje określone w pkt 14 niniejszego rozdziału.
Zamawiający wymaga od wykonawców wskazania w ofercie lub we wniosku o dopuszczenie do udziału w postępowaniu imion i nazwisk osób wykonujących czynności przy realizacji zamówienia wraz z informacją o kwalifikacjach zawodowych lub doświadczeniu tych osób:
Informacje dodatkowe:

III.2) PODSTAWY WYKLUCZENIA

III.2.1) Podstawy wykluczenia określone w art. 24 ust. 1 ustawy Pzp
III.2.2) Zamawiający przewiduje wykluczenie wykonawcy na podstawie art. 24 ust. 5 ustawy Pzp Tak Zamawiający przewiduje następujące fakultatywne podstawy wykluczenia: Tak (podstawa wykluczenia określona w art. 24 ust. 5 pkt 1 ustawy Pzp)
Tak (podstawa wykluczenia określona w art. 24 ust. 5 pkt 2 ustawy Pzp)

Tak (podstawa wykluczenia określona w art. 24 ust. 5 pkt 4 ustawy Pzp)

III.3) WYKAZ OŚWIADCZEŃ SKŁADANYCH PRZEZ WYKONAWCĘ W CELU WSTĘPNEGO POTWIERDZENIA, ŻE NIE PODLEGA ON WYKLUCZENIU ORAZ SPEŁNIA WARUNKI UDZIAŁU W POSTĘPOWANIU ORAZ SPEŁNIA KRYTERIA SELEKCJI

Oświadczenie o niepodleganiu wykluczeniu oraz spełnianiu warunków udziału w postępowaniu
Nie
Oświadczenie o spełnianiu kryteriów selekcji
Nie

III.4) WYKAZ OŚWIADCZEŃ LUB DOKUMENTÓW , SKŁADANYCH PRZEZ WYKONAWCĘ W POSTĘPOWANIU NA WEZWANIE ZAMAWIAJACEGO W CELU POTWIERDZENIA OKOLICZNOŚCI, O KTÓRYCH MOWA W ART. 25 UST. 1 PKT 3 USTAWY PZP:

III.5) WYKAZ OŚWIADCZEŃ LUB DOKUMENTÓW SKŁADANYCH PRZEZ WYKONAWCĘ W POSTĘPOWANIU NA WEZWANIE ZAMAWIAJACEGO W CELU POTWIERDZENIA OKOLICZNOŚCI, O KTÓRYCH MOWA W ART. 25 UST. 1 PKT 1 USTAWY PZP

III.5.1) W ZAKRESIE SPEŁNIANIA WARUNKÓW UDZIAŁU W POSTĘPOWANIU:

III.5.2) W ZAKRESIE KRYTERIÓW SELEKCJI:

III.6) WYKAZ OŚWIADCZEŃ LUB DOKUMENTÓW SKŁADANYCH PRZEZ WYKONAWCĘ W POSTĘPOWANIU NA WEZWANIE ZAMAWIAJACEGO W CELU POTWIERDZENIA OKOLICZNOŚCI, O KTÓRYCH MOWA W ART. 25 UST. 1 PKT 2 USTAWY PZP

III.7) INNE DOKUMENTY NIE WYMIENIONE W pkt III.3) - III.6)

SEKCJA IV: PROCEDURA

IV.1) OPIS
IV.1.1) Tryb udzielenia zamówienia: Przetarg nieograniczony
IV.1.2) Zamawiający żąda wniesienia wadium:

Tak
Informacja na temat wadium
1. Wykonawca jest zobowiązany do wniesienia wadium w wysokości: 1) Dla Zadania 1: 8 500,00 zł (słownie: jeden tysiąc pięćset zł). 2) Dla Zadania 2: 1 000,00 zł (słownie: jeden tysiąc zł). 3) Dla Zadania 3: 1 000,00 zł (słownie: jeden tysiąc zł). 2. Wadium musi być wniesione przed upływem terminu składania ofert w jednej lub kilku następujących formach, w zależności od wyboru Wykonawcy: 1) pieniądzu, przelewem na rachunek bankowy w BS w Pasłęku f. Pieniężno, nr rachunku 03 8313 0009 0042 6015 2000 0020 (w tytule przelewu należy wpisać sygnaturę przetargu i wskazać którego zadania dotyczy wadium). 2) poręczeniach bankowych; 3) poręczeniach pieniężnych spółdzielczych kas oszczędnościowo-kredytowych; 4) gwarancjach bankowych; 5) gwarancjach ubezpieczeniowych; 6) poręczeniach udzielanych przez podmioty, o których mowa w art. 6b ust. 5 pkt 2 ustawy z dnia 9 listopada 2000 roku o utworzeniu Polskiej Agencji Rozwoju Przedsiębiorczości (Dz. U. z 2014 poz. 1804 oraz z 2015 poz. 978 i 1240). 3. W przypadku wnoszenia wadium w formie gwarancji bankowej lub ubezpieczeniowej, gwarancja musi być gwarancją nieodwołalną, bezwarunkową i płatną na pierwsze pisemne żądanie zamawiającego, sporządzoną zgodnie z obowiązującymi przepisami i powinna zawierać następujące elementy: a) nazwę dającego zlecenie (Wykonawcy), beneficjenta gwarancji (Zamawiającego), gwaranta (banku lub instytucji ubezpieczeniowej udzielających gwarancji) oraz wskazanie ich siedzib, b) kwotę gwarancji c) termin ważności gwarancji w formule: „od dnia …….– do dnia ………”, d) wadium musi obejmować cały okres związania ofertą, e) zobowiązanie gwaranta do zapłacenia kwoty gwarancji na pierwsze żądanie Zamawiającego w sytuacjach określonych w art. 46 ust. 4a oraz art. 46 ust. 5 ustawy. Zamawiający nie dopuszcza możliwości umieszczenia w treści gwarancji klauzuli dotyczącej pośrednictwa podmiotów trzecich. W przypadku wnoszenia wadium w formie innej niż pieniężna, zamawiający wymaga złożenia wraz z ofertą oryginału dokumentu wadialnego (gwarancji lub poręczenia). 4. Wadium wniesione w pieniądzu przelewem na rachunek bankowy musi wpłynąć na wskazany rachunek bankowy Zamawiającego, najpóźniej przed upływem terminu składania ofert pod rygorem odrzucenia Oferty. Ze względu na ryzyko związane z czasem trwania okresu rozliczeń międzybankowych Zamawiający zaleca dokonanie przelewu ze stosownym wyprzedzeniem. 5. W przypadku ubiegania się przez Wykonawcę o dwa lub trzy zadania, zobowiązany jest on do wniesienia wadium do każdego zadania odrębnie. 6. Oryginał wniesienia wadium w innej formie niż pieniężnej, odrębnie na każde zadanie zamówienia, należy dołączyć do oferty w osobnej kopercie, a kopię wpiąć do oferty. 7. Zamawiający dokona zwrotu wadium na zasadach określonych w art. 46 ust. 1-4 ustawy PZP. 8. Zgodnie z art. 46 ust. 4a i 5 ustawy Zamawiający zatrzyma wadium wraz z odsetkami w przypadku, gdy: 1) Wykonawca, którego oferta zostanie wybrana: a) odmówi podpisania umowy w sprawie zamówienia publicznego na warunkach określonych w ofercie; b) zawarcie umowy w sprawie zamówienia publicznego stanie się niemożliwe z przyczyn leżących po stronie Wykonawcy. 2) Wykonawca w odpowiedzi na wezwanie, o którym mowa w art. 26 ust. 3 i 3a ustawy PZP, z przyczyn leżących po jego stronie, nie złożył oświadczeń lub dokumentów potwierdzających okoliczności, o których mowa w art. 25 ust. 1 ustawy PZP, oświadczenia, o którym mowa w art. 25a ust. 1 ustawy PZP, pełnomocnictw lub nie wyraził zgody na poprawienie omyłki, o której mowa w art. 87 ust. 2 pkt 3 ustawy PZP, co spowodowało brak możliwości wybrania oferty złożonej przez Wykonawcę jako najkorzystniejszej.

IV.1.3) Przewiduje się udzielenie zaliczek na poczet wykonania zamówienia:

Nie
Należy podać informacje na temat udzielania zaliczek:

IV.1.4) Wymaga się złożenia ofert w postaci katalogów elektronicznych lub dołączenia do ofert katalogów elektronicznych:

Nie
Dopuszcza się złożenie ofert w postaci katalogów elektronicznych lub dołączenia do ofert katalogów elektronicznych:
Nie
Informacje dodatkowe:

IV.1.5.) Wymaga się złożenia oferty wariantowej:

Nie
Dopuszcza się złożenie oferty wariantowej

Złożenie oferty wariantowej dopuszcza się tylko z jednoczesnym złożeniem oferty zasadniczej:

IV.1.6) Przewidywana liczba wykonawców, którzy zostaną zaproszeni do udziału w postępowaniu
(przetarg ograniczony, negocjacje z ogłoszeniem, dialog konkurencyjny, partnerstwo innowacyjne)

Liczba wykonawców
Przewidywana minimalna liczba wykonawców
Maksymalna liczba wykonawców
Kryteria selekcji wykonawców:

IV.1.7) Informacje na temat umowy ramowej lub dynamicznego systemu zakupów:

Umowa ramowa będzie zawarta:

Czy przewiduje się ograniczenie liczby uczestników umowy ramowej:

Przewidziana maksymalna liczba uczestników umowy ramowej:

Informacje dodatkowe:

Zamówienie obejmuje ustanowienie dynamicznego systemu zakupów:

Adres strony internetowej, na której będą zamieszczone dodatkowe informacje dotyczące dynamicznego systemu zakupów:

Informacje dodatkowe:

W ramach umowy ramowej/dynamicznego systemu zakupów dopuszcza się złożenie ofert w formie katalogów elektronicznych:

Przewiduje się pobranie ze złożonych katalogów elektronicznych informacji potrzebnych do sporządzenia ofert w ramach umowy ramowej/dynamicznego systemu zakupów:

IV.1.8) Aukcja elektroniczna
Przewidziane jest przeprowadzenie aukcji elektronicznej (przetarg nieograniczony, przetarg ograniczony, negocjacje z ogłoszeniem)
Należy podać adres strony internetowej, na której aukcja będzie prowadzona:

Należy wskazać elementy, których wartości będą przedmiotem aukcji elektronicznej:
Przewiduje się ograniczenia co do przedstawionych wartości, wynikające z opisu przedmiotu zamówienia:

Należy podać, które informacje zostaną udostępnione wykonawcom w trakcie aukcji elektronicznej oraz jaki będzie termin ich udostępnienia:
Informacje dotyczące przebiegu aukcji elektronicznej:
Jaki jest przewidziany sposób postępowania w toku aukcji elektronicznej i jakie będą warunki, na jakich wykonawcy będą mogli licytować (minimalne wysokości postąpień):
Informacje dotyczące wykorzystywanego sprzętu elektronicznego, rozwiązań i specyfikacji technicznych w zakresie połączeń:
Wymagania dotyczące rejestracji i identyfikacji wykonawców w aukcji elektronicznej:
Informacje o liczbie etapów aukcji elektronicznej i czasie ich trwania:

Czas trwania:

Czy wykonawcy, którzy nie złożyli nowych postąpień, zostaną zakwalifikowani do następnego etapu:
Warunki zamknięcia aukcji elektronicznej:

IV.2) KRYTERIA OCENY OFERT
IV.2.1) Kryteria oceny ofert:
IV.2.2) Kryteria

IV.2.3) Zastosowanie procedury, o której mowa w art. 24aa ust. 1 ustawy Pzp (przetarg nieograniczony)

IV.3) Negocjacje z ogłoszeniem, dialog konkurencyjny, partnerstwo innowacyjne
IV.3.1) Informacje na temat negocjacji z ogłoszeniem
Minimalne wymagania, które muszą spełniać wszystkie oferty:

Przewidziane jest zastrzeżenie prawa do udzielenia zamówienia na podstawie ofert wstępnych bez przeprowadzenia negocjacji
Przewidziany jest podział negocjacji na etapy w celu ograniczenia liczby ofert:
Należy podać informacje na temat etapów negocjacji (w tym liczbę etapów):

Informacje dodatkowe

IV.3.2) Informacje na temat dialogu konkurencyjnego
Opis potrzeb i wymagań zamawiającego lub informacja o sposobie uzyskania tego opisu:

Informacja o wysokości nagród dla wykonawców, którzy podczas dialogu konkurencyjnego przedstawili rozwiązania stanowiące podstawę do składania ofert, jeżeli zamawiający przewiduje nagrody:

Wstępny harmonogram postępowania:

Podział dialogu na etapy w celu ograniczenia liczby rozwiązań:
Należy podać informacje na temat etapów dialogu:

Informacje dodatkowe:

IV.3.3) Informacje na temat partnerstwa innowacyjnego
Elementy opisu przedmiotu zamówienia definiujące minimalne wymagania, którym muszą odpowiadać wszystkie oferty:

Podział negocjacji na etapy w celu ograniczeniu liczby ofert podlegających negocjacjom poprzez zastosowanie kryteriów oceny ofert wskazanych w specyfikacji istotnych warunków zamówienia:

Informacje dodatkowe:

IV.4) Licytacja elektroniczna
Adres strony internetowej, na której będzie prowadzona licytacja elektroniczna:

Adres strony internetowej, na której jest dostępny opis przedmiotu zamówienia w licytacji elektronicznej:

Wymagania dotyczące rejestracji i identyfikacji wykonawców w licytacji elektronicznej, w tym wymagania techniczne urządzeń informatycznych:

Sposób postępowania w toku licytacji elektronicznej, w tym określenie minimalnych wysokości postąpień:

Informacje o liczbie etapów licytacji elektronicznej i czasie ich trwania:

Czas trwania:

Wykonawcy, którzy nie złożyli nowych postąpień, zostaną zakwalifikowani do następnego etapu:

Termin składania wniosków o dopuszczenie do udziału w licytacji elektronicznej:
Data: godzina:
Termin otwarcia licytacji elektronicznej:

Termin i warunki zamknięcia licytacji elektronicznej:

Istotne dla stron postanowienia, które zostaną wprowadzone do treści zawieranej umowy w sprawie zamówienia publicznego, albo ogólne warunki umowy, albo wzór umowy:

Wymagania dotyczące zabezpieczenia należytego wykonania umowy:

Informacje dodatkowe:

IV.5) ZMIANA UMOWY
Przewiduje się istotne zmiany postanowień zawartej umowy w stosunku do treści oferty, na podstawie której dokonano wyboru wykonawcy: Tak
Należy wskazać zakres, charakter zmian oraz warunki wprowadzenia zmian:
Należy wskazać zakres, charakter zmian oraz warunki wprowadzenia zmian: Przewidywane zmiany umowy i warunki ich wprowadzenia zostały określone we wzorze umowy (Załącznik nr 9).
IV.6) INFORMACJE ADMINISTRACYJNE

IV.6.1) Sposób udostępniania informacji o charakterze poufnym (jeżeli dotyczy):

Środki służące ochronie informacji o charakterze poufnym

IV.6.2) Termin składania ofert lub wniosków o dopuszczenie do udziału w postępowaniu:
Data: 2019-10-25, godzina: 12:00,
Skrócenie terminu składania wniosków, ze względu na pilną potrzebę udzielenia zamówienia (przetarg nieograniczony, przetarg ograniczony, negocjacje z ogłoszeniem):
Nie
Wskazać powody:

Język lub języki, w jakich mogą być sporządzane oferty lub wnioski o dopuszczenie do udziału w postępowaniu
>
IV.6.3) Termin związania ofertą: do: okres w dniach: 30 (od ostatecznego terminu składania ofert)
IV.6.4) Przewiduje się unieważnienie postępowania o udzielenie zamówienia, w przypadku nieprzyznania środków pochodzących z budżetu Unii Europejskiej oraz niepodlegających zwrotowi środków z pomocy udzielonej przez państwa członkowskie Europejskiego Porozumienia o Wolnym Handlu (EFTA), które miały być przeznaczone na sfinansowanie całości lub części zamówienia:
IV.6.5) Przewiduje się unieważnienie postępowania o udzielenie zamówienia, jeżeli środki służące sfinansowaniu zamówień na badania naukowe lub prace rozwojowe, które zamawiający zamierzał przeznaczyć na sfinansowanie całości lub części zamówienia, nie zostały mu przyznane
IV.6.6) Informacje dodatkowe:

ZAŁĄCZNIK I - INFORMACJE DOTYCZĄCE OFERT CZĘŚCIOWYCH

Część nr:

Nazwa:

Dostawa, instalacja i wdrożenie portalu e-urząd wraz z oprogramowaniem

1) Krótki opis przedmiotu zamówienia (wielkość, zakres, rodzaj i ilość dostaw, usług lub robót budowlanych lub określenie zapotrzebowania i wymagań) a w przypadku partnerstwa innowacyjnego -określenie zapotrzebowania na innowacyjny produkt, usługę lub roboty budowlane:Przedmiotem niniejszego zadania jest wdrożenie portalu e-urząd wraz z katalogiem 16 elektronicznych usług publicznych, które będą świadczone przez Urząd Miejski Pieniężno (UM) oraz informatyzacja procedur wewnętrznych w UM. Uruchamiane e-usługi charakteryzować się będą wysokim poziomem dojrzałości (13 usług transakcyjnych – poziom 4 i 3 na 3 poziomie dojrzałości), większość z nich charakteryzuje wysoki potencjał korzystania (dotyczą często załatwianych spraw). Po stronie Wykonawcy leży uruchomienie e-usług i połączenie ich z posiadanymi systemami informatycznymi SD Zamawiającego. Jeżeli uruchomienie portalu e-urząd wraz e-usługami będzie wymagało modernizacji systemów informatycznych oraz ich API lub otrzymanie API od producenta systemów posiadanych przez Zamawiającego, to po stronie Wykonawcy leży, jeżeli jest konieczne, pozyskanie niezbędnych informacji do realizacji zamówienia, zawarcie koniecznych umów itp. Po stronie Wykonawcy leży również uporządkowanie plików baz danych SD oraz jeżeli będzie wymagał tego system e-urząd połączeniu ich w jedną bazę, przeprowadzenia niezbędnej konwersji danych oraz dostarczeniu narzędzia/i do porządkowania danych osobowych powstałej bazy danych. Koszt tej operacji należy zawrzeć w ofercie wraz z asystą techniczną oraz wdrożeniem systemów informatycznych w UM Pieniężno. Projekt zakłada integrację systemów informatycznych UM, wykorzystanie możliwości platformy e-urząd i uruchomienie dedykowanego rozwiązania front-office dla mieszkańców. Portal e-urząd, w związku z wdrażaniem e-usług w ramach projektu, ma spełniać wymagania dot. interoperacyjności i wytyczne WCAG 2.0 w zakresie dostępności. Zaplanowane rozwiązania uwzględniają potrzeby osób niepełnosprawnych. 1. Ogólne wymogi związane z dostępnością treści Wszystkie rozwiązania wdrażane w ramach projektu w tzw. części publicznej 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. zastosowanie znaczników semantycznych, skrótów klawiaturowych interpretowanych przez programy czytające do nawigacji po stronie internetowej; f. opisanie stron internetowych w plikach CSS; g. zastosowanie w kodzie HTML logicznej i intuicyjnej sekwencji nawigacji oraz czytania; h. instrukcje i komunikaty nie będą zależeć od kształtu, lokalizacji wizualnej, miejsca, dźwięku; i. kolor nie będzie używany jako jedyna metoda do przekazywania treści i rozróżniania elementów wizualnych; j. zapewniony zostanie mechanizm, dzięki któremu użytkownik zatrzyma dźwięki, spauzuje, wyciszy lub zmieni głośność; k. 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; l. 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 %; m. 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. zostanie zapewniony mechanizm pauzy, zatrzymania, ukrycia dla informacji, które są automatycznie przesuwane, przewijane lub mrugające; d. nie zostaną utworzone treści, które migają więcej niż 3 razy na sekundę; e. 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; f. określenie każdej podstrony serwisu internetowego przez unikalny i sensowny tytuł; g. zapewnienie logicznej i intuicyjnej kolejności nawigacji po linkach, elementach formularzy itp.; h. 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; i. zapewnienie znalezienia innych stron w serwisie na wiele sposobów, tj. spis treści, mapa serwisu, wyszukiwarka; j. zapewnienie jednoznacznego opisu nagłówków i etykiet; k. zapewnienie, że nie będą dublowane nagłówki i etykiety; l. 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:langw 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; 4. W zakresie zasady kompatybilności: a. zostanie przeprowadzona weryfikacja kodu HTML i CSS pod kątem błędu przy wykorzystaniu walidatorów . 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. f. Zawierać logo i nazwę urzędu lub Gminy Pieniężno 2. 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 Zamawiającego 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 Zamawiającego 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, NIP, 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. 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 3. Ogólne warunki licencjonowania dostarczonych systemów informatycznych, portali lub oprogramowania 1. Licencjobiorcą wszystkich licencji będzie Gmina Pieniężno. 2. Oferowane licencje dotyczą oprogramowania, systemu lub portalu/i, w skrócie licencje, i muszą pozwalać na użytkowanie zgodnie z przepisami prawa. 3. Licencje nie mogą ograniczać prawa licencjobiorcy do rozbudowy, zwiększenia ilości serwerów obsługujących oprogramowanie, przeniesienia danych na osobny serwer aplikacji, osobny serwer plików. 4. Licencje muszą być licencją bez ograniczenia ilości użytkowników, komputerów, serwerów, na których można zainstalować i używać oprogramowanie. 5. Licencje nie mogą w żaden sposób ograniczać sposobu pracy użytkowników końcowych (np. praca w sieci LAN, praca zdalna poprzez Internet). 6. Licencje nie mogą ograniczać prawa licencjobiorcy do wykonania kopii bezpieczeństwa oprogramowania w ilości, którą uzna za stosowną. 7. Licencje nie mogą ograniczać prawa licencjobiorcy do instalacji użytkowania oprogramowania na serwerach zapasowych uruchamianych w przypadku awarii serwerów podstawowych. 8. Licencje nie mogą ograniczać prawa licencjobiorcy do korzystania z oprogramowania na dowolnym komputerze klienckim (licencja nie może być przypisana do komputera/urządzenia). 9. Wykonawca dostarczy oprogramowanie niezbędne do wdrożenia oraz prawidłowego funkcjonowania systemu dla wszystkich Użytkowników, bez konieczności nabycia jakichkolwiek dodatkowych licencji w nieograniczonym czasie. 10. Udzielona licencja musi obejmować całość dostarczanego rozwiązania. Jeśli w ramach licencji konieczne jest udzielenie licencji na jakąkolwiek część systemu przez inny podmiot to wymaga się jej udzielenia Zamawiającemu. Udzielona w ten sposób sublicencja nie może w żaden sposób ograniczać pozostałych warunków licencjonowania. 11. Licencja musi obejmować także działania oprogramowania narzędziowego (systemy operacyjne, bazy danych i inne). 12. Licencja musi zostać udzielona na czas nieokreślony dla nieograniczonej liczby podmiotów oraz użytkowników systemu. 4. Ogólne warunki gwarancji dostarczonych systemów informatycznych, portali lub oprogramowania 1. Świadczenie usługi gwarancji w okresie minimum 60 miesięcy rozpocznie swój bieg w dniu następnym po podpisaniu końcowego protokołu odbioru całego przedmiotu zamówienia przez Zamawiającego. W przypadku, jeżeli Wykonawca dokona modernizacji istniejącego systemu informatycznego, zmodernizowany system informatyczny musi zostać objęty gwarancją na warunkach określonych w niniejszym punkcie. Świadczenie usługi gwarancji ma na celu zapewnienie ciągłości sprawnego działania systemu poprzez realizację działań naprawczych wynikających z analizy ujawnionych problemów, wykrytych błędów i wad systemów, niewłaściwego działania systemu, spadku wydajności oraz zmian prawnych uniemożliwiających zgodne z prawem funkcjonowanie systemu. W szczególności: 2. Wykonawca zobowiązuje się do dostarczania wolnych od wad i zgodnych z aktualnie obowiązującym prawem kolejnych wersji oprogramowania składającego się na przedmiot zamówienia. 3. Wykonawca zobowiązuje się do aktualizacji dokumentacji użytkownika i/lub administratora. 4. Wsparcie użytkowników obejmuje świadczenie usługi wsparcia technicznego, merytorycznego oraz konsultacji w przypadku wystąpienia problemów, wykrytych błędów i wad systemów, niewłaściwego działania systemu, spadku wydajności w celu utrzymania poprawnej pracy przedmiotu zamówienia zgodnego z wymaganiami zamówienia. 5. Wykonawca zapewni w godzinach 8:00 – 15:30 w dni robocze obecność specjalistów mających niezbędną wiedzę i doświadczenie z zakresu eksploatacji przedmiotu zamówienia, którzy będą odpowiedzialni za przyjmowanie zgłoszeń i realizację działań naprawczych wynikających z analizy ujawnionych problemów, wykrytych błędów i wad systemów, niewłaściwego działania systemu, spadku wydajności. 6. W ramach gwarancji Wykonawca zobowiązany jest do nieodpłatnego: a. usuwania błędu, awarii, wady z przyczyn zawinionych przez Wykonawcę będących konsekwencją wystąpienia: błędu w systemie, błędu lub wady fizycznej pakietu aktualizacyjnego lub instalacyjnego, błędu w dokumentacji administratora lub w dokumentacji użytkownika, błędu w wykonaniu usług przez Wykonawcę; b. usuwania błędu, awarii, wady związanych z realizacją usługi wdrożenia oprogramowania; c. usuwania błędów lub awarii spowodowanych aktualizacjami oprogramowania. 7. Wykonawca musi informować Zamawiającego o dostępnych aktualizacjach i poprawkach oprogramowania najpóźniej w ciągu 7 dni od dnia publicznego udostępnienia aktualizacji bądź poprawki. 8. Portal e-urząd, w tym e-podatki, będzie zawierał przyjazny system CMS do zarządzania treścią oraz uprawnieniami użytkowników, statystyką, niezbędnymi raportami i dziennikiem zdarzeń. 9. Zgłaszający, w przypadku wystąpienia błędu, awarii, wady przesyła do Wykonawcy przy pomocy środków komunikacji zgłoszenie wystąpienia błędu/awarii/wady. 10. Wykonawca zapewnia dostosowanie do obowiązujących przepisów nie później niż w dniu ich wejścia w życie, chyba że, zmiany prawne nie zostały ogłoszone z minimum 30-dniowym terminem poprzedzającym ich wprowadzenie w życie oraz przeprowadzi aktualizację portalu e-urząd, e-podatki oraz e-usług i formularzy, jeżeli będą wymagać tego przepisy. W przypadku, jeżeli zmiany nie zostały ogłoszone z minimum 30-dniowym terminem poprzedzającym ich wprowadzenie w życie Wykonawca zobligowany jest do ich wprowadzenia w ciągu 30 dni roboczych od dnia wprowadzenia przepisu w życie. 11. Zgłoszenia będą klasyfikowane na awarie, błędy i wady: a. Awaria - oznacza sytuację, w której nie jest możliwe prawidłowe użytkowanie oprogramowania z powodu uszkodzenia lub utraty spójności danych, struktur danych. b. Błąd - niezgodne z dokumentacją użytkową lub wymaganiami Zamawiającego określonymi w SIWZ, z instrukcjami lub innymi dokumentami wytworzonymi w czasie wdrożenia działanie Oprogramowania; c. Wada - zakłócenie działania oprogramowania polegające na nienależytym działaniu jego części, nie ograniczające działania całego oprogramowania; nie mające istotnego wpływu na zastosowanie oprogramowania i nie będące awarią lub błędem. 12. Wykonawca zobowiązany jest do usunięcia awarii, błędów i wad w następujących terminach: a. Awarie w terminie 1 dni roboczych od przyjęcia zgłoszenia przez Wykonawcę. b. Błędy w terminie 3 dni roboczych od przyjęcia zgłoszenia przez Wykonawcę, c. Wady w terminie 7 dni roboczych od przyjęcia zgłoszenia przez Wykonawcę. 13. W okresie objętym gwarancją Wykonawca zobowiązuje się do: 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 14. W przypadku stwierdzenia nieprawidłowości w funkcjonowaniu dostarczonego oprogramowania Wykonawca zobowiązany jest wprowadzić odpowiednie zmiany(poprawki) na własny koszt, w terminie 7 dni od stwierdzenia lub zgłoszenia nieprawidłowości. 15. Wykonawca musi zagwarantować, że przedmiot Zamówienia będzie działał zgodnie z jego opisem, dostarczonymi opisami i instrukcjami oraz wymogami wynikających z przepisów prawa, o których mowa w poprzednich rozdziałach niniejszego opracowania 16. Gwarancja na system wdrożony w ramach niniejszego projektu obejmuje: nośniki elektroniczne, dokumentację techniczną dostarczoną wraz z nim oraz zgodność systemu wdrożonego w ramach niniejszego projektu ze specyfikacjami oficjalnie publikowanymi lub dostarczonymi Zamawiającemu przez Wykonawcę. 5. Dostawa, wdrożenie i uruchomienie portalu e-urząd, e-usług publicznych oraz systemu wspomagania pracy Rady Miejskiej Lp. Nazwa Ilość 1. Zakup licencji centralnej platformy portalu e-urząd 1 2. Wdrożenie centralnej platformy portalu e-urząd 1 3. Modernizacja systemu dziedzinowego, jeżeli wymaga tego wdrożenie e-usług 1 4. Integracja e-urząd z EZD oraz SD 1 5. Opracowanie i wdrożenie e-usług na platformie portalu e-urząd - 4PD i 3PD 16 6. Wdrożenie systemu wspomagania pracy Rady Miejskiej 1 5.1. Zakup licencji platformy e-urząd Platforma e-urząd to portal integrujący wszystkie dane z innych systemów, informacje o świadczonych e-usługach przez ePUAP. Jest to główny system z punktu widzenia mieszkańca, działający na styku Klient - 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 powinien: 1. zawierać opisy wszystkich usług świadczonych przez urząd na platformie ePUAP, z których mieszkaniec może skorzystać w sposób elektroniczny; 2. przykładowo wypełnione formularze wraz z opisem oraz możliwością ich pobrania w formie pdf; 3. zapewniać podgląd oraz wizualizację swoich, spersonalizowanych danych o należnościach i zobowiązaniach z tytułu podatków i opłat lokalnych – system e-podatki; 4. zapewniać możliwość dokonania płatności z tytułu podatków i opłat lokalnych – system e-podatki. 5. Portal e-urząd zostanie postawiony na serwerze zewnętrznym wybranym przez Wykonawcę i będzie zapewniał bezpieczeństwo, łączność z posiadanym serwerem pośredniczącym Zamawiającego. Wszelkie prawa do dostępu oraz prawa własności do utworzonego portalu, systemu zarządzania portalem zostaną przekazane dla Zamawiającego wraz z dostępem do portalu, administrowania portalem i utworzonych baz danych bez ograniczeń czasowych. 6. W przypadku potrzeby Wykonawca na własny koszt jednorazowo przeniesie System (portal e-urząd) na wskazany przez Zamawiającego serwer internetowy w czasie trwania okresu gwarancji. 7. Wykonawca powinien zapewnić bezawaryjność i bezpieczeństwo danych portalu e-urząd, w tym powinien być replikowalny w czasie rzeczywistym na serwer zapasowy. Dane portalu mają być kopiowane automatycznie na zewnętrzny nośnik/macierz codziennie, a w przypadku awarii serwera odtworzone w ciągu 24 godzin w przypadku awarii serwera zapasowego, w innym przypadku przeniesione z serwera zapasowego. 8. Wykonawca powinien również zapewnić odpowiednią przepustowość łącza internetowego do portalu e-urząd, biorąc pod uwagę ilość danych oraz ilość wejść na portal i odpowiednio monitorując tę przepustowość oraz dostępność portalu na poziomie 99%. 9. Wykonawca zapewni zabezpieczenie i nadzór nad Systemem pod kątem ataków z Internetu. 10. W przypadku naruszeniu bezpieczeństwa oraz dostępności Systemu, wznowienie działania serwisu powinno nastąpić w ciągu nie dłuższym niż 24 godziny od otrzymania informacji email od Zamawiającego. W przypadku sobót i niedziel oraz świąt państwowych reakcja serwisu zostaje przedłużona o te dni wolne. 11. Wykonawca powinien udzielać pomocy serwisowej dotyczącej Systemu przy zagrożeniu serwisu przed atakami Internetowymi. 12. Do zadań Wykonawcy należy automatyczne tworzeniem codziennych kopii bezpieczeństwa Systemu internetowego. 5.2. Wymagania funkcjonalne platformy e-urząd 1. Portal musi umożliwiać bezpieczne zalogowanie się przez przeglądarkę z wykorzystaniem SSO (Single Sign-On) platformy ePUAP (protokół SAML). 2. Portal musi umożliwiać pozyskiwanie z Systemu Dziedzinowego (dalej SD), 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. Prowadzenia spraw w zakresie podatku od nieruchomości od osób fizycznych. b. Prowadzenia spraw w zakresie podatku od nieruchomości od osób prawnych. c. Prowadzenia spraw w zakresie podatku rolnego od osób fizycznych. d. Prowadzenia spraw w zakresie podatku rolnego od osób prawnych. e. Prowadzenia spraw w zakresie podatku leśnego od osób fizycznych. f. Prowadzenia spraw w zakresie podatku leśnego od osób prawnych. g. Prowadzenia spraw w zakresie podatku od środków transportowych. h. Prowadzenie spraw w zakresie gospodarki komunalnej (odpady, woda i ścieki) 3. Portal musi zawierać elektroniczne biuro interesanta stanowiące wirtualny punkt przyjęć formularzy elektronicznych stosowanych w urzędzie oraz informacji dotyczących sposobu załatwienia spraw, co najmniej w zakresie odpowiadającym e-usługom wdrażanym w ramach zamówienia oraz mieć możliwość rozbudowy o kolejne usługi. 4. Portal w części publicznej musi prezentować skategoryzowane karty usług, do każdej usługi musi być przedstawiony pełny jej opis, sposób załatwienia oraz przykładowo wypełniony formularz 5. Portal musi być podzielny na część publiczną – udostępnianą niezalogowanym użytkownikom oraz część wewnętrzną – dla administratorów systemu wraz z systemem CMS. 6. Użytkownik w części publicznej powinien mieć możliwość przejrzenia karty usługi, dla której prezentowanej jest opis zredagowany przez Wykonawcę z możliwością wprowadzenia zmian przez administratorów oraz możliwość przejścia do wypełnienia formularza elektronicznego na ePUAP. 7. 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). 8. Administrator musi mieć możliwość zdefiniowania karty usługi i utworzenia jej wizualizacji. 9. Karty usług powinny umożliwiać definiowanie co najmniej takich informacji jak: a. Opisu karty b. Właściwego organu do realizacji usługi c. Kogo dotyczy usługa d. Podstawy prawnej e. Czas realizacji f. Wymaganych dokumentów g. Informację o opłatach h. Informację o trybie odwoławczym i. Rezultat realizacji usługi j. Poszczególne etapy realizacji usługi k. Poziom dostępności usługi l. Do kogo skierowana m. Informacji czy usługa wymaga autoryzacji 10. Wykonawca przygotuje i zamieści wymagane karty usług zgodnie z wymaganiami Zamawiającego 11. Wszystkie możliwe dane e-podatki muszą być pobierane z SD. 12. System musi umożliwiać zarządzanie rejestrem interesantów, gdzie każdego interesanta można: a. zidentyfikować minimum takimi danymi jak: typ podmiotu, Imię, Nazwisko, Login, dane kontaktowe (telefon, email, www, adres korespondencyjny, oraz dowolną liczbę innych form kontaktu), b. zmienić mu dane podstawowe, c. zmienić mu dane kontaktowe, d. powiązać go z interesantem z SD, e. aktywować lub dezaktywować konto interesanta, f. przypisać interesanta do grup użytkowników. 13. Administratorzy muszą mieć możliwość powiązania użytkownika z kontem kontrahenta w SD. 14. Użytkownik zalogowany do systemu musi mieć możliwość przeglądania i zmiany własnych danych: typ podmiotu (osoba fizyczna / osoba prawna), imię, nazwisko / nazwa, dane kontaktowe standardowe: telefon, email, www, adres korespondencyjny, dane kontaktowe dodatkowe. 15. Użytkownik musi mieć możliwość zmiany hasła. 16. Użytkownik musi mieć możliwość powiązania konta z kontem ePUAP. 17. Użytkownik musi mieć możliwość 3 sposoby logowania się do portalu e-urząd: poprzez profil zaufany, węzeł krajowy oraz poprzez login i hasło założone w urzędzie przez uprawnioną osobę. Podczas rejestracji takiej osoby w urzędzie, pracownik ma mieć możliwość wygenerowania formularza rejestracyjnego z możliwością potwierdzenia wyrażenia zgody na komunikację elektroniczną przez użytkownika. 18. Użytkownik musi mieć możliwość przeglądu swoich danych kontrahenta z SD, o ile jego konto zostało powiązane z kontem kontrahenta SD. 19. 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). 20. Po zalogowaniu na swoje konto interesant musi mieć możliwość wyświetlenia informacji o wszystkich swoich należnościach wobec JST pobranych z SD oraz historię swoich płatności. Portal musi umożliwiać przegląd wszystkich zobowiązań finansowych z uwzględnieniem tytułu należności, należności głównej, 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. 21. 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., o ile takimi informacjami dysponują SD. 22. Możliwość prezentowania i wyszukiwania konkretnej należności według rodzaju, daty, terminu płatności itp. 23. Możliwość wyświetlania historii wszystkich interakcji finansowych mieszkańca z urzędem, jakie zostały zrealizowane poprzez system. 24. System powinien być zintegrowany co najmniej z dwoma systemami płatniczymi. Systemy płatnicze powinny posiadać zezwolenie Komisji Nadzoru Finansowego na świadczenie usług płatniczych w charakterze krajowej instytucji płatniczej lub realizować bezpośrednie płatności z konta płatnika na rachunek urzędu. 25. 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. 26. System ma mieć możliwość wystawienia EPO udostępniane przez ePUAP. 27. Możliwość ustawienia sortowania wyświetlanych danych rosnąco lub malejąco względem dowolnego z wyświetlanych parametrów należności. 28. 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) portal winien również przedstawiać klientowi informację, którą ratę kwota płatności stanowi. 29. W przypadku, jeśli należność powstała w drodze decyzji administracyjnej urzędu numer decyzji ma być również widoczny dla klienta. 30. Możliwość ukrycia wyświetlania wybranych parametrów należności wyszukiwanych na ekranie użytkownika. 31. Aplikacja powinna posiadać mechanizmy kontroli i bezpieczeństwa chroniące użytkowników przed kilkukrotnym wniesieniem płatności z tego samego tytułu. 32. Portal 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 portalu a transakcja jeszcze jest przetwarzana. 33. Możliwość wydrukowania wypełnionego polecenia przelewu bankowego lub pocztowego, dla zaznaczonej jednej lub zaznaczonych wielu należności. 34. Możliwość wyszukiwania i prezentowania należności według jej rodzaju np. „pokaż tylko opłaty za dzierżawę” itp. 35. Możliwość wyszukiwania i prezentowania należności według statusu płatności tzn. np. pokaż tylko zaległe itp. 36. Możliwość wysyłania wiadomości za pośrednictwem sms poprzez portal lub może być wysyłka realizowana za pomocą dodatkowej aplikacji powiązanej z SD Zamawiającego lub bezpośrednio z SD: a. powinien obsługiwać wysyłkę minimum następujących typów wiadomości z systemu dziedzinowego: • Informacja o wystawionej decyzji • Informacja o zbliżającym się terminie płatności • Informacja o zaległości • Wezwanie do złożenia deklaracji/informacji b. powinien zapisywać i odpowiednio oznaczać w dzienniku zdarzeń wszystkie wysłane informacje podatkowe, c. cała komunikacja pomiędzy systemem dziedzinowym, a systemem powinna być zabezpieczona przed nieautoryzowanym dostępem, 37. Wygenerowane płatności zlecone za pośrednictwem portalu, 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. 38. Możliwość ustawienia sortowania wyświetlanych danych rosnąco lub malejąco względem dowolnego z wyświetlanych parametrów. 39. 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. 40. Możliwość przeglądu operacji księgowych już zrealizowanych tzn. opłaconych (wpłaty, zwroty, przeksięgowania) 41. 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 zaksięgowana operacja, identyfikator, rok, rata, kwota, odsetki, kwota zapłacona faktycznie, data i godzina przelewu. 42. Możliwość ustawienia sortowania wyświetlanych danych rosnąco lub malejąco względem dowolnego z wyświetlanych parametrów. 43. Możliwość wyszukiwania lub filtrowania zrealizowanych i zaksięgowanych operacji według co najmniej: kontrahenta SD, rodzaju należności, terminu płatności od – do. 44. Dla należności dotyczących nieruchomości system musi prezentować dodatkowo minimum: numer decyzji, typ nieruchomości, numer nieruchomości, numer dokumentu własności/władania, datę wydania dokumentu – pobrane z SD. 45. Dla należności dotyczących podatku od osób prawnych system musi prezentować dodatkowo rok wydania decyzji, typ dokumentu, rodzaj podatku. 46. Wszystkie parametry konfiguracyjne systemu związane z komunikacją powinny być konfigurowalne za pomocą dedykowanych formularzy będących częścią systemu. 5.3. Wymagania niefunkcjonalne platformy e-urząd 1. System musi być zaprojektowany w modelu trójwarstwowym: a. warstwa danych, b. warstwa aplikacji, c. warstwa prezentacji - przeglądarka internetowa - za pośrednictwem której następuje właściwa obsługa systemu przez użytkownika końcowego. 2. System powinien umożliwiać pracę na bazie typu Open Source bądź na komercyjnym systemie bazodanowym. 3. Użyte narzędzia będą wspierać architekturę zorientowaną na usługi SOA (Service-Oriented Architecture). 4. Wszystkie istotne dane systemu będą zapisywane w bazie danych systemu. 5. Do opisu protokołów i struktur wymiany danych usługi sieciowej wykorzystany zostanie Web Services Description Language (WSDL). Zakłada się przede wszystkim integrację wewnętrzną systemów w ramach urzędu oraz kompatybilność z systemami zewnętrznymi (ePUAP, obywatel.gov.pl). 6. W celu zapewnienia poprawnej współpracy systemów teleinformatycznych Wykonawca w porozumieniu z Zamawiającym przekaże opis usługi sieciowej do repozytorium interoperacyjności. 7. Formularze przesyłane będą za pomocą interfejsu dostępnego na stronie, której adres podany będzie na stronie Biuletynu Informacji Publicznej UM Pieniężno, poprzez zastosowanie protokołu wywoływania zdalnego dostępu do obiektów (SOAP), opisanego językiem opisu usług sieciowych (WSDL), dostępnego przez protokół komunikacyjny sieci WWW (HTTP), szyfrowanego przy użyciu protokołu szyfrującego dla sieci WWW (SSL). Do podpisywania dokumentu wykorzystany zostanie profil zaufany oraz podpis elektroniczny a także profil indywidualny nadany przez Urząd. 8. System w warstwie serwera aplikacji i bazy danych powinien mieć możliwość uruchomienia w środowiskach opartych na systemach operacyjnych z rodziny Windows lub równoważnych oraz w środowiskach opartych na systemie Linux lub równoważnych. 9. System w warstwie klienckiej powinien poprawnie działać w różnych środowiskach z minimum 5 najbardziej popularnymi przeglądarkami w Polsce (zgodnie ze statystyką prowadzoną na stronie http://gs.statcounter.com/ za okres 6 miesięcy poprzedzających miesiąc ogłoszenia postępowania określoną dla komputerów stacjonarnych „desktop”). 10. System powinien realizować wszystkie czynności przez przeglądarkę internetową. 11. System musi pracować w wersji sieciowej z wykorzystaniem protokołu TCP/IP oraz być w pełni kompatybilny z sieciami TCP/IP. 12. Architektura systemu powinna umożliwiać pracę jedno i wielostanowiskową, zapewniać jednokrotne wprowadzanie danych tak, aby były one dostępne dla wszystkich użytkowników. 13. W przypadku gdy system do pracy wykorzystuje silnik bazy danych, baza taka musi być kompatybilna z systemem operacyjnym i musi istnieć możliwość jej instalacji i pracy na zasadach określonych jak dla systemu. 14. System w zakresie wydruków musi wykorzystywać funkcjonalność systemu operacyjnego i umożliwiać wydruk na dowolnej drukarce zainstalowanej i obsługiwanej w systemie operacyjnym, na którym zostanie zainstalowane oprogramowanie (drukarki lokalne, drukarki sieciowe). 15. Interfejs użytkownika (w tym administratora) powinien być w całości polskojęzyczny. 16. Dokumentacja powinna zawierać opis funkcji programu, wyjaśniać zasady pracy z programem, oraz zawierać opisy przykładowych scenariuszy pracy. 17. Dokumentacja musi być dostępna z poziomu oprogramowania w postaci elektronicznej (pliki PDF lub DOC lub RTF) zarówno dla użytkownika jak i administratora, dla każdego z nich w zakresie ich zadań. 18. System musi zapewniać weryfikację wprowadzanych danych w formularzach i kreatorach. 19. Zapewnienie bezpieczeństwa danych zarówno na poziomie danych wrażliwych jak i komunikacji sieciowej przy zastosowaniu bezpiecznych protokołów sieciowych. 20. System powinien być skalowalny, poprzez możliwość dołączenia dodatkowych stanowisk komputerowych, zwiększenie zasobów obsługujących warstwę aplikacyjną, zwiększenie zasobów obsługujących warstwę bazy danych. 21. System powinien umożliwiać okresowe wykonywanie, w sposób automatyczny, pełnej kopii aplikacji i danych systemu. 22. System powinien posiadać funkcjonalność zarządzania dostępem do aplikacji: a. administrator systemu ma możliwość tworzenia, modyfikacji oraz dezaktywacji kont użytkowników; b. administrator systemu powinien móc nadawać uprawnienia użytkownikom; c. administrator systemu powinien mieć możliwość przypisywać użytkowników do grup; d. system pozwalać powinien na zmianę danych uwierzytelniających użytkownika. e. administrator systemu poprzez CMS ma możliwość zmiany ilości wyświetlanych danych systemu e-podatki tzn. może pewne pola może uruchomić jako widoczne lub niewidoczne dla użytkownika, szczególnie potrzebne w pierwszej fazie uruchomienia portalu e-podatki. Może to zrobić np. za pomocą checkbox-a przy nazwie danego pola lub w inny sposób. 23. System powinien posiadać możliwość określenie maksymalnej liczby nieudanych prób logowania, po przekroczeniu której użytkownik zostaje zablokowany. 24. System powinien się komunikować z systemami zewnętrznymi w sposób zapewniający poufność danych. 25. System powinien być odporny na znane techniki ataku i włamań, typowe dla technologii, w której został wykonany. 26. Docelowo system powinien być zintegrowany z modułami księgowości podatkowej oraz podatkowymi w zakresie niezbędnym do realizacji funkcjonalności e-usług, e-podatki oraz systemem EZD. 27. System powinien prowadzić dziennik zdarzeń (w postaci logów systemowych) i dostępu do obiektów danych, dokumentów, operacji na słownikach umożliwiający odtwarzanie historii aktywności poszczególnych użytkowników systemu. 28. System musi posiadać stronę główną umożliwiającą dodanie nazwy adresu oraz znaku graficznego JST. 29. System powinien mieć możliwość wykonywania raportów oraz statystyk dla administratorów portalu oraz operatorów (jeżeli administrator przydzieli dla operatora takie uprawnienia), ich drukowania. oraz zapisania w formie pdf. Raporty o ilości utworzonych użytkownikach w zadanym okresie czasu, datę utworzenia konta, dodatkowo wydruk użytkowników wraz z loginami oraz danymi powiązaniami z SD. Wszystkie wydruki muszą zawierać logotypy urzędu, projektu oraz posiadać uzgodnione nazewnictwo z Zamawiającym. Ilości pobrań/wypełnień poszczególnych e-usług. 30. System e-urząd będzie prowadził też elektroniczny rejestr aktywności użytkowników dostępny dla administratorów. 31. System powinien umożliwiać monitoring dostępności portalu e-urząd, e-usług oraz e-podatki i za pomocą emaila na konto administratora lub operatora portalu mieć możliwość wysyłania powiadomień o braku dostępności e-urząd, e-usług lub portalu e-podatki. Dane o braku dostępności będzie zapisywał w zdarzeniach i ww. informacje będą dostępne z poziomu administratora na stronie portalu e-urząd. 5.4. Wdrożenie platformy e-urząd Wdrożenie systemu obejmie: 1. Instalację i konfigurację systemu przy uzgodnieniu z Zamawiającym, wymaga się by oprogramowanie było zainstalowane na infrastrukturze Zamawiającego. 2. Instruktaże oraz asystę stanowiskową dla 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 oraz drukowaniem raportów, dla osób pełniących obowiązki administratorów systemu wskazanych przez urząd; 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. 4. zapewnienie opieki powdrożeniowej systemu w okresie 60 miesięcy (tj. do dnia podpisania końcowego protokołu odbioru całego przedmiotu zamówienia przez Zamawiającego) 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. dostosowaniu do obowiązujących przepisów nie później niż w dniu ich wejścia w życie, chyba że, zmiany prawne nie zostały ogłoszone z minimum 30-dniowym terminem poprzedzającym ich wprowadzenie w życie. W przypadku, jeżeli zmiany nie zostały ogłoszone z minimum 30-dniowym terminem poprzedzającym ich wprowadzenie w życie Wykonawca zobligowany jest do ich wprowadzenia w ciągu 30 dni roboczych od dnia wprowadzenia przepisu w życie, 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 aplikacyjnego, g. świadczeniu telefonicznie usług doradztwa i opieki w zakresie eksploatacji systemu. h. podejmowaniu czynności związanych z diagnozowaniem problemów oraz usuwaniem przyczyn nieprawidłowego funkcjonowania dostarczonego rozwiązania. Po wdrożeniu Wykonawca przekaże Zamawiającemu wszelkie niezbędne dokumenty w celu umożliwienia mu korzystania z wdrożonego oprogramowania. Dokumenty jakie powinny zostać przekazane to: 1. Pełna dokumentacja powykonawcza obejmująca: 1) opis użytych bibliotek (funkcji, parametrów), 2) szczegółowy schemat baz danych systemu, uwzględniający powiązania i zależności między tabelami, 3) opis techniczny procedur aktualizacyjnych, 4) dostarczenie wszelkich niezbędnych materiałów uzupełniających do powyższej dokumentacji powykonawczej, które są konieczne do właściwej eksploatacji systemu. 2. Instrukcje użytkownika i administratora wdrożonego systemu informatycznego. 3. Raport z przeprowadzonych testów penetracyjnych dla wdrożonego systemu informatycznego. 5.5. Integracja platformy e-urząd z systemem dziedzinowym oraz EZD Obecnie w Urzędzie Miejskim w Pieniężnie są użytkowane nw. moduły w obrębie systemu dziedzinowego SD: Tabela nr 1 Nazwa Obsługiwany obszar merytoryczny Dostawca Puma m. in.: kontrahent, statystyki dla ewidencji ludności, wyborcy, odpady komunalne, kadry, płace, akcyza, kasa, dowody osobiste i ewidencja ludności, podatki od osób fizycznych i prawnych, windykacja, dodatki mieszkaniowe, faktury, ewidencja podmiotów gospodarczych, podatek od środków transportowych, koncesje alkoholowe, środki trwałe, ewidencja ludności ZETO Software Sp. z o.o. System Groszek finanse i księgowość, środki trwałe IO Bydgoszcz W ramach integracji/modernizacji istniejącego systemu dziedzinowego (poszczególnych modułów) z portalem e-urząd, Wykonawca przeprowadzi niezbędne prace programistyczne obejmujące: 1. Przygotowanie systemu dziedzinowego do obsługi dokumentów elektronicznych sporządzonych przy pomocy formularzy elektronicznych i przesyłanych z portalu e-urząd do SD (wymiana dwukierunkowa) przy redukcji do niezbędnego minimum ręcznego wprowadzania danych z dokumentu elektronicznego. Zakres danych przenoszonych automatycznie i ręcznie zostanie określony na etapie analizy przedwdrożeniowej. 2. Utworzenie niezbędnych do procedowania e-usług elementów systemu dziedzinowego. 3. Przygotowanie systemu dziedzinowego w zakresie umożliwienia przygotowania dokumentu elektronicznego w celu wysyłki do klienta bez konieczności ręcznego wprowadzania danych do dokumentu wychodzącego, które istnieją w systemie dziedzinowym. 4. Przygotowanie systemu dziedzinowego w zakresie umożliwienia podpisania dokumentu elektronicznego podpisem kwalifikowanym oraz weryfikacji poprawności podpisu na dokumencie elektronicznym przychodzącym. 5. Przygotowanie systemu dziedzinowego w zakresie umożliwienia automatycznej obsługi dokumentów elektronicznych przychodzących i wychodzących w zakresie innych systemów merytorycznych funkcjonujących w urzędzie. 6. Utworzenie hurtowni danych zawierającej jednolitą i uporządkowaną informację dotyczącą wszystkich należności, wartości odsetek należnych dla urzędu w przypadku należności zaległych ze wszystkich systemów merytorycznych funkcjonujących w urzędzie. Hurtownia danych powinna zawierać rodzaje należności, historię wpłat dotycząca należności wraz z listą osób wpłacających należności, wartości odsetek należnych dla urzędu w przypadku należności zaległych. 7. Przygotowanie systemu dziedzinowego do współpracy z zamawianym systemem elektronicznego obiegu dokumentów (EOD) w zakresie: 1) SD musi mieć możliwość korzystania ze wspólnych danych logowania (login i hasło) z EOD dla pracowników JST opartych o usługę katalogową LDAP, 2) SD musi mieć możliwość synchronizowania baz kontrahentów w zakresie z EOD: a) dodawania kontrahentów z pełnymi danymi (m.in.: imię, nazwisko/nazwa, pesel, nip, adresy pocztowe, adresy elektroniczne i inne), b) +usuwanie kontrahentów, c) modyfikowanie danych kontrahenta, d) masowe synchronizowanie baz kontrahentów, e) łączenie kontrahentów w obu systemach jednocześnie. 3) Zakres wymienianych danych z EOD nie może być mniejszy niż (w zakresie jakim dotyczy): Nazwisko lub nazwa firmy, Imię, Drugie imię, PESEL, REGON, NIP, Adres stały ze wskazanie na TERYT, Adres korespondencyjny ze wskazaniem na TERYT, Adres skrytki ePUAP, Oznaczenie czy jest zgoda na komunikację drogą elektroniczną, Forma prawna, Typ podmiotu (osoba fizyczna, podmiot gospodarczy). 4) SD musi wymieniać dokumenty elektroniczne przychodzące z ePUAP i skierowane na ePUAP z EOD w zakresie: a) metadanych dokumentów, b) dokumentu elektronicznego w XML, c) załączników do dokumentu elektronicznego. 5) SD musi mieć możliwość podglądu wszystkich dokumentów danego kontrahenta. 8. Integracja systemu dziedzinowego w zakresie gospodarki nieruchomościami z zasobem ewidencji gruntów i budynków (z wykorzystaniem formatu plików SWDE), do generowania bazy nieruchomości, a także do celów weryfikacji w systemach dziedzinowych np. porównywania zgłoszonych powierzchni do opodatkowania a faktycznym stanem posiadania zawartym w ewidencji gruntów i budynków. 9. Integrację systemu dziedzinowego z aplikacjami zewnętrznymi, które pośredniczą w komunikacji z innymi organami administracji np. Zakładem Ubezpieczeń Społecznych (ZUS – program PŁATNIK), Ministerstwem Finansów (MF – BESTIA), oraz Głównym Urzędem Statystycznym (GUS), które agregują dane w skali całego kraju dla celów analitycznych i sprawozdawczych. 10. Integrację systemu dziedzinowego z systemami bankowymi, w zakresie generowania przelewów do banku oraz automatyzacja obsługi wyciągów bankowych, zwłaszcza w zakresie masowych płatności podatników. 11. Przygotowanie mechanizmów integracji poprzez rozbudowę funkcjonalności SD w zakresie: 1) SD musi udostępniać informacje o kontrahentach w zakresie nie mniejszym niż: Nazwa/Nazwisko, Imię, Pesel, NIP, Adres z uwzględnieniem wskazań na słownik TERYT, 2) SD musi udostępniać informacje o należnościach kontrahenta z uwzględnieniem, że kilku kontrahentów może dotyczyć jedna należność, 3) Informacje dot. należności nie mogą mieć mniejszego zakresu niż: rodzaj należności, kwota, kwota do zapłaty, kwota odsetek, VAT, kwota do zapłaty VAT, numer decyzji urzędowej, termin płatności, 4) SD musi udostępniać informacje dotyczące kont bankowych, na które należy wpłacić należność z uwzględnieniem konfiguracji modułu SD dotyczącego przyjmowania masowych płatności, 5) SD musi udostępniać informacje dotyczące wpłat dokonanych na należności. Przekazane dane muszą zawierać zakres informacyjny przynajmniej: data wpłaty, kwota, kwota odsetek, kwota vat, kontrahent wpłacający, 6) SD musi udostępniać szczegółowe informacje dla należności do zapłaty będących Wezwaniami lub Upomnieniami takie jak: data odbioru, data wydania, data zapłaty, koszt, numer, 7) SD musi udostępniać szczegółowe informacje dla należności dotyczących obszaru wydawania zezwoleń na sprzedaż alkoholu w zakresie nie mniejszym niż: data od – do dla zezwolenia, data wydania, numer zezwolenia, rok zezwolenia, typ zezwolenia (A, B, C), stan zezwolenia, adres punktu sprzedaży, 8) SD musi udostępniać szczegółowe informacje dla należności dotyczących mienia, w zakresie nie mniejszym niż: data wystawienia dokumentu, numer dokumentu, nazwa dokumentu (np. Akt notarialny, Akt własności ziemi, decyzja administracyjna, księga wieczysta i inne), dane o nieruchomości której to dotyczy (lokal, budynek, działka, obręb, jednostka ewidencyjna), dane kontrahenta wskazanego jako właściciel i część udziału którą posiada (np. 100%, 1/3, etc.), 9) SD musi udostępniać informacje dla należności dotyczącej podatku od osób prawnych i fizycznych w zakresie nie mniejszym niż: numer dokumentu, rok dokumentu, typ dokumentu (Decyzja czy Deklaracja), rodzaj podatku, typ decyzji, wskazanie nieruchomości które dotyczy (budynek, działka, obręb etc.), 10) SD musi udostępniać informacje dla należności dotyczącej opłaty za gospodarowanie odpadami w zakresie minimalnym: punkt odbioru odpadów, typ zbiórki odpadów (np. selektywna / nieselektywna), parametry deklaracji, numer deklaracji, adres punktu odbioru odpadów., 11) SD musi udostępniać informacje o mieszkańcach tj. dane kontrahenta dodatkowo uzupełnione o datę urodzenia / zgonu, płeć, adres zameldowania z terenu JST, 12) SD musi umożliwiać podanie należności z określeniem: nazwy, typu, kwoty, terminu płatności, kontrahenta, 13) CPeUM i SD muszą mieć możliwość korzystania z jednego systemu LDAP, który pozwoli na posługiwanie się jednym loginem i hasłem dla pracowników JST. Po przeprowadzonych pracach programistycznych system dziedzinowy powinien osiągnąć następujące funkcjonalności: 1. Baza informacji o interesantach urzędu, powinna być jedna i wspólna dla wszystkich modułów dziedzinowych. 2. Baza informacji o kontrahentach powinna mieć możliwość podziału na grupy lub jednostki, tak aby użytkownik z jednej jednostki nie miał dostępu do danych osobowych z drugiej jednostki. 3. System powinien mieć możliwość archiwizacji dokumentów, danych. 4. System powinien obsługiwać płatności masowe i automatyczne księgowanie wyciągów bankowych. 5. Wszystkie moduły podatkowe powinny mieć wspólne słowniki (stawek podatkowych, rodzaju i stawek ulg, obrębów ewidencyjnych itp.), oraz być zintegrowane, tak by organizacyjnie osoba merytoryczna wystawiająca np. zaświadczenie dla podatnika o zaleganiu bądź niezaleganiu w podatkach miała dostęp do grupy funkcji wydawania zaświadczeń obejmujących wszystkie moduły podatkowe. Podobnie w zakresie wydawania decyzji umarzających, zmieniających terminy płatności, rozkładających należność na raty, symulacjami i postępowaniem egzekucyjnym. System powinien dawać możliwość ustawienia wielu wartości słownikowych w jednym miejscu, np. słownik stawek, terminów, klas gruntów itp. 6. Moduły dziedzinowe powinny być zintegrowane z modułami usług dla ludności, a w szczególności, w zakresie przelewów masowych (w księgowości zobowiązań powinno być widoczne, na które należności dokonano przelewów), dokumentów elektronicznych składanych przez interesantów za pomocą platformy ePUAP i dostępnych formularzy (np. deklaracji czy informacji podatkowych). 7. Wymagana jest możliwość zapisu szablonów systemowych do wydruków z systemu dziedzinowego do pliku zewnętrznego (w celu ich dalszej modyfikacji) oraz modyfikacja szablonów wydruków w aplikacji, a także możliwość wydruków z użyciem zmodyfikowanego szablonu (z pliku). 8. Musi być możliwość pracy w środowisku sieciowym z możliwością jednoczesnego dostępu do danych wielu użytkownikom. 9. Musi istnieć mechanizm zapewniający bezpieczeństwo danych oraz mechanizmy autoryzacji przez logowanie do aplikacji (także z wykorzystaniem uwierzytelniania za pomocą usług katalogowych). 10. Dostęp (zabezpieczony hasłem i kodem dostępu) do poszczególnych modułów musi być możliwy przez wyposażenie w funkcje zarządzania użytkownikami modułów (przydzielania lub odbieranie uprawnień do poszczególnych funkcji lub grupy funkcji, a także aktywowanie lub zamykanie kont użytkowników). 11. W bazie danych musi być zapis informacji o dodaniu rekordu (data i godzina operacji, użytkownik) oraz o ostatniej modyfikacji rekordu (data i godzina operacji, użytkownik). 12. Na każdym etapie pracy użytkowników poszczególnych modułów merytorycznych musi istnieć tzw. pomoc kontekstowa informująca użytkownika o możliwych działaniach. 13. System powinien dawać możliwość wymuszania zmiany hasła, aby użytkownicy musieli zmieniać hasło w określonym odstępie czasu. System musi też umożliwiać skonfigurowanie wymuszania stosowania tzw. twardego hasła, np. wymuszając stosowanie wielkich i małych liter, cyfr itp. 14. System powinien zabezpieczać przed nieautoryzowanym dostępem do bazy danych. 15. System powinien mieć możliwość wykonywania kopii zapasowej bazy danych z poziomu systemu, bez konieczności dostępu do bazy danych na serwerze. 16. System powinien dawać możliwość skorzystania z tzw. „zdalnego pulpitu”, aby użytkownicy mogli się łączyć zdalnie z pracownikiem wsparcia systemu. 17. Zarządzanie uprawnieniami powinno umożliwiać również ograniczenie uprawnień do danej jednostki budżetowej. Przykładowo użytkownik obsługujący moduł księgowy powinien mieć uprawnienia jedynie do jednostki, którą obsługuje. 18. Powinna istnieć możliwość wysyłania przez administratora systemu komunikatów do poszczególnych użytkowników, jak również wylogowanie użytkownika z systemu. 19. Powinna być możliwość ustawienia wielu jednostek organizacyjnych, aby zwiększyć możliwość pracy kontekstowej i umożliwiać np. dodanie różnych pieczątek dla różnych jednostek, różnych numerów NIP itp. 20. System powinien dawać administratorowi możliwość zarządzania listą aktywnych modułów i funkcji. Zarządzanie powinno dawać możliwość aktywacji, dezaktywacji modułu lub funkcji. 21. System musi dawać możliwość ustawienia parametrów czasu bezczynności. Po określonym czasie nieużywania systemu użytkownik musi być wylogowany z systemu. 22. Mechanizm wspólnej bazy danych musi zabezpieczać przed powielaniem zapisów, np. blokować możliwość ręcznego wpisywania nazwy ulicy przez użytkownika i wymuszać używanie słowników. 23. System w przypadku aktywnego modułu do obsługi ewidencji ludności powinien dawać możliwość aktualizowania danych wprowadzanego kontrahenta danymi z ewidencji ludności. 24. System powinien kontrolować, aby użytkownicy wykonujący operacje na tych samych danych nie mogli tego wykonać. System musi blokować operacje użytkownika, który chce wykonać działanie na modyfikowanych danych. Blokada powinna być zdejmowana przez administratora systemu. 25. System musi dawać możliwość kontrolowania połączeń systemu z bazą danych oraz dawać możliwość sprawdzania dostępności nowych wersji systemu. 26. Powinna istnieć możliwość konfiguracji i kontroli integracji z innymi systemami. Administrator w jednym miejscu powinien mieć możliwość sprawdzenia konfiguracji z innymi systemami, a także ustawienia listy elementów podlegających integracji (kontrahenci, dokumenty itp.). 27. System powinien dawać możliwość eksportu danych do formatu XML i CSV dla ustalonych parametrów indywidualnie przez użytkownika. 28. System powinien dawać możliwość tworzenia pliku IPE-PN XML dla osób prawnych i fizycznych dotyczący danych podatkowych. 29. Powinna istnieć możliwość eksportu danych w formacie XML z modułu rejestru mieszkańców oraz modułów podatkowych. 30. System musi być bezpieczny, to znaczy musi posiadać procedury ochrony i kontroli dostępu do całej bazy danych (ochrona przed nieuprawnionym dostępem, mechanizmy kryptograficzne, wsparcie redundancji sprzętowej i programowej, ochrona integralności danych, zabezpieczenie danych przed uszkodzeniem i utratą danych), oraz poszczególnych rodzajów danych (np. dane osobowe, dane o zaległościach podatników). Dostęp do bazy musi być zabezpieczony zakodowanym hasłem i odpowiednio zdefiniowanymi parametrami połączenia aplikacji z bazą. 31. System musi umożliwiać elastyczne zarządzanie użytkownikami i uprawnieniami to znaczy: 1) aktywowanie oraz dezaktywowanie (bez usuwania) kont użytkowników, 2) możliwość podglądu aktualnie zalogowanych użytkowników, 3) przypisywanie (lub odbieranie) uprawnień dla użytkowników do poziomu jednostkowej funkcji, 4) grupowanie dowolnie wybranych funkcji w zbiory uprawnień (grupy funkcji) i przypisywanie (lub odbieranie) ich użytkownikom, 5) brak możliwości zmiany danych historycznych, 6) możliwość zmiany hasła użytkownika oraz jego resetowania, wymuszanie zmiany hasła co 30 dni zgodnie z ogólnymi wymaganiami dotyczącymi systemów informatycznych, 7) umożliwienie identyfikowania użytkownika po nr PESEL oraz nazwie użytkownika. 32. Moduły obsługujące prowadzenie rozliczeń finansowych podatników i płatników urzędu, powinny być pogrupowane według różnych rodzajów należności i jednocześnie powinny stanowić wzajemnie spójną całość, tak by użytkownik aplikacji, w zależności od nadanych mu uprawnień, mógł mieć możliwość obsługi wybranego konta zobowiązanego z dostępem do jego wszystkich zobowiązań wobec urzędu (System musi mieć możliwość dokonywania przeksięgowań np. z należności podatkowej na inną nie podatkową, automatyczne rozdysponowanie wpłaty na występujące należności). 33. System musi umożliwiać integrację z zewnętrznym systemem – modułem komunikacji dla centralnej platformy e-usług mieszkańca. Integracja ma umożliwiać wysyłanie, za pośrednictwem platformy, wiadomości i powiadomień generowanych w systemie, które skierowane są do interesantów urzędu. Moduł komunikacji umożliwiać będzie wysyłanie wiadomości minimum następującymi metodami: sms, email lub przez aplikację mobilną. Wykonawca zapewni w systemie dziedzinowym dostęp do dedykowanego WEBAPI dla modułu komunikacji, dostępnego za pośrednictwem protokołu http w formacie JSON lub XML. System w zakresie integracji w szczególności musi: 1) Umożliwiać wysyłanie wiadomości w zakresie minimalnym o: Informacja o wystawionej decyzji; Informacja o zbliżającym się terminie płatności; Informacja o zaległości; Wezwanie do złożenia deklaracji; 2) Umożliwiać, poprzez dedykowane formularze, konfigurację ustawień połączenia minimum w zakresie: a) adresu IP i/lub adresu domenowego - Zamawiający wymaga stosowania protokołu https, b) hasła użytkownika. Zamawiający nie posiada autorskich praw majątkowych do funkcjonującego w urzędzie oprogramowania, nie posiada kodów źródłowych oprogramowania, a licencja posiadanego oprogramowania nie umożliwia mu modyfikacji kodów źródłowych, zatem Zamawiający nie jest w stanie zapewnić Wykonawcę, że udostępni mu stałe, niezmienne interfejsy integracyjne umożliwiające pełną wymianę danych z nowo uruchamianymi rozwiązaniami. Wykonawca odpowiedzialny jest za dostawę w pełni funkcjonujących rozwiązań opisanych w niniejszym załączniku, w tym jeżeli jest konieczne, pozyskanie niezbędnych informacji do realizacji zamówienia, zawarcie koniecznych umów itp. Mając na uwadze powyższe, w przypadku jeżeli Wykonawcy nie mają możliwości uzyskania odpowiedniego do realizacji dostępu do oprogramowania firm trzecich, w celu zapewnienia zasady konkurencyjności postępowania, Zamawiający dopuszcza wymianę systemu dziedzinowego na jedno zintegrowane rozwiązanie (Zintegrowany System Dziedzinowy- ZSD) pod warunkiem, że: 1. Rozwiązania zastępujące dotychczas funkcjonujące u Zamawiającego systemy Wykonawca dostarcza i wdraża na swój koszt, z zachowaniem warunków licencjonowania wskazanych w niniejszym dokumencie. 2. Wykonawca przeprowadzi migrację danych w zakresie wskazanym przez Zamawiającego na swój koszt, migracja musi objąć pełny zakres danych bieżących i archiwalnych. 3. Wykonawca przeprowadzi instruktaże stanowiskowe i będzie świadczył asystę techniczną w zakresie umożliwiającym pracownikom jednostki Zamawiającego płynną obsługę systemów. 4. Wymiana systemu nie może zakłócić bieżącej pracy Zamawiającego oraz musi zapewnić ciągłość pracy wynikającą z obowiązujących terminów, przepisów prawa i stosowanych procedur. W szczególności dotyczy to wymiaru podatków i opłat, sprawozdawczości budżetowej oraz obsługi kadrowo-płacowej. 5. Wszelkie uzgodnienia i konsultacje w zakresie transmisji danych powinny być dokonane w siedzibie Zamawiającego na podstawie zatwierdzonego harmonogramu. 6. Proces migracji musi objąć pełne dane zawarte we wcześniej użytkowanym systemie. 7. Nowe rozwiązania muszą realizować wszystkie wymienione wyżej funkcje systemu oraz zapewnić zgodność z wymaganiami dla systemu dziedzinowego określonymi poniżej. 8. Wykonawca przeprowadzi demonstrację zaoferowanego Systemu Dziedzinowego w zakresie prawidłowego działania oraz posiadanych funkcjonalności opisanych poniżej w Wymogach funkcjonalnych dla zintegrowanego systemu dziedzinowego ofertowanego jako rozwiązanie równoważne do modernizacji istniejącego systemu dziedzinowego (załącznik nr 10 SIWZ) Wymogi funkcjonalne dla zintegrowanego systemu dziedzinowego ofertowanego jako rozwiązanie równoważne do modernizacji istniejącego systemu dziedzinowego. Zintegrowany System Dziedzinowy (ZSD) musi objąć cały obszar funkcjonalny Zamawiającego z wyłączeniem zadań realizowanych przez systemy krajowe (np. CEIDG, Bestia@). Zintegrowany System Dziedzinowy musi być przygotowany do pełnej obsługi dokumentu elektronicznego tj. musi umożliwiać przyjęcie danych poprzez import danych z dokumentów elektronicznych sporządzonych przy pomocy formularzy elektronicznych udostępnionych przez Zamawiającego, bez konieczność ręcznego wprowadzania danych z dokumentu elektronicznego. Zintegrowany System Dziedzinowy musi umożliwić przygotowanie dokumentu elektronicznego w celu wysyłki go do klienta oraz wydrukowanie kopii dokumentu w wersji papierowej zgodnie z wymaganiami Instrukcji Kancelaryjnej. Wszystkie funkcjonalności muszą umożliwiać pełną realizację czynności niezbędnych do obsługi danego obszaru. Funkcjonalności muszą być ergonomiczne, wykonane zgodnie z najlepszymi praktykami projektowania systemów informatycznych. Zaleca się, aby ZSD miał budowę modułową oraz zapewniał pełną wymianę informacji pomiędzy poszczególnymi modułami systemu pozwalając na kompletne i kompleksowe prowadzenie wszystkich zadań administracji samorządowej, jednak Zamawiający nie narzuca sposobu podziału ZSD na moduły, czy ich liczby. Z punktu widzenia Zamawiającego istotnym jest spełnienie przez ZSD wskazanych niżej funkcjonalności. W stosunku do Zintegrowanego Systemu Dziedzinowego na potrzeby opisu funkcjonalnego stosuje się zamiennie nazwy: „moduł” – mając na uwadze część funkcjonalną Zintegrowanego Systemu Dziedzinowego, „obszar” – mając na uwadze część funkcjonalną Zintegrowanego Systemu Dziedzinowego, a także „System”, „Aplikacja” – mając na uwadze ZSD. W przypadku, jeżeli Zamawiający nie uwzględnił obszaru funkcjonalnego systemu ZSD w poniższym opisie, a jest on niezbędny z tytułu funkcjonowania całego rozwiązania oraz e-usług publicznych musi on zostać uwzględniony przez Wykonawcę w cenie oferty, a wszystkie dostarczone elementy ZSD muszą spełniać wymogi licencyjne określone w niniejszym dokumencie. W poniżej wskazanych wymaganiach Zamawiający posługuje się terminami „musi”, „powinien”, „możliwość” w stosunku do ZSD określając wymaganą funkcjonalność systemu. Obszar obsługi podatków i opłat lokalnych. 1. Możliwość porównania informacji o działkach w ewidencji podatkowej z ewidencją z modułu do obsługi mienia Gminy. Porównanie musi być możliwe z określeniem parametrów: stanu na dzień, typu podmiotu, nazwy, minimalnej wartości różnicy, która ma być przechwytywana do raportu. 2. Raport z różnic powinien obejmować co najmniej: nazwę, adres, NIP, dane dot. powierzchni wg ewidencji podatkowej, dane dot. powierzchni wg EGiB, wielkość różnicy. 3. Umożliwienie konfiguracji słowników: 1) stawek podatku od nieruchomości, 2) rodzajów i stawek ulg, 3) obrębów ewidencyjnych, 4) przeliczników, 5) typów zasobów, 6) znacznika gospodarstwa, 7) ceny żyta, 8) ceny drzewa – podatek leśny. 4. Umożliwienie prowadzenia postępowań i spraw, m.in. postępowań egzekucyjnych, zgodnie ze zdefiniowanymi słownikami, m.in.: 1) rodzaju czynności, 2) rodzaju dokumentu, 3) rodzaju podmiotu, 4) rodzaju przedmiotu, 5) rodzaju sprawy, 6) rodzaju statusu sprawy, 7) kosztów egzekucyjnych. 5. Dostęp do rejestru spraw z możliwością wyszukiwania co najmniej po: rodzaju, statusie, numerze sprawy, opisie. 6. Możliwość zakładania i przeglądu spraw, w tym dodawania: 1) czynności zgodnie ze zdefiniowanym słownikiem, 2) przedmiotów zgodnie ze zdefiniowanym słownikiem, 3) dokumentów do sprawy. 7. Możliwość wykonania i modyfikowania szablonów treści wydruków: 1) postanowienia o wszczęciu postępowania egzekucyjnego, 2) postanowienia o zawieszeniu postępowania egzekucyjnego, 3) postanowienia o umorzeniu postępowania egzekucyjnego, 4) wniosku o ujawnienie danych do Urzędu Skarbowego, 5) wniosku o ujawnienie danych do ZUS, 6) zawiadomienia o zajęciu prawa majątkowego, 7) zawiadomienia o uchyleniu zajęcia. 8. Możliwość wydrukowania metryki sprawy. 9. Możliwość dodania pliku pisma do sprawy. 10. Możliwość wydruku kopert adresowych dla wybranych spraw. 11. Możliwość wystawiania, wyszukiwania i wydruku decyzji: o rozłożeniu na raty, o odroczeniu terminu płatności, o umorzeniu zaległości (również z odsetkami), o umorzeniu odsetek, dla należności z tytułu podatku od osób fizycznych, prawnych, od środków transportu oraz opłat, w tym z tytułu gospodarowania mieniem Gminy, opłat za psa wprowadzanych do systemu. 12. Umożliwienie wyliczania opłaty prolongacyjnej wg ustalonej stawki. 13. Możliwość modyfikacji niezatwierdzonych decyzji. 14. Możliwość zatwierdzenia wystawionych decyzji z aktualizacją stanu należności w windykacji. 15. Możliwość wysłania decyzji w formie dokumentu elektronicznego na ePUAP w przypadku korzystania z modułu do obsługi dokumentów elektronicznych. 16. Możliwość edycji szablonu treści decyzji, wydruku na podstawie szablonu i przekazania do archiwum wydruków. 17. Możliwość prowadzenia rejestru wystawionych decyzji oraz wykonania wydruku zestawienia decyzji. 18. Możliwość anulowania wystawionej decyzji lub rat. 19. Przesyłanie danych o należnościach objętych decyzją do modułów księgowości zobowiązań, kasowego i finansowo-księgowego. 20. Wyszukiwanie kartotek podatników wg. różnych kryteriów, m. in. wg numeru kartoteki, nazwiska podatnika, adresu gospodarstwa, numeru działki, numeru decyzji. 21. Definiowanie podatników - osoby fizyczne, małżeństwa, podmioty grupowe, w tym możliwość określania, którzy z nich mają być adresatami korespondencji np. decyzji ze wskazaniem na kontrahentów. 22. Możliwość definiowanie pełnomocników i spadkobierców dla kartotek. 23. Możliwość określanie adresów gospodarstw dla kartotek. 24. Możliwość przeglądania, wprowadzania, usuwania, modyfikacji przedmiotów opodatkowania (np. gruntów, nieruchomości) objętych podatkiem rolnym, podatkiem leśnym i podatkiem od nieruchomości dla kartotek podatkowych. 25. Funkcjonalność określania informacji o działkach związanych z danym przedmiotem opodatkowania na podstawie Ewidencji Gruntów i Budynków prowadzonej w module do obsługi gospodarowania mieniem. System powinien umożliwić wskazanie i powiązanie przedmiotu opodatkowania bezpośrednio z działką z modułu Ewidencji Gruntów i Budynków. 26. Moduł umożliwia rejestrowanie ulg i zwolnień podmiotowych (dotyczących kartoteki) i przedmiotowych (dotyczących poszczególnych przedmiotów opodatkowania). 27. Moduł umożliwia rejestrowanie zmian – nabycia, zbycia przedmiotów opodatkowania w trakcie roku. 28. Funkcjonalność masowe zbycia składników na kartotece poprzez wyświetlenie tych składników, umożliwienie zaznaczenia elementów do zbycia, ustawienia daty i wykonanie zbycia. 29. Możliwość zmiany znacznika gospodarstwa w celu dostosowania typu gospodarstwa do ilości posiadanych gruntów, 30. Przegląd pogrupowanych powierzchni przedmiotów opodatkowania w ramach gruntów, lasów oraz nieruchomości wg stanu na wybrany dzień, stanu na dany rok podatkowy lub wg całego znanego stanu ewidencyjnego (również z przyszłych okresów). 31. Przegląd wysokości naliczonego podatku, wysokości uwzględnionych poszczególnych ulg i zwolnień z podatku, wystawionych decyzjach dotyczących wymiaru i zmiany wymiaru podatku, wysokościach rat podatku oraz terminach ich płatności. 32. Możliwość zapisywania dodatkowych informacji o kartotece w notatniku. 33. Moduł powinien dawać możliwość porównywania stanu ewidencyjnego kartoteki podatkowej ze stanem posiadania podatnika(-ów) w Ewidencji Gruntów i Budynków prowadzonej w module do obsługi mienia. 34. Moduł powinien umożliwiać podgląd naliczonych opłat dla wybranej kartoteki w module księgowości zobowiązań. 35. Moduł musi umożliwiać naliczanie podatku rolnego, podatku leśnego i podatku od nieruchomości na podstawie stanu posiadania podatnika oraz naliczanie zmian podatku w trakcie roku na skutek zmiany stanu posiadania dla pojedynczej kartoteki oraz dla zakresu kartotek. 36. Powinna istnieć możliwość anulowania naliczonego podatku dla pojedynczej kartoteki oraz dla zakresu kartotek. 37. Moduł powinien umożliwiać wystawianie decyzjami w sprawie wymiaru i zmiany wymiaru podatku rolnego, podatku leśnego, podatku od nieruchomości, w tym pobieranego w formie łącznego zobowiązania pieniężnego za rok bieżący dla pojedynczej kartoteki oraz dla zakresu kartotek. 38. Moduł powinien również umożliwiać zarządzanie wystawionymi decyzjami w zakresie: 1) obsługi szablonów treści decyzji, 2) wyszukiwania decyzji wg różnych kryteriów, 3) ustawienia parametrów wydruku decyzji (drukowanie kodu kreskowego, drukowanie potwierdzenia odbioru, drukowanie kwitów do kasy, drukowanie bankowego polecenia przelewu itd.), 4) modyfikacji wybranych elementów treści decyzji przed jej wydrukowaniem, 5) wydruku decyzji, w tym w sposób masowy (lub z podziałem np. na sołectwa), 6) rejestracja daty wysłania decyzji, daty odbioru decyzji, 7) tworzenia dokumentu elektronicznego z wybraną decyzją przygotowanego do wysyłki na ePUAP poprzez moduł do obsługo dokumentów elektronicznych. 39. Moduł musi umożliwiać anulowanie decyzji w sprawie wymiaru i zmiany wymiaru podatku, w tym także decyzji wysłanych do podatnika. 40. Moduł musi obsługiwać wykonywanie i zarządzanie przypisami należności z tytułu podatku wysyłanymi do modułu księgowości zobowiązań, w tym: 1) przekazywanie przypisu podatku dla pojedynczej kartoteki oraz dla zakresu kartotek, 2) zawieszanie przypisów w przypadku braku żyjących podatników, pełnomocników, spadkobierców, 3) anulowanie przypisu. 41. Przypisy, o których mowa trafiają bezpośrednio do modułu księgowania zobowiązań w trybie online. 42. Moduł musi umożliwiać obsługę decyzji dotyczących zobowiązań pieniężnych - decyzji ustalającej wysokość podatku za lata ubiegłe: 1) wyszukiwanie decyzji wg wielu kryteriów, 2) dodawanie i edycja decyzji ustalającej wysokość podatku za lata ubiegłe, 3) przeglądanie decyzji, 4) zatwierdzanie decyzji, 5) anulowanie i wygaszanie decyzji, 6) drukowanie decyzji. 43. Możliwość wystawienia decyzji o odroczeniu terminu płatności, rozłożeniu zapłaty należności na raty, umorzeniu zaległości, umorzeniu odsetek. 44. Moduł musi umożliwiać drukowanie kopert i zwrotnych potwierdzeń odbioru adresowanych do wszystkich podatników, do podatników z Gminy lub do podatników spoza Gminy. 45. Moduł powinien umożliwiać zarządzanie sposobem przenoszenie przypisów należności do modułu księgowości zobowiązań, w tym: 1) przenoszenia wszystkich przypisów, niezależnie od wielkości, 2) przenoszenie przypisów nie mniejszych niż kwota minimalnego przypisu określona w księgowości, zsumowane w ramach pojedynczej decyzji danego rodzaju i typu, decyzji danego rodzaju i niezależne od typu, wszystkich decyzji, dla których jest wykonywany dany przypis. 46. Moduł musi umożliwiać zmianę numeru kartoteki (pojedynczo oraz dla zakresu kartotek). 47. Ustawienia modułu powinny również umożliwiać m. in. ustawienie maksymalnej kwoty podatku płatnej jednorazowo, sposobu numerowania decyzji, prezentacji powierzchni na kartotece, sposobu prezentacji składników objętych w dzierżawę. 48. Ustawienia powinny również umożliwiać konfigurację cen zboża, obrębów, znaków dokumentów i typów decyzji. 49. W celach statystycznych i porównawczych moduł powinien umożliwiać wykonanie wydruków/zestawień: 1) listy kartotek, listy kartotek z błędnym znacznikiem gospodarstwa, 2) zestawienia wydanych decyzji, wykaz niewydrukowanych decyzji, 3) zestawienia ulg w nieruchomościach, 4) rejestru wymiarowego nieruchomości, 5) zestawienia gospodarstw wg wielkości, 6) karty gospodarstwa, 7) rejestru wymiarowego, 8) wydruku z wybranymi informacjami podatkowymi o kartotekach z zadanego przez użytkownika zakresu, 9) zestawienia podatników, 10) zestawienia nieruchomości, 11) zestawienia zmiany numerów kartotek, 12) zestawienia działek z przedmiotami opodatkowania. 50. Moduł musi mieć możliwość wyszukiwania i podglądu kartotek podatników. 51. Możliwość przeglądu listy deklaracji na kartotece. 52. Możliwość przeglądu listy działek (przeglądanie informacji o elementach ewidencji podatkowej wybranej kartoteki) 53. Możliwość przeglądu opłat naliczonych w ramach kartoteki 54. Możliwość dodawania notatek do kartoteki 55. Moduł musi mieć możliwość wydruku informacji o działce. 56. Moduł powinien umożliwiać dodawanie i zarządzanie deklaracjami podatkowymi, w tym: 1) wyszukiwanie deklaracji, 2) dodawanie, edycję i usuwanie deklaracji, 3) naliczanie podatku w ramach deklaracji (pojedynczo i dla zakresu kartotek podatkowych). 57. Moduł musi umożliwiać przegląd i porównanie przedmiotów opodatkowania (dla podatku od nieruchomości, rolnego i leśnego). 58. Moduł powinien dawać możliwość dodawania, edycji i usuwania składników opodatkowania dla podatku rolnego, leśnego i od nieruchomości. 59. Moduł powinien dawać możliwość określenia ulgi w podatku. 60. Moduł musi dawać możliwość porównania stanu ewidencyjnego ze stanem w module do obsługi mienia Gminy. 61. Moduł powinien umożliwiać prowadzenie ewidencji działek, w tym: 1) adresów gospodarstw, 2) danych o nieruchomościach (także rolnych i leśnych), 3) przeglądania danych o działkach z EGiB. 62. Moduł musi dawać możliwość porównania powierzchni przedmiotów opodatkowania z powierzchnią działek. 63. Powinna istnieć możliwość anulowania naliczenia podatku dla wybranych kartotek i wybranych deklaracji. 64. Moduł powinien umożliwiać wystawianie i zarządzanie decyzjami w sprawie wymiaru podatku i obsługiwać: 1) wystawianie decyzji, 2) wyszukiwanie i edycja (w tym usuwanie) decyzji, 3) wydruk decyzji w sprawie określenia wysokości zobowiązania podatkowego, 4) zatwierdzanie decyzji w sprawie określenia wysokości zobowiązania podatkowego, 5) anulowanie decyzji w sprawie określenia wysokości zobowiązania podatkowego. 65. Moduł powinien również umożliwiać wystawienie decyzji o odroczeniu terminu płatności, rozłożeniu zapłaty należności na raty, umorzeniu zaległości, umorzeniu odsetek. 66. Moduł powinien umożliwiać wykonanie zestawień: 1) nieruchomości, 2) powierzchni lasów, 3) powierzchni gruntów, 4) deklaracji, 5) ulg i zwolnień w podatku od nieruchomości, 6) kontrahentów objętych podatkiem. 67. Moduł powinien umożliwiać przynajmniej wykonanie wydruków: 1) zawiadomienia o błędnych deklaracjach, 2) zawiadomienia o stawkach podatkowych, 3) wezwania do złożenia deklaracji. 68. Moduł powinien mieć możliwość sporządzenia wydruku rejestru decyzji. 69. Moduł powinien umożliwiać modyfikację treści wydruków: 1) wezwania do złożenia deklaracji, 2) zawiadomienia o stawkach podatkowych, 3) zawiadomienia o błędnych deklaracjach. 70. Powinna istnieć możliwość ustawienia parametrów pracy modułu, co najmniej: 1) typów pism, 2) typów decyzji, 3) znaku decyzji, 4) roku podatkowego, 5) minimalnej stawki podatku płaconego jednorazowo. 71. Moduł powinien dawać możliwość naliczania przypisów w celu ich obsługi w module księgowości zobowiązań dla pojedynczej kartoteki lub dla grupy kartotek. Moduł przekazuje naliczenia przypisów w trybie online do modułu księgowania zobowiązań. 72. Możliwość wystawienia decyzji o odroczeniu terminu płatności, rozłożeniu zapłaty należności na raty, umorzeniu zaległości, umorzeniu odsetek. 73. Moduł musi dawać możliwość podglądu naliczonych opłat w ramach kartotek w module do obsługi księgowości zobowiązań. 74. Moduł musi umożliwiać zdefiniowane dowolnej nazwy opłaty, która będzie wprowadzana do systemu. 75. Parametry modułu muszą pozwalać na ustalenie czy naliczenie wprowadzanej opłaty będzie wykonywane w zaokrągleniu do złotówki, do grosza, czy do 10 groszy. 76. Moduł musi dać możliwość zdefiniowania, czy opłata będzie rozliczana w module do obsługi księgowości zobowiązań, czy też będzie pobierana w kasie. Definiowanie integracji do modułów odbywa się w trybie online. 77. Powinna istnieć możliwość zdefiniowania rodzaju odsetek dla opłaty. 78. Moduł powinien umożliwiać wprowadzanie kartotek opłat oraz zarządzanie nimi: 1) dawać możliwość ustalenia stanu rozliczenia naliczonej opłaty, 2) dawać możliwość wyszukiwania kartotek według wybranych kryteriów: numeru opłaty, roku opłaty, opisu opłaty, danych opłacającego, daty wprowadzenia, stanu rozliczenia, statusu opłaty. 79. Podczas zakładania nowych kartotek system musi dawać możliwość wyboru zobowiązanych oraz zdefiniowania rat i terminów płatności rat. 80. Moduł powinien umożliwiać anulowanie naliczonych opłat. 81. Moduł powinien dawać możliwość zdefiniowania jaki rodzaj zawiadomienia ma być wystawiany w przypadku stwierdzenia zaległości (Upomnienie, Wezwanie). 82. Moduł powinien dawać użytkownikowi możliwość podejrzenia kartoteki w module do księgowości zobowiązań w trybie online. 83. Powinna istnieć możliwość wystawienia decyzji dla opłaty: o odroczeniu terminu płatności, rozłożeniu zapłaty należności na raty, umorzeniu zaległości, umorzeniu odsetek. 84. Moduł powinien mieć możliwość zdefiniowania, czy opłata ma mieć przypisany VAT i możliwość określenia domyślnego podatku VAT w celu prawidłowego rozliczenia w księgowości zobowiązań. 85. Moduł powinien mieć symulacje podatkowe od osób fizycznych i os. prawnych w podatku od nieruchomości , podatku leśnym, podatku rolnym i podatku od środków transportu 86. Moduł powinien mieć możliwość wystawienia zaświadczeń o pomocy de-minimis. Obszar budżetowo-sprawozdawczy. 1. System musi umożliwiać tworzenie budżetu zarówno w układzie klasycznym, jak i zadaniowym. 2. System musi umożliwiać wprowadzanie planu na rok budżetowy do pełnego klucza budżetowego, przy wymaganych elementach klucza budżetowego: 1) dysponent środków budżetowych, 2) klasyfikacja budżetowa wraz z możliwością wprowadzenia pozycji paragrafu, 3) źródła finansowania, 3. System musi zapewniać użytkownikom, w zależności od nadanych uprawnień, możliwość korzystania ze słowników budżetowych: 1) słownik klasyfikacji budżetowej z informacjami o działach, rozdziałach, paragrafach i pozycjach paragrafów definiowanych przez użytkowników, 2) słownik klasyfikacji strukturalnej zawierający klasyfikację strukturalną, 4. System musi pozwalać na wprowadzenie do każdego zadania parametrów. 1) nazwa, 2) cel realizacji (wraz z określeniem priorytetu), 3) jednostka nadzorująca zadanie, 4) jednostka realizująca zadanie, 5) dziedzina, 6) kategoria, 7) opis dodatkowy. 5. System musi zapewniać możliwość wprowadzenia przez użytkowników merytorycznych kwot planu budżetu oraz zmian budżetowych tylko w ramach otwartych zmian. 6. System musi zapewniać dwupoziomowe zatwierdzanie projektu budżetu. 7. System musi umożliwiać, wybranym użytkownikom, anulowanie zatwierdzenia projektu całości budżetu oraz anulowania zatwierdzenia wybranej zmiany w ramach wybranego dysponenta środków budżetowych. 8. System musi posiadać możliwość podłączenia wariantów planów jednostek organizacyjnych w ramach tylko ukończonych bądź wszystkich utworzonych projektów jednostek. 9. System musi umożliwiać wprowadzanie uzasadnień opisowych do wprowadzanych zmian budżetowych. 10. System musi umożliwiać udostępnienie on-line planu jednostkom organizacyjnym. 11. System musi zawierać funkcjonalność umożliwiającą udostępnienie elementów wprowadzania projektu budżetu oraz zmian budżetowych przez jednostki organizacyjne. 12. System musi umożliwiać agregowanie sprawozdań jednostkowych i sporządzania sprawozdań zbiorczych. 13. System musi umożliwiać kontrolę planu jednostki w zakresie zgodności z uchwalonym planem. 14. System musi umożliwiać generowanie planów, zmian i sprawozdań budżetowych do plików XML(możliwość eksportu do systemu BESTI@). 15. System musi umożliwiać przegląd, w dowolnym momencie, aktualnego stanu budżetu dla wybranego dysponenta środków budżetowych bądź dla wszystkich jednostek dla pełnego klucza budżetowego. 16. System musi umożliwiać utworzenie symulacji budżetu na podstawie zatwierdzonego plan budżetu z poprzedniego roku, 17. System musi umożliwiać tworzenia symulacji przy wybraniu parametrów związanych z kluczem budżetowym. 18. System musi umożliwiać raportowanie w zakresie planu oraz wykonania na podstawie sprawozdań budżetowych do arkusza kalkulacyjnego (w formacie xls), przy czym wymagana jest: 1) możliwość definiowania dynamicznych zestawień przez użytkowników modułu w oparciu o zarejestrowane dane, 2) możliwość generowania raportów w dowolnym momencie czasu, które wcześniej zostaną zdefiniowane przez użytkowników, zarówno z zarejestrowanych danych aktualnych, jak i historycznych, 3) możliwość blokady definicji raportu dla użytkowników. 19. System musi być zintegrowany z modułem księgowym w zakresie dekretacji planu budżetu i zmian. 20. System musi umożliwiać budowanie wzorców dekretacji planu budżetu, zmian i sprawozdań budżetowych w oparciu o konta księgowe. 21. System musi być zintegrowany z rejestrem umów i umożliwiać sprawdzenie na danym poziomie planowania budżetu bieżącego stanu zaangażowania w oparciu o wybrany klucz budżetowy. 22. System musi umożliwiać rejestrację sprawozdań budżetowych Rb wymaganych przepisami prawa oraz możliwość wydruku na wzorach ustawowych. 23. System musi umożliwiać rejestrację sprawozdań Rb-27S i Rb-28S z pełną szczegółowością klasyfikacji budżetowej, zadania budżetowego, źródła finansowania. 24. System musi posiadać obsługę sprawozdań wymaganych przepisami prawa, w zakresie: 1) dwupoziomowe zatwierdzanie, 2) tworzenie korekt sprawozdań, 3) tworzenie sprawozdań łącznych, 4) tworzenie sprawozdań zbiorczych w zakresie wybranej jednostki organizacyjnej, 5) wydruk sprawozdań na wydrukach zgodnych z przepisami prawa, 6) wydruk sprawozdań do arkusza kalkulacyjnego, 7) eksport do programu Besti@, 8) podłączenie załączników do wybranego sprawozdania, 9) generowanie sprawozdań Rb27S, Rb28S, RbN, RbZ, Rb-50, Rb-27ZZ, Rb-28NW, Rb-ZN, Rb-UZ, Rb-UN, RB-PDP, RB-ST i RB-SP1 z ksiąg rachunkowych i eksport do sprawozdawczości budżetowej. 25. System musi posiadać integrację z programem Besti@ w zakresie importu sprawozdań w postaci plików xml. 26. System musi zapewniać możliwość przeglądu oraz porównania planu budżetu oraz wykonania w dowolnym momencie. 27. System musi umożliwiać tworzenie sprawozdań łącznych na dowolnym poziomie wybranym przez użytkownika. 28. System musi być zintegrowany z modułem księgowym w zakresie dekretacji sprawozdań Rb27S i Rb28S. 29. System musi umożliwiać budowanie wzorców dekretacji planu budżetu, zmian i sprawozdań budżetowych w oparciu o konta księgowe. 30. System musi posiadać obsługę sprawozdań finansowych (rachunek zysków i strat, bilans jednostki budżetowej oraz zestawienie zmian w funduszu jednostki), w tym możliwość automatycznego ich generowania. 31. System musi posiadać możliwość wprowadzania uzasadnień do wykonania planu w pełnej szczegółowości do klucza budżetowego. 32. System musi umożliwiać czynności w zakresie deklaracji VAT, w szczególności: 1) generowanie zbiorczej deklaracji VAT dla całej Gminy (centralizacja VAT), 2) import faktur sprzedażowych i zakupowych z jednostek podległych w formacie JPK, z podziałem na jednostki i wydziały. 3) obsługę korekt deklaracji zbiorczej, 4) tworzenie zbiorczej korekty deklaracji VAT-7, 5) wprowadzenie powodu złożenia korekty, których lista będzie dołączana do deklaracji zbiorczej, 6) archiwizowanie deklaracji w formacie PDF. 33. System musi umożliwiać tworzenie wariantów prognozy finansowej. Obszar finansowo-księgowy. 1. System musi umożliwiać rejestrację faktur zakupu w zakresie danych opisowych, pozycji faktury wraz z wyborem z listy stawki podatku VAT. 2. System musi umożliwiać ukończenie faktury, anulowanie faktury, dekretację faktury według automatów dekretujących zdefiniowanych przez użytkownika. 3. System musi umożliwiać rejestrowanie realizacji do wybranej umowy na podstawie utworzonej faktury zakupu wraz z przypisaniem szczegółowości klucza budżetowego. 4. System musi posiadać możliwość wygenerowania korekty faktury oraz podpięcie jej do kwot realizacji do wybranej umowy. 5. System musi umożliwiać utworzenie noty korygującej dla wybranego dokumentu. 6. System musi posiadać ewidencję faktur zakupów. 7. System musi posiadać możliwość rejestracji dowolnych dokumentów zobowiązań będących podstawą wydatków. 8. System musi umożliwiać wprowadzanie listy dokumentów zobowiązań wg określonych kryteriów: 1) rodzaj dokumentu, 2) typ operacji księgowej, 3) jednostka organizacyjna, 4) data wystawienia, 5) data otrzymania, 6) data terminu płatności, 7) stały opis dokumentu. 9. System musi umożliwiać generowanie korekt dokumentów zobowiązań. 10. System musi umożliwiać powiązanie dowolnego zobowiązania do wybranej umowy. 11. System musi posiadać możliwość generowania paczki przelewów oraz pliku elektronicznego do systemu bankowego. 12. System musi posiadać możliwość dekretacji dokumentu zobowiązań według zdefiniowanych automatów księgowych utworzonych przez użytkownika. 13. System musi umożliwiać dekretację pojedynczych dokumentów zobowiązań bądź dekretację zbiorczą wybranych dokumentów przez użytkownika. 14. System musi umożliwiać wygenerowanie raportów: 1) zestawienie dokumentów na kontrahenta, 2) zestawienie z ewidencji dokumentów, 3) sumaryczne zestawienie na rodzaj dokumentu oraz typu operacji księgowej, 4) zestawienie kontrahentów. 15. System musi umożliwiać wyszukiwanie dowolnych dokumentów po wybranych parametrach z dokumentów (numer, data wystawienia, data zapłaty, rodzaj dokumentu, typ operacji księgowej, jednostka organizacyjna). 16. System musi zapewniać możliwość wprowadzenia jednolitego planu kont z podziałem na jednostki organizacyjne gminy. 17. System musi zapewniać możliwość grupowania kont. 18. System musi zapewniać możliwość definiowania różnych typów dekretów. 19. System musi pozwalać na rozbudowę analityki według potrzeb za pomocą wykorzystania zdefiniowanych słowników pomocniczych: 1) klasyfikacji budżetowej – dział, rozdział, paragraf oraz opcjonalnie pozycja paragrafu, 2) listy zadań budżetowych, 3) listy jednostek organizacyjnych, 4) listy źródeł finansowania, 5) listy kontrahentów, 6) słownika zadań inwestycyjnych, 7) słownika klasyfikacji wydatków strukturalnych, 20. System musi zapewniać możliwość definiowania wielu poziomów kont księgowych. 21. System musi umożliwiać zdefiniowanie rodzajów dokumentów/należności, które pozwalają charakteryzować poszczególne operacje wykonywane w systemie i agregować je w jednorodne grupy. 22. System musi zapewniać możliwość zdefiniowania słownika typów operacji księgowej. 23. System musi zapewniać możliwość tworzenia automatów dekretujących i wzorców księgowań dla zdefiniowanych operacji księgowych. 24. System powinien posiadać kontrole sprawdzające: 1) uzupełnienia wymagalnych elementów dekretu, 2) czy kwoty dekretu są różne od zera, 3) czy księgowanie odbywa się na najniższym poziomie analityki, 4) czy data dowodu odpowiada okresowi, który nie został zamknięty ani zablokowany. 25. System powinien pozwalać na nadawanie numerów dla dowodów w ewidencji księgowej zgodnie ze zdefiniowanym numeratorem. 26. System powinien zapewniać przyporządkowanie kolejnych numerów dla dowodów w sposób chronologiczny. 27. System musi umożliwić wykonywanie operacji dla dowodów zaksięgowanych: 1) generowanie dowodów storna, 2) przeglądanie stornowanych dowodów, 3) przeglądanie dowodów storna, 4) wydruk księgowania, 5) przegląd dokumentów źródłowych, 6) kopiowanie dowodu. 28. System musi mieć funkcjonalność służącą do otwierania nowego roku bilansowego z: 1) automatycznego definiowania okresów sprawozdawczych, 2) kopiowania dostępów do okresów z poprzedniego roku bilansowego. 29. System powinien umożliwiać wyodrębnienie dowolnej ilości okresów dla przeksięgowań technicznych wykonywanych pod koniec roku w zależności od potrzeb użytkownika. 30. System powinien umożliwiać wprowadzanie dowodów księgowych do dowolnej ilości otwartych okresów jednocześnie. 31. System powinien umożliwiać blokowanie oraz zamykanie okresów uniemożliwiające wprowadzanie dowodów księgowych. 32. System powinien umożliwiać przeglądanie i drukowanie dowodów księgowych, w szczególności: 1) wyszukanie dowodów wprowadzonych w ramach danego okresu sprawozdawczego, 2) wyszukanie wszystkich dowodów wprowadzonych przez danego użytkownika, 3) wyszukanie dowodów księgowych według: daty operacji, daty dowodu, nazwy, numeru, symbolu rejestru, rodzaju dowodu, symbolu operacji księgowej, 4) wyszukanie dekretów wg kwot, dat, kont, klucza dekretu uzupełniającego. 33. System musi zapewniać możliwość generowania sprawozdań budżetowych Rb-28S, Rb-27S, Rb-27, Rb-28, Rb-23, Rb-27ZZ, Rb-30S, Rb-31, Rb-32, Rb-33, Rb-34, Rb-50D, Rb-50W, Rb-N, Rb-Z, Rb-UN, Rb-UZ, Rb-WS, Rb-ZN, Rb-28NWS oraz zestawień. 34. System musi zapewniać możliwość tworzenia sprawozdań finansowych (bilans, rachunek zysków i strat, zestawienie zmian w funduszu). 35. System powinien dawać możliwość wygenerowania potwierdzenia sald z kontrahentami, w szczególności: 1) stworzenia zbioru kont biorących udział w wyliczaniu salda rozliczeń z kontrahentem, 2) generowania potwierdzenia salda na wskazany dzień dla jednego lub wielu kontrahentów z funkcją pozwalająca na przeglądanie, drukowanie, nanoszenie uwag, modyfikowanie opisu, 3) prowadzenia ewidencji wygenerowanych potwierdzeń sald, 4) możliwości zdefiniowania odpowiednich filtrów pozwalających na wyszukanie kontrahentów zgodnie z warunkami zawartymi w filtrze. 36. System musi zapewniać możliwość archiwizacji ksiąg rachunkowych. 37. System musi umożliwiać generowanie raportów i zestawień, w szczególności: 1) wydruk kart kontowych kont analitycznych, 2) wydruk Dziennika, 3) wydruk zestawień dowodów księgowych, 4) wydruk obrotów i sald, 5) wydruk obrotów i sald dla dekretów uzupełniających, 6) wydruk raportów obrotów i sald wygenerowanego na podstawie zaksięgowanych dowodów prezentujący skutki dekretacji. 38. System musi umożliwiać definiowanie dowolnej ilości rejestrów sprzedaży i nabycia. 39. System musi umożliwiać przydzielanie i modyfikowanie dostępów do rejestrów sprzedaży. 40. System musi pozwalać na oznaczanie rodzaju dokumentu: 1) Symbolem, 2) pełną nazwą dokumentu, 3) zdefiniowaniem numeracji (miesięczna, roczna, kwartalna, własna), 4) rejestrem VAT do którego należy, 5) domyślnego szablonu wydruku faktury, 6) domyślnego typu płatności (ilość dni czy termin). 41. System musi umożliwiać definiowanie oddzielnych numeratorów dla poszczególnych rejestrów sprzedaży. 42. System musi umożliwiać obsługę centralizacji VAT w zakresie fakturowania z możliwością wskazania na fakturze jednostki organizacyjnej. 43. System musi umożliwiać umieszczanie faktur VAT w rejestrach zgodnie z datą wystawienia; system powinien zapewniać nadanie kolejnych numerów faktur narastająco zgodnie z datą wystawienia. 44. System musi umożliwiać wprowadzenia daty VAT na fakturze określającej moment powstania obowiązku podatkowego. 45. System musi umożliwiać wygenerowanie wydruku rejestru pozwalającego na zestawienie wystawionych faktur umieszczonych w różnych rejestrach według daty wystawienia oraz według daty powstania obowiązku podatkowego w danym miesiącu. 46. System musi umożliwiać wygenerowanie zbiorczego zestawienia dla rejestrów VAT: 1) podsumowanie wartości netto, VAT i brutto dla poszczególnych rejestrów, 2) łączne podsumowanie wartości netto, VAT i brutto dla rejestrów danego okresu, 3) wyszczególnienie sumarycznego ujęcia pozycji sprzedaży podlegającej opodatkowaniu w rozbiciu na poszczególne stawki podatku VAT oraz sprzedaży zwolnionej z podatku VAT dla faktur ujętych we wszystkich rejestrach danego okresu, 4) wyszczególnienie sumarycznego zestawienia pozycji faktur według przyporządkowanej jednostki księgowej oraz rodzaju dowodu. 47. System musi umożliwiać wygenerowanie wydruku danych rejestrów z możliwością ograniczenia: 1) rodzaju dokumentu, 2) symbolu rejestru, 3) miesiąca, w ramach którego utworzony był rejestr, 4) wybranej grupy rejestrów, 5) daty VAT, 6) daty wystawienia w okresie. 48. System musi umożliwiać wprowadzanie zarówno faktur jedno- jak i wielopozycyjnych. 49. System musi umożliwiać wprowadzanie faktur sprzedaży zarówno w kwotach netto jak i brutto. 50. System musi umożliwiać wprowadzenie danych ewidencyjnych i opisowych zawartych na fakturze: 1) kontrahenta zarejestrowanego w ewidencji kontrahentów, 2) nazwy, ceny jednostkowej, stawki VAT, jednostki miary, 3) podsumowania pozycji faktury, 4) terminu płatności dla faktury wpływającego na wysokość odsetek od zaległości, 5) terminu zapłaty drukowanego na fakturze, 6) rodzaju należności. 51. System musi umożliwiać wprowadzanie faktur korygujących ze szczególnym uwzględnieniem zapewnienia powiązania pomiędzy dokumentem pierwotnym a korektą oraz ewidencjonowanie wprowadzonych korekt. 52. System powinien umożliwiać hurtowe drukowanie partii utworzonych faktur. 53. System powinien umożliwiać prowadzanie ewidencji faktur wewnętrznych. 54. System musi pozwalać na przegląd wystawionych faktur oraz ich wyszukiwanie po zadeklarowanym parametrze (m.in. numerze faktury, kodzie kontrahenta, dacie wystawienia, sprzedaży, VAT). 55. System musi umożliwiać: 1) generowanie wielu duplikatów faktur, 2) wprowadzanie daty wystawienia dla każdego z duplikatów przed jego zatwierdzeniem, 3) wygenerowanie duplikatu faktury z danymi, jakie zawierała faktura pierwotna, 4) wygenerowanie i odłożenie kopii wygenerowanych faktur w formacie PDF. 56. System musi umożliwiać: 1) automatyczne pobieranie danych zarejestrowanych w ewidencji modułu dziedzinowego do generowanych faktur dla zaznaczonych grup należności, 2) hurtowe generowanie faktur dla usług o charakterze ciągłym, których ewidencje prowadzone są w modułach dziedzinowych, 3) generowanie faktur zaliczkowych na podstawie przekazanych informacji o zarejestrowaniu wpłat dla wybranej grupy należności. 57. System powinien pozwolić na tworzenie ewidencji zamówień z uwzględnieniem możliwości tworzenia faktur zaliczkowych oraz generowania faktur końcowych. 58. System musi generować Jednolity Plik Kontrolny zgodny z wymaganiami prawa. 59. W systemie musi istnieć możliwość prowadzenia rejestru umów. 60. Prowadzenie rejestru umów musi opierać się na podziale umów: 1) będące w przygotowaniu - umowy, które można edytować, 2) umowy aktualne, 3) umowy archiwalne. 61. W systemie musi istnieć możliwość prowadzenia słowników do umów, które będą daną umowę charakteryzowały: 1) słownik rodzajów umów, 2) słownik kategorii, 3) słownik typów umów. 62. System musi mieć możliwość prowadzenia rejestru aneksów do wybranych umów, które będą powiązane z umową główną za pomocą jej numeru. 63. System musi mieć możliwość wprowadzania harmonogramu finansowego do każdej umowy, wraz z możliwością zmiany w momencie podpisania aneksu oraz powiązania danej pozycji harmonogramu z wybranym aneksem. 64. System musi mieć możliwość wprowadzania i aktualizacji harmonogramu umowy ze szczegółowością do klasyfikacji budżetowej, zadania budżetowego, źródła finansowania, obiektu budżetowego oraz dysponenta środków budżetowych, wraz z określeniem rodzaju kosztu. 65. System musi mieć możliwość weryfikacji zarejestrowanych harmonogramów z danymi już zaksięgowanymi dotyczącymi zaksięgowanego planu budżetu, zaksięgowanego wykonania, pozostałej kwoty do wykorzystania, zaksięgowanego zaangażowania oraz kosztów. 66. System musi umożliwiać śledzenie na bieżąco zaangażowanych środków ze wszystkich umów na danym kluczu budżetowym oraz weryfikację z danymi realizacji umów. 67. System musi umożliwiać szybkie zweryfikowanie z jakimi fakturami (dokumentami) powiązana jest dana umowa, w tym również z fakturami (dokumentami) korygującymi lub dokumentami wewnętrznymi. 68. System musi umożliwiać rejestrowanie informacji o umowach podpisanych w wyniku prowadzonego postępowania o zamówienie publiczne. Wymagane informacje: 1) numer postępowania, 2) data rozpoczęcia postępowania, 3) data zakończenia postępowania. 69. System musi umożliwiać rejestrację i ewidencję składników majątku trwałego, w szczególności: 1) nazwy środka, 2) opisu środka, 3) daty przychodu, 4) wartości środka, 5) umorzenia, 6) jednostki organizacyjnej, 7) rodzaju GUS, 8) rodzaju WNP, 9) roku produkcji, 10) numeru fabrycznego, 11) KST, 12) stawki amortyzacji. 70. System musi umożliwiać przyporządkowanie oraz zmianę osoby odpowiedzialnej za składnik majątku z określeniem w jakim okresie dana osoba jest przypisana jako osoba odpowiedzialna. 71. System musi umożliwiać przyporządkowanie oraz zmianę adresu składnika majątku z określeniem w jakim okresie dany adres jest przypisany do składnika majątku. 72. System musi umożliwiać budowanie przez użytkownika słowników cech wraz z możliwością przypisywania cech wybranym składnikom majątku. 73. System musi umożliwiać wykonanie operacji hurtowego przychodu składników majątku o takiej samej charakterystyce. 74. System musi umożliwiać generowanie dokumentów przychodu, likwidacji, sprzedaży, zmiany miejsca użytkowania, odpowiedzialności, zmian wartości. 75. System musi umożliwiać ewidencję zmian: 1) zwiększenia wartości, 2) zmniejszenia wartości, 3) zmiany stawki amortyzacji, 4) przeceny, 5) korekty umorzeń, 6) zatrzymanie naliczania umorzeń. 76. System musi umożliwiać ewidencję przemieszczeń składników majątku. 77. System musi umożliwiać hurtowe wykonywanie operacji na składnikach majątku, w szczególności: 1) przemieszczenia, 2) rozchody, 3) przyporządkowanie lub zmiana adresu, 4) przyporządkowanie lub zmiana osoby odpowiedzialnej, 5) przyporządkowanie lub zmiana osoby użytkującej, 6) nadanie cechy. 78. System musi umożliwiać naliczanie umorzeń i amortyzacji na wybrany okres (miesiąc, rok). 79. System musi umożliwiać pełną obsługę inwentaryzacji z wykorzystaniem czytników kodów kreskowych. 80. System musi umożliwiać przeglądanie i wydruk ilościowo-wartościowych zestawień majątku w zakresie: 1) zestawienie stanu majątku, 2) zestawienie obrotów za wskazany okres, 3) zestawienie przychodów za wskazany okres, 4) zestawienie rozchodów za wskazany okres, 5) zestawienie majątku według adresów, 6) zestawienie majątku według osób użytkujących, 7) zestawienie majątku według osób odpowiedzialnych, 8) zestawienie majątku według jednostek organizacyjnych. 81. System musi umożliwiać równoległe prowadzenie wielu ewidencji i wielu ksiąg inwentarzowych. 82. System musi umożliwiać prowadzenie odrębnych ewidencji majątku trwałego dla jednostek podległych które ewidencjonowane są przez jednostkę główną, ewidencje jednostek muszą być rozdzielone poprzez ich wybór na etapie logowania 83. System musi umożliwiać prowadzenie słowników związanych z ewidencją środków: 1) rodzaje środków – nazwa rodzaju (np. środki trwałe, pozostałe środki trwałe, wartości niematerialne i prawne), 2) rodzaje GUS wraz z przyporządkowaniem stawki, 3) rodzaje PKD na potrzeby sprawozdania SG-01, 4) rodzaje WNiP wraz z przyporządkowaniem stawki. 84. System musi umożliwiać prowadzenie słowników związanych z ewidencją księgową środków w zakresie: 1) rodzaje przychodów, 2) rodzaje rozchodów, 3) rodzaje operacji, 4) konta księgowe, 5) wzorce dekretacji. Obszar gospodarowania odpadami komunalnymi. 1. Moduł musi umożliwiać ewidencję, tworzenie, edycja kartotek płatników opłaty za gospodarowanie odpadami komunalnymi, w tym: 1) określanie głównych podmiotów dla kartoteki oraz współzobowiązanych jako bezpośrednie wskazania na kontrahentów z modułu interesariusze, 2) możliwość przeglądu szczegółowych danych kontrahenta ze składu kartoteki. 2. Możliwość podglądu stanu kartoteki w księgowości analitycznej z modułu do obsługi księgowości zobowiązań. 3. Możliwość założenia ewidencji na podstawie danych podatkowych osób fizycznych i prawnych – współpraca z podatkami od os. fizycznych oraz od osób prawnych. 4. Możliwość importu ewidencji z pliku XML w określonym schemacie. 5. Ewidencja punktów adresowych, z których odbierane są odpady komunalne, w tym: 1) tworzenie, edycja i usuwanie punktów adresowych, 2) określanie szczegółowych danych punktów adresowych (powierzchnie, liczba mieszkańców dla punktów zamieszkałych, dowolne adnotacje dla punktu), 3) wydruk zestawienia punktów adresowych wg zadanych kryteriów. 6. Możliwość rejestracji i ewidencji złożonych deklaracji o wysokości opłaty za gospodarowanie odpadami: 1) rejestrowanie wszystkich niezbędnych danych do naliczenia opłaty oraz celów statystycznych, 2) możliwość wprowadzania pierwszych deklaracji oraz ich późniejszych zmian, 3) wspomaganie weryfikacji deklaracji wraz z możliwością korygowania danych i wprowadzania nowych, ujawnionych i zweryfikowanych danych, wraz z zapamiętaniem statusu weryfikacji deklaracji, 4) przyjęcie deklaracji złożonej w formie elektronicznej z wykorzystaniem platformy ePUAP. 7. Naliczanie opłat za gospodarowanie odpadami komunalnymi: 1) naliczanie pojedynczych kartotek lub naliczanie masowe według zadanych kryteriów, 2) naliczanie opłat z uwzględnieniem miesięcznego rozliczania ich w księgowości zobowiązań, 3) możliwość anulowania naliczeń dla wybranego roku naliczenia lub wszystkich lub pojedyncze anulowanie zrobionego przypisu w ciągu roku. 4) szczegółowa parametryzacja naliczeń opłat (m. in. zaokrąglanie kwot, stosowanie częstotliwości wywozu pojemników dla punktów niezamieszkałych). 8. Możliwość obsługi wezwań do złożenia deklaracji lub złożenia wyjaśnień: 1) określanie parametrów wystawianego wezwania, 2) możliwość anulowania wystawionego wezwania, 3) wydruk wezwania według określonego przez użytkownika szablonu. 9. Obsługa decyzji: 1) możliwość wystawiania decyzji o wysokości opłaty za gospodarowanie odpadami komunalnymi, 2) określanie szczegółowych parametrów wystawianych decyzji (indywidualne uzasadnienia, parametry opłat, dowolny szablon decyzji), 3) wydruk decyzji z możliwością edycji treści, 4) możliwość wystawienia decyzji o odroczeniu terminu płatności, rozłożeniu zapłaty należności na raty, umorzeniu zaległości, umorzeniu odsetek. 10. Możliwość wykonania wydruków i zestawień: 1) wydruk zestawienia płatników i opłat według zadanych parametrów, 2) wydruk zestawienia deklaracji według określonych przez użytkownika parametrów, 3) wydruk i eksport do pliku arkusza kalkulacyjnego zestawienia szczegółowego punktów adresowych z możliwością zdefiniowania dowolnych parametrów zestawienia oraz określenia zawartości informacyjnej na końcowym zestawieniu. 11. Możliwość zapamiętania schematu wyszukiwania zestawienia z punktów adresowych. 12. Moduł musi obsługiwać wiele taryf opłat za gospodarowanie odpadami komunalnymi według wielu kryteriów, w tym m. in. wg: liczby zamieszkałych osób, ryczałtowo od gospodarstw (w tym domów letniskowych), rzeczywistego zużycia wg odczytów licznika, powierzchni nieruchomości, liczby pojemników. 13. Moduł powinien umożliwiać różnicowanie opłat m. in. z tytułu liczby dzieci zamieszkujących gospodarstwo domowe, długotrwałego przebywania poza miejscem zamieszkania, segregowania odpadów, liczby dzieci w wieku poniżej określonego wieku z uwzględnieniem wskaźnika procentowego lub kwotowego oraz z uwzględnieniem przedziału czasowego obowiązywania danej ulgi. 14. Obsługa rejestru umów z firmami odpowiedzialnymi za wywóz odpadów. 15. Obsługa naliczania i windykowania kar za niewłaściwe realizowanie umów. 16. Możliwość prowadzenia rejestru działalności regulowanej: 1) dodawanie, edycja i wykreślanie wpisów do/z rejestru, 2) wydruk rejestru działalności regulowanej, 3) wydruk zaświadczenia o wpisie do rejestru działalności regulowanej w zakresie odbierania odpadów komunalnych od właścicieli nieruchomości, 4) wydruk zaświadczenia o zmianie wpisu do rejestru działalności regulowanej w zakresie odbierania odpadów komunalnych od właścicieli nieruchomości. 17. Obsługa sprawozdań z zakresu gospodarki odpadami: 1) rejestrowanie, import z pliku arkusza kalkulacyjnego (zgodnego z obsługiwaną strukturą) sprawozdań od przedsiębiorców odbierających odpady, 2) tworzenie sprawozdań z zakresu gospodarowania odpadami komunalnymi, 3) wydruk sprawozdania według wybranego szablonu. 18. W celu usprawnienia pracy użytkownika moduł musi dysponować słownikami: sektorów, źródeł pochodzenia danych ewidencyjnych, cykli rozliczeniowych oraz terminów płatności, adresatów sprawozdań z zakresu gospodarki odpadami, składowisk odpadów, różnicowania stawek opłat za gospodarowanie odpadami komunalnymi. 19. Moduł musi umożliwiać prowadzenie katalogu odpadów: 1) słownika nieczystości ciekłych, 2) słownika rodzajów odpadów, 3) słownika zagospodarowania odpadów. 20. Moduł musi umożliwiać obsługę tras i harmonogramów wywozu odpadów komunalnych wraz z wydrukiem harmonogramu odbiorów odpadów i nieczystości. 21. Moduł musi posiadać możliwość zmiany stawek z trakcie roku wraz z aktualizacją wysokości opłat za gospodarowanie odpadami komunalnymi. 22. Moduł musi umożliwia wykonanie wydruku zawiadomienia o zmianie stawki i wysokości rat. 23. Powinien być możliwy import danych ewidencyjnych z pliku XML w określonej strukturze na potrzeby weryfikacji danych deklaracji w przypadku braku aktywnego połączenia systemu z modułem rejestru mieszkańców. 24. Moduł powinien wspierać obsługę kodów kreskowych dla punktów adresowych: 1) umożliwiać wydruk etykiet kodów kreskowych według własnych zdefiniowanych szablonów, 2) umożliwiać przegląd historii wydruków etykiet kodów kreskowych dla kartoteki (rejestr wydruków), 3) umożliwiać weryfikację odczytów kodów kreskowych dla kartoteki z poziomu ewidencji, 4) umożliwiać konfigurację i import odczytów kodów kreskowych z pliku, 5) wspierać zarządzanie odczytami kodów kreskowych z możliwością usunięcia importu, 6) umożliwiać wykonanie zbiorczego i szczegółowego zestawienia statystycznego odczytów kodów kreskowych według zadanych parametrów. 25. Wyszukiwanie umów czynszowych i zużycia wody wg podanych parametrów. 26. Rejestrowanie, edycja i przeglądanie danych umowy, w szczególności strony umowy, a także numeru umowy, daty zawarcia, daty obowiązywania, punktu poboru mediów, okres i sposób rozliczania opłat, okres i sposób fakturowania. Rejestrowanie notatki dla umowy. 27. Korygowanie umowy, wprowadzanie aneksu do umowy. 28. W przypadku umowy dot. rozliczenia opłat za wodę powinna znaleźć się możliwość dodania informacji o liczniku. 29. Wydruk umowy z systemu z możliwością edycji szablonu treści umowy. 30. Wyszukiwanie nieruchomości wg podanych parametrów. 31. Rejestrowanie, edycja i przeglądanie danych nieruchomości. 32. Możliwość rejestrowania obiektów składających się z wielu budynków, lokali. Rejestrowanie notatki dla nieruchomości. 33. Wprowadzanie informacji technicznych odnośnie nieruchomości, np. awarie, remonty, naprawy. 34. Możliwość zdefiniowania adresu nieruchomości, podziału rejon/sektor, możliwość wprowadzenia informacji o licznikach. 35. Możliwość ewidencjonowania nieruchomości, które rozliczane są w różnych grupach taryfowych. 36. Możliwość ewidencjonowania prezentacji, wyszukiwania, dodawania, edycji i usuwania pozostałych obiektów, takich jak budynek, garaż, miejsce parkingowe, piętro w budynku. 37. Możliwość dodawania, prezentacji, wyszukiwania, edycji i usuwania lokali w ramach nieruchomości. 38. Rejestrowanie i edycja danych licznika z wysokim poziomem szczegółowości, w szczególności: numer, numer ewidencyjny, średnica, typ (samodzielny, główny, podlicznik) licznika, zakres pomiarowy, data montażu, data legalizacji, stan początkowy, numer plomby, położenie, właściciel, przepustowość, stan (czynny, zdjęty). 39. Prowadzenie pełnej historii liczników. Możliwość zapamiętywania informacji o wszelkich zdarzeniach, miejscach instalacji. 40. Możliwość wyświetlenia pełnej historii rozliczeń w danym punkcie rozliczeniowym, uwzględniającej zmiany płatników, liczników, ewidencjonowane zdarzenia (np. awarie liczników). 41. Wyszukiwanie, przeglądanie, rejestrowanie i edycję odczytów liczników. 42. Prowadzenie ewidencji plomb – przegląd i aktualizacja ilościowych stanów. Wprowadzanie, zdejmowanie ze stanu. 43. Monitorowanie terminów legalizacyjnych liczników. 44. Naliczanie opłat za poszczególne usługi na podstawie obowiązujących stawek i wartości odczytów/ilości usług bądź ustalonych wartości ryczałtów. 45. Rozliczanie według dowolnie definiowanych cenników opłat. 46. Wyliczanie szacunkowego zużycia na podstawie średniego zużycia za miniony okres do wystawienia faktury w przypadku niemożności dokonania odczytu. 47. Możliwość określania i wykorzystywania różnych cykli rozliczeniowych (miesięczne, dwumiesięczne, kwartalne, półroczne, roczne). 48. Stosowanie zniżek (ulg) i zwyżek procentowych i kwotowych. 49. Wystawianie faktur w powiązaniu z modułem faktury. 50. Wydruk kodu kreskowego na fakturze. 51. Możliwość podziału numeracji faktur do szczegółowości inkasenta. 52. Automatyczne, proporcjonalne dzielenie zużycia w okresach, gdy podczas okresu podlegającego fakturowaniu wystąpiła zmiana cen lub stawek VAT. 53. Możliwość wystawienia decyzji o udzieleniu ulg (rozłożenie na raty, umorzenie, zmiana terminu płatności). 54. Możliwość szerokiej konfiguracji działania modułu, przynajmniej w zakresie: 1) określania rodzajów umów, rodzajów liczników, rodzajów usług, sektorów, cech nieruchomości, 2) określenia stawek usług, zniżek/zwyżek, grup taryfowych, ryczałtów, terminów płatności, sposobów fakturowania, cykli rozliczeniowych, 3) określenia tras, rejonów odczytów. 55. Automatyczne monitorowanie danych w module, np. na koniec miesiąca stan wodomierzy z odczytami bez wystawionej faktury, monitorowanie terminów legalizacyjnych wodomierzy. 56. Możliwość wykonania wydruku zawiadomienia o wysokości opłat. 57. Moduł powinien wspierać wykonywanie zestawień i statystyk, w tym: 1) raport ze sprzedaży danego medium, np. wody, 2) raport z zużycia danego medium - w zależności od wybranych parametrów, 3) raport ze średniego zużycia danego medium - w zależności od wybranych parametrów, 4) zestawienie umów, zestawienie liczników. 58. Eksport danych niezbędnych do wykonania prac w terenie, tj. przekazywanie danych do urządzeń mobilnych. 59. Import danych z urządzenia mobilnego (odczyty, wystawione faktury, przyjęte wpłaty). Weryfikacja przy imporcie i raportowanie niezgodności. Obszar prowadzenia ewidencji środków trwałych. 1. Moduł musi umożliwiać rejestrację i ewidencję składników majątku trwałego, w szczególności: 1) nazwy środka, 2) opisu środka, 3) daty przychodu, 4) wartości środka, 5) umorzenia, 6) jednostki organizacyjnej, 7) rodzaju GUS, 8) rodzaju WNP, 9) roku produkcji, 10) numeru fabrycznego. 2. Moduł musi umożliwiać przyporządkowanie oraz zmianę osoby użytkującej składnik majątku z określeniem w jakim okresie dana osoba jest przypisana jako osoba użytkująca. 3. Moduł musi umożliwiać przyporządkowanie oraz zmianę osoby odpowiedzialnej za składnik majątku z określeniem w jakim okresie dana osoba jest przypisana jako osoba odpowiedzialna. 4. Moduł musi umożliwiać przyporządkowanie oraz zmianę adresu składnika majątku z określeniem w jakim okresie dany adres jest przypisany do składnika majątku. 5. Moduł musi umożliwiać budowanie przez użytkownika słowników cech wraz z możliwością przypisywania cech wybranym składnikom majątku. 6. Moduł musi umożliwiać wykonanie operacji hurtowego przychodu składników majątku o takiej samej charakterystyce. 7. Moduł musi umożliwiać generowanie dokumentów OT, PT, LT. 8. Moduł musi umożliwiać ewidencję zmian: 1) zwiększenia wartości, 2) zmniejszenia wartości, 3) zmiany stawki amortyzacji, 4) przeceny, 5) korekty umorzeń, 6) zatrzymanie naliczania umorzeń. 9. Moduł musi umożliwiać ewidencję przemieszczeń składników majątku. 10. Moduł musi umożliwiać hurtowe wykonywanie operacji na składnikach majątku, w szczególności: 1) przemieszczenia, 2) rozchody, 3) przyporządkowanie lub zmiana adresu, 4) przyporządkowanie lub zmiana osoby odpowiedzialnej, 5) przyporządkowanie lub zmiana osoby użytkującej, 6) nadanie cechy. 11. Moduł musi umożliwiać naliczanie umorzeń i amortyzacji na wybrany okres (miesiąc, rok). 12. Moduł musi umożliwiać pełną obsługę inwentaryzacji z wykorzystaniem czytników kodów kreskowych. 13. Moduł musi umożliwiać przeglądanie i wydruk ilościowo-wartościowych zestawień majątku w zakresie: 1) zestawienie stanu majątku, 2) zestawienie obrotów za wskazany okres, 3) zestawienie przychodów za wskazany okres, 4) zestawienie rozchodów za wskazany okres, 5) zestawienie majątku według adresów, 6) zestawienie majątku według osób użytkujących, 7) zestawienie majątku według osób odpowiedzialnych, 8) zestawienie majątku według jednostek organizacyjnych. 14. Moduł musi umożliwiać równoległe prowadzenie wielu ewidencji i wielu ksiąg inwentarzowych. 15. Moduł musi umożliwiać prowadzenie słowników związanych z ewidencją środków: 1) rodzaje środków – nazwa rodzaju (np. środki trwałe, pozostałe środki trwałe, wartości niematerialne i prawne), 2) rodzaje GUS wraz z przyporządkowaniem stawki, 3) rodzaje WNiP wraz z przyporządkowaniem stawki. 16. Moduł musi umożliwiać prowadzenie słowników związanych z ewidencją księgową środków w zakresie: 1) rodzaje przychodów, 2) rodzaje rozchodów, 3) rodzaje operacji, 4) konta księgowe, 5) wzorce dekretacji. Obszar kasy i fakturowania. 1. Moduł musi umożliwiać definiowanie dowolnej ilości rejestrów sprzedaży. 2. Moduł musi umożliwiać przydzielanie i modyfikowanie dostępów do rejestrów sprzedaży. 3. Moduł musi pozwalać na oznaczanie danego rejestru: 1) miesiącem i rokiem, w ramach którego powinien obowiązywać rejestr, 2) symbolem unikalnym w ramach danego miesiąca, 3) elastycznie definiowanym numeratorem, na podstawie którego nadawane są numery faktur umieszczonych w danym rejestrze, 4) polem opisowym, które może zawierać wskazanie typu transakcji rejestrowanych w ramach danego rejestru. 4. Moduł musi umożliwiać definiowanie oddzielnych numeratorów dla poszczególnych rejestrów sprzedaży. 5. Moduł musi umożliwiać obsługę centralizacji VAT w zakresie fakturowania z możliwością wskazania na fakturze jednostki organizacyjnej. 6. Moduł musi umożliwiać umieszczanie faktur VAT w rejestrach zgodnie z datą wystawienia; system powinien zapewniać nadanie kolejnych numerów faktur narastająco zgodnie z datą wystawienia. 7. Moduł musi umożliwiać wprowadzenia daty VAT na fakturze określającej moment powstania obowiązku podatkowego. 8. Moduł musi umożliwiać wygenerowanie wydruku rejestru pozwalającego na zestawienie wystawionych faktur umieszczonych w różnych rejestrach według daty wystawienia oraz według daty powstania obowiązku podatkowego w danym miesiącu. 9. Moduł musi umożliwiać wygenerowanie zbiorczego zestawienia dla rejestrów VAT: 1) podsumowanie wartości netto, VAT i brutto dla poszczególnych rejestrów, 2) łączne podsumowanie wartości netto, VAT i brutto dla rejestrów danego okresu, 3) wyszczególnienie sumarycznego ujęcia pozycji sprzedaży podlegającej opodatkowaniu w rozbiciu na poszczególne stawki podatku VAT oraz sprzedaży zwolnionej z podatku VAT dla faktur ujętych we wszystkich rejestrach danego okresu, 4) wyszczególnienie sumarycznego zestawienia pozycji faktur według przyporządkowanej jednostki księgowej oraz rodzaju dowodu. 10. Moduł musi umożliwiać wygenerowanie wydruku danych rejestrów z możliwością ograniczenia: 1) rodzaju dokumentu, 2) symbolu rejestru, 3) miesiąca, w ramach którego utworzony był rejestr, 4) wybranej grupy rejestrów, 5) daty VAT, 6) daty wystawienia w okresie. 11. Moduł musi umożliwiać wprowadzanie zarówno faktur jedno- jak i wielopozycyjnych. 12. Moduł musi umożliwić odtwierdzenie faktury już zatwierdzonej oraz jej edycję bez konieczności tworzenia korekty. 13. Moduł musi umożliwiać wprowadzanie faktur sprzedaży zarówno w kwotach netto jak i brutto. 14. Moduł musi umożliwiać wprowadzenie danych ewidencyjnych i opisowych zawartych na fakturze: 1) kontrahenta zarejestrowanego w ewidencji kontrahentów, 2) nazwy, ceny jednostkowej, stawki VAT, jednostki miary, PKWiU dla pozycji z faktury z dostępnej w odpowiednim słowniku listy, 3) podsumowania pozycji faktury, 4) terminu płatności dla faktury wpływającego na wysokość odsetek od zaległości, 5) rat stanowiących sumę kwot wynikających z pozycji faktury, 6) terminu zapłaty drukowanego na fakturze, 7) rodzaju należności. 15. Moduł musi umożliwiać wprowadzanie faktur korygujących ze szczególnym uwzględnieniem zapewnienia powiązania pomiędzy dokumentem pierwotnym a korektą oraz ewidencjonowanie wprowadzonych korekt. 16. Moduł powinien umożliwiać hurtowe drukowanie partii utworzonych faktur. 17. Moduł powinien umożliwiać prowadzanie ewidencji faktur wewnętrznych. 18. Moduł musi pozwalać na przegląd wystawionych faktur oraz ich wyszukiwanie po zadeklarowanym parametrze (m.in. numerze faktury, kodzie kontrahenta, dacie wystawienia, sprzedaży, VAT). 19. Moduł musi zapewniać możliwość tworzenia elektronicznej kopii faktury. 20. Moduł musi umożliwiać: 1) generowanie wielu duplikatów faktur, 2) wprowadzanie daty wystawienia dla każdego z duplikatów przed jego zatwierdzeniem, 3) wygenerowanie duplikatu faktury z danymi, jakie zawierała faktura pierwotna, 4) wygenerowanie i odłożenie kopii wygenerowanych faktur w formacie PDF wraz z elektroniczną kopią faktury. 21. Moduł musi umożliwiać: 1) automatyczne pobieranie danych zarejestrowanych w ewidencji modułu dziedzinowego do generowanych faktur dla zaznaczonych grup należności, 2) hurtowe generowanie faktur dla usług o charakterze ciągłym, których ewidencje prowadzone są w modułach dziedzinowych, 3) generowanie faktur zaliczkowych na podstawie przekazanych informacji o zarejestrowaniu wpłat dla wybranej grupy należności. 22. Moduł powinien pozwolić na tworzenie ewidencji zamówień z uwzględnieniem możliwości tworzenia faktur zaliczkowych oraz generowania faktur końcowych dla danego zamówienia. 23. Moduł musi generować Jednolity Plik Kontrolny zgodny z wymaganiami prawa. 24. Moduł powinien zapewniać obsługę wielu kas oznaczonych unikalnym numerem z przyporządkowaną walutą oraz jednostką, w ramach której ewidencjonowane są operacje rejestrowane w danej kasie. 25. Moduł powinien zapewniać możliwość zdefiniowania grupy użytkowników mających dostęp do danej kasy. 26. Moduł powinien umożliwiać definiowanie raportu kasowego (dziennego lub kilkudniowego). 27. Moduł powinien umożliwiać wprowadzanie dokumentów zapłat gotówkowych oraz bezgotówkowych. 28. Moduł powinien umożliwiać nadanie indywidualnych numerów zgodnie ze zdefiniowanym numeratorem dla wpłat i wypłat kasowych. 29. Moduł powinien umożliwić określenie na dokumencie zapłaty daty, od której mają być naliczanie odsetki od zaległości. 30. Moduł powinien zapewniać możliwość wykonania symulacji rozdysponowania środków wynikających z wpłaty z uwzględnieniem: 1) symulacji zapłat odsetek od zaległości z możliwością wyboru lub zmiany stopy odsetek od zaległości. Analiza sposobu naliczania odsetek powinna być dostępna dla użytkownika z poziomu aplikacji z możliwością wydruku. 2) przeglądania tytułów wykonawczych wystawionych na płacone raty, 3) przeglądania upomnień wystawionych na płacone raty, 4) przypisania kosztów upomnienia z poziomu formularza symulacji zapłat odsetek od zaległości, 5) wyświetlenia oznaczenie należności dowolnym znacznikiem określającym cechy szczególne należności. 31. Moduł powinien umożliwić rejestrowanie różnych dokumentów kasowych dołączanych do różnych raportów kasowych za pomocą jednego formularza. 32. Moduł powinien zliczać kwoty operacji kasowych rejestrowanych przez jednego użytkownika systemu (kasjera) w ramach obsługi jednego kontrahenta, niezależnie od tego, do którego raportu kasowego operacja była przypisana. Na tej podstawie system powinien wyliczać kwotę reszty po podaniu kwoty jaką przekazał wpłacający. 33. Moduł powinien informować o aktualnym stanie gotówki (lub sumie operacji bezgotówkowych) po wskazaniu, że dana operacja będzie przypisana do danego raportu kasowego w ramach danej kasy. 34. Moduł powinien umożliwiać automatyczne tworzenie faktur na podstawie zarejestrowanego dokumentu KP dla jednorodnych operacji objętym obowiązkiem podatkowych VAT. 35. Moduł powinien zapewniać możliwość modyfikacji otwartego raportu kasowego w zakresie daty początkowej oraz końcowej raportu. 36. Moduł powinien zapewniać możliwość wyliczania wysokości przychodu i rozchodu przed zamknięciem raportu kasowego. 37. Moduł powinien zapewniać możliwość automatycznego wyliczania stanu końcowego kasy. 38. Moduł powinien zapewniać możliwość zamknięcie raportu kasowego, które blokuje możliwość wprowadzania zmian. 39. Moduł powinien pozwalać na wydruk raportu kasowego. 40. Moduł ma posiadać funkcjonalności umożliwiające tworzenie i zapisywanie nieukończonych dokumentów zapłat ze szczególnym uwzględnieniem: 1) umieszczenia dokumentu w „poczekalni”, 2) przeglądania dokumentów umieszczonych w „poczekalni”, 3) pobierania dokumentów z „poczekalni”, 4) modyfikowania i zakańczania dokumentów pobranych z „poczekalni”. 41. Moduł ma pozwolić na wyświetlenie monitu informującego o stanie zaległości lub nadpłat kontrahenta podczas rejestrowana wpłaty. Komunikat ma być wyświetlany po wskazaniu informacji na temat osoby dokonującej wpłaty. 42. Moduł powinien umożliwiać bezpośrednie przejście z formularza służącego do wprowadzania zapłat do konta kontrahenta pozwalającego przeanalizować stan rozrachunków kontrahenta, dla którego rejestrowana jest zapłata. 43. Moduł powinien umożliwiać podgląd osób solidarnie zobowiązanych, współwłaścicieli związanych z dokumentem. 44. Moduł powinien umożliwiać zdefiniowanie wielu wzorców dokumentów stanowiących szablon dokumentu wpłaty wykorzystywany każdorazowo podczas rejestrowania powtarzalnych rodzajów zapłat. Na podstawie wzorca dokumentu moduł powinien automatycznie uzupełnić m.in.: rodzaj należności, kwotę, informacje dotyczące kontrahenta z uwzględnieniem jego nazwy, adresu, konta. 45. Moduł powinien pozwolić na automatyczną dekretację raportów kasowych na podstawie zdefiniowanego wzorca dekretacji dla operacji rejestrowanych w ramach danej kasy. Obszar kadr i płac. 1. Moduł musi umożliwiać definiowanie struktury jednostki z uwzględnieniem podziału kadrowego. 2. Moduł musi umożliwiać ewidencjonowanie danych osobowych pracownika. 3. Moduł musi umożliwiać ewidencjonowanie umów o pracę, aneksów, angaży. 4. Moduł 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. Moduł musi umożliwiać prowadzenie ewidencji wszystkich rodzajów nieobecności w pracy. 6. Moduł musi umożliwiać rejestrację badań lekarskich, dodatkowych badań lekarskich, szkoleń, ryczałtów samochodowych i kar. 7. Moduł musi umożliwiać generowanie danych o ubezpieczeniach w ZUS. 8. Moduł musi umożliwiać wydruk umowy o pracę, zaświadczenia o zatrudnieniu, wydruk karty stażu pracy, wydruk pisma o nagrodzie jubileuszowej, wydruk informacji o warunkach zatrudnienia, świadectwa pracy i innych dokumentów. 9. Moduł musi umożliwiać wydruk zestawień i sprawozdań tj.: plan nagród jubileuszowych, zestawienia nieobecnosci pracowników, zestawienia nagród, kar, emerytów i rencistów, zestawienia funduszu socjalnego, zestawienia pracowników- aktualne umowy i nieaktualne, zestawienia dodatków stażowych, zestawienia dodatkowego wynagrodzenia rocznego, sparowazdań: Z-05 badanie popytu na pracę, informacja INF-1, informacja RMUA, sprawozdania GUS Z-03, Z-06. 10. Moduł musi umożliwiać dowolne wyszukanie i zestawienie danych zgromadzonych w zapisach bazy danych w formie wydruku. 11. Moduł 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ę: 1) podstawowe informacje (nazwisko, imię, stan cywilny, obywatelstwo, miejsce i datę urodzenia, NIP, pesel, nr dowodu osobistego, urząd skarbowy); 2) adresy pobytu stałego, zameldowania i do korespondencji; 3) informacje o członkach rodziny, kontach bankowych, odbytych szkoleniach, kwalifikacjach, szkoleniach, odznaczeniach, przynależności do organizacji i znajomości języków; 4) historia poprzedniego zatrudnienia. 12. Moduł musi pozwalać na definiowanie informacji o NIP, regonie, kontach bankowych, ustawiania kalendarza. 13. Moduł musi zawierać wszystkie informacje dotyczące kolejnych umów o pracę i aneksów do umowy oraz informację o składnikach wynagrodzenia z uwzględnieniem czasookresów, za który dany składnik przynależy. 14. Moduł musi pozwalać na zdefiniowanie kalendarza dla danego pracownika. Tworzenie nowego miesiąca dla kalendarza musi odbywać się na podstawie zdefiniowanych w słowniku. Na podstawie kalendarzy oraz słownika kodów nieobecności musi być tworzony szczegółowy wykaz czasu pracy dla pracownika. Kalendarze muszą mieć postać graficzną. 15. Moduł musi umożliwiać ewidencjonowanie bieżącego i zaległego urlopu wypoczynkowy oraz ilość urlopu wypoczynkowego na żądanie. 16. Moduł musi umożliwiać generowanie dokumentów ZUS w formacie kompatybilnym z programem PŁATNIK. Dostępne muszą być następujące formularze: 1) ZUA - zgłoszenie do ubezpieczeń / zgłoszenie zmiany danych osoby ubezpieczonej; 2) ZUS ZZA - zgłoszenie do ubezpieczenia zdrowotnego / zgłoszenie zmiany danych; 3) ZUS ZIUA - zgłoszenie zmiany danych identyfikacyjnych osoby ubezpieczonej; 4) 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; 5) ZUS ZWUA - wyrejestrowanie z ubezpieczeń; 6) ZUS RCA – imienny raport o należnych składkach i wypłaconych świadczeniach; 7) ZUS RZA - imienny raport miesięczny o należnych składkach na ubezpiecznie zdrowotne; 8) ZUS RSA - imienny raport miesięczny o wypłaconych świadczeniach i przerwach w opłacaniu składek; 9) ZUS DRA – deklaracja rozliczeniowa. 17. Moduł musi umożliwiać automatyczne przenoszenie na powyższe formularze danych płatnika składek i osoby ubezpieczanej, tak aby maksymalnie uprościć wprowadzanie danych. 18. Moduł musi posiadać gotowe składniki płacowe podzielone na grupy tematyczne: składniki wynagrodzenia, składniki inne, socjalne, potrącenia i inne. 19. Moduł musi posiadać standardowe słowniki list płacowych. 20. Moduł musi posiadać możliwość obsługi dowolnego Modułu wynagrodzeń oraz możliwość jego modyfikacji indywidualnie przez przeszkolonego administratora Modułu lub użytkownika Modułu. 21. Moduł musi posiadać możliwość tworzenia wielu rodzajów list płac w dowolnych okresach rozliczeniowych. 22. Moduł musi posiadać możliwość wyszukiwania pracowników według wielu kryteriów. 23. Moduł musi posiadać możliwość uwzględniania różnych sposobów wynagradzania takich jak: umowa o pracę, umowa o dzieło, umowa zlecenia, funkcje publiczne, wypłaty komisji, ryczałtów, diet. 24. Moduł musi posiadać możliwość tworzenia wielu rodzajów list płac takich jak: lista podstawowa, listy dodatkowe, lista wyrównująca, lista korygująca, planowana trzynastka, lista godzinowa (lista godzin ponadwymiarowych), lista dodatku wiejskiego, lista dodatkowego wynagrodzenia rocznego (możliwość eksportu danych z zestawienia dodatkowego wynagrodzenia rocznego do listy płac). 25. Moduł musi posiadać możliwość wprowadzania składników płacowych dla wybranych pracowników np. diety, nagrody, dodatki. 26. Moduł musi posiadać możliwość obsługi dodatkowych wypłat między innymi takich jak: wypłaty diet, ryczałtów, wynagrodzeń za posiedzenia komisji. 27. Moduł musi posiadać możliwość konfiguracji parametrów płacowych określających sposób wyliczania wynagrodzenia z uwzględnieniem regulaminu wynagradzania danej jednostki. 28. Moduł musi posiadać możliwość zdefiniowania podstaw do wyliczenia wynagrodzeń za czas nieobecności pracownika (chorobowe, macierzyńskie itp.). 29. Moduł musi posiadać możliwość zdefiniowania podstaw do wyliczenia godzin nadliczbowych oraz „trzynastki”. 30. Moduł musi posiadać zestaw parametrów potrzebnych do wyliczeń (parametry składek ZUS, progi podatkowe itp.) uzupełnianych w trakcie aktualizacji. 31. Moduł musi umożliwiać konfigurację pod względem praw dostępu użytkownikom Modułu. Administrator Modułu musi mieć możliwość określenia dokładnie i jednoznacznie zakresu danych oraz czynności, do których jest upoważniony dany użytkownik. 32. Moduł musi umożliwiać prowadzenie ewidencji danych osobowych pracowników oraz innych osób, dla których prowadzimy wypłaty (radni, umowy cywilnoprawne, inkasenci itp.) 33. Moduł 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. 34. Moduł musi umożliwiać prowadzenie archiwum pracowników. 35. Moduł musi umożliwiać automatyczne naliczanie płac. 36. Moduł musi zawierać eksportu danych listy płac do części finansowej. 37. Moduł musi umożliwiać eksport danych do programu płatności elektronicznych. 38. Moduł musi umożliwiać tworzenie Deklaracji PIT: 11/R, 40/8C, 4/4R/8AR, 2,12,IFT. 39. Moduł misi umożliwiać wysłanie Deklaracji PIT do Urzędu Skarbowego. Obszar indywidualnych kartotek. 1. Moduł musi umożliwiać rejestrację w odrębnych kartotekach osób fizycznych i podmiotów gospodarczych(osoby pozostałe). 2. Moduł musi pozwalać na wyszukiwanie osób/organizacji po niżej wymienionych kryteriach: 1) dla osobach fizycznych: nazwisko, imię, nr PESEL/NIP, danych adresowych (miejscowość, ulica, numer budynku/lokalu), data urodzenia, imię ojca, matki, typ i numer dokumentu, 2) dla organizacji pozostałych: nazwa/REGON/ NIP, danych adresowych (miejscowość, ulica, numer budynku/lokalu), 3) dla obydwu grup: po identyfikatorze, będącym indywidualnym numerem przyporządkowanym tylko dla danej osoby. 3. Moduł musi umożliwiać wprowadzanie osób/podmiotów gospodarczych 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) Moduł musi umożliwiać wprowadzanie: 1) kilku różnych typów adresów, 2) osób powiązanych z daną osobą (np.: dla osób fizycznych – nazwisko rodowe, dla osoby pozostałej –właściciele), 3) dla osób pozostałych – kody PKD – funkcja zintegrowana z aplikacjami windykacyjnymi w celu stworzenia sprawozdania PKD, 4) kilku numerów kont bankowych. 5. Moduł 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. Moduł 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 modułu z różnymi danymi (aktualnymi i archiwalnymi). 8. Moduł musi umożliwiać tworzenie uprawnień, np. do grup danych interesantów dla poszczególnych użytkowników aplikacji w zakresie dostępu do informacji znajdujących się w Module 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.). 9. Moduł musi zawierać słowniki: krajów, miejscowości, ulic, imion, adresów, rodzajów organizacji, pozwalające dopisywać nowe dane i poprawiać uprzednio wprowadzone. 10. Moduł musi zawierać słowniki pieczątek/znaków graficznych wykorzystywanych w korespondencjach w zintegrowanym module podatku od nieruchomości. 11. Moduł musi posiadać funkcję importu danych z TERYTU Modułu 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. 12. Kartoteka interesantów Modułów dziedzinowych musi być wspólna dla modułu oraz powinna zawierać mechanizmy jej integracji (powiązań) z kartoteką EOD w szczególności w zakresie aktualizacji danych oraz wprowadzania nowych podmiotów. 13. Moduł musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji. Obszar płatności masowych i wyciągów bankowych. 1. Moduł musi umożliwiać gromadzenie i zarządzanie danymi o wyciągu bankowym oraz poszczególnych operacjach zarejestrowanych pod wyciągiem na podstawie dostarczanego przez bank elektronicznego pliku z zapisem operacji na koncie (kontach) bankowych. 2. Moduł musi zapewniać import wyciągów bankowych w formie elektronicznej o wymaganym formacie, w tym subwyciągów w ramach Modułu indywidualnych rachunków bankowych kontrahentów. 3. Moduł musi zapewniać rozkodowanie pliku wyciągu bankowego ze szczególnym uwzględnieniem wydzielenia z poszczególnych operacji bankowych kwoty oraz tytułu wpłaty. 4. Moduł musi zapewniać możliwość wyszukiwania danych z operacji zawartych w wyciągach bankowych. 5. Moduł musi zapewniać możliwość automatycznej identyfikacji wpłacającego na podstawie kodowanej informacji zawartej w numerze rachunku bankowego (wirtualne konta) oraz identyfikacja tytułu. 6. Moduł musi zapewniać weryfikację poprawności rozliczenia wyciągu w odniesieniu do ilość pozycji, kwoty, itp. 7. Moduł musi umożliwiać kodowanie i dekodowanie informacji o kontrahencie/podatniku urzędu oraz tytułu należności w ramach Modułu indywidualnych rachunków bankowych. 8. Moduł powinien zapewniać integrację funkcjonalności z modułami Modułu podatkowego (podatki i opłaty) obsługującymi indywidulane konta dla kontrahentów (konta wirtualne) w zakresie generowania indywidualnych rachunków bankowych. 9. Moduł musi umożliwiać import wyciągów bankowych z Modułu bankowości elektronicznej w zakresie zrealizowanych dochodów. 10. Moduł musi umożliwiać zaczytanie wyciągu bankowego wraz ze szczegółowym informacjami dotyczącymi dokumentów wpłaty: 1) data operacji, 2) data wpłaty, 3) kwota wpłaty, 4) dane kontrahenta, 5) tytuł płatności. 11. Moduł musi pozwalać na uzupełnienie informacji dodatkowych na dokumencie wpłaty oraz przyporządkowanie rat płaconych dokumentem zapłaty. 12. Moduł musi uniemożliwiać modyfikację rozliczonego wyciągu bankowego. 13. Moduł powinien zapewniać możliwość wykonania symulacji rozdysponowania środków wynikających z wpłaty: 1) symulacje zapłat odsetek od zaległości z możliwością wyboru lub zmiany stopy odsetek od zaległości. Analiza sposobu naliczania odsetek powinna być dostępna dla użytkownika z poziomu aplikacji z możliwością wydruku, 2) przeglądanie tytułów wykonawczych wystawionych na zaległe raty, 3) przeglądanie upomnień wystawionych na zaległe raty, 4) przypisanie kosztów upomnienia z poziomu formularza symulacji zapłat odsetek od zaległości, 5) wyświetlanie oznaczenia należności dowolnym znacznikiem określającym cechy szczególne należności. 14. Moduł musi zapewniać możliwość sprawdzenia poprawności rozliczenia wyciągu bankowego, w szczególności: 1) weryfikacji zgodności sald wyciągu bankowego z sumą obciążeń i uznań, 2) sprawdzenia, czy wyciąg posiada nieukończone dokumenty, 3) sprawdzenia, czy wyciąg posiada nierozliczone operacje, 4) weryfikacji zgodności poszczególnych kwot operacji z kwotami dokumentów, 5) weryfikacji zgodności sumy kwot operacji z łączną kwotą wynikająca z dokumentów. 15. Moduł musi umożliwiać prowadzenie rejestru postanowień o zarachowaniu wraz z możliwością wydruku ewidencji ze szczególnym uwzględnieniem możliwości: 1) zatwierdzania postanowienia o zarachowaniu, 2) wydrukowania zwrotki dołączanej do postanowienia, 3) wydrukowania duplikatu postanowienia, 4) archiwizowania postanowień. Obszar zwrotu podatku akcyzowego. 1. Moduł musi posiadać funkcjonalność ewidencjonowania (rejestracji) wniosków o zwrot podatku akcyzowego dla rolników zawartego w cenie oleju napędowego. 2. Moduł musi być zintegrowany tj. współpracować z dostarczanym w niniejszym postępowaniu obszarem podatków w obszarze podatku rolnego w zakresie automatycznego uzyskania informacji o posiadanych zasobach osób wnioskujących (według deklaracji/wniosków) w celu kontroli danych osobowych oraz powierzchni gruntów rolnych. 3. Moduł musi dokonywać automatycznego importu danych wyeksportowanych przez aplikację podatków w obszarze podatku rolnego, celem bezpośredniej pracy aplikacji na zaimportowanych danych, bez ingerencji i wykorzystywania w działaniu aplikacji danych przetwarzanych w obszarze podatków. 4. Moduł musi posiadać funkcjonalność kompleksowej obsługi wniosków o jakich mowa w pkt 1 tj. co najmniej: rejestracja, sprawdzenie poprawności danych, dokonanie przeliczeń: stawek, należności, wydanie decyzji wraz z jej wydrukiem. 5. Moduł musi obsługiwać tj. wystawiać decyzje określające zwrot podatku akcyzowego. 6. Moduł musi umożliwiać automatyczne seryjne wystawianie decyzji określających zwrot podatku akcyzowego. 7. Moduł musi umożliwiać tworzenie listy wypłat do banku/kasy wraz z przeliczeniem nominałów potrzebnych do wypłaty oraz wydrukiem. 8. Moduł musi posiadać funkcjonalność generowania zestawienia przyjętych wniosków oraz zestawienia wydanych decyzji. 9. Moduł musi posiadać funkcjonalność generatora wydruków i zestawień generowanych na podstawie dostępnych w aplikacji parametrów. 10. Moduł musi posiadać funkcjonalność wygenerowania zestawień statystycznych na podstawie dostępnych w aplikacji parametrów i przetwarzanych przez aplikację danych. 11. Moduł musi posiadać funkcjonalność rejestracji faktur paliwowych wraz z możliwością zaewidencjonowania danych szczegółowych faktury. 12. Moduł musi posiadać funkcjonalność aktualizacji (automatycznej oraz ręcznej – na żądanie użytkownika) rocznych stawek za 1 litr oleju napędowego. 13. Moduł musi posiadać funkcjonalność automatycznego wyliczenia zwrotu podatku akcyzowego na podstawie dołączonych do wniosków faktur przy uwzględnieniu powierzchni użytków rolnych wnioskodawcy. 14. Moduł musi posiadać funkcjonalność automatycznego wyliczenia rocznego limitu kwoty zwrotu podatku akcyzowego wraz z informowaniem użytkownika aplikacji o stopniu wykorzystania przysługującej w danym roku kwoty oraz prezentowania informacji o wartości kwoty jaka pozostała do wypłaty w kolejnym okresie przyjmowania wniosków. 15. Moduł musi posiadać funkcjonalność wyliczania ilości litrów oleju napędowego potrzebnych do wykorzystania w ramach przysługującej części zwrotu w drugim terminie rozliczeniowym. 16. Moduł musi posiadać funkcjonalność podglądu danych gruntów rolnych wyeksportowanych z obszaru podatkowego (dane z podatku rolnego). 17. Moduł musi posiadać funkcjonalność sumowania i zliczania danych z pojedynczych faktur za olej napędowy oraz możliwość wprowadzenia faktury zbiorczej. 18. Moduł musi zapewniać obsługę pomocy publicznej w rolnictwie lub rybołówstwie, innej niż pomoc DE MINIMIS, wraz z możliwością wyeksportowania danych dotyczących pomocy publicznej w formie elektronicznej do pliku. 19. Moduł musi obsługiwać zlecenia wypłat zwrotu tj. generować pliki elektroniczne dla przelewów elektronicznych w formatach co najmniej: ELIXIR, HOMENET, MultiCash. 20. Moduł musi obsługiwać tj. rozliczać wypłaty częściowe zwrotu podatku akcyzowego. 21. Moduł musi posiadać funkcjonalność archiwizacji wykonanych w module wydruków. 22. Moduł musi posiadać funkcjonalność automatycznego wyliczenia „Wniosku o przekazanie gminie dotacji celowej na zwrot podatku akcyzowego” w danym okresie rozliczeniowym. 23. Moduł musi posiadać funkcjonalność automatycznego wyliczenia rocznych i okresowych sprawozdań, w tym co najmniej: 1) sprawozdanie rzeczowo-finansowe, 2) rozliczenie dotacji celowej. 24. Moduł musi posiadać funkcjonalność generowania zestawień przyjętych wniosków. 25. Moduł musi posiadać funkcjonalność generowania zestawień wystawionych decyzji. 26. Moduł musi posiadać dwuetapowe automatyczne (z poziomu modułu oraz wydruków) sprawdzenie oraz kontrolowanie wprowadzonych wniosków i wydawanych decyzji. Obszar koncesji alkoholowych. 1. Moduł musi umożliwiać rejestrację podmiotu ubiegającego się o zezwolenie z jego lokalizacją oraz z wyszczególnieniem: 1) nazwa przedsiębiorcy, 2) adres przedsiębiorcy, 3) numer NIP / REGON, 4) rodzaj przedsiębiorcy (np.: spółka cywilna, działalność gospodarcza, sp. z o. o. itd.), 5) dane właścicieli np.: spółki cywilnej (nazwa/imię nazwisko, REGON/PESEL, NIP, adres), 6) data rozpoczęcia działalności, 7) lokalizacja, 8) pole opisowe na dodatkowe informacje zdefiniowane przez użytkownika. 2. Minimalny zakres danych dotyczących lokalizacji punktu powinien zawierać: 1) nazwa lokalizacji, 2) adres lokalizacji lub opis miejsca sprzedaży, 3) numer aktu i data, od której podmiot posiada prawa do lokalizacji (np.: data dzierżawy lokalu), 4) decyzja Sanepidu, 5) pole opisowe na dodatkowe informacje zdefiniowane przez użytkownika. 3. Moduł musi umożliwiać rejestrację nazwy i adresu magazynu, w którym składowany jest alkohol. 4. Moduł musi umożliwiać rejestrację informacji o limicie przyznawanych koncesji na sprzedaż napojów alkoholowych przeznaczonych do spożycia w miejscu lub poza miejscem sprzedaży ustalonych w drodze uchwały przez Radę Miejską. 5. Moduł musi posiadać możliwość rejestracji wniosku, na podstawie którego zostaną wystawione zezwolenia na sprzedaż alkoholu z funkcjonalnością dostępu do historii punktu sprzedaży. 6. Moduł musi umożliwiać rejestrację zezwoleń na sprzedaż i wyprzedaż napojów alkoholowych, na podstawie danych z wniosku, w szczególności: 1) data rejestracji, 2) nazwa oraz typ zezwolenia, 3) czas obowiązywania zezwolenia, 4) automatyczne nadawanie numeru zezwolenia, wygenerowanego w oparciu 5) definiowany przez użytkownika szablon, 6) pole opisowe na dodatkowe informacje zdefiniowane przez użytkownika. 7. Moduł musi umożliwiać wygaszenie/cofnięcie zezwolenia z podaniem przyczyny i numeru decyzji. 8. Moduł musi umożliwiać rejestrację oświadczeń o sprzedaży za rok poprzedni. 9. Moduł musi umożliwiać naliczenie opłat dla pojedynczego zezwolenia z podziałem na raty, lub jednorazową opłatę. 10. Moduł musi umożliwiać tworzenie zestawień: 1) według nazwy i typu zezwolenia, 2) według czasu trwania zezwolenia, 3) liczba wystawionych zezwoleń dla podmiotu/lokalizacji. 11. Moduł musi umożliwiać wyszukiwanie danych według podstawowych danych przedsiębiorcy, lokalizacji, danych wniosku lub zezwolenia. 12. Moduł musi umożliwiać tworzenie statystyk, w szczególności: 1) zarejestrowanych wniosków, 2) zarejestrowanych zezwoleń, 3) lista punktów limitowych. 13. Moduł musi umożliwiać tworzenie zestawień zbiorczych dla zezwoleń oraz ich wydruk. 14. Moduł musi umożliwiać rejestrację wszystkich możliwych rodzajów decyzji (zwykłe, jednorazowe, catering). 15. Moduł musi wspierać obsługę pism do Głównej Komisji Rozwiązywania Problemów Alkoholowych. 16. Moduł musi umożliwiać ewidencję kontroli punktu sprzedaży alkoholu. 17. Moduł musi umożliwiać uzyskanie informacji o liczbie punktów sprzedaży alkoholu wraz z określeniem obrotów dla każdego typu alkoholu na potrzeby bieżącego określenia i kontroli limitów przyznawanych koncesji na sprzedaż napojów alkoholowych przeznaczonych do spożycia w miejscu lub poza miejscem sprzedaży ustalonych w drodze uchwały przez Radę Miejską. Obszar ewidencji ludności. 1. Moduł powinien wspierać 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, PESEL, nazwisko aktualne, imię, płeć, data urodzenia, miejscowość, adres stały, adres czasowy (aktualny, poprzedni), nazwisko rodowe, nazwisko poprzednie, obcokrajowiec. 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, imiona, nr PESEL, historia zameldowania. Moduł powinien umożliwiać gromadzenie danych określonych w art. 8 Ustawy z dnia 24 września 2010 r. o ewidencji ludności (Dz. U. z 2010 r., Nr 217, poz. 1427 z późń. zm.). 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 Moduł 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ć dostęp do rejestru cudzoziemców, w tym przynajmniej: 1) tworzenie danych historycznych cudzoziemca; 2) modyfikację danych historycznych cudzoziemca; 3) usuwanie danych historycznych cudzoziemca; 4) przeglądanie danych historycznych cudzoziemca. 10. 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. 11. Powinna istnieć możliwość określania formatu adresu na wydrukach poprzez przygotowanie szablonu adresu zgodnie ze wzorem, które określa rozporządzenie. 12. Możliwość wygenerowania plików DW1, DW2, DW3 przekazywanych do GUS. 13. Moduł musi zapewnić obsługę e-usług w zakresie niezbędnym do ich realizacji. 14. Moduł powinien umożliwić po wyszukaniu danych osoby wygenerowanie wydruków: 1) zaświadczenie zawierające pełny odpis przetwarzanych danych; 2) wniosek o udostępnienie danych osobowych; 3) zaświadczenie o ilości osób współzameldowanych pod adresem stałym lub czasowym mieszkańca; 4) zaświadczenie o zameldowaniu na pobyt stały; 5) zaświadczenie o zameldowaniu na pobyt czasowy; 6) zaświadczenie o wymeldowaniu z pobytu stałego; 7) zaświadczenie o wymeldowaniu z pobytu czasowego; 8) zaświadczenie o zameldowaniu na pobyt strały z poprzednimi adresami. 15. Moduł powinien umożliwić wygenerowanie wydruków: 1) wykaz osób podlegających rejestracji do kwalifikacji wojskowej; 2) wykaz osób podlegających obowiązkowi stawienia do kwalifikacji wojskowej; 3) protokół z pracy systemu (użytkownik, data, godzina, PESEL, opis); 4) zestawienie dowodów osobistych do unieważnienia; 5) wydruk listy mieszkańców według parametrów (dane aktualne i dane poprzednie); 6) wydruk zgonów; 7) wydruk listy miejscowości i ulic. 16. Moduł powinien prowadzić statystykę dla rejestru mieszkańców: 1) statystyka pod wskazanym adresem (parametry: miejscowość, ulica, numer domu, numer lokalu, mieszkańcy: zameldowani na stałe, zameldowani czasowo); 2) lista lokali w budynku (parametry: miejscowość, ulica, numer domu, mieszkańcy: zameldowani na stałe, zameldowani czasowo); 3) zestawienie informacyjne z Rejestru mieszkańców (parametry: zameldowanie na dzień, miejscowość, zameldowanie - stałe, czasowe, wszystkie, wiek z przedziałami standardowymi (np. do 18 lat, od 18 lat itp. ). 17. Dostęp do bazy Ewidencja ludności przed 01.03.2015 r. Obszar dotyczący rejestru wyborców. 1. 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. 2. Moduł powinien wyszukiwanie kart rejestru dodatkowego. 3. Powinna istnieć możliwość utworzenia edycji i usunięcia kart rejestru dodatkowego, a także podglądu listy kart rejestru dodatkowego w formie wydruku. 4. Moduł musi umożliwiać wykonanie wydruków: 1) zawiadomienia o dopisaniu do rejestru wyborców, 2) o skreśleniu z rejestru wyborców, 3) aktu pełnomocnictwa, 4) masowych zawiadomień o dopisaniu do spisu wyborców, 5) decyzji o dopisaniu do rejestru wyborców, 6) rejestru niegłosujących, 7) zaświadczenia o prawie do głosowania, 8) statystyka wydanych zaświadczeń. 5. Moduł powinien umożliwiać wyszukiwanie kart rejestru niegłosujących wg. zadanych parametrów, a także tworzenie, edycję i usunięcie kart rejestru niegłosujących. 6. Rejestr wyborców powinien umożliwiać filtrowanie danych. 7. Moduł powinien umożliwiać zarządzanie listą wyborów dodawanie, edycja, usuwanie oraz zatwierdzanie listy wyborów. 8. Moduł powinien umożliwiać wykreślanie i usuwanie pozycji ze spisu wyborczego. 9. Moduł powinien umożliwiać określanie i edycję przyczyny dopisania lub wykreślenia ze spisu wyborczego. 10. Moduł powinien umożliwiać tworzenie, edycję, usuwanie i weryfikację geografii wyborczej. 11. Moduł powinien umożliwiać tworzenie meldunku: 1) stanie rejestru wyborców w gminie/mieście, 2) o stanie rejestru wyborców w stałych okręgach wyborczych i obwodach głosowania. Obszar dotyczący opłat innych. 1. Moduł musi umożliwiać zdefiniowane dowolnej nazwy opłaty, która będzie wprowadzana do systemu. 2. Parametry modułu muszą pozwalać na ustalenie czy naliczenie wprowadzanej opłaty będzie wykonywane w zaokrągleniu do złotówki, do grosza, czy do 10 groszy. 3. Moduł musi dać możliwość zdefiniowania, czy opłata będzie rozliczana w module do obsługi księgowości zobowiązań, czy też będzie pobierana w kasie. Definiowanie integracji do modułów odbywa się w trybie online. 4. Powinna istnieć możliwość zdefiniowania rodzaju odsetek dla opłaty. 5. Moduł powinien umożliwiać wprowadzanie kartotek opłat oraz zarządzanie nimi: 1) dawać możliwość ustalenia stanu rozliczenia naliczonej opłaty, 2) dawać możliwość wyszukiwania kartotek według wybranych kryteriów: numeru opłaty, roku opłaty, opisu opłaty, danych opłacającego, daty wprowadzenia, stanu rozliczenia, statusu opłaty. 6. Podczas zakładania nowych kartotek system musi dawać możliwość wyboru zobowiązanych oraz zdefiniowania rat i terminów płatności rat. 7. Moduł powinien umożliwiać anulowanie naliczonych opłat. 8. Moduł powinien dawać możliwość zdefiniowania jaki rodzaj zawiadomienia ma być wystawiany w przypadku stwierdzenia zaległości (Upomnienie, Wezwanie). 9. Moduł powinien dawać użytkownikowi możliwość podejrzenia kartoteki w module do księgowości zobowiązań w trybie online. 10. Powinna istnieć możliwość wystawienia decyzji dla opłaty: o odroczeniu terminu płatności, rozłożeniu zapłaty należności na raty, umorzeniu zaległości, umorzeniu odsetek. 11. Moduł powinien mieć możliwość zdefiniowania, czy opłata ma mieć przypisany VAT i możliwość określenia domyślnego podatku VAT w celu prawidłowego rozliczenia w księgowości zobowiązań. Obszar dotyczący dodatków mieszkaniowych. 1. Moduł musi mieć możliwość prowadzenia ewidencji wnioskodawców z uwzględnieniem: 1) danych o lokalu mieszkalnym; 2) danych o osobach w rodzinie, 3) źródłach dochodu 4) wysokości zarobków; 5) wywiadu środowiskowego. 2. Moduł musi mieć możliwość: wprowadzania wniosku, ustalania dodatku, wystawianie decyzji (o przyznaniu lub odmownych). 3. Możliwość naliczania wypłat, tworzenia listy wypłat a w konsekwencji wydruk listy, przelewów oraz list do zarządców do tej listy. 4. Możliwość wykonania oddzielnych wydruków dla list wypłat podstawowych jak i dodatkowych. 5. Moduł musi mieć możliwość eksportu danych dotyczących przelewów w celu połączenia z systemem bankowym. 6. Możliwość wygaszania dodatków z mocy ustawy. 7. Możliwość zawieszania, odwieszania wypłat dodatków. 8. Możliwość wydruku zaświadczenia o wysokości pobranych dodatków mieszkaniowych w podanym okresie. 9. Możliwość tworzenia przelewów elektronicznych z list wypłat. 10. Możliwość prowadzenia statystyki ilościowo-wartościowej dodatków. 11. Powinna być możliwość ewidencji pracowników przeprowadzających wywiady. 12. Możliwość symulacji zmiany wysokości dodatków w przypadku wprowadzenia innego ograniczenia. 13. Możliwość wprowadzenia podziału czynszu na media. 14. System musi mieć możliwość otrzymania zestawień: zestawienia wypłat za wybrany okres; zestawienia dodatków mieszkaniowych wg. zarządców; wydruk statystyki do sprawozdania GUS (SG-01). 15. Kartoteka wnioskodawcy powinna zawierać szczegółowe dane potrzebne do prowadzenia ewidencji, łącznie z danymi o cenie energii elektrycznej, zarządcy, tytule prawnym do lokalu, dochodu, powierzchni, mediach itp. 16. Moduł powinien dawać możliwość konfiguracji danych słownikowych, np. słownika zarządców, słownika rodzajów wydatków (energia elektryczna, opłata za ciepłą wodę itp.), stawki najniższej emerytury, próg najniższego podatku, ryczałtów, pracowników, znaków decyzji, kwot dodatku energetycznego. 17. Moduł powinien mieć możliwość konfiguracji takich danych parametrów, jak liczba miejsc po przecinku w przypadku ryczałtu tytułów prawnych, listy osób otrzymujących kopie pisma. 18. Moduł musi dawać możliwość konfiguracji i wydruku pism. 19. System musi umożliwiać wprowadzanie korekty dodatku. 20. Obsługa dodatków powinna mieć również możliwość dodania notatek tekstowych, potrzebnych pracownikom obsługującym dodatki. 21. Wypłaty dodatków powinny być możliwe do przejrzenia w postaci listy lub rejestru wypłat. 22. Moduł powinien dawać możliwość przeglądu wypłat z lat poprzednich. 23. Kartoteka przyznanego dodatku powinna dawać możliwość przeglądu historii zmian dodatku. 24. Kartoteka powinna zawierać również metrykę sprawy z możliwością przeglądu osoby odpowiedzialnej za przyznanie wniosku. Obszar symulacji podatkowych. 1. Moduł powinien umożliwiać określanie dwóch wariantów symulowanych stawek dla naliczenia dla podatku rolnego, podatku leśnego, podatku od nieruchomości i podatku od środków transportowych. 2. Moduł powinien umożliwiać wykonywanie symulowanych naliczeń z uwzględnieniem stawek ustawowych, gminnych oraz dwóch wariantów stawek symulacyjnych dla podatku rolnego, podatku leśnego, podatku od nieruchomości i podatku od środków transportowych w podziale na osoby fizyczne i osoby prawne oraz dla opłaty za posiadanie psów. 3. Moduł powinien umożliwiać sporządzanie wydruku skutków obniżenia górnych stawek podatku dla podatku rolnego, podatku leśnego, podatku od nieruchomości i podatku od środków transportowych w podziale na osoby fizyczne i osoby prawne oraz dla opłaty za posiadanie psów. 4. Moduł powinien umożliwiać sporządzanie wydruku skutków udzielonych ulg i zwolnień dla podatku rolnego, podatku leśnego, podatku od nieruchomości i podatku od środków transportowych w podziale na osoby fizyczne i osoby prawne oraz dla opłaty za posiadanie psów. Obszar wydruków. 1. Moduł powinien umożliwiać wyszukiwanie szablonów wg parametrów, co najmniej wg: 1) typu szablonu dokumentu, 2) nazwie, 3) wersji, 4) opisie, 5) autorze, 6) dacie utworzenia, 7) dacie zmiany. 2. Moduł powinien umożliwiać zmianę szablonu wydruków systemu dziedzinowego, w tym co najmniej dla: 1) decyzji o umorzeniu, 2) decyzji o umorzeniu odsetek, 3) decyzji o odroczeniu terminu płatności zobowiązania, 4) decyzji o rozłożeniu zobowiązania na raty, 5) zestawienia decyzji, 6) decyzji o ustaleniu wysokości zobowiązania (opłat za gospodarowanie odpadami), 7) wezwania do złożenia deklaracji, 8) wezwania do złożenie wyjaśnień, 9) sprawozdania rocznego z zakresu gospodarki odpadami, 10) sprawozdanie kwartalnego z odpadów komunalnych, 11) sprawozdania kwartalnego z nieczystości ciekłych, 12) kopert adresowych dla kontrahenta, 13) etykiet środka trwałego, 14) postanowienia o zarachowaniu wpłaty, 15) tytułu wykonawczego, 16) wydruku sprawy, 17) zawiadomienia dla płatnika z płatności masowych, 18) zawiadomienia o zmianie wysokości stawki opłaty za śmieci, 19) polecenia przelewu, 20) zestawienia indywidualnych numerów rachunków, 21) wydruku kwitariusza. 3. Moduł powinien umożliwiać tworzenie nowego szablonu na podstawie istniejącej wersji danego rodzaju szablonu. 4. Moduł powinien umożliwiać modyfikację treści szablonu, w tym możliwość dodawania lub usuwania elementów wydruku pobieranych z bazy danych systemu dziedzinowego. Lista dostępnych elementów dla każdego z wydruków powinna być dostępna w edytorze. Znacznik pobierający dane z bazy można dodać metodą „drag and drop” lub poprzez dwukrotne kliknięcie. Moduł musi umożliwiać dowolne umiejscowienie znacznika na wydruku. Przykładowe treści pobieranie z bazy i dodawane do wydruku w postaci znacznika to: 1) adres, 2) imię, 3) data (np. podania, odbioru), 4) nr kartoteki, 5) stanowisko osoby wydającej dokument, 6) kwoty rat, 7) kod pocztowy itd. 5. Moduł powinien umożliwiać edycję wizualną szablonu, w tym co najmniej: 1) koloru, rozmiaru i stylu czcionki (podkreślenia, przekreślenia, pogrubienia), 2) ustawienia parametrów strony typu szerokość, wysokość, marginesy, koloru tła, wyśrodkowania, wyrównania, 3) możliwości kopiowania formatu elementów znajdujących się na wydruku i wklejania tego formatu do innych elementów, 4) wstawiania pól tekstowych, 5) wstawiania obiektów typu obraz, wykres, element OLE, 6) poszerzenia i zwężania elementów wydruków poprzez przesunięcie kursorem, 7) wyrównania względem innych elementów wydruku. 6. Moduł powinien umożliwiać podgląd wydruku szablonu ze znacznikami, w tym podgląd szablonu ze wstawionymi wartościami przykładowymi w miejsce znaczników. 7. Moduł powinien umożliwiać aktywację i dezaktywację szablonu (gdy szablon jest np. nieaktualny). 8. Moduł powinien umożliwiać wydruk kopii wykonanego wydruku z oznaczeniem, że jest to kopia wykonanego wydruku. 5.6. Opracowanie i wdrożenie e-usług na platformie e-urząd – 3PD i 4PD Zakres planowanych do wdrożenia e-usług bazujących na formularzach ePUAP w zakresie usług na 3 i 4 poziomie dojrzałości obejmować będzie: Lp. Nazwa e-usługi Opis e-usługi Poziom dojrzałości 1. Deklaracja na podatek od nieruchomości od osób prawnych Usługa pozwala na złożenie drogą elektroniczną deklaracji na podatek od środków transportowych. • Klient otrzymuje na portalu informację o wysokości płatności, w systemie EOD jest generowane UPD, • Klient uiszcza opłatę elektronicznie, • System informatyczny rejestruje dokonaną opłatę 4 2. Informacja o wysokości opłat za podatek od nieruchomości od osób fizycznych Usługa pozwalająca na elektroniczną weryfikację informacji o wysokości opłat indywidualnych, wnoszonych przez osoby fizyczne, na poczet podatku od nieruchomości. • zalogowany użytkownik wejdzie do odpowiedniej zakładki w portalu dotyczącej jego podatków, • do Systemu ERP będzie wysyłane zapytanie o informacje dotyczące konkretnego użytkownika, • System ERP wyślę informacje odnośnie użytkownika, zostaną one zwizualizowane na portalu 4 3. Deklaracja na podatek rolny od osób prawnych Usługa pozwala na złożenie drogą elektroniczną deklaracji na podatek rolny przez osobę prawną • Klient otrzymuje na portalu informację o wysokości płatności, w systemie EOD jest generowane UPD, • Klient uiszcza opłatę elektronicznie, • System informatyczny rejestruje dokonaną opłatę 4 4. Informacja o wysokości opłat za podatek rolny od osób fizycznych Usługa pozwalająca na elektroniczną weryfikację informacji o wysokości opłat indywidualnych, wnoszonych przez osoby fizyczne, na poczet podatku rolnego. • zalogowany użytkownik wejdzie do odpowiedniej zakładki w portalu dotyczącej jego podatków, • do Systemu ERP będzie wysyłane zapytanie o informacje dotyczące konkretnego użytkownika, • System ERP wyślę informacje odnośnie użytkownika, zostaną one zwizualizowane na portalu 4 5. Deklaracja na podatek leśny od osób fizycznych Usługa pozwala na złożenie drogą elektroniczną deklaracji na podatek leśny • Klient otrzymuje na portalu informację o wysokości płatności, w Systemie EOD jest generowane UPD, • Klient uiszcza opłatę elektronicznie, • System informatyczny rejestruje dokonaną opłatę 4 6. Informacja o wysokości opłat za podatek leśny od osób fizycznych Usługa pozwala na złożenie drogą elektroniczną informacji w sprawie podatku leśnego • Klient otrzymuje na portalu informację o wysokości płatności z decyzją, w Systemie EOD generuje się UPD, • Klient uiszcza opłatę elektronicznie, • System informatyczny rejestruje dokonaną opłatę 4 7. Deklaracja na podatek od środków transportowych od osób fizycznych Usługa pozwala na złożenie przez osobę fizyczną drogą elektroniczną deklaracji na podatek od środków transportowych (DT-1) wraz z załącznikami (DT-1/A) (Rozporządzenie Ministra Finansów z dnia 13 grudnia 2018 r. w sprawie wzoru deklaracji na podatek od środków transportowych (Dz. U. z 2018 poz. 2436) 4 8. Deklaracja na podatek od środków transportowych od osób prawnych Usługa pozwala na złożenie przez osobę prawną drogą elektroniczną deklaracji na podatek od środków transportowych (DT-1) wraz z załącznikami (DT-1/A) (Rozporządzenie Ministra Finansów z dnia 13 grudnia 2018 r. w sprawie wzoru deklaracji na podatek od środków transportowych (Dz. U. z 2018 poz. 2436) 4 9. Deklaracja o wysokości opłaty za gospodarowanie odpadami komunalnymi Usługa pozwala na złożenie drogą elektroniczną deklaracji o wysokości opłaty za gospodarowanie odpadami komunalnymi • Klient otrzymuje na portalu informację o wysokości płatności, w systemie EOD jest generowane UPD, • Klient uiszcza opłatę elektronicznie, • System informatyczny rejestruje dokonaną opłatę 4 10. Wydanie zaświadczenia o wysokości zaległości podatkowych podatnika Usługa pozwala na złożenie drogą elektroniczną wniosku o wydanie zaświadczenia dotyczącego wysokości zaległości podatkowych podatnika • wygenerowanie automatyczne zaświadczenia o wysokości zaległości, • wysłanie decyzji na portal 4 11. Informacja o niezaleganiu w podatkach/opłatach Usługa pozwala na złożenie drogą elektroniczną wniosku o wydanie zaświadczenia dotyczącego niezaleganiu w podatkach/opłatach • wygenerowanie automatyczne zaświadczenia o niezaleganiu w podatkach/opłatach, • wysłanie decyzji na portal, 4 12. Stwierdzenie nadpłaty podatku Usługa pozwala na złożenie drogą elektroniczną wniosku o stwierdzenie nadpłaty podatku • wygenerowanie decyzji, • wysłanie informacji o korekcie należności do Systemu ERP, • wysłanie decyzji na portal z otrzymaniem UPD, • odbiór decyzji przez Interesanta na portalu. 4 13. Akcyza Zwrot podatku akcyzowego zawartego w cenie oleju napędowego wykorzystywanego do produkcji rolnej • Klient wysyła elektronicznie formularz wniosku wraz z załącznikami, • Użytkownik otrzymuje wygenerowane UPO potwierdzające dostarczenie dokumentu, • Odbiór formularza w Systemie obiegu dokumentów powoduje wykonanie transakcji przez system informatyczny 4 14. wycinka drzew Wniosek składany przez posiadacza, właściciela nieruchomości albo właściciela urządzeń o których mowa w art. 49 § 1 Kodeksu cywilnego wraz z załącznikami. 3 15. zaświadczenie o przeznaczeniu w planie miejscowym Uprawnieni wnioskodawcy składają wniosek o wydanie zaświadczenia z miejscowego planu zagospodarowania przestrzennego gminy oraz potwierdzenie wniesienia opłaty skarbowej. 3 16. wydanie warunków zabudowy Osoby uprawnione składają wniosek o wydanie decyzji o warunkach zabudowy wraz z załącznikami wymienionymi w formularzu wniosku, a także: • wypis z Krajowego Rejestru Sądowego lub innego rejestru (podmioty prawne) wydany nie później niż 3 miesiące przed datą złożenia wniosku, • pełnomocnictwo dla osoby upoważnionej, jeżeli wnioskodawca działa przez pełnomocnika, • dowód dokonania należnej opłaty skarbowej. Wydanie decyzji wiąże się z koniecznością wniesienia opłat skarbowych. 3 Opracowanie i wdrożenie e-usług na 3 i 4 poziomie dojrzałości obejmie: 1. Odwzorowanie zaprojektowanych procesów biznesowych w systemach informatycznych wspierających świadczenie e-usług publicznych na 3 i 4 poziomie dojrzałości. 2. Wskazanie odpowiednich aktów prawnych jako źródeł wytycznych i ograniczeń dotyczących dokumentów odnoszących się do danej elektronizowanej usługi publicznej, 3. Identyfikację w treści dokumentów zapisów wymagających modyfikacji w wyniku elektronizacji usług publicznych. 4. Opracowanie kart usług zawierające podstawowe informacje dotyczące specyfiki danej usługi publicznej. 5. 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. 6. Analizę dostępności formularzy elektronicznych w Centralnym Repozytorium Wzorów Dokumentów Elektronicznych pod kątem możliwości ich wykorzystania w celu świadczenia wdrażanych w ramach projektu e-usług publicznych. W przypadku, jeżeli nie będzie możliwości wykorzystania dla e-usługi publicznej formularzy dostępnych w CRWD prace obejmą przygotowanie i zgłoszenie formularzy ePUAP dla każdej z wybranych e-usług publicznych zgodnie z zapisami niniejszego załącznika. Zamawiający zastrzega sobie możliwość zmiany w/w e-usług publicznych na etapie realizacji zamówienia oraz zmiany formularzy e-usług, szczególnie w przypadku zmiany formularzy narzuconych przez zmianę przepisów prawa. 5.7. Wymagania w zakresie bezpieczeństwa systemu 1. System musi pracować w trybie 24/7/365 (24h na dobę, 7 dni w tygodniu i 365 dni w roku). 2. System musi być wyposażony w mechanizmy zabezpieczenia danych (backup) pozwalający na automatyczne zgodnie z uzgodnionym harmonogramem tworzenie kopii zapasowych całej aplikacji oraz bazy danych, zgodnie z wytycznymi odpowiedniej Polityki Bezpieczeństwa. 3. Do komunikacji z interesantem jest wykorzystywany protokół HTTPS. 4. System powinien zabezpieczać wymianę danych z systemami zewnętrznymi co najmniej za pomocą protokołu SSL. 5. System musi być odporny na znane ataki internetowe mogące zakłócić jego funkcjonowanie, w tym być odpornym na wstrzykiwanie/podmianę kodu lub uruchamianie skryptów niebędących częścią systemu. 6. Formularze elektroniczne niezabezpieczone podpisem elektronicznym (np. formularz rejestracji użytkownika, formularz wiadomość wysyłanej w trakcie prowadzenia czatu) muszą być zabezpieczone mechanizmem CAPTCHA. 5.8. Szkolenia 1. Wykonawca przeprowadzi dla administratora i użytkowników systemu u Zamawiającego szkolenie z zakresu obsługi i konfiguracji dostarczonych rozwiązań aplikacyjnych obejmujące co najmniej: a. obsługę całego systemu bądź jego części wspomagającej obsługę obszarów działalności urzędu i jego jednostek dla pracowników, w liczbie niemniej niż 8 godzin zegarowych; 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 w liczbie niemniej niż 8 godzin zegarowych; 2. Szkolenie odbywało się będzie w siedzibie Zamawiającego. 5.9. Postanowienia końcowe 1. Zamawiający zastrzega sobie możliwość zmiany w/w e-usług publicznych na etapie realizacji zamówienia oraz zmiany formularzy e-usług, szczególnie w przypadku zmiany formularzy narzuconych przez zmianę przepisów prawa. 2. Wykonanie całości ww. Systemu zostanie zakończone procedurą odbioru oraz protokołem odbioru, w tym wymienionych elementów systemu e-urząd. Szczegółowy Opis przedmiotu zamówienia -http://bip.pieniezno.pl/przetarg/4379/in-271-1-4-2019
2) Wspólny Słownik Zamówień(CPV): 48000000-8, 48422000-2, 48442000-8, 48600000-4, 48900000-7, 72000000-5, 72211000-7, 72263000-6, 72253200-5, 72322000-8, 72310000-1, 72512000-7, 48422000-2

3) Wartość części zamówienia(jeżeli zamawiający podaje informacje o wartości zamówienia):
Wartość bez VAT:
Waluta:

4) Czas trwania lub termin wykonania:
okres w miesiącach:
okres w dniach:
data rozpoczęcia:
data zakończenia: 2019-12-31
5) Kryteria oceny ofert: