Cześć dotycząca zamawianego sprzętu

Znak: ZIN.271.02.2014

Załącznik nr 7

do SIWZ

Szczegółowy opis przedmiotu zamówienia

Cześć dotycząca zamawianego sprzętu

oju o

Serwer - 2 szt.

LP	Parametr	Minimalne wymagania
1	Obudowa	Obudowa typu Rack o wysokości maksymalnie 2U z możliwością instalacji minimum 8 dysków 3.5" Hot Plug wraz z kompletem szyn umożliwiających montaż w szafie rack i wysuwanie serwera do celów serwisowych oraz organizatorem kabli. Posiadająca fizyczne zabezpieczenie dedykowane przez producenta serwera uniemożliwiające wyjęcie dysków twardych przez nieuprawnionych użytkowników.
2	Płyta główna	Z możliwością instalacji minimum dwóch fizycznych procesorów dwu, cztero, sześcio lub ośmiordzeniowych, posiadająca minimum 12 slotów na pamięci z możliwością zainstalowania do minimum 384GB pamięci RAM, możliwe zabezpieczenia pamięci: ECC, SDDC, Memory Mirroring Rank Sparing, SBEC. Płyta główna zaprojektowana przez producenta serwera i oznaczona trwale jego znakiem firmowym
3	Procesor	Dwa procesory sześciordzeniowe dedykowane do pracy z zaoferowanym serwerem umożliwiające osiągnięcie wyniku minimum 351 punktów w teście SPECint_rate_base2006 dostępnym na stronie internetowej xxx.xxxx.xxx dla konfiguracji dwuprocesorowej. Do oferty należy załączyć wydruk z wynikiem testu dla oferowanego modelu serwera.
4	Pamięć operacyjna	Minimum 128 GB pamięci RAM; typu RDIMM o częstotliwości taktowania minimum 1600 MHz
5	Sloty PCI Express	Funkcjonujące sloty PCI Express: - minimum jeden slot x16 generacji 3 - minimum trzy sloty x16 o predkości x8 generacji 3 dla kart pełnej wysokości
6	Karta graficzna	Zintegrowana karta graficzna, umożliwiająca wyświetlanie obrazu w rozdzielczości minimum 1280x1024 pikseli
7	Wbudowane porty	Minimum 5 portów USB 2.0 (w tym 2 na przednim panelu,2 na tylnym panelu, 1 wewnętrzny), 1x RS-232, 2x VGA D-Sub
8	Interfejsy sieciowe	Minimum 2 interfejsy sieciowe Gigabit Ethernet Base-T nie zajmujące żadnego z dostępnych slotów PCI Express Dodatkowa czteroportowa karta sieciowa 1Gb Ethernet w standardzie BaseT oraz dodatkowa dwuportowa karta sieciowa 10Gb Ethernet w standardzie SFP+/Direct Attach
9	Kontroler dysków	Sprzętowy kontroler dyskowy, posiadający minimum 512MB nieulotnej pamięci cache , umożliwiający konfigurację poziomów RAID : 0, 1, 5, 6, 10, 50, 60 oraz dodatkowa zainstalowana dwuportowa karta HBA posiadająca min. 2 złącza zewnętrzne SAS o prędkości minimum 6Gb/s
10	Wewnętrzna pamięć masowa	Zainstalowane 4 dyski twarde, o pojemności minimum 600 GB SAS 15k RPM każdy skonfigurowane fabrycznie w RAID 5. Możliwość instalacji dysków SATA, NearLine SAS, SAS, SSD i SED dostępnych w ofercie producenta serwera. Możliwość instalacji wewnętrznego modułu dedykowanego dla hypervisora wirtualizacyjnego, wyposażonego w dwa jednakowe nośniki typu flash z możliwością skonfigurowania zabezpieczenia typu "mirror" pomiędzy nośnikami z poziomu BIOS serwera, rozwiązanie nie może powodować zmniejszenia ilości wnęk na dyski twarde.
11	Napęd optyczny	Zainstalowany wewnętrzny napęd umożliwiający odczyt nośników DVD+/-RW
12	System diagnostyczny i bezpieczeństwo	- Panel LCD umieszczony na froncie obudowy, umożliwiający wyświetlenie informacji o stanie procesora, pamięci, dysków, BIOS’u, zasilaniu oraz temperaturze Zintegrowany z płytą główną moduł TPM Wbudowany czujnik otwarcia obudowy współpracujący z BIOS i kartą zarządzającą.
13	Zasilacze	Dwa redundantne zasilacze Hot Plug o mocy minimum 750 Wat każdy
14	Wentylatory	Minimum pięć wewnętrznych wentylatorów pracujących w trybie fault tolerant.
15	Karta zarządzająca	Niezależna od zainstalowanego systemu operacyjnego, zintegrowana z płytą główną posiadająca port RJ45 lub jako dodatkowa karta rozszerzeń (Zamawiający dopuszcza zastosowanie karty instalowanej w slocie PCI Express jednak nie może ona powodować zmiejszenia minimalnej ilości wymaganych slotów w serwerze), posiadająca minimalną

		funkcjonalność : - komunikacja poprzez dedykowany interfejs RJ45 - podstawowe zarządzanie serwerem poprzez protokół IPMI 2.0, SNMP, VLAN tagging - wbudowana diagnostyka - wbudowane narzędzia do instalacji systemów operacyjnych - dostęp poprzez interfejs graficzny Web karty oraz z linii poleceń - monitorowanie zasilania oraz zużycia energii przez serwer w czasie rzeczywistym z możliwością graficznej prezentacji - lokalna oraz zdalna konfiguracja serwera - zdalna instalacja systemów operacyjnych - wsparcie dla IPv4 i IPv6 - zapis zrzutu ekranu z ostatniej awarii - integracja z Active Directory - wirtualna konsola z dostępem do myszy i klawiatury - udostępnianie wirtualnej konsoli - autentykacja poprzez publiczny klucz (dla SSH) - możliwość obsługi poprzez dwóch administratorów równocześnie - wysyłanie do administratora powiadomienia o awarii lub zmianie konfiguracji sprzętowej - automatyczne przywracanie ustawień serwera, kart sieciowych, BIOS, wersji firmware w przypadku awarii i wymiany któregoś z komponentów (w tym kontrolera RAID, kart sieciowych, płyty głównej) zapisanych na dedykowanej pamięci flash wbudowanej na karcie zarządzającej - możliwość partycjonowania wbudowanej pamięci flash na minimum dwie partycje po 4GB każda
16	Certyfikaty	Serwer musi być wyprodukowany zgodnie z normą ISO-9001 oraz ISO-14001 Serwer musi posiadać deklaracja CE (dokument załączyć do oferty) Oferowany sewer musi znajdować się na liście Windows Server Catalog i posiadać status „Certified for Windows” dla systemów Microsoft Windows Server 2008 R2 x64, x86, Microsoft Windows Server 2012 oraz Microsoft Hyper-V Zgodność z systemami SUSE Linux Enterprise Server, RedHat Enterprise Linux, Citrix XenServer, VMware vSphere.
17	Gwarancja	Pięć lat gwarancji realizowanej w miejscu instalacji sprzętu, z czasem reakcji do następnego dnia roboczego od przyjęcia zgłoszenia, możliwość zgłaszania awarii w trybie 24x7x365 poprzez ogólnopolską linię telefoniczną producenta. W przypadku awarii, diagnostyka przeprowadzona w miejscu instalacji przez pracownika autoryzowanego serwisu producenta. W przypadku awarii, dyski twarde pozostają własnością Zamawiającego. Do oferty należy załączyć oświadczenie producenta serwera o spełnieniu tego warunku. Firma serwisująca musi posiadać ISO 9001:2000 na świadczenie usług serwisowych oraz posiadać autoryzacje producenta serwera – dokumenty potwierdzające załączyć do oferty. Oświadczenie producenta serwera, że w przypadku nie wywiązywania się z obowiązków gwarancyjnych oferenta lub firmy serwisującej, przejmie na siebie wszelkie zobowiązania związane z serwisem – dokumenty potwierdzające załączyć do oferty. Możliwość telefonicznego i elektronicznego sprawdzenia konfiguracji sprzętowej serwera oraz warunków gwarancji po podaniu numeru seryjnego bezpośrednio u producenta oraz poprzez stronę internetową producenta lub jego przedstawiciela. Dokumentacja dostarczona wraz z serwerem dostępna w języku polskim.
18	System operacyjny	Zainstalowany system musi być zgodny ze specyfikacją oferowanego serwera sprzętowego i umożliwiać obsługę co najmniej 192 GB pamięci RAM. - System musi automatycznie weryfikować cyfrowe sygnatury sterowników w celu sprawdzenia, czy sterownik przeszedł testy jakości przeprowadzone przez producenta systemu. - System musi mieć możliwość dynamicznego obniżania poboru energii przez rdzenie procesora/ów nie wykorzystywane w bieżącej pracy. - System musi być wyposażony w mechanizmy klasyfikowania i indeksowania plików w oparciu o ich zawartość. - System musi umożliwiać uruchamianie aplikacji internetowych wykorzystujących technologię XXX.XXX. - System musi umożliwiać automatyczną aktualizację w oparciu o poprawki publikowane przez producenta. - System musi umożliwiać zmianę języka interfejsu i posiadać minimum języki angielski i polski. - System musi być objęty polskojęzycznym cyklem szkoleń i zestawem materiałów szkoleniowych. - System musi posiadać polskojęzyczne wsparcie producenta systemu. - System musi mieć możliwość uruchomienia serwerów usług sieciowych takich jak WWW, DNS i DHCP.

oju o

		- System musi posiadać możliwość uruchomienia kontrolera usług katalogowych. - System musi umożliwiać pracę terminalową użytkownikom na zasadzie licencji dostępowych. - licencja musi umożliwiać obsługę co najmniej dwóch procesorów fizycznych - wymagana obsługa minimum dwóch wirtualnych instancji w ramach jednej licencji - dołączony nośnik z wersją instalacyjną systemu operacyjnego
19	Instalacja i konfiguracja	- wymagana instalacja systemu operacyjnego na dostarczonym serwerze fizycznym w ramach tego postępowania - wymagana podstawowa konfiguracja systemu
20	Liczba licencji dostępowych	5 licencji umożliwiających dostęp użytkowników do serwera poprzez sieć

oju o

Macierz dyskowa – 1 szt.

LP	Parametr	Minimalne wymagania
1	Obudowa	- do instalacji w standardowej szafie RACK 19”. Wysokość maksymalnie 2U wraz z kompletem szyn do montażu w szafie Rack. - dodatkowy przedni panel zamykany na klucz chroniący dyski twarde przed nieuprawnionym wyjęciem z macierzy.
2	Kontrolery	- dwa kontrolery posiadające łącznie minimum osiem portów SAS 6Gb/s do podłączenia serwerów pracujące w trybie active-active. Wymagane poziomy RAID 0,1,5,6,10. W komplecie 4 sztuki kabli SAS do podłączenia serwerów o dł. min. 2 m każdy.
3	Cache	Min. 2 GB na kontroler, pamięć cache zapisu mirrorowana między kontrolerami, z opcją zapisu na dysk lub inną pamięć nieulotną lub podtrzymywana bateryjnie przez min. 72h w razie awarii
4	Dyski	Zainstalowane dyski : 3 dyski 600GB SAS 15k RPM Hot-Plug 3.5” każdy 3 dyski 2TB NL SAS 7.2k RPM Hot-Plug 3.5” każdy Możliwość rozbudowy przez dokładanie kolejnych dysków/półek dyskowych, możliwość obsługi łącznie minimum 190 dysków, wydajnych dysków SAS,SSD, ekonomicznych dysków typu SATA (lub NearLine SAS), samoszyfrujących dysków SED dostepnych w ofercie producenta macierzy, możliwość mieszania typów dysków w obrębie macierzy oraz półki.
5	Oprogramowanie	- zarządzające macierzą w tym powiadamianie mailem o awarii, umożliwiające maskowanie i mapowanie dysków. - dodatkowa licencja pozwalającą na utworzenie minimum 512 LUN’ów oraz 32 kopii migawkowych na LUN - licencja macierzy powinna umożliwiać podłączanie minimum 32 hostów bez konieczności zakupu dodatkowych licencji. - producent macierzy musi udostępniać wszystkie licencje w trybie testowym by umożliwić użytkownikowi sprawdzenia poszczególnych płatnych funkcjonalności w/w macierzy - obsługa wielu protokołów i interfejsu użytkownika opartego o język Java - oprogramowanie do graficznej obsługi wielu ścieżek zapewniających awaryjne przełączanie nadmiarowych ścieżek danych między serwerem a macierzą pamięci masowej
6	Wsparcie dla systemów operacyjnych	MS Windows 2003/ 2008, RedHat Enterprise Linux, SUSE Linux.
7	Bezpieczeństwo	Ciągła praca obu kontrolerów nawet w przypadku zaniku jednej z faz zasilania. Zasilacze, wentylatory, kontrolery RAID redundantne. Możliwość przydzielenia większej przestrzeni dyskowej dla serwerów niż fizycznie dostępna (Thin Provisioning)
8	Zasilacz	redudantny
9	Inne	Możliwość podłączenia czterech serwerów ze skonfigurowanymi funkcjami wysokiej dostępności (HA) lub ośmiu serwerów bez technologii HA
9	Warunki gwarancji dla macierzy	Wymagane pięć lat gwarancji od momentu podpisania umowy z czasem reakcji do następnego dnia roboczego od zgłoszenia awarii. W przypadku awarii dyski twarde pozostają własnością Zamawiającego. Firma serwisująca musi posiadać ISO 9001:2000 na świadczenie usług serwisowych oraz posiadać autoryzacje producenta – dokumenty potwierdzające załączyć do oferty. Oświadczenie producenta, że w przypadku nie wywiązywania się z obowiązków gwarancyjnych oferenta lub firmy serwisującej, przejmie na siebie wszelkie zobowiązania związane z serwisem – dokumenty potwierdzające załączyć do oferty.
10	Dokumentacja użytkownika	Zamawiający wymaga dokumentacji w wersji elektronicznej i drukowanej w języku polskim.
11	Certyfikaty	Macierz musi być wyprodukowana zgodnie z normą ISO 9001. Oświadczenie producenta oferowanego serwera o poprawnej współpracy z zaoferowaną macierzą

Zapora sieciowa – 1 szt.

Dostarczony system bezpieczeństwa musi zapewniać wszystkie wymienione poniżej funkcje bezpieczeństwa oraz funkcjonalności niezależnie od dostawcy łącza. Dopuszcza się aby elementy wchodzące w skład systemu ochrony były zrealizowane w postaci zamkniętej platformy sprzętowej lub w postaci komercyjnej aplikacji instalowanej na platformie ogólnego przeznaczenia. W przypadku implementacji programowej dostawca powinien zapewnić niezbędne platformy sprzętowe wraz z odpowiednio zabezpieczonym systemem operacyjnym.

oju o

Dla elementów systemu bezpieczeństwa obsługujących Zamawiającego, Wykonawca zapewni wszystkie poniższe funkcjonalności.

LP	Parametr	Minimalne wymagania
1	Funkcjonalność	1. Możliwość łączenia w klaster Active-Active lub Active-Passive każdego z elementów systemu. 2. Monitoring i wykrywanie uszkodzenia elementów sprzętowych i programowych systemów zabezpieczeń oraz łączy sieciowych. 3. Monitoring stanu realizowanych połączeń VPN oraz automatyczne przekierowanie pakietów zgodnie z trasą definiowaną przez protokół OSPF. 4. System realizujący funkcję Firewall powinien dawać możliwość pracy w jednym z dwóch trybów: Routera z funkcją NAT lub transparent. 5. System realizujący funkcję Firewall powinien dysponować minimum 18 portami Ethernet 10/100/1000 Base-TX . 6. Możliwość tworzenia min 230 interfejsów wirtualnych definiowanych jako VLANy w oparciu o standard 802.1Q. 7. W zakresie Firewall’a obsługa nie mniej niż 2,1 milionów jednoczesnych połączeń oraz 22 tys. nowych połączeń na sekundę 8. Przepustowość Firewall’a: nie mniej niż 1 Gbps. Wydajność szyfrowania AES lub 3DES: nie mniej niż 400 Mbps 9. W ramach dostarczonego systemu ochrony muszą być realizowane wszystkie z poniższych funkcjonalności. Poszczególne funkcjonalności systemu bezpieczeństwa mogą być realizowane w postaci osobnych platform sprzętowych lub programowych: ✓ kontrola dostępu - zapora ogniowa klasy Stateful Inspection ✓ ochrona przed wirusami – antywirus [AV] (dla protokołów SMTP, POP3, IMAP, HTTP, FTP, HTTPS). W celu zapewnienia wysokiej skuteczności mechanizmu antywirusowego wymaga się aby mechanizm skanowania działał w oparciu o technologię proxy. umożliwiającą analizę dowolnego typu załączników ✓ poufność danych - połączenia szyfrowane IPSec VPN oraz SSL VPN ✓ ochrona przed atakami - Intrusion Prevention System [IPS] ✓ kontrola stron internetowych pod kątem rozpoznawania witryn potencjalnie niebezpiecznych: zawierających złośliwe oprogramowanie, stron szpiegujących oraz udostępniających treści typu SPAM. ✓ kontrola zawartości poczty – antyspam [AS] (dla protokołów SMTP, POP3, IMAP) ✓ kontrola pasma oraz ruchu [QoS, Traffic shaping] ✓ Kontrola aplikacji oraz rozpoznawanie ruchu P2P ✓ Możliwość analizy ruchu szyfrowanego protokołem SSL ✓ Ochrona przed wyciekiem poufnej informacji (DLP) z funkcją archiwizowania informacji na lokalnym dysku 10. Wydajność skanowania ruchu w celu ochrony przed atakami (IPS) min 700 Mbps 11. Wydajność całego systemu bezpieczeństwa przy skanowaniu strumienia danych z włączoną funkcją: Antivirus, min. 600 Mbps 12. W zakresie realizowanych funkcjonalności VPN, wymagane jest nie mniej niż: ✓ Tworzenie połączeń w topologii Site-to-site oraz Client-to-site ✓ Producent oferowanego rozwiązania VPN powinien dostarczać klienta VPN współpracującego z proponowanym rozwiązaniem. ✓ .Monitorowanie stanu tuneli VPN i stałego utrzymywania ich aktywności ✓ Praca w topologii Hub and Spoke oraz Mesh ✓ Możliwość wyboru tunelu przez protokół dynamicznego routiongu, np. OSPF ✓ Obsługa mechanizmów: IPSec NAT Traversal, DPD, XAuth 13. Rozwiązanie powinno zapewniać: obsługę Policy Routingu, routing statyczny i dynamiczny w oparciu o protokoły: RIPv2, OSPF, BGP oraz PIM. Protokoły routingu powinny funkcjonować w ramach terminowanych na urządzeniu połączeniach IPSec VPN. 14. Możliwość budowy min 2 oddzielnych (fizycznych lub logicznych) instancji systemów bezpieczeństwa w zakresie routingu, Firewall’a, Antywirus’a, IPS’a, Web Filter’a. 15. Translacja adresów NAT adresu źródłowego i NAT adresu docelowego. 16. Polityka bezpieczeństwa systemu zabezpieczeń musi uwzględniać adresy IP, interfejsy, protokoły, usługi sieciowe, użytkowników, reakcje zabezpieczeń, rejestrowanie zdarzeń

		oraz zarządzanie pasmem sieci (x.xx. pasmo gwarantowane i maksymalne, priorytety) 17. Możliwość tworzenia wydzielonych stref bezpieczeństwa Firewall np. DMZ 18. Silnik antywirusowy powinien umożliwiać skanowanie ruchu w obu kierunkach komunikacji dla protokołów działających na niestandardowych portach (np. FTP na porcie 2021) 19. Ochrona IPS powinna opierać się co najmniej na analizie protokołów i sygnatur. Baza wykrywanych ataków powinna zawierać co najmniej 5000 wpisów. Ponadto administrator systemu powinien mieć możliwość definiowania własnych wyjątków lub sygnatur. Dodatkowo powinna być możliwość wykrywania anomalii protokołów i ruchu stanowiących podstawową ochronę przed atakami typu DoS oraz DDos. 20. Funkcja Kontroli Aplikacji powinna umożliwiać kontrolę ruchu na podstawie głębokiej analizy pakietów, nie bazując jedynie na wartościach portów TCP/UDP 21. Baza filtra WWW o wielkości co najmniej 45 milionów adresów URL pogrupowanych w kategorie tematyczne. W ramach filtra www powinny być dostępne takie kategorie stron jak: spyware, malware, spam, proxy avoidance. Administrator powinien mieć możliwość nadpisywania kategorii oraz tworzenia wyjątków i reguł omijania filtra WWW. 22. Automatyczne aktualizacje sygnatur ataków, aplikacji , szczepionek antywirusowych oraz ciągły dostęp do globalnej bazy zasilającej filtr URL. 23. System zabezpieczeń musi umożliwiać wykonywanie uwierzytelniania tożsamości użytkowników za pomocą nie mniej niż: ✓ Haseł statycznych i definicji użytkowników przechowywanych w lokalnej bazie systemu ✓ haseł statycznych i definicji użytkowników przechowywanych w bazach zgodnych z LDAP ✓ haseł dynamicznych (RADIUS, RSA SecurID) w oparciu o zewnętrzne bazy danych ✓ Rozwiązanie powinno umożliwiać budowę architektury uwierzytelniania typu Single Sign On w środowisku Active Directory bez konieczności instalowania jakiegokolwiek oprogramowania a kontrolerze domeny. 24. Poszczególne elementy oferowanego systemu bezpieczeństwa powinny posiadać następujące certyfikaty: ✓ ICSA dla funkcjonalności SSLVPN, IPS, Antywirus ✓ ICSA lub EAL4 dla funkcjonalności Firewall 25. Elementy systemu powinny mieć możliwość zarządzania lokalnego (HTTPS, SSH) jak i współpracować z dedykowanymi do centralnego zarządzania i monitorowania platformami wchodzącymi w skład systemu. Komunikacja systemów zabezpieczeń z platformami zarządzania musi być realizowana z wykorzystaniem szyfrowanych protokołów.
2	Serwis, szkolenia i gwarancje	1. gwarancja 12 miesięcy, 2. subskrypcje oprogramowania i serwisu na okres: 12 miesięcy; 3. serwis logistyczny na terenie Polski z dostawą urządzenia zastępczego na drugi dzień roboczy od chwili zgłoszenia awarii – 7x24; 4. szkolenie w języku polskim na poziomie profesjonalnym w siedzibie klienta z zakresu obsługi i konfiguracji systemu 5. oferent musi posiadać co najmniej trzech certyfikowanych inżynierów w zakresie obsługi oferowanego sprzętu; 6. Instalacja oraz konfiguracja sprzętu niezależnie od struktury i rozległości lokalizacji komputerów objętych ochroną 7.Wykaz 5 dostaw na podobne urządzenia, wykonanych w okresie ostatnich trzech lat przed dniem wszczęcia postępowania o udzielenie zamówienia, a jeżeli okres prowadzenia działalności jest krótszy - w tym okresie, odpowiadających swoim rodzajem dostawom stanowiącym przedmiot zamówienia, z podaniem ich wartości, daty, miejsca wykonania oraz dokumentów potwierdzających, że te dostawy zostały wykonane należycie.

oju o

Centralny zasilacz awaryjny UPS – 1 szt.

LP	Parametr	Minimalne wymagania
1	Obudowa	Max. 4U do instalacji w szafie Rack posiadająca graficzny wyświetlacz LCD
2	Moc rzeczywista	4 200 Watt
3	Moc pozorna	6 000 VA
4	Zakres napięcia wejściowego	220V – 240V
5	Czas przełączenia na baterie	0 ms
6	Gniazda wyjściowe	Oferowane urządzenie powinno zapewnić możliwość podłączenia i podtrzymania wszystkich urządzeń objętych niniejszym postępowaniem + min. 2 wolne gniazda
7	Czas podtrzymania	przy obciążeniu 100% / 50% : min. 3 min / min. 11 min
9	Czas pełnego	Max 2,5 godz.

	ładowania
10	Funkcjonalność	- automatyczna regulacja napięcia AC (AVR) - wbudowana karta do zarządzania zasilaczem poprzez sieć LAN - ręczny i automatyczny bypass wewnętrzny - sinusoidalny przebieg napięcia wyjściowego bez względu na charakter obciążenia
11	Porty komunikacyjne	- 1xRS232 (DB9) - 1x10/100BaseTX (RJ45)
12	Gwarancja	60 miesięcy

Szafa xxxxxxxxx 00X z wyposażeniem, KVM z monitorem i klawiaturą – 1 szt.

LP	Parametr	Minimalne wymagania
1	Ilość miejsc U	min. 42
2	Szerokość	800 mm
3	Głębokość	1000 mm
4	Waga	nie przekraczająca 150 kg
5	Nośność	600 kg
6	Drzwi przednie	- podwójne, - wklejona w ramę (z blachy stalowej) drzwi szyba hartowana
7	Inne	- zabezpieczenie min. IP 20, - rama spawana z profili stalowych gr. 1,5 mm ustawiana na 4 nóżkach samopoziomujących , - drzwi przednie z możliwością montażu prawo i lewostronnego z zamkiem trzypunktowym z klamką, zamontowane na zawiasach umożliwiających otwarcie drzwi o 180o, - ściana tylna z blachy stalowej o gr. 1 mm zdejmowana , mocowana przy pomocy dwóch zamków jednopunktowych - ściany boczne perforowane z blachy stalowej o gr. 1 mm zdejmowane, mocowane przy pomocy dwóch zamków jednopunktowych, - w dachu i podłodze po dwa otwory 8U pod zainstalowanie paneli wentylacyjnych oraz po dwa otwory 2U szer. 450 mm do wprowadzania kabli, - cztery pionowe profile montażowe 19” z blachy ocynkowanej numerowane co 1U, - kolor szary RAL 7035
8	Instalacja	- szafa kompletnie zmontowana i uziemiona w miejscu wskazanym przez Zamawiającego - w szafie muszą zostać zainstalowane wszystkie dostarczone akcesoria tj. listwy zasilające, półki, organizery.
9	Gwarancja	60 miesięcy
10	KVM	- min. 8 portów wraz z odpowiednią ilością kabli umożliwiającą podłączenie serwerów do wszystkich dostępnych portów, - obsługiwana rozdzielczość 16:10 – 1680x1050, 4:3 – 1600x1200, - możliwość instalacji w szafie rack, - min. 4 złącza USB 2.0, - w komplecie monitor LCD umożliwiający instalację w szafie rack, wysokość 1U, przekątna ekranu min. 17”, - zintegrowana klawiaturą w standardzie QWERTY z touchpadem, - zarządzanie min. ośmioma serwerami - gwarancja - 60 miesięcy

oju o

Przełącznik sieciowy Ethernet – 2 szt.

LP	Parametr	Minimalne wymagania
1	Ilość portów	48 portów 10/100/10000 Gigabit Ethernet, 2x sloty SFP+ obsługujące moduły światłowodowe 10Gb oraz 1 Gb minimum 2potry HDMI (typ A) wspierające łączenie w stos (w komplecie kabel HDMI i długości min. 1m do połączenia w stos)
2	Wymiar, zasilanie	19 cali – do montażu w szafie rackowej, wysokość max 1 U, dodatkowy redundantny zasilacz
3	Inne	✓ Stakowalny do minimum 8 urządzeń w stosie HA ✓ Prędkość transmisji w stosie – min 40Gb ✓ Tablica MAC 16000 ✓ Packet Buffer 12 Mb ✓ 16 Routes (static) ✓ Forwarding Rate 100 Mpps ✓ Switching fabric 176 Gbps ✓ Jumbo frame 9k ✓ 256 grup multicast

		✓ Obsługa IPv4 oraz IPv6 ✓ 802.1Q VLAN – minimum 4000 ✓ ACL – minimum 3000 wpisów ✓ Typowe opóźnienie 2,8 ms
4	Zarządzanie, zabezpieczenia	Połączenie szyfrowane: SSL 3.0 oraz SSH, autentykacja dostępu w oparciu o Radius oraz na podstawie MAC adresu, listy dostępu; RMON, CLI, SNMP v3
5	Warunki gwarancji	✓ Dożywotnia podstawowa gwarancja, przyjmowanie zgłoszeń w trybie 24x7. ✓ Firma serwisująca musi posiadać ISO 9001:2000 na świadczenie usług serwisowych oraz posiadać autoryzacje producenta – dokumenty potwierdzające załączyć do oferty. ✓ Oświadczenie producenta, że w przypadku nie wywiązywania się z obowiązków gwarancyjnych oferenta lub firmy serwisującej, przejmie na siebie wszelkie zobowiązania związane z serwisem producenta – dokumenty potwierdzające załączyć do oferty.
6	Dokumentacja użytkownika	Zamawiający wymaga dokumentacji w wersji elektronicznej i drukowanej w języku polskim

Mata antyelektrostatyczna

Mata jest przeznaczona do wyłożenia w pomieszczeniu o powierzchni 9 m2, w którym znajduje się obecnie centrala telefoniczna, serwery i węzeł sieci lokalnej, a w najbliższym czasie zostaną zamontowane urządzenia będące przedmiotem niniejszego postępowania. Wymiary pomieszczenia 3 m x 3 m. Podstawowym zadaniem maty będzie odprowadzanie ładunków elektrostatycznych przy jednoczesnym zapewnieniu antypoślizgowości.

LP	Parametr	Minimalne wymagania
1	Materiał	Guma winylowa
2	Kolor	Czarny
3	Powierzchnia	nie gładka (fakturowa)
4	Klasyfikacja pożarowa	Cfl-s1, według DIN EN13501-1
5	Spełnia wymagania norm	- IEC61340-4-1 (kategoria DIF), zmierzona rezystancja Rg 106 - 109 Ω, Rp 106 - 109 Ω. - Ładunek elektrostatyczny (test chodzenia), spełnia wymagania norm ISO6356 i EN1815.
6	Uwagi	- Mata musi być wyposażona w gniazdko umożliwiające podłączenie jej do punktu uziemienia. - Zamawiający wymaga, aby po dostarczeniu mata została wyłożona i podpięta do uziemienia we wskazanym pomieszczeniu. - Należy tak dopasować poszczególne elementy maty, aby tworzyły jednolitą powierzchnię.
7	Gwarancja	min. 12 m-cy

Klimatyzator do serwerowni – 1 szt.

Pomieszczenie o powierzchni 9 m2, w którym znajduje się centrala telefoniczna, serwery i węzeł sieci lokalnej, i zostaną zamontowane urządzenia będące przedmiotem niniejszego postępowania. Wymiary pomieszczenia 3 m x 3 m. Wysokość pomieszczenia 2,70 m

LP	Parametr	Minimalne wymagania
1	Typ urządzenia	Split – inwerter
2	Wydajność chodzenia	5,3 kW
3	Wydajność grzania	5,8 kW
4	Tryby pracy	- chłodzenie - grzanie - cyrkulacja - osuszanie
5	Zdalne sterowanie	pilot
6	Gwarancja	min. 24 miesiące przy zachowaniu obowiązkowych przeglądów serwisowych
7	Instalacja	wymagana kompletna instalacja w miejscu wskazanym przez Zamawiającego.

oju o

Drukarka kodów – 1 szt.

LP	Parametr	Minimalne wymagania
1	Rodzaj druku	termiczny lub termotransferowy
2	Rozdzielczość druku	203 dpi
3	Maksymalna prędkość druku	102 mm/s

4	Szerokość druku	104 mm
5	Maksymalna długość druku	990 mm
6	Minimalna szerokość etykiety	19 mm
7	Interfejsy komunikacyjne	USB, LAN
8	Gwarancja	12 miesięcy

Czytnik kodów – 5 szt.

LP	Parametr	Minimalne wymagania
1	Typ czytnika	diodowy
2	Zasięg odczytu	do 21 cm
3	Prędkość skanowania	256 skanów na sekundę
4	Odczytywane kody kreskowe	1D: 21D: 2/5 family, Code39 (plus Code32, Cip39),EAN/UPC, EAN128, Code 128, Code 93, CODABAR, TTELEPEN,PLESSEY, Code 49, Code MSI, Code Delta IBM, Code 11, Code 16K, ISBN/ISSN, ISBT128, RSS
5	Interfejsy	USB, PS2 lub RS232
6	Gwarancja	60 miesięcy

Cześć dotycząca zamawianych modułów wchodzących w skład Zintegrowanego Systemu Informatycznego

A. Wymagania ogólne

I. Wymagania wobec technologii

1) wszystkie dane w systemie są obsługiwane w relacyjnej transakcyjnej bazie danych w wersji komercyjnej jak i darmowej, umożliwiającej dostęp do danych za pomocą języka zapytań SQL;

2) system musi być zbudowany w architekturze otwartej, umożliwiającej późniejszą integrację z innymi systemami informatycznymi;

3) posiadanie polskojęzycznego interfejsu użytkownika oraz polskojęzyczne wartości danych przechowywanych w systemie (sortowanie, reprezentacja dat, liczb);

4) system zapewni kontrolę wprowadzanych danych oraz pomoc dla użytkownika.

II. Wymagania dotyczące bezpieczeństwa

1) zakładanie nowych użytkowników systemu (bez ograniczeń) i modyfikacja istniejących;

2) nadawanie identyfikatora użytkownika;

3) identyfikator użytkownika, który utracił uprawnienia do przetwarzania danych, nie może być

przydzielony innej osobie;

4) rejestracja daty założenia;

5) wprowadzanie i modyfikacja opisu użytkownika systemu;

6) ustawianie i zmiana hasła; definiowanie i modyfikacja czasu ważności hasła,;, definiowanie

oju o

7) liczby nieudanych prób zalogowania, definiowanie złożoności hasła (co najmniej z 8 znaków, zawiera małe i wielkie litery oraz cyfry lub znaki

8) wymuszanie zmiany hasła przy pierwszym zalogowaniu do bazy danych;

9) blokowanie i odblokowywanie konta użytkownika;

10) przydzielanie podsystemów - nadawanie i odbieranie uprawnień do modułów;

11) możliwość generowania zestawień typu: ewidencja użytkowników systemu, lista użytkowników wybranego systemu;

12) wykonywanie kopii zapasowych bazy danych, automatyzacja wykonywania kopii (z poziomu serwera SQL),

13) możliwość definiowania harmonogramu wykonywania kopii (z poziomu serwera SQL).

Dla dostarczonego oprogramowania należy dostarczyć:

a) licencje,

b) nośniki instalacyjne.

B. Podstawowe funkcjonalności pakietów wchodzących w skład Zintegrowanego Systemu Informatycznego

Pakiet portalu e- Kętrzyn

Stworzenie jednolitego systemu informacji polegać będzie na stworzeniu dwóch struktur –

portalu zewnętrznego dla „klientów” Urzędu i portal wewnętrznego dla jej pracowników. Portal oparty będzie o system zarządzania treścią CMS, który pozwoli na dowolne profilowanie przekazywanych treści. Portal zewnętrzny to elektroniczna platforma umożliwiająca publikację i prezentację informacji z różnych dziedzin. Celem portalu jest zebranie w jednym miejscu informacji obejmującej różne aspekty działalności Urzędu. Aby informacja ta była łatwo dostępna, treści publikowane w portalu zostaną podzielone tematyczne. Portal zostanie zrealizowany jako serwis WWW dostępny publicznie w sieci Internet z wydzieleniem części ogólnie dostępnej dla użytkowników anonimowych oraz części dostępnej po uwierzytelnieniu użytkownika. Formatowanie publikowanych treści ma następować w oparciu o zdefiniowane szablony, zapewniające spójną prezentację informacji w całym Portalu. Administrator portalu będzie dysponował narzędziami umożliwiających zarządzanie publikowanymi dokumentami oraz przyznawanie uprawnień administratorom poszczególnych modułów tematycznych. Zadaniem portalu wewnętrznego będzie integracja informacji i usług dotyczących publikowanych tematów.

Interaktywność portalu pozwoli na wprowadzenie mechanizmów umożliwiających kontakt z odbiorcami przekazu. Będzie się to odbywać praktycznie na wszystkich płaszczyznach, od bazy informacji po udostępnienie forum wyrażania opinii oraz zastosowanie mechanizmów szybkiej konsultacji społecznej.

oju o

Portal „e-Kętrzyn” będzie odnosił się do co najmniej następujące usług:

✓ opis e-usług - procedur załatwiania spraw,

✓ dostęp do e-usług - formularzy interaktywnych umożliwiających załatwienie poszczególnych spraw,

✓ dostępną po zalogowaniu „strefę klienta” umożliwiającą dostęp do indywidualnych kont Płatniczych,

✓ e-konsultacje społeczne – możliwość dla mieszkańców zapoznania się z projektami najważniejszych przedsięwzięć planowanych przez władze miasta oraz wyrażenia swojego zdanie na ich temat.

I. Elektroniczny obieg dokumentów (EOD)

System umożliwiający zarządzanie korespondencją, dokumentami, projektami, poleceniami, terminami i czasem pracy pracowników, tworząca centralną, uporządkowaną bazę informacji oraz dokumentów. System zapewni pracownikom dostęp do umów, procedur wewnętrznych, korespondencji oraz dokumentów a także kontrolował będzie obieg dokumentów, stan realizacji procesów, usprawniając w ten sposób obsługę klientów. System posiadał będzie moduł zarządzania procesami pracy, który pozwoli na automatyzację działań zachodzących wewnątrz organizacji. System rozwiąże problem przepływu informacji, zarówno wewnątrz Urzędu jak również pomiędzy nimi interesantami. Przepływ informacji przedstawia poniższy rysunek.

Rysunek: Schemat elektronicznego systemu obiegu dokumentów

oju o

System zawierać ma rozbudowany moduł bezpieczeństwa zarządzający dostępem użytkowników zarówno do odpowiedniego typu dokumentów (grup dokumentów, teczek), jak i funkcji systemu. Dodatkowo system wykorzysta technologie PKI do podpisywania lub akceptacji

dokumentów. System zapewni zgodność formatu metadanych eksportowanych dokumentów ze standardem „e-PL” opracowanym przez Naczelną Dyrekcję Archiwów Państwowych oraz umożliwi automatyczne pobieranie korespondencji elektronicznej z sieci internetowej do wewnętrznej.

System elektronicznego obiegu dokumentów jest elementem niezbędnym do uruchomienia wirtualnego urzędu w którym interesant będzie mógł wnosić sprawy w sposób elektroniczny przez Internet. System umożliwiać będzie informowanie interesanta o stanie realizacji jego sprawy (wymóg ustawowy - ustawa o dostępie do informacji publicznej).

I. Wymagania funkcjonalne ogólne dla oprogramowania EOD

1) System posiadać powinien mechanizm ochrony i kontroli dostępu oraz zapewnienie bezpieczeństwa danych i ograniczenie dostępu na poziomie wewnętrznym, dostęp musi być strzeżony dla każdego użytkownika;

2) Wszystkie dane wprowadzone do systemu, jak ich usuwanie, są autoryzowane, a system umożliwia identyfikację osoby, która je wprowadziła i ustalenie daty wprowadzenia i modyfikacji danych;

3) Parametryzacja systemu a w tym: zawartości słowników i szablonów musi być możliwa do wykonania przez przeszkolonych administratorów, w każdym momencie eksploatacji; zapisy dotyczą zmian i tworzenia nowych elementów;

4) System musi posiadać możliwość wyszukiwania danych według różnych kryteriów w tym według fragmentów nazw i zakresów (dat, numerów);

5) System powinien umożliwiać export wybranych danych do 10 różnych formatów x.xx. edytora tekstu, arkusza kalkulacyjnego oraz do PDF;

6) System powinien posiadać mechanizmy kontroli zmian;

7) System musi umożliwiać definiowanie dowolnej ilości użytkowników;

8) System musi być w całości spolonizowany (nie dotyczy narzędzi administracyjnych do raportowania i analiz), a więc posiadać polskie znaki i instrukcję obsługi po polsku dla użytkownika oraz administratora;

9) System musi posiadać graficzny interfejs użytkownika gwarantujący wygodne wprowadzanie danych, przejrzystość prezentowania danych na ekranie oraz wygodny sposób wyszukiwania danych po dowolnych kryteriach;

10) System musi pracować w środowisku sieciowym i posiadać wielodostępność pozwalającą na równoczesne korzystanie z bazy danych przez wielu użytkowników;

oju o

11) System musi posiadać mechanizmy ochrony danych przed niepowołanym dostępem, nadawania uprawnień dla użytkowników do korzystania z modułów jak również do korzystania z wybranych funkcji;

12) System musi posiadać słowniki wewnętrzne, uprawniony użytkownik musi mieć możliwość ich rozbudowy jak i definiowania własnych.

13) System musi posiadać interfejs komunikacyjny umożliwiający współpracę z innymi systemami np. wykorzystanie usług sieciowych.

II. Wymagania szczegółowe dla systemu EOD

1) EOD musi spełniać wszystkie warunki określone dla systemu EZD w rozporządzeniu w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz.U. z 2011 r. Nr 14, poz. 67) i wszystkie jego funkcje będą działać zgodnie z tym rozporządzeniem.

2) EOD musi realizować pełną funkcjonalność przewidzianą przepisami prawa dla systemu EZD, co pozwoli jednostkom użytkującym ten EOD wykorzystywać go, jako podstawowy sposób dokumentowania przebiegu załatwiania i rozstrzygania spraw.

3) jeśli jakaś czynność kancelaryjna jest obsługiwana przez EOD (np. dołączenie dokumentu do sprawy), to struktura systemu musi umożliwiać wykonywanie wszystkich wariantów tego zadania dopuszczalnych instrukcją kancelaryjną (np. dołączenie praktycznie dowolnej ilości dokumentów do sprawy – tzn. liczby na tyle dużej, by w praktyce nie napotkać ograniczeń systemu). Zarówno liczba dopuszczalnych dokumentów jak i ich łączny rozmiar powinny być parametrami konfigurowalnymi systemu.

4) jeśli instrukcja kancelaryjna wprost wskazuje na możliwość automatyzacji jakiegoś zadania w systemie EZD, EOD powinien umożliwiać automatyzację tego zadania. Jeśli instrukcja kancelaryjna dopuszcza różne warianty jego wykonania, EOD powinien zapewniać pełną konfigurowalność sposobu wykonania tego zadania (np. w zakresie rozdziału przesyłek przychodzących, opatrywania przesyłek metadanymi, archiwizacji). EOD powinien także umożliwić konfigurowanie maksymalnej wielkości pliku załączanego do sprawy.

5) EOD musi umożliwić definiowanie i wykorzystywanie wartości domyślnych dla wybranych pól w formularzach opisujących przesyłki, pisma, dokumenty i sprawy oraz sposób ich przetwarzania, tam gdzie wykorzystanie ustawień domyślnych znacznie usprawni pracę. Ustalenie takiej konfiguracji powinno być możliwe zarówno globalnie dla całego systemu, jak i na poziomie stanowiska lub użytkownika

6) EOD musi pozwalać na dodawanie dowolnej liczby metadanych dla pism, spraw, teczek, interesantów, zadań (liczba, tekst, słownik, data i godzina, wartość z e-formularzy ePUAP) z możliwością wykorzystania ich:

a) na listach,

b) w raportowaniu

oju o

c) we wbudowanym edytorze tekstu, jako pola auto podstawialne

7) EOD będzie umożliwiał wykorzystanie skrótów klawiszowych do wywoływania często użytkowanych funkcji. EOD będzie zawierał zestaw predefiniowanych skrótów klawiszowych i umożliwi zdefiniowanie własnych (nadpisanie predefiniowanych i zdefiniowanie dodatkowych) na poziomie całego systemu.

8) EOD musi obsługiwać rejestrację przesyłek przychodzących w formie papierowej (składane osobiście, przysyłane pocztą) i elektronicznej (składane osobiście na nośnikach, przesyłane przez elektroniczną skrzynkę podawczą oraz pocztą elektroniczną) wraz z załącznikami zgodnie z wymogami Rozporządzenia w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz.U. z 2011 r. Nr 14, poz. 67).

9) w ramach procesu rejestracji przesyłek przychodzących w formie papierowej EOD musi umożliwić zeskanowanie (z poziomu interfejsu aplikacji) poszczególnych dokumentów, wchodzących w skład przesyłki.

10) EOD musi umożliwiać skanowanie wsadowe przesyłek (np. przychodzących pocztą).

11) EOD musi umożliwiać generowanie potwierdzenia przyjęcia przesyłki przychodzącej przez punkt kancelaryjny i opatrzonej kodem kreskowym.

12) EOD musi umożliwiać rejestrację przesyłek w wielu punktach kancelaryjnych.

13) EOD musi umożliwiać opatrywanie przesyłek przychodzących metadanymi zgodnie z obowiązującymi przepisami oraz dodatkowymi (konfigurowalny zakres), przy czym metadane powinny być, zesłownikowane co najmniej w zakresie rodzaju dokumentu, sposobu dostarczenia oraz danych teleadresowych.

14) EOD musi umożliwić odróżnienie, jednoznaczną identyfikację i odrębne przetwarzanie (np. niezależne udostępnianie) poszczególnych dokumentów, przechowywanych w postaci skanów, wchodzących w skład przesyłki, przy zachowaniu ich powiązania z przesyłką.

15) EOD musi umożliwić opcjonalne dodawanie przez użytkownika informacji opisujących poszczególne dokumenty, przesyłki lub sprawy w postaci notatek, zgodnie z Instrukcją Kancelaryjną.

16) dla dokumentów papierowych nie podlegających skanowaniu oraz dokumentów na nośnikach elektronicznych nie podlegających kopiowaniu do systemu EOD (wymaganie dotyczy zarówno całych przesyłek, jak i dokumentów wchodzących w skład przesyłki), EOD musi umożliwić sporządzenie metryki, zawierającej podstawowe informacje o dokumencie, (co najmniej – tytuł, identyfikator, notatka).

oju o

17) EOD musi umożliwić prawidłową obsługę przychodzącej poczty elektronicznej, zgodnie z wymogami przepisów w zakresie instrukcji kancelaryjnych (rejestracja w rejestrze przesyłek wpływających lub bezpośrednie dołączenie wiadomości z załącznikami do akt sprawy); w sposób niezależny od użytkowanego programu pocztowego.

18) EOD musi automatycznie pobierać przesyłki, które przyszły przez elektroniczną skrzynkę podawczą systemu ePUAP, i musi umożliwić ich rejestrację w systemie.

19) dla przesyłek, które przyszły przez elektroniczną skrzynkę podawczą systemu ePUAP, EOD musi umożliwić realizację rozdziału w sposób automatyczny (w zależności od kategorii usługi).

20) rozdział przesyłek przychodzących do właściwych komórek merytorycznych musi się odbywać poprzez przekazanie uprawnień do plików i informacji zawartych w systemie.

21) EOD musi umożliwić generowanie i drukowanie nalepek z kodami kreskowymi na dokumenty papierowe oraz nośniki i odnajdywanie na podstawie zeskanowanej nalepki odwzorowania cyfrowego bądź metryki danego dokumentu.

22) EOD musi umożliwić rejestrację obiegu (lokalizacja, czas przemieszczenia, użytkownik) dokumentów papierowych, (dla których istnieje odwzorowanie cyfrowe oraz dla których nie zostało ono wykonane) oraz nośników.

23) EOD musi umożliwić sporządzanie odwzorowań cyfrowych dokumentów poprzez skanowanie dostępne z poziomu aplikacji EOD, zgodnie z wymaganiami określonymi w instrukcji kancelaryjnej

24) EOD musi umożliwiać wykonanie OCR w języku polskim dla skanowanych dokumentów i jego wykorzystanie w późniejszym przetwarzaniu sprawy lub przeszukiwaniu pełnotekstowym dokumentów (dotyczy pisma maszynowego a nie odręcznego).

25) EOD musi umożliwić rejestrację, przechowywanie, procedowanie oraz dołączanie do akt sprawy dokumentów elektronicznych, dokumentów papierowych w postaci odwzorowań, jak również metryk (dla dokumentów papierowych nie skanowanych i elektronicznych na nośnikach).

26) EOD musi umożliwić wszczynanie, prowadzenie i załatwianie spraw, przechowywanie akt sprawy i prowadzenie spisów spraw zgodnie z obowiązującymi przepisami. EOD automatycznie musi nadawać znak sprawy i zapewnia jego zgodność z wymogami instrukcji kancelaryjnej.

27) EOD musi umożliwiać ręczne przenumerowanie sprawy wyłącznie w przypadkach dopuszczonych instrukcją kancelaryjną.

28) EOD musi umożliwić prowadzenie rejestrów kancelaryjnych, w tym rejestru przesyłek wpływających, wychodzących oraz pism wewnętrznych, definiowanie i prowadzenie dowolnych innych rejestrów kancelaryjnych dopuszczonych instrukcją kancelaryjną

29) EOD musi umożliwić numerację i klasyfikację pism oraz spraw w oparciu o JRWA zgodnie z instrukcją kancelaryjną

30) EOD musi od strony technicznej umożliwić stworzenie odrębnych podrzędnych EOD dla jednostek podległych, z odrębnym JRWA i odrębną hierarchią użytkowników.

oju o

31) EOD musi umożliwić i procedowanie i dekretację spraw oraz pism z wykorzystaniem mechanizmu procedowania według definiowalnych ścieżek (mechanizm przepływu pracy — workflow) w pełni zgodnie z instrukcją kancelaryjną.

32) EOD musi umożliwić akceptację dokumentów z wykorzystaniem mechanizmu procedowania według zdefiniowanych ścieżek (mechanizm przepływu pracy — workflow) w pełni zgodnie z instrukcją kancelaryjną. EOD obsługuje akceptację jedno – lub wielostopniową

33) akceptacja pism elektronicznych przeznaczonych do wysyłki musi się odbywać z wykorzystaniem podpisu elektronicznego zgodnie z wymogami prawa.

34) EOD musi umożliwić zapis projektów pism przekazywanych pomiędzy użytkownikami lub komórkami w trakcie załatwiania sprawy, a także zamieszczanie adnotacji odnoszących się do projektów pism.

35) EOD musi zapewnić prowadzenie i wydruk metryki sprawy zgodnie z obowiązującymi przepisami.

36) EOD musi umożliwić opisywanie spraw i akt sprawy metadanymi zgodnie z obowiązującymi przepisami.

37) EOD musi umożliwić dokumentowanie wyjęcia dokumentacji ze składu chronologicznego lub ze składu informatycznych nośników danych.

38) EOD ma umożliwiać wiązanie dowolnych dokumentów ze sobą oraz ze sprawami oraz dodawanie konfigurowalnych atrybutów (opisów, notatek) do tych powiązań.

39) EOD musi umożliwić sporządzanie i wydruk raportów, statystyk i zestawień, w szczególności wymaganych przepisami prawa. EOD umożliwi monitorowanie liczby spraw i terminowości ich załatwiania (globalnie, przez poszczególne komórki i osoby) w zadanych przedziałach czasu, także w podziale na kategorie spraw. Możliwość generowania raportów będzie zależna od uprawnień i będzie dotyczyła pracy osób i komórek podległych oraz pracy osoby sporządzającej raport.

40) EOD musi umożliwić sporządzenie raportu w postaci pliku .pdf, .xls, .rtf, .csv, .xml, .html,*.doc,

41) EOD musi umożliwić przeszukiwanie i sortowanie pism i spraw według złożonych kryteriów, w szczególności wg znaku sprawy, identyfikatora przesyłki, osoby lub komórki odpowiedzialnej, kategorii JRWA, dat wpłynięcia lub załatwienia, terminu załatwienia, statusu pisma lub sprawy, danych klienta urzędu, nadawcy, adresata.

42) EOD musi umożliwić użytkownikowi dostęp do: zestawienia spraw, za które jest odpowiedzialny, zestawienia aktualnych zadań wynikających z przepływu p racy (sprawy i korespondencja, w odniesieniu, do których użytkownik ma aktualnie coś do zrobienia), zestawienia korespondencji otrzymanej i wysłanej w podziale na korespondencję wewnętrzną i z podmiotami zewnętrznymi

43) EOD musi umożliwić pełnotekstowe przeszukiwanie dokumentów w obrębie wyszukanego wcześniej zbioru, w tym co najmniej dokumentów w formatach .txt, .pdf (zawierający tekst), rtf,

oju o

.doc, .docx.

44) EOD musi posiadać funkcję automatycznej wysyłki pism za potwierdzeniem odbioru przez platformę ePUAP.

45) EOD musi umożliwić automatyczną wysyłkę korespondencji pocztą elektroniczną poprzez pobranie adresu odbiorcy i wysłanie treści pisma w treści poczty oraz załączników w formie załączników do poczty.

46) EOD musi umożliwić odnotowanie wysyłki wszelkich przesyłek wychodzących w rejestrze i opatrzenie ich metadanymi zgodnie z przepisami. EOD będzie w miarę możliwości automatyzował te czynności.

47) EOD musi umożliwić generowanie korespondencji seryjnej i automatyzację jej wysyłki (do zdefiniowanych, konfigurowalnych grup odbiorców).

48) Pismo do wysyłki wygenerowane na podstawie e-szablonu musi być w formacie edytowalnym (co najmniej *.doc, *.odt, *.rtf).

49) EOD musi zapewnić automatyczne przejmowanie dokumentacji przez archiwum zakładowe po upływie okresu przewidzianego w instrukcji kancelaryjnej. Przejęcie dokumentacji musi polegać na przekazaniu archiwiście uprawnień do tej dokumentacji w systemie EOD i ograniczeniu uprawnień komórki merytorycznej, zgodnie z instrukcją kancelaryjną.

50) EOD musi posiadać dedykowane funkcje do udostępniania i wycofywania dokumentacji elektronicznej z archiwum zakładowego.

51) EOD musi posiadać funkcje wspierające proces porządkowania dokumentacji w archiwum zakładowym (wskazanie dokumentacji wymagającej uzupełnienia).

52) EOD musi realizować brakowanie akt elektronicznych oraz przekazanie akt do archiwum państwowego oraz musi umożliwić sporządzenie i przechowywanie odpowiedniej dokumentacji. EOD musi wspierać pracę archiwisty poprzez automatyczne typowanie dokumentacji do brakowania lub przekazania do archiwum państwowego (po upływie terminów związanych z danymi kategoriami archiwalnymi) oraz funkcjonalność automatycznych przypomnień

53) EOD musi zapewnić wsparcie dla procesu archiwizacji informatycznych nośników danych oraz dokumentów papierowych, dla których nie wykonano pełnego odwzorowania cyfrowego, w tym umożliwi:

a) sporządzanie spisu zdawczo-odbiorczego,

b) zapis miejsca ich przechowywania i kategorii archiwalnej,

c) wsparcie procedury brakowania akt, wypożyczeń oraz przekazania do archiwum państwowego poprzez odnotowywanie tych zdarzeń, sporządzanie i przechowywanie odpowiedniej dokumentacji.

54) ścieżki muszą dopuszczać rozwidlanie oraz łączenie się podścieżek (ścieżek w obrębie innych

oju o

ścieżek).

55) EOD musi umożliwić tworzenie i obsługę podścieżek, w szczególności musi umożliwić użytkownikowi procedującemu korespondencję lub sprawę zdefiniowanie podścieżki, która zaczyna się i kończy w jego węźle.

56) ścieżki mogą zawierać także warunki określone dla dokumentów XML wymaganych na dowolnym etapie sprawy (np. wariant ścieżki uruchamiany jest w zależności od zawartości jednego z pól wniosku).

57) EOD musi umożliwić import, eksport i wykorzystanie schematów ścieżek.

58) EOD musi zapewnić przydzielanie spraw i korespondencji, przekazanych na dane stanowisko, konkretnym użytkownikom, pracującym na tym stanowisku.

59) EOD musi umożliwić przekazywanie korespondencji/sprawy na stanowisko lub bezpośrednio do wskazanego Użytkownika.

60) EOD musi umożliwić ewidencjonowanie i wersjonowanie ścieżek obiegu.

61) EOD musi umożliwić podgląd ścieżki obiegu sprawy (w formie grafu).

62) EOD musi umożliwić procedowanie sprawy lub korespondencji trybem „ad hoc” poprzez określanie na bieżąco kolejnych stanowisk zajmujących się sprawą/korespondencją bez wykorzystywania uprzednio zdefiniowanych ścieżek procedowania sprawy/korespondencji. Użytkownik może przejść do trybu „ad hoc” w dowolnym momencie przetwarzania sprawy/korespondencji.

63) EOD musi umożliwić modelowanie ścieżek w narzędziu graficznym.

64) EOD musi umożliwić monitorowanie i kontrolę obiegu dokumentów z wykorzystaniem konfigurowalnych raportów, zestawień, statystyk i alertów – w zakresie pracy własnej oraz osób podległych.

65) EOD musi umożliwić przypisywanie (w ramach ścieżki lub „ad-hoc”) procesom i zadaniom terminów realizacji, monitorowanie terminowości ich realizacji, automatyczne konfigurowalne przypomnienia i alerty.

66) EOD musi posiadać funkcjonalność kalendarza i zadań (z terminami i priorytetami) oraz notatek dla użytkowników.

67) EOD musi umożliwić obsługę wielu kalendarzy z możliwością ich łącznego udostępniania w terminarzu użytkownika, włączania i wyłączania subskrypcji i podglądu wybranych kalendarzy.

68) dostęp do kalendarzy musi być regulowany przez system uprawnień do ich tworzenia, edycji, publikowania, podglądu i subskrypcji.

69) EOD musi umożliwiać definiowanie zdarzeń kalendarza i zadań dla innych osób oraz ich grup przez osoby uprawnione (np. przełożonego dla podwładnych).

oju o

70) kalendarz musi umożliwiać podgląd zadań w siatce o rozdzielczości, co najmniej 15 minut, zaś ich definiowanie z dokładnością do 5 minut.

71) EOD musi być wyposażony w funkcjonalność komunikatora tekstowego. Komunikator musi być wewnętrznym oprogramowaniem dla urzędu i nie może umożliwiać komunikacji z zewnętrznymi komunikatorami dostępnymi publicznie.

72) EOD musi umożliwić użytkownikowi podgląd przypisanych do niego spraw i korespondencji, z możliwością sortowania, filtrowania i przeszukiwania.

73) EOD musi umożliwić składanie i weryfikowanie podpisu elektronicznego na każdym dokumencie elektronicznym w dowolnej liczbie podpisów elektronicznych.

74) EOD musi przyjmować dokumenty elektroniczne złożone przez klientów za pośrednictwem platformy ePUAP i umożliwiać automatyczne kierowanie ich na właściwą ścieżkę zgodnie z e-usługą, której dotyczą

75) EOD musi umożliwiać doręczanie dokumentów poprzez ePUAP.

76) EOD musi być zintegrowany z ePUAP w zakresie słowników.

77) EOD musi integrować się edytorem aktów prawnych. Proces przygotowania i publikacji aktu prawnego musi obejmować przygotowanie wersji roboczej oraz jej akceptację, która może, lecz nie musi obejmować podpisanie aktu prawnego bezpiecznym podpisem elektronicznym weryfikowanym kwalifikowanym certyfikatem. Akt prawny jest po akceptacji automatycznie eksportowany do systemu zewnętrznego obsługującego publikację (dziennik urzędowy).

78) EOD musi umożliwić wprowadzanie zmian kadrowych, urlopów i zastępstw bez konieczności modyfikacji ścieżek procedowania i umożliwia przekazanie osobie zastępującej części lub całości uprawnień osoby zastępowanej. Uprawnienia muszą być przekazane na określony czas dat lub bezterminowo.

79) funkcjonalność obsługi zastępstw, zmian kadrowych i urlopów umożliwia ustalenie, która osoba faktycznie realizowała daną czynność w systemie (każdy z użytkowników zachowuje swoją tożsamość i działa w oparciu o swoje konto użytkownika).

80) EOD musi umożliwić ewidencjonowanie struktury instytucji oraz jej pracowników, które umożliwią przypisanie pracowników (osób) do stanowisk (funkcji).

81) EOD musi umożliwić definiowanie uprawnień, w tym delegowanie części lub całości posiadanych uprawnień.

82) EOD umożliwi zarządzanie uprawnieniami w oparciu o grupy uprawnień i grupy zasobów, jakich dotyczą. System uprawnień musi być zdolny do odzwierciedlenia uprawnień i odpowiedzialności poszczególnych urzędników, stosowany w jednostkach samorządu terytorialnego i wynikający z Instrukcji Kancelaryjnych oraz struktury stanowisk.

oju o

83) EOD musi umożliwić definiowanie sposobu logowania dla poszczególnych użytkowników i grup użytkowników. Dostępne muszą być, co najmniej następujące metody logowania: użytkownik/hasło, karta kryptograficzna, jednokrotne logowania przez domenę.

84) przy logowaniu EOD musi prezentować użytkownikowi informację o dacie i czasie ostatniego udanego logowania oraz ostatniego nieudanego logowania.

85) EOD musi także umożliwiać generowanie raportu dotyczącego logowań użytkownika (przez użytkownika i administratora) oraz wykrywać zachowania określone, jako podejrzane i uruchamiać konfigurowalne alerty w tym zakresie. Konfiguracja powinna dotyczyć tego, kto ma być informowany (np. użytkownik, administrator), w jakich przypadkach, w jakiej formie, (np. sms, mail, alert w systemie).

86) hasła są przechowywane w systemie w formie zaszyfrowanej i nie ma możliwości ich odtworzenia, lecz jedynie zresetowania. Po zresetowaniu hasła użytkownika przez administratora systemu zmusza użytkownika do zdefiniowania nowego hasła przy pierwszym logowaniu

87) EOD umożliwia administratorowi wymuszenie okresowej zmiany haseł (i zdefiniowanie odpowiedniego interwału czasowego) oraz wspiera wykrywanie kont nieużywanych poprzez odpowiednie alerty.

88) EOD musi umożliwić wykonywanie kopii bezpieczeństwa (backup) z wykorzystaniem dostarczonego, w tym celu sprzętu. EOD musi umożliwić automatyzację wykonywania backupu w określonych interwałach czasu lub pod określonymi warunkami i umożliwia ustawienie częstotliwości backupu. Zaoferowane rozwiązanie musi być zdolne do tworzenia kopii zapasowych (backupu) danych dokonywanych nie i rzadziej niż codziennie.

89) EOD powinien umożliwiać tworzenie backupu pełnego

90) zakres wartości w słownikach prowadzonych przez system powinien być konfigurowalny przez administratora lub pochodzić z rejestrów centralnych, (np. TERYT). Zmiana wartości w słownikach nie może powodować zmian w dokumentach sporządzonych z wykorzystaniem poprzednich wersji słowników.

91) EOD musi umożliwić prowadzenie książki teleadresowej interesantów i wspierać wykorzystywanie jej w procesie rejestracji i wysyłce przesyłek, tworzeniu pism, rejestracji spraw.

92) EOD musi umożliwiać tworzenie grup interesantów (np. poprzez dodatkowe atrybuty) na podstawie książki teleadresowej i z nią zsynchronizowanej. Grupy będą wykorzystywane do wyszukiwania i korespondencji seryjnej.

93) EOD musi umożliwić nadawanie i ograniczanie uprawnień do danych osobowych interesantów – osób fizycznych, zapewniając ochronę tych danych zgodnie z ustawą o ochronie danych osobowych (Dz. U. z 2004 r. nr 100, poz. 1024).

oju o

94) słowniki prowadzone i wykorzystywane w systemie muszą obejmować w szczególności: słownik dekretacji, słownik lokalizacji, słownik rodzajów nośników, słownik kategorii archiwalnych, JRWA.

95) EOD musi umożliwić zdefiniowanie dodatkowych metadanych do opisu spraw, akt sprawy, przesyłek wchodzących i wychodzących oraz dowolnych dokumentów.

96) EOD musi umożliwić zdefiniowanie dodatkowych słowników.

97) EOD musi posiadać wewnętrzny edytor, służący do sporządzania notatek, załączanych do akt sprawy.

98) EOD musi posiadać architekturę trójwarstwową.

99) EOD musi być w pełni transakcyjny i musi zabezpieczać dane przed zniszczeniem lub przypadkowym nadpisaniem w przypadku równoczesnego korzystania z tych danych przez wielu użytkowników.

100) EOD od strony technicznej musi zapewnić skalowalność w zakresie wydajności, pojemności oraz dołączania dodatkowych użytkowników i elementów infrastruktury sprzętowej.

101) EOD musi zapewnić możliwość rozbudowy warstw poprzez zwiększenie zasobów komputerów obsługujących warstwę poprzez rozbudowę pamięci, zwiększenie liczby procesorów, zwiększanie liczby maszyn oraz zwiększenie pojemności pamięci masowych.

102) EOD musi umożliwiać rozpraszanie repozytorium dokumentów w ramach jednego systemu elektronicznego obiegu dokumentów na wiele komputerów rozmieszczonych w różnych lokalizacjach geograficznych (np. budynki urzędu).

103) EOD musi cechować się interfejsem użytkownika opartym na intranetowych nowoczesnych rozwiązaniach: wykorzystywać menu, listy, formularze, przyciski, referencje (linki), itp.

104) wymaga się, aby interfejs użytkownika EOD stosował oznaczanie pól wymaganych na formularzu ekranowym w sposób wyróżniający te pola.

105) organizacja pracy w ramach interfejsu użytkownika EOD musi się opierać na zestawieniach podstawowych, prezentujących informacje znajdujące się w Systemie w formie syntetycznej, (jako podsumowania, listy, zestawienia, grupy opcji, itp.) oraz na zestawieniach szczegółowych, tworzonych przez EOD w sytuacji, gdy zachodzi potrzeba zaprezentowania wskazanej przez użytkownika jednostki danych np. konkretnego dokumentu elektronicznego, słownika parametrów systemowych, itp.

106) interfejs użytkownika EOD musi posiadać widok indywidualny, w ramach którego prezentowane będą tylko te składniki zawartości informacyjnej Systemu, za które odpowiedzialny jest węzeł struktury organizacyjnej, do którego przypisany jest dany użytkownik.

107) wymaga się, aby widok indywidualny zawierał odnośniki do zestawień udostępniających wszystkie zadania realizowane przez pracowników danego węzła struktury organizacyjnej, dla których to zadań:

oju o

a) termin zakończenia realizacji zadania już minął,

b) termin zakończenia realizacji zadania mija za określoną w konfiguracji systemowej liczbę dni kalendarzowych.

108) wymaga się, aby interfejs użytkownika zawierał informację o węźle struktury organizacyjnej, w którym aktualnie pracuje użytkownik.

109) wymaga się, aby była możliwość konfiguracji widoków indywidualnych np. wysokość wiersza listy zawierającej sprawy, dokumenty, zadania (najmniejsza, mała, średnia, największa).

110) wymaga się, aby była możliwość grupowania elementów (mechanizm drag&drop) na listach pism, spraw, zadań poprzez mechanizmy list przestawnych (grupowania zagnieżdżonego co najmniej do 20 poziomów). EOD musi umożliwiać zapamiętywanie zdefiniowanych grup dla konkretnego użytkownika.

111) wymaga się, aby była możliwość przechodzenia z własnych list dokumentów i spraw na listy wskazanych osób., do których podglądu dany użytkownik jest uprawniony.

112) wymaga się, aby była możliwość dowolnego ustawiania kolumn oraz zapamiętywania tych ustawień.

113) wymaga się, aby była możliwość wyświetlania bądź ukrywania kolumn na listach spraw, dokumentów, zadań.

114) wymaga się, aby była możliwość wykorzystania na listach spraw, dokumentów, zadań mechanizmów szybkiej filtracji po dowolnie wybranej kolumnie.

115) EOD musi posiadać mechanizm kontroli dostępu do usług pozwalający na dostęp do danej usługi ze względu na użytkownika oraz grupę (jednostkę organizacyjną) do której należy.

116) EOD musi rejestrować wszystkie czynności dostępu do usług i zasobów w systemie, w zakresie dostępu przez użytkowników oraz aplikacje współpracujące z EOD.

117) EOD musi być zgodny z przepisami prawa, obowiązującymi na dzień ostatecznego odbioru systemu oraz opublikowanymi aktami prawnymi z określoną datą wejścia w życie (nawet, jeżeli ta data jest po dniu ostatecznego odbioru systemu).

118) EOD musi umożliwić obsługę plików (dokumentów) w dowolnym formacie zgodnym z obowiązującymi przepisami prawa (pliki te są otwierane i modyfikowane przez użytkowników w odrębnych aplikacjach, jednak mogą być przedmiotem obiegu w EOD).

119) EOD musi posiadać wbudowany mechanizm zdalnej asysty technicznej pozwalający na wsparcie użytkowników systemu przez uprawnionych do tego administratorów.

120) EOD powinien współpracować z relacyjną bazą danych SQL w wersji komercyjnej oraz darmowej.

II. Elektroniczne Biuro Obsługi Interesanta (e-BOI)

1) E-BOI powinien wykorzystywać elementy architektury opartej na usługach (ang. Service- Oriented Architecture, SOA).

oju o

2) E-BOI powinien posiadać wbudowaną pomoc techniczną

3) E-BOI powinien integrować się z EOD na następującym poziomie:

a) karty usług,

b) wniosków do pobrania,

c) informacji na temat prowadzonych spraw (status, osoba prowadząca, dokumenty w sprawie),

d) konta Klienta (aktywacji dostępu do e-BOI z poziomu systemu EOD.

4) E-BOI powinien zapewniać komunikację z ESP x.xx. na poziomie e-formularzy i kart usług

5) E-BOI powinien umożliwiać założenie konta Klienta poprzez system EOD lub interfejs e-BOI dostępny przez stronę www. Konto powinno być wykorzystywane w celu uwierzytelniania Klienta celem dostępu np. do informacji na temat sprawy

6) E-BOI powinien rozróżniać Klientów na osoby fizyczne, osoby prawne i podmioty gospodarcze (firmy).

7) E-BOI powinien weryfikować adres e-mail Klienta poprzez link weryfikujący

8) E-BOI pozwala na ponowne wysłanie linku weryfikującego na konto e-mail Klienta (z poziomu panelu administratora).

9) E-BOI pozwala na zablokowanie konta Klienta (z poziomu panelu administratora).

10) E-BOI powinien pozwalać na uwierzytelnianie Klienta za pomocą certyfikatu podpisu elektronicznego i profilu zaufanego.

11) E-BOI pozwala na odzyskanie dostępu do konta Klienta.

12) E-BOI pozwala na zmianę hasła z poziomu konta Klienta.

13) E-BOI pozwala na zmianę danych adresowych Klienta z poziomu jego konta.

14) E-BOI pozwala na alfabetyczne przeszukiwanie treści kart usług.

15) E-BOI pozwala na przeszukiwanie kart usług według wydziałów urzędu.

16) E-BOI pozwala na podział kart usług według JRWA.

17) E-BOI pozwala na wyszukiwanie treści po opisie sprawy, po symbolu JRWA, po nazwie sprawy.

18) E-BOI powinien pozwalać na pobranie dokumentów powiązanych z kartami usług np. wniosków do pobrania.

19) E-BOI pozwala na udostępnienie (po uwierzytelnieniu Klienta) informacji o prowadzonej sprawie. E-BOI dostarcza następujących informacji:

a) status sprawy,

b) znak sprawy,

c) osoba prowadząca,

d) dokumenty w sprawie.

oju o

20) E-BOI musi integrować się z platformą ePUAP (obsługa profilu zaufanego).

21) E-BOI musi pozwalać na definiowanie wymagalności stosowania podpisu/profilu pod e- formularzami.

22) E-BOI powinien być wyposażony w bezpieczny moduł sprzętowy HSM (pracujący w trybie FIPS 140-2 poziom 3 po stronie wykonawcy).

23) E-BOI powinien być w stanie obsłużyć do 20 000 skrzynek kontaktowych

24) E-BOI ma zostać wyposażony w dedykowane repozytorium zintegrowane z repozytorium EOD.

25) E-BOI powinien pozwalać na zasilenie e-formularza danymi adresowymi z konta Klienta.

26) E-BOI powinien pozwalać na wypełnienie e-formularza i zapisanie go do kopii roboczych

27) E-BOI pozwala na przypisanie e-formularza roboczego do foldera roboczego.

28) E-BOI pozwala na usunięcie e-formularza roboczego.

29) E-BOI powinien pozwalać na wygenerowanie pliku PDF z zapisanego e-formularza

30) E-BOI powinien pozwalać na podpisanie wypełnionego formularza podpisem elektronicznym weryfikowanym certyfikatem kwalifikowanym lub profilem zaufanym

31) E-BOI ma pozwalać na odbiór decyzji elektronicznych zgodnie z ustawą z dnia 12 lutego 2010 r. o zmianie ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne oraz niektórych innych ustaw. W szczególności E-BOI umożliwi odbiór podpisanych pism urzędowych wg standardu XAdES-XL lub XAdES-A z użyciem klucza o długości co najmniej 2040 bitów.

32) E-BOI powinien generować UPO zgodne z ustawą z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne.

33) E-BOI ma pozwalać na zarządzanie e-formularzami, w tym:

a) dodawaniem, usuwaniem,

b) dodawaniem kolejnych wersji,

c) aktywowaniem/dezaktywowaniem,

d) definiowanie wymagalności podpisu,

e) definiowanie kwoty opłaty skarbowej w powiązaniu z systemem płatności elektronicznych.

34) E-BOI ma pozwalać na zarządzanie zaufanymi centrami certyfikacji

35) generowanie statystyk, co najmniej:

a) założone konta Klientów,

b) złożone wnioski w postaci plików,

c) złożone wnioski w postaci e-formularzy.

oju o

36) E-BOI powinien współpracować z relacyjną bazą danych SQL w wersji komercyjnej oraz darmowej

37) E-BOI powinien pozwalać na poprawną pracę w następujących przeglądarkach: Internet Explorer w wersji co najmniej 9, Firefox w wersji co najmniej 16, Opera w wersji, co najmniej 12, Chrome w wersji co najmniej 23, Safari w wersji co najmniej 6.

III. Pakiet do obsługi Rady Miasta (e-rada)

1) E-RADA usprawnia pracę Rady Miasta poprzez udostępnienie drogą internetową zasobów związanych z działalnością Rady Miasta oraz wsparcie procesu legislacyjnego.

2) E-RADA musi być zgodny z regulaminem Rady Miasta.

3) E-RADA ma umożliwiać radnym zdalny dostęp do:

a) projektów uchwał,

b) protokołów z posiedzeń,

c) projektów budżetu,

d) podjętych uchwał,

e) danych statystycznych i analiz.

4) E-RADA ma umożliwiać obieg ww. dokumentów w wersji elektronicznej oraz tworzenie wiadomości i zadań grupowych

5) E-RADA ma umożliwiać przekazywanie członkom Rady ww. dokumentów w wersji elektronicznej

6) E-RADA ma umożliwiać przesyłanie informacji i dokumentów przy pomocy poczty elektronicznej

7) E-RADA ma umożliwiać obsługę sesji Rady w tym również obsługę głosowań poprzez dedykowany formularz do tworzenia protokołu z sesji.

8) E-RADA ma umożliwiać potwierdzanie obecności radnych na sesjach Rady i na posiedzeniach poszczególnych komisji Rady Miasta.

9) E-RADA ma umożliwiać automatyczną prezentację wyników głosowania podczas posiedzenia. Wyświetlanie wyników głosowania ma odbywać się będzie z poziomu podglądu uchwały

10) E-RADA musi zapewniać dedykowane procesy obiegu dokumentów (workflow):

a) projekt aktu prawnego

b) tworzenie porządku obrad Rady Miasta

c) tworzenie porządku obrad komisji Rady Miasta

d) tworzenie protokołu z sesji Rady Miasta

e) tworzenie protokołu z posiedzenia komisji

f) tworzenie rocznego planu pracy Rady Miasta

oju o

g) zgłaszanie uwag do protokołu

h) interpelacja lub zapytanie

i) wniosek

j) skarga

k) informacja

l) pismo

11) E-RADA ma umożliwiać dodanie dokumentu zwierającego projekt aktu prawnego w dedykowanym formularzu przygotowywania porządku obrad Rady (lub komisji RM).

12) E-RADA ma umożliwiać gromadzenie i przechowywanie projektów aktów prawnych w dedykowanym zestawieniu w elektronicznym repozytorium.

13) E-RADA ma umożliwiać przesyłanie informacji (monitu) do wskazanych radnych (czyli zgodnie z przyznanymi uprawnieniami) o pojawieniu się nowego porządku obrad, do którego radny ma dostęp zgodnie z nadanymi mu uprawnieniami .mailem lub sms

14) E-RADA ma umożliwiać powiązanie wyników głosowania nad projektem aktu prawnego z dokumentem zawierającym dany akt prawny.

15) E-RADA ma umożliwiać tworzenie, zapis i archiwizację aktu prawnego w wersji elektronicznej. Archiwizacja ma odbywać się z poziomu modułu archiwizacji EOD.

16) E-RADA ma umożliwiać prowadzenie całości procesu związanego z obiegiem wersji elektronicznych dokumentów skierowanych do radnych i Rady przez mieszkańców/interesantów.

17) Dokumenty kierowane przez interesantów mają trafiać do systemu poprzez wykorzystanie mechanizmów elektronicznej skrzynki podawczej na ePUAP ww. dokumenty mają być procesowane w EOD oraz przesłane (jeżeli zajdzie taka konieczność) na posiedzenie Rady Miasta lub właściwej dla danego przedmiotu sprawy komisji RM.

18) Przekazanie dokumentu na posiedzenie Rady Miasta lub właściwej dla danego przedmiotu sprawy komisji RM ma odbywać się poprzez dodanie go do formularza porządku obrad RM lub komisji RM

19) E-RADA ma umożliwiać gromadzenie dokumentów w teczkach spraw w podziale na JRWA w elektronicznym repozytorium EOD.

20) Wszystkie szablony dokumentów elektronicznych typu: plan sesji RM, plan posiedzenia komisji RM, protokół z sesji RM oraz protokół z posiedzenia komisji RM obsługiwane w systemie e-rada mają być zgodne z ich odpowiednikami w wersjach papierowych.

21) Wszystkie wersje elektroniczne dokumentów w systemie mają posiadać unikalny numer zgodny z wewnętrzną numeracją stosowaną w Urzędzie Miasta.

oju o

22) Numeracja wersji elektronicznych dokumentów przetwarzanych w systemie ma być zgodna z ich papierowym odpowiednikiem.

23) Dokumenty mają zostać pogrupowane według typów dokumentów, np.:

a) rejestr wniosków,

b) rejestr zapytań,

c) rejestr skarg,

d) rejestr interpelacji.

24) E-RADA ma umożliwiać przesyłanie informacji (monitu) do wskazanych radnych (czyli zgodnie z przyznanymi uprawnieniami) o pojawieniu się nowego dokumentu, do którego radny ma dostęp zgodnie z nadanymi mu uprawnieniami e-mailem lub sms.

25) E-RADA ma zostać wyposażony w dedykowane repozytorium zintegrowane z repozytorium EOD.

26) W repozytorium znajdować będą się pogrupowane (hierarchiczna struktura drzewa) w teczki tematyczne zawierające x.xx.:

a) rejestr uchwał,

b) rejestr projektów uchwał,

c) rejestr protokołów z posiedzeń oraz rejestr protokołów z posiedzeń komisji,

d) rejestry sprawozdań ,

e) rejestr pism przychodzących z zewnętrz: skargi/wnioski/pisma/zapytania.

27) E-RADA ma umożliwiać eksport zestawień z rejestrów do pliku w formacie co najmniej: html, csv, pdf, xls.

28) E-RADA ma zostać wyposażony w dedykowane formularze do tworzenia protokołów z sesji Rady Miasta oraz posiedzeń komisji wspomagające prace podczas posiedzeń RM i komisji RM.

29) E-RADA ma umożliwiać sporządzanie rocznego Planu Pracy Rady w formie dedykowanego formularza elektronicznego zawierającego datę utworzenia, rok, na który sporządzany jest plan oraz kontrolkę do załączania pliku z treścią planu z możliwością wersjonowania załącznika.

30) E-RADA ma umożliwiać edycję i dalsze rozbudowanie formularza rocznego Planu Pracy Rady za pomocą edytora formularzy wbudowanego w EOD.

31) E-RADA ma gromadzić i przechowywać formularze w repozytorium, w dedykowanym widoku, np. „Roczne Plany Pracy”

32) Elektroniczny Formularz Porządku Obrad Rady ma zawierać co najmniej następujące pola:

a) przyjęcie protokołu z obrad poprzedniej sesji,

b) informacja wójta o pracach w okresie międzysesyjnym oraz o wykonaniu uchwała Rady Miasta,

oju o

c) interpelacje i zapytania radnych.

d) rozpatrzenie projektów uchwał lub zajęcie stanowiska,

e) odpowiedzi na interpelacje,

f) wolne wnioski i informacje,

g) wnioski mieszkańców.

33) Poszczególne pola formularza mają umożliwiać co najmniej:

a) wprowadzenie treści właściwej w punkcie,

b) dołączenie załącznika (np. stanowiącego protokół z poprzedniej sesji),

c) wynik głosowania (jeżeli właściwe).

34) Elektroniczny formularz porządku obrad rady ma zostać oparty na mechanizmach edytora formularzy w EOD.

35) E-RADA ma umożliwiać wydruk elektronicznego formularza porządku obrad rady do pliku w formacie RTF, WORD.

36) E-RADA ma umożliwiać edycję formularza poprzez użycie mechanizmu edytora formularzy EOD.

37) E-RADA ma umożliwiać dołączanie do formularza projektu porządku obrad Rady przesyłanego do radnych:

a) dokumentu zawierającego porządek obrad w pliku,

b) projektów uchwał,

c) innych niezbędnych materiałów związanych z porządkiem obrad.

38) E-RADA ma umożliwiać sporządzenie protokołu z każdej sesji Rady; w tym celu E-RADA musi posiadać dedykowany formularz elektroniczny „Protokół z Sesji"

39) Formularz Protokół z Sesji ma zawierać co najmniej:

a) numer sesji (pole tekstowe),

b) data sesji (pole daty),

c) miejsce odbycia sesji (pole tekstowe),

d) stwierdzenie prawomocności posiedzenia (pole typu checkbox),

e) sekcja powtarzalna z możliwością wyboru nieobecnych radnych oraz dopisania komentarza z przyczyną nieobecności lub usprawiedliwieniem,

f) pole tekstowe umożliwiające wpisanie dowolnej treści,

g) porządek obrad (pobrany z formularza porządku obrad, z polami na wpisanie liczby głosów „za”, „przeciw” oraz „wstrzymujących”),

h) dane osoby sporządzającej protokół (pole słownikowe z listy pracowników, domyślnie zalogowany pracownik),

oju o

i) dane osoby przewodniczącej sesji (pole wyboru spośród przewodniczącego Rady lub jego zastępcy, domyślnie zalogowany pracownik).

40) Formularz Protokół z Sesji ma umożliwiać dodawanie następujących załączników:

a) listy obecności radnych (wraz z adnotacją, gdy nieobecność została usprawiedliwiona),

b) listy zaproszonych gości,

c) tekstów przyjętych uchwał (wraz z załącznikami),

d) innych dokumentów (treści wraz załącznikami),

e) zapisu audiowizualnego sesji (jeżeli był prowadzony), np. w formie pliku MP3, WMA.

41) Wersje elektroniczne protokołów z sesji mają być gromadzone i przechowywane w repozytorium e - rada, w dedykowanych widokach.

42) E-RADA ma być zbudowany w sposób modułowy, skalowalny, mają być zapewnione interfejsy do systemu obiegu dokumentów i BIP, a całość funkcjonalności systemu ma zostać zorganizowana w taki sposób, by grupować i prezentować informacje i dane według poszczególnych kadencji Rady Miasta. Uchwały publikowane wedle ustawy i jej wymogów

43) E-RADA powinien współpracować z relacyjną bazą danych SQL w wersji komercyjnej oraz darmowej.

IV. e-konsultacje

1) E-KONSULTACJE zapewnia bezpieczeństwo wprowadzania i przesyłania danych za pomocą szyfrowanego kanału transmisji.

2) E-KONSULTACJE pozwala na wyświetlanie informacji w wersji dla osób niedowidzących

3) E-KONSULTACJE pozwala na importowanie dokumentu XML z edytora aktów prawnych.

4) E-KONSULTACJE umożliwi automatyczną konwersję pliku XML umożliwiającą nanoszenie komentarzy do poszczególnych sekcji.

5) E-KONSULTACJE pozwala na wyświetlanie zaimportowanego pliku XML (uchwały) w sposób umożliwiający intuicyjne dodawanie komentarzy poprzez zaznaczenie obszaru (paragrafu, akapitu, punktu etc.):

a) wizualne odznaczenie na akcie prawnym punktów (oraz paragrafów, akapitów) posiadających komentarze za pomocą ustalonego indeksu

b) lista wyświetlająca wszystkie dodane komentarze:

− wyświetlona pod przeglądanym aktem prawnym,

− filtrowanie komentarzy ze względu na autora - wyświetl wszystkie lub wyświetl

„moje”,

− wyświetlanie dodanych komentarzy w zgrupowany sposób, umożliwiający łatwą interpretację(komentarze dotyczące zagnieżdżonych punktów będą wyświetlane jako podpunkty w ramach sekcji),

oju o

− tworzenie oraz edycja komentarzy do aktów prawnych (użytkownik),

− podgląd dodanych komentarzy (własnych oraz obcych) do aktów prawnych (użytkownik),

− moderowanie wprowadzonych komentarzy (administrator),

− generowanie raportów zbiorczych wszystkich dodanych komentarzy przez użytkowników (administrator).

6) E-KONSULTACJE poprawnie wyświetla informacje w przeglądarkach w wersji, co najmniej Internet Explorer 9, Firefox 19, Chrome 25, Safari 6

7) E-KONSULTACJE powinien współpracować z relacyjną bazą danych SQL w wersji komercyjnej oraz darmowej

V. e-deklaracje

1) E-DEKLARACJE winny opierać się o architekturę opartą na usługach (SOA).

2) E-DEKLARACJE powinien współpracować z relacyjną bazą danych SQL w wersji komercyjnej oraz darmowej

3) E-DEKLARACJE zapewniać powinien bezpieczeństwo wprowadzania i przesyłania danych za pomocą szyfrowanego kanału transmisji.

4) E-DEKLARACJE pozwalać ma na wyświetlanie informacji w wersji dla osób niedowidzących.

5) E-DEKLARACJE pozwalać ma na składanie deklaracji z wykorzystaniem podpisu elektronicznego kwalifikowanego oraz profilu zaufanego ePUAP wraz z urzędowym poświadczeniem odbioru.

6) E-DEKLARACJE pozwala na przygotowanie i wysłanie deklaracji bez podpisu elektronicznego kwalifikowanego z wygenerowanym kodem paskowym. Platforma powinna umożliwiać wydrukowanie deklaracji wraz z kodem kreskowym i złożenie jej w formie papierowej. Urząd musi mieć możliwość jednoznacznej identyfikacji składanej deklaracji wraz z automatycznym pobraniem danych przesłanych za pomocą platformy.)

7) E-DEKLARACJE zalogowanym użytkownikom udostępnią informacje na temat prowadzonej sprawy.

8) Zaimplementowane deklaracje posiadają wbudowany słownik ulic i miejscowości.

9) E-DEKLARACJE pozwala na złożenie nowej deklaracji na podstawie już złożonej.

10) E-DEKLARACJE współpracuje z dostarczanym systemem obiegu dokumentów w zakresie obsługi korespondencji przychodzącej i wychodzącej opatrzonej podpisem elektronicznym kwalifikowanym oraz profilem zaufanym ePUAP.

11) E-DEKLARACJE pozwala na publikowanie kart informacyjnych (kart usług) związanych z załatwianymi sprawami. Podana kartę usługi istnieje możliwość podłączenia deklaracji wraz z instrukcją wypełnienia.

oju o

12) E-DEKLARACJE poprawnie wyświetla informacje w przeglądarkach w wersji, co najmniej Internet Explorer 9, Firefox 19, Chrome 25, Safari 6

VI. e-decyzje

1) E-DECYZJE winny opierać się o architekturę opartą na usługach (SOA).

2) E-DECYZJE zapewniać powinny bezpieczeństwo wprowadzania i przesyłania danych za pomocą szyfrowanego kanału transmisji.

3) E-DECYZJE pozwolą na wyświetlanie informacji w wersji dla osób niedowidzących.

4) E-DECYZJE pozwolą ma odbiór decyzji z wykorzystaniem podpisu elektronicznego kwalifikowanego oraz profilu zaufanego ePUAP oraz wygenerować urzędowe poświadczenie odbioru.

5) E-DECYZJE zalogowanym użytkownikom udostępnia informacje na temat prowadzonej sprawy. Funkcjonalność dopuszczalna poprzez E-BOI.

6) E-DECYZJE współpracuje z dostarczanym systemem obiegu dokumentów w zakresie obsługi korespondencji przychodzącej i wychodzącej opatrzonej podpisem elektronicznym kwalifikowanym oraz profilem zaufanym ePUAP.

7) E-DECYZJE poprawnie wyświetla informacje w przeglądarkach w wersji co najmniej Internet Explorer 9, Firefox 19, Chrome 25, Safari 6.

8) E-DECYZJE powinien współpracować z relacyjną bazą danych SQL w wersji komercyjnej oraz darmowej.

VII. e-podatki/e-odpady

1) E-PODATKI/E-ODPADY winny opierać się o architekturę opartą na usługach (SOA).

2) E-PODATKI/E-ODPADY zapewniać powinny bezpieczeństwo wprowadzania i przesyłania danych za pomocą szyfrowanego kanału transmisji.

3) E-PODATKI/E-ODPADY pozwalać ma na wyświetlanie informacji w wersji dla osób niedowidzących.

4) E-PODATKI/E-ODPADY zalogowanym użytkownikom udostępnią informacje na temat prowadzonej sprawy poprzez E-BOI.

5) E-PODATKI/E-ODPADY współpracuje z dostarczanym systemem obiegu dokumentów w zakresie obsługi korespondencji przychodzącej i wychodzącej opatrzonej podpisem elektronicznym kwalifikowanym oraz profilem zaufanym ePUAP.

6) E-PODATKI/E-ODPADY zalogowanym użytkownikom udostępnia informacje podatkowe z systemów dziedzinowych, co najmniej w zakresie kwoty rat, wymaganych płatności, dokonanych wpłat, historii transakcji poprzez e-BOI.

7) E-PODATKI/E-ODPADY zalogowanym użytkownikom udostępnia informacje z systemu gospodarowania odpadami, co najmniej kwoty rat, wymagane płatności, zapłacono, historia transakcji.

oju o

8) E-PODATKI/E-ODPADY zalogowanym użytkownikom udostępnia informacje z systemu czynszowego, co najmniej kwoty rat, wymagane płatności, zapłacono, historia transakcji.

9) E-PODATKI/E-ODPADY zalogowanym użytkownikom udostępnia informacje z systemu opłat za użytkowanie wieczyste, co najmniej kwoty rat, wymagane płatności, zapłacono, historia transakcji.

10) E-PODATKI/E-ODPADY poprawnie wyświetla informacje w przeglądarkach w wersji, co najmniej Internet Explorer 9, Firefox 19, Chrome 25, Safari 6.

11) E-PODATKI/E-ODPADY powinien współpracować z relacyjną bazą danych SQL w wersji komercyjnej oraz darmowej.

Pakiet Finansowy

I. Moduł finansowo-budżetowy

1) Moduł umożliwi prowadzenie księgowości jednostki budżetowej, księgowości budżetu, oraz księgowości jednostek podległych.

2) Moduł umożliwi ewidencję zdarzeń gospodarczych w oparciu o zdefiniowany plan kont oraz rejestrację dowodów księgowych na kontach bilansowych i pozabilansowych.

3) Moduł musi zapewnić tworzenie dzienników częściowych grupujących zdarzenia według ich rodzajów, oraz chronologiczne ujęcie zdarzeń w danym okresie sprawozdawczym.

4) Moduł musi mieć możliwość podglądu i wydruku dziennika (dziennika częściowego) zarejestrowanych operacji gospodarczych zgodnie z ustawą o rachunkowości.

5) Moduł musi zapewnić, że zapisy w dzienniku (dziennikach częściowych) będą kolejno i automatycznie numerowane, a sumy ich zapisów (obroty) będą liczone w sposób ciągły.

6) Moduł musi mieć możliwość podglądu i wydruku dekretów zaewidencjonowanych (nie zaksięgowanych) i zaksięgowanych.

7) Moduł musi mieć możliwość zdefiniowania rozbudowanej struktury kont analitycznych.

8) Klasyfikacja budżetowa dochodów i wydatków oraz przychodów i rozchodów musi stanowić jeden wspólny słownik wykorzystywany podczas tworzenia zarówno projektu/budżetu urzędu jak i definiowania planu kont klasyfikacji budżetowej.

9) Moduł w zakresie wprowadzania dokumentów powinien dać także możliwość używania klawiatury bez używania myszki.

10) Moduł musi mieć możliwość usprawnienia obsługi zamknięcia roku przez automatyzację procesu przeksięgowań związanych z zamykaniem kont bilansowych i pozabilansowych na koniec roku obrotowego.

11) Moduł musi mieć możliwość tworzenia bilansu otwarcia na podstawie stanu kont na koniec roku poprzedniego.

oju o

12) Moduł ma umożliwiać pracę na przełomie roku obrotowego (praca w nowym roku bez konieczności zamykania roku poprzedniego).

13) Moduł ma umożliwiać tworzenie zestawień obrotów i sald z uwzględnieniem dokumentów przeznaczonych do zaksięgowania (zadekretowanych, ale jeszcze nie zaksięgowanych).

14) Moduł ma umożliwiać obsługę rozrachunków (rozliczanie, noty odsetkowe, zestawienia należności i zobowiązań kontrahentów, wydruki potwierdzenia salda kontrahentów). Wydruk powinien zawierać istotne daty dokumentu (wystawienia, zaksięgowania, płatności).

15) Moduł ma umożliwiać sporządzenie wygenerowania zestawienia obrotów i sald kont księgi głównej, a także ksiąg pomocniczych (analityka kont) zawierającego, co najmniej:

a) nazwy kont,

b) salda (suma sald) kont na dzień otwarcia ksiąg rachunkowych (bilans otwarcia),

c) obroty za okres sprawozdawczy,

d) obroty narastająco od początku roku obrotowego,

e) salda (sumy sald) na koniec okresu sprawozdawczego.

16) Moduł musi mieć możliwość wyszukiwania i wydruku wprowadzonych dokumentów według różnych parametrów:

a) zakresu pozycji księgowych, pod którą zostały wprowadzone do dziennika,

b) zakresu dat dokumentów,

c) rodzaju dziennika

d) oraz innych cech np. rodzajów i symboli dokumentów, określonych kodów oraz księgowań na konkretną kwotę.

17) Moduł musi mieć możliwość obsługi dekretów przekazywanych z innych obszarów (podobszarów), jako polecenia księgowania.

18) Moduł musi posiadać mechanizmy pozwalające na automatyzację dekretowania na właściwych kontach pozabilansowych planu finansowego wydatków i jego zmian tworzonych w budżecie

19) Moduł musi mieć możliwość automatycznego zaczytania lub rejestracji ręcznej sprawozdań jednostkowych do organu i ich automatyczne dekretowania na kontach księgowych budżetu (organu).

20) Moduł musi mieć możliwość rejestrowania dokumentów w dowolnym (nie zamkniętym) miesiącu bez konieczności zamykania miesiąca poprzedniego.

21) Moduł podczas wprowadzania (dekretowania) operacji gospodarczej powinien dawać możliwość podglądu planu i aktualnego stanu wykonania budżetu dla danego zadania i paragrafu oraz po zadekretowaniu operacji w przypadku przekroczenia planu, automatycznie to sygnalizować.

oju o

22) Moduł powinien dawać umożliwiać kopiowania dokumentów już raz do niego wprowadzonych, np. zadekretowanej listy płac z poprzedniego m-ca do m-ca bieżącego.

23) Moduł powinien dawać możliwość naniesienia zmiany we wprowadzonej operacji księgowej zaewidencjonowanej pod danym numerem L.p. poprzez automatyczną zmianę danego parametru, np. kwoty, treści operacji, klasyfikacji budżetowej, numeru zadania, dla wszystkich kont jednocześnie, np.: 401 – 201, 201 – 130, 013 – 072, 998 – 998, 980 bez konieczności odrębnego nanoszenia zmian na każdym z użytych kont.

24) Moduł musi mieć możliwość obsługi wydatków strukturalnych (podczas dekretowania wydatków możliwość wyboru właściwej klasyfikacji strukturalnej) i sporządzenia sprawozdania RB-WS.

25) Moduł musi mieć możliwość sporządzenia (naliczenia na podstawie stanów kont oraz wydruk) bilansu jednostki i budżetu oraz załączników do bilansu jednostki: Rachunek zysków i strat, Zestawienie zmian w funduszu jednostki.

26) Moduł musi umożliwiać otrzymanie, co najmniej następujących zestawień:

a) wydruk dziennych zapisów księgowych wraz z identyfikacją osoby, odpowiedzialnej za wprowadzenie zapisu,

b) wydruk stanu kont (na wybrany dzień) - obrotów i sald w układzie syntetycznym, analitycznym i klasyfikacji budżetowej,

c) wydruk kartotek w układzie analitycznym i klasyfikacji budżetowej,

d) karta wydatków/dochodów,

e) wydruk należności/zobowiązań kontrahentów (wymagane i niewymagane wraz z terminem płatności).

27) Moduł musi mieć możliwość prezentacji kont klasyfikacji na zestawieniach w następujący sposób:

a) dochody - plan – wykonanie -% wykonania dział -rozdział – paragraf,

b) wydatki - plan - wykonanie - % wykonania,

c) dział - rozdział - paragraf dla każdej jednostki wg. jej kodu i zbiorczo.

28) Moduł musi mieć możliwość naliczania sprawozdań jednostkowych oraz zbiorczych.

29) Moduł musi mieć możliwość naliczenia sprawozdań na podstawie dokumentów zaksięgowanych oraz sprawozdań roboczych (z uwzględnieniem dokumentów przeznaczonych do zaksięgowania ).

30) Przed wydrukiem sprawozdania moduł musi posiadać mechanizm weryfikacji i sygnalizowania błędnych zapisów (ostrzeżenia) dla każdej klasyfikacji.

31) Moduł musi mieć możliwość eksportu sprawozdań do programu Besti@.

32) Moduł musi pozwalać na bez plikową wymianę sprawozdań z jednostkami podległymi.

oju o

33) Moduł musi pozwalać na wyodrębnienie niezależnych instancji konfigurowanych bezpośrednio w jednostkach podległych.

34) Obsługa słowników modułu.

35) Moduł powinien dawać możliwość zapisywania w słowniku treści operacji (np. tytułu płatności) i ponownego jej wykorzystania przy następnych dekretowaniach (np. w następnym m-cu). Powinien również dawać możliwość zaczytywania operacji z kont rozrachunkowych 2xx (z księgowań po stronie Ma) do operacji na kontach rozrachunkowych 2xx po stronie Wn.

36) Moduł musi obsługiwać (księgować) płatności masowe realizowane za pośrednictwem banku poprzez automatyczne rozksięgowanie przelewów z indywidualnych kont bankowych

37) Moduł musi obsługiwać część finansową związaną z realizacją dochodów podatkowych oraz nie podatkowych urzędu poprzez integrację z księgowością podatkową i niepodatkową - na podstawie zapisów księgowości podatkowej księgowości niepodatkowej tworzone mają być zapisy w księdze głównej.

38) Moduł powinien umożliwiać uzyskanie informacji wspomagających podejmowanie decyzji przez organ wykonawczy (funkcja analiz i zestawień), w tym prezentowanie danych o planowanych dochodach i wydatkach oraz o stanie realizacji wykonania, w oparciu o dane z obszaru finansowo-budżetowego poprzez:

a) prezentacji danych w postaci tabelarycznej, graficznej lub kostki OLAP,

b) tworzenia zestawień oraz graficznej prezentacji informacji o należnościach i wpłatach podatników lub innych płatników w podziale na poszczególne rodzaje należności,

c) konfigurowanie dowolnych raportów z wykorzystaniem wbudowanego narządzenia raportującego,

d) tworzenie dynamicznych analiz na bazie grupowania zagnieżdżonego list danych,

e) zapisywanie raportów do 10 różnych formatów.

39) Moduł finansowy-budżetowy powinien posiadać funkcjonalność w zakresie analiz i zestawień usprawniających zarządzanie obejmującą, co najmniej:

a) możliwość uzyskania informacji wspomagających podejmowanie decyzji, w tym prezentowania danych o planowanych dochodach i wydatkach oraz o stanie realizacji wykonania, w oparciu o dane z obszarów finansowo budżetowych.

b) możliwość prezentacji danych w postaci tabelarycznej, graficznej lub kostki OLAP.

c) możliwość tworzenia zestawień oraz graficznej prezentacji informacji o należnościach i wpłatach podatników lub innych płatników w podziale na poszczególne rodzaje należności.

oju o

d) konfigurowanie dowolnych raportów z wykorzystaniem wbudowanego narządzenia raportującego.

e) tworzenie dynamicznych analiz na bazie grupowania zagnieżdżonego list danych.

f) zapisywanie raportów do 10 różnych formatów.

II. Moduł rejestru umów (należności i zobowiązania), zaangażowania

Moduł ma służyć do ewidencjonowania, kontroli i zarządzania wszelkimi należnościami i zobowiązaniami występującymi w jednostkach oraz ewidencjonowanie związanych z tymi należnościami i zobowiązaniami zapłat wynikających z wszelkich umów, porozumień oraz aktów notarialnych (itp.) zawieranych przez Gminę. Rejestr umów powinien być obsługiwany przez każdą komórkę urzędu (każdy rejestruje tylko swoje umowy), lub centralnie przez jeden wydział. Zarejestrowane dane powinny być wykorzystywane później do wystawiania i kontroli innych dokumentów w innych systemach (np.: księgowych, takich jak faktury). Całość ma służyć utrzymywaniu dyscypliny budżetowej.

Wymagania podstawowe:

1) Prowadzenie komputerowej ewidencji dokumentów związanych z powstaniem, zmianą lub wygaśnięciem zobowiązań lub należności,

2) Współpraca z modułem BUDŻET (do projektowania i analizy wykonania budżetu) w zakresie automatycznego pobierania dokumentów planu budżetowego,

3) Współpraca z modułem finansowo-księgowym w zakresie automatycznego księgowania zaangażowania budżetu – generowanie dekretów księgowych do modułu finansowo – księgowego wynikających z zaewidencjonowanych umów oraz faktur niezwiązanych z umowami,

4) Podgląd aktualnej wartości planu budżetowego oraz dokumentów uchwał i zarządzeń z których wartość ta wynika niezależnie dla każdego dysponenta budżetowego,

5) Rejestr umów – ewidencja umów zawieranych przez poszczególne wydziały urzędu w kontekście zaangażowania środków budżetowych,

6) Rejestr faktur – ewidencja faktur, wynikających z realizacji zawartych umów a także faktur i innych dokumentów rozliczeniowych niezwiązanych z umowami,

7) Zatwierdzanie dokumentów potwierdzające ich poprawność merytoryczną i finansową,

8) Kontrola realizacji budżetu – analiza środków budżetowych pozostających do dyspozycji, na różnych etapach realizacji zadań (faktycznego wykonania, zaangażowania, wszczętych zamówień publicznych),

9) Ewidencja wydatków strukturalnych,

10) Generowanie szeregu zestawień w różnych przekrojach,

11) Wyszukiwanie umów z kartoteki umów wydatkowych, dochodowych, mieszanych i innych:

oju o

a) wg numeru umowy

b) wg nazwy lub nazwiska kontrahenta

c) wg daty umowy

d) wg kategorii umowy

e) wg grupy umowy

f) wg jednostki realizującej (wydziału, który otrzymał środki na realizację umowy w budżecie)

g) wg statusu umowy

12) Rejestracja umów:

a) umowy zlecenie

b) umowy o dzieło

c) umowy o roboty budowlane

d) umowy pożyczki

e) umowy najmu

f) umowy dzierżawy

g) umowy kupna

h) umowy sprzedaży

i) akty notarialne

j) umowa użyczenia

k) dowolnie skonfigurowane rodzaje umów

13) Poprawianie zarejestrowanej umowy.

14) Akceptacja umowy przez komórkę finansową.

15) Tworzenie aneksu do umowy.

16) Przeglądanie stanu realizacji umowy.

17) Tworzenie różnego rodzaju zestawień:

a) zestawienie umów i aneksów anulowanych

b) zestawienie umów zakończonych

c) wydruk wykazu umów wg rożnych kryteriów

d) wydruk zestawienia syntetycznego umów

18) Obsługa słowników modułu.

III. Moduł obsługi kasowej

1) Moduł musi umożliwić ewidencję wpłat i wypłat gotówkowych.

2) Moduł musi umożliwić rejestrację oraz druk dowodów wpłat i wypłat

oju o

3) Moduł musi umożliwić tworzenie i wydruk raportów kasowych.

4) Moduł musi mieć możliwość integracji z obszarami księgowości należności tj. księgowości podatków, dochodów z nieruchomości i księgowości opłat (pobieranie informacji o należnościach kontrahentów do zapłaty (lub zwrotach nadpłat) w kasie, a także przekazywanie informacji o realizacji do odpowiednich obszarów (windykacja należności).

5) Moduł musi umożliwić automatyczne księgowanie raportów kasowych (po ich zamknięciu) w księgowości jednostki.

6) Moduł musi mieć możliwość chronologicznego wydruku dokumentów KP i KW za wybrany okres.

7) Moduł musi mieć możliwość generowania druku odprowadzenia gotówki do banku - druk przelewu.

8) Moduł musi mieć możliwość przyjmowania wpłat od osoby bez konieczności rejestrowania jej w bazie kontrahentów urzędu (dotyczy sporadycznych wpłat).

9) Moduł musi mieć możliwość obsługi kilku kas jednocześnie.

10) Moduł musi współpracować z czytnikami kodów kreskowych

11) Obsługa słowników modułu.

IV. Moduł fakturowania i prowadzenia rejestrów VAT

1) Moduł musi umożliwić zarządzanie rejestrem towarów i usług.

2) Moduł musi mieć możliwość elastycznego tworzenia rejestrów VAT: kwartalne, miesięczne, zarządzanie rejestrami

3) Moduł musi umożliwić wystawianie i obsługę faktur sprzedaży i ich korekt:

a) tworzenie,

b) zmiana,

c) anulowanie,

d) zatwierdzanie,

e) wydruk.

4) Moduł musi umożliwić ewidencję i obsługę faktur zakupu i korekt faktur zakupu.

5) Moduł musi mieć możliwość tworzenia chronologicznego rejestru VAT według terminów.

6) Moduł musi mieć obsługę stawek VAT.

7) Moduł musi mieć możliwość przekazywania danych o fakturach do księgowości.

8) Moduł musi umożliwić wydruk Rejestru VAT.

9) Obsługa słowników modułu.

V. Moduł środki trwałe i wyposażenie

oju o

Moduł ma zapewniać pełną obsługę w zakresie ewidencji środków trwałych, wyposażenia, wartości niematerialnych i prawnych oraz gruntów jednej lub wielu jednostek organizacyjnych z

dowolnie zdefiniowanym podziałem np. na działy, wydziały, referaty, osoby odpowiedzialne, biura, pokoje itp., zgodnie z potrzebami.

1) Moduł musi umożliwiać wyszukanie asortymentu według fragmentu jednego z kryteriów (np. fragmentu nazwy "%TEL%" - wyszuka takie NAZWY jak TELEFON, FOTEL, TELEFON Z SEKRETARKĄ).

2) Moduł musi być zintegrowany z systemem finansowo księgowym i umożliwiać przesłanie informacji o rejestrowanych dokumentach i naliczonych umorzeniach do księgowania.

Wymagania podstawowe dla środków trwałych:

1) Obsługa zarządzaniem pełnym cyklem obsługi każdego środka trwałego od zakupu lub przekazania poprzez amortyzację aż do sprzedaży lub likwidacji w tym kontrolę pod względem formalnym. Moduł ma automatycznie tworzyć planu amortyzacji, a także jego modyfikację, w oparciu o wprowadzone przez użytkownika kryteria oraz na wybór metody naliczania planu amortyzacji (liniowa, degresywna, jednorazowa). Umożliwiać także zewidencjonowanie środka trwałego, będącego już w trakcie amortyzacji, lub też pochodzącego z przekazania oraz wykorzystać współczynnik modyfikujący.

2) Moduł musi umożliwiać ewidencjonowanie wyposażenia, wartości niematerialnych i prawnych oraz gruntów oraz możliwość prowadzenia ewidencji środków trwałych, z uwzględnieniem ich części składowych.

3) Moduł musi pozwalać na przeprowadzenie i ewidencję typowych operacji dokonywanych na środkach trwałych, takich jak: modernizacja, przeszacowanie, likwidacja, sprzedaż, przekazanie. Wszystkie operacje muszą być zapisywane w historii danego środka trwałego. Moduł musi umożliwia wydruk potwierdzeń dla wykonanych operacji. W łatwy sposób umożliwiać zlokalizowanie środka trwałego posiadanego przez użytkownika, określić skład komisji spisowych.

4) Moduł musi posiadać wbudowany słownik klasyfikacji środków trwałych oraz klasyfikacji budżetowej. Moduł musi umożliwiać przypisywane podziałki klasyfikacji budżetowej do danego środka trwałego, co ma pozwolić na powiązanie ewidencji z danymi finansowo-księgowymi.

5) Moduł musi posiadać wbudowany kreator raportów pozwalający na przygotowywanie konfigurowanych przez użytkownika zestawień; umożliwiać przygotowywane wydruków według kryteriów określanych przez użytkownika, np. zestawienia roczne, wartości środków i umorzeń, raport SG-01 oraz exportu tych zestawień do formatu xls lub pdf.

Wymagania podstawowe dla ewidencji wyposażenia:

oju o

1) Prowadzenie jednolitej kartoteki wyposażenia zapewniającej unikalność numerów inwentarzowych.

2) Możliwość definiowania przez użytkownika dokumentów księgowych dotyczących obrotu wyposażeniem.

3) Prowadzenie kartoteki ilościowej wyposażenia.

4) Możliwość przeszacowania wyposażenia.

5) Sporządzanie rozliczeń w oparciu o spis z natury.

6) Możliwość dokumentacyjnej zmiany lokalizacji.

VI. Kadry i płace

A. Kadry

Wymagania minimalne:

1) Rejestracja następujących danych w module:

a) związanych z zatrudnieniem:

− pracownicze: nazwisko, imię, drugie imię, data urodzenia, miejsce urodzenia, płeć, xxxx xxxxxxx, imiona rodziców, nazwisko panieńskie matki, nr dowodu osobistego, miejsce zamieszkania (czasowe, stałe, do korespondencji), PESEL, NIP, wykształcenie, kod tytułu ubezpieczenia, podlega/nie ubezpieczeniu społecznemu i zdrowotnemu, Urząd Skarbowy zgodny z miejscem zameldowania, nr telefonu, emeryt lub rencista (nr emerytury, renty, grupa inwalidzka), stosunek do służby wojskowej

− kwalifikacje: data i miejsce ukończenia szkoły, wyuczony zawód, nr dyplomu, specjalizacja, znajomość języków, obecne stanowisko pracy, kwalifikacja stanowiska pracy (robotnicze lub nierobotnicze)

− ukończone kursy

b) związanych z trwającym stosunkiem pracy:

− stanowisko, komórka organizacyjna

− data zatrudnienia w Urzędzie

− okres zatrudnienia (próbny, określony, nieokreślony)

− wynagrodzenie zasadnicze (kwota i grupa zaszeregowania), wynagrodzenie ryczałtowe, premia, dodatki (%, kwotę wylicza program) wraz z informacją o czasie, na jaki jest przyznany (funkcyjny, stażowy, specjalny)

− historia zatrudnienia dla potrzeb obliczenia stażu pracy,

− wymiar etatu.

2) Wyróżnienia i kary regulaminowe.

oju o

3) Kartoteka urlopowa w postaci czytelnej makiety urlopowej na zasadzie kalendarza z możliwością nanoszenia i sumowania wszystkich możliwych nieobecności pracownika (urlop wypoczynkowy, urlop bezpłatny, urlop szkolny, urlop rehabilitacyjny, choroba, opieka nad dzieckiem chorym, opieka nad dzieckiem zdrowym, godziny nadliczbowe, delegacje, urlop

xxxxxxxxxxxx, urlop wychowawczy, urlop okolicznościowy, inne nieusprawiedliwione nieobecności).

4) Kartoteka badań lekarskich z możliwością wprowadzania daty następnego badania.

5) Kartoteka szkoleń BHP z możliwością wprowadzania daty następnego szkolenia BHP.

6) Kartoteka szkoleń dla każdego pracownika z następującym danymi: temat szkolenia, termin, koszt, otrzymane zaświadczenia o odbyciu kursu (szkolenia).

7) Ewidencja pracowników pracujących dłużej niż 4 godziny dziennie przy monitorze.

8) Moduł musi zapewnić automatyczne naliczanie wymiaru urlopu, sygnalizacja wymiaru urlopu szkolnego z możliwością bilansowania miesięcznego i rocznego urlopów (wg rodzajów), wydruk dla pracownika z dokładnością do minuty.

9) Moduł musi zapewnić wydruk dokumentów kadrowych takich jak: umowa o pracę, świadectwo pracy, porozumienie zmieniające, angaż, wypowiedzenie, skierowanie na badania lekarskie, zaświadczenie o zatrudnieniu i wynagrodzeniu na podstawie wprowadzonych wzorów dokumentów kadrowych.

10) Moduł umożliwi tworzenie i edycję wzorów dokumentów kadrowych wykorzystywanych do drukowania.

11) Moduł musi automatycznie obliczać daty uprawnienia do nagrody jubileuszowej i daty do emerytury z możliwością wykluczania okresów nakładających się na siebie na podstawie wprowadzonych świadectw pracy.

12) Moduł musi naliczać staż pracy w zakładzie oraz staż pracy ogólny z możliwością wykluczania okresów nakładających się na siebie na podstawie wprowadzonych świadectw pracy.

13) możliwość eksportowania do programu ZUS PŁATNIK w pełnym zakresie dokumentów zgłoszeniowych i wyrejestrowujących

14) Prognozowanie wynagrodzenia:

a) kopiowanie danych rzeczywistych do planu wynagrodzeń,

b) tworzenie planu poprzez korektę poszczególnych składników wynagrodzenia lub poprzez zmianę - kwoty brutto (składniki wynagrodzenia obliczane automatycznie),

c) kontrola różnic powstałych pomiędzy planowanymi a rzeczywistymi składnikami wynagrodzenia, na poziomie pracownika, wydziału i całego Urzędu,

d) obliczanie średnich wartości poszczególnych składników wynagrodzenia w ramach wydziałów i grup pracowniczych (stanowisk służbowych),

e) drukowanie zestawień z planem wynagrodzenia wg wydziałów i grup pracowniczych,

f) akceptacja planu - kopiowanie utworzonego planu do bieżącej kartoteki.

oju o

15) Planowanie zatrudnienia

16) Moduł powinien automatycznie sygnalizować (bez konieczności wywoływania raportów) zdarzeń określonych przez użytkownika z określonym wyprzedzeniem, np: upływu ważności badań lekarskich pracowników, szkoleń BHP itp.

17) Moduł powinien posiadać archiwum odrębnie dla pracowników zwolnionych i obecnie pracujących, w przypadku ponownego przyjęcia do pracy osoby zwolnionej możliwość łatwego przywrócenie danych

18) Moduł powinien umożliwiać samodzielne generowanie raportów na poziomie użytkownika i administratora z dowolnie wybranych elementów za różne okresy za pomocą generatorów raportów

19) Moduł musi automatycznie generować dane do sprawozdań Z05, Z03, Z06, Z12

20) Moduł powinien umożliwiać eksport dowolnych danych do Excel’a lub pliku tekstowego

21) Moduł musi być prosty w obsłudze, z rozbudowanym generatorem zestawień tabelarycznych, umożliwiający definiowanie przez użytkownika zakresu danych z dowolnych danych z systemu z możliwością ich przeliczania, filtrowania oraz grupowania

22) Moduł powinien posiadać wbudowany moduł raportowania z możliwością stworzenia dowolnych raportów w postaci formatki wydruku

23) możliwość obsługi wielu płatników składek ZUS

B. Płace

1) Moduł zapewni korzystanie z danych pochodzących z systemu kadrowego bez konieczności ich transmisji

2) Moduł:

a) nalicza płace i przygotowuje wypłaty (sporządzanie list płac: głównej uwzględniającej ulgę podatkową i koszty uzyskania przychodu oraz list dodatkowych z uwzględnieniem wspólnej podstawy do wyliczenia składek zus dla wynagrodzeń wypłacanych w tym samym miesiącu,

b) automatycznie tworzy dokumenty wynagrodzenia za czas urlopu i choroby na podstawie kartoteki absencji oraz wyliczanie na podstawie kartoteki zarobkowej wysokości wynagrodzenia i zasiłków

c) nalicza nagrody jubileuszowej, nagrody uznaniowej, 13-ta pensji, odprawy emerytalnej, ekwiwalentu za urlop, wynagrodzenia za urlop, wynagrodzenia za nadgodziny, odprawy z tytułu zwolnienia, zwrotu składek ZUS za lata poprzednie i rok bieżący

d) umożliwia zmiany składników w stosunku do poprzedniego miesiąca poprzez ich modyfikację, z automatycznym obliczaniem pozostałych składników

3) Moduł musi rozliczać płace w zakresie:

oju o

a) obliczanie narzutów od wynagrodzeń,

b) eksport danych do programu PŁATNIK,

c) rozliczanie zaliczek miesięcznych na poczet podatku dochodowego od łącznej kwoty wypłat dla Urzędu Skarbowego,

d) obliczanie i pobieranie składki na ubezpieczenia społeczne, zdrowotne, Fundusz Pracy,

e) tworzenie przelewów bankowych na konto ZUS, Urząd Skarbowy, PERON i inne wynikające z zadeklarowanych potrąceń,

f) tworzenie i wydruk przelewu na konto osobiste pracownika,

g) sporządzanie wydruków związanych z wypłatą (odcinek dla pracownika, zestawienie gotówkowe, zbiorówka listy płac),

h) wykonanie wydruków związanych z rocznymi rozliczeniami (roczna karta wynagrodzeń, dokumenty podatkowe PIT-4R, PIT-8C, PIT-8S, PIT 8AR, PIT-11, PIT-40, IFT-1, zaświadczenia o wynagrodzeniu),

i) rejestracja i obsługa wypłat z tytułu umowy o dzieło, umowy zlecenia zarówno dla pracowników własnych jak i obcych,

j) tworzenie z dowolnie wybranych elementów zestawień w celu sprawdzenia poprawności sporządzonej listy płac,

k) obliczanie i wypełnianie deklaracji PFRON.

4) Moduł musi współpracować z modułem finansowo-księgowym poprzez przygotowanie i eksport do systemu finansowo-księgowego informacji i danych do księgowania w postaci noty księgowej z możliwością przygotowania noty w rozbiciu na rozdziały i paragrafy zgodnie z klasyfikacją budżetową.

5) Moduł musi automatycznie wyliczać i generować 13-tą pensję.

6) Moduł musi automatyczne korygować przeszeregowania i skutki zmian wynagrodzenia

7) Moduł musi automatyczna zmieniać progi podatkowe.

8) Moduł musi automatyczne naliczać wysokości dodatków stażowych.

9) Moduł musi automatyczne uwzględniać roczny limit wypłaconych świadczeń z ZFŚS

10) Moduł musi posiadać kalkulator umożliwiający symulację listy płac dla pojedynczego pracownika.

11) Moduł musi automatycznie generować dokumenty nadpłat i niedopłat związanych z wystawionymi dokumentami PIT-40.

12) Moduł musi automatyczne naliczać wyrównania składników stałych w związku ze zmianą warunków zatrudnienia sprzed kilku miesięcy.

13) Moduł musi automatyczne wyliczać wynagrodzenie urlopowe na podstawie absencji.

14) Moduł musi generować i naliczać odprawy emerytalnej.

oju o

15) Moduł musi posiadać możliwość przesyłanie „pasków” wynagrodzeń na e-maila pracownika.

16) Moduł musi posiadać możliwość obsługi wielu płatników składek ZUS.

VII. Podatki i opłaty lokalne

A. Moduł podatku od nieruchomości, rolnego i leśnego

1) Moduł musi posiadać wbudowaną bazę niezbędnych słowników. Umożliwiać, aby dane raz wprowadzone do systemu być potem wielokrotnie wykorzystywane i modyfikowane lub korzystać z bazy modułu ewidencji ludności.

2) System ewidencji podatków w module musi stanowić integralną część ewidencji księgowej urzędu. Co oznacza to, że przypisy, odpisy, wpłaty, zwroty i zaliczenia nadpłat dokonuje się na kontach syntetycznych księgi głównej urzędu, co ma wyeliminować konieczność prowadzenia „podwójnej” księgowości.

3) Moduł musi integrować się z modułem Ewidencja ludności oraz modułem EOD oraz wykorzystywać istniejące urzędowe rejestry (np. TERYT, SWDE).

4) Moduł musi podpowiadać rodzaju podatku w zależności od wprowadzonych składników podatku

5) Moduł musi umożliwiać identyfikację i weryfikację podatników i przedmiotów opodatkowania poprzez mechanizmy kontrolne oparte o zdefiniowane reguły, np. NIP, REGON, PESEL, nr działki, nr budynku, nr lokalu,

6) Moduł musi umożliwić zarejestrowanie kart podatników z uwzględnieniem:

a) podatników (osoby fizyczne, małżeństwa, podmioty grupowe tzn. wiele osób fizycznych),

b) pełnomocników podatników,

c) właściciel i(współwłaścicieli),

d) adresów gospodarstw,

e) przedmiotów opodatkowania (grunty, lasy, nieruchomości),

f) dodatkowych informacji o przedmiocie np. informacji o działkach.

7) Moduł musi umożliwić rejestrowanie zmian - zbywanie/nabywanie przedmiotów opodatkowania w trakcie roku.

8) Moduł musi umożliwić wprowadzenie ulg i zwolnień podmiotowych i przedmiotowych.

9) Moduł musi umożliwić naliczanie podatku rolnego, leśnego i od nieruchomości na podstawie stanu posiadania podatnika oraz naliczanie zmian w podatku w trakcie roku na skutek zmian stanu posiadania.

10) Moduł musi mieć możliwość wystawiania i wydruku decyzji (lub decyzji zmieniającej do wcześniej wydanej) w sprawie wymiaru podatku rolnego, leśnego, od nieruchomości lub łącznego zobowiązania pieniężnego.

11) Moduł musi mieć możliwość wygenerowania, co najmniej:

oju o

a) zestawienia wydanych decyzji,

b) zestawienia gospodarstw,

c) kart gospodarstwa,

d) zestawienia nieruchomości,

e) zestawienia ulg w nieruchomościach,

f) rejestru wymiarowego,

g) zestawienia podatników.

12) Moduł musi mieć możliwość obsługi (korekta, wydruk) decyzji o wysokości zobowiązania pieniężnego (za lata ubiegłe), oraz o umorzeniu zaległości, o odroczeniu terminu płatności oraz o rozłożeniu płatności na raty z możliwością odnotowania daty potwierdzenia odbioru decyzji.

13) W zakresie wystawiania zaświadczeń w oparciu bazę podatków prowadzoną w Urzędzie, moduł musi umożliwić uzyskania informacji o posiadanych zasobach, oraz o zaleganiu lub nie w płatnościach, przez osoby wnioskujące o zaświadczenie.

14) Moduł musi umożliwić wystawianie zaświadczeń o wielkości gospodarstwa oraz o zaleganiu lub nie zaleganiu z opłatami podatku

15) Wykonywanie symulowanych naliczeń na podstawie bazy podatkowej Urzędu.

16) Moduł musi mieć możliwość obliczenia skutków udzielonych przez Urząd ulg i zwolnień.

17) Moduł musi mieć możliwość wystawiania, wydruku i rejestracji zaświadczeń o nieposiadaniu gospodarstwa dla osób, które nie posiadają gospodarstwa na terenie gminy.

18) Moduł musi umożliwić prezentację skutków ulg i umorzeń według rodzajów należności.

19) Podatek od osób fizycznych - moduł musi mieć możliwość wprowadzenia informacji o działkach dla poszczególnych składników opodatkowania (nr działki, obręb, nr księgi wieczystej, nr jednostki rejestrowej).

20) Podatek od osób fizycznych - moduł musi mieć możliwość wyszukiwania według kartotek podatników według nr działek, obrębów, jednostki rejestrowej, nr decyzji itp.

21) Podatek od osób fizycznych - moduł musi mieć możliwość obsługi pełnomocników podatników z możliwością wystawienia decyzji na pełnomocników.

22) Moduł musi mieć możliwość edycji treści wystawianych zaświadczeń.

23) Możliwość obsługi wyboru do izb rolniczych w oparciu o bazę podatków.

24) Moduł musi mieć możliwość obsługi deklaracji i deklaracji korygujących składanych przez podatników z uwzględnieniem:

a) danych o podatnikach,

b) przedmiotów opodatkowania,

c) ulgach w podatku,

oju o

d) adresów nieruchomości,

e) danych o nieruchomościach i działkach.

25) Moduł musi umożliwić obsługę kartotek podatników – osób prawnych.

26) Moduł musi mieć możliwość naliczenia podatku na podstawie składanych deklaracji.

27) Moduł musi mieć możliwość wystawiania i obsługi decyzji o wysokości zobowiązania pieniężnego, oraz o umorzeniu zaległości, o odroczeniu terminu płatności oraz o rozłożeniu płatności na raty z możliwością odnotowania daty odbioru decyzji umorzeniowej.

28) Moduł musi mieć możliwość po zamknięciu roku automatycznego przepisania na nowy rok przedmiotów opodatkowania z deklaracji na podstawie stanu w roku poprzednim do weryfikacji.

29) Moduł musi mieć możliwość wystawiania, wydruku zaświadczeń o nie zaleganiu w podatkach lub stwierdzających kwotę zaległości.

30) Wykonywanie symulowanych naliczeń na podstawie bazy podatkowej Urzędu.

31) Moduł musi mieć możliwość wykonywania symulacji z uwzględnieniem stawek ustawowych, gminnych oraz co najmniej dwóch wariantów stawek symulacyjnych z możliwością obliczenia skutków obniżenia stawki podatkowej.

32) Moduł musi mieć możliwość obliczenia skutków udzielonych ulg i zwolnień i uwzględnienie ulg w sprawozdaniu Rb-27S.

33) Prezentacja skutków ulg i umorzeń według rodzajów należności.

34) Podatek od osób prawnych – moduł musi mieć możliwość wprowadzenia informacji o działkach dla poszczególnych składników opodatkowania (nr działki, obręb, nr księgi wieczystej, nr jednostki rejestrowej).

35) Podatek od osób prawnych - moduł musi mieć możliwość wyszukiwania według kartotek podatników według nr działek, obrębów.

36) Moduł musi umożliwić otrzymanie, co najmniej następujących wydruków:

a) zestawienie nieruchomości według składników,

b) zestawienie powierzchni lasów,

c) zestawienie powierzchni gruntów,

d) zestawienie deklaracji,

e) wezwania do złożenia deklaracji,

f) zestawienie kontrahentów objętych podatkiem,

g) rejestr decyzji.

37) Moduł musi prowadzić ewidencji wydanych decyzji, upomnień i tytułów wykonawczych z możliwością drukowania ewidencji oraz poszczególnych decyzji

38) Moduł musi posiadać podgląd historii właścicieli nieruchomości

oju o

39) Moduł musi współpracować z czytnikami kodów kreskowych i umożliwiać drukowanie decyzji, upomnień z kodem kreskowym do odczytania przez pozostałe moduły np. kasa.;

40) Moduł musi współpracować z modułem obiegu dokumentów, systemem finansowo- księgowym, kasą, posiadać możliwość wczytywania do systemu informacji i załączników złożonych przez podatnika za pomocą platformy e-deklaracje/e-podatki/e-boi;

41) Moduł musi mieć możliwość eksport danych podatkowych do pliku XML wymagany stosownym rozporządzeniem.

42) Moduł musi posiadać możliwość tworzenia książki nadawczej dla korespondencji wysyłanej.

43) Moduł musi posiadać możliwość wygenerowania indywidualnych kont bankowych i wysłania odpowiednich zawiadomień do podatników.

B. Moduł podatku od środków transportu

2) Moduł musi mieć możliwość obsługi deklaracji i deklaracji korygujących składanych przez podatników z uwzględnieniem danych o podatnikach, posiadanych pojazdach, ulg w podatku

3) Moduł musi umożliwić prowadzenie ewidencji pojazdów

4) Moduł musi umożliwić obsługę kartotek podatników podatku od środków transportu.

5) Moduł musi mieć możliwość naliczenia podatku na podstawie składanych deklaracji.

6) Moduł musi mieć możliwość wystawiania i obsługi:

a) decyzji o wysokości zobowiązania pieniężnego,

b) decyzji o umorzeniu zaległości,

c) decyzji o odroczeniu terminu płatności,

d) decyzji o rozłożeniu płatności na raty,

e) z możliwością odnotowania daty potwierdzenia odbioru decyzji.

7) Moduł musi mieć możliwość w zależności od potrzeb użytkownika wyszukiwania informacji o pojazdach i właścicielach według różnych kryteriów.

8) Tworzenie, co najmniej następujących zestawień, zawiadomień i wezwań:

a) zestawienie deklaracji,

b) zestawienie decyzji,

c) ewidencja pojazdów,

d) wezwania do złożenia deklaracji,

e) postanowienia o wszczęciu postępowania,

f) zestawienie kontrahentów objętych podatkiem,

g) rejestr wydanych decyzji.

9) Wykonywanie symulowanych naliczeń na podstawie bazy podatkowej Urzędu.

oju o

10) Moduł musi mieć możliwość wykonywania symulacji z uwzględnieniem stawek ustawowych, gminnych oraz co najmniej dwóch wariantów stawek symulacyjnych.

11) Moduł musi mieć możliwość obliczenia skutków udzielonych przez Urząd ulg i zwolnień.

12) Moduł musi prowadzić ewidencję wydanych decyzji, upomnień i tytułów wykonawczych z możliwością drukowania ewidencji oraz poszczególnych decyzji.

13) Moduł musi posiadać podgląd historii właścicieli nieruchomości.

14) Moduł musi współpracować z czytnikami kodów kreskowych i umożliwiać drukowanie decyzji, upomnień, tytułów wykonawczych z kodem kreskowym do odczytania przez pozostałe moduły np. kasa.;.

15) Moduł musi współpracować z modułem obiegu dokumentów, systemem finansowo- księgowym, kasą, posiadać możliwość wczytywania do systemu informacji i załączników złożonych przez podatnika za pomocą platformy e-deklaracje/e-podatki/e-boi.

16) Moduł musi posiadać możliwość wygenerowania indywidualnych kont bankowych i wysłania odpowiednich zawiadomień do podatników.

C. Moduł opłat lokalnych

1) Moduł musi umożliwić prowadzenie kartotek podatników, dodawanie i przechowywanie informacji na temat posiadanych psów i płatności za nie.

2) Moduł musi mieć możliwość naliczania opłaty dla osób posiadających psy.

3) Moduł musi mieć możliwość obsługi ulg i zwolnień dla osób posiadających psy.

4) Moduł musi mieć możliwość wystawiania i obsługi decyzji o wysokości zobowiązania pieniężnego, oraz o umorzeniu zaległości, o odroczeniu terminu płatności oraz o rozłożeniu płatności na raty

5) Moduł musi generować minimum następujące zestawienia:

a) osób zobowiązanych do opłat według różnych kryteriów,

b) rejestr wydanych decyzji.

6) Moduł musi mieć możliwość obsługi opłat pobieranych w drodze inkasa:

a) opłata targowa,

b) miejscowa,

7) Moduł musi mieć możliwość rejestrowania i rozliczania kwitariuszy wpłat.

8) Moduł musi być zintegrowany z księgowością podatków i opłat lokalnych oraz kasą urzędu w zakresie przekazywania informacji o należnościach i procesem windykacyjnym.

9) Moduł musi współpracować z modułem obiegu dokumentów, systemem finansowo- księgowym, kasą, posiadać możliwość wczytywania do systemu informacji i załączników złożonych przez podatnika za pomocą platformy e-deklaracje/e-podatki/e-boi.

oju o

VIII. Moduł księgowości podatkowej i opłat lokalnych

1) Podobszar obsługujący księgowość podatków (dochody) musi być wewnętrzne zintegrowany z podobszarem księgowości budżetowej.

2) Moduł musi mieć możliwość automatycznej wymiany danych z obszarem księgowości budżetowej (tworzenie poleceń księgowania na kontach księgi głównej na podstawie informacji o przypisach i odpisach), oraz z kasą urzędu (automatyczne rozliczanie raportów kasowych z wpłatami podatników).

3) Moduł musi mieć możliwość rejestracji operacji finansowych;

a) wpłaty,

b) zwroty,

c) przeksięgowania,

d) nadpłaty,

e) kwoty do wyjaśnienia,

f) i rozliczenia tych operacji na kartotekach podatników.

4) Moduł musi mieć możliwość automatycznego rozdysponowania wpłaconej przez podatnika kwoty według przepisu art. 55 § 2 – ustawy – Ordynacja podatkowa

5) Moduł powinien umożliwić księgowanie wpłat z podpowiedzią odsetek w przypadku wpłat po terminie.

6) Moduł musi mieć możliwość obsługi upomnień (wystawianie, wydruk, prowadzenie rejestru).

7) Moduł musi mieć możliwość anulowania upomnienia i kosztów związanych z jego wystawieniem.

8) Wystawianie upomnień powinno być sparametryzowane:

a) wystawianie masowe (dla płatników z wybranego zakresu np. mieszkających na tej samej ulicy, dla wybranego rodzaju należności) lub pojedyncze (dla wybranego płatnika lub kartoteki),

b) z uwzględnieniem kosztów upomnienia, oraz parametryzacja kwoty kosztów,

c) dla wszystkich zaległości danego dłużnika lub tylko dla wybranych,

d) moduł musi mieć możliwość zdecydowania przez użytkownika, ilu pozycyjne ma być upomnienie,

e) jaka minimalna kwota ma podlegać windykacji,

f) moduł musi mieć możliwość wyboru okresu czasu, z którego mają być wybierane należności do upomnień (zaległości, których termin przypada w zadanym okresie).

9) Moduł musi mieć możliwość wystawienia upomnienia na zaległości z bieżącego roku, bądź z lat ubiegłych lub uwzględnienie tych dwóch opcji jednocześnie.

oju o

10) Moduł musi mieć możliwość pokazywania lub nie odsetek za zwłokę na upomnieniu (do decyzji użytkownika).

11) Moduł musi mieć możliwość wystawienia upomnienia na poszczególne rodzaje należności.

12) System, podczas rejestracji wpłaty, musi mieć możliwość pobierania lub nie pobierania kosztów upomnień

13) Moduł musi mieć możliwość umorzenia (lub anulowania) upomnienia.

14) Moduł musi mieć możliwość obsługi tytułów wykonawczych (wystawianie - na poszczególne rodzaje należności, wydruk, rejestry) oraz możliwość eksportu danych do właściwego Urzędu Skarbowego w postaci pliku PDF.

15) Moduł musi mieć możliwość obsługi nadpłat - zapytania o nadpłatę oraz prowadzenie rejestru zapytań.

16) Moduł musi umożliwiać rejestracje daty wszczęcia postępowania egzekucyjnego, zawieszenia, umorzenia i zakończenia postępowania egzekucyjnego.

17) Moduł musi zawierać opcję automatycznego naliczania kosztów egzekucyjnych:

a) naliczanie wysokości opłaty egzekucyjnej w zależności od zastosowanego środka egzekucyjnego,

b) naliczanie opłaty manipulacyjnej.

18) Moduł musi zawierać opcję umorzenia kosztów egzekucyjnych.

19) Moduł musi zawierać opcję podziału sumy uzyskanej z egzekucji.

20) Moduł musi mieć możliwość obsługi dzienników wpłat, raportów kasowych, dzienników wpłat bankowych, zwrotów i przeksięgowań.

21) Moduł musi mieć możliwość wydruku dowodu przeksięgowania i prowadzenie rejestru tych przeksięgowań. Dowód przeksięgowania jest elementem dokumentacji księgowej a rejestr przeksięgowań służy do zarządzania przeksięgowaniami dokumentów.

22) Moduł musi mieć możliwość obsługi hipotek (wystawianie, anulowanie).

23) Umożliwienie realizacji przedawnień (odpis z urzędu w związku z upłynięciem okresu przedawnienia). Wymaganie dotyczy możliwości rejestrowania w module dziedzinowym informacji o przedawnieniu określonego zobowiązania z inicjatywy użytkownika. Fakt rejestracji informacji o przedawnieniu musi mieć konsekwencje w postaci odpowiedniego, zgodnego z przepisami traktowania przedawnionego zobowiązania.

24) Moduł musi mieć możliwość określenia daty, do której należy liczyć odsetki w związku z rozpoczęciem postępowania wobec podatnika i jego zobowiązań w celu zabezpieczenia należności przed przedawnieniem.

25) Kwitariusze powinny zawierać:

a) numer kolejny,

b) dane podatnika i współpodatników,

c) identyfikator kartoteki podatnika,

oju o

d) rodzaj należności,

e) kwotę należności (raty podatku),

f) kwotę zaległości.

26) W systemie musi być umożliwienie rejestrowania wpłaty od dowolnej osoby (lub osób) na należności innych osób lub osoby (zapamiętanie informacji, kto płaci i za kogo płaci).

27) Moduł musi mieć możliwość obsługi prolongat.

28) Moduł musi mieć możliwość naliczania i zapamiętywania należnych a nie pobranych odsetek do pobrania w terminie późniejszym.

29) Moduł musi mieć możliwość tworzenia i obsługi dyspozycji do kasy. W takim wypadku użytkownik kasy realizuje tylko konkretną dyspozycję dla danego płatnika utworzoną przez użytkownika księgowości zobowiązań w oparciu o stan konta płatnika.

30) Moduł musi współpracować modułem kasa przy zastosowaniu kodów kreskowych do identyfikacji wpłacającego.

31) Moduł musi mieć możliwość wygenerowania i wydrukowania zestawień:

a) wydruk kartoteki należności i wpłat dla wybranego podatnika/płatnika (narastająco od początku roku),

b) rozliczenie miesięczne wg rodzajów należności,

c) dziennik obrotów ,

d) wydruk przypisów i odpisów,

e) wydruk umorzeń,

32) Moduł musi mieć możliwość wygenerowania i wydrukowania raportów analitycznych:

a) raport zaległości i nadpłat w rozbiciu na lata - sumaryczny,

b) raport stanów kont analitycznych (w podziale na rodzaje należności).

33) Moduł musi posiadać możliwość automatycznego wykonania sprawozdań RB-27 na podstawie zapisów księgowych.

34) Moduł musi posiadać możliwość automatycznego wykonania sprawozdań RBN na podstawie zapisów księgowych.

35) Moduł musi współpracować z modułem obiegu dokumentów, systemem finansowo- księgowym, platformą e-deklaracje/e-podatki/e-boi.

36) Moduł musi obsługiwać (księgować) płatności masowe realizowane za pośrednictwem banku poprzez automatyczne rozksięgowanie przelewów z indywidualnych kont bankowych.

IX. Moduł akcyza

oju o

1) Wymagana jest współpraca z obszarem podatków w zakresie uzyskania informacji o posiadanych zasobach wnioskujących

2) Moduł musi mieć możliwość rejestracji wniosków związanych z dopłatą do paliw i kompleksowa ich obsługą.

3) Prowadzenie kartotek wnioskodawców.

4) Wystawianie decyzji (pozytywnych) oraz wezwań w sprawie uzupełnienia dokumentów.

5) Tworzenie listy wypłat

6) Moduł musi mieć możliwość otrzymania różnego typu wydruków i zestawień według różnych parametrów:

b) sprawozdanie miesięczne w sprawie zwrotu podatku akcyzowego wg wnioskodawców, daty oraz kwoty zwrotu,

c) zestawienia decyzji pozytywnych,

d) wykazy wnioskodawców ,

e) statystyki decyzji i wniosków.

7) Moduł musi mieć możliwość otrzymania zestawienia statystycznego-Statystyka realizacji ustawy o zwrocie podatku akcyzowego zgodnie z wymaganiami prawa.

8) Moduł musi mieć możliwość generowania przelewów do systemu bankowego.

9) Moduł musi być zintegrowany z księgowością opłat oraz kasą urzędu.

10) Moduł musi współpracować z modułem obiegu dokumentów, systemem finansowo- księgowym, kasą, posiadać możliwość wczytywania do systemu informacji i załączników złożonych przez podatnika za pomocą platformy e-deklaracje/e-podatki/e-boi.

X. Moduł opłat z tytułu zajęcia pasa drogowego

1) Moduł musi mieć możliwość rejestrowania i obsługi składanych wniosków.

2) Moduł musi mieć możliwość wystawiania decyzji dotyczących: zezwoleń na zajęcie pasa drogowego, na lokalizację zjazdu lub na umieszczenie urządzeń infrastruktury technicznej w pasie drogowym.

3) Moduł musi mieć możliwość naliczenia opłaty z tytułu wystawionych zezwoleń oraz prowadzenie księgowań należności od płatników.

4) Moduł musi być zintegrowany z księgowością opłat oraz kasą urzędu w zakresie przekazywania informacji o należnościach i procesem windykacyjnym.

XI. Moduł różnych opłat

1) Moduł musi mieć możliwość zarejestrowania dowolnej opłaty (np. mandatów lub innych kar wpłacanych przez mieszkańców np. opłaty za parkowanie) dla wybranego kontrahenta, wraz z określeniem kwoty do zapłaty oraz terminu lub terminów płatności.

oju o

2) Moduł musi mieć możliwość określenia sposobu egzekwowania należności od kontrahenta

(sposób naliczania odsetek - podatkowe, ustawowe, czy też nie naliczać odsetek).

3) Moduł musi mieć możliwość dowolnego definiowania przez użytkownika rodzaju opłaty - słownik opłat różnych.

4) Moduł musi mieć możliwość dla zdefiniowanej opłaty określenia czy ma być windykowana łącznie z całym procesem upominawczym (upomnienia, wezwanie do zapłaty, tytuł wykonawczy), czy może być pobierana w kasie (dyspozycja do kasy).

5) Moduł musi być zintegrowany z księgowością opłat oraz kasą urzędu w zakresie przekazywania informacji o należnościach i procesem windykacyjnym.

XII. Moduł księgowości opłat

1) Moduł musi mieć możliwość obsługi procesu księgowego w zakresie należności z tytułu różnych opłat dokonywanych przez płatników na rzecz urzędu.

2) Podobszar obsługujący księgowość pozostałych opłat musi być wewnętrzne zintegrowany z podobszarem księgowości budżetowej (dochody/wydatki) .

3) Moduł musi mieć możliwość automatycznej wymiany danych z systemem księgowości budżetowej, oraz z kasą urzędu (automatyczne rozliczanie raportów kasowych z wpłatami płatników).

4) Moduł musi mieć możliwość rejestracji operacji finansowych (wpłaty, zwroty, przeksięgowania, nadpłaty, kwoty do wyjaśnienia) i rozliczenia tych operacji na kartotekach płatników.

5) Moduł musi mieć możliwość automatycznego rozdysponowania wpłaconej przez zobowiązanego kwoty według zasady: od najstarszego terminu płatności z uwzględnieniem kolejności (najpierw odsetki potem należność główna) lub proporcjonalnej wpłaty na należność główną i odsetki, w zależności od rodzaju i typu opłaty. Z możliwością ręcznej zmiany przez użytkownika sposobu rozdysponowania zaproponowanego przez system.

6) Moduł musi mieć możliwość obsługi wezwań do zapłaty lub upomnień (wystawianie, wydruk, prowadzenie rejestru).

7) Moduł musi mieć możliwość anulowania wezwania i kosztów związanych z jego wystawieniem.

8) Wystawianie wezwań powinno być sparametryzowane:

a) wystawianie masowe (dla płatników z wybranego zakresu np. mieszkających na tej samej ulicy, dla wybranego rodzaju należności) lub pojedyncze (dla wybranego płatnika lub kartoteki),

b) z uwzględnieniem lub nie kosztów wezwania, oraz parametryzacja kwoty kosztów,

oju o

c) dla wszystkich zaległości danego dłużnika lub tylko dla wybranych.

9) Moduł musi mieć możliwość wystawienia wezwania do zapłaty na zaległości z bieżącego roku, bądź z lat ubiegłych lub uwzględnienie tych dwóch opcji jednocześnie.

10) Moduł musi mieć możliwość pokazywania lub nie odsetek za zwłokę na wezwaniu (do decyzji użytkownika).

11) Moduł musi mieć możliwość obsługi kosztów wezwań: podczas rejestracji wpłaty, pobierania lub nie pobierania kosztów wezwań, umorzenia.

12) Moduł musi mieć możliwość obsługi dzienników wpłat, raportów kasowych, dzienników wpłat bankowych, zwrotów i przeksięgowań.

13) Moduł musi mieć możliwość wydruku dowodu przeksięgowania i prowadzenie rejestru tych przeksięgowań.

14) Moduł musi mieć możliwość obsługi hipotek (wystawianie, anulowanie).

15) Moduł musi umożliwiać realizację przedawnień (odpis z urzędu w związku z upłynięciem okresu przedawnienia).

16) Moduł musi mieć możliwość określenia daty, do której należy liczyć odsetki w związku z rozpoczęciem postępowania wobec podatnika i jego zobowiązań w celu zabezpieczenia należności przed przedawnieniem.

17) Moduł musi mieć możliwość wygenerowania i wydrukowania różnych wydruków według zdefiniowanych parametrów w tym, co najmniej:

a) wydruk kartoteki należności i wpłat dla wybranego płatnika (narastająco od początku roku i szczegółowo z podziałem na lata),

b) rozliczenie miesięczne wg rodzajów należności,

c) dziennik obrotów,

d) wydruk przypisów i odpisów.

XIII. Gospodarka nieruchomościami

A. Moduł umów z tytułu dzierżaw i najmu:

1) obsługa umów dzierżaw i najmu poprzez utworzenie kart kontowych płatników

2) wprowadzenie informacji dotyczących umów dzierżaw i najmu nieruchomości z możliwością podglądu na dane z ewidencji gruntów,

3) możliwość prowadzenia rat dla płatności typowych, nietypowych i cyklicznych,

4) wprowadzenie informacji dotyczących płatników z możliwością wykorzystania informacji z Ewidencji ludności,

5) tworzenie różnorodnych zestawień na podstawie wprowadzonych danych, zestawienie Rozliczenie umowy,

oju o

6) drukowanie zawiadomień,

7) generowanie faktur VAT na podstawie umów i automatyczne naliczanie i tworzenie rejestru VAT,

8) współpraca z modułem EOD.

B. Moduł użytkowania wieczystego:

1) obsługa umów użytkowania wieczystego poprzez utworzenie kart kontowych płatników

2) możliwość prowadzenia umów w ścisłym powiązaniu z danymi pochodzącymi z ewidencji gruntów,

3) automatyczne naliczanie i tworzenie rejestru VAT,

4) wprowadzenie informacji dotyczących użytkowników z możliwością wykorzystania informacji z Ewidencji ludności,

5) prowadzenie historii zmian użytkowników wieczystych w jednostce rejestrowej,

6) prowadzenie historii zmian na działkach,

7) drukowanie zawiadomień,

8) udzielanie różnego rodzaju ulg,

9) moduł musi umożliwiać przeprowadzenie procedury odwołania płatnika do SKO w przypadku wypowiedzenia opłaty,

10) możliwość przeprowadzenia procedurę wypowiedzenia stawki opłaty,

11) wyszukiwanie podatnika wg następujących kryteriów lub ich fragmentów:

a) nazwiska, imienia, adresu zamieszkania, numeru pesel właścicieli

b) nazwiska, imienia, adresu zamieszkania, numeru pesel administratora, użytkownika, dzierżawcy

c) adresu nieruchomości (działki) a w przypadku jego braku wg opisu położenia

d) numeru jednostki rejestrowej, numeru działki, obrębu, księgi wieczystej

e) wg karty kontowej

12) rejestracja sposobu wykorzystywania działki oraz wprowadzanie różnych wariantów naliczenia opłaty t.j.; dokładnej kwoty opłaty dla działki lub udziału, wprowadzenie opłaty za metr, wartości działki, wartości udziału, stawki VAT.

13) funkcja pozwalająca na poprawę, zmianę składników mających wpływ na wysokość opłaty .

14) naliczanie korekty wraz z tworzeniem korekty faktury dla pozycji objętych podatkiem VAT.

15) wydruki zawiadomień, decyzji i wypowiedzeń - zbiorcze i indywidualne.

16) wydawanie decyzji uznaniowych (przyznanie, przeglądanie, anulowanie)

a) odroczenie terminu płatności,

oju o

b) nowe raty,

c) umorzenie należności,

d) umorzenie odsetek,

e) umorzenie należności "z urzędu",

f) przedawnienie,

g) decyzja o wygaśnięciu zobowiązania (np: z tytułu przejęcia mienia),

h) postanowienie o wygaśnięciu zobowiązania,

i) wygaśnięcie (ograniczenie) decyzji ratalnej,

j) uchylenie częściowe decyzji ratalnej,

k) korekta decyzji uznaniowej z tytułu korekty opłaty (zmiany wysokości rat objętych decyzją uznaniową,

17) moduł musi obsługiwać przekształcenie użytkowania wieczystego we własność poprzez automatycznie obliczanie opłaty za przekształcenie i tworzenie odpowiedniego zapisu na karcie kontowej.

18) rejestrować wnioski o przekształcenie oraz umożliwiać ich modyfikacje (poprawianie danych wniosku o przekształcenie, zmiana danych wniosku o przekształcenie, anulowanie wniosku o przekształcenie).

19) moduł musi umożliwiać rozliczenie opłaty rocznej w przypadku zbycia prawa użytkowania wieczystego w ciągu roku,

20) moduł musi umożliwiać wydanie decyzji o przekształceniu wraz ze sposobem płatności:

a) o umorzeniu odsetek,

b) o umorzeniu należności,

c) o odroczeniu terminu płatności,

d) o rozłożeniu na nowe raty,

e) o wygaśnięciu decyzji;

21) tworzenie różnorodnych zestawień na podstawie wprowadzonych danych w tym x.xx.

zliczenia mienia wg:

a) powierzchni: dzierżawionych gruntów, oddanych w użytkowanie wieczyste, innych form władania,

b) ilości dzierżawców, użytkowników wieczystych.

22) współpraca z modułem EOD.

oju o

XIV. Moduł księgowość dochodów z nieruchomości (umów dzierżaw, najmu i użytkowania wieczystego)

1) Moduł musi mieć możliwość obsługi procesu księgowego w zakresie należności z tytułu zawartych umów (użytkowanie wieczyste, przekształcenia użytkowania wieczystego na własność, dzierżawy oraz sprzedaży).

2) Podobszar obsługujący księgowość dochodów z nieruchomości musi być wewnętrzne zintegrowany z podobszarem księgowości budżetowej.

3) Moduł musi mieć możliwość automatycznej wymiany danych z systemem księgowości budżetowej (tworzenie poleceń księgowania na kontach księgi głównej na podstawie informacji o przypisach i odpisach), oraz z kasą urzędu (automatyczne rozliczanie raportów kasowych z wpłatami płatników).

4) Moduł musi mieć możliwość zaimportowania danych z wprowadzonych faktur i traktowania ich, jako przypisów

5) Moduł musi mieć możliwość rejestracji operacji finansowych (wpłaty, zwroty, przeksięgowania, nadpłaty, kwoty do wyjaśnienia) i rozliczenia tych operacji na kartotekach płatników.

6) Moduł musi mieć możliwość automatycznego rozdysponowania wpłaconej przez zobowiązanego kwoty proporcjonalnie na należność główną i odsetki zaległe. Powinien także posiadać możliwość ręcznej zmiany przez użytkownika sposobu rozdysponowania zaproponowanego przez system.

7) Moduł musi mieć możliwość obsługi wezwań do zapłaty (wystawianie, wydruk, prowadzenie rejestru).

8) Moduł musi mieć możliwość anulowania wezwania i kosztów związanych z jego wystawieniem.

9) Wystawianie wezwań powinno być sparametryzowane: wystawianie masowe (dla płatników z wybranego zakresu np.:

a) mieszkających na tej samej ulicy,

b) dla wybranego rodzaju należności) lub pojedyncze (dla wybranego płatnika lub kartoteki) z uwzględnieniem lub nie kosztów wezwania,

c) oraz parametryzacja kwoty kosztów, dla wszystkich zaległości danego dłużnika lub tylko dla wybranych.

10) Moduł musi mieć możliwość wystawienia wezwania do zapłaty na zaległości z bieżącego roku, bądź z lat ubiegłych lub uwzględnienie tych dwóch opcji jednocześnie.

11) Moduł musi mieć możliwość pokazywania lub nie odsetek za zwłokę na wezwaniu (do decyzji użytkownika).

oju o

12) Moduł musi mieć możliwość obsługi kosztów wezwań: podczas rejestracji wpłaty, pobierania lub nie pobierania kosztów wezwań, umorzenia.

13) Moduł powinien umożliwiać zaznaczenia należności, w stosunku do których został wydany sądowy nakaz zapłaty.

14) Moduł musi mieć możliwość obsługi nadpłat - zapytania o nadpłatę oraz prowadzenie rejestru zapytań.

15) Moduł musi mieć możliwość obsługi dzienników wpłat, raportów kasowych, dzienników wpłat bankowych, zwrotów i przeksięgowań.

16) Moduł musi mieć możliwość wydruku dowodu przeksięgowania i prowadzenie rejestru tych przeksięgowań.

17) Moduł musi mieć możliwość obsługi hipotek (wystawianie, anulowanie).

18) Moduł musi umożliwiać realizację przedawnień (odpis z urzędu w związku z upłynięciem okresu przedawnienia).

19) Moduł musi mieć możliwość określenia daty, do której należy liczyć odsetki w związku z rozpoczęciem postępowania wobec podatnika i jego zobowiązań w celu zabezpieczenia należności przed przedawnieniem.

20) Moduł musi mieć możliwość wygenerowania i wydrukowania zestawień:

a) wydruk kartoteki należności i wpłat dla wybranego płatnika (narastająco od początku roku i szczegółowo z podziałem na lata),

b) rozliczenie miesięczne wg rodzajów należności,

c) dziennik obrotów,

d) wydruk przypisów i odpisów,

e) wydruk umorzeń,

f) wydruk wystawionych hipotek,

g) zestawienie zarejestrowanych przedawnień oraz przedawnień niezrealizowanych.

21) Moduł musi posiadać możliwość tworzenia przypisu odsetek na koniec miesiąca bądź kwartału w postaci dokumentów not odsetkowych lub w postaci odsetek obliczonych, uwzględnianych na wydrukach sprawozdania RB27s

22) Moduł musi posiadać możliwość zastosowania różnych rodzajów operacji księgowych umożliwiających analizę wpłat, np. wpłaty gotówkowe, wyciągi bankowe, przerachowania

23) Moduł musi współpracować z modułem obiegu dokumentów, systemem finansowo- księgowym, platformą PUAP/e-boi.

XV. Obsługa płatności masowych realizowanych za pośrednictwem banku.

oju o

System ma służyć do komunikacji z systemami bankowymi w zakresie obsługi płatności masowych oraz importem wyciągów wpłat z terminali płatniczych. Współpracować ma z modułami podatkowymi oraz opłatowymi dostarczanego oprogramowania w ramach zamówienia. Moduł ma

umożliwiać automatyczne rozksięgowanie wpłat na indywidualne rachunki bankowe, generowane w podsystemach wymiarowych i/lub windykacyjnych. Rozksięgowanie wpłat odbywa się na podstawie plików przesłanych przez bank.

Umożliwiać ma sporządzanie zestawień na podstawie wpłat przyjętych/zaksięgowanych w systemach dziedzinowych (podatki/opłaty).

Wymagania:

1) zdefiniowanie parametrów do tworzenia plików z wpłatami,

2) pobieranie plików transakcji przesłanych przez bank,

3) podpięcie plików pod wyciąg bankowy,

4) automatyczne rozksięgowanie wpłat z możliwością zmiany sposobu zaksięgowania zgodnie z tytułem wpłaty podanym przez wpłacającego,

5) uzgodnienie wyciągu bankowego.

Pakiet ewidencyjny

I. Moduł ewidencji ludności i wybory

1) Moduł musi posiadać homologację RCI PESEL.

2) Moduł musi prawidłowo realizuje funkcje w zakresie ustalonym dla Lokalnych Banków Danych ewidencji ludności.

3) Możliwość tworzenia geografii bazy danych na potrzeby wyborów, naboru do szkół itp.

4) Moduł musi mieć możliwość obsługi:

a) zameldowań,

b) wymeldowań,

c) rejestracja urodzeń,

d) rejestru stanu cywilnego

e) rejestru zgonów.

5) Moduł musi mieć możliwość obsługi zawiadomień w zakresie meldowania, wymeldowania, rejestracji urodzeń, zgonów, zmian w stanie cywilnym.

6) Moduł musi umożliwiać obsługę masowych wydruków w zakresie wyborców, wydanych i używanych dokumentów tożsamości oraz inne listy mieszkańców według dowolnych parametrów szukania.

oju o

7) Moduł musi posiadać mechanizmy umożliwiające wykonywanie akcji rejestrujących na podstawie aktów wystawionych w obszarze USC (np. rejestracja zgonu mieszkańca na podstawie aktu zgonu wystawionego w obszarze USC, rejestracja małżeństwa na podstawie aktu małżeństwa, rejestracja urodzenia i zameldowanie noworodka, zmiana nazwiska i

imienia, oraz danych osobowych itp.) w tym zakresie powinien zostać zintegrowany z modułem obsługującym USC, aby zapewnić tą funkcjonalność dla zdarzeń z obszaru działania USC w Kętrzynie automatycznie po jej zarejestrowaniu w USC Kętrzyn.

8) Wprowadzenie do ewidencji nowej osoby przez:

a) zameldowanie stałe lub czasowe,

b) rejestrację noworodka,

c) import aktów urodzenia z USC.

9) Moduł musi posiadać wykaz osób podlegających rejestracji do kwalifikacji wojskowej oraz listę stawiennictwa do kwalifikacji wojskowej.

10) Moduł musi przechowywać pełną historię mieszkańca (historia wszystkich zmian danych w adresach, meldunkach, nieobecności czasowych, stanów cywilnych, imion, nazwisk itp.).

11) Moduł musi umożliwić wyszukiwanie informacji o mieszkańcach według dowolnie zdefiniowanych i wskazanych parametrów

12) Moduł, w zakresie obsługi wyborców, musi mieć możliwość tworzenia i przeglądu rejestru wyborców z możliwością wykreślenia ze spisu głównego.

13) Moduł w zakresie obsługi wyborców musi mieć możliwość tworzenia rejestrów dodatkowych wyborców (karty zielone i niebieskie, wpisy jednorazowe oraz zmiany adresów głosowania).

14) Moduł w zakresie obsługi wyborców musi mieć możliwość wpisywania do rejestru dodatkowego wyborców z zamkniętych obwodów (ze szpitali, więzień itp.).

15) Moduł w zakresie obsługi wyborców nie głosujących musi mieć możliwość elastycznego tworzenia rejestrów

16) Moduł w zakresie obsługi wyborców musi mieć możliwość definiowanie obszarów oraz tworzenia wersji geografii pod wybory.

17) Moduł w zakresie obsługi wyborców musi zapewniać weryfikację geografii obszarów spisowych pod względem nieobjętych adresów.

18) Moduł w zakresie obsługi wyborców musi umożliwić generowanie kwartalnych meldunków dla KBW (Krajowego Biura Wyborczego) o stanie wyborców w mieście.

19) Moduł musi mieć możliwość masowej korekty danych adresowych (np. zmiana kodu terytorialnego, zmiana ulicy itp.).

20) Moduł musi mieć możliwość definiowania przez użytkownika obszarów geograficznych według dowolnie zdefiniowanych danych (wiek, miejscowość, ulica, nr domu) oraz otrzymywanie wykazów osób z danego obszaru.

21) Zestawienie informacyjne LBD - np. ilość mieszkańców na wybranej ulicy na dany dzień z zakresami wiekowymi wg płci.

oju o

22) Moduł musi mieć możliwość tworzenia i obsługi edytowalnych szablonów pism wystawianych przez urząd w celu dostosowania wydruków do własnych potrzeb

użytkownika.

23) Moduł musi mieć możliwość otrzymania zestawienia statystycznego: DW1, DW2, DW3 i ich przekazywanie do GUS w formie elektronicznej.

24) Moduł musi mieć możliwość tworzenia i wydruku listy mieszkańców wg wybranych parametrów oraz wybranych danych (generator wydruków)

25) Moduł w zakresie obsługi wyborców musi mieć możliwość utworzenia, co najmniej wydruków:

a) spisów dodatkowych (osoby dodane do rejestru dodatkowego po głównym drukowaniu spisów wyborczych),

b) meldunku o stanie rejestru wyborców w poszczególnych okręgach i obwodach,

c) zaświadczenia o prawie do głosowania z automatycznym usunięciem z głównej listy wyborców,

d) zawiadomienia o dopisaniu do rejestru wyborców w gminie,

e) niezależnych list kart (zielonych, różowych) oraz wpisów jednorazowych wyborców nie głosujących i dodatkowych dla poszczególnych dat wyborów.

26) Drukowanie KOM, wszystkich wezwań, zaświadczeń, poświadczeń i zawiadomień, oraz adresowanie kopert do urzędów.

27) Prowadzenie rejestrów osób poszukiwanych przez policję, utraconych dowodów osobistych, udostępnień danych osobowych

Szczegółowy opis funkcjonalności:

A. Ewidencja Ludności

1) Ewidencje mieszkańców:

- Stali mieszkańcy;

- Czasowi mieszkańcy;

- Czasowi do 3 miesięcy;

- Byli mieszkańcy;

- Niepotwierdzeni;

2) Rejestracja:

- zameldowania na pobyt stały (sprawdzanie poprawności i unikalności numeru PESEL);

- zameldowania na pobyt czasowy – powyżej i poniżej trzech miesięcy (sprawdzanie poprawności i unikalności numeru PESEL);

- wymeldowania z pobytu stałego lub czasowego (także na podstawie decyzji administracyjnej);

- przemeldowania osoby;

oju o

- emigracji stałej lub czasowej osoby;

- zgonu osoby;

- zastrzeżenia adresu;

- sprzeciwu dotyczącego przetwarzania danych osobowych;

- wszczęcia postępowania meldunkowego;

3) Wyszukiwanie osób według różnych kryteriów np.:

- numeru PESEL (także poprzedniego numeru PESEL);

- nazwiska, nazwiska poprzedniego, nazwiska xxxxxxxx;

- imion, imion poprzednich;

- adresu zameldowania (aktualnego, czasowego, byłego) – według miejscowości, ulicy, nr budynku, nr lokalu, zakresu dat zameldowania, kodu gminy;

- danych urodzenia – według daty urodzenia, miejscowości urodzenia, aktu urodzenia, imion rodziców, nazwiska rodowego matki;

- obywatelstwa;

- danych dot. stanu cywilnego – według rodzaju stanu cywilnego, numeru aktu stanu cywilnego;

- danych dot. dokumentów – według rodzaju dokumentu, serii dokumentu, numeru dokumentu;

- rodzaju zameldowania;

- Po wyszukaniu osób według wybranych powyższych kryteriów istnieje możliwość wydrukowania listy takich osób.

4) Przeglądanie szczegółów danych osoby.

5) Zmiana danych personalnych osoby (w przypadku zaistnienia faktycznych zmian):

- zmiana nazwiska;

- zmiana imienia;

- zmiana numeru PESEL;

- zmiana nazwiska z poprzedniego małżeństwa;

- zmiana obywatelstwa;

- zmiana stanu cywilnego;

- zmiana statusu wyborczego;

- przysposobienie;

- zgon osoby;

6) Zmiana danych adresowych (w przypadku zaistnienia faktycznych zmian):

- przemeldowanie (zmiana adresu stałego lub czasowego w obrębie gminy);

- zameldowanie na pobyt stały osoby zameldowanej na pobyt czasowy (nie jest powtarzana rejestracja);

oju o

- zameldowanie na pobyt czasowy osoby zameldowanej na pobyt stały (nie jest

powtarzana rejestracja);

- zmiana daty przy zameldowaniu czasowym do 3 m-cy;

- zmiana daty przy zameldowaniu czasowym powyżej 3 m-cy;

- wymeldowanie z pobytu stałego i czasowego;

- wymeldowanie za granice kraju – emigracja;

- zastrzeżenie adresu;

- postępowanie meldunkowe;

7) Zmiana danych dotyczących dokumentów tożsamości:

- wprowadzenie nowego dokumentu;

- wprowadzenie potwierdzenia odbioru dokumentu;

- zmiana daty ważności dokumentu;

8) Poprawki (w przypadku pomyłki pracownika lub nieczytelnych dokumentów) danych dotyczących:

- nazwiska;

- nazwiska rodowego;

- nazwiska z poprzedniego małżeństwa;

- imion;

- urodzenia;

- aktualnego adresu stałego i czasowego;

- dokumentu tożsamości;

- stanu cywilnego;

- obywatelstwa;

- rysopisu;

- danych wojskowych;

- zgonu;

9) Uzupełnianie archiwalnych danych:

- poprzednie nazwiska;

- poprzednie nazwiska z poprzedniego małżeństwa;

- poprzednie imiona;

- poprzednie numery PESEL;

- poprzednie adresy stałe i czasowe;

- poprzednie dokumenty;

- poprzednie stany cywilne;

- poprzednie dane dotyczące urodzenia;

10) Przywrócenia wymeldowanej osoby do kartoteki stałych lub czasowych mieszkańców;

oju o

11) Weryfikacja poprawności i kompletności danych osoby;

12) Rejestrowanie zapytań o dane osobowe:

- rejestrowanie zapytania o wybrane dane osobowe;

- możliwość rejestrowania zapytań o dane osobowe osób, które nie znajdują się w Ewidencji Ludności;

- możliwość rejestrowania zapytań wielokrotnych;

13) Zapytania o dane osobowe – wydruki:

- wydruk odpowiedzi na zapytania o dane osobowe;

- wydruk odpowiedzi o niefigurowaniu osoby w Ewidencji Ludności (dla zapytań o dane osób spoza ewidencji);

- wydruk listy zapytań dot. wybranej osoby;

- wydruk listy zapytań zarejestrowanych w wybranym czasie;

14) Zliczanie liczby mieszkańców według ulic, budynków i lokali.

15) Zmiany nazw ulic we wszystkich zbiorach podsystemu;

- zmiana nazwy całej ulicy;

- zmiana nazwy części ulicy;

- nadanie nazwy ulicy;

16) Generowanie protokołów 0/B i 1/B dla TBD.

17) Statystyka wydruku raportów:

- dla wybranego operatora dla wybranego zakresu dat;

- dla wybranego raportu dla wybranego zakresu dat;

18) Generowanie statystyk na potrzeby GUS-u.

19) Wydruki:

- zawiadomienie dla gminy o zameldowaniu osoby na pobyt stały lub czasowy;

- zawiadomienie dla gminy o wymeldowaniu osoby z pobytu czasowego;

- odpowiedź na zawiadomienie z innej gminy o zameldowaniu osoby na pobyt stały;

- zaświadczenia/potwierdzenia zameldowania osoby na pobyt stały;

- zaświadczenia/potwierdzenia wymeldowania osoby z pobytu stałego;

- zaświadczenia/potwierdzenia zameldowania osoby na pobyt czasowy;

- zaświadczenia/potwierdzenia wymeldowania osoby z pobytu czasowego;

- pełne dane osoby;

- zawiadomienia o zmianach w danych osoby;

- zawiadomienia do WKU (Wojskowa Komisja Uzupełnień);

- historia wszystkich zmian przeprowadzonych na osobie przez poszczególnych operatorów podsystemu;

- statystyka operacji wykonanych przez operatorów dla wybranego okresu czasu;

oju o

- lista dokumentów nieodebranych w ciągu dwóch miesięcy od daty wystawienia;

- lista zameldowanych w gminie cudzoziemców spoza UE;

- spis budynków zamieszkanych;

- wydruk zliczający liczbę lokali na każdej z ulic gminy;

- list osób zameldowanych pod wybranym adresem dla wybranego okresy czasu;

20) Obsługa słowników modułu.

B. Wybory

1) Tworzenie i modyfikacja podziałów na:

- okręgi;

- obwody;

- obwody zamknięte;

- ulice;

2) Sprawdzanie poprawności podziału:

- rejonizacja adresów;

- weryfikacja spójności;

- kompletność;

- sprawdzanie ulic archiwalnych;

3) Obsługa rejestru wyborców i spisów wyborców:

- rejestracja wyborcy;

- edycja danych wyborcy;

- określenie statusu wyborczego;

- pełnomocnictwa;

4) Import list osób głosujących w obwodach zamkniętych;

5) Obsługa komisji wyborczych:

- listy kandydatów, członków, kandydatów odrzuconych;

- wypłaty;

- wydruki składów;

- eksport XML;

6) Tworzenie list wyborczych;

7) Statystyka wyborcza (np.: do PKW);

8) Wydruki:

- listy wyborcze;

- zaświadczenia (np.: Zaświadczenie o prawie do głosowania);

- zawiadomienia (np.: Zawiadomienie o wpisaniu do rejestru wyborców);

- decyzje (np.: Decyzja o wpisaniu do rejestru wyborców);

- listy (np.: Lista wydanych zaświadczeń);

oju o

- obwieszczenia wyborcze;

- lista zgonów;

9) Funkcje dodatkowe:

- obsługa list i wezwań związanych z poborem do wojska;

- tworzenie list dla szkół;

- użycie geografii wyborczej w Ewidencji Ludności, aby w danych osoby był widoczny okręg (lub obwód) do głosowania.

II. Koncesje na sprzedaż alkoholu

1) Moduł musi automatyczne obliczać wysokości rat w oparciu o rodzaj zezwolenia, okres na jaki zostało wydane, oraz wysokości sprzedaży za poprzedni rok.

2) Moduł powinien przechowywać informacje o wysokości sprzedaży w roku poprzednim.

3) Moduł powinien przechowywanie informacji o ratach za lata poprzednie oraz w roku bieżącym

4) Moduł musi posiadać możliwość prowadzenia dowolnej liczby rejestrów.

5) Moduł musi posiadać możliwość wprowadzenia wielu osób otrzymujących zezwolenie.

6) Moduł musi posiadać możliwość zasilenia kartoteki osób z ewidencji ludności,

7) Moduł musi mieć możliwość prowadzenia następujących ewidencji:

a) wniosków o wydanie zezwolenia,

b) wydanych zezwoleń,

c) wygasłych zezwoleń,

d) punktów, którym cofnięto zezwolenia,

e) skarg na punkt,

f) kontroli przeprowadzonych w punkcie.

8) Moduł musi mieć możliwość prowadzenia następujących zestawień:

a) punktów sprzedających alkohol

b) wydanych zezwoleń

c) wysokości rat dla zezwoleń

d) nie zapłaconych w terminie rat za korzystanie z zezwoleń.

9) Informacja o wysokości rat do zapłaty za korzystanie z zezwoleń w bieżącym roku.

10) Potwierdzenie dokonania opłaty za korzystanie z zezwoleń.

11) Polecenie przelewu – druk dla przedsiębiorcy - sumarycznie dla wybranej raty za korzystanie z zezwoleń w danym punkcie sprzedaży.

12) Możliwość stworzenia dowolnego wydruku w oparciu o dane wprowadzone do systemu.

oju o

13) Moduł musi współpracować z systemem obsługującym kasę urzędu (wysyłanie informacji o wysokości płaconych rat)

14) Współpraca modułu z systemem finansowo – księgowym.

15) Moduł powinien umożliwiać pobieranie danych z formularzy elektronicznych złożonych za pośrednictwem ESP np. oświadczeń o sprzedaży napojów alkoholowych.

Pakiet Gospodarka Odpadami

I. Moduł gospodarowania odpadami

1) Moduł musi mieć możliwość utworzenia bazy płatników na podstawie zasilenia danymi z innych obszarów systemu - automatyczne tworzenie bazy płatników np. z Ewidencji ludności lub podatników podatku od nieruchomości.

2) Moduł musi mieć możliwość obsługi deklaracji płatników w zakresie gospodarowania odpadami.

3) Moduł musi umożliwiać tworzenia następujących zestawień na podstawie danych zawartych w deklaracji z :

a) ze wszystkich deklaracji:

- ilości osób zamieszkujących w nieruchomościach zadeklarowanych segregację,

- ilości osób zamieszkujących w nieruchomościach zadeklarowanych nie segregację,

- łącznej zaległości,

- łącznej należności.

b) z deklaracji obejmujących zabudowę mieszkaniową wielorodzinną:

- ilości osób zamieszkujących w nieruchomościach zadeklarowanych segregację,

- ilości osób zamieszkujących w nieruchomościach zadeklarowanych nie segregację,

- łącznej zaległości,

- łącznej należności.

c) z deklaracji obejmujących zabudowę mieszkaniową jednorodzinną:

- ilości osób zamieszkujących w nieruchomościach zadeklarowanych segregację,

- ilości osób zamieszkujących w nieruchomościach zadeklarowanych nie segregację,

- łącznej zaległości,

- łącznej należności.

oju o

4) Moduł musi mieć możliwość wspomagania weryfikacji deklaracji wraz z możliwością korygowania danych i wprowadzania nowych, ujawnionych i zweryfikowanych danych, wraz

z zapamiętaniem statusu weryfikacji deklaracji.

5) Zakres informacyjny deklaracji musi obejmować wszystkie dane niezbędne do realizowania obowiązków w zakresie gospodarowania odpadami:

a) klasyfikacja nieruchomości,

b) liczba zamieszkujących osób,

c) zużycie wody,

d) informacja o segregowaniu odpadów,

e) preferencje dotyczące częstości rozliczania (okresy rozliczeniowe).

6) Moduł musi mieć możliwość zautomatyzowanego tworzenie decyzji w sprawie opłat za wywóz nieczystości (wymaganie dotyczy wszystkich rodzajów odpadów i nieczystości, za które odpowiada gmina).

7) Moduł musi zapewnić mechanizm windykacji opłat, w tym tworzenia wezwań do zapłaty.

8) Obsługa opłat w zakresie odbioru odpadów musi być zintegrowana z obszarem księgowości budżetowej, pozostałych opłat, windykacji.

9) Moduł musi umożliwiać prowadzenie rejestru umów z firmami odbierającymi odpady.

10) Moduł musi mieć możliwość rejestrowania danych z raportów obowiązkowo tworzonych przez firmy odbierające odpady.

11) Moduł musi zapewnić możliwość naliczania i egzekwowania kar za niewłaściwe realizowanie umów przez firmy odbierające odpady.

12) Moduł musi zapewnić tworzenie wymaganych przez prawo raportów w zakresie gospodarowania odpadami.

13) Moduł musi umożliwiać prowadzenie ewidencji zaległości z możliwością wydawania oraz drukowania postanowień o wszczęciu postępowania, decyzji określających zaległość, upomnień oraz tytułów wykonawczych.

14) Współpracować z modułem kasa z zastosowaniem kodów kreskowych do identyfikacji wpłacającego.

15) Moduł musi automatyczne wykonywać sprawozdanie RB-27 na podstawie zapisów księgowych.

16) Moduł musi automatyczne wykonywać sprawozdanie RBN na podstawie zapisów księgowych.

17) Moduł musi umożliwiać podgląd z możliwością wydruku kartoteki konta z uwzględnieniem aktualnych odsetek do wszystkich zaległości.

18) Moduł musi umożliwiać prowadzenie ewidencji upomnień, tytułów wykonawczych i postanowień o zarachowaniu wpłat.

oju o

19) Moduł musi współpracować z czytnikami kodów kreskowych.

20) Moduł musi umożliwiać tworzenia książki nadawczej dla korespondencji wysyłanej.

21) Moduł musi współpracować z modułem obiegu dokumentów EOD, systemem finansowo- księgowym, kasą, posiadać możliwość wczytywania do systemu informacji i załączników złożonych przez podatnika za pomocą platformy e-deklaracje/e-podatki/e-boi

22) Moduł musi posiadać możliwość wygenerowania indywidualnych kont bankowych i wysłania odpowiednich zawiadomień do podatników.

Pozostałe wymagania

I. Wymagania w zakresie wdrożenia

1. Wykonawca dostarczy odpowiednią ilość licencji dla wyspecyfikowanych modułów.

2. Wykonawca skonfiguruje dostarczoną platformę serwerową pod kątem wdrożenia wyspecyfikowanych modułów.

3. Wykonawca zainstaluje wszystkie wymagane komponenty (w tym systemy operacyjne, bazodanowe) niezbędne do poprawnego funkcjonowania wyspecyfikowanych modułów.

4. Wykonawca dokona migracji danych w zakresie umożliwiającym generowanie wymiaru podatkowego w roku 2014/2015. Zakres migracji opisany został poniżej.

5. Wykonawca przeszkoli użytkowników oraz administratorów wdrażanych rozwiązań.

6. Wykonawca przeznaczy łącznie nie mniej niż 180 godzin wdrożeniowych/szkoleniowych na realizację projektu w zakresie opisanych modułów.

II. Wymagania w zakresie migracji danych

1. Wykonawca dokona migracji danych podatkowych zarówno z systemu wymiarowego i księgowego (dotyczy wszystkich zamawianych modułów podatkowych). Obecnie wykorzystywanym systemem jest: PUMA spółki ZETO OLSZTYN.

2. Wykonawca dokona migracji danych z systemu gospodarki odpadami zarówno z systemu wymiarowego jak i księgowego. Obecnie wykorzystywanym systemem jest: PUMA spółki ZETO OLSZTYN.

3. Wykonawca dokona migracji danych z systemu kadro-płacowego. Obecnie wykorzystywanym systemem jest: PUMA spółki ZETO OLSZTYN.

4. Wykonawca dokona migracji danych z systemu czynszowego i użytkowania wieczystego zarówno z systemu ewidencyjnego i księgowego. Obecnie wykorzystywanym systemem jest: moduł spółki ZETO OLSZTYN (działającym w systemie DOS).

oju o

5. Wykonawca dokona migracji danych mieszkańców z ewidencji ludności. Obecnie wykorzystywanym systemem jest: PUMA spółki ZETO OLSZTYN i zintegruje dostarczony

moduł ewidencji ludności z modułem ewidencji zdarzeń stanu cywilnego PB_USC spółki Technika IT SA Gliwice wykorzystywanym w USC Kętrzyn.

6. Wykonawca wprowadzi BO do systemu księgowego.

III. Wymagania w zakresie szkoleń

1. Wykonawca przeszkoli użytkowników z zamawianych modułów. Szkolenia z systemów dziedzinowych muszą być realizowane w formie instruktarzy stanowiskowych bezpośrednio na stanowiskach pracy użytkowników.

oju o

2. Szkolenie z pozostałych modułów (w tym EOD) mogą być realizowane w grupach max 10 osobowych przy stanowiskach komputerowych dostarczonych przez Wykonawcę (w formie mobilnej sali szkoleniowej). Odpowiednie pomieszczenie zapewni Zamawiający. Poniższa tabela zawiera liczbę użytkowników do przeszkolenia (z podziałem na moduły).

Lp.	Nazwa modułu	Liczba użytkowników	Liczba administratorów
1	EOD elektroniczny obiegu dokumentów	60	2
2	e-boi	3	2
3	e-rada	3	2
4	e-konsultacje	4	2
5	e-deklaracje	3	2
6	e-decyzje	7	2
7	e-podatki/e-odpady	6	2
8	Moduł finansowo-księgowy	9	2
9	Moduł rejestru umów (należności i zobowiązania), zaangażowania	3	2
10	Moduł kasa	3	2
11	Moduł fakturowanie i prowadzenie rejestrów VAT	5	2
12	Moduł środki trwałe wyposażenie	4	2
13	Moduł kadry	2	2
14	Moduł płace	2	2
15	Moduł podatki lokalne (wymiar)	3	2
16	Moduł księgowości podatkowej i opłat lokalnych	3	2
17	Moduł akcyza	2	2
18	Moduł opłat z tytułu zajęcia pasa drogowego	2	2
19	Moduł różnych opat	2	2
20	Moduł księgowości różnych opłat	2	2

21	Moduł ewidencji dzierżaw najmu, użytkowania wieczystego	5	2
22	Moduł księgowości dochodów z dzierżaw, najmu, użytkowania wieczystego	2	2
23	Obsługa płatności masowych	2	2
24	Ewidencja ludności i wybory	4	2
25	Koncesje na sprzedaż alkoholu	2	2
26	Gospodarka odpadami - wymiar	2	2
27	Gospodarka odpadami - księgowość	3	2

IV. Wymagania w zakresie gwarancji i wsparcia technicznego

1. Gwarancja na oprogramowanie EOD, e-Kętrzyn i ZSI wyspecyfikowane powyżej udzielona zostaje na okres 60 miesięcy.

2. Wsparcie techniczne oprogramowanie EOD, e-Kętrzyn i ZSI realizowane będzie przez okres 36 miesięcy.

3. Gwarancja na sprzęt udzielona zostaje na okres zgodny z zapisami zawartymi w części sprzętowej.

4. Wykonawca w ramach projektu uruchomi dedykowaną platformę zgłoszeń Help Desk.

5. Wykonawca, w ramach wsparcia technicznego będzie świadczył na rzecz Zamawiającego następujące usługi:

a. Pomoc telefoniczną w zakresie użytkowania wdrożonych modułów świadczoną przez wyspecjalizowany dział Wykonawcy, w dni robocze, w godzinach 8:00 – 16:00.

b. Usuwanie błędów działania modułów, odpowiednio:

− w ciągu 48 godzin od zgłoszenia, w przypadku błędów krytycznych, uniemożliwiających pracę systemów,

− w ciągu 14 dni roboczych od zgłoszenia, w przypadku innych błędów.

c. Dostosowywanie modułów do zmian przepisów prawnych związanych bezpośrednio z ich funkcjonowaniem.

d. Dostęp do zdalnej asysty technicznej

6. Aktualizacje pobierane są automatycznie po akceptacji ze strony Administratora modułów.

7. Aktualizacje modułów muszą być dystrybuowane automatycznie na wszystkie stanowiska użytkowników.

V. Wymagany poziom integracji na dzień złożenia oferty

oju o

a) EOD <-> moduły wymiaru podatkowego – zautomatyzowany proces przekazywania decyzji podatkowych i inicjowania na ich podstawie spraw zgodnych z JRWA,

b) EOD <-> moduły wymiaru podatkowego – obsługa korespondencji seryjnej (masowa obsługa decyzji podatkowych z poziomu kancelarii EOD),

c) EOD <-> moduł księgowości – zautomatyzowany proces księgowania na podstawie informacji o doręczeniu decyzji podatkowych generowanych z poziomu kancelarii EOD.

d) EOD <–> moduł księgowości - zautomatyzowany proces obsługi wniosków zakupowych oraz faktur VAT (sprawdzenie dostępności środków, według podziałek klasyfikacji budżetowej, dekret księgowy, zaangażowanie środków).

e) EOD <–> moduł księgowości - zautomatyzowany proces obsługi umów (sprawdzenie dostępności środków, według podziałek klasyfikacji budżetowej, dekret księgowy, zaangażowanie środków).

f) Moduły wymiaru podatkowego -> moduł ewidencji ludności (pobieranie danych podatników w czasie rzeczywistym)

g) Moduł ewidencji ludności <–> moduł USC zautomatyzowany proces przekazywania danych celem uzupełnienia aktualizacji rejestrów i danych w nich zawartych

h) EOD<-> wymiana danych z e-boi i ePUAP (w zakresie opisanym w specyfikacji)

i) EOD <-> e-rada (współpraca w opisanym zakresie)

j) EOD<-> edytor aktów prawnych XML (współpraca w opisanym zakresie)

k) EOD<-> ePUAP

l) e-konsultacje <-> edytor aktów prawnych XML

m) Zintegrowany System Informacyjny <-> współpraca z e-boi i ePUAP w zakresie obsługi e- formularzy.

n) Moduły księgowości i wymiaru podatkowego <-> portal e-Kętrzyn (wymiana danych).

VI. Inne wymagania

1) Oferowany system w dniu składania ofert nie może być przeznaczone przez producenta do wycofania z produkcji, sprzedaży lub z wsparcia technicznego.

2) Wymaga się , aby dostarczone oprogramowanie było oprogramowaniem w wersji aktualnej na dzień składania ofert;

3) Do oferty należy dołączyć próbkę systemów backoffice wchodzących w skład ZSI.

VII. Wymagania w zakresie dostarczenia wersji DEMO

oju o

Zamawiający zobowiązany jest do złożenia wraz z ofertą, w celu potwierdzenia spełniania warunku dysponowania odpowiednim potencjałem technicznym oraz osobami zdolnymi do wykonania zamówienia płytę (y) instalacyjną (e) CD/DVD zawierającą (e) oprogramowanie demonstracyjne (spełniające wymagania zawarte w SIWZ) systemu informatycznego składającego się minimum z modułów wymiaru podatkowego, księgowości podatkowej i budżetowej, kasy, kadr, systemu obiegu dokumentów, e-konsultacje, e-boi wraz instrukcją instalacji oprogramowania demonstracyjnego w formie dokumentu.