Minimalne wymagania NSI 2014

Transkrypt

1 Załącznik nr 3 Zapytanie ofertowe nr CUPT/DO/OZ/DE/25/3/IM/14/SW Minimalne wymagania NSI 2014 Warszawa, dnia r.

2 Klucz interpretacji wymagań: Wymagania techniczne i funkcyjne opisane w formie System musi spełniać dane wymaganie należy traktować jako wymaganie krytyczne w stosunku do funkcjonalności lub technologii. Wymagania techniczne i funkcyjne opisane w formie System może spełniać dane wymaganie należy traktować jako oczekiwanie Zamawiającego niebędące wymaganiem krytycznym. Wykaz stosowanych skrótów: CUPT/Zamawiający/Jednostka/Instytucja Wdrażająca Centrum Unijnych Projektów Transportowych NSI/System - System Finansowo-Księgowy, Kadrowo-Płacowy oraz Środków Trwałych CUPT DE Departament Ekonomiczno-Finansowy DO Departament Organizacji i Zarządzania Zasobami KSI Krajowy System Informatyczny SIMIK POIiŚ Program Operacyjny Infrastruktura i Środowisko NBP Narodowy Bank Polski BGK Bank Gospodarstwa Krajowego UOFP Ustawa z 27 sierpnia 2009 r. o finansach publicznych (Dz. U. z 2013 r., poz. 885 z późn. zm.) KP Ustawa z dnia 26 czerwca 1974 r. - eks Pracy (Dz. U. z 1998 r. Nr 21, poz. 94 z późn. zm.) Pzp Ustawa z 29 stycznia 2004 r. - Prawo zamówień publicznych (Dz. U. z 2013 r., poz. 907 z późn. zm.) Strona 2 z 43

3 SPIS TREŚCI: I. ZAKRES PRZEDMIOTU ZAMÓWIENIA... 4 II. WYMAGANIA OGÓLNE... 5 III. OGÓLNE WYMAGANIA TECHNICZNE NSI... 6 IV. OPIS FUNKCJONALNOŚCI NSI WYMAGANIA OGÓLNE PLAN FINANSOWY PROCES KONTROLI FINANSOWEJ PROCES EWIDENCJI KSIĘGOWEJ PROCES REALIZACJI PŁATNOŚCI PROCES OBSŁUGI KASOWEJ REJESTRY a. Rejestr Kontrahentów b. Rejestr Wniosków o Zaciągnięcie Zobowiązania c. Rejestr Umów/Aneksów/Zamówień d. Rejestr Dokumentów Źródłowych e. Rejestr Lista Płac f. Rejestr składników majątku g. Rejestr Delegacji V. SPRAWOZDAWCZOŚĆ NSI SPRAWOZDANIA RAPORTY Strona 3 z 43

4 I. Zakres Przedmiotu Zamówienia 1) zakup NSI, dostosowanie i zaprojektowanie funkcjonalności (w tym po przeprowadzeniu analizy przedwdrożeniowej) w ramach następujących obszarów: a) finansowo-księgowego (w tym, w szczególności: ewidencji księgowej z uwzględnieniem specyfiki jednostki budżetowej oraz instytucji wdrażającej, kontroli finansowej, sprawozdawczości, obsługi wniosków o płatność w ramach pomocy technicznej), b) kadrowo-płacowego, c) ewidencji składników majątku, d) tworzenia zaawansowanych raportów oraz konfigurację i instalację NSI, 2) dostawę, do siedziby Zamawiającego wraz z załadunkiem, rozładunkiem, ustawieniem, instalacją oraz konfiguracją sprzętu oraz oprogramowania (sprzęt dostarczony w ramach zamówienia przechodzi na własność Zamawiającego; licencja na oprogramowanie przechodzi na własność Zamawiającego; sprzęt musi być fabrycznie nowy; sprzęt oraz oprogramowanie musi podlegać min. 36 miesięcznej gwarancji), 3) przeprowadzenie szkoleń użytkowników NSI oraz administratorów NSI (łącznie ok. 100 osób na dwóch etapach wdrożenia, tj. w trakcie i po wdrożeniu NSI), 4) udzielenie gwarancji jakości na wdrożony NSI, 5) dostarczenie dokumentu gwarancyjnego dla całego wdrożonego NSI, 6) świadczenie serwisu gwarancyjnego przez okres co najmniej 36 miesięcy od zakończenia wdrożenia NSI, 7) przygotowanie i dostarczenie dokumentacji technicznej, 8) przygotowanie i dostarczenie dokumentacji analizy przedwdrożeniowej, 9) przygotowanie i dostarczenie instrukcji użytkownika NSI w języku polskim, 10) przygotowanie i dostarczenie instrukcji administratora NSI w języku polskim, 11) udostępniania poprawek i aktualizacji NSI zawierających nowości funkcjonalne oraz merytoryczne w ramach rozwoju rynkowego oprogramowania oraz dostarczenie co najmniej jednej aktualizacji oprogramowania rocznie przez okres 36 miesięcy od wdrożenia Systemu; w przypadku zmiany przepisów powszechnie obowiązujących Wykonawca dostarczy odpowiednią modyfikację Systemu najpóźniej w dniu wejścia przepisów w życie, a jeżeli przepisy weszły w życie z dniem ogłoszenia nie później niż 7 dni od tego dnia. Ponadto, Przedmiot Zamówienia obejmuje: 1) udzielenie bezterminowej, niewyłącznej, przechodniej licencji na korzystanie z NSI, 2) przeniesienie prawa własności Nośnika/Nośników NSI, na którym został utrwalony NSI, 3) migrację danych. Strona 4 z 43

5 II. Wymagania ogólne 1) System musi zapewnić pełną zgodność z aktualnie obowiązującymi przepisami w zakresie wdrażanych obszarów, w tym szczególności ustawą o rachunkowości, ustawą o finansach publicznych, prawem pracy, ustawą o podatku dochodowym od osób fizycznych, ustawą o podatku dochodowym od osób prawnych, przepisami wykonawczymi, przepisami szczególnymi dla państwowych jednostek budżetowych oraz wytycznymi dla jednostek realizujących programy unijne. 2) System musi posiadać standardowe funkcjonalności systemu finansowo-księgowego, typowe dla jednostki budżetowej wdrażającej projekty unijne. 3) Ewidencja w systemie wszystkich operacji gospodarczych musi odbywać się przy użyciu klasyfikatorów, w tym w szczególności: klasyfikatora budżetu tradycyjnego, klasyfikatora unijnego (w tym strukturalnego), klasyfikatora budżetu zadaniowego oraz znaczników, cech, wyróżników, masek itp. Dla wybranych klasyfikatorów musi istnieć możliwość określenia dat ich obowiązywania. 4) System musi spełniać wymagania w zakresie ochrony danych osobowych. 5) System musi zapewnić automatyzację nadawania numerów oraz elastyczne tworzenie maski numerów. 6) System musi zapewnić jednokrotność wprowadzania danych oraz dokumentów. 7) System musi zapewnić sporządzanie różnego rodzaju wydruków/prezentacji na ekran/importu/exportu zestawień/raportów z możliwością definiowania przez użytkownika kryteriów wyborów wydruku, z uwzględnieniem wyboru opcji dokumentów z jawną prezentacją na wydruku zastosowanej opcji. 8) System musi zapewnić prowadzenie różnego typu rejestrów z uwzględnieniem specyfiki rejestrowanych dokumentów, w szczególności: wniosków, umów (w tym umów o dofinansowanie), dokumentów źródłowych (w szczególności faktur, wniosków o płatność). 9) System co do zasady musi zapewnić wszystkim rejestrom i wszystkim typom dokumentów (w ramach poszczególnych rejestrów) wszystkie obszary kontroli finansowej. 10) System musi zapewnić obsługę nielimitowany wolumen danych. 11) System musi umożliwiać sortowanie, filtrowanie i wyszukiwanie według wszystkich wprowadzonych danych, w tym według dowolnego ciągu znaków. 12) System musi posiadać widoczną dla użytkownika funkcjonalność śladowania zmian dla danych wskazanych przez Zamawiającego na etapie analizy przedwdrożeniowej. 13) System musi dokonywać walidacji danych wskazanych przez Zamawiającego. 14) Dokumenty generowane przez system muszą posiadać metrykę (m. in. data utworzenia, data zatwierdzenia, dane osoby sporządzającej, zatwierdzającej). System musi wspierać obieg dokumentów poprzez m.in. informacje o statusie, dacie utworzenia, dacie zatwierdzenia, danych osób: sporządzającej, weryfikującej, akceptującej, zatwierdzającej. 15) System musi posiadać funkcjonalność archiwizowania dokumentów wskazanych przez Zamawiającego. Strona 5 z 43

6 III. Ogólne wymagania techniczne NSI 1. Wymagania Techniczne Opis funkcjonalności 1 2 Architektura Relacyjna baza danych musi udostępnia tzw. widoki, za pomocą których WT-01 Zamawiający będzie mógł we własnym zakresie eksplorować zgromadzone w Systemie dane. System musi działać na stanowiskach użytkowników w środowisku graficznym MS WT-02 Windows Vista i nowszym (np. MS Windows 7, MS Windows 8) System musi być zaprojektowany z zastosowaniem informatycznego modelu wielowarstwowego, z warstwami min.: WT warstwa bazy danych 2. warstwa prezentacyjna (interfejs użytkownika) System musi wykorzystywać relacyjną bazę danych. Zamawiający dopuszcza następujące rozwiązania: Microsoft SQL Server, Oracle, Sybase. WT-04 WT-05 WT-06 WT-07 WT-08 WT-09 WT-10 WT-11 WT-12 WT-13 WT-14 WT-15 WT-16 W ramach zamówienia, Wykonawca musi dostarczyć licencje na silnik relacyjnej bazy danych wykorzystywanej przez zamawiany System. Zamawiający nie dopuszcza rozwiązania darmowego, ograniczonego funkcjonalnie. Komunikacja pomiędzy serwerem/serwerami Systemu a stacjami klienckimi musi się odbywać za pomocą protokołu TCP/IP System musi zapewniać mechanizm wykonywania kopii bezpieczeństwa zgodny z wymaganiami bezpieczeństwa określonymi w normie ISO System musi umożliwiać wykonanie kopii bezpieczeństwa w czasie pracy Systemu. W czasie wykonywania kopii bezpieczeństwa nie może być przerwy w działaniu Systemu lub spowolnienia uniemożliwiającego normalną pracę. System musi umożliwiać wspólny System haseł zabezpieczających przed dostępem osób niepowołanych z uwzględnieniem przyznawania praw do różnych funkcji poszczególnym użytkownikom System musi zapewnić zabezpieczenie przed nieautoryzowanym dostępem zarówno na poziomie klienta (aplikacja) jak i serwera (serwer baz danych) zgodne z wymaganiami bezpieczeństwa określonymi w normie ISO Zamawiający dopuszcza możliwość wykorzystania zdalnego dostępu do serwera na etapie wdrożenia Systemu, podczas świadczenia usług gwarancyjnych jak i podczas późniejszego utrzymania Systemu Przedmiotem zamówienia jest dostarczenie licencji na wymagane oprogramowanie w celu zapewnienia optymalnego funkcjonowania zamawianego Systemu. System musi umożliwiać obsługę czytników kodów kreskowych. System musi umożliwiać obsługę lokalnych drukarek atramentowych, laserowych, igłowych oraz drukarek etykiet oraz drukarek sieciowych atramentowych i laserowych. System musi umożliwiać obsługę wydruków w formatach do A3 na kartkach pojedynczych z możliwością zapisu wydruku do pliku oraz podglądu na ekranie System i jego moduły muszą być ściśle dostosowane do polskiego ustawodawstwa i charakteru działalności Zamawiającego jako instytucji publicznej. Poszczególne moduły Systemu muszą wykorzystywać wspólną Bazę Danych. System musi być zaprojektowany w architekturze klient-serwer, umożliwiającej centralne zarządzanie oprogramowaniem i aktualizacjami tj. aktualizacja Strona 6 z 43

7 Opis funkcjonalności 1 2 Systemu musi być automatycznie uwzględniana przy zalogowaniu do Systemu przez użytkownika bez konieczności jej przeprowadzania na stacji roboczej. Funkcjonalność Systemu System musi umożliwiać administratorowi monitorowanie wszystkich zdarzeń związanych z eksploatacją Systemu (wprowadzanie danych, ich modyfikacja itp.) wraz z przechowywaniem informacji o użytkowniku obsługującym zdarzenie). WT-17 Wykonawca musi określić optymalne wymagania sprzętowe (serwery, macierze dyskowe i inne) dedykowane dla Systemu z uwzględnieniem rozwoju Systemu i przyrostu bazy danych przez okres gwarancji określony w kodzie WT-52 w celu zagwarantowania bezkonfliktowej współpracy Systemu ze sprzętem Zamawiającego. System musi umożliwiać przetwarzanie danych w czasie rzeczywistym (Real Time WT-18 Processing) z kontrolą dostępu do pojedynczego rekordu przez więcej niż jeden proces (proces lub użytkownik) WT-19 Praca w czasie rzeczywistym - każde działanie podjęte w programie musi mieć swoje odzwierciedlenie w całym Systemie System musi być polskojęzyczny, cała komunikacja w Systemie musi następować w języku polskim oraz musi posiadać dokumentację w języku polskim (w postaci WT-20 wydruku oraz na nośniku CD) pozwalająca na samodzielną naukę obsługi Systemu. Wszystkie nowe wersje Systemu również muszą być dostarczone w wersji polskojęzycznej. WT-21 Wykonawca musi przekazać Zamawiającemu pełny opis, sporządzony w języku polskim, struktury bazy danych wraz z jej charakterystyką System musi posiadać mechanizmy ograniczające ryzyko wprowadzenia nieprawidłowych danych, na przykład: walidacja wartości poszczególnych pól formularzy wejściowych z danymi WT-22 słownikowymi wprowadzanie wartości pól formularzy z istniejących w Systemie słowników, kontrola krzyżowa zależności występowania pól np. jeśli wybierze się pole firma to pojawia się miejsce na NIP lub pole NIP staje się aktywne Interfejs użytkownika Systemu musi spełniać następujące wymagania: interfejs powinien być intuicyjny i ergonomiczny (uporządkowanie pól zgodne z kolejnością i częstością wypełniania, optymalna liczba okien wymaganych do zrealizowania funkcji) komendy i komunikaty dla użytkownika muszą być w języku polskim, obsługiwany przy pomocy myszy i klawiatury jednolity wygląd ekranów (uporządkowanie pól, umieszczenie przycisków, WT-23 opisy pól w ustalonej konwencji) jednolite działanie typowych funkcji (wyszukiwanie, sortowanie, przeglądanie, drukowanie itp.) dostępnych z różnych ekranów w przypadku istotnych operacji na danych (np. usuwanie danych) musi być możliwość potwierdzania zamiaru wykonania operacji mechanizmy podpowiedzi do pól komunikaty o błędach lub nieprawidłowościach działania Systemu muszą być wyświetlane w języku polskim sformułowane w sposób zrozumiały dla użytkownika System musi odpowiadać warunkom technicznym oraz pozwalać na adaptację WT-24 warunków organizacyjnych (przy jego eksploatacji), jakie powinny spełniać Systemy informatyczne przetwarzające dane osobowe zgodnie z Ustawą o Ochronie Danych Osobowych z dnia 29 sierpnia 1997 r. (Dz.U. z 2002 r., Nr 101, poz. 926, z późn. zm.) i Strona 7 z 43

8 Opis funkcjonalności 1 2 z rozporządzeniami wykonawczymi do niej oraz zgodnie z rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych. System musi umożliwiać bezpieczeństwo w następujących obszarach: 1. System uprawnień odpowiadający zdefiniowanej strukturze organizacyjnej CUPT z określeniem ról użytkowników w Systemie 2. Zabezpieczenie przed dostępem do przeglądania i edycji danych poprzez konieczność podania nazwy użytkownika i hasła. 3. Zarządzanie użytkownikami oraz grupami użytkowników WT Przypisywanie uprawnień do użytkowników i grup 5. Raport logowań użytkowników 6. Automatycznie zamykanie sesji po upływie czasu określonego w konfiguracji Systemu, od przerwania pracy z Systemem, a nie wylogowaniu się. 7. Historia aktywności użytkownika w Systemie 8. Definiowanie wymagań odnośnie hasła (minimalna długość, zawartość znaków, historia haseł) WT-26 System musi udostępniać pomoc dla Użytkowników na wszystkich ekranach. WT-27 Poszczególne obszary Systemu muszą mieć własne menu System musi umożliwiać edytowanie list słownikowych (np. słownik podgrup WT-28 wniosków, nazwy wnioskodawców, nazwisk pracowników poszczególnych wydziałów CUPT). WT-29 System po wprowadzeniu wyróżnika (np. NIP lub nazwa wnioskodawcy) musi uzupełniać dane w powiązanych polach (np. dane teleadresowe wnioskodawcy). WT-30 System musi umożliwiać pobieranie informacji o użytkownikach z usług katalogowych (LDAP) w zakresie autentykacji i autoryzacji w Systemie. System musi umożliwić współpracę obszarów Systemu z aplikacjami typu MS Word, WT-31 MS Excel w zakresie importu/eksportu danych (obsługiwane formaty minimum dla importu i eksportu danych: csv, xml). WT-32 System musi umożliwić pełną integrację z Systemem ZUS Płatnik. WT-33 System musi umożliwić integrację Systemu z bankowymi Systemami płatności, w szczególności Videotel. WT-34 System musi wymagać wpisywania wartości zgodnie z ustalonymi formatami (np. daty, kwoty, tekst). System musi umożliwiać dokonywanie korekt wprowadzonych danych i WT-35 załączników, zachowując historię zmian. Wprowadzanie zmian musi być możliwe dla użytkowników ze specjalnymi uprawnieniami System musi umożliwiać automatyczną rejestrację i śledzenie historii zmian WT-36 określonych załączników. System musi zapewnić, że załącznik nie będzie mógł zostać usunięty lub zmodyfikowany bez pozostawienia wyraźnego śladu System musi umożliwić generowanie dokumentów na podstawie szablonów zdefiniowanych przez użytkownika, w których część danych będzie automatycznie WT-37 wypełniana z bazy danych. System musi umożliwiać ręczną korektę danych na generowanych dokumentach. Wzory szablonów zostaną uzgodnione z Zamawiającym. Szablony pism muszą być zdefiniowane w ten sposób by: 1. zawierać część pól wypełnianych automatycznie przez System WT zawierać możliwość wprowadzania fragmentów tekstu przez operatora a dotyczących zagadnień merytorycznych Strona 8 z 43

9 Opis funkcjonalności 1 2 System musi umożliwiać zmianę fragmentów związanych z Corporate Identity (np. WT-39 nagłówki, stopki, logo) System musi posiadać wbudowany generator raportów: Zawierający dostęp do wszelkich danych wprowadzonych w Systemie WT-40 Pozwalający na filtrowanie danych wg dowolnych warunków Pozwalający na stosowanie szablonów raportów System musi umożliwiać zapis wyników raportów do plików w formatach CSV, XLS, WT-41 DOC, XML, TXT i PDF System musi umożliwiać eksportowanie wybranych danych celem tworzenia WT-42 zaawansowanych zestawień (format eksportu CSV, XLS, DOC, XML, TXT i PDF). Użytkownicy System musi umożliwiać jednoznaczną identyfikację użytkowników wykonujących WT-43 czynności w Systemie System musi umożliwiać odtworzenie historii aktywności użytkownika w Systemie w WT-44 dowolnym okresie Administrator musi mieć możliwość nadawania uprawnień dostępu do konkretnych danych w zakresie m.in. podglądu, edycji, dodawania, usuwania oraz uniemożliwiać WT-45 dokonywania zmian przez nieuwierzytelnione właściwie osoby. Podział będzie wynikać ze struktury organizacyjnej oraz roli, jaką użytkownik pełnić będzie w poszczególnych etapach realizacji procesu. WT-46 System musi umożliwiać podgląd na liście zalogowanych użytkowników w Systemie System musi automatycznie rejestrować oraz utrzymywać historię dat i czasów WT-47 kolejnych działań dotyczących spraw i identyfikatorów pracowników dokonujących zmian System musi umożliwić podział użytkowników na grupy i przypisywanie praw WT-48 dostępu do określonych grup. Jeden użytkownik może być członkiem wielu grup WT-49 System musi umożliwiać tworzenie ról, czyli grup uprawnień. Administrator musi mieć możliwość definiowania ról i grupowania uprawnień w WT-50 ramach tych ról Wykonawca musi zagwarantować bezproblemową, jednoczesną pracę wymaganej liczby użytkowników, bez spowolnienia działania Systemu. Obecna liczba WT-51 użytkowników Systemu wynosi 50 osób, planowany roczny przyrost to 15%. Liczba administratorów obsługujących System to aktualnie 2 osoby. Inne System musi zostać objęty gwarancją, bez odrębnego wynagrodzenia, przez okres co WT-52 najmniej 36 miesięcy po zakończeniu wdrożenia. W ramach gwarancji Wykonawca musi stosować podane poniżej czasy reakcji i usunięcia awarii, liczonych z pominięciem niedziel i dni ustawowo wolnych od pracy. Czas reakcji na zgłoszenie awarii: 1. błąd krytyczny: a. czas reakcji 1 godzina od zgłoszenia b. czas usunięcia w ciągu 24 godzin od momentu zgłoszenia awarii 2. błędy ważne: WT-53 a. czas reakcji 24 godziny od zgłoszenia b. czas usunięcia w ciągu 72 godzin od momentu zgłoszenia awarii 3. błędy istotne: a. czas reakcji 72 godziny od zgłoszenia b. czas usunięcia w ciągu 7 dni od momentu zgłoszenia awarii 4. inne problemy: a. czas reakcji 7 dni od zgłoszenia b. czas usunięcia 14 dni od momentu zgłoszenia awarii Strona 9 z 43

10 Opis funkcjonalności 1 2 Definicje błędów: 1. Błąd krytyczny (występuje co najmniej jeden z poniższych warunków) a. Powoduje zatrzymanie pracy Systemu na czas powyżej 1 godziny b. Kluczowe funkcje Systemu (przynajmniej jedna) nie działają przez okres ponad 1 godziny i nie ma sposobu obejścia problemu c. Nie ma żadnej możliwości realizacji procesu biznesowego 2. Błąd ważny (występuje co najmniej jeden z poniższych warunków) a. System może pracować, lecz kluczowa funkcjonalność jest niedostępna przez okres powyżej 1 godziny, istnieje jednak możliwość obejścia problemu b. Niektóre funkcjonalności pomocnicze nie są dostępne przez ponad 2 godziny i nie ma sposobu obejścia problemu c. Nie ma możliwości pełnej realizacji procesu biznesowego 3. Błąd istotny (występuje co najmniej jeden z poniższych warunków) a. System może pracować, lecz kluczowa funkcjonalność jest niedostępna przez okres powyżej 2 godzin, istnieje jednak możliwość obejścia problemu b. Niektóre funkcjonalności pomocnicze nie są dostępne przez ponad 2 godziny, ale można zastosować dla nich obejście c. Możliwa jest realizacja większości procesu biznesowego 4. Inne problemy Utrudnienie w pracy i/lub obsłudze Systemu nie powodujące generowania i zapisywania błędnych i/lub niepoprawnie przetworzonych danych w Systemie i nie powodujące nieprawidłowej obsługi procesów biznesowych Oceny kategorii błędu dokonuje Zamawiający. Wykonawca musi dostarczyć licencję Systemu pozwalającą na jednoczesną pracę WT-54 min. 50 użytkowników, na dowolnej liczbie stanowisk. Wykonawca musi dokonać migracji danych z programu RaksSQL (baza danych w formacie Firebird 1.5) użytkowanego przez Zamawiającego oraz wybranych WT-55 arkuszy kalkulacyjnych w formacie MS Excel. Szczegółowy zakres danych przeznaczonych do migracji zostanie ustalony na etapie analizy przedwdrożeniowej Gwarancja dla Systemu, realizowana przez Wykonawcę na rzecz Zamawiającego przez okres co najmniej 36 miesięcy od zakończenia wdrożenia, musi zawierać: a. Wizyty serwisantów w siedzibie Zamawiającego, w przypadku naprawy wad/usterek Systemu. b. Zdalny dostęp do zarządzania i naprawy wad/usterek Systemu. c. Hotline - zgłaszanie awarii/wad/usterek dotyczących Systemu telefonicznie i/lub za pomocą poczty elektronicznej. Dostępność serwisu i Hotline w godzinach roboczych tj. od poniedziałku do piątku od 8.00 do WT-56 d. Wsparcie telefoniczne i/lub pocztą elektroniczną umożliwiające jak najsprawniejsze usunięcie awarii Systemu. Okresową kontrolę stanu Systemu raz na kwartał. Zamawiający dopuszcza możliwość kontroli stanu Systemu poprzez zdalny dostęp do Systemu. Okresowa kontrola stanu Systemu musi się odbywać przez konsultanta Wykonawcy, poprzez uruchomienie dedykowanych funkcji kontrolnych zawartych w oferowanym Systemie i w narzędziach bazy danych. Nie dopuszcza się uruchamiania mechanizmów obciążających pracę serwera bazy danych, które mogą spowodować spowolnienie pracy Systemu. Każda nowa wersja Systemu musi być dostarczona na płycie CD/DVD, wysłana za WT-57 pomocą maila lub udostępniona na serwerze ftp Wykonawcy. WT-58 Wykonawca musi dostarczyć Zamawiającemu kolektor danych współpracujący z Strona 10 z 43

11 Opis funkcjonalności 1 2 Systemem, o minimalnych parametrach: Pamięć RAM: min KB; Klawiatura: min. 26 klawisze alfanumeryczne; Wyświetlacz: LCD, min. 96 x 49 punktów graficznych; System optyczny: laserowy; Wzór skanowania: pojedyncza linia skanująca; Kąt odczytu: 53 O ; Komunikacja: USB, RS-232; Typy kodów kreskowych: UPC-A/E, EAN-8/13, ISBN/ISSN, 128, I 2 z 5, 93, Codabar, 39, 39 pełny ASCII; Wykonawca musi dostarczyć Zamawiającemu drukarkę etykiet współpracującą z Systemem, o minimalnych parametrach: Metoda wydruku: termiczna, termotransferowa; Rozdzielczość drukowania: 203 dpi; Maksymalna szerokość druku: 110 mm; Maksymalna długość druku: 1628 mm; WT-59 Maksymalna prędkość druku: 150mm/s; Maksymalny wymiar taśmy drukującej: średnica wewnętrzna 25 mm, długość 300 m; Komunikacja: USB, RS-232; Drukowane kody kreskowe: 1D: wszystkie standardowe kody jednowymiarowe, 2D: wszystkie standardowe kody dwuwymiarowe; Języki programowania: Datamax, ZPLII; 2. Wymagania Opieki Eksploatacyjnej (WOE) WOE-01 WOE-02 WOE-03 WOE-04 Wykonawca musi bez odrębnego wynagrodzenia udostępniać poprawki i aktualizacje Systemu, zawierające nowości funkcjonalne oraz merytoryczne w ramach rozwoju rynkowego oprogramowania. Wymagane jest dostarczenie co najmniej jednej aktualizacji oprogramowania rocznie przez okres użytkowania Systemu przez Zamawiającego. W przypadku zmiany przepisów powszechnie obowiązujących Wykonawca dostarczy odpowiednią modyfikację sytemu najpóźniej w dniu wejścia przepisów w życie, a jeżeli przepisy weszły w życie z dniem ogłoszenia nie później niż 7 dni od tego dnia. Zamawiający musi mieć możliwość zgłaszania problemów na specjalnym, określonym w warunkach świadczenia opieki eksploatacyjnej, formularzu, za pośrednictwem poczty elektronicznej, faxu lub wypełniając formularz umieszczony na stronie internetowej systemu rozwiązywania problemów. Wykonawca musi zapewnić bez odrębnego wynagrodzenia wsparcie telefoniczne i e- mailowe od poniedziałku do piątku w godzinach 8:00-16:00, a także co najmniej 360 godzin konsultacji eksploatacyjnych w siedzibie Zamawiającego (czas liczony bez dojazdu Wykonawcy do siedziby Zamawiającego) przez okres gwarancji, czyli co najmniej 36 miesięcy od zakończenia wdrożenia. Wykonawca musi zapewnić bezpłatne szkolenia administratorów Systemu z konfiguracji i eksploatacji Systemu (maksymalnie 2 osoby rocznie) w trakcie trwania gwarancji. Zamawiający nie dopuszcza możliwości szkolenia administratorów Systemu z konfiguracji i eksploatacji Systemu na zasadzie przekazywania Zamawiającemu aktualizacji instrukcji do Systemu wraz z możliwością konsultacji merytorycznych w tym zakresie Strona 11 z 43

12 WOE-05 Wykonawca musi zapewnić, bez odrębnego wynagrodzenia, funkcjonalność bazy testowej jeśli w niniejszym dokumencie jest mowa o bazie danych Systemu zapisy te dotyczą co najmniej dwóch baz: bazy produkcyjnej i testowej w rozumieniu środowiska testowego tj.: bazy do zarządzania zmianą w systemie (akceptacje poprawek, aktualizacji, zmian parametrów merytorycznych i wartości słownikowych), monitorowania i strojenia parametrów wydajnościowych, testowania funkcjonalności krytycznych, a także do celów szkoleniowych. Silnik relacyjnej bazy danych musi umożliwić automatyczną replikację danych z bazy produkcyjnej do bazy testowej codziennie w dni robocze oraz ręczną replikację w przypadku doraźnej potrzeby. Strona 12 z 43

13 IV. Opis funkcjonalności NSI wymagania ogólne 1. Plan finansowy FPP-01 FPP-02 FPP-03 FPP-04 FPP-05 FPP-06 FPP-07 FPP-08 Rejestr wniosków i decyzji w sprawie zmiany planu finansowego CUPT System musi umożliwiać prowadzenie rejestru wniosków i decyzji w sprawie zmiany planu finansowego z uwzględnieniem m.in. typów, cech, progów wartościowych oraz korekt tych dokumentów. System musi posiadać funkcjonalność sprawdzenia zgodności kwot czy proponowane przez użytkownika zmniejszenie planu finansowego jest dopuszczalne z punktu widzenia środków zaangażowanych na danym klasyfikatorze. System musi posiadać funkcjonalność automatycznego blokowania środków objętych wnioskiem w sprawie zmiany planu finansowego (dotyczy kwoty zmniejszeń). System musi posiadać System zatwierdzania poprawności wniosku w sprawie zmiany planu w zakresie kompetencji dwóch Departamentów dokonujących kontroli finansowej. System musi pozwolić na edycję danych projektu decyzji. System musi posiadać System zatwierdzania poprawności decyzji w sprawie zmiany planu w zakresie kompetencji dwóch Departamentów dokonujących kontroli finansowej. System musi automatycznie w oparciu o zatwierdzoną decyzję wygenerować propozycję dekretacji dokumentu. System (w momencie zaksięgowania - trwałego zapisu w księgach rachunkowych) musi automatycznie zwolnić blokadę kwot objętych w ramach wniosku zmniejszeniem planu oraz uwzględniać w ramach kontroli finansowej kwoty zwiększające plan. 2. Proces Kontroli Finansowej FPKF-01 FPKF-02 FPKF-03 FPKF-04 FPKF-05 Proces kontroli co do zasady musi być dokonywany na trzech etapach, tj.: 1. na etapie wniosku o zaciągnięcie zobowiązania (w ciężar planu), 2. na etapie projektu umowy (w ciężar wniosku o zaciągnięcie zobowiązania z ponowną weryfikacją planu lub w ciężar planu), 3. na etapie dokumentu źródłowego (w ciężar umowy lub/i w ciężar planu). Kontrola finansowa w szczególności musi polegać na wspomaganiu przez System obszarów: 1. kontroli merytorycznej (wspomagana przez System), 2. kontroli zgodności kwot opisanych Systemem klasyfikatorów na dokumentach wprowadzonych do Systemu z planem finansowym CUPT/z wnioskiem o zaciągnięcie zobowiązania/z umową (wykonywana przez System), 3. kontroli formalno-rachunkowej (wspomagana przez System). Każdemu etapowi kontroli finansowej mogą odpowiadać różne obszary kontroli finansowej. Kontrola wykonywana przez System oznacza, że System dokonuje automatycznej kontroli i określa jej wynik. Użytkownik nie ma wpływu na wynik kontroli. Kontrola finansowa musi być dokonywana na najniższym poziomie analityki Strona 13 z 43

14 FPKF-06 FPKF-07 FPKF-08 FPKF-09 FPKF-10 (struktury) każdego klasyfikatora. Dla każdego z ww. klasyfikatorów musi istnieć klasyfikator neutralny (pozostający bez wpływu na proces kontroli finansowej) zgodny ze strukturą danego klasyfikatora. System dla każdego dokumentu, w szczególności operacji wprowadzonej do Systemu przed jej zadekretowaniem musi prowadzić ewidencję pozabilansową w układzie klasyfikatorów z wykorzystaniem innych urządzeń rejestrujących, niż konta księgowe. System na poziomie każdego dekretu (w ewidencji bilansowej oraz pozabilansowej z wykorzystaniem kont księgowych) musi prowadzić równolegle ewidencję pozabilansową w układzie klasyfikatorów. System musi umożliwiać ewidencję planu finansowego na różnym poziomie szczegółowości klasyfikatora. W procesie kontroli finansowej System musi blokować i zwalniać kwoty w planie finansowym w taki sposób, aby: 1. nie wystąpiło ryzyko niezabezpieczenia przez System środków na realizację operacji gospodarczej, 2. nie wystąpiło ryzyko zdublowania blokady środków na realizację operacji gospodarczej. 3. Proces ewidencji księgowej FEK-01 FEK-02 FEK-03 FEK-04 FEK-05 FEK-06 FEK-07 Plan kont System musi prezentować rzeczywistą datę księgowania. System musi umożliwiać elastyczne dostosowywanie organizacji ksiąg rachunkowych i rejestrów do zmian w zasadach ewidencji programów /projektów/miejsc powstawania kosztów obsługiwanych przez CUPT. Zmiany w zasadach ewidencji ww. programów będą dokonywane w takim zakresie, w jakim będą wymagały zmieniające się przepisy bez dodatkowych kosztów dla Zamawiającego. Wykonawca Systemu musi dostarczyć dokumentację, o której mowa w art. 10 ust. 1 pkt. 3 lit. b oraz pkt. 4 ustawy z dnia 29 września 1994 r. o rachunkowości (Dz. U. z 2013 r., poz. 330 z późn. zm.). System musi mieć możliwość ustalenia stałej maski konta księgowego. System może umożliwiać pracę w dowolnym układzie kont syntetycznych. System musi mieć możliwość zdefiniowania planu kont zgodnie z potrzebami Jednostki oraz możliwość modyfikacji, rozbudowy. System musi umożliwiać oznaczenie rodzaju konta jako w szczególności konto: rozrachunkowe, bilansowe, pozabilansowe, jednosaldowe, dwusaldowe. Oznaczenie rodzaju konta musi następować na poziomie syntetyki konta księgowego. Oznacza to w szczególności, że każda analityka danego konta zostanie przez System opisana tymi samymi rodzajami. Dla każdego roku obrotowego System musi umożliwiać zmianę oznaczenia rodzaju konta bez możliwości zmiany w ciągu roku obrotowego. System musi domyślnie oznaczyć każde konto jako aktywne. System musi umożliwiać uprawnionemu użytkownikowi dokonanie zmiany oznaczenia konta jako nieaktywne. Konto nieaktywne to takie, na którym nie mogą być dokonywane zapisy księgowe po dacie jego blokady. Jednocześnie zapisy konta nieaktywnego (dokonane przed blokadą) muszą być uwzględniane w raportach, zestawieniach itp. System musi umożliwiać zmianę oznaczenia rodzaju konta z możliwością Strona 14 z 43

15 zmiany w ciągu roku obrotowego. System musi umożliwiać zdefiniowanie kont przeciwstawnych (reguły FEK-08 współzależności). System może umożliwiać wybór sposobu prezentacji konta księgowego na dowolnym poziomie analityki. Wyboru użytkownik może dokonać FEK-09 w szczególności w trakcie wprowadzania danych, generowania wydruków, zestawień. System musi pozwolić na wstępne księgowanie dokumentów. Przez określenie Dokument wstępnie zaksięgowany należy rozumieć dokument, który został zaksięgowany przez użytkowników o niższym stopniu uprawnień i wymaga FEK-10 zatwierdzenia przez użytkownika z uprawnieniem do zatwierdzania i zapisania w Księdze Głównej. Do momentu powyższego zatwierdzenia w dokumencie i w dekrecie tego dokumentu użytkownik może dokonywać wszelkich zmian ( bufor ). System musi automatycznie bądź w wyniku ingerencji użytkownika nadawać i zmieniać status dokumentu księgowego w zależności od etapu w procesie ewidencji księgowej. Przykładowe statusy dokumentu księgowego obejmują: a) wprowadzony (od wprowadzenia dokumentu źródłowego do jego zatwierdzenia), b) zatwierdzony (dokument, który uzyskał wynik kontroli pozytywny we wszystkich wymaganych obszarach), c) wstępnie zaksięgowany (od zatwierdzenia zgodności z planem FEK-11 finansowym do wstępnego zaksięgowania przez użytkownika o niższym stopniu uprawnień), d) zaksięgowany (dokument trwale zapisany w księgach rachunkowych bez możliwości dokonywania zmian), e) wstrzymany (w szczególności dokument, który uzyskał wynik kontroli pozytywny we wszystkich wymaganych obszarach ale decyzją użytkownika został wstrzymany do dalszego obiegu dokumentów w Systemie np. księgowania, wygenerowania przelewu), f) wycofany (dokument wycofany z realizacji). System z pozycji planu kont musi pokazywać obroty konta księgowego w układzie FEK-12 syntetycznym i analitycznym z możliwością podglądu zapisów oraz równolegle w układzie (z wykorzystaniem) klasyfikatorów. System może umożliwiać usunięcie z planu kont, kont księgowych nie FEK-13 zawierających zapisów. System musi umożliwiać zdefiniowanie powiązań dla każdego konta kosztów FEK-14 w układzie rodzajowym z wieloma klasyfikatorami. System musi posiadać funkcjonalność wstępnego i ostatecznego zamknięcia roku obrotowego. Funkcjonalność wstępnego zamknięcia roku obrotowego może być wykonywana wielokrotnie. Funkcjonalność ostatecznego zamknięcia roku obrotowego jest wykonywana jednokrotnie i polega na nieodwracalnym wyłączeniu możliwości dokonywania zapisów księgowych w zbiorach tworzących księgi rachunkowe. Do funkcjonalności zamknięcia roku obrotowego należą w szczególności: FEK automatyczne wygenerowanie przeksięgowania z kont księgowych wynikowych na konto księgowe wyniku finansowego, 2. automatyczne wygenerowanie przez System planu kont w nowym roku obrotowym na podstawie sugerowanego przez System planu kont roku poprzedniego (z możliwością zmiany, dopisania, edycji), 3. wygenerowanie dokumentu księgowego Bilans Otwarcia (BO) z dokumentu księgowego Bilans Zamknięcia (BZ) (przeniesienie sald kont Strona 15 z 43

16 FEK-16 FEK-17 FEK-18 FEK-19 FEK-20 FEK-21 FEK-22 FEK-23 FEK-24 FEK-25 FEK-26 bilansowych i pozabilansowych) z możliwością wielokrotnej aktualizacji BO wraz z równoległą ewidencją w układzie klasyfikatorów. Przeniesienie wszystkich niezbędnych kartotek z zaktualizowanymi danymi. Użytkownik musi mieć możliwość wyboru wykonania jednej lub wielu funkcjonalności zamknięcia roku obrotowego. Dekretacja dokumentów księgowych System musi wspierać proces automatycznego dekretowania dokumentów w zakresie ewidencji bilansowej oraz pozabilansowej z wykorzystaniem kont księgowych oraz równolegle do powyższych ewidencji, wspierać proces automatycznego dekretowania w ewidencji pozabilansowej w układzie (z wykorzystaniem) klasyfikatorów, znaczników, cech, wyróżników, masek itp. System może umożliwiać tworzenie wzorców (szablonów) dekretów dla np.: określonych dokumentów, grup dokumentów, operacji gospodarczych. System musi umożliwić definiowanie automatycznych dekretacji uprawnionemu użytkownikowi merytorycznemu, który nie posiada wiedzy z zakresu programowania. System musi umożliwiać wprowadzenia dokumentów z ręcznym wskazaniem sposobu dekretacji (sposobu ujęcia dowodu w księgach rachunkowych). Dekret księgowy składa się z jednej lub wielu pozycji księgowych. Dekret może zawierać nieograniczoną ilość pozycji księgowych. W ramach wzorców System musi umożliwiać tworzenie pól zmiennych, które uzupełniane są automatycznie w trakcie księgowania danych. Pola zmienne we wzorcu to m.in. kontrahent, beneficjent, pracownik. System musi automatycznie, na bieżąco przeprowadzać kontrolę bilansowania się zapisów księgowych oraz prezentować obroty dekretu. System musi uniemożliwić wprowadzenie przez użytkownika zapisów niebilansujących się na kontach bilansowych. System musi umożliwiać dodatkowo księgowanie jednostronne na kontach pozabilansowych bez kontroli bilansowania zapisów. System musi umożliwić prowadzenie słownika zdarzeń operacji gospodarczych. Do każdego elementu słownika musi być możliwość zdefiniowania wzorcowych opisów operacji gospodarczych. Definiowanie może odbywać się z wykorzystaniem elementów dokumentu źródłowego. Sugerowany przez System opis operacji gospodarczej na dokumencie źródłowym musi podlegać modyfikacji. System musi umożliwiać księgowanie dokumentów źródłowych w dwóch niezamkniętych okresach sprawozdawczych równocześnie to znaczy w miesiącu n (miesiąc bieżący) i n+1 (miesiąc następujący po bieżącym), a także na przełomie roku. System musi umożliwiać zamknięcie miesiąca stycznia kolejnego roku budżetowego oraz miesięcy następnych w sytuacji niezamknięcia miesiąca grudnia poprzedniego roku budżetowego z jednoczesną możliwością zmiany bilansu otwarcia. W procesie dekretacji System musi sugerować listę kont księgowych możliwych do wykorzystania (symbol oraz opis konta księgowego). Przykładowo po wpisaniu syntetyki System automatycznie podpowiada dalej tylko konta analityczne dla danej syntetyki. System musi sugerować listę dokumentów źródłowych do rozliczenia np. nierozliczonych zaliczek. System musi umożliwiać automatyczne dekretowanie pozycji wyciągu bankowego z wykorzystaniem elementów dokumentu źródłowego oraz musi automatyzować rozliczenie rozrachunków. Funkcjonalność ta dotyczy wydatków Jednostki. Strona 16 z 43

17 FEK-27 FEK-28 FEK-29 FEK-30 FEK-31 FEK-32 FEK-33 FEK-34 FEK-35 FEK-36 W przypadku operacji wpływu, operacji w walucie obcej i rozliczania rozrachunków System musi umożliwiać ingerencję użytkownika. System musi po zatwierdzeniu listy płac automatycznie generować pełną dekretację listy płac w szczególności z uwzględnieniem składników wynagrodzeń, pochodnych, potrąceń. System musi zapewnić ewidencję listy płac zarówno w Systemie ewidencji bilansowej oraz pozabilansowej z wykorzystaniem kont księgowych oraz musi prowadzić równolegle do powyższych ewidencji, ewidencję pozabilansową w układzie (z wykorzystaniem) klasyfikatorów. System musi automatyzować proces dekretowania naliczonej amortyzacji składników majątku jednostki. System musi zapewnić wielowalutowość operacji. Rozrachunki System musi umożliwiać wgląd i wydruki z historii rozrachunków z kilku lat obrotowych przechowywanych w Systemie. System musi automatycznie tworzyć i rozliczać rozrachunki w szczególności z uwzględnieniem ewidencji bilansowej oraz pozabilansowej w układzie (z wykorzystaniem) klasyfikatorów. System musi umożliwiać również utworzenie i rozliczenie rozrachunku poprzez ingerencję użytkownika. W procesie tworzenia i rozliczania rozrachunków muszą być odwzorowane następujące zależności (relacje): 1. jeden rozrachunek jeden dokument rozliczający, 2. jeden rozrachunek wiele dokumentów rozliczających, 3. wiele rozrachunków jeden dokument rozliczający. System musi umożliwiać wiekowanie rozrachunków, zgodnie z przedziałami wiekowymi definiowanymi przez użytkownika w szczególności: 1. z uwzględnieniem terminu zapłaty (przeterminowane i nieprzeterminowane), 2. z uwzględnieniem ich wymagalności (krótko, długoterminowe zgodnie z definicją ustawy o rachunkowości), 3. z uwzględnieniem ich wymagalności (krótko, długoterminowe zgodnie z definicją na potrzeby sporządzenia sprawozdań budżetowych), 4. z uwzględnieniem odpisów aktualizujących. System musi umożliwiać zarządzanie rozrachunkami, w szczególności musi umożliwić dokonanie analizy rozrachunków w różnych przekrojach np.: 1. według rodzaju rozrachunku, 2. według typu rozrachunku, 3. według kontrahenta, 4. rodzaju relacji kontrahenta w stosunku do CUPT (relacje zdefiniowane w Rejestrze kontrahentów), 5. według grupy lub kilku grup kontrahentów, 6. z uwzględnieniem ewidencji bilansowej oraz pozabilansowej w układzie (z wykorzystaniem) klasyfikatorów, 7. z uwzględnieniem terminów płatności, 8. monitorowanie należności pod kątem terminów wymagalności, 9. monitorowanie zobowiązań pod kątem zapadalności, 10. na dowolnie wybrany dzień (uwzględniając stan na wybrany dzień). Wydruki System musi zapewnić sporządzenie wydruku/prezentacji na ekran/importu/exportu wszelkich zestawień/raportów wymaganych ustawą o rachunkowości i zgodnych z ustawą o rachunkowości, z uwzględnieniem wyboru opcji dokumentów wstępnie zaksięgowanych i zaksięgowanych z jawną Strona 17 z 43

18 FEK-37 FEK-38 FEK-39 FEK-40 prezentacją na wydruku zastosowanej opcji, w szczególności: a. zestawienia obrotów i sald kont Księgi Głównej oraz zestawienie sald kont ksiąg pomocniczych, b. konta Księgi Głównej (ewidencja syntetyczna), c. konta ksiąg pomocniczych (ewidencja analityczna), d. dzienniki księgowań w dowolnym układzie, e. aktywność kont księgowych (zapisy na kontach księgowych). System musi zapewnić sporządzenie wydruku/prezentacji na ekran/importu/exportu wszelkich zestawień/raportów wymaganych ustawą o rachunkowości i zgodnych z ustawą o rachunkowości, w szczególności dla ewidencji bilansowej oraz ewidencji pozabilansowej w układzie (z wykorzystaniem) klasyfikatorów, lub osobne wydruki dla obu ewidencji, lub wydruk dla ewidencji pozabilansowej z wykorzystaniem kont księgowych oraz ewidencji pozabilansowej w układzie (z wykorzystaniem) klasyfikatorów, lub osobne wydruki dla obu ewidencji, na dowolnym poziomie szczegółowości powyższych ewidencji. System musi zapewnić sporządzenie wydruku/prezentacji na ekran/importu/exportu wszelkich zestawień/raportów z możliwością definiowania przez użytkownika kryteriów wyborów wydruku, z uwzględnieniem wyboru opcji dokumentów wstępnie zaksięgowanych i zaksięgowanych z jawną prezentacją na wydruku zastosowanej opcji, w szczególności: a. na dowolny dzień, b. dla dowolnych okresów czasu, c. dla wybranych kont księgowych (w tym tylko konta syntetyczne), d. dla wybranej grupy kont (możliwość zdefiniowania przez użytkownika grup kont np. w zakresie wybranych analityk konta syntetycznego), e. dla rodzaju dziennika, f. z uwzględnieniem rodzaju kont księgowych (np. bilansowe, pozabilansowe, wynikowe itp.), g. z uwzględnieniem kont o zerowych saldach narastających, h. z uwzględnieniem kont o zerowych obrotach okresu, i. z uwzględnieniem kont o zerowych obrotach narastających, j. z uwzględnieniem dowolnego poziomu ewidencji pozabilansowej w układzie (z wykorzystaniem) klasyfikatorów, k. z uwzględnieniem dowolnego klasyfikatora/zestawu klasyfikatorów. System może umożliwiać definiowanie oddzielnie przez każdego użytkownika wydruku/prezentacji na ekran. System może zapamiętywać indywidualne ustawienia użytkownika. Każdy wydruk zawsze musi zawierać: a. trwałe oznaczenie nazwą (pełną lub skróconą Zamawiającego) której dotyczą, nazwę danego rodzaju księgi rachunkowej oraz nazwę programu przetwarzania, b. wyraźne oznaczenie co do roku obrotowego okresu sprawozdawczego i daty sporządzenia, c. liczbą porządkową pozycji na wydruku, d. numer strony z oznaczeniem bieżącej i ostatniej, e. sumę kwot na stronie, sumę kwot z przeniesienia oraz sumę kwot narastająco, f. metrykę wydruku, tj. użytkownik dokonujący wydruku (imię i nazwisko - login), data i godzina dokonania wydruku, g. parametry wydruku zastosowane przez użytkownika. Strona 18 z 43

19 FEK-41 FEK-42 System musi zapewnić możliwość wydruku/prezentacji na ekran/exportu dekretów księgowych. System musi automatycznie umieszczać na wydruku dekretu datę jego sporządzenia oraz informację o osobie odpowiedzialnej za treść zapisu z wyspecyfikowaniem użytkowników dokonujących weryfikacji na poszczególnych poziomach uprawnień do zatwierdzenia i zapisania dokumentu w Księdze Głównej. System musi umożliwiać wybór opcji sporządzenia wydruku dekretów np.: a. jeden wydruk dla dekretu ewidencji bilansowej oraz ewidencji pozabilansowej w układzie (z wykorzystaniem) klasyfikatorów, b. osobne wydruki dla dekretu ewidencji bilansowej i ewidencji pozabilansowej w układzie (z wykorzystaniem) klasyfikatorów, c. jeden wydruk dla dekretu ewidencji pozabilansowej wykorzystaniem kont księgowych oraz ewidencji pozabilansowej w układzie (z wykorzystaniem) klasyfikatorów, d. osobne wydruki dla dekretu ewidencji pozabilansowej wykorzystaniem kont księgowych oraz ewidencji pozabilansowej w układzie (z wykorzystaniem) klasyfikatorów. 4. Proces realizacji płatności FPRP-01 FPRP-02 FPRP-03 FPRP-04 FPRP-05 FPRP-06 FPRP-07 FPRP-08 FPRP-09 System musi zapewniać możliwość integracji (przepływu/przenoszenia) informacji do/z Systemu Bankowości Elektronicznej (BE). Obecnie wykorzystywany jest w Jednostce BE enbepe moduł VideoTEL. System może zapewniać możliwość integracji (przepływu/przenoszenia) informacji do portalu komunikacyjnego BGK-Zlecenia, tj. eksport z Systemu do portalu BGK w zakresie tworzenia programowych zleceń płatności. System musi pozwalać na wygenerowanie przelewów (dla realizacji przelewów w NBP) w sposób automatyczny na podstawie danych wprowadzonych do Systemu, z uwzględnieniem wymaganych warunków, w tym w szczególności z uwzględnieniem wyników procesu kontroli finansowej, statusu dokumentu. System musi umożliwiać wygenerowanie przelewów/zleceń płatności przez użytkownika (w sposób ręczny ). System musi umożliwiać dla przelewów wprowadzanych w sposób ręczny wskazanie referencji do dokumentów źródłowych/płatności źródłowych. System musi pozwalać na wygenerowanie zleceń płatności (dla realizacji zleceń płatności w BGK) do Rejestru Przelewów w sposób automatyczny na podstawie danych wprowadzonych do Systemu, z uwzględnieniem wymaganych warunków, w tym w szczególności z uwzględnieniem wyników procesu kontroli finansowej, statusu dokumentu. System musi generować/eksportować przelewy w formacie wymaganym przez Urząd Skarbowy i Zakład Ubezpieczeń Społecznych. System musi generować/eksportować przelewy/zlecenia płatności w formacie i z uwzględnieniem danych wymaganych w przelewie/zleceniu płatności dla Instytucji Wdrażającej i Jednostki budżetowej (np. rozdział/ paragraf). Rejestr Przelewów musi umożliwiać przeglądanie przelewów, a także ewentualną możliwość ich modyfikacji. Zlecenie płatności musi zawierać dane zgodne z Załącznikiem nr 1 do Rozporządzenia Ministra Finansów z dnia 21 grudnia 2012 r. w sprawie płatności w ramach programów finansowanych z udziałem środków europejskich oraz przekazywania informacji dotyczących tych płatności (Dz. U. z dnia Strona 19 z 43

20 FPRP-10 FPRP-11 FPRP-12 FPRP-13 FPRP-14 FPRP-15 FPRP-16 FPRP-17 FPRP-18 FPRP-19 FPRP r., poz. 1539) np. kategoria interwencji, sektor beneficjenta. System musi importować z Systemu bankowości elektronicznej (w przypadku NBP) pozycje wyciągów bankowych/wyciągi bankowe z jednoczesnym automatycznym rozliczaniem właściwego rozrachunku w Systemie. System może importować z Systemu bankowości internetowej (w przypadku BGK) informację o zrealizowanych zleceniach płatności z jednoczesnym automatycznym rozliczaniem właściwego rozrachunku w Systemie. System musi umożliwiać wygenerowanie przelewu w odmiennej walucie niż waluta rachunku. System musi zapewniać pełną automatyzację sporządzania przelewów dotyczących wynagrodzeń osobowych oraz bezosobowych. System musi zapewniać zachowanie poufności informacji o wynagrodzeniach oraz innych świadczeń na rzecz pracowników. Poufność w szczególności może polegać na możliwości importu wyciągów bankowych dla przelewów oznaczonych jako wrażliwe (np. wynagrodzenia) w kwotach zbiorczych. System musi umożliwiać ręczny wybór przelewów/zleceń płatności do realizacji. W przypadku generowania przez System przelewu z rachunku wydatków na rachunek dochodów CUPT, System automatycznie sugeruje wygenerowanie przelewu na odpowiedni rachunek dochodów centralnego rachunku bieżącego budżetu państwa, tj. rachunek, którego dysponentem jest Minister Finansów zgodnie z Rozporządzeniem Ministra Finansów z dnia 15 stycznia 2014 r. w sprawie szczegółowego sposobu wykonywania budżetu państwa (Dz. U. z 2014 r., poz. 82). System musi umożliwiać częściową zapłatę za zobowiązania. System musi umożliwiać wydrukowanie pozycji składających się na przelewy/zlecenia płatności wychodzące/przychodzące. System musi generować informację o płatnościach zrealizowanych po terminie w stosunku do terminu płatności określonego np. w umowie. Po zrealizowaniu przelewu/zlecenia płatności System może automatycznie przekazywać ww. informacje (za pośrednictwem poczty elektronicznej) do wskazanych pracowników Jednostki w poszczególnych komórkach organizacyjnych CUPT. Informacja ta może zawierać niezbędne dane identyfikujące przelew/zlecenie płatności w szczególności nazwę odbiorcy, kwotę, tytuł płatności. 5. Proces obsługi kasowej FPOK-01 FPOK-02 FPOK-03 FPOK-04 FPOK-05 System obsługi kasy musi być zintegrowany z systemem ewidencji księgowej. System musi umożliwiać ewidencję operacji kasowych z uwzględnieniem klasyfikatorów. System musi umożliwiać tworzenie funkcjonalnych kas w zależności od waluty i numeru rachunku bankowego, z którego pobierane są środki pieniężne z banku do kasy. System musi umożliwiać edycję (dodawanie, usuwanie i zmianę) wzorów (szablonów) dokumentów kasowych (KP, KW, Raport kasowy) oraz zawierać opcje automatycznego podstawiania zaaprobowanego wzoru do wszystkich funkcjonalnie wydzielonych kas. System musi umożliwiać tworzenie dokumentów KP, KW, Raportów kasowych oraz umożliwiać powiązanie powyższych dokumentów z rozrachunkami. Strona 20 z 43

21 FPOK-06 FPOK-07 FPOK-08 FPOK-09 FPOK-10 FPOK-11 System musi mieć możliwość ustalenia, a także edycji masek dokumentów. System powinien zapewnić możliwość przypisania środków pieniężnych znajdujących się w kasie do więcej niż jednego klasyfikatora. System musi zapewnić możliwość dokonywania zmian w zakresie przypisania środków pieniężnych do klasyfikatorów. System musi umożliwiać edycję dokumentów kasowych do chwili ujęcia dokumentu w raporcie kasowym. System musi mieć możliwość wygenerowania Raportu kasowego za dowolny okres. System powinien umożliwić prowadzenie rejestrów: 1. depozytów, 2. blankietów czeków gotówkowych. 6. Rejestry FO-01 FO-02 System musi umożliwić prowadzenie podstawowych rejestrów, obsługujących procesy realizowane u Zamawiającego, w szczególności: 1. Rejestr Kontrahentów, 2. Rejestr Wniosków o zaciągnięcie zobowiązania, 3. Rejestr Umów/Aneksów/Zamówień, 4. Rejestr Dokumentów źródłowych, 5. Rejestr Lista Płac, 6. Rejestr składników majątku 7. Rejestr Delegacji. System musi umożliwiać wpisanie wszystkich danych Zamawiającego niezbędnych do obsługi wszystkich procesów w Systemie, w szczególności: 1. nazwa pełna Jednostki, 2. nazwa skrócona Jednostki, 3. adres Jednostki, w tym adres do korespondencji, 4. NIP, 5. REGON, 6. dane teleadresowe, 7. kod województwa, 8. rachunki bankowe, których Zamawiający jest właścicielem i z których realizuje płatności, w tym w szczególności właściciel rachunku, numer rachunku, przeznaczenie rachunku, okres obowiązywania rachunku, nazwa banku, waluta rachunku, IBAN, SWIFT/BIC, dane osób do kontaktu w danym banku, data złożenia NIP-2 (B) w Urzędzie Skarbowym, data odwołania rachunku bankowego w Urzędzie Skarbowym, informacja o oprocentowaniu rachunku, opłaty/prowizje, pole uwagi; System musi umożliwić zdefiniowanie wielu rachunków, System musi umożliwiać wskazanie rachunku domyślnego do przelewów zgodnie z jego przeznaczeniem, 9. rachunki bankowe, których Zamawiający nie jest właścicielem, a z których realizuje płatności, w tym w szczególności właściciel rachunku, numer rachunku, przeznaczenie rachunku, okres obowiązywania rachunku, nazwa banku, waluta rachunku, IBAN, SWIFT/BIC, dane osób do kontaktu w danym banku, pole uwagi; System musi umożliwić zdefiniowanie wielu rachunków, System musi umożliwiać wskazanie rachunku domyślnego do przelewów zgodnie z jego przeznaczeniem. Strona 21 z 43