Lp. Opis wymagania 1 Wymagania ogólne dotyczące budowy SEOD
Transkrypt
Lp. Opis wymagania 1 Wymagania ogólne dotyczące budowy SEOD
BDG/12/2011/PN zał. nr 3 Wymagania funkcjonalne Spełnienie wymogów Lp. Opis wymagania TAK/NIE 1 Wymagania ogólne dotyczące budowy SEOD 1.1 SEOD musi umożliwiać wydajną, efektywną i ergonomiczną pracę co najmniej 400 pracowników równocześnie, z dostępem przez przeglądarkę internetową w środowisku LAN oraz WAN równocześnie. Centralna lokalizacja serwera SEOD w Wyższym Urzędzie Górniczym z dostępem przez LAN i WAN. 1.2 SEOD musi być przygotowany na rozbudowę w przyszłości i obsługę dodatkowej ilości użytkowników. Docelowa pojemność w perspektywie 5 lat to 550 użytkowników. Udzielone licencje SEOD oraz wszystkich komponentów 1.3 potrzebnych do użytkowania SEOD, w tym komponentów firm trzecich, muszą być bezterminowe, a ich użytkowanie nie może wiązać się i być uzależnione w przyszłości, od ponoszenia przez Zamawiającego dodatkowych kosztów. 1.4 Zamawiający nie wymusza konkretnego rozwiązania planu licencyjnego, pod warunkiem, że użytkownicy kończący pracę w systemie (odchodzący na emeryturę, zwalniani itp.) będą uzyskiwać status np. nieaktywny oraz zwalniać licencję dla nowego użytkownika, jednocześnie pozostając w systemie, celem identyfikacji spraw które prowadzili w przeszłości, bez konieczności przekazywania ich zamkniętych spraw innemu użytkownikowi. Użytkownicy tacy nie mogą się też pojawiać na listach wyboru aktualnie aktywnych użytkowników. Inaczej mówiąc SEOD musi pozwalać niezmiennie w czasie na pracę co najmniej 400 aktywnym użytkownikom. W wypadku zaoferowania wariantu licencyjnego w postaci ilości 1.5 jednocześnie zalogowanych użytkowników i automatycznego zamykania sesji po określonym czasie nieaktywności, SEOD musi pozwalać na konfigurację czasu po którym nastąpi wylogowanie sesji użytkownika do min. 120 min Użytkownicy muszą posiadać aktywną sesję pomimo braku aktywności przez min.120 min SEOD musi posiadać wbudowane i możliwe do wskazania funkcje 1.6 zbudowane z użyciem mechanizmów AJAX. Funkcje takie powinny występować co najmniej w: • Rejestracji dokumentu – podczas pobierania danych podmiotu będącego adresatem lub nadawcą dokumentu • Generowaniu listy folderów (przynajmniej na jednym z silników baz danych) • Podczas generowania listy użytkowników przy rozsyłaniu dokumentów lub przydzielaniu spraw • Podczas weryfikowania sumy kontrolnej pliku dołączonego do sprawy lub dokumentu Strona 1 z 51 1.7 1.8 1.9 1.10 1.11 1.12 • Podczas korzystania z funkcji przejęcia danych (przekazywanie danych pomiędzy użytkownikami systemu) • Podczas edycji danych pracownika (przy wyborze stanowiska pracy) • Module delegacji, przy wyborze środka lokomocji • Module urlopów przy wyliczaniu liczby dni urlopu SEOD musi być zbudowany w architekturze, co najmniej trójwarstwowej. Serwer SEOD musi być niezależny od platformy systemowej, i powinien poprawnie funkcjonować pod kontrolą systemów operacyjnych z rodziny UNIX np. Linux oraz Windows. Aplikacja musi mieć budowę modułową umożliwiającą uruchamianie kolejnych funkcji poprzez zmianę parametrów konfiguracji systemu. Przez moduł rozumie się wydzieloną funkcjonalność systemu, której uruchomienie odnosi efekt w postaci pojawienia się nowych funkcji i elementów w SEOD np.: Terminarze, JRWAUG, Delegacje itp. Budowa modułowa musi umożliwiać stopniowe uruchamianie kolejnych funkcjonalności wraz ze wzrostem wiedzy oraz potrzeb użytkowników, przeprowadzone przez użytkownika na prawach administratora, poprzez zmianę parametrów systemu, bez potrzeby zmiany kodów programu i pomocy programisty. Żadne informacje wprowadzone do SEOD nie mogą być z niego usunięte, nawet przez Administratora. Jedyną możliwością usunięcia elementów z SEOD jest proces brakowania akt. Wszystkie elementy SEOD muszą posiadać interfejs w języku polskim. Jako element interfejsu zamawiający określa również elementy konfiguracji poszczególnych części składowych systemu – szczególnie część użytkownika oraz część administracyjną, jak również wszystkie aplikacje wymagane przy pracy z systemem SEOD. W języku polskim muszą być również wyświetlane wszystkie komunikaty przekazywane przez SEOD, włącznie z komunikatami o błędach. SEOD musi być zbudowany w oparciu o dostępne na rynku i stabilnie działające komponenty, które zostaną skonfigurowane i uruchomione przez Wykonawcę w postaci spójnego systemu. Konieczne jest by dostarczone komponenty posiadały wsparcie producenta przez okres co najmniej równy wymaganej gwarancji na system. Strona 2 z 51 1.13 Wykonawca musi być producentem dostarczanego Systemu i musi być uprawniony do wprowadzania modyfikacji w kodzie źródłowym aplikacji. W przypadku gdy wykonawca oferuje moduły firmy trzeciej musi być upoważniony przez producenta oprogramowania do wprowadzania modyfikacji w kodzie źródłowym aplikacji, celem ewentualnego dostosowania, obecnie i w przyszłości, systemu do potrzeb Zamawiającego. Modyfikacja kodów źródłowych nie jest przedmiotem postępowania. 1.14 Dostarczony SEOD musi być w pełni konfigurowalny bez konieczności modyfikacji kodu źródłowego, w którym został utworzony. Niedopuszczalne jest by dostarczone oprogramowanie wymagało parametryzacji poprzez modyfikację kodu aplikacji oraz angażowania programistów. Wszystkie elementy SEOD muszą umożliwiać poprawną pracę poprzez przeglądarkę internetową co najmniej: Internet Explorer w wersji 8 lub nowszej, Firefox w wersji 3 lub nowszej, Chrom w wersji 10 lub nowszej. Skanowanie dokumentów, podpis elektroniczny, funkcje integracji z zewnętrznym oprogramowaniem pocztowym np. Microsoft Outlook, edycja plików - mogą być realizowane poprzez aplikacje instalowane po stronie stacji roboczej. SEOD musi udostępniać możliwość konfiguracji na poziomie globalnym oraz lokalnym. 1. Przez poziom globalny należy rozumieć poziom aplikacji, gdzie opcja konfiguracyjna ma zastosowanie dla całej aplikacji – dostępny dla użytkowników posiadających specjalne uprawnienia. Wymagane jest minimalnie konfigurowanie: a. wspólnej struktury organizacyjnej, b. folderów publicznych, c. rejestrów dokumentów, d. słowników. 2. Przez poziom lokalny należy rozumieć poziom profilu konta pojedynczego użytkownika SEOD gdzie opcja konfiguracyjna ma zastosowanie jedynie dla tego konta – dostępny dla wszystkich użytkowników systemu. Wymagane jest minimalnie: a. Włączanie i wyłączanie powiadomień o nowych elementach przesłanych do użytkownika, b. Wybór sortowania (rosnąco, malejąco, alfabetycznie) elementów systemu tj. spraw, dokumentów, notatek, 1.15 1.16 c. Określenie kolumn widocznych na listach obiektów tj. dokumenty, sprawy, rejestry, lista nowych dokumentów (oczekujących na zarejestrowanie) Strona 3 z 51 1.17 1.18 1.19 1.20 1.21 d. Określanie domyślnego ustawienia dla filtrów dokumentów i spraw, e. Określanie domyślnego rozmiaru i nazwy czcionki używanej podczas tworzenia raportów we wbudowanym w aplikację edytorze WYSIWYG f. Definiowania kont poczty e-mail g. Definiowania zakresu godzin wyświetlanych w terminarzach h. Określania domyślnego celu rozsyłania dokumentu oraz przydzielenia sprawy i. Określenia w jakim profilu użytkownika aplikacja domyślnie ma być uruchamiana (np. administrator, użytkownik zwykły czy operator skanujący) SEOD musi posiadać możliwość zarządzania strukturą folderów z poziomu lokalnego (przez każdego użytkownika) oraz globalnego (z poziomu użytkownika posiadającego specjalne uprawnienia – posiadającego możliwość tworzenia folderów i przydzielania dostępu do tych folderów wybranym użytkownikom). Foldery powinny być rozumiane jako kontenery służące do przechowywania informacji takich jak dokumenty lub sprawy i być niezależne od systematyki wynikającej z Jednolitego Rzeczowego Wykazu Akt Urzędów Górniczych. SEOD musi posiadać obsługę mechanizmu przeciągnij i upuść (ang. Drag And Drop) umożliwiając przenoszenie dokumentów, spraw, notatek do wybranych folderów utworzonych w SEOD. SEOD musi być zabezpieczony przed lukami bezpieczeństwa wynikającymi z technologii, w której został stworzony. Szczególny nacisk musi zostać położony na zabezpieczenie aplikacji przed wstrzykiwaniem kodu SQL (SQL injection) oraz Cross Site Scripting. Odpowiednie mechanizmy zabezpieczające powinny być wbudowane w aplikację. W przypadku wykrycia próby wykonania ataku metodą SQL injection, system powinien wyświetlić (lub zapisać w logach aplikacji) komunikat informujący o wykryciu próby ataku. SEOD musi gromadzić pliki dokumentów,skany, załączniki do spraw, w odrębnym repozytorium plikowym. W bazie danych mogą znajdować się jedynie metadane opisujące dokumenty, pliki, raporty itp. elementy wchodzące w skład spraw prowadzonych w SEOD. SEOD musi umożliwiać rozdzielenie repozytorium plikowego oraz bazy danych na odrębne serwery. Aplikacja musi zabezpieczać repozytorium plikowe tak aby nie było ono bezpośrednio dostępne dla użytkowników (nie mogą to być stałe hiperłącza do plików). Strona 4 z 51 1.22 1.23 1.24 1.25 SEOD musi posiadać możliwość współpracy z przynajmniej jednym silnikiem bazy danych opartym o technologię „open source”, co najmniej MySQL 5 lub nowszy lub PostgreSQL 8 lub nowszy, oraz przynajmniej jednym komercyjnym silnikiem bazy danych, co najmniej MSSQL. SEOD musi posiadać mechanizm zabezpieczający pliki przechowywane w repozytorium plikowym przed ich zmianą. Nawet jeśli plik w repozytorium plikowym zostanie zmieniony – aplikacja musi umożliwiać użytkownikowi zweryfikowanie takiego pliku. Zabezpieczenie powinno być oparte co najmniej o algorytm MD5. SEOD musi posiadać funkcję umożliwiającą wgląd do skompresowanych plików w formatach co najmniej: ZIP, GZIP, TAR, dołączanych do SEOD. Funkcja musi umożliwiać wyświetlenie zawartości skompresowanego pliku bez konieczności zapisywania go na stacji roboczej użytkownika i rozpakowywania. SEOD musi spełniać podstawowe warunki bezpieczeństwa poprzez: zapis operacji wykonywanych przez użytkownika w zakresie: Zapis notatki do sprawy i do dokumentu, Odczyt nowego dokumentu i nowej sprawy przesłanej do użytkownika, Zapis i modyfikacja pliku dodanego do dokumentu i sprawy, Zablokowanie dostępu do sprawy lub dokumentu, Utworzenie sprawy, Nadanie lub usunięcie znaku sprawie, Dołączenie oraz odłączenie dokumentu do/od sprawy, Dodanie oraz usunięcie pliku dołączonego do dokumentu oraz sprawy, Dodanie notatki tekstowej do sprawy oraz dokumentu, Akceptacja oraz odrzucenie pliku, Przekazanie do akceptacji pliku, Połączenie sprawy z wybranym kontaktem z bazy adresowej, Dołączenie oraz odłączenie użytkownika do/od terminarza, Modyfikacja opisu oraz innych parametrów sprawy, Dołączenie oraz odłączenie maila do/od sprawy, Wysłanie dokumentu mailem. zapis w historii wszystkich zmian zachodzących w sprawach, dokumentach lub innych elementach mających wpływ na prowadzone sprawy. szyfrowanie informacji przesyłanych pomiędzy użytkownikiem a systemem z użyciem protokołu SSL, możliwość pracy w systemie poprzez VPN z określonej lokalizacji geograficznej. Strona 5 z 51 1.26 Wszystkie elementy SEOD muszą być dostępne poprzez Graficzny Interfejs Użytkownika tzw. GUI, zgodny co do zasady i obsługi z tzw. okienkowymi systemami operacyjnymi i dostępny przez przeglądarkę internetową. 1.27 SEOD musi umożliwiać rejestracje chronologiczną spraw zgodnie z JRWAUG odrębnie dla każdej jednostki organizacyjnej Zamawiającego 2 Instrukcja obsługi . 2.1 SEOD musi być opatrzony polskojęzyczną instrukcją obsługi przeznaczoną do oferowanej wersji (zwanej dalej instrukcją) opisującą szczegółowo zarówno aspekty techniczne (instalację, konfigurację, wymagane komponenty do poprawnej pracy) oraz funkcjonalne wszystkich elementów. Instrukcja musi być podzielona zgodnie z częściami składowymi 2.2 SEOD oraz jego modułami/funkcjonalnościami. 2.3 Instrukcja musi być opracowana w sposób umożliwiający zidentyfikowanie sposobu wykonania określonej czynności np.: Zakładanie sprawy - użyj funkcji „Załóż sprawę” znajdującej się w … itd. Instrukcja musi być aktualizowana po każdorazowej zmianie części składowej SEOD dokonywanej po stronie Zamawiającego. Instrukcja musi zawierać zrzuty ekranów odnoszące się do opisywanych funkcji. 2.4 Instrukcja SEOD musi zawierać co najmniej następujące elementy: opis działania i zastosowanie poszczególnej części składowej systemu z dokładnością do pojedynczej funkcji, oraz przycisków interfejsu wykorzystywanych do wykonywania konkretnych operacji w systemie. informacja dotycząca poszczególnych funkcji zastosowanych w częściach składowych SEOD musi być przekazana w formie instrukcji krok po kroku opisującej wykonanie określonej czynności. 2.5 Instrukcja opisująca funkcjonalność musi być przygotowana w postaci: instrukcji dostępnej co najmniej z poziomu SEOD (przeglądarki internetowej) w postaci HTML albo XML, pliku pomocy Windows Help (CHM), piku PDF. Zawartość dokumentacji elektronicznej powinna być odpowiednio zindeksowana. 2.6 Instrukcja w formacie CHM, PDF lub innym tekstowym powinna być wyposażona w indeks wyrażeń oraz musi umożliwiać proste wyszukiwanie w treści. Strona 6 z 51 2.7 2.8 2.9 3 3.1 Dla SEOD instrukcja musi być zintegrowana z interfejsem użytkownika; zawierać dostęp do spisu treści oraz wyszukiwania z poziomu SEOD. Treści zawarte w instrukcji dostępnej z poziomu interfejsu użytkownika muszą być identyczne jak dostarczane w plikach chm, html oraz pdf. Wymagane jest załączenie instrukcji oferowanego SEOD do oferty na nośnikach elektronicznych: płycie CD lub DVD. Na podstawie załączonej instrukcji nastąpi weryfikacja funkcjonalności oprogramowania będącego przedmiotem postępowania. W zakresie objętym instrukcją Zamawiający wymaga dostarczenia produktu gotowego, tj. istniejącego na dzień opublikowania postępowania. Wykonawca wskaże w odrębnym dokumencie miejsca (numery, zakresy stron) w instrukcji obsługi opisujące realizację każdego wymagania funkcjonalnego. Dokument winien być złożony jako integralna część oferty. Administracja systemem SEOD musi posiadać narzędzia umożliwiające jego konfigurację poprzez graficzny interfejs (GUI). Konfiguracji poprzez graficzny interfejs muszą podlegać: • Struktura organizacyjna oraz podległości służbowe, • Rejestry dokumentów i spraw, Jednolity Rzeczowy Wykaz Akt Urzędów Górniczych, • Znak separatora w znaku sprawy i oznaczenia dokumentu (do wyboru co najmniej znaki: ‘/’ i ‘.’) • Budowa znaku sprawy i oznaczenia dokumentu w sprawie (tak aby były zgodne z instrukcją kancelaryjną Zamawiającego) • Definicje rodzajów stanowisk (np.: dyrektor, naczelnik) przypisanych do opisu każdego ze stanowisk, • Definicje kategorii dokumentów, plików, notatek i spraw umożliwiające grupowanie tych elementów według kategorii. • Cele (np.: do realizacji, do dekretacji), w których przesyła się dokument, • Definicje sposobów dostarczenia dokumentu, • Definicje folderów i przydzielania dostępu do tych folderów wybranym użytkownikom (foldery rozumiane jako kontenery dla dokumentów), o Do wybranego folderu możliwe musi być przypisanie reguły globalnej umożliwiającej przeniesienie wybranego dokumentu do tego folderu. • Definicje stanów spraw (np.: zamknięta, archiwalna, zawieszona), Strona 7 z 51 4 4.1 4.2 • Definicje formularzy umożliwiające użycie następujących typów pól: o Pole tekstowe, o Pole liczbowe, o Pole opisu, o Pole wyboru (check), o Pole opcji (radio), o Pole kombo, o Pole listy, o Pole daty. • Szablony dokumentów, • Definiowanie terminarzy i przydzielanie uprawnień dostępu do nich użytkownikom, • Użytkownicy, • Rezerwacje zasobów i przydzielanie uprawnień do ich rezerwacji wybranym użytkownikom, • Definicje urlopów, • Definicje zastępstw, • Definicje delegacji, • Definicje ścieżek procesów workflow, • Definicje skrytek i skrzynek przewidzianych do integracji z ePUAP Dokumenty Podczas rejestracji dokumentu SEOD musi umożliwiać przechodzenie pomiędzy kolejnymi polami formularza rejestracji przy pomocy przycisku TAB (tabulacji). SEOD musi umożliwiać opisanie dokumentu przynajmniej następującymi metadanymi: • Podstawowa klasyfikacja: przychodzący, wychodzący, wewnętrzny. • Numer dokumentu – nadawany automatycznie przez SEOD podczas rejestracji dokumentu, unikalny, jednoznacznie identyfikujący rejestrowany dokument w obrębie całego systemu (na podstawie jednego wspólnego rejestru chronologicznego wszystkich pism w roku przychodzących, wychodzących i wewnętrznych - 6 znaków numerycznych z poprzedzającymi zerami), • Sposób dostarczenia – pole słownikowe np.: list zwykły, email, ESP itd. • Oznaczenie komórki do której kwalifikowany jest dokument – pole słownikowe, • Kategoria dokumentu – pole słownikowe np.: podanie, wniosek, skarga itd. Strona 8 z 51 • Adresat/Nadawca - do wyboru z listy adresowej SEOD (z automatycznym wypłnieniem zdefiniowanych pól) na podstawie pierwszych wprowadzonych liter (podpowiedzi kontekstowe) oraz możliwy do wpisania ręcznego w wypadku niedopasowania do istniejącego w bazie, z uwzględnieniem danych teleadresowych, co najmniej pola: 4.3 4.4 o Osoba prawna lub fizyczna, o Skrót, o NIP, o REGON, o PESEL, o Skrytka pocztowa, o Miasto, o Kod pocztowy, o Ulica, o Numer budynku, o Numer lokalu, o Kraj, o Województwo, o Powiat, o Gmina, • Data ważności, • Numer nadawczy, • Opis dokumentu, • Słowa kluczowe, • Lokalizacja fizyczna, • Dowolnie zdefiniowane pola – dostosowywane do wybranej kategorii rejestrowanego dokumentu. SEOD musi posiadać możliwość rozsyłania dokumentów do zdefiniowanej liczby odbiorców bez konieczności jej powielania (każdy dokument w systemie musi istnieć tylko w jednym egzemplarzu). Wszystkie adnotacje i operacje wykonywane przez użytkowników powinny być zapisywane na tym samym dokumencie. SEOD musi posiadać możliwość dołączania do dokumentów i spraw elementów w formie elektronicznej, co najmniej: plików, informacji w postaci tekstowej edytowanej z poziomu SEOD, dokumentów zarejestrowanych w SEOD, spraw założonych w SEOD. Strona 9 z 51 4.5 4.6 4.7 4.8 4.9 4.10 4.11 SEOD musi posiadać możliwość zarządzania wielopoziomową strukturą folderów (wyświetlającą zagnieżdżoną strukturę folderów w postaci drzewa), umożliwiającą grupowanie dokumentów i spraw. W tym celu każdy użytkownik musi posiadać dostęp do odpowiedniej funkcji umożliwiającej mu wybór lokalizacji, w której ma zostać utworzony, usunięty lub zmieniony folder. SEOD musi umożliwiać wydrukowanie poświadczenia przyjęcia pisma. Poświadczenie musi zawierać informacje jednoznacznie identyfikujące dokument, datę jego rejestracji oraz przez kogo został on przyjęty i przez kogo został złożony. Funkcja musi być dostępna z poziomu interfejsu SEOD po rejestracji dostarczonego dokumentu. SEOD musi umożliwiać powiadamianie użytkownika o zmianach zachodzących na jego koncie. Powiadomienia muszą dotyczyć co najmniej: otrzymania nowego dokumentu, otrzymania nowej sprawy, dołączenia do dokumentu lub sprawy pliku, dołączenia do dokumentu lub sprawy notatki tekstowej. Przesyłana informacja powinna zawierać tytuł oraz treść. Treść powinna w jednoznaczny sposób identyfikować element, którego dotyczy powiadomienie. SEOD musi umożliwiać włączanie oraz wyłączanie powiadamiania użytkownika o zmianach w elementach, do których ten ma dostęp. Wyłączenie powiadamiania powinno być dostępne na poziomie grupy elementów jak i pojedynczego elementu np.: dla wszystkich spraw, dla wybranej sprawy. SEOD musi umożliwiać ustawienie następujących parametrów, zapisywanych w metadanych dokumentu, podczas dekretacji: cel – pole słownikowe umożliwiające wybór celu dekretacji, zwrotu dekretacji pilny – oznaczenie dokumentu jako pilny, data ważności – data ważności dokumentu, notatka służbowa – umożliwiające wpisanie informacji dla odbiorcy. uwagi do dekretacji – umożliwiające przekazanie uwag dot. dekretowanego dokumentu do adresata dekretacji. SEOD musi zawierać mechanizm tworzenia wersji dla plików, dokumentów oraz notatek tekstowych. Użytkownik musi mieć możliwość dodania kolejnej wersji pliku. Wszystkie zmiany muszą zostać odnotowane automatycznie w SEOD. SEOD musi sygnalizować próbę użycia nieaktualnej wersji poprzez wyświetlenie odpowiedniej informacji ostrzegawczej w interfejsie użytkownika. Wyszukiwanie proste musi umożliwiać pełnotekstowe przeszukanie elementów SEOD. Przez wyszukiwanie pełnotekstowe rozumie się przeszukiwanie w treści elementów dołączanych do spraw, czy dokumentów (w treści raportów, notatek, plików tekstowych). Strona 10 z 51 4.12 4.13 4.14 4.15 4.16 W przypadku gdy użytkownik nie posiada uprawnień umożliwiających mu wyświetlenie treści odnalezionego elementu, SEOD musi informować o tym fakcie podczas dostępu do tego elementu poprzez wyświetlenie odpowiedniego komunikatu. Po odnalezieniu elementów (spraw, dokumentów lub innych) SEOD powinien grupować je w formie zakładek według ich typu (sprawy, dokumenty itd.) oraz wyświetlać liczbę trafień odnalezionych dla wybranego typu. SEOD powinien wyróżniać kolorem odnalezioną frazę w liście wybranych elementów umożliwiając użytkownikowi identyfikację jej wystąpienia. Podczas wyszukiwania prostego możliwe powinno być użycie następujących znaków specjalnych: • % (procent) – umożliwiający wyszukanie innych słów za, przed lub za oraz przed wyszukiwanym słowem, np.: %słowo, Słowo%, %słowo%, • (podkreślenie) – umożliwiające wyszukanie słów, których pełne znaczenie nie jest znane. Ilość znaków podkreślenia w słowie oznacza ilość znaków, które powinny zostać zastąpione, np.: sł__o (zostanie odnalezione słowo), ____słowo (zostanie odnalezione np.: pomysłowo), • „” cudzysłów – umożliwiający odnalezienie wyrazów następujących po sobie, • + (plus) – słowo za znakiem + plus (pomiędzy znakiem plus a następującym po nim słowie nie może występować spacja) musi znajdować się w wyszukiwanej frazie (dla słowa po znaku + stawiany jest warunek AND, a dla pozostałych słów w wyrażeniu OR). W przypadku gdy w wyrażeniu występuje znak +słowo i nie zostanie ono odnalezione w zasobach systemu to wynik powinien wynosić zero mimo, że pozostałe słowa zostaną odnalezione. • – (minus) – słowo napisane za znakiem – (minus) (pomiędzy znakiem minus a następującym po nim słowie nie może występować spacja) zostanie wykluczone z wyszukiwanej frazy (dla słowa po znaku - stawiany jest warunek AND, a dla pozostałych słów w wyrażeniu OR). Zwrócone powinny być tylko te wyrażenia, które nie zawierają tego słowa. SEOD musi posiadać mechanizm rejestracji dokumentów dostępny dla dowolnej liczby jednostek organizacyjnych Zamawiającego, rozproszonych geograficznie, z możliwością rozróżnienia w którym punkcie był rejestrowany każdy z dokumentów oraz jakie osoby dokonały rejestracji każdego z dokumentów. Strona 11 z 51 4.17 4.18 4.19 4.20 4.21 4.22 SEOD musi umożliwiać rozdzielenie procesu rejestracji dokumentu co najmniej na podprocesy: rejestracji i skanowania, w taki sposób by każda z tych czynności była możliwa w innej lokalizacji geograficznej (poprzez lokalizację geograficzną należy rozumieć inny komputer, pokój w budynku, różne pokoje w różnych budynkach, różne budynki w różnych miastach itd.). Równocześnie użytkownik obsługujący wszystkie lub tylko przypisane podprocesy musi mieć możliwość pracy bez przelogowywania się (podawania loginu i hasła) pomiędzy rolami (kontami) – jednokrotne logowanie. SEOD musi umożliwiać lokalizację dokumentów w postaci papierowej oraz możliwość zmiany informacji o lokalizacji. Informację powinien zmienić każdy użytkownik za pomocą odpowiedniej funkcji w SEOD. W celu zmiany informacji o lokalizacji fizycznej użytkownik powinien wybierać z listy osób posiadających dostęp do dokumentu odpowiednią i wysyłać jej żądanie akceptacji przekazanego dokumentu. Użytkownik, do którego przekazano żądanie staje się odpowiedzialny za oryginał dokumentu, dopiero po potwierdzeniu przez niego faktu odebrania oryginału dokumentu. Do czasu potwierdzenia odebrania dokumentu, osoba przekazująca oryginał, powinna mieć możliwość wycofania informacji o przekazaniu oryginału dokumentu. Akceptacja musi oznaczać zmianę informacji o użytkowniku posiadającym wersję papierową dokumentu. SEOD musi umożliwiać łączenie dowolnych dokumentów ze sobą oraz ze sprawami. Z poziomu dokumentu muszą być widoczne wszystkie połączenia ze sprawami oraz innymi dokumentami. Połączenia muszą być widoczne w formie tekstowej lub graficznej umieszczonej w metadanych lub informacjach uzupełniających dokumentu. SEOD musi umożliwiać rejestrację dokumentu przez każdego użytkownika oraz możliwość przekazania dokumentu do rejestracji innemu użytkownikowi (z odpowiednimi uprawnieniami). Rejestracja dokumentu polegać będzie na wypełnieniu formatki opisującej ten dokument oraz zatwierdzeniu tego opisu. Jeżeli użytkownik opisuje skan dokumentu to podczas rejestracji musi wraz z formatką na jednym ekranie (w tym samym czasie) widzieć treść rejestrowanego dokumentu, bez przełączania okien. SEOD musi posiadać możliwość rejestracji kosztów w przypadku rejestracji korespondencji związanej z opłatami. W przypadku rejestracji dokumentu musi istnieć możliwość dodania informacji np.: o kosztach poniesionych w związku z doręczeniem przesyłki. Dokumenty przyłączone do spraw muszą dziedziczyć znaki nadane tym sprawom wraz z indywidualnym oznaczeniem dokumentu. Strona 12 z 51 4.23 4.24 4.25 4.26 4.27 5 SEOD musi umożliwiać dołączenie jednego dokumentu do wielu spraw jednocześnie. W takim przypadku dokument musi dziedziczyć znaki ze wszystkich spraw, do których został dołączony. Wszystkie znaki muszą być widoczne z poziomu dokumentu. Po wybraniu odpowiedniego znaku musi nastąpić przekierowanie do odpowiedniej sprawy, a sprawa wyświetlona zgodnie z uprawnieniami użytkownika. Po najechaniu na znak sprawy (z poziomu dokumentu) musi pojawić się informacja dostępna dla wszystkich użytkowników posiadających wybrany dokument dołączony do sprawy, składająca się z następujących elementów: • Nazwa sprawy nadana przez użytkownika, • Opis wybranego hasła z JRWAUG, • Numer sprawy (w wybranej komórce organizacyjnej oraz roku), • Właściciel sprawy (Imię i Nazwisko), • Data utworzenia, • Data rozpoczęcia pracy nad sprawą, • Data zakończenia pracy nad sprawą, • Stan sprawy. Funkcja korespondencji seryjnej SEOD musi być dostępna za pomocą kreatora, który krok po kroku przeprowadza użytkownika przez proces jej tworzenia. Po uruchomieniu kreatora korespondencji seryjnej dostępne muszą być następujące opcje: • wybór adresatów – możliwość wyboru określonych podmiotów połączonych ze sprawą. Dostępne powinny być przynajmniej pola: Nazwa (Imię i Nazwisko), Ulica i numer domu, Kod i Miejscowość, • koperty i dokumenty (koperty – umożliwia wydruk seryjny kopert, dokumenty – umożliwia wydruk seryjny dokumentów na podstawie zdefiniowanych w systemie szablonów, w obu przypadkach poprzez naniesienie na nie danych teleadresowych), • ustawienia rozmiaru strony/koperty (A4, A3 i co najmniej 5 najbardziej popularnych wydruków), • wybór w zakresie wydrukowania znaku sprawy na kopercie, • wybór szablonu z repozytorium zdefiniowanych szablonów, na podstawie którego powstanie dokument. Każdy z użytkowników systemu powinien posiadać możliwość rejestracji nowych dokumentów z plików załączanych do sprawy (o ile administrator nada użytkownikowi takie uprawnienie). Sprawy Strona 13 z 51 5.1 5.2 5.3 5.4 5.5 5.6 SEOD musi posiadać mechanizmy pracy grupowej umożliwiające np.: wspólną pracę nad prowadzonymi sprawami i dokumentami. Przez wspólną pracę należy rozumieć dostęp do tych samych informacji dowolnej grupie użytkowników bez pojawiania się konfliktów w jednym czasie. SEOD musi posiadać możliwość wglądu do spraw z poziomu dokumentu oraz wglądu do dokumentów z poziomu spraw zgodnie z posiadanymi uprawnieniami. SEOD musi zapewnić możliwość zablokowania dostępu do danej sprawy/dokumentu dla danego użytkownika któremu wcześniej sprawa/dokument został przydzielony. Po zablokowaniu dostępu użytkownik traci wgląd do wybranej sprawy lub/i dokumentu oraz wszystkich informacji, które były z nimi powiązane. Administrator SEOD musi posiadać możliwość definiowania wzorców spraw. Wzorce spraw muszą umożliwiać powiązanie z kategoriami JRWAUG. Każdy wzorzec sprawy powinien mieć możliwość zdefiniowania etapów załatwiania sprawy. SEOD musi być wyposażony w mechanizm akceptacji, który umożliwia co najmniej: Akceptację przez jednego użytkownika – element jest zaakceptowany tylko przez jednego użytkownika (jeden z jeden) Przesłanie dokumentu do wielu i akceptację przez jednego z nich – element jest zaakceptowany gdy tę operację wykona jeden z grupy użytkowników (np.: jeden z trzech) Przesłanie i akceptacje przez wielu użytkowników – element jest zaakceptowany gdy tę operację wykona większość użytkowników (np.: dwóch z trzech) Przesłanie i akceptację przez wszystkich – element jest zaakceptowany gdy tę operację wykonają wszyscy użytkownicy (np.: trzech z trzech) SEOD musi umożliwiać przesyłanie do akceptacji plików załączonych do spraw czy zeskanowanych dokumentów oraz informacji w postaci tekstowej stworzonej poprzez wbudowany w SEOD edytor WYSIWYG. Istotne jest aby akceptacja była odrębnym mechanizmem – a nie prostym procesem Workflow – tak aby nie było konieczności definiowania procesu workflow do realizacji mechanizmu akceptacji. SEOD musi umożliwiać przeglądanie historii zmian dotyczącej elementów z określeniem czasu i opisu zmian, informacją o osobach, które tych zmian dokonały, elementu, którego dotyczy zmiana oraz czynności, której dotyczy zmiana. Konieczne jest umożliwienie filtrowania historii zmian według następujących parametrów: użytkownika, który wykonał operację, Strona 14 z 51 5.7 5.8 5.9 5.10 elementu, którego zmiana dotyczy (minimalnie 4 parametry: dokument, sprawa, notatka, plik), czynności (minimalnie trzy parametry: modyfikacja, dodanie, usunięcie). SEOD musi wyróżniać zmianę, która nastąpiła poprzez opisanie elementu, w którym ta zmiana nastąpiła np.: dodano użytkownika, zmieniono nazwę sprawy, itd. SEOD musi posiadać możliwość sortowania historii zmian względem daty wykonania operacji. SEOD musi posiadać eksport historii zmian do sformatowanego pliku tekstowego, w którym dane oddzielone są separatorami. Historia zmian musi obejmować co najmniej zdarzenia w: sprawie, dokumencie, strukturze organizacyjnej, koncie użytkownika, bazie teleadresowej, zastępstwie, pliku dołączonym do systemu, notatce tekstowej dołączonej do systemu, rezerwacjach zasobów JRWAUG SEOD musi umożliwiać graficzną prezentację informacji o użytkownikach posiadających dostęp do wybranych elementów np.: spraw lub dokumentów w postaci drzewa o strukturze hierarchicznej (wielopoziomowej). Na podstawie tej informacji musi istnieć możliwość identyfikacji użytkownika, który przydzielił określony zasób opatrzony datą przydzielenia oraz kiedy wybrany użytkownik odczytał przydzielone mu informacje. SEOD musi umożliwiać hierarchiczne łączenie dowolnej ilości spraw w relacji nadrzędna – podrzędna. SEOD musi posiadać możliwość wyznaczenia osób lub osoby prowadzącej sprawę posiadającej pełne uprawnienia do prowadzonej sprawy. Musi istnieć również możliwość zdefiniowania referenta sprawy. SEOD musi posiadać możliwość zakładania spraw przez każdego użytkownika i opisania jej co najmniej według następujących parametrów: znak sprawy – zgodny z instrukcją kancelaryjną Zamawiającego nazwa – nadanie nazwy sprawie, stan - np.: otwarta, zamknięta, zawieszona, opis – nadanie rozszerzonego opisu sprawie, termin rozpoczęcia oraz termin zakończenia pracy nad sprawą, priorytet – np.: pilny, ważny, normalny. Strona 15 z 51 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 SEOD musi również umożliwiać przypisanie dodatkowych parametrów dla spraw za pomocą formularzy dynamicznie przydzielanych do spraw o określonej kategorii lub powiązanych z odpowiednim wzorcem. SEOD musi posiadać mechanizm automatycznie łączący sprawę z danymi teleadresowymi podmiotu, którego ta sprawa dotyczy. Użytkownik musi posiadać możliwość połączenia sprawy z więcej niż jednym podmiotem. SEOD musi posiadać funkcję określenia cykliczności przypomnień dla realizowanych spraw. SEOD musi umożliwiać dzielenie spraw na sprawy podrzędne i delegowania ich do różnych osób. System musi być wyposażony w mechanizm umożliwiający hierarchiczne tworzenie spraw w strukturze nadrzędna – podrzędna i przedstawienie tego połączenia w postaci drzewa z zagnieżdżonymi sprawami podrzędnymi. SEOD musi posiadać możliwość przekazywania spraw bez utraty kontroli nad ich realizacją. Użytkownik po przekazaniu sprawy musi mieć możliwość zachowania dostępu do tej sprawy. Przekazanie sprawy powinno być realizowane poprzez wskazanie osoby prowadzącej lub ustalenia referenta dla danej sprawy. SEOD powinien generować spis spraw z użyciem co najmniej następujących parametrów: • komórka organizacyjna, • symbol z JRWAUG, • rok, • data rozpoczęcia Od, • data zakończenia Do, • stan sprawy (np.: zakończona, otwarta itd.). Raport powinien być generowany do postaci tabelarycznej i możliwy do pobrania i zapisu w wersji XLS oraz PDF. SEOD musi powiadamiać o przekroczonych terminach załatwienia spraw poprzez oznaczanie tych spraw oraz możliwość filtrowania spraw o przekroczonych terminach. Wyróżnienie powinno się odbywać poprzez oznaczenie elementu specjalną flagą, a na listach powinna to być widoczna np. ikona sygnalizująca przekroczenie czasu załatwienia sprawy. SEOD musi umożliwiać założenie sprawy bez konieczności natychmiastowego nadania znaku sprawy zgodnego z JRWAUG. Musi istnieć możliwość nadania znaku sprawy w każdej chwili oraz zmiana znaku sprawy. Zmiana znaku sprawy musi być odnotowana w historii sprawy. System musi umożliwiać ponowne wykorzystanie usuniętego znaku sprawy. Strona 16 z 51 5.19 5.20 5.21 5.22 5.23 6 6.1 6.2 SEOD musi posiadać możliwość blokowania powtórnego wykorzystania tego samego symbolu sprawy w przypadku jego usunięcia lub zmiany. SEOD musi posiadać funkcję umożliwiającą prowadzenie korespondencji seryjnej z poziomu sprawy. Korespondencja powinna być prowadzona względem podmiotów połączonych ze sprawą. SEOD musi informować o sprawach z przekroczonym terminem poprzez wyskakujące okno zawierające spis wszystkich tych spraw zgodnie z widokiem użytkownika. SEOD musi umożliwiać definiowanie czasu względem którego ma nastąpić powiadomienie o zbliżającym się terminie zakończenia sprawy (np.: powiadom o terminie zakończenia na 5 dni przed jego upływem). SEOD musi umożliwiać automatyczne grupowanie elementów należących do sprawy w formie drzewa rozdzielając takie elementy jak: dokumenty, pliki, raporty, formularze, elementy do akceptacji. Dodatkowo drzewo rozdzielające elementy powinno automatycznie rozdzielać elementy ze względu na ich kategorię np. odrębna gałąź dla dokumentów przychodzących skategoryzowanych jako wniosek, skarga itp. To samo powinno dotyczyć plików czy raportów o ile użytkownik określi ich kategorię. Notatki SEOD musi posiadać możliwość przesyłania notatek pomiędzy użytkownikami, które nie muszą być powiązane ze sprawami czy dokumentami. Notatka musi pełnić rolę wiadomości informacyjnej przesyłanej pomiędzy użytkownikami systemu. SEOD musi umożliwiać zdefiniowanie treści notatki za pomocą wbudowanego w SEOD edytora WYSIWYG. Edytor powinien pozwalać przynajmniej na takie podstawowe operacje formatowania tekstu jak: • Wybór czcionki • Wybór rozmiaru czcionki • Określenie nagłówków • Pogrubienia, pochylenia, podkreślenia lub przekreślenia czcionki • Wstawiania tabel • Ustawienia tekstu: do lewej, do prawej, do środka, wyjustowanie • Punktowanie • Akapity • Indeks górny, indeks dolny • Wklejanie z edytorów zewnętrznych z możliwością usunięcia formatowania • Kolorowanie czcionek i tła Strona 17 z 51 6.3 7 7.1 7.2 7.3 7.4 7.5 7.6 Edytor notatek musi pozwalać na wybór trybu pełnoekranowego, drukowania tworzonej notatki oraz wstawiania hiperłączy. Użytkownicy SEOD musi posiadać funkcję umożliwiającą kontrolę liczby zalogowanych użytkowników, oraz zdalne wylogowanie wszystkich bądź wybranych użytkowników. Funkcja musi być dostępna dla użytkownika posiadającego stosowne uprawnienia. SEOD musi posiadać możliwość definicji przez każdego użytkownika grup złożonych z użytkowników SEOD. Poprzez użycie odpowiedniej funkcji każdy z użytkowników musi mieć możliwość wpisania nazwy grupy np.: „Komisja powypadkowa ….” i dodania do tej grupy odpowiednich użytkowników. Po zdefiniowaniu użytkownik będzie mógł posługiwać się tą grupą w celu przekazywania do jej członków informacji. Użytkownik musi posiadać możliwość oznaczenia tej grupy jako domyślnej co automatycznie zawęzi widok do członków tej grupy podczas przekazywania informacji. SEOD musi posiadać mechanizm przejmowania spraw i dokumentów między użytkownikami. Przejęcie danych musi skutkować przeniesieniem wszystkich informacji z konta jednego użytkownika na konto innego użytkownika. Funkcja przejęcia danych musi oferować możliwość przejęcia jednorazowo wszystkich informacji pomiędzy profilami wybranych użytkowników lub wybór poszczególnych danych które zostaną przejęte. Po przejęciu danych wszystkie informacje historyczne muszą zostać zachowane (ze szczególnym wskazaniem na informację na temat użytkownika, który wykonał określone operacje w SEOD). Mechanizm musi być dostępny z poziomu modułu administratora systemu wchodzącego w skład SEOD. SEOD musi umożliwiać ustalenie poziomu uprawnień do modyfikacji bazy adresowej podmiotów, oraz określenie, który z użytkowników może zarządzać bazą adresową na poziomie usuwania, łączenia oraz modyfikowania wpisów. Takich użytkowników musi być dowolnie definiowana ilość, w szczególności wszyscy użytkownicy. SEOD musi gwarantować możliwość przydzielenia roli administratora do więcej niż jednego użytkownika systemu poprzez nadanie mu odpowiednich uprawnień. SEOD musi umożliwiać dodawanie użytkownika do struktury organizacyjnej z poziomu formatki ustawień konta użytkownika. Strona 18 z 51 7.7 7.8 7.9 7.10 8 8.1 SEOD musi umożliwiać przeglądanie danych dotyczących logowania użytkowników do systemu. Rejestrowane muszą być próby udanego i nieudanego logowania z datą i godziną. Dostęp do tych informacji posiada administrator systemu. Informacje na temat logowania użytkowników muszą być dostępne bezpośrednio z poziomu interfejsu SEOD – w panelu administratora. Użytkownik posiadający uprawnienia administracyjne musi posiadać dostęp do informacji na temat obciążenia pracowników względem wykonywanych czynności w określonych punktach zdefiniowanych ścieżek workflow. Zestawienie obciążenia powinno być przedstawione w czytelny sposób np. w formie tabelarycznej pokazującej listę pracowników oraz ilość punktów przydzielonych do pracowników. SEOD musi umożliwiać użytkownikowi wybranie adresatów informacji kierując się listą: użytkowników zajmujących określone stanowisko np.: Dyrektor Urzędu Górniczego, Naczelnik, użytkowników w komórce organizacyjnej np.: Departament X, Biuro Y, użytkowników należących do grup zdefiniowanych przez użytkownika np.: Sekretariaty, Kancelarie, bezpośrednio do wybranego użytkownika. SEOD musi umożliwiać jednoznaczną identyfikację użytkownika. Wszystkie operacje zapisywane w historii i w logach aplikacji muszą być przyporządkowane do konkretnego użytkownika. Struktura organizacyjna Użytkownik posiadający podwładnych musi mieć możliwość wglądu do posiadanych przez nich dokumentów oraz spraw poprzez dedykowaną funkcje wyświetlającą wszystkich podwładnych oraz odwołania do posiadanych przez nich dokumentów oraz spraw. Funkcja musi wyświetlać w widoku tabelarycznym (matrycy) poszczególnych użytkowników wraz z informacją ilościową o posiadanych sprawach: sumarycznie, przeterminowanych, załatwionych w terminie, załatwionych po terminie, oczekujących na załatwienie, anulowanych, zamkniętych; dokumentach odebranych, nieodebranych oraz o aktywnych procesach workflow, w których uczestniczy każdy użytkownik. Opisana informacja musi być dostępna poprzez zestawienie tabelaryczne bez konieczności wchodzenia w profil poszczególnych użytkowników. Strona 19 z 51 8.2 9 9.1 9.2 9.3 9.4 9.5 10 10.1 11 11.1 SEOD musi posiadać funkcję umożliwiającą definiowanie wielopoziomowej struktury organizacyjnej oraz definicję podległości służbowych. Funkcja ta musi umożliwiać zdefiniowanie jednostek organizacyjnych wraz z przypisaniem im odpowiedniej kategorii (np.: OUG XYZ, departament, biuro, wydział itp.) oraz podległości służbowych wraz z przyporządkowaniem im odpowiedniego stanowiska np.: dyrektor, naczelnik. Modyfikacje struktury organizacyjnej są zapisywane w postaci historii zmian i nigdy nie mogą zostać utracone. Ustawienia SEOD powinien, dla ułatwienia użytkownikom pracy z systemem, posiadać miejsce gdzie zaraz po zalogowaniu użytkownik będzie informowany o nowych elementach typu: dokument, sprawa, elementy oczekujące na akceptację itp. Gdzie po kliknięciu na element użytkownik zostanie przeniesiony do treści danego elementu. Informacje o nowych elementach powinny być widoczne zaraz po zalogowaniu do systemu w centralnym miejscu interfejsu aplikacji. SEOD musi umożliwiać dynamiczną konfigurację szerokości kolumn wyświetlających informacje o elementach systemu. Mechanizm powinien działać w sposób analogiczny do modyfikacji ustawień szerokości kolumn w arkuszach kalkulacyjnych pakietów biurowych. SEOD musi umożliwiać włączanie i wyłączanie powiadamiania o aktualizacjach w sprawach i dokumentach, dla każdego użytkownika indywidualnie. SEOD musi umożliwiać ukrywanie wybranych kolumn opisujących dokument lub sprawę. Każdy użytkownik powinien posiadać możliwość wyboru kolumn, które są widoczne w jego profilu, dostosowując wygląd list elementów do własnych preferencji. SEOD musi umożliwiać użytkownikowi zmiany sortowania dokumentów i spraw względem określonych kolumn, dostosowując domyślny sposób sortowania list elementów do własnych preferencji. Pomoc Pomoc musi zapewniać możliwość wyświetlenia okna kontekstowego powiązanego z aktualnie wybraną funkcją SEOD. Reguły SEOD musi posiadać mechanizm ustalania Reguł, umożliwiających sortowanie dokumentów, spraw i poczty elektronicznej względem folderów, do których dostęp ma użytkownik. Funkcja powinna umożliwiać stworzenie reguły względem następujących parametrów opisujących: • Dokument: Strona 20 z 51 • o Opis dokumentu – względem części lub całego opisu, o Kategoria, o Sposób dostarczenia (np.: email, ręcznie), o Przekazania w celu, o Oznaczenia flagą (ważny, pilny), o Przekazany przez (wybór określonego użytkownika systemu, który przekazał dokument), o Nadawca/Odbiorca. Sprawa: o Przekazana przez (wybór określonego użytkownika systemu, który przekazał sprawę), o Nazwa sprawy – względem części lub całej nazwy, o Znak sprawy – względem części lub całego znaku, 12 12.1 12.2 o Priorytet (pilna, ważna, zwykła), o Stan (zawieszona, w toku, zamknięta). • Poczta elektroniczna: o Pole Od, Do, Temat – względem części lub całego opisu, o Występuje, o Zawiera dokładnie, o Rozpoczyna się od, o Kończy się na. Mechanizm musi działać analogicznie do tworzenia reguł w popularnych programach pocztowych. Baza adresowa SEOD musi posiadać wbudowany mechanizm tworzenia słowników miejscowości i ulic oraz umożliwiać powiązanie tych danych z podziałem terytorialnym kraju na gminy, powiaty i województwa. SEOD musi posiadać mechanizm rozbudowy i modyfikacji słowników bazy adresowej poprzez wbudowane mechanizmy importu danych udostępnianych przez GUS z systemu TERYT. SEOD musi wykorzystywać informacje zawarte w bazie adresów np.: do rejestracji dokumentów. SEOD musi automatycznie wypełniać pola formatki powiązane z danymi słownikowymi. Możliwe powinno być np.: wypełnienie danych adresowych kontrahenta (pełna nazwa, ulica, numer budynku, lokalu, kod pocztowy, miasto NIP itd.) po odnalezieniu go w bazie adresowej systemu. SEOD musi posiadać zawężający widok danych w zależności od parametrów wybranych podczas uzupełniania danych podmiotu. Strona 21 z 51 12.3 12.4 12.5 13 13.1 13.2 13.3 13.4 13.5 13.6 SEOD musi oferować możliwość rozbudowy i modyfikacji bazy adresowej systemu z poziomu użytkowników posiadających uprawnienia, nadane przez administratora systemu, do modyfikacji bazy adresowej, wraz z możliwością dodawania atrybutów opisujących podmioty oraz generowania raportu przedstawiającego dokumenty i sprawy powiązane z podmiotami zdefiniowanymi w bazie adresowej. SEOD musi pozwalać na wybór podmiotu z bazy adresowej podczas rejestracji dokumentu. Wybór powinien następować poprzez wybranie pozycji podpowiadanej przez SEOD na podstawie informacji wprowadzonych przez użytkownika rejestrującego dokument. System powinien podpowiadać wszystkie podmioty, które spełniają parametry zapytania. Np. po wprowadzeniu 3-5 znaków z nazwy podmiotu SEOD powinien zaproponować listę dostępnych do wyboru podmiotów, a następnie po wyborze jednego z nich, wypełnić wszystkie zdefiniowane w bazie adresowej pola opisujące podmiot. SEOD musi pozwalać na odnalezienie podmiotu w bazie adresowej na etapie rejestracji dokumentu na podstawie wypełnionego jednego z pól adresowych np: wypełnienie pola NIP – wówczas po wyborze odpowiedniej funkcji (np.: dopasuj, szukaj itp.), powinien podpowiedzieć podmiot spełniający to zapytanie. Skanowanie Moduł ten musi umożliwiać współpracę ze skanerami dokumentowymi zgodnymi ze sterownikiem TWAIN. Moduł musi pozwolić na odwzorowanie cyfrowe (zeskanowanie) dokumentu z wybranymi parametrami, następnie wprowadzenie go do SEOD. Moduł skanowania powinien być dostępny zarówno w wersji aplikacji desktopowej jak i w wersji webowej. Moduł skanowania w wersji desktopowej powinien posiadać instalator w formacie .MSI Skanowane dokumenty powinny pojawiać się na liście, która umożliwi grupowe wprowadzenie dokumentów do SEOD, np.: poprzez zaznaczenie na liście skanów dokumentów, pola typu checkbox. Aplikacja musi umożliwiać grupowe zaznaczenie wszystkich dokumentów jednym kliknięciem np. przez kliknięcie w nagłówek tabeli w kolumnie odpowiedzialnej za zaznaczanie dokumentów. Moduł skanowania musi umożliwiać dokonanie transformacji zeskanowanego obrazu co najmniej w następującym zakresie: • Obrót skanu (odwzorowania cyfrowego dokumentu) o 90 stopni w dowolną stronę • Wybranie opcji pokazywania miniatur stron w przypadku skanu wielostronicowego Strona 22 z 51 13.7 13.8 13.9 14 14.1 14.2 15 15.1 15.2 15.3 15.4 • Możliwość zamiany kolejności stron • Możliwość usuwania stron Moduł skanowania musi umożliwiać wysyłanie skanów dokumentów co najmniej przez otoczenie sieciowe i przez FTP. Moduł skanowania musi umożliwiać zdefiniowanie następujących trybów skanowania: • Wszystkich skanowanych dokumentów / stron jako jeden plik – jeden dokument • Wszystkich skanowanych dokumentów / stron jako oddzielne pliki – oddzielne dokumenty • Możliwość dodawania nowych stron do dokumentu • Możliwość skanowania dokumentu jako jeden dokument, nawet w przypadku gdy podajnik skanera nie pozwala na wprowadzanie wszystkich kartek dokumentu za jednym razem (skanowanie ciągłe do jednego pliku) Moduł skanowania musi umożliwiać definiowanie profili skanowania (zapisanych parametrów skanowania). Formularze dla dokumentów SEOD musi posiadać możliwość przypisywania formularzy do formatki rejestracji dokumentu oraz nadawania uprawnień umożliwiających używanie zdefiniowanych formularzy przez określonych użytkowników. Formularz powinien pojawiać się po wyborze odpowiedniej kategorii dokumentu. Formularze muszą umożliwiać dokonanie opisu dokumentu dodatkowymi cechami (metadanymi), a uprawnienia do definiowania dodatkowych formularzy musi mieć użytkownik specjalny. SEOD musi posiadać mechanizm dynamicznych formularzy umożliwiający dodawanie określonych pól co najmniej do formatek opisu dokumentu, oraz procesów Workflow, tak aby możliwe było przydzielenie osobnego formularza dla każdego z kroków procesu. Rezerwacje Administrator SEOD musi posiadać możliwość zdefiniowania listy przedmiotów współdzielonych pomiędzy użytkownikami jak i ustalenia uprawnień dla tych przedmiotów oraz uprawnień do zarządzania nimi. Uprawnienia muszą umożliwiać co najmniej określenie: kto posiada uprawnienia do rezerwacji danego zasobu, oraz kto może dokonywać rezerwacji w imieniu innych użytkowników. SEOD musi umożliwiać dodawanie, modyfikacje, usuwanie zasobów przeznaczonych do rezerwacji. SEOD musi umożliwiać grupowanie zasobów przeznaczonych do rezerwacji (np.: grupa samochody czy sale konferencyjne, w której dostępne są konkretne przedmioty). SEOD musi umożliwiać nadawanie uprawnień do pojedynczych zasobów (np.: wybranego samochodu) w zakresie: Strona 23 z 51 15.5 15.6 16 16.1 16.2 16.3 17 możliwości rezerwacji zasobu, wglądu w rezerwacje, możliwości usuwania rezerwacji zasobu, możliwośći rezerwacji zasobu oraz przeglądania rezerwacji z użyciem kalendarza, widoku kalendarza rezerwacji z podziałem co najmniej na: dzień, tydzień, miesiąc, oznaczania różnym kolorem rezerwacji wykonanych przez różnych użytkowników, możliwości dokonania rezerwacji z dokładnością do 15 minut. W SEOD musi istnieć możliwość wykonania rezerwacji w imieniu innej osoby wraz z odnotowaniem faktu kto i dla kogo dokonał rezerwacji. SEOD musi informować użytkownika o rezerwacjach nakładających się. Informacja musi być wyświetlana już w momencie próby dodania nakładającego się wpisu w rezerwacjach. Rejestry SEOD musi posiadać mechanizm definiowania rejestrów dokumentów oraz przydzielania dostępu do nich wybranym użytkownikom. Podczas definiowania uprawnień do rejestru musi istnieć możliwość wybrania zakresu uprawnień do rejestru dla wybranego użytkownika przynajmniej na poziomie: odczyt, pełny. Definiowanie rejestru musi umożliwiać użycie co najmniej następujących pól: klasyfikacja dokumentu (przychodzący, wychodzący, wewnętrzny), kategoria (np.: wniosek, skarga, decyzja itd.), komórka organizacyjna, kontakt z bazy adresowej. SEOD musi pozwalać na nadanie nazwy oraz symbolu rejestrowi. SEOD musi umożliwiać przydzielanie spraw/dokumentów do odrębnych rejestrów spraw/dokumentów, które to rejestry mogą być odrębnie numerowane. Mechanizm numeracji elementów w rejestrach musi pozwalać na ustalanie formatu numeracji poprzez możliwość zastosowania takich elementów jak: numer kolejny, symbol komórki, miesiąc, rok. Mechanizm numeracji powinien również pozwalać na ustalanie wartości początkowych. SEOD musi również pozwalać na określenie typu numeracji: np. ciągły, miesięczny, roczny. SEOD musi automatycznie grupować elementy rejestrów do osobnych folderów z podziałem na lata. Np. 2011, 2012 itd. Terminarze Strona 24 z 51 17.1 17.2 17.3 17.4 SEOD musi umożliwiać zarządzanie terminarzami z poziomu panelu administracyjnego. Administrator powinien posiadać możliwość utworzenia terminarza i przypisania go jednemu lub wielu użytkownikom, tak aby w zależności od uprawnień przydzielonych do danego terminarza użytkownicy mogli wprowadzać i zarządzać zmianami w danym terminarzu. SEOD musi posiadać wbudowany mechanizm terminarzy umożliwiający definiowanie terminarzy indywidualnych, grupowych oraz globalnych umożliwiający ustalanie i kontrolę nad terminami. Definiowanie terminarzy musi być proste – tzn. opierać się o odpowiednie wypełnienie pól formularzy wyświetlanych w interfejsie aplikacji (przeglądarce internetowej). Użytkownik musi posiadać możliwość udostępnienia całego swojego terminarza, z uprawnieniami tylko do wglądu lub do zapisu, innemu użytkownikowi. SEOD musi posiadać możliwość ustalania uprawnień do dodawania i do wglądu terminarzy dostępny dla każdego użytkownika. Uprawnienia muszą dotyczyć indywidualnie każdego terminarza. 17.5 Wpisy o terminach dokonane przez różnych użytkowników w udostępnionym terminarzu muszą być oznaczone innym kolorem. 17.6 SEOD musi udostępniać następujące widoki terminarzy: dzienny, tygodniowy, miesięczny. W każdym z tych widoków muszą zostać wyświetlone informacje na temat ustalonych terminów. 17.7 SEOD musi informować użytkownika o terminach nakładających się w momencie próby wprowadzenia takiego kolidującego terminu i jednocześnie proponować najbliższy wolny termin. 17.8 SEOD musi umożliwiać wpisanie do terminarza, na dany dzień, dowolnej liczby zdarzeń tzw. „całodziennych” o nakładających się terminach np. planowane przez różne jednostki na ten sam dzień kontrole zewnętrzne. 17.9 SEOD musi posiadać funkcję cyklicznego przypominania o zdarzeniach zapisanych w terminarzach. Powiadamianie musi być możliwe za pomocą wyskakującego okienka, w którym zostaną wymienione zdarzenia pochodzące ze wszystkich terminarzy, do których dostęp ma użytkownik. Musi istnieć możliwość odłożenia przypomnienia o zdarzeniach na określony czas dla wszystkich terminów jednocześnie oraz dla każdego z osobna lub odrzucenia powiązanego z usunięciem przypomnienia o wybranym terminie lub grupie terminów. 17.10 SEOD musi umożliwiać wyeksportowanie wszystkich zdarzeń z terminarza do pliku CSV. SEOD musi umożliwiać eksport przynajmniej następujących pól: data rozpoczęcia, data zakończenia, tytuł, opis. Strona 25 z 51 17.11 SEOD musi posiadać funkcję umożliwiającą synchronizację wbudowanego terminarza z komercyjnym oprogramowaniem Microsoft Outlook (w wersji 2000, 2003, 2007 i nowszej). JRWAUG 18 18.1 SEOD musi umożliwiać modyfikację JRWAUG tylko przez uprawnionego użytkownika (lub administratora) z poziomu interfejsu graficznego będącego częścią SEOD. Modyfikacje JRWAUG są zapisywane w postaci historii zmian. Historia zmian powinna zawierać co najmniej informacje na temat tego kto dokonał zmiany, kiedy ona nastąpiła, co zostało zmienione, jakiego symbolu JRWAUG dotyczyła, oraz czy była to modyfikacja czy rozbudowa JRWAUG. 18.2 SEOD musi posiadać narzędzia umożliwiające import JRWAUG z pliku tekstowego o odpowiednio sformatowanej strukturze. Mechanizm importu powinien umożliwiać zaimportowanie struktury JRWAUG przygotowanej co najmniej w pliku w formacie CSV. 18.3 SEOD musi umożliwiać nadanie znaku JRWAUG na etapie zakładania sprawy, lub już po założeniu sprawy. 18.4 SEOD musi umożliwiać usuwanie znaku sprawy JRWAUG, oraz na ponowne nadanie znaku sprawy. 18.5 SEOD musi uniemożliwiać usuwanie znaków spraw w sposób powodujący powstawanie „pustych” wpisów w ewidencji spraw. 19 Edytor 19.1 SEOD musi uniemożliwiać edycję dokumentu lub pliku w przypadku gdy jest on otwarty w tym celu przez innego użytkownika. SEOD musi umożliwiać definicję maksymalnego czasu blokowania plików pobranych do edycji i automatycznie odblokowywać plik po przekroczeniu zdefiniowanego czasu. SEOD musi informować użytkownika o zablokowaniu edycji dokumentu poprzez wyświetlenie informacji zawierającej Imię i Nazwisko użytkownika, przez którego dostęp do pliku został zablokowany. 19.2 SEOD musi posiadać mechanizm umożliwiający modyfikację dokumentów pakietu komercyjnego Microsoft Office Word (w wersji co najmniej 2003 lub nowszy). Użytkownik musi posiadać możliwość zapisania informacji z poziomu aplikacji macierzystej bezpośrednio w systemie. Po kliknięciu na plik MS Word umieszczony w SEOD ten otwierany jest w programie MS Word. Po modyfikacji pliku musi istnieć możliwość zapisania zmodyfikowanego pliku bezpośrednio w SEOD z poziomu MS Word. Plik powinien być zapisany jako kolejna wersja uprzednio edytowanego pliku. Strona 26 z 51 19.3 20 20.1 20.2 20.3 21 21.1 21.2 22 22.1 22.2 22.3 Dopuszcza się aby moduł edytora był dostępny jako komponent ActiveX, jednocześnie dostarczany SEOD musi posiadać instalator edytora w formacie .MSI – tak aby Administrator mógł zainstalować komponent ActiveX za pomocą mechanizmów domenowych (Group Policy). SEOD powinien również umożliwiać automatyczną instalację komponentu przy założeniu, że konfiguracja przeglądarki na to pozwala. Taka instalacja może się odbywać tylko przy pierwszym uruchomieniu edytora. Drag & Drop SEOD musi umożliwiać przenoszenie elementów pomiędzy folderami SEOD za pomocą mechanizmu Drag & Drop – użytkownik wskazuje element, klikając myszą, a następnie przeciąga go do folderu docelowego. Mechanizm Drag & Drop nie może pozwalać na „wymieszanie” elementów w folderach. Np. SEOD nie może pozwolić na przeniesienie obiektu typu „sprawa” do folderu np. typu „dokument”. W przypadku próby przeniesienia obiektu do niewłaściwego folderu SEOD musi poinformować użytkownika o próbie wykonania niedozwolonej operacji. Formularze dla spraw SEOD musi pozwalać na zdefiniowanie formularzy dynamicznych dla zdefiniowanych wzorców spraw. Do każdego symbolu sprawy z JRWAUG może zostać przydzielony odrębny wzorzec, a co za tym idzie formularz opisujący daną sprawę. Za pomocą formularzy dynamicznych musi istnieć możliwość opisania sprawy dowolnymi polami tj. text, textarea, drop down list, radiobutton, checkbox. SEOD musi pozwalać na wyszukiwanie spraw wg. atrybutów wchodzących w skład formularzy dynamicznych opisujących sprawy. Zastępstwa Mechanizm zastępstw nie może wymuszać przekazywania haseł pomiędzy użytkownikami na czas nieobecności. Każdy użytkownik systemu, zgodnie z uprawnieniami, musi posiadać możliwość wskazania początku oraz końca okresu, w którym będzie zastępowany. Wszystkie operacje wykonywane przez zastępcę w systemie muszą zostać odnotowane. Na ich podstawie powinien być tworzony spis wykonanych operacji, w taki sposób aby osoba powracająca do swoich obowiązków po zakończeniu zastępstwa była w stanie zapoznać się z operacjami jakie zastępujący wykonywał w obrębie konta zastępowanego. Wszystkie elementy, na których zastępca wykonał jakiekolwiek operacje muszą być przedstawione w postaci zbiorczej listy lub raportu. Strona 27 z 51 22.4 22.5 22.6 23 23.1 24 24.1 24.2 24.3 SEOD musi posiadać możliwość modyfikacji zastępstwa w taki sposób aby istniała możliwość zmiany osoby zastępowanej bądź zastępującej. Wszystkie operacje realizowane przez zastępcę muszą zostać zapisane w historii zdarzeń i umożliwiać identyfikację osoby, która je wykonała. Mechanizm zastępstw musi umożliwiać określenie do jakich elementów należących do osoby zastępowanej, zastępca otrzyma dostęp na czas pełnionego zastępstwa. Mechanizm zastępstw powinien umożliwiać zdefiniowanie dostępu do co najmniej następujących elementów: dokumenty, sprawy, elementy do akceptacji, elementy do dekretacji, notatki, poczta, rezerwacje, delegacje, urlopy, zastępstwa, foldery publiczne. Szablony dokumentów SEOD musi wspomagać przygotowanie szablonów dokumentów do otwartego formatu RTF, zawierających obok definiowanej stałej treści, predefiniowane pola, wśród których muszą znaleźć się: data aktualna, dane teleadresowe odbiorcy z podziałem na nazwę, imię i nazwisko, ulicę, numer domu, numer lokalu, kod, miasto, numer dokumentu, znak sprawy, do której należy dokument, imię i nazwisko osoby odpowiedzialnej za sprawę. Predefiniowane pola muszą być automatycznie wypełniane przez SEOD na żądanie użytkownika podczas generowania dokumentu na podstawie szablonu. Użytkownik musi mieć możliwość modyfikacji treści dokumentu i uzupełniania go o dowolne informacje. Podpis elektroniczny SEOD musi posiadać mechanizm umożliwiający swobodne korzystanie z kwalifikowanego i powszechnego podpisu elektronicznego bez konieczności posiadania fachowej wiedzy. Funkcja podpisu elektronicznego powinna umożliwiać podpisywanie jednego elementu SEOD przez wielu użytkowników. Funkcjonalność podpisu powinna umożliwiać stosowanie podpisu w formacie XAdES (ETSI TS 101 903 1.3.2) lub nowszy oraz PKCS#7 w zależności od konfiguracji systemu. SEOD musi zapewniać użycie podpisu opakowanego i opakowującego. Funkcja podpisu elektronicznego musi umożliwiać poprawne wykorzystanie certyfikatów kwalifikowanych pochodzących od wszystkich certyfikowanych wystawców. SEOD musi umożliwiać złożenie podpisu na dokumencie lub pliku załączonym do sprawy dowolnej liczbie osób. Strona 28 z 51 24.4 SEOD musi umożliwiać zweryfikowanie poprawności złożonego podpisu przez każdego z użytkowników, którzy podpisali dokument. 25 25.1 Foldery publiczne SEOD musi umożliwiać zdefiniowanie folderów dostępnych dla dowolnie zdefiniowanej przez administratora systemu listy użytkowników. Foldery publiczne powinny być widoczne dla wszystkich użytkowników posiadających do nich wgląd, i powinny być zdefiniowane w identyczny sposób u każdego z użytkowników. Administrator SEOD może w każdej chwili nadać lub odebrać uprawnienia do folderu kolejnym użytkownikom. Active Directory SEOD musi umożliwiać synchronizację kont użytkowników poprzez LDAP ze szczególnym uwzględnieniem Active Directory. Synchronizacji powinny podlegać, co najmniej, następujące informacje: • Imię i nazwisko, • Adres email, • Numer telefonu, • Stan konta: zablokowane, aktywne. Mechanizm integracji z Active Directory powinien pozwalać co najmniej na: • Kopiowanie kont wybranych lub wszystkich aktywnych kont z Active Directory, • Synchronizację informacji o kontach z Active Directory – np. w przypadku gdy SEOD posiada informację o n – użytkownikach, a w między czasie w Active Directory został dodany nowy n+1 użytkownik, SEOD podczas synchronizacji powinien odnaleźć takie nowe konto i umożliwić zaimportowanie go do SEOD. Mechanizm integracji z Active Directory nie może ograniczać SEOD do pracy tylko i wyłącznie z LDAP/Active Directory. SEOD musi działać poprawnie także w środowiskach bez LDAP/Active Directory. Integracja z Active Directory nie może również być integracją online. SEOD musi umożliwiać pracę użytkownikom nawet w przypadku gdy Active Directory nie jest dostępne. Pobieranie informacji z Active Directory o użytkownikach powinno być inicjowane przez Administratora SEOD. Integracja online powinna służyć jedynie do zintegrowanego uwierzytelniania systemowego użytkowników podczas uruchamiania SEOD. Użytkownik autoryzowany w domenie, uruchamiając SEOD, jest automatycznie logowany na swoje konto w SEOD – o ile jego konto w SEOD istnieje (zostało pobrane z Active Directory, lub dodane ręcznie przez Administratora). 25.2 26 26.1 26.2 26.3 Strona 29 z 51 26.4 26.5 26.6 26.7 27 27.1 27.2 27.3 27.4 27.5 Mechanizm integracji SEOD z Active Directory nie może uniemożliwiać dodania konta użytkownika SEOD, który nie posiada konta w Active Directory. W takim przypadku użytkownik podczas logowania do systemu będzie musiał podać login i hasło aby SEOD autoryzował użytkownika. SEOD musi pozwalać na poprawną pracę także w środowiskach bezdomenowych. W takim przypadku użytkownik podczas logowania do systemu będzie musiał podać login i hasło aby SEOD autoryzował użytkownika. SEOD musi umożliwiać kopiowanie kont użytkowników poprzez LDAP. Możliwość autoryzacji użytkowników poprzez LDAP ze szczególnym uwzględnieniem Active Directory oznacza że użytkownik po zalogowaniu się do systemu operacyjnego nie może logować się po raz kolejny do SEOD. Użytkownik musi być uwierzytelniany automatycznie po wpisaniu adresu, pod którym dostępny jest SEOD i skierowany na przypisane do niego konto. Delegacje SEOD musi posiadać moduł delegacji umożliwiający rozliczenie delegacji pracownikom posiadającym konto w SEOD. Administrator SEOD musi mieć możliwość nadawania uprawnienia użytkownikom do administrowania delegacjami lub uprawnienie tylko do wprowadzania delegacji w zakresie jednostek organizacyjnych Zamawiającego. Moduł delegacji musi umożliwiać wprowadzenie delegacji oraz – po zakończeniu delegacji, na jej rozliczenie. Użytkownik posiadający uprawnienia do administrowania delegacjami, musi posiadać dostęp do: • Delegacji do zatwierdzenia • Zaliczek do zatwierdzenia • Rachunków do zatwierdzenia • Dokumentów (dołączanych do rozliczenia delegacji) • Podziału na delegacje odbywane samochodem prywatnym, służbowym oraz innymi środkami transportu (kolej, autobus) • Delegacji oczekujących na zatwierdzenie • Opcji umożliwiającej masowe zatwierdzanie delegacji Moduł delegacji musi pozwalać użytkownikowi na wprowadzenie informacji o delegacji poprzez wypełnienie formularza delegacji. Formularz delegacji musi zawierać następujące pola: • Numer delegacji (tylko do odczytu, generowany automatycznie przez SEOD) • Numer polecenia (tylko do odczytu, generowany automatycznie przez SEOD) • Pełniona funkcja – lista rozwijalna Strona 30 z 51 27.6 27.7 27.8 27.9 28 28.1 28.2 28.3 28.4 • Miejsce wyjazdu – słownik miejscowości • Czas trwania delegacji – godzina wyjazdu i godzina powrotu • Cel delegacji – lista rozwijalna lub pole tekstowe, w zależności od wyboru użytkownika wypełniającego formularz delegacji • Środki lokomocji • Wyżywienie (delegacja z wyżywieniem lub bez) • Osoba delegująca • Zastępca • Uwagi SEOD musi automatycznie definiować zastępstwo w przypadku gdy użytkownik wypełniając formularz delegacji zdefiniuje zastępcę. SEOD musi pozwalać wybranym użytkownikom na rozliczanie i zatwierdzanie delegacji. SEOD na liście delegacji musi prezentować i odpowiednio zmieniać automatycznie status delegacji: • Niezatwierdzona • Zatwierdzona • W toku • Rozliczona SEOD musi umożliwiać definiowanie ustawień ewidencji przebiegu pojazdu oraz na drukowanie karty ewidencji przebiegu pojazdu. Urlopy Moduł urlopy musi umożliwiać uprawnionemu użytkownikowi wprowadzenie informacji niezbędnych do poprawnego wyliczania ilości dostępnego urlopu. Moduł powinien pozwalać na wprowadzenie takich informacji jak: • Ilość dostępnego urlopu na żądanie • Ilość dostępnego urlopu z tytułu opieki nad dzieckiem • Ile godzin ma dzień roboczy dla pełnego etatu. SEOD w części pozwalającej na określenie uprawnień użytkowników do modułu urlopu musi umożliwiać określenie przynajmniej: • Czy użytkownik posiada uprawnienia do raportów dot. wykorzystania urlopów • Czy uprawnienia dotyczące zarządzania urlopami dotyczą wszystkich pracowników czy tylko wybranych pracowników • Czy użytkownik posiada uprawnienia do anulowania wniosków urlopowych W przypadku zmiany uprawnień do modułu urlopów SEOD musi zapisywać w historii listę tych zmian. Strona 31 z 51 28.5 28.6 28.7 28.8 28.9 29 29.1 Użytkownik posiadający uprawnienia administrowania urlopami powinien mieć możliwość wprowadzenia dla pracowników informacji o ich zatrudnieniu. SEOD musi umożliwiać, użytkownikowi definiującemu dane o zatrudnieniu pracownika, wprowadzenie co najmniej następujących informacji: • Data od kiedy pracownik jest zatrudniony • Data do kiedy pracownik jest zatrudniony lub na określenie, że okres zatrudnienia nie jest ograniczony • Wymiar etatu np. ½, ¼, 1/8, itd. • Podstawa urlopu (pierwsza praca, 20 dni, 26 dni) • Urlop dodatkowy (szkolny, służba cywilna) • Opieka nad dzieckiem • Uwagi Użytkownik posiadający uprawnienia do administrowania urlopami pracowników musi posiadać dostępną funkcję Oblicz urlop, która pozwoli na obliczenie urlopu na podstawie danych o zatrudnieniu pracownika. SEOD musi umożliwiać wygenerowanie szczegółowego raportu dot. wykorzystania urlopów pracownikowi posiadającemu odpowiednie uprawnienia. Raport powinien w sposób tabelaryczny przedstawiać ilość wykorzystanego urlopu w godzinach i minutach, dla każdego z typu urlopów oraz sumę. Zestawienie powinno jednocześnie pokazywać wszystkich pracowników do których użytkownik posiada uprawnienia administracji urlopami. SEOD w mechanizmie urlopów powinien w folderze Wnioski (wnioski urlopowe) dzielić wnioski na następujące foldery: • Nowe • Zweryfikowane • Zaakceptowane • Anulowane • SEOD podczas wprowadzania nowego urlopu musi umożliwiać wprowadzenie w formularzu elektronicznym następujących informacji: • Rok • Data od • Data do • Długość urlopu w dniach i godzinach z przeliczeniem na godziny • Rodzaj urlopu • Zastępca (z listą aktywnych pracowników SEOD) • Uwagi Komunikator SEOD musi współpracować z aplikacją umożliwiającą wymianę informacji pomiędzy użytkownikami – tzw. komunikator, w sposób analogiczny do programów komercyjnych np. GaduGadu. Strona 32 z 51 29.2 29.3 29.4 29.5 29.6 29.7 29.8 29.9 29.10 29.11 29.12 29.13 29.14 29.15 29.16 29.17 29.18 Komunikator musi zapewnić możliwość powiadamiania użytkownika o zmianach zachodzących pośród informacji w SEOD poprzez wyskakujący komunikat zawierający informację o aktualizacji. Komunikator musi umożliwiać dwukierunkowe rozmowy tekstowe pomiędzy użytkownikami systemu. Komunikator musi umożliwiać przechowywanie listy użytkowników na serwerze. Komunikator musi informować o zmianach statusów użytkowników przy użyciu ikon oraz okien z aktualnym statusem użytkownika. Komunikacja pomiędzy użytkownikami powinna być poprzedzona autoryzacją przez użytkownika, do którego kierowana jest rozmowa. Komunikator powinien umożliwiać konstruowanie wizytówki w oparciu o dane zawarte w systemie oraz pola uzupełniane przez użytkownika. Komunikator powinien umożliwiać przeglądanie wizytówek przez każdego użytkownika systemu. Komunikator powinien umożliwiać przesyłanie plików pomiędzy użytkownikami poprzez połączenie szyfrowane, z zastosowaniem protokołu SFTP bądź innego równoważnego. Komunikator powinien umożliwiać współdzielenie plików pomiędzy użytkownikami. Komunikator powinien umożliwiać zabezpieczanie utworzonej wielopoziomowej struktury katalogów hasłem. Komunikator powinien umożliwiać informowanie użytkownika animowaną ikoną o nowej wiadomości. Komunikator powinien umożliwiać ustawienie formatowania tekstu (rodzaju czcionki, typu czcionki, rozmiaru oraz stylu) dla wiadomości przychodzących oraz wychodzących. Komunikator powinien umożliwiać włączenie i wyłączenie funkcji wyświetlania ikon odzwierciedlających emocje (tzw. emotikony) dla wiadomości tekstowych. Komunikator powinien umożliwiać przesłanie tekstu z opcją wyświetlenia tekstu czcionką o stałej długości znaku bez formatowania i dzielenia tekstu (np. do wysyłania tabel itp.) Komunikator powinien umożliwiać podłączenie kompozycji graficznych zmieniających interfejs aplikacji w zakresie tła, koloru okien, ikon. Komunikator powinien umożliwiać włączenie i wyłączenie skrótów klawiaturowych umożliwiających szybką zmianę statusu. Komunikator musi umożliwiać skonfigurowanie możliwości uruchamiania po zalogowaniu się użytkownika do systemu operacyjnego. Strona 33 z 51 29.19 Komunikator musi umożliwiać skonfigurowanie wyświetlania informacji dotyczących dostępności użytkowników. 29.20 Komunikator musi umożliwiać skonfigurowanie możliwości ukrywania użytkowników ze statusem nieaktywny (offline). 29.21 Serwer z którym współpracuje komunikator musi współpracować z serwerem relacyjnych baz danych SQL. 29.22 Autoryzacja użytkowników powinna być możliwa poprzez LDAP ze szczególnym uwzględnieniem Active Directory. 29.23 Serwer komunikatora musi pracować poprawnie pod kontrolą systemu operacyjnego Linux (Unix) oraz Windows. 29.24 Serwer komunikatora musi przechowywać wszystkie wiadomości przekazywane pomiędzy użytkownikami. 30 BIP - współpraca 30.1 Funkcja publikacji do BIP zintegrowana w SEOD musi pozwalać na poprawną bezpośrednią integrację z zewnętrznym Biuletynem Informacji Publicznej, w taki sposób by możliwe było umieszczenie informacji dotyczących spraw z SEOD w strukturze stron BIP. Funkcja umożliwiająca publikację do BIP musi być oparta o mechanizm Webservices. Aktualnie Zamawiający wykorzystuje aplikację BIP z firmy Hoga.pl http://www.wug.bip.info.pl ,i z tą aplikacją musi współpracować SEOD. Dostawa aplikacji Biuletynu Informacji Publicznej NIE JEST przedmiotem zamówienia. 30.2 W ramach publikacji informacji do BIP z poziomu SEOD muszą być przekazywane następujące informacje: znak sprawy (taki sam jak w SEOD) – „numer sprawy”, stan sprawy, data rozpoczęcia sprawy – „data utworzenia”, data zakończenia sprawy – „data rozpatrzenia” 30.3 SEOD musi umożliwiać przekazywanie informacji w oparciu o szablony XML zawierające opisaną strukturę przekazywanych informacji. 30.4 Opublikowana do BIP sprawa z poziomu SEOD musi być w SEOD oznaczona odpowiednią ikoną. 30.5 SEOD w przypadku modyfikacji sprawy musi umożliwić uaktualnienie opublikowanej do BIP sprawy – szczególnie jej stanu. Publikowanie informacje muszą być agregowane względem sprawy, której dotyczą. Identyfikatorem agregacji jest znak sprawy. 31 Wielojęzyczność interfejsu 31.1 SEOD powinien umożliwiać ustawienie co najmniej 2 języków interfejsu aplikacji - w wersji polskiej (podstawowy) i angielskiej. 30.6 Strona 34 z 51 31.2 SEOD musi pozwolić aby każdy z użytkowników mógł wybrać jeden z dwóch języków niezależnie. Poczta elektroniczna 32 32.1 SEOD musi posiadać możliwość zarządzania kontami poczty elektronicznej obsługiwanymi w SEOD z poziomu użytkownika pełniącego rolę administratora systemu. Administrator musi posiadać możliwość utworzenia konta poczty elektronicznej i przypisania go jednemu lub wielu użytkownikom. 32.2 SEOD musi posiadać wbudowanego klienta poczty elektronicznej obsługującego co najmniej protokoły POP3 oraz SMTP. Klient poczty elektronicznej musi stanowić integralną całość pod względem graficznym i funkcjonalnym SEOD. 32.3 Wbudowany klient poczty elektronicznej musi posiadać co najmniej następujące funkcje: • Utwórz wiadomość – umożliwia utworzenie nowej wiadomości, • Odpowiedz – umożliwia udzielenie odpowiedzi nadawcy wraz z cytowaniem i oznaczenie cytowanego tekstu napisanego przez nadawcę, • Odpowiedz wszystkim – umożliwia udzielenie odpowiedzi nadawcy wraz z przesłaniem jej na pozostałe adresy email wymienione w polu Do, Do wiadomości oraz Ukryty do wiadomości wraz z cytowaniem i oznaczenie cytowanego tekstu napisanego przez nadawcę, • Prześlij dalej – umożliwia przesłanie poczty elektronicznej kolejnemu odbiorcy, • Przenieś – umożliwia przenoszenie poczty elektronicznej pomiędzy folderami na wybranym koncie, • Drukuj – umożliwia wydrukowanie poczty elektronicznej, • Dołącz – umożliwia dołączenie poczty elektronicznej do sprawy lub dokumentu, • Odbierz – umożliwia ręczne odebranie poczty elektronicznej, • Usuń – umożliwia usunięcie wybranej poczty elektronicznej, • Znajdź – umożliwia uruchomienie wyszukiwania poczty elektronicznej, • Rejestruj – umożliwia rejestrację poczty elektronicznej jako dokumentu w systemie w sposób analogiczny do rejestracji dokumentu zeskanowanego. 32.4 SEOD musi udostępniać możliwość konfiguracji konta poczty elektronicznej każdemu użytkownikowi lub tylko administratorowi w zależności od globalnej konfiguracji SEOD. Strona 35 z 51 SEOD musi zapewniać możliwość konfiguracji dowolnej liczby kont poczty elektronicznej dla każdego użytkownika. 32.6 SEOD musi posiadać funkcję umożliwiającą przypisanie pojedynczego konta poczty elektronicznej użytkownikowi bądź grupie użytkowników. 32.7 SEOD musi umożliwiać rejestrację poczty elektronicznej jako dokumentów w systemie z podziałem na treść i załączniki. Funkcja Rejestracji musi być dostępna z poziomu klienta poczty elektronicznej wbudowanego w SEOD i dostępna dla użytkownika zgodnie z nadanymi uprawnieniami. 32.8 SEOD musi umożliwiać dołączanie poczty elektronicznej do dokumentów lub spraw. Dołączenie musi być możliwe z poziomu klienta poczty elektronicznej wbudowanego w system. 32.9 SEOD musi posiadać możliwość przeszukania każdego z kont poczty elektronicznej względem następujących parametrów: • Od – pole nadawcy poczty elektronicznej • Do – pole odbiorcy poczty elektronicznej • Temat – pole tematu poczty elektronicznej • Treść – pole treści poczty elektronicznej • W podfolderach – możliwość przeszukania wszystkich bądź wybranych podfolderów na koncie 32.10 SEOD musi umożliwiać wysyłanie i odbieranie poczty elektronicznej wraz z załącznikami poprzez zdefiniowane konta pocztowe. 32.11 SEOD musi umożliwiać wysyłanie poczty elektronicznej w formacie HTML. SEOD powinien poprawnie obsługiwać wiadomości odbierane i wysyłane jako wiadomości w formacie HTML i formacie tekstowym. 33 Automatyczny przepływ dokumentów 33.1 SEOD musi umożliwiać zdefiniowanie ścieżki automatycznego przepływu dokumentów. 33.2 Mechanizm automatycznego przepływu dokumentów musi umożliwiać operatorowi rejestrującemu dokument wybranie co najmniej jednej ze ścieżek wg. której dokument ma zostać automatycznie przesyłany pomiędzy użytkownikami. 33.3 Mechanizm automatycznego przepływu dokumentów musi umożliwiać zdefiniowanie formularzy dynamicznych, które będą wypełnianie przez użytkowników na poszczególnych etapach przepływu dokumentu. 33.4 Graficzna prezentacja zdefiniowanej ścieżki automatycznego przepływu dokumentów musi być zrealizowana w dwuwymiarowej grafice wektorowej. 32.5 Strona 36 z 51 33.5 33.6 33.7 33.8 34 34.1 34.2 34.3 34.4 34.5 Mechanizm automatycznego przepływu dokumentów musi oferować graficzny modeler ścieżki przepływu dokumentów oparty o rozwiązanie którego specyfikacja jest jawna i nie podlega żadnym prawom patentowym. Mechanizm pozwalający na graficzne modelowanie ścieżek przepływu dokumentów musi pozwalać na rozszerzenie funkcjonalności poprzez dodanie własnych elementów i właściwości przy pomocy standardowych technik XML. Mechanizm pozwalający na graficzne modelowanie ścieżek przepływu dokumentów musi być niezależny od platformy systemowej. Mechanizm pozwalający na graficzne modelowanie ścieżek musi również zapewniać możliwość łączenia obiektów w sposób graficzny – poprzez łączenie punków strzałkami, które mogą być swobodnie kształtowane za pomocą krzywych Beziera. Moduł Workflow Oferowany z SEOD moduł Workflow musi być w pełni zgodny ze specyfikacją XPDL opracowaną przez Workflow Management Coalition (WfMC). Zamawiający dopuszcza zaoferowanie modułu z inną specyfikacją, posiadającą podobne zastosowanie i charakterystykę jednak oferowane rozwiązanie musi wspierać co najmniej eksport i import definicji procesów zgodnie ze standardem XPDL. Specyfikacja ta musi posiadać wsparcie i być stosowana przez powszechnie znanych producentów oprogramowania na świecie. Zgodność ze specyfikacją XPDL winna być potwierdzona przez autorów oferowanej specyfikacji, w formie pisemnej (dokument potwierdzający zgodność) lub opublikowana jako powszechnie dostępna informacja w Internecie na stronach autorów specyfikacji XPDL. Na listę zgodności musi zostać wpisany oferowany System Elektronicznego Obiegu Dokumentów. Kopia potwierdzenia (lub wydruk z ogólno dostępnej strony internetowej, z podaniem adresu) winna być złożona jako integralna część oferty. Administrator systemu musi posiadać możliwość zarządzania procesami / ścieżkami workflow. Interfejs aplikacji musi pozwolić w prosty sposób (bez znajomości języków programowania) na definiowanie nowych procesów / ścieżek workflow. Workflow musi być wyposażony w graficzne narzędzie umożliwiające definiowanie ścieżki dostępne z poziomu przeglądarki internetowej. Strona 37 z 51 34.6 34.7 34.8 34.9 34.10 34.11 34.12 34.13 34.14 34.15 34.16 Narzędzie musi umożliwiać rozmieszczanie elementów ścieżki (punktów ścieżki) metodą przeciągnij i upuść (ang. drag and drop). Przenoszenie elementów oraz ich łączenie musi być możliwe do wykonania za pomocą urządzenia wskazującego (myszki komputerowej). Narzędzie do graficznego modelowania ścieżek workflow musi umożliwiać tworzenie graficznego schematu procesu w dwuwymiarowej grafice wektorowej. Narzędzie do graficznego modelowania ścieżek workflow musi być oparte o rozwiązanie którego specyfikacja jest jawna i nie podlega żadnym prawom patentowym Narzędzie do graficznego modelowania ścieżek Workflow musi pozwalać na rozszerzenie jego funkcjonalności poprzez dodanie własnych elementów i właściwości przy pomocy standardowych technik XML. Narzędzie do graficznego modelowania ścieżek Workflow musi być niezależne od platformy systemowej. Narzędzie do graficznego modelowania ścieżek musi również zapewniać możliwość łączenia obiektów w sposób graficzny – poprzez łączenie punków strzałkami, które mogą być swobodnie kształtowane za pomocą krzywych Beziera Workflow musi umożliwiać definicję punktów (kroków) w ścieżce oraz połączeń pomiędzy tymi punktami. Workflow musi umożliwiać opisanie czynności, które muszą zostać wykonane w wybranym punkcie ścieżki. Workflow musi informować poprzez odpowiednie oznaczenie graficzne, w którym punkcie realizacji znajduje się użytkownik. Poprzez odpowiednie oznaczenie graficzne rozumie się oznaczenie punktu w odmiennym kolorze w stosunku do pozostałych punktów ścieżki. Workflow musi zapisywać pełną historię wszystkich zdarzeń, które miały miejsce w ścieżce wraz z oznaczeniem daty i godziny wykonania oraz użytkownika, który wykonywał wybraną operację. W historii zdarzeń powinny się zawierać co najmniej informacje takie jak: kto wykonał daną operację, kiedy to nastąpiło, daty zakończenia i rozpoczęcia punktów i ścieżek. Workflow musi umożliwiać wykorzystanie wyrażeń arbitralnych XOR, AND w zakresie realizacji warunków określonych w poszczególnych punktach ścieżki. Strona 38 z 51 34.17 Workflow musi umożliwiać definiowanie formularzy i przyporządkowanie ich do poszczególnych punktów ścieżki oraz podpisywanie tych formularzy podpisem elektronicznym przez wielu użytkowników. Podczas definicji formularzy dostępne muszą być następujące typy pól: data, data i czas, lista wyboru, plik, pole tekstowe, pole text area, checkbox, radiobutton, pole typu dokument – pozwalające na podpięcie identyfikatora dokumentu z SEOD do formularza, pole typu sprawa pozwalające na podpięcie do formularza identyfikatora sprawy. Dodatkowo musi istnieć możliwość wskazania źródła danych zasilających wartości dla danych pól. Powinny to być co najmniej: właściciel ścieżki, zalogowany użytkownik, właściciel sprawy, numer zadania, lista aktywnych użytkowników systemu. 34.18 SEOD musi umożliwiać zarządzanie rolami, do których mogą zostać przypisani użytkownicy. Po zdefiniowaniu roli i przypisaniu do niej użytkowników, workflow musi umożliwiać wykorzystanie jej podczas definicji kolejnych ścieżek. Powinna istnieć możliwość wykorzystania zdefiniowanej roli dowolną ilość razy w każdej ze ścieżek. Definicja roli powinna być możliwa na etapie definiowania ścieżki. W każdej chwili definiowania ścieżki lub jej modyfikowania musi istnieć możliwość zdefiniowania nowej roli. 34.19 SEOD musi posiadać możliwość definiowania przedziału czasu z dokładnością przynajmniej do 1 dnia, w którym musi zostać wykonana ścieżka oraz czasu wykonania czynności dla każdego z punktów ścieżki. Musi istnieć mechanizm weryfikujący czas przypisany w poszczególnych punktach do ogólnego czasu przypisanego ścieżce tak by nie było możliwe przekroczenie czasu przypisanego ścieżce bez poinformowania o tym uczestników ścieżki lub punktu w ścieżce. 34.20 SEOD musi informować uczestników punktu i ścieżki o czasie pozostałym do realizacji całej ścieżki oraz punktu w tej ścieżce. 34.21 Mechanizm Workflow powinien być wbudowany w SEOD. Workflow musi być w pełni dostępny w języku polskim – zarówno mechanizm po stronie użytkownika jak i administratora, definiującego ścieżki Workflow. Mechanizm Workflow powinien pozwalać administratorowi na zdefiniowanie dowolnej ilości ścieżek. Każdy element mechanizmu Workflow powinien być dostępny za pośrednictwem graficznej przeglądarki internetowej. 35 Faks Strona 39 z 51 35.1 35.2 36 36.1 36.2 SEOD musi posiadać możliwość automatycznego rejestrowania faksów. Zamawiający dopuszcza stosowanie aplikacji zewnętrznej do obsługi faksów o ile nie będzie to wymagało wykonywania dodatkowych czynności przez użytkowników. Tzn. aplikacja powinna automatycznie wprowadzać faks do rejestru dokumentów SEOD – ewentualny opis dokumentu w SEOD musi być możliwy z poziomu przeglądarki internetowej. Faksy wpływające powinny być automatycznie (okresowo) wprowadzane do SEOD. Faks powinien trafiać na listę nowych dokumentów, gdzie każdy z operatorów posiadających uprawnienia do dokumentów danej komórki, będzie miał możliwość zarejestrowania dokumentu. Integracja SEOD z MS Outlook Z poziomu Microsoft Outlook (w wersji co najmniej 2000, 2003 i 2007) musi istnieć możliwość rejestracji poczty email jako dokumentu w SEOD poprzez wypełnienie formatki dokumentu. Instalator pluginu pocztowego musi być dostępny w formacie .MSI Integracja SEOD z Elektroniczną Skrzynką Podawczą SEOD powinien posiadać mechanizmy pozwalające na integrację rozwiązania pełniącego rolę Elektronicznej Skrzynki Podawczej (ESP). SEOD powinien bezproblemowo współpracować co najmniej z rozwiązaniem dostępnym na platformie ePUAP w wersji aktualnej na dzień podpisania umowy. 37.2 SEOD powinien posiadać mechanizmy pozwalające na integrację z dowolną Elektroniczną Skrzynką Podawczą pozwalającą na integrację za pomocą webservices. Moduł Skanowania WEB 38 38.1 SEOD powinien posiadać możliwość skanowania bezpośrednio z poziomu wbudowanego narzędzia uruchamianego i osadzonego w oknie przeglądarki, zintegrowanego z SEOD. Dopuszcza się stosowanie tego narzędzia z poziomu stacji roboczej. 38.2 Moduł aplikacji do skanowania dostępny z poziomu przeglądarki internetowej może być instalowany po stronie stacji roboczej użytkownika, ale tylko przy jego pierwszym uruchomieniu. Archiwum spraw 39 39.1 SEOD musi posiadać wbudowany mechanizm umożliwiający przeniesienie wybranych spraw oraz dokumentów w poszczególnych jednostkach organizacyjnych Zamawiającego do archiwum danej jednostki organizacyjnej Zamawiającego. Sprawy przeniesione do archiwów zakładowych muszą być nadal dostępne dla użytkownika z uprawnieniami tylko do odczytu. SEOD musi posiadać możliwość generowania paczki archiwalnej zgodnie z obowiązującymi przepisami. 37 37.1 Strona 40 z 51 SEOD musi posiadać mechanizm pozwalający na import oraz export paczki archiwalnej zgodny z Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 r. w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych. Import musi być dostępny z poziomu SEOD poprzez wskazanie pliku stanowiącego paczkę archiwalną 39.3 Archiwum musi być modułem SEOD, do którego dostęp mogą posiadać tylko wybrani użytkownicy jednostek organizacyjnych Zamawiającego zgodnie z nadanymi przez administratora uprawnieniami. 39.4 SEOD musi umożliwiać przenoszenie zamkniętych spraw do archiwum. 39.5 SEOD musi umożliwiać nadanie uprawnień w zakresie możliwości tworzenia spisów zdawczo-odbiorczych oraz przekazywania tych spisów do archiwum. Tworzenie spisów zdawczo-odbiorczych oraz ich przekazywanie do archiwum powinno być proste, oparte o mechanizm kreatora. 39.6 SEOD musi umożliwiać zarządzanie uprawnieniami w zakresie dostępu do spisów zdawczo-odbiorczych. 39.7 SEOD musi zapewniać możliwość tworzenia wykazów (zestawienie) spisów zdawczo-odbiorczych. 39.8 SEOD musi umożliwiać utworzenie spisu zdawczo-odbiorczego z wykorzystaniem następujących parametrów: • Komórka organizacyjna (możliwość wyboru jednocześnie wielu komórek), • Symbol JRWAUG (możliwość wyboru wielu symboli jednocześnie), Daty od - do (możliwość zawężenia zakresu, z którego ma być utworzony spis zdawczo-odbiorczy). 39.9 SEOD musi zapewniać możliwość wydruku opisu teczki zgodnie z obowiązującym u Zamawiającego wzorem. 39.10 SEOD musi umożliwiać przeprowadzenie procesu akceptacji spisu zdawczo-odbiorczego, w którym możliwa jest akceptacja lub odrzucenie spisu. Akceptacja spisów zdawczo-odbiorczych powinna opierać się o wbudowany w system mechanizm akceptacji, a nie powinna być procesem workflow. 39.11 SEOD musi umożliwiać wykonywanie spisów zdawczo odbiorczych przez wybranego użytkownika dla wybranych komórek organizacyjnych np.: całego urzędu, departamentu czy biura oraz wszystkich komórek podrzędnych w tej jednostce. 39.12 SEOD musi numerować kolejno spis zdawczo-odbiorczy po umieszczeniu go w wykazie spisów zdawczo-odbiorczych. 39.2 Strona 41 z 51 39.13 SEOD musi umożliwiać zarządzanie uprawnieniami w zakresie możliwości dołączania spisów zdawczo-odbiorczych do wykazu spisów. Nadawanie uprawnień powinno odbywać się z poziomu panelu administratora SEOD. 39.14 SEOD musi umożliwiać dodawanie uwag do pojedynczej teczki (sprawy) umieszczonej w spisie zdawczo-odbiorczym. 39.15 SEOD musi umożliwiać modyfikację kategorii archiwalnej dla wybranej teczki umieszczonej w spisie zdawczo-odbiorczym. 39.16 SEOD musi umożliwiać usuwanie oraz modyfikację spisów zdawczo-odbiorczych wybranym użytkownikom zgodnie z posiadanymi przez nich uprawnieniami. 39.17 SEOD musi zabezpieczać przed usunięciem spisów zdawczoodbiorczych i innych danych, które byłoby niezgodne z obowiązującymi przepisami. 39.18 SEOD musi umożliwiać udostępnianie akt w formie elektronicznej wybranemu użytkownikowi SEOD. Mechanizm udostępniania akt musi być analogiczny do udostępniania akt w formie papierowej, odpowiednio zmieniony do obsługi akt elektronicznych. 39.19 SEOD musi umożliwiać odnotowanie faktu udostępnienia akt przechowywanych w formie papierowej nie sklasyfikowanych w formie elektronicznej. SEOD musi umożliwić dodanie wpisu, który będzie wskazywał na to, że akta w formie papierowej zostały udostępnione konkretnej osobie, oraz kiedy miało to miejsce. 39.20 SEOD musi zapewniać możliwość oznaczania ram czasowych, w których dokumentacja będzie udostępniana. 39.21 SEOD musi zapewniać ewidencję udostępnionych akt w formie listy lub raportu oraz informować o przekroczonych terminach udostępnienia. 39.22 SEOD musi umożliwiać udostępnianie całych teczek aktowych oraz pojedynczych spraw przekazanych do archiwum. 39.23 SEOD musi zapewniać możliwość przeszukiwania zasobu archiwalnego względem metadanych opisujących materiały przekazane do archiwum (dokumenty, sprawy i inne elementy wytworzone podczas pracy w SEOD). 39.24 SEOD musi zapewniać zapis historii zdarzeń wykonywanych względem materiałów przekazanych do archiwum. 40 OCR - rozpoznawanie tekstu 40.1 SEOD musi posiadać możliwość współpracy ze zintegrowanym mechanizmem skanowania dokumentów i rozpoznawania tekstu – OCR. 40.2 SEOD musi umożliwiać działanie mechanizmu OCR po stronie serwera i umożliwiać rozpoznawanie tekstu automatycznie, bez udziału użytkownika. Strona 42 z 51 40.3 40.4 41 41.1 41.2 41.3 41.4 Aplikacja OCR musi poprawnie rozpoznawać dokumenty w języku polskim, a także językach wszystkich krajów Europy oraz dodatkowo w rosyjskim. Aplikacja OCR musi umożliwiać obsługę formatów: • PDF: zapis do formatu PDF (w wersji 1.6 oraz wcześniejszej), włączając PDF/Archive (PDF/A). • BMP: 2-bit – nieskompresowany czarno-biały, 16-bit – nieskompresowany Mask, 24-bit – nieskompresowany Palette i TrueColor, 32-bit – nieskompresowany Mask, • PCX, DCX: 2-bit – nieskompresowany czarno-biały, 4- i 8-bit – skala szarości, TrueColor • JPEG: skala szarości, kolor, • JPEG 2000: skala szarości – Part 1, kolor – Part 1, • TIFF: czarno-biały – nieskompresowany, CCITT3, CCITT3FAX, CCITT4, Packbits, ZIP, LZW, skala szarości – nieskompresowany, Packbits, JPEG, ZIP, LZW, TrueColor - nieskompresowany, JPEG, ZIP, LZW, Palette - nieskompresowany, Packbits, ZIP, TIFF, • GIF: czarno biały – skompresowany LZW, skala szarości – skompresowany LZW, TrueColor – skompresowany LZW, • PNG: czarno biały, skala szarości, kolor. Integracja SEOD z ePUAP Mechanizm integracji z ePUAP musi zapewniać możliwość definiowania/dodawania nowych skrzynek z poziomu panelu administratora SEOD Mechanizm integracji z ePUAP musi zapewniać możliwość edytowania parametrów zdefiniowanych skrzynek z poziomu panelu administratora SEOD. SEOD musi pozwalać na edycję co najmniej następujących parametrów skrzynki: Nazwa podmiotu powiązanego ze skrzynką, Nazwa skrzynki, Adres skrzynki, komórka organizacyjna (urząd) do której skrzynka jest przyporządkowana, Termin doręczenia (termin ważności doręczenia, czas po którym doręczenie jest uznawana za nieudane). Mechanizm integracji z ePUAP musi zapewniać możliwość zdefiniowania dowolnej ilości skrzynek z poziomu panelu administratora SEOD. Mechanizm integracji z ePUAP musi zapewniać możliwość przyporządkowania poszczególnych skrzynek do odpowiednich jednostek organizacyjnych Zamawiającego. Strona 43 z 51 41.5 41.6 41.7 41.8 Mechanizm integracji z ePUAP musi zapewniać możliwość pobierania dokumentów wraz z UPP (Urzędowe Poświadczenie Przedłożenia) lub UPD (Urzędowe Poświadczenie Doręczenia) ze skrzynki ePUAP z rozdzieleniem na skrzynki zdefiniowane w obrębie skrzynki (konta) na żądanie użytkownika systemu. Dokumenty pobierane z platformy ePUAP powinny trafiać na listę dokumentów oczekujących na rejestrację w SEOD SEOD powinien automatycznie wypełniać pola opisujące dokument – na podstawie metadanych zawartych w dokumencie pobieranym z platformy ePUAP. Powinny to być co najmniej pola opisujące nadawcę dokumentu. SEOD powinien również automatycznie oznaczać sposób dostarczenia takiego dokumentu jako dokumentu pochodzącego z ePUAP. SEOD automatycznie musi wyszukiwać w swojej bazie podmiotów informacje czy dany podmiot nie znajduje się już w bazie podmiotów SEOD. Jeśli tak – dane opisujące nadawcę powinny być automatycznie wypełniane na etapie rejestracji dokumentu w SEOD. 41.9 SEOD musi prezentować podgląd dokumentu już podczas jego rejestracji. Podgląd musi być widoczny w tym samym oknie co formularz służący do zarejestrowania dokumentu w SEOD. 41.10 SEOD musi automatycznie oznaczać dokumenty pochodzące z platformy ePUAP. 41.11 SEOD musi umożliwiać utworzenie sprawy na podstawie odebranego dokumentu. SEOD musi zapewniać możliwość wysłania odpowiedzi do ePUAP bezpośrednio z SEOD. Np. z poziomu dokumentu lub sprawy założonej w SEOD. Odpowiedź (plik, formularz) musi być umieszczona w odpowiedniej kopercie XML, tak aby była akceptowana przez platformę ePUAP. 41.12 Użytkownik SEOD, pracujący nad dokumentem, który pochodzi z ePUAP, musi widzieć podgląd dokumentu (wizualizacja wysłanego formularza). SEOD musi również zapewniać możliwość pobrania dokumentu (pliku xml zawierającego dane) na komputer lokalny danego użytkownika. 41.13 SEOD musi zapewniać, że załączniki znajdujące się w dokumencie pochodzącym z ePUAP będą widoczne w SEOD również jako załączniki do zarejestrowanego w SEOD dokumentu. Np. pliki .doc, .txt, .odt. SEOD musi umożliwiać użytkownikowi możliwość pobrania samego załącznika. 41.14 Integracja SEOD z ePUAP musi umożliwić uprawnionym użytkownikom pełną komunikację z ePUAP bez konieczności logowania się użytkowników na platformie ePUAP. Strona 44 z 51 41.15 Integracja SEOD z ePUAP musi umożliwiać obsługę formularzy zdefiniowanych za pomocą edytora formularzy ePUAP. Poziom integracji musi umożliwiać odebranie tak wypełnionego formularza, rozpoznanie przez SEOD jego kategorii oraz automatyczne przeniesienie metadanych identyfikujących dokument/formularz do pól opisujących dokument w SEOD. 41.16 Integracja SEOD z ePUAP musi umożliwiać automatyczne odesłanie odpowiedzi na dokument wpływający z ePUAP do wszystkich stron zainteresowanych w prowadzonej w SEOD sprawie. 41.17 SEOD musi umożliwiać odesłanie do ePUAP podpisanych elektronicznie (podpis kwalifikowany i/lub niekwalifikowany) dokumentów będących odpowiedzią na dokument wpływający z ePUAP. 41.18 SEOD musi umożliwiać odesłanie dokumentów do ePUAP w tzw. trybie UPD (Urzędowe Poświadczenie Doręczenia) – z żądaniem potwierdzenia dostarczenia dokumentu. 42 Raporty / Wyszukiwanie 42.1 SEOD musi posiadać mechanizm definicji raportu z danych, do których dostęp ma użytkownik. SEOD musi umożliwiać wygenerowanie co najmniej następujących raportów w formacie co najmniej .xls lub .pdf: • raport zarejestrowanych dokumentów z uwzględnieniem pól: przedział czasowy od do, numery dokumentów od do, kategoria dokumentu, komórka organizacyjna, sposób dostarczenia dokumentu, nadawca, adresat, podział na przychodzące, wychodzące wewnętrzne, osoba rejestrująca dokument. Powinna istnieć możliwość dodania do raportu kolumn: podpis i lokalizacja, umożliwiających odpowiednio podpisanie się na wydrukowanym raporcie określonego użytkownika np.: odbierającego dokument oraz wydruk lokalizacji fizycznej, w której umieszczono dokument papierowy. • książka doręczeń z uwzględnieniem następujących pól: data wprowadzenia dokumentu, numer kolejny dokumentu, kategoria dokumentu, data na dokumencie, znak na dokumencie, nadawca, adresat, opis dokumentu, data odbioru, data zwrotu. • książka pocztowa nadawcza w pełni zgodna ze wzorem ogłoszonym przez Pocztę Polską z uwzględnieniem pól: przedział czasowy od do, numery dokumentów od do, komórka organizacyjna, typ listu (zwykły, polecony), • spraw i dokumentów powiązanych z wybranym podmiotem, Strona 45 z 51 42.2 42.3 42.4 42.5 42.6 42.7 • bazy adresowej umożliwiający podział na podmioty prawne i fizyczne, oraz zawierający wszystkie pola opisujące podmiot, • spis dokumentów i spraw, do których dostęp posiadają podwładni wybranego użytkownika z uwzględnieniem pól: imię i nazwisko, sprawy (otwarte, zamknięte), dokumenty, przedział czasowy od do, • spis spraw wybranej komórki organizacyjnej z uwzględnieniem pól: przedział czasowy od do, właściciel sprawy, osoby prowadzące sprawy, • spis spraw i dokumentów własnych zawierający informacje o elementach, których użytkownik jest właścicielem bądź uczestniczy jako osoba prowadząca z uwzględnieniem pól: przedział czasowy od do, Raporty powinny być dostępne z poziomu dedykowanych funkcji, nie poprzez wyszukiwanie, tak aby użytkownik nie musiał za każdym razem definiować parametrów raportu a jedynie zmieniać np. zakres dat. SEOD musi umożliwiać podgląd raportów w formie graficznej widocznej na ekranie oraz ich eksport co najmniej do formatów xls, pdf. SEOD musi posiadać funkcję tzw. wyszukiwania prostego. Za jego pomocą musi być możliwe przeszukanie wszystkich elementów po wpisaniu szukanego słowa lub wyrażenia do okna wyszukiwania, bez konieczności zawężania widoku do poszczególnych elementów SEOD. Okno wyszukiwania prostego musi być cały czas widoczne podczas pracy z SEOD przynajmniej w zakresie prac realizowanych przez użytkowników załatwiających sprawy. Funkcja wyszukiwania prostego musi zapamiętywać przynajmniej 10 ostatnio wpisanych wyrażeń lub słów przez użytkownika i umożliwiać ich wybór z listy. Po wyborze szukane wyrażenie powinno być automatycznie wpisywane do okna wyszukiwania. SEOD musi umożliwiać tworzenie raportu ze zdefiniowanego zapytania wyszukującego w obiektach systemu – za pomocą mechanizmu wyszukiwania. System musi zapewnić wyeksportowanie wyników wyszukiwania do formatu co najmniej .xls lub .pdf. SEOD musi umożliwiać wygenerowanie eksportu do pliku .xls wybranego zakresu danych opisujących dokumenty, uwzględniając również pola formularzy dynamicznych np. w przypadku dokumentu typu faktura, opisywanego polami kwota netto, kwota brutto – tak aby raport taki umożliwiał np. sumowanie pól liczbowych w zewnętrznej aplikacji typu arkusz kalkulacyjny. Strona 46 z 51 42.8 43 43.1 SEOD musi umożliwić wybór kolumn, które mają być wyeksportowane do pliku arkusza kalkulacyjnego .xls. Gwarancja i serwis SEOD Wykonawca jest zobowiązany do zapewnienia 36 miesięcznego okresu gwarancyjnego dla dostarczonego rozwiązania SEOD w tym zapewnienia aktualizacji komponentów SEOD do wydawanych nowych (poprawionych) wersji. Spełnienie warunków 44. Sprzęt komputerowy – 44.1 45 45.1 45.2 45.3 45.4 Konfiguracja rozwiązania oraz specyfikacja parametrów minimalnych: TAK/NIE SEOD musi poprawnie pracować w oparciu o następującą konfigurację sprzętową będącą integralną częścią postępowania: Serwer systemu SEOD wraz z macierzą dyskową NAS do wykonywania backupu systemu oraz osprzętem dodatkowym w postaci skanerów dokumentowych, zapasowego źródła zasilania, przełącznika 1Gb/s, szafy serwerowej oraz przełącznika KVM.. Serwer bazodanowy dla systemu SEOD – 1 sztuka powinien posiadać parametry nie gorsze niż: Płyta główna: : Dedykowana, serwerowa, wyprodukowana i zaprojektowana przez producenta serwera, min 18 gniazd pamięci RAM, min 2 sloty PCIe x8 min 4 sloty PCIe 4x (min. dwa porty PCIe x4 powinny być możliwe do użycia jako PCIe x8 jeżeli sąsiedni slot jest pusty) min 10 portów USB (w tym min. 3 z przodu, 4 z tyłu i 2 w środku) 2 porty RS-232 (w tym jeden dostępny zarówno dla systemu jak i dla kontrolera zdalnego zarządzania) 2 porty VGA (1 z przodu, 1 z tyłu) Obudowa: RACK 19”, max.2U Procesory: Dwa procesory klasy serwerowej w architekturze x86, będące w produkcji nie dłużej niż 2 lata: - 64 bity, - min. 4 rdzenie, 8 wątków, - cache min. 8 MB Pamięć: Min: 32 GB RAM typu Advanced ECC, registered, DDR3 co najmniej 1333 MHz, z opcją aktywnej rezerwy i zapisu lustrzanego, obsadzone min. 2 gniazda w trybie niezależnym, Strona 47 z 51 45.5 45.6 45.7 45.8 45.9 45.10 45.11 45.12 możliwość rozbudowy do 192 GB HDD: 6 sztuk dysków twardych typu SATA II, hot-plug, nie mniejsze niż 500 GB, 3,5”, 7200 krpm każdy, wewnętrzne, pracujące w macierzy sprzętowej RAID 5. Serwer musi posiadać możliwość jednoczesnej instalacji dysków SATA i SAS. Kontrolery: SATA, 2 kanałowy SATA dla DVD i backupu, SAS 6G min. 8 portów: z obsługą min. RAID 5/6 Napęd: DVD-RW wewnętrzny Panel serwisowy z wyświetlaczem LCD Karty sieciowe: Dwie karty Ethernet 10/100/1000 Mb/s Jedna karta Ethernet 10/100 Mb/s do komunikacji z kontrolerem zdalnego zarządzania Zasilanie: Dwa redundantne zasilacze 800 W na zasilacz, zgodne ze standardem EPA, hot-plug, Sprawność min. 92% przy obciążeniu 50% (potwierdzone międzynarodowym raportem badawczym honorowanym w Unii Europejskiej) Chłodzenie: Nadmiarowe redundantne wentylatory typu hot-plug Oprogramowanie: Oprogramowanie zarządzające i diagnostyczne producenta serwera, pozwalające na konfigurację kontrolera RAID, instalację systemów operacyjnych, zdalne zarządzanie, diagnostykę i przewidywanie awarii w oparciu o zintegrowany w serwerze system monitorujący. 45.13 Kontroler zdalnego zarządzania: Zgodny z IPMI 2.0, pozwalający na zdalny restart serwera i pełne zarządzanie z przejęciem konsoli tekstowej. Dedykowana karta sieciowa dla kontrolera zdalnego zarządzania z możliwością przeniesienia tej komunikacji na inną kartę sieciową współdzieloną z systemem operacyjnym 45.14 System operacyjny serwera: Serwer musi być dostarczony z zainstalowanym systemem operacyjnym pozwalającym na pełną realizację całego Projektu SEOD, z odpowiednią do Projektu ilością licencji. Strona 48 z 51 45.15 45.16 45.17 46 46.1 46.2 46.3 46.4 46.5 46.6 46.7 46.8 47 47.1 47.2 47.3 47.4 47.5 47.6 47.7 47.8 47.9 47.10 Wymagana bezwzględna kompatybilność serwera z oferowanym w ramach projektu systemem operacyjnym, potwierdzona oświadczeniem Wykonawcy lub certyfikatem kompatybilności serwera z oferowanym systemem operacyjnym. Certyfikaty i normy: Serwer musi być produkowany zgodnie z normą ISO 9001 oraz spełniać normę EnergyStar Oferowany serwer musi być dostarczony z całym niezbędnym do działania wyposażeniem (kable połączeniowe, zasilające itp), wszystkie niezbędne instrukcje, licencje oprogramowania oraz nośniki ze sterownikami Gwarancja: Wymagana gwarancja na oferowany serwer to 36 miesięcy z gwarantowanym czasem naprawy w ciągu 24 godzin od zgłoszenia, możliwość zgłoszeń usterek 7x24h, potwierdzone oświadczeniem producenta serwera Macierz dyskowa NAS – 1 sztuka o parametrach nie gorszych niż: Obudowa: RACK 19” max.2U Obsługa dysków co najmniej SATA II, o pojemności do 2TB Możliwość pracy w konfiguracji RAID 0/1/5/6 z funkcją rozbudowy i zmiany trybu bez utraty danych 4 dyski twarde o pojemności 1TB, pracujące w konfiguracji RAID 5 Współpraca z zasilaczami awaryjnymi UPS po USB lub SNMP Monitorowanie stanu dysków Redundantne zasilanie Dwie karty sieciowe 1000 Mb/s Zapasowe źródło zasilania UPS – 1 sztuka o parametrach nie gorszych niż: Obudowa: RACK 19’’ Układ automatycznej regulacji napięcia AVR Sinus podczas pracy na baterii Programowanie godziny włącz/wyłącz Porty komunikacyjne RS232, USB Gniazda zasilające – 8 Diody sygnalizacyjne oraz alarmy dźwiękowe stanu baterii i urządzenia. Instrukcja obsługi Oprogramowanie zgodne z oferowanym systemem operacyjnym Urządzenie powinno być wyprodukowane zgodnie z wymaganiami normy jakości ISO 9001 lub równoważnej na cały proces produkcji Strona 49 z 51 47.11 Moc pozwalająca na podtrzymanie całości konfiguracji sprzętowej przez okres min. 20 minut i bezpieczne zamknięcie serwera oraz wyłączenie macierzy dyskowej. 48 Skanery dokumentowe - 2 sztuki Współpracujące z systemem SEOD, o parametrach nie gorszych niż: 48.1 Moduł skanowania dwustronnego w standardzie 48.2 Obciążenie miesięczne min: 1000 stron 48.3 Podajniki na dokumenty min: 100 stron 48.4 Certyfikat EnergyStar – wymagany wpis w bazie na stronach http://www.euenergystar.org, lub oświadczenie producenta. 49 49.1 49.2 49.3 49.4 49.5 49.6 Szafa serwerowa – 1 sztuka: Rodzaj: 19”, stojąca Wymiary: 600mm x 1000mm Wysokość: 42U Stelaż 19’’, Zamykana na klucz Drzwi przednie– trzypunktowe, z zamkiem, stalowe, z perforacją o zwiększonej przewiewności 49.7 Scianka tylna – zdejmowalna, zamykana na zamek, stalowa, z perforacją o zwiększonej przewiewności 49.8 Ścianki boczne – pełne, stalowe, demontowane, zamykane na zamek 49.9 49.10 49.11 49.12 50 50.1 50.2 50.3 50.4 50.5 50.6 50.7 51 51.1 51.2 51.3 51.4 51.5 51.6 51.7 51.8 51.9 51.10 Szkielet na cokole z wysuwaną ramą wsporczą Trzy pary belek nośnych w rozstawie 19”, regulowanych Wyposażenie: Listwa zasilająca i linki uziemienia Obciążenie min: 600 kg Konsola KVM do szafy serwerowej – 1 sztuka: konsola w pełni sprzętowa, montaż szuflady w stelażu 19’’, pojedyńcza szyna, z monitorem: 15’’ 8 portów PC/KVM wybór zarządzanego komputera: przycisk oraz skrót klawiszowy, wysuwana klawiatura z touchpadem Przełącznik sieciowy Gigabitowy – 1 sztuka: 16 x port 1Gb/s 4 x SFP (współdzielone) Zarządzalny, warstwa 2, Graficzny interfejs użytkownika przez www VLAN, 256 grup statycznych QoS Mirroring portów ARP-spoofing Agregacja łączy 802.3ad ACL, oparte o MAC/IP Strona 50 z 51 51.11 Uwierzytelnianie 802.1X RADIUS 51.12 Przystosowany do montażu w standardowej szafie 19’’ 51.13 Wyłączanie nieaktywnych portów w celu zmniejszenia zużycia energii tzw. zielone urządzenie ("green line"/"green IT"). 52 Wszystkie dostarczone urządzenia winny być wyposażone w niezbędne kable zasilające i połączeniowe, niezbędne oprogramowanie, sterowniki oraz instrukcje obsługi w języku polskim, oraz dokumenty potwierdzające spełnianie wymagań SIWZ w szczególności wszystkie certyfikaty spełniania wymaganych norm. 52.1 Wykonawca winien dołączyć do oferty pełną specyfikację oferowanego sprzętu obejmującą : typ, dokładny model, pełną konfigurację oraz producenta zaoferowanych komponentów sprzętowych. zgodnie z załącznikiem nr 9 do SIWZ. 52.2 Wykonawca jest zobowiązany do zapewnienia 36 miesięcznego okresu gwarancyjnego i serwisowego dla wszystkich dostarczonych komponentów sprzętu komputerowego .........................................., dnia. ....................... 2011r. …..……………..…................................................. (imię i nazwisko oraz czytelny podpis osoby/ osób uprawnionych do reprezentowania wykonawcy) Strona 51 z 51