WSTĘPNY OPIS SYSTEMU INFORMATYCZNEGO.

Transkrypt

1 WSTĘPNY OPIS SYSTEMU INFORMATYCZNEGO. Przedmiotem dialogu technicznego jest system informatyczny wspomagających zarządzanie Instytutem Podstawowych Problemów Techniki PAN w obszarach: system rozliczania i kontroli budżetów projektów współpracujący z serwisem intranetowym i systemem finansowo-księgowym (w skrócie: rozliczania projektów), system elektronicznego obiegu dokumentów (w skrócie: EOD) obejmujący obieg formularza wniosku o zakup oraz obieg faktury zakupu (z możliwością rozbudowy o obiegi innych dokumentów) powiązany z systemem rozliczania i kontroli budżetów projektów, system do elektronicznego obiegu wniosku o delegację oraz rozliczenia delegacji (w skrócie: rozliczania delegacji) powiązany z systemem rozliczania i kontroli budżetów projektów, System do wspomagający pracę działu zamówień publicznych. System powyższy musi zapewniać możliwość integracji z systemem ERP posiadanym przez Zamawiającego, tj. Zintegrowanym Systemem Informatycznym Xpertis, którego producentem jest firma Macrologic S.A. (m. in. zapewniając jednokrotne wprowadzanie danych do systemów i wymianę niezbędnych danych pomiędzy systemami, w szczególności z systemem finansowoksięgowym). Dopuszcza się możliwość zakupu systemu obejmującego pełny zakres wspomagania zarządzania Instytutem, obejmujący także obecnie wdrożone funkcjonalności programu Xpertis, tj. Finanse i Księgowość, Informacja Finansowa, Środki Trwałe, Kadry i Płace, Portal Firmowy Serwis Pracowniczy, Bankowość Elektroniczna, Fakturowanie, Alerty Biznesowe. Wymagania ogólne: 1. Systemy do rozliczania projektów, EOD, rozliczania delegacji, zamówień publicznych muszą być polskojęzyczne oraz posiadać dokumentację w języku polskim pozwalającą na samodzielną naukę. 2. Dostęp do oferowanego systemu rozliczania projektów dla pracowników w roli Kierownika Projektu lub Kierownika Zakładu musi być realizowany za pomocą przeglądarki internetowej. Dodatkowo musi być dostępny interfejs pracy w aplikacji bez wykorzystywania przeglądarki internetowej w standardowym interfejsie okienkowym Windows, 3. Dostęp do systemu EOD oraz rozliczania delegacji dla pracowników IPPT PAN musi być realizowany za pomocą przeglądarki internetowej. Dodatkowo musi być możliwość pracy w aplikacji bez wykorzystywania przeglądarki internetowej w standardowym interfejsie okienkowym Windows i X-Window (Linux). 4. Dostarczone systemy powinny umożliwiać uzależnienie dostępu do określonych danych i funkcjonalności od uprawnień jaka jest przypisana do użytkownika. 5. Systemy muszą być ze sobą zintegrowane aby nie było konieczności wprowadzania wielokrotnie tej samej informacji do poszczególnych systemów. Muszą również zostać zintegrowane z systemem ERP posiadanym przez Zamawiającego, tj. Zintegrowanym Systemem Informatycznym Xpertis, którego producentem jest firma Macrologic S.A. Strona 1 z 21

2 WYMAGANIA FUNKCJONALNE ZAMAWIAJACEGO W ZAKRESIE SYSTEMU DO ROZLICZANIA I KONTROLI BUDŻETÓW PROJEKTÓW WSPÓŁPRACUJĄCEGO Z SERWISEM INTRANETOWYM. Lp. RP1 RP2 RP3 RP4 RP5 RP6 RP7 RP8 Rozliczanie i kontrola budżetów projektów Tworzenie budżetów rzeczowo-finansowych dla poszczególnych komórek organizacyjnych. Tworzenie kalkulacji i budżetów kosztów oraz rozliczanie przychodów realizowanych zleceń (projektów). Bieżąca kontrola realizacji budżetów wraz z procentowym wskaźnikiem zaawansowania realizacji planu oraz odchyleniami zarówno dla budżetu pierwotnego jak i skorygowanego (możliwość przeprowadzenia analizy dla dowolnej wersji budżetu).. Tworzenie zbiorczego budżetu Instytutu na podstawie budżetów poszczególnych komórek organizacyjnych z możliwością rozdzielenia planowanych kosztów ogólnych na zaplanowane projekty według kluczy określonych przez użytkownika. Wielowymiarowe, definiowalne przez użytkownika analizy budżetów i ich realizacji z możliwością eksportu danych do arkusza kalkulacyjnego. Budżet i wykonanie udostępniane dla osób upoważnionych (przez przeglądarkę WWW i arkusze kalkulacyjne MS Excel). Pełna ewidencja umów realizowanych przez Instytut, możliwość tworzenia raportów w dowolnej konfiguracji między innymi według numeru umowy, tematu, stanowiska kosztów, osób odpowiedzialnych za realizację. Podpinanie oraz archiwizacja umów i innych dokumentów w postaci elektronicznej. Możliwość rozliczania wszystkich zlecanych i wykonywanych przez Instytut umów (częściowa realizacja umowy i całkowicie zakończona). Budżetowanie Osoba odpowiedzialna za proces budżetowania będzie miała możliwość samodzielnego: RP9 - budowania modeli danych do zabudżetowania (różne struktury budżetów w zależności od potrzeb projektu), - instalowania zdefiniowanych modeli w hurtowni danych - przygotowania procesu budżetowania - aktualizowania danych oraz elementów wymiarów w hurtowni danych RP10 Możliwość opisania poszczególnych elementów w strukturze do budżetowania dodatkowymi informacjami (cechami). Strona 2 z 21

3 RP11 RP12 RP13 RP14 RP15 RP16 RP17 RP18 RP19 RP20 RP21 RP22 RP23 RP24 RP25 RP26 RP27 Automatyczne tworzenie dodatkowych modeli do budżetowania, bazujących na modelach podstawowych w oparciu o dodatkowe informacje w nich zapisane, w wyniku czego powinny powstać dodatkowe modele z większą liczbą wymiarów uzupełnione automatycznie. Samodzielne tworzenie przez osoby odpowiedzialne za proces budżetowania formularzy do wprowadzania danych budżetowych przez użytkowników. Samodzielne definiowanie przez osoby odpowiedzialne za proces budżetowania harmonogramów budżetowania. Samodzielne definiowanie przez osoby odpowiedzialne za proces budżetowania zadań dla poszczególnych osób uczestników procesu budżetowania. Samodzielne wskazywanie przez osoby odpowiedzialne za proces budżetowania formularzy, w jakich będą wprowadzane dane przez uczestników procesu budżetowania. Samodzielne definiowanie przez osoby odpowiedzialne za proces budżetowania ram czasowych zadań dla poszczególnych uczestników procesu budżetowania. Samodzielne definiowanie przez osoby odpowiedzialne za proces budżetowania procesów przetwarzających wprowadzane dane, w celu uzyskania symulacji wyników. Możliwość tworzenia wielu wersji budżetów. Powiadamianie uczestnika procesu budżetowania o zadaniu budżetowym. Możliwość pobrania formularza do wprowadzenia danych do budżetowania przez przeglądarkę internetową. Możliwość wprowadzenia danych do budżetu przez arkusz kalkulacyjny. Bieżąca informacja w systemie o stanie (postępie) procesu budżetowania. Możliwość tworzenia jednego formularza dla wielu uczestników procesu budżetowania. Możliwość zawężania zakresu danych widocznych w formularzu uniwersalnym dla poszczególnych uczestników budżetowania podczas definiowania zadań dla konkretnych osób. Możliwość przerywania przez uczestników procesu budżetowania pracy nad arkuszem budżetowym, zapisania wprowadzonych już danych i powrotu do wprowadzania w późniejszym czasie z możliwością pobrania już wprowadzonych danych. Bieżąca weryfikacja i analiza danych wysyłanych do systemu przez uczestników budżetowania. Możliwość wprowadzenia w formularzu do wprowadzania danych budżetowych, kolumny z wartościami z poprzedniego roku obrachunkowego. Strona 3 z 21

4 RP28 Możliwość skorzystania podczas tworzenia arkuszy do budżetowania wynagrodzeń z aktualnej listy pracowników podległych kierownikowi wypełniającymi budżet cząstkowy. RP29 Automatyczne tworzenie formularzy do budżetowania wynagrodzeń dla pracowników podległych wybranemu kierownikowi. RP30 RP31 RP32 RP33 RP34 RP35 RP36 RP37 RP38 RP39 RP40 RP41 RP42 RP43 Możliwość kopiowania danych pomiędzy modelami do budżetowania. Możliwość wskazania w zadaniach budżetowych osoby wprowadzającej dane i zatwierdzającej wprowadzone wartości. Możliwość wprowadzania różnych algorytmów dla tej samej pozycji budżetowej w zależności od wersji planu i wykonania. Tworzenie budżetów operacyjnych. Okresy analityczne: miesiąc, kwartał, rok. Możliwość tworzenia innych okresów analitycznych niż wymienione (niezależnie dla każdego projektu). Możliwość definicji słownika MPK (Miejsce Powstawania Kosztów) w układzie hierarchicznym. Możliwość zdefiniowania struktury organizacyjnej instytutu. Możliwość definiowania projektów wraz z jego etapami (zadaniami). Możliwość łączenia projektów w grupy projektów. Możliwość budżetowania projektów. Możliwość przygotowania szablonu budżetu. Planowanie sprzedaży ilościowe oraz wartościowe. Rozliczenie kosztów poprzez zastosowanie rozdzielników kosztów. Możliwość pracy z kilkoma wersjami budżetu. Kontrola wykonania budżetu (controlling) RP44 RP45 RP46 RP47 RP48 RP49 RP50 Analiza wykonania w zdefiniowanych okresach analitycznych (RP34) i narastająco. Możliwość analizy wykonania budżetu. Możliwość dokonywania korekt budżetu. Możliwość analizy porównawczej między wersjami planu. Raportowanie porównawcze planu i wykonania. Raportowanie porównawcze planu i wykonania/ rok do roku (okres analityczny do okresu analitycznego). Raporty na MPK (Miejsce Powstawania Kosztów) plan/wykonanie/%odchylenia. Strona 4 z 21

5 RP51 RP52 Raporty dla Zarządu w układzie na jednostki organizacyjne. Prognozowanie wykonania planu na koniec okresu analitycznego. RP53 Możliwość wykonania sprawozdań finansowych na podstawie danych planowanych. RP54 Zestawienia wybranych wskaźników ekonomicznych wykonywanych w oparciu o dane z wykonania oraz dane planowane: - Analizy porównawcze plan/wykonanie - Realizacja wartościowa umów w podziale na poszczególne działalności, projekty - Analiza porównująca koszty planowane z kosztami rzeczywistymi RP55 RP56 RP57 RP58 RP59 RP60 RP61 Porównanie planów wieloletnich. Ustalenie odchyleń w poszczególnych latach w planie wieloletnim. Analiza odchyleń. Możliwość kontroli budżetu podczas akceptowania wniosków o zapotrzebowanie zakupu. Możliwość blokady akceptacji wniosków o zapotrzebowanie zakupu w sytuacji przekroczenia budżetu. W kontroli budżetu powinny być uwzględnione dokumenty: zaakceptowane wnioski o zapotrzebowanie zakupu, faktury zakupu w obiegu (faktury jeszcze nie zaksięgowane) oraz dokumenty zaksięgowane, a także inne dokumenty prognozujące koszty z systemów EOD i rozliczania delegacji (np.: wnioski o delegacje wg szacunku kosztów). Umożliwienie rozliczania projektów na potrzeby różnych jednostek finansujących. Wprowadzenie opisu faktur kosztowych, w tym pól: zadanie, kategoria kosztów, kategoria kosztów/opis kategorii kosztów, netto, VAT, suma (brutto), kwota kwalifikowana netto, kwota kwalifikowana VAT, suma (kwoty kwalifikowana brutto), przypisanie do raportu rozliczeniowego składanego do instytucji rozliczającej projekt w którym znalazł się dokument. RP62 RP63 RP64 RP65 Możliwość uzyskania z systemu raportów w szczególności: o wniosek o płatność o raport w postaci Excel do przekazywania do generatora wniosków o płatność o postęp rzeczowo-finansowy. Możliwość samodzielnego tworzenia raportów przez użytkowników. Możliwość generowania raportów przez użytkowników. Możliwość przypisywania raportów do użytkowników. Strona 5 z 21

6 RP66 RP67 RP68 RP69 RP70 RP71 Możliwość udostępniania raportów przez stronę internetową. Możliwość przypisywania uprawnień do danych dla poszczególnych użytkowników na poziomie poszczególnych elementów wymiarów (np. do jednego rodzaju wartości i jednego MPK (Miejsce Powstawania Kosztów)). Możliwość oglądania raportów w arkuszu kalkulacyjnym Excel. Możliwość oglądania raportowanych danych na urządzeniach mobilnych. Wizualizacja danych w raportach. Definiowanie różnego rodzaju analiz i zestawień ekonomiczno finansowych w tym porównania danych z różnych okresów. Analiza wykonania budżetu: RP72 RP73 RP74 według projektów według struktury organizacyjnej według rodzajów według źródeł finansowania Wszystkie raporty dot. controlingu powinny dawać możliwość wyboru konkretnych komórek organizacyjnych ze struktury organizacyjnej, przedziałów czasowych, syntetyki i analityki kont. Automatyczne pobranie danych (wykonań) do systemu rozliczania projektów systemu ERP Xperits. Weryfikacja automatyczna danych w systemie finansowo-księgowym przez system controllingowy przed pobraniem danych do systemu controllingowego w zakresie: - Czy wszystkie dokumenty są zaksięgowane - Czy wszystkie dokumenty są zaakceptowane controllingowo - Czy wszystkie dokumenty opisano controllingowo - Czy występuje zgodność pomiędzy wartościami dla controllingu a wartościami księgowymi RP75 Możliwość dekretowania controllingowego dokumentów w systemie finansowoksięgowym. RP76 Podgląd na dekretację controllingową dokumentu z poziomu dokumentu księgowego. RP77 Powiązanie wymiarów controllingowych z słownikami analitycznymi kont księgowych. RP78 Możliwość pogrupowania dekretów controllingowych na grupy i zdefiniowania w systemie controllingowym mechanizmów sprawdzających zgodność zapisów w grupach z zapisami księgowymi na kontach syntetycznych. Strona 6 z 21

7 RP79 RP80 RP81 RP82 RP83 RP84 RP85 RP86 RP87 RP88 RP89 RP90 RP91 RP92 RP93 RP94 RP95 RP96 Możliwość zdefiniowania w systemie controllingowym formuł do automatycznej dekretacji dokumentów z systemu finansowo-księgowego. Możliwość zdefiniowania w systemie controllingowym formuł do automatycznej dekretacji dokumentów z systemu sprzedażowego. Możliwość zdefiniowania w systemie controllingowym formuł do automatycznej dekretacji dokumentów z systemu magazynowego. Możliwość zdefiniowania w systemie controllingowym formuł do automatycznej dekretacji dokumentów z systemu kadrowo płacowego. Możliwość zdefiniowania w systemie controllingowym formuł do automatycznej dekretacji dokumentów z systemu do ewidencji środków trwałych. Możliwość zdefiniowania w systemie controllingowym formuł do automatycznej dekretacji dokumentów z systemu kasowego. Możliwość wskazywania sposobu dekretacji controllingowej dla konkretnych środków trwałych. Możliwość wskazywania sposobu dekretacji controllingowej dla poszczególnych pracowników. Możliwość wskazywania sposobu dekretacji controllingowej dla poszczególnych zleceniobiorców. Utworzenie automatyczne zapisów controllingowych dla dokumentów księgowych z poziomu systemu controllingowego. Utworzenie automatyczne dekretów controllingowych dla amortyzacji środków trwałych z poziomu systemu controllingowego. Utworzenie automatyczne dekretów controllingowych dla umów zleceń z poziomu systemu controllingowego. Utworzenie dekretów controllingowych dla list płac z poziomu systemu controllingowego. Sprawdzenie wykonania dekretacji księgowej amortyzacji przed pobraniem danych do systemu controllingowego. Sprawdzenie wykonania dekretacji dokumentów magazynowych przed pobraniem danych do systemu controllingowego. Sprawdzenie wykonania dekretacji list płac przed pobraniem danych do systemu controllingowego Sprawdzenie wykonania dekretacji raportów kasowych przed pobraniem danych do systemu controllingowego Możliwość pobierania automatycznego danych do controllingu z dokumentów magazynowych. Strona 7 z 21

8 RP97 RP98 RP99 Możliwość pobierania automatycznego danych do controllingu z dokumentów sprzedaży. Możliwość pobierania automatycznego danych do controllingu z dokumentów związanych z środkami trwałymi. Możliwość pobierania automatycznego danych do controllingu z dokumentów z systemu kadrowo płacowego. RP100 Możliwość pobierania automatycznego danych do controllingu z dokumentów finansowo księgowych. RP101 Możliwość "zejścia" w analizach do poszczególnych zapisów controllingowych składających się na daną pozycję zagregowaną w sprawozdaniu. RP102 Możliwość wprowadzania do systemu wartości pomocniczych, które następnie będą wykorzystywane w przeliczeniach, np. kursu waluty dla całego modelu w jednym zapisie. RP103 Weryfikacja zgodności zapisów księgowych z podziałami controllingowymi. RP104 Aktualizacja struktur controllingowych na podstawie kartotek z innych modułów systemu, np. kontrahentów. RP105 Możliwość importu zagregowanych wartości dla controllingu pliku tekstowego. RP106 Możliwość agregowania dekretów controllingowych dla dokumentów księgowych. RP107 Możliwość agregowania dekretów controllingowych dla list płac. RP108 Utworzenie dekretów controllingowych dla planów amortyzacji. RP109 Aktualizacja dekretów controllingowych na podstawie wartości pomocniczych wprowadzanych do systemu, np. kursów walut. RP110 Możliwość samodzielnego definiowania przez upoważnionych użytkowników kluczy podziałowych kosztów w systemie dla controllingu. RP111 Możliwość alokacji wartości dla controllingu wybranymi kluczami podziałowymi. RP112 Kopiowanie danych pomiędzy wersjami danych. RP113 Możliwość pobrania danych dla modelu controllingowego z innych modeli. RP114 Możliwość aktualizacja definicji hurtowni danych z poziomu systemu controllingowego. RP115 Możliwość aktualizacja wartości i przetwarzanie kostki danych z poziomu systemu controllingowego. RP116 Możliwość definiowania dodatkowych, niestandardowych formuł przetwarzania danych w systemie controllingowych. Strona 8 z 21

9 RP117 Usuwanie automatycznych dekretów controllingowych dla dokumentów księgowych z poziomu systemu controllingowego. RP118 Możliwość usuwania wartości zagregowanych dla modelu z poziomu systemu controllingowego. RP119 Możliwość wycofywania akceptacji dekretów controllingowych dla dokumentów z poziomu systemu controllingowego. RP120 Możliwość oglądania dokumentów księgowych z poziomu systemu controllingowego. RP121 Możliwość nakładania filtrów na przeglądane dokumenty księgowe w zależności od statusu w systemie controllingowym. RP122 Możliwość wyświetlania informacji o dokumentach źródłowych na podstawie których zaprezentowana została wartość wykonania budżetu. WYMAGANIA FUNKCJONALNE ELEKTRONICZNY OBIEG WNIOSKU O ZAPOTRZEBOWANIE ZAKUPU I FAKTURY ZAKUPU Lp. EO1 Elektroniczny obieg wniosku o zapotrzebowanie zakupu i faktury zakupu Rejestrowanie faktury zakupu, poprzedzone elektronicznym obiegiem wniosku o zapotrzebowanie zakupu zgodnie z procedurą akceptacji obowiązującą w Instytucie. Możliwość kontroli wpływu dokonania zakupu na budżet projektu czy umowy. Możliwość kontroli wpływu dokonania zakupu na budżet umowy zgodnie z Ustawą o Zamówieniach Publicznych. Powyższa kontrola ma uwzględniać zarówno dokumenty zaksięgowane, dokumenty w obiegu jak i wnioski o zapotrzebowanie zakupu. Opisanie wniosku o zapotrzebowanie zakupu zgodnie z wymaganymi przez Instytut informacjami tj. co najmniej jednostka organizacyjna, projekt, pozycja kosztowa, źródło finansowania. Powiązanie wniosku o zapotrzebowanie zakupu z fakturą zakupu. Zadekretowanie faktury zakupu na odpowiednie konta wynikające z wprowadzonego opisu podczas elektronicznego obiegu. EO2 Definiowanie przez użytkownika systemu różnych typów wniosków o zapotrzebowanie zakupu oraz różnych typów faktur zakupu. EO3 Możliwość definiowania dla poszczególnych typów wniosków o zapotrzebowanie zakupu oraz faktur zakupu wymagalnych danych do wprowadzenia przez użytkownika. Strona 9 z 21

10 EO4 Możliwość wprowadzenia na wniosku o zapotrzebowanie zakupu co najmniej: - wartości netto i brutto - zakresu dat - kontrahenta - pracownika - kodu materiału z systemu magazynowego - ilości - jednostki organizacyjnej - projektu - umowy - źródła finansowania EO5 EO6 EO7 EO8 EO9 Możliwość wprowadzenia na fakturze zakupu co najmniej: - wartości netto, VAT, brutto - daty wystawienia, - daty płatności, - kontrahenta. - skanu faktury. Możliwość wprowadzenia formuły sprawdzającej czy wypełnione zostały prawidłowo wszystkie wymagane pola na wniosku o zapotrzebowanie zakupu oraz fakturze zakupu. Możliwość określenia różnej procedury elektronicznego obiegu dla różnych typów wniosków o zapotrzebowanie zakupu czy różnych typów faktur zakupu oraz dowolnej ilości etapów elektronicznego obiegu. Możliwość wprowadzania przez operatora akceptującego opisów słownych do wniosków o zapotrzebowanie zakupu oraz faktury zakupu na poszczególnych etapach elektronicznego obiegu. Wniosek o zapotrzebowanie zakupu oraz faktura zakupu powinny być identyfikowane w systemie co najmniej przez unikany numeru (ID dokumentu) nadawany przez system bez możliwości jego zmiany przez użytkownika. Możliwość określenia dla różnych typów faktur zakupu - na potrzeby automatycznej dekretacji - różnego rejestru księgowego oraz rodzaju dokumentu księgowego. EO10 Możliwość wprowadzenia formuły do wykonania przez system w przypadku akceptacji, odrzucenia czy wycofania dokumentu w elektronicznym obiegu. EO11 Możliwość akceptowania lub odrzucenia wniosku o zapotrzebowanie zakupu czy faktury zakupu przez wskazane osoby na poszczególnych etapach. Możliwość odrzucania opisywanego dokumentu do poprzedniego etapu lub do początku obiegu. EO12 Możliwość wskazania jednej bądź wielu osób do akceptacji na danym etapie. Możliwość wprowadzenia na danym etapie obowiązku akceptacji dokumentu przez kilka osób, aby przeszedł on do kolejnego etapu. EO13 Możliwość automatycznego wyboru operatora akceptującego dokument poprzez wprowadzenie odpowiedniej formuły. Strona 10 z 21

11 EO14 Możliwość wskazania podpowiadanej domyślnej grupy użytkowników do akceptacji dla danego etapu obiegu. EO15 Kontrola budżetu projektu/umowy/zadania tj. czy akceptowany wniosek o zapotrzebowanie zakupu nie przekracza budżetu, poprzez sprawdzenie kwoty wynikającej z innych złożonych wcześniej wniosków o zapotrzebowanie zakupu, faktur w obiegu (niezaksięgowanych) oraz dokumentów zaksięgowanych. Możliwość wskazania różnych parametrów dla kontroli budżetu, w tym wartości procentowych oraz kwotowych. EO16 Możliwość blokowania akceptacji zapotrzebowań przekraczających budżet. EO17 Możliwość wprowadzania limitów kwotowych dla operatorów, do których mają prawo akceptować wnioski o zapotrzebowanie zakupu. EO18 Możliwość wysyłania powiadomień mailowych w przypadku akceptacji wniosku o zapotrzebowanie zakupu przekraczającego budżet zarówno wartościowo jaki i ilościowo. EO19 Powiązanie wniosku o zapotrzebowanie zakupu z fakturą zakupu, która dotyczy realizacji wniosku o zapotrzebowanie zakupu. EO20 Kontrola budżetu projektu/umowy/zadania tj. czy akceptowana faktura zakupu nie przekracza budżetu, poprzez sprawdzenie kwoty wynikającej z innych złożonych wcześniej faktur zakupu w obiegu i dokumentów zaksięgowanych. EO21 Możliwość wprowadzania limitów kwotowych dla operatorów, do których mają prawo akceptować faktury zakupu. EO22 Możliwość blokowania akceptacji faktur w obiegu przekraczających budżet. EO23 Możliwość wysyłania powiadomień mailowych w przypadku akceptacji faktury zakupu przekraczającej budżet projektu/umowy/zadania zarówno wartościowo jaki i ilościowo. EO24 Możliwość ewidencji przetargów wraz z informacją szczegółową jakiego przedmiotu/usługi dotyczą (w oparciu o słownik CPV). EO25 Możliwość ewidencji umów oraz pozycji umów opartych na słownikach CPV. Dodatkowo umożliwienie kontroli wykorzystania umowy w zakresie ilości, kwoty oraz terminów ważności umów. EO26 Dwuetapowe rejestrowanie dokumentów zakupu tj. faktury zakupu. I etap: rejestracja dokumentu faktury zakupu wpływających do Instytutu. Termin płatności zarejestrowanego dokumentu powinien być widoczny w systemie bez konieczności jej dekretacji. Do zarejestrowanego dokumentu powinna być możliwość podpięcia skanu dokumentu. II etap: dekretacja na odpowiednie konta. W trakcie dekretacji dostępny podgląd skanu dokumentu. Strona 11 z 21

12 EO27 System powinien zapewnić możliwość wydruku raportu zawierającego wszystkie dekrety kontrolingowe i informacje o akceptacji danego dokumentu, który będzie mógł być dołączony do oryginału dokumentu w postaci papierowej w celu prezentacji realizacji pełnego procesu obiegu faktury. WYMAGANIA FUNKCJONALNE ELEKTRONICZNY OBIEG WNIOSKU O DELEGACJĘ I ROZLICZENIE DELEGACJI Lp. OD1 OD2 OD3 OD4 OD5 OD6 OD7 OD8 OD9 Elektroniczny obieg wniosku o delegację i rozliczenie delegacji Możliwość złożenia przez pracownika w sposób elektroniczny wniosku o delegację krajową lub zagraniczną oraz wniosku o zaliczkę na delegację. Możliwość wprowadzania przez pracownika wniosków o delegację, wniosku o zaliczkę do delegacji, delegacji przez przeglądarkę internetową. Elektroniczny obieg wniosku o delegację krajową oraz wniosku o delegację zagraniczną musi uwzględniać obowiązujące w Instytucie procedury akceptacji. Proces akceptacji dokumentów zawiązanych z delegacjami powinien odbywać się przez przeglądarkę internetową. Złożony przez pracownika wniosek o delegacje powinien zawierać co najmniej informacje dotyczące projektu/umowy, struktury organizacyjnej, pozycji kosztowej, źródła finansowania. Możliwość wprowadzenia przez pracownika danych odbytej delegacji wraz z możliwością podpięcia skanów np. faktur, biletów i innych poniesionych wydatków podczas delegacji. Możliwość wprowadzenia delegacji na podstawie wniosku o delegację. Możliwość powiązania wniosku o delegację z odbytą delegacją. System powinien w sposób automatyczny naliczyć diety do delegacji (krajowej i zagranicznej). OD10 Rozliczenie delegacji powinno uwzględniać pobrane przez pracownika zaliczki. OD11 Automatyczne dekretowanie delegacji do systemu finansowo-księgowego (krajowej i zagranicznej). Strona 12 z 21

13 WYMAGANIA FUNKCJONALNE ZAMÓWIENIA PUBLICZNE Lp. ZP1 Elektroniczny obsługa procesu zamówień publicznych Cel ogólny: Zadaniem modułu jest automatyzacja pracy Zespołu Zamówień Publicznych przez informatyczne prowadzenie spraw związanych z procesem realizacji zamówień z podziałem na te do 30 tys. euro oraz powyżej 30 tys. euro zgodnie z ustawą z dnia 29 stycznia 2004 r. Prawo Zamówień Publicznych (Dz.U poz. 907 z póżn. zm.) zwaną dalej Pzp. Moduł musi współpracować z pozostałymi modułami systemu w szczególności z ewidencją zakupów, fakturowania i umów. Postępowania do 30 tys. euro. System musi uwzględniać zasady postępowania ujęte w Regulaminie wewnętrznym IPPT ZP 2 ewidencja faktur zakupowych przy wartości do 1000 euro. ewidencja druków zapotrzebowań z przydzieleniem sposobu realizacji zgodnie z ZP 3 Regulaminem oraz określeniem ich statusu (zgłoszony, w trakcie realizacji, wykonane, inny) Przekształcenie w procedurę realizacji zapotrzebowania, wygenerowanie i ZP 4 ewidencjonowanie dokumentów (zapytanie cenowe, protokół, zlecenie, umowa, itp.) rejestr wszystkich postępowań z podziałem na poszczególne kategorie ZP 5 (komputerowe, materiały, usługi, zatrudnienie, itd.) ZP 6 powiązanie rejestru z powyższej pozycji z zbiorczym rejestrem umów Postępowania powyżej 30 tys. euro. ZP 7 ewidencja druków zapotrzebowań (przy uwzględnieniu: zgłaszającego, wartości szacunkowej netto, źródła (jednego lub kilka z podziałem na kwoty) finansowania) z przydzieleniem sposobu realizacji oraz określeniem ich statusu (zgłoszony, w trakcie realizacji, wykonane, inny) ZP 8 ZP 9 ZP 10 ZP 11 przekształcanie druku zapotrzebowania (także kumulowanie wielu druków) na wybrany rodzaj postępowania (przetargowe, zapytanie o cenę, itd.) obsługa postępowań we wszystkich trybach ujętych w Pzp generowanie wymaganych dokumentów do publikacji na stronach internetowych zamawiającego na wszystkich etapach postępowania wraz z mechanizmami edycji, oraz generacja ogłoszeń w postaci plików PDF publikowanie na stronie WWW materiałów do pobrania (Ogłoszenie, SIWZ, załączniki do SIWZ, inne) wraz z mechanizmami ładowania aktualnych wersji dokumentów ZP 12 automatyczne wysyłanie informacji mailowej o ogłoszeniach przetargowych do wskazanych, potencjalnych wykonawców ZP 13 przygotowanie i publikowanie na stronie WWW nowych lub nowszych wersji dokumentów ZP 14 mechanizm publikowania odpowiedzi na zapytania do SIWZ ZP 15 zarządzanie Kalendarzem Postępowania z funkcją sygnalizacji upływających terminów z określonym przez użytkownika wyprzedzeniem Strona 13 z 21

14 prowadzenie i monitorowanie postępowania od jego rozpoczęcia poprzez rozstrzygnięcie do zawarcia umowy (wykonawcy, kwoty umowy) i ewidencjonowania ZP 16 przebiegu jej realizacji z uwzględnieniem jego statusu (w przygotowaniu, otwarty, itd.) z uwzględnieniem możliwości unieważnienia postępowania i procedury wynikłej z odwołania. ZP 17 rejestracja informacji o pobraniach dokumentów przez wykonawców automatyczne informowanie wykonawców drogą mailową o zmianach w materiałach ZP 18 przetargowych, wystosowanych zapytaniach do SIWZ i odpowiedziach oraz wniesionych odwołaniach ZP 19 generowanie dokumentów Komisji przetargowej dla procedury otwarcia ofert wspomaganie procesu wyboru oferentów dla danego postępowania poszczególnych ZP 20 na podstawie założonych kryteriów Obsługa postępowania, wybór najkorzystniejszej oferty, publikacja dokumentu ZP 21 ogłoszenie o wyborze najkorzystniejszej oferty. ZP 22 rejestracja wraz z dokumentowaniem treści zawieranych umów (np. w formie skanu) ZP 23 publikacja ogłoszenia o udzieleniu zamówienia automatyczne tworzenie protokołu postępowania na podstawie Informacji ZP 24 wprowadzonych do systemu w trakcie prowadzenia postępowania ZP 25 monitorowanie realizacji umowy (protokół/y odbioru, faktury, zwrot zabezpieczeń) Funkcje i uwarunkowania ogólne generowanie rocznego sprawozdania o udzielonych zamówieniach publicznych ZP 26 zgodnie z wymogami Pzp ZP 27 utworzenie elektronicznego archiwum dokumentów wszystkich prowadzonych postępowań zamówień publicznych ZP 28 tworzenie statystyk i raportów z wprowadzonych do systemu wniosków i postępowa ZP 29 prowadzenie Planu zamówień publicznych i weryfikacja z rzeczywiście dokonanymi zakupami ZP 30 wbudowany Wspólny Słownik Zamówień (słownik główny i uzupełniający CPV) zarządzanie użytkownikami systemu oraz przypisanymi uprawnieniami dla różnych ZP 31 ról w systemie ZP 32 możliwość zmiany wysokości progów finansowych wynikającej ze zmiany przepisów ZP 33 budowa i możliwość wykorzystania jednolitej bazy wykonawców ZP 34 wszystkie dokumenty, niezależnie od ich roboczej postaci plikowej, mają być przechowywane w bazie danych i udostępnione dla osób upoważnionych ZP 35 użytkownik musi mieć możliwość zastosowania własnego systemu numeracji Strona 14 z 21

15 WYMAGANIA TECHNICZNE Lp. WT1 WT2 WT3 WT4 WT5 Architektura i platforma systemowa Systemy do rozliczania projektów, EOD, rozliczania delegacji będą w pełni zintegrowane, pracujące w oparciu o środowisko bazodanowe. Wszystkie dane będą przechowywane w relacyjnej bazie danych. Dostarczone systemy do rozliczania projektów, EOD, rozliczania delegacji muszą pracować w technologii trójwarstwowej: Serwer bazy danych Serwer aplikacji Cienki klient, umożliwiająca pracę w sieci LAN jak i WAN. Systemy do rozliczania projektów, EOD, rozliczania delegacji muszą zapewnić: publikowanie danych na witrynie WWW, które pobierane są bezpośrednio z systemu ERP Xpertis, wprowadzanie i modyfikację danych w systemie ERP Xpertis z poziomu systemu rozliczania projektów, zarówno z wykorzystaniem przeglądarki internetowej jak i bez przeglądarki w standardowym interfejsie okienkowym Windows. wprowadzanie i modyfikację danych w systemie ERP Xpertis z poziomu systemu elektronicznego obiegu dokumentów. Wymagane jest aby serwer bazy danych na którym pracować będzie system do rozliczania projektów pracował w systemach rodziny Windows (Windows 2000 Server, Windows 2003, Windows 2008, Windows Server 2012) lub Linux. WT6 Wymagane jest aby serwer bazy danych, na którym pracować będzie oprogramowanie do elektronicznego obiegu dokumentów oraz rozliczania delegacji pracował w systemach z rodziny Windows (Windows 2000 Server, Windows 2003, Windows 2008, Windows Server 2012) oraz Linux. Ponadto powinno być możliwe przeniesienie danych pomiędzy platformami bez zmiany ich formatu oraz migracja z systemu Windows na Linux nie powinna wymagać dostosowywania aplikacji do nowego środowiska czyli: modyfikacji algorytmów aplikacji, konwersji bazy danych itp. WT7 WT8 WT9 Wymagane jest aby system rozliczania projektów obsługiwał dwie wersje serwera bazy danych w zależności od wielkości obsługiwanych zasobów serwer bazy danych w wersjach: 32 i 64-bitowych dla środowiska Windows. Wymagane jest aby oferowany system elektronicznego obiegu dokumentów oraz rozliczania delegacji obsługiwał dwie wersje serwera bazy danych w zależności od wielkości obsługiwanych zasobów serwer bazy danych w wersjach: 32 i 64- bitowych zarówno dla środowiska Windows jak i Linux. Niezależnie od systemu operacyjnego Windows czy Linux system elektronicznego obiegu dokumentów oraz rozliczania delegacji powinien posiadać taki sam interfejs i taką samą funkcjonalność. WT10 Wymagane jest aby końcówki klienckie na których działać będą systemy działały w środowisku Windows. Strona 15 z 21

16 WT11 Oferowany system rozliczania projektów musi być zgodny z systemami: Windows 7, Windows Vista, Windows XP Pro (Compatible with Microsoft Windows 7, Certified for Microsoft Windows Vista). WT12 System elektronicznego obiegu dokumentów oraz rozliczania delegacji musi być zgodny z systemami: Windows 7, Windows Vista, Windows XP Pro i SUSE Linux (Compatible with Microsoft Windows 7, Certified for Microsoft Windows Vista, SUSE Linux Ready). WT13 Połączenia pomiędzy końcówkami użytkownika a serwerem aplikacji muszą być szyfrowane protokołem SSL. WT14 Do pracy w sieci rozległej w środowisku graficznym nie może być wymagane dodatkowe oprogramowanie terminali Windows (np. Windows NT TSE, Terminal Services w Windows 2000/2003/2008, oprogramowanie Citrix Metaframe, itp.). WT15 System powinien być wyposażony w wbudowany debugger oraz profiler w celu śledzenia wykonania kodu oraz wykrywania długotrwających lub często wykonywanych operacji. WT16 Dostęp do danych w bazie danych musi być możliwy przy użyciu co najmniej sterowników ODBC i JDBC. WT17 WT18 Oferowane rozwiązanie musi mieć możliwość pracy zdalnej z wykorzystaniem protokołu VPN. Oferowane rozwiązanie musi mieć możliwość pracy w sieci rozległej, także przy wykorzystaniu łączy o niskiej przepustowości. Do pracy w sieci rozległej w środowisku graficznym nie powinno być wymagane dodatkowe oprogramowanie wspomagające pracę terminalową. WT19 Baza danych musi zapewnić możliwość przechowywania minimum 2TB danych. WT20 WT21 System bazy danych musi umożliwiać podłączenie wielu baz danych do jednej instancji serwera baz danych. System baz danych umożliwia rozdzielenie plików bazy danych na różne dyski. W szczególności dotyczy to rozdzielnych zestawów danych, jak dane produkcyjne, dane testowe. WT22 Oferowane rozwiązanie musi umożliwiać budowę hurtowni danych. WT23 WT24 Oferowane rozwiązanie musi zawierać możliwość przeprowadzania analiz, w tym analiz przy użyciu kostek OLAP. Dodatkowo oferowane rozwiązanie powinno mieć możliwość użycia mechanizmów typu ETL w celu sprawnego zasilania danymi do analiz. Oferowane rozwiązanie musi zapewniać współpracę z oprogramowaniem biurowym: Microsoft Office 2007 i nowszym (zarówno w wersjach 32bit jak i 64bit). Strona 16 z 21

17 WT25 WT26 WT27 Oferowane rozwiązanie musi umożliwiać tworzenie portali firmowych dostępnych w sieci Internet/Intranet przy wykorzystaniu aplikacji webowych typu Content Management System. Portale firmowe powinny mieć możliwość udostępniania funkcjonalności i danych z zasobów systemu ERP Xpertis. W przypadku użycia rozwiązań opartych o przeglądarkę internetową oferowane rozwiązanie powinno poprawnie działać na najnowszych wersjach przeglądarek internetowych Internet Explorer, Firefox, Chrome, Safari, Opera.. WT28 Oferowane rozwiązanie musi zapewniać możliwość otwierania plików załączonych do systemu za pomocą domyślnie skojarzonych z nimi programów. W szczególności dotyczy to dokumentów tekstowych, plików graficznych, arkuszy kalkulacyjnych, archiwów (ZIP, RAR, 7ZIP), dokumentów w formacie PDF. WT29 WT30 WT31 Oferowane rozwiązanie powinno zapewniać możliwość eksportu danych do plików. W szczególności powinny być obsługiwane pliki w formatach TXT, CSV, XLS, XLSX, XML, PDF, HTML, HTMLX. Oferowane rozwiązanie powinno zapewniać możliwość importu danych z plików. W szczególności powinny być obsługiwane pliki w formatach TXT, CSV, XML, XLS. Oferowane rozwiązanie powinno zapewniać możliwość generowania kodów 2D (kodów kreskowych) jak i 3D (QR Code). Dodatkowo powinna być możliwość odczytywania (lub współpracy z zewnętrznymi urządzeniami odczytującymi) takich kodów. Dostęp do danych i funkcji WT32 Każdy użytkownik systemu musi posiadać konto identyfikowane przez unikalny identyfikator. WT33 Użytkownik systemu musi być uwierzytelniany poprzez podanie hasła. WT34 W przypadku uwierzytelniania za pomocą hasła, oferowane rozwiązanie musi umożliwiać zastosowanie dodatkowych mechanizmów silnego hasła. W szczególności powinny być dostępne funkcjonalności: - wymuszenie odpowiedniej budowy hasła, - definiowanie okresu ważności hasła, - wymuszanie zmiany hasła po jego upływie okresu ważności, - wymuszenie, aby hasło istotnie różniło się od określonej liczby poprzednich haseł. Strona 17 z 21

18 WT35 WT36 W przypadku uwierzytelniania za pomocą hasła i zastosowania silnego hasła dostarczone rozwiązanie powinno spełniać wytyczne dotyczące bezpieczeństwa określone w Rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 roku, co najmniej na poziomie podwyższonym (hasło 8 znakowe, zawierające małe i wielkie litery oraz cyfry lub znaki specjalne, wymuszenie zmiany nie rzadziej niż co 30 dni). Użytkownik systemu powinien być uwierzytelniany przy użyciu mechanizmów Active Directory. WT37 W systemie powinna być możliwość zdefiniowana dowolnej liczby kont użytkowników. WT38 W systemie powinna być możliwość definiowania grup użytkowników. WT39 WT40 WT41 WT42 WT43 W systemie powinna być możliwość przypisania użytkownika do więcej niż jednej grupy. W systemie powinna być możliwość definiowania uprawnień do poszczególnych funkcji i elementów systemu dla grupy użytkowników. W przypadku przypisania użytkownika do więcej niż jednej grupy, jego uprawnienia są sumą logiczną uprawnień wynikających ze wszystkich grup, do których użytkownik należy. Uprawnienia użytkownika systemu można wyrazić poprzez zabranie lub nadanie dostępu do poszczególnych funkcji i elementów systemu. Dostęp do danych w bazie danych musi być możliwy przy użyciu co najmniej sterowników ODBC i JDBC. Bezpieczeństwo danych WT45 Oferowane rozwiązanie musi posiadać możliwość rejestracji wszystkich prób uwierzytelniania. Dotyczy to zarówno prób udanych, jak i nieudanych. Minimalny zestaw rejestrowanych danych powinien zawierać: - datę i czas zdarzenia - nazwę użytkownika - rodzaj zdarzenia - nazwa i adres IP terminala (hosta). WT46 Oferowane rozwiązanie musi mieć możliwość wykonywania kopii zapasowej systemu bez konieczności użycia dedykowanego oprogramowania, poprzez wykonanie kopii struktury katalogów i plików. WT47 Oferowane rozwiązanie musi mieć możliwość odtworzenia całości lub części danych z kopii zapasowej. W przypadku częściowego odtworzenia, zapewnienie mechanizmów sprawdzających integralność całości danych po odtworzeniu. Strona 18 z 21

19 WT48 Oferowane rozwiązanie musi zapewnić rejestrowanie wszystkich błędów systemu w logach. Minimalny zestaw rejestrowanych danych powinien zawierać: - datę i czas zdarzenia - identyfikator błędu - opis błędu - kontekst wystąpienia błędu. WT49 WT50 WT51 WT52 Oferowane rozwiązanie musi zapewnić możliwość rejestrowania modyfikacji danych w systemie. Minimalny zestaw rejestrowanych danych powinien zawierać: - datę i czas zdarzenia, - nazwę użytkownika, - rodzaj zmiany (dodanie, modyfikacja, usunięcie), - parametry zmiany (jakie dane zostały zmienione). Oferowane rozwiązanie musi umożliwiać składnie bezpiecznego podpisu elektronicznego, przy użyciu certyfikatu elektronicznego, także kwalifikowanego. Oferowane rozwiązanie musi umożliwiać szyfrowanie połączenia pomiędzy serwerem a klientem za pomocą protokołu SSL. W oferowanym rozwiązaniu w przypadku pracy zdalnej, komunikacja pomiędzy serwerem a klientem musi odbywać się za pomocą protokołu TCP/IP. Ponadto liczba i numery wykorzystywanych portów muszą być dokładnie określone i konfigurowalne (np. na firewall-u). WT53 Wszystkie dane w systemie muszą być przechowywane w relacyjnej bazie danych. System bazodanowy powinien zapewnić mechanizmy zachowania integralności danych zarówno fizycznych (pliki danych na nośniku), jak i logicznych (utrzymanie relacji, kryteria poprawności danych). WT54 System bazodanowy musi zapewniać mechanizmy obsługi jednoczesnego dostępu wielu klientów, w tym mechanizmy transakcyjne zgodne z kryteriami ACID oraz blokowanie danych na poziomie tabel i/lub rekordów. WT55 Oferowane rozwiązanie musi zawierać mechanizmy obsługi wielodostępności i wielostanowiskowości. W szczególności dotyczy to kontroli współużytkowania danych i dokumentów, obsługę konfliktów, korzystania z tych samych danych przez więcej niż jednego użytkownika. WT56 Oprogramowanie bazy danych powinno zapewnić metody i/lub narzędzia pozwalające administratorowi na tuning bazy danych. W szczególności poprawnie skonfigurowana baza danych powinna być bezobsługowa. Strona 19 z 21

20 Wymagania dotyczące interfejsu i ergonomii WT57 Oferowany system musi posiadać okienkowy interfejs graficzny, przy czym wygląd interfejsu na platformie Windows i Linux powinien być identyczny funkcjonalnie z uwzględnieniem różnic w obsłudze każdego z tych systemów operacyjnych. WT58 WT59 WT60 Wszystkie elementy tekstowe interfejsu użytkownika oferowanego systemu muszą być w języku polskim. W szczególności dotyczy to także wszystkich komunikatów widocznych dla użytkownika. Wszystkie komunikaty o błędach widoczne dla użytkownika powinny być wyświetlane w języku polskim, a także być przejrzyste i zwięzłe. Oferowany system w zakresie swojej funkcjonalności powinien zawierać kontekstowy system pomocy w języku polskim. System pomocy powinien mieć możliwość wyszukiwania kontekstowego oraz według haseł (indeksu). WT61 Oferowany system powinien umożliwiać wprowadzanie, przechowywanie i pracę na danych w różnych językach. Wymaganie dotyczy także raportowania. Minimalny zestaw obsługiwanych języków powinien zawierać wszystkie języki oparte na alfabecie łacińskim z dodatkowymi znakami specyficznymi dla tych języków, alfabecie greckim i cyrylicy. WT62 Oferowany system powinien umożliwiać tworzenie skrótów do najczęściej używanych funkcji programu. Dodatkowo zbiory takich skrótów powinny być zapamiętywane indywidualnie dla każdego użytkownika. WT63 Oferowane rozwiązanie powinno zapewniać powiązanie logiczne danych pomiędzy poszczególnymi modułami systemu. Przez powiązanie logiczne rozumie się także wykorzystywanie wspólnych danych (np. słowniki). WT64 Oferowany system powinien sygnalizować przypadki wykonywania operacji długotrwałych. Minimalny sposób sygnalizacji to zmiana wskaźnika na zajętość. W przypadku operacji, których stan zaawansowania jest określony, dopuszcza się sygnalizację za pomocą wskaźnika (paska) postępu. WT65 Oferowane rozwiązanie powinno wykonywać wszystkie swoje funkcje samodzielnie. W przypadku konieczności zakupu dodatkowego oprogramowania, jego cena powinna być uwzględniona w cenie oferty. Warunek ten nie dotyczy posiadanego już oprogramowania przez Zamawiającego (np. pakiet Microsoft Office). WT66 Zamawiający dopuszcza utrzymywanie testowego zestawu danych (lub testowej kopii całego rozwiązania) np. w celach sprawdzenia skutków wykonania określonej funkcji (np. przy wprowadzeniu/modyfikacji funkcjonalności systemu, wykonaniu nieodwracalnej operacji na danych itp.). Strona 20 z 21