Minimalne wymagania NSI

Transkrypt

1 Minimalne wymagania NSI

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 nie będące wymaganiem krytycznym. W przypadku, gdy nie występują jednoznacznie wskazane wymagania w postaci powyższych zapisów, należy je traktować jako zapisy informacyjne. Wykaz stosowanych skrótów: NSI/System - System Finansowo-Księgowy, Kadrowo-Płacowy oraz Środków Trwałych CUPT CUPT/Zamawiający Centrum Unijnych Projektów Transportowych DE Departament Ekonomiczno-Finansowy DO Departament Organizacji i Zarządzania Zasobami OK Wydział Kadr i Szkoleń OA Wydział Administracji OT Wydział Pomocy Technicznej OI Wydział Informatyki KSI Krajowy System Informatyczny NBP Narodowy Bank Polski BGK Bank Gospodarstwa Krajowego UOFP Ustawa z 27 sierpnia 2009 r. o finansach publicznych (Dz. U. z 2009 r. Nr 157, poz z późn. zm.) Pzp Ustawa z 29 stycznia 2004 r. - Prawo zamówień publicznych ( Dz. U. z 2010 r. Nr 113, poz. 759 z późn. zm.)

3 Wymagania techniczne NSI 1. Wymagania ogólne Kod WT-1 WT-2 WT-3 WT-4 WT-5 WT-6 WT-7 Opis wymagania funkcjonalnego 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 System musi eksportować i importować dane do i z Systemu na każdym poziomie modułów do i z dokumentów Excel, Word, XML. System i jego moduły muszą być ściśle dostosowane do polskiego ustawodawstwa i charakteru działalności Zamawiającego jako instytucji publicznej. System musi udostępniać graficzne narzędzie służące do definiowania procesów w szczególności: 1. tworzenie diagramów definiujących obiegi dokumentów i zadań 2. tworzenie schematów struktury organizacyjnej CUPT 3. określanie odpowiedzialności za poszczególne sprawy i zadania 4. definiowanie słowników zmiennych opisujących określone typy spraw 5. definiowanie formularzy służących do wpisywania danych o sprawach System musi umożliwiać edytowanie list słownikowych (np. słownik podgrup wniosków, nazwy wnioskodawców, nazwisk pracowników poszczególnych wydziałów CUPT). System musi posiadać wbudowany generator raportów: 1. Zawierający dostęp do wszelkich danych wprowadzonych w Systemie 2. Pozwalający na filtrowanie danych wg dowolnych warunków 3. Pozwalający na stosowanie szablonów raportów Wykonawca musi zagwarantować bezproblemową, jednoczesną pracę wymaganej liczby użytkowników, bez spowolnienia działania Systemu. Obecna liczba użytkowników Systemu wynosi 50 osób, planowany roczny przyrost to 15%. Liczba administratorów obsługujących System to aktualnie 2 osoby. 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: WT-8 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: 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 Definicje błędów: 1. Błąd krytyczny (występuje co najmniej jeden z poniższych warunków)

4 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 WT-9 WT Inne problemy a. 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 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 d. Zgłaszanie usterek i innych potrzeb za pomocą Systemu typu bug tracker. W przypadku braku dostępu lub awarii tego Systemu za pomocą poczty elektronicznej i/lub telefonicznie. System typu bug-tracker musi być dostępny 24 godz. na dobę przez 7 dni w tygodniu. e. Wsparcie telefoniczne i/lub pocztą elektroniczną umożliwiające jak najsprawniejsze usunięcie awarii Systemu. f. 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. 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 (jednej na 12 miesięcy).. 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.

5 WT-11 WT-12 WT-13 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-17: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

6 I. Opis procesów finansowo-księgowych oraz kadrowo-płacowych w CUPT Proces planowania Planowanie Akceptacja Poglądowy przebieg procesu planowania przedstawia Re-Planowanie poniższy schemat: Tabela planistyczna Tabela planistyczna Tabela planistyczna Tabela planistyczna Re-Akceptacja Tabela planistyczna Działalność: operacyjna programowa Limity Budżetu Państwa Formularze planistyczne Formularze planistyczne II etapu Projekt Planu Finansowego Projekt Planu Finansowego Plan finansowy Plan Finansowy Wnioski i zmiany Plan Finansowy Wnioski i zmiany do Planu Finansowego Limity Projektu Ustawy budżetowej Limity Ustawy Budżetowej

7 Kod FPP-01 FPP-02 FPP-03 FPP-04 FPP-05 FPP-06 FPP-07 Opis wymagania funkcjonalnego W ramach menu Planowanie muszą zostać wyodrębnione następujące zakładki/obszary: a. budżety (tabele planistyczne), b. formularze planistyczne, c. limity, d. plan finansowy, e. Rejestr wniosków i decyzji w sprawie zmiany planu, w tym obejmujący również wnioski do rezerwy celowej. Funkcjonalności dotyczące planowania mogą być dostępne w ramach odrębnego interfejsu/menu w Systemie. Budżety (tabele planistyczne) W Systemie musi być dostępna funkcjonalność generowania tabeli planistycznej/tabel planistycznych z uwzględnieniem funkcjonujących w Systemie klasyfikatorów. System musi posiadać funkcjonalność symulowania planowanych wydatków operacyjnych i programowych na podstawie danych dostępnych w Systemie zgodnie z algorytmem wskazanym przez użytkownika. Przykładowy algorytm dla wydatków operacyjnych planowanych na rok 2013: a. pobieraj dane z wykonania planu w roku 2011 (konto 130) w układzie klasyfikatorów oraz każdą kwotę przemnóż przez 115%, i b. na poszczególnych klasyfikatorach wprowadź kwoty nie mniejsze niż zaplanowane wydatki na rok 2012, i c. na poszczególnych klasyfikatorach wprowadź kwoty nie mniejsze niż zaangażowanie wydatków na poszczególnych klasyfikatorach na rok Przykładowy algorytm dla wydatków programowych: a. dla umów o dofinansowanie podpisanych pobieraj dane z rejestru umów na podstawie zaangażowania środków dla danej umowy dla danego okresu, b. dla umów o dofinansowanie podpisanych pobieraj dane z rejestru umów na podstawie harmonogramu finansowego realizacji projektu wraz zadanym przesunięciem np. o dwa kwartały, c. dla projektów, dla których nie podpisano umów o dofinansowanie dane będą importowane z tabeli excelowej. System musi pozwalać na tworzenie i zapisanie wielu wersji budżetu/tabeli planistycznej dla danego okresu (wersjonowanie budżetu) oraz umożliwiać przywrócenie dowolnej poprzedniej wersji Formularze planistyczne System na podstawie danych z jednej lub większej liczby tabel planistycznych (wersji budżetu w Systemie) wskazanych przez użytkownika musi automatycznie generować formularze planistyczne na wzorach wynikających z Rozporządzenia w sprawie szczegółowego sposobu, trybu i terminów opracowania materiałów do ustawy budżetowej. System musi pozwalać uprawnionym użytkownikom na zmianę/uzupełnienie/dopisanie/dostosowanie wzorów formularzy planistycznych. Limity System musi pozwalać na definiowanie wielu typów limitów operacyjnych i programowych.

8 FPP-08 FPP-09 FPP-10 FPP-11 FPP-12 FPP-13 FPP-14 FPP-15 FPP-16 FPP-17 FPP-18 FPP-19 FPP-20 FPP-21 FPP-22 Każdy typ limitu musi być co do zasady zdefiniowany w oparciu o System klasyfikatorów na dowolnym jego poziomie. System musi pozwalać na wprowadzenie limitów wydatków operacyjnych i programowych na różnych etapach planowania, w szczególności: a. prowadzenie limitów wydatków operacyjnych i programowych na poszczególne lata budżetowe, b. na poszczególnych etapach planowania w danym roku. System musi posiadać funkcjonalność sprawdzania zgodności danych wprowadzonych do tabeli planistycznej ze wskazanymi przez użytkownika dostępnymi w Systemie limitami. Plan Finansowy System musi generować propozycje projektu planu finansowego/planu finansowego dla budżetu państwa oraz budżetu środków europejskich w układzie klasyfikatorów w oparciu o tabelę planistyczną/tabele planistyczne wskazane przez użytkownika dla projektu planu; dla planu finansowego w oparciu o projekt planu na dany rok budżetowy z uwzględnieniem: a. przyznanych limitów wprowadzonych do Systemu oraz wskazanych przez użytkownika, b. zaangażowania na poszczególnych klasyfikatorach na dany rok budżetowy. System musi posiadać funkcjonalność wielokrotnego sprawdzania zgodności kwot projektu planu finansowego/planu finansowego ze wskazanymi przez użytkownika limitami wprowadzonymi do Systemu. System musi posiadać funkcjonalność wielokrotnego sprawdzenia zgodności kwot na dowolnym poziomie klasyfikatora z zaangażowaniem na tych klasyfikatorach. System musi pozwolić na automatyczne wygenerowanie dekretu księgowego projektu planu finansowego/planu finansowego w celu ujęcia go w księgach rachunkowych CUPT. 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. 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 CUPT) musi automatycznie zwolnić blokadę kwot objętych w ramach wniosku zmniejszeniem planu oraz uwzględniać w ramach kontroli finansowej kwoty zwiększające plan.

9 Proces Kontroli Finansowej Kod FPKF-01 FPKF-02 FPKF-03 FPKF-04 FPKF-05 FPKF-06 FPKF-07 FPKF-08 FPKF-09 FPKF-10 FPKF-11 FPKF-12 Opis wymagania funkcjonalnego Proces kontroli co do zasady musi być dokonywany na trzech etapach, tj: a. na etapie wniosku o zaciągnięcie zobowiązania (w ciężar planu), b. na etapie projektu umowy (w ciężar wniosku o zaciągnięcie zobowiązania z ponowną weryfikacją planu lub w ciężar planu), c. 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: a. kontroli merytorycznej (wspomagana przez System), b. 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), c. kontroli formalno-rachunkowej (wspomagana przez System), d. kontroli zabezpieczeń (wykonywana przez System). Kontrola wykonywana przez System oznacza, że System dokonuje automatycznej kontroli i określa jej wynik. Użytkownik nie ma wpływu na wynik kontroli. System może wykorzystać funkcjonalność work flow. Kontrola finansowa musi być dokonywana na najniższym poziomie analityki (struktury) każdego klasyfikatora. Dla każdego z ww. klasyfikatorów musi istnieć klasyfikator neutralny zgodny ze strukturą danego klasyfikatora. Kontrola zabezpieczeń w szczególności musi polegać na sprawdzeniu przez System zabezpieczeń wymaganych w umowie z zabezpieczeniami złożonymi do umowy, komunikowaniu o zbliżającym się terminie wygaśnięcia zabezpieczenia oraz potwierdzeniu, że kwota do wypłaty zawiera się w kwocie ustanowionego zabezpieczenia. 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 CUPT w taki sposób, aby: a. nie wystąpiło ryzyko niezabezpieczenia przez System środków na realizację operacji gospodarczej, b. nie wystąpiło ryzyko zdublowania blokady środków na realizację operacji gospodarczej. System co do zasady musi zapewnić wszystkim rejestrom i wszystkim typom dokumentów w ramach poszczególnych rejestrów wszystkie obszary kontroli finansowej. Każdemu etapowi kontroli finansowej mogą odpowiadać różne obszary kontroli finansowej.

10 Proces Kontroli Finansowej w zakresie kadrowo-płacowym wymagania ogólne Szczegółowy zakres i proces kontroli finansowej w zakresie wynagrodzeń i pochodnych zostanie zdefiniowany przez Wykonawcę przy współpracy z Zamawiającym (ponadto zostanie zweryfikowany i zatwierdzony przez Zamawiającego) w ramach realizacji przedmiotu zamówienia na etapie analizy przedwdrożeniowej. Kod Opis wymagania funkcjonalnego Proces kontroli wynagrodzeń, co do zasady musi być dokonywany na trzech etapach, tj.: a. na etapie wniosku o zaciągnięcie zobowiązania kontrola dokonywana jest w ciężar planu. Kontroli podlegają wnioski pracownicze wymienione w rejestrze wniosków o zaciągnięcie zobowiązania. FPKP-01 FPKP-02 Wniosek o zatrudnienie Wniosek podwyżka, dodatek, nagroda Wniosek nagrody - zbiorczy Umowy cywilnoprawne Inne Dokumentem potwierdzającym dokonanie tej kontroli jest karta kontroli zaangażowania. b. na etapie projektu umowy (w ciężar wniosku o zaciągnięcie zobowiązania z ponowną weryfikacją planu lub w ciężar planu) c. na etapie dokumentu źródłowego (w ciężar zaangażowania i planu) kontroli podlega lista płac. Kontrola finansowa w szczególności musi polegać na wspomaganiu przez System obszarów: a. kontroli merytorycznej (wspomagana przez System) np. kontroli w zakresie zgodności proponowanych warunków zatrudnienia na poszczególnych stanowiskach z określonymi w przepisach wymaganiami dotyczącymi stażu pracy, wykształcenia, wysokości wynagrodzenia i dodatków wspomagana przez System (widełki płacowe) b. 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) c. kontroli formalno-rachunkowej (wspomagana przez System) Kontrola wspomagana przez System oznacza, że uprawniony użytkownik sam określa wynik kontroli. Wspomaganie polega na możliwości edycji wymaganych walidacji. Użytkownik ma wpływ na wynik kontroli. Kontrola wykonywana przez System oznacza, że System dokonuje automatycznej kontroli i określa jej wynik. Użytkownik nie ma wpływu na wynik kontroli. System może wykorzystać funkcjonalność work flow. Kontrola finansowa zgodności kwot opisanych Systemem klasyfikatorów na dokumentach wprowadzonych do Systemu z planem finansowym oznacza weryfikacje: a. dla bieżącego roku budżetowego - z planem finansowym bieżącego roku budżetowego lub projektem planu finansowego bieżącego roku budżetowego,

11 i/lub b. dla następnego roku budżetowego z projektem planu finansowego na następny rok budżetowy lub tabelą planistyczną, jeśli projekt planu nie został jeszcze zatwierdzony. Proces ewidencji księgowej Kod Opis wymagania funkcjonalnego System musi umożliwiać organizację ksiąg rachunkowych oraz realizację procesów finansowych zgodnie z obowiązującą ustawą z dnia 29 września 1994 r. o rachunkowości (Dz. U. z 2009 r. Nr 152 poz z późn. zm.) oraz obowiązującym Rozporządzeniem Ministra Finansów z dnia 5 lipca 2010 r. w FEK-01 sprawie szczególnych zasad rachunkowości oraz planów kont dla budżetu państwa, budżetów jednostek samorządu terytorialnego, jednostek budżetowych, samorządowych zakładów budżetowych, państwowych funduszy celowych oraz państwowych jednostek budżetowych mających siedzibę poza granicami Rzeczpospolitej Polskiej ( Dz. U. Nr 128 poz. 861). Plan kont FEK-02 System musi w bazie danych pokazywać rzeczywistą datę księgowania,. FEK-03 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 FEK-04 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, wynikowe, pozabilansowe, jednosaldowe, dwusalowe. Oznaczenie rodzaju konta musi następować na poziomie syntetyki konta FEK-05 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 FEK-06 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ą zmiany w ciągu roku obrotowego. FEK-07 System musi umożliwiać zdefiniowanie kont przeciwstawnych (reguły współzależności). System może umożliwiać wybór sposobu prezentacji konta księgowego FEK-08 na dowolnym poziomie analityki. Wyboru użytkownik może dokonać w szczególności w trakcie wprowadzania danych, generowania wydruków, zestawień. System z pozycji planu kont musi pokazywać obroty konta księgowego FEK-09 w układzie syntetycznym i analitycznym z możliwością podglądu zapisów oraz równolegle w układzie (z wykorzystaniem) klasyfikatorów. FEK-10 System może umożliwiać usunięcie z planu kont, kont księgowych nie zawierających zapisów. FEK-11 System musi umożliwiać zdefiniowanie powiązań dla każdego konta kosztów w układzie rodzajowym z wieloma klasyfikatorami. System musi posiadać funkcjonalność wstępnego i ostatecznego zamknięcia roku FEK-12 obrotowego. Funkcjonalność wstępnego zamknięcia roku obrotowego może być wykonywana wielokrotnie. Funkcjonalność ostatecznego zamknięcia roku

12 FEK-13 FEK-14 FEK-15 FEK-16 FEK-17 FEK-18 FEK-19 FEK-20 FEK-21 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: a. automatyczne wygenerowanie przeksięgowania z kont księgowych wynikowych na konto księgowe wyniku finansowego, b. 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), c. wygenerowanie dokumentu księgowego Bilans Otwarcia (BO) z dokumentu księgowego Bilans Zamknięcia (BZ) (przeniesienie sald kont 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. 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ż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

13 FEK-22 FEK-23 FEK-24 FEK-25 FEK-26 FEK-27 FEK-28 FEK-29 FEK-30 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. 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. 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): a. jeden rozrachunek jeden dokument rozliczający, b. jeden rozrachunek wiele dokumentów rozliczających, c. 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: a. z uwzględnieniem terminu zapłaty (przeterminowane i nieprzeterminowane), b. z uwzględnieniem ich wymagalności (krótko, długoterminowe zgodnie z definicją ustawy o rachunkowości), c. z uwzględnieniem ich wymagalności (krótko, długoterminowe zgodnie z definicją na potrzeby sporządzenia sprawozdań budżetowych), d. z uwzględnieniem odpisów aktualizujących. System musi umożliwiać zarządzanie rozrachunkami, w szczególności musi umożliwić na dokonanie analizy rozrachunków w różnych przekrojach: a. według rodzaju rozrachunku, b. według typu rozrachunku, c. według kontrahenta, d. rodzaju relacji kontrahenta w stosunku do CUPT (relacje zdefiniowane w Rejestrze kontrahentów), e. według grupy lub kilku grup kontrahentów, f. z uwzględnieniem ewidencji bilansowej oraz pozabilansowej w układzie (z wykorzystaniem) klasyfikatorów, g. z uwzględnieniem terminów płatności, h. monitorowanie należności pod kątem terminów wymagalności, i. monitorowanie zobowiązań pod kątem zapadalności, j. na dowolnie wybrany dzień (uwzględniając stan na wybrany dzień).

14 Proces realizacji płatności Kod FPRP-01 FPRP-02 FPRP-03 FPRP-04 FPRP-05 FPRP-06 FPRP-07 FPRP-08 FPRP-09 FPRP-10 FPRP-11 FPRP-12 FPRP-13 FPRP-14 FPRP-15 FPRP-16 FPRP-17 Opis wymagania funkcjonalnego 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 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. 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 17 grudnia 2009 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 2009 r., Nr 220, poz. 1726) 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 przed eksportem przelewu/zlecenia płatności do bankowości elektronicznej/internetowej musi sprawdzić wynik kontroli zabezpieczeń (w rozumieniu zabezpieczeń prawnych umowy). 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

15 FPRP-18 FPRP-19 FPRP-20 FPRP-21 na rachunek dochodów CUPT, System automatycznie sugeruje wygenerowanie przelewu na rachunek Ministra Finansów. 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 Departamentach/Wydziałach 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. Proces obsługi kasowej 1. System musi być otwarty na prowadzenie obsługi kasowej. II. Opis funkcjonalności NSI wymagania ogólne System musi zapewniać także co najmniej następujące funkcjonalności ogólne (FO): Kod FO-01 FO-02 Opis wymagania funkcjonalnego System musi umożliwić prowadzenie podstawowych rejestrów, obsługujących procesy realizowane u Zamawiajacego, w szczególności: a. Rejestr Kontrahentów b. Rejestr Wniosków o zaciągnięcie zobowiązania c. Rejestr Umów/Aneksów d. Rejestr Dokumentów źródłowych e. Rejestr Lista Płac f. Rejestr Środków trwałych g. Rejestr Delegacji h. Rejestr Szkoleń i. Rejestr Zabezpieczeń System musi umożliwiać wpisanie wszystkich danych Zamawiającego niezbędnych do obsługi wszystkich procesów w Systemie, w szczególności: a. nazwa pełna jednostki, b. nazwa skrócona jednostki, c. adres jednostki, w tym adres do korespondencji, d. NIP, e. REGON f. dane teleadresowe, g. kod województwa, h. 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ć

16 FO-03 FO-04 FO-05 FO-06 FO-07 FO-08 FO-09 FO-10 FO-11 FO-12 FO-13 FO-14 FO-15 FO-16 FO-17 FO-18 na zdefiniowanie wielu rachunków, System musi umożliwiać wskazanie rachunku domyślnego do przelewów zgodnie z jego przeznaczeniem, i. 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ć na zdefiniowanie wielu rachunków, System musi umożliwiać wskazanie rachunku domyślnego do przelewów zgodnie z jego przeznaczeniem. System musi zapewniać zabezpieczenia przed nieautoryzowanym dostępem do baz danych poprzez loginy i hasła przydzielane poszczególnym użytkownikom. System musi wymuszać na użytkownikach okresową zmianę haseł dostępu do baz danych. System musi umożliwiać określenie poziomu uprawnień dostępu użytkowników do poszczególnych rejestrów wraz z zakresem ingerencji w dane (dodawanie/usuwanie danych, edycja). System musi umożliwiać selektywne dodawanie danych w ramach poszczególnych rejestrów. System musi umożliwiać gromadzenie danych w ramach poszczególnych rejestrów. System musi umożliwiać wymianę danych pomiędzy poszczególnymi rejestrami tak, aby zapewnić ich spójność i komplementarność. System musi umożliwiać wybieranie wartości z list słownikowych, podlegających cyklicznym weryfikacjom i ewentualnym zmianom, w szczególności System musi umożliwiać oznaczenie każdego elementu list słownikowych jako element archiwalny. System musi umożliwiać eksportowanie wygenerowanych sprawozdań oraz raportów do formatów używanych przez MS Office oraz.pdf System musi umożliwiać pracę z kodami kreskowymi (w przypadku środków trwałych) System musi umożliwiać gromadzenie danych archiwalnych oraz historii dokonanych zmian System musi umożliwiać walidację danych wprowadzonych do Systemu przez użytkownika. Zakres danych podlegających walidacji oraz zakres walidacji do określenia na etapie analizy przedwdrożeniowej np. wymagana walidacja pola NIP, numer rachunku bankowego (dublowanie, ilość znaków) W Systemie muszą być zdefiniowane pola obowiązkowe do wypełnienia/uzupełnienia (ręcznie lub automatycznie). Brak wypełnienia pola wstrzymuje proces W Systemie muszą być zdefiniowane pola, których brak uzupełnienia będzie komunikowane przez System. Brak wypełnienia pola nie wstrzymuje procesu System musi pozwalać na elastyczne wyszukiwanie danych w całym Systemie z uwzględnieniem ewidencji bilansowej oraz pozabilansowej z wykorzystaniem kont księgowych oraz równolegle do powyższych ewidencji, ewidencję pozabilansową w układzie (z wykorzystaniem) klasyfikatorów, w szczególności według danych kontrahenta, według kwot (zakres, wartość bezwzględna), według zakresu dat, według numeru pozycji księgowej itp. System musi umożliwiać zapisanie ustawień okna operacyjnego zdefiniowanych oddzielnie przez każdego użytkownika. System musi zapamiętywać indywidualne ustawienia i nie może ich zmienić przy aktualizacji Systemu System musi umożliwiać uruchamianie wielu wątków (okien operacyjnych) dla jednego użytkownika. System musi umożliwiać uruchamianie równocześnie wielokrotnej liczby dokumentów przez jednego użytkownika. System nie może pozwalać na uruchomienie jednego dokumentu przez wielu użytkowników

17 FO-19 FO-20 FO-21 FO-22 FO-23 FO-24 FO-25 FO-26 FO-27 FO-28 FO-29 FO-30 FO-31 FO-32 FO-33 FO-34 FO-35 FO-36 FO-37 System może umożliwiać zdefiniowanie przez użytkownika skrótów (np. klawiaturowych np. F1, F2 ) do szybszego dostępu do danego zbioru danych. System może umożliwiać dołączanie do każdego dokumentu podlegającego zaksięgowaniu, dodatkowego opisu lub komentarza w formie notatki System może pozwolić na zdefiniowanie/opisanie dokumentów podlegających księgowaniu dodatkowymi atrybutami/ znacznikami z uwzględnieniem, których użytkownik będzie mógł sporządzać raporty/zestawienia/analizy System musi zapewnić każdemu użytkownikowi podgląd danego dokumentu w procesie jego ewidencji System musi umożliwiać elastyczne definiowanie rodzajów, a w ramach rodzajów typów dokumentów w poszczególnych rejestrach System musi zapewnić opisywanie danych w rejestrach z wykorzystaniem atrybutów Każdy dokument wpisany do rejestru musi posiadać numer systemowy. Numer systemowy jest to numer nadawany przez System od 1 do n dla każdego rodzaju dokumentu w danym rejestrze z uwzględnieniem roku kalendarzowego. Każdy dokument wpisany do rejestru musi posiadać numer dokumentu. System musi pozwalać na wprowadzenie dowolnej struktury (maski) numeru. Przyjęta struktura numeru w ramach poszczególnych rodzajach dokumentów nie może podlegać modyfikacji przez użytkownika (w trakcie roku budżetowego). System automatycznie musi sugerować numer dokumentów, jako numer systemowy, o ile dla danego numeru dokumentu System nie wymusza zadanej struktury numeru np. struktura numeru umowy POIiS. W rejestrze umów dla rodzaju umów programowe System musi wymuszać strukturę numeru dokumentu zgodną ze strukturą POIiŚ w KSI W rejestrze dokumentów źródłowych dla typu dokumentu wniosek o płatność System musi wymuszać strukturę numeru dokumentu zgodną ze strukturą POIiŚ w KSI. System musi komunikować zdublowanie numeru dokumentu. Prezentacja każdego rejestru w Systemie musi odbywać się za pomocą okna operacyjnego. Prezentacja danych z rejestru w oknie operacyjnym musi być definiowana oddzielnie przez każdego użytkownika w oparciu o dane wprowadzone do rejestru. Dodatkowo okno operacyjne musi mieć możliwość prezentowania danych jako wynik danych arytmetycznych wprowadzonych do rejestru. System musi zapamiętywać indywidualne ustawienia użytkownika System musi umożliwiać sortowanie, filtrowanie i wyszukiwanie według wszystkich wprowadzonych do rejestru danych, w tym według dowolnego ciągu znaków. System musi posiadać funkcjonalność śladowania zmian. Śladowanie musi prezentować: a. treści przed zmianą i treść po zmianie, b. metrykę zmian, tj. użytkownik dokonujący zmiany (imię i nazwisko - login), data i godzina dokonania zmiany. Śladowanie musi obejmować wybrane pola w rejestrach System musi generować wydruki z rejestrów Zakres danych do wydruków musi być definiowany przez użytkownika NSI Wydruk danych z rejestru oprócz danych merytorycznych musi zawierać: a. Nazwę (pełną lub skrócona Zamawiającego), nazwę danego rodzaju rejestru oraz nazwę programu przetwarzania, b. Wyraźne oznaczenie co do roku obrotowego okresu za jaki sporządzony jest wydruk, c. liczbą porządkową pozycji na wydruku, d. metrykę wydruku, tj. użytkownik dokonujący wydruku (imię i nazwisko - login), data i godzina dokonania wydruku, e. parametry wydruku zastosowane przez użytkownika.

18 III. Opis funkcjonalności NSI wymagania szczegółowe Rejestr Kontrahentów System w zakresie opisywanego rejestru musi zapewniać co najmniej poniższe funkcjonalności dodatkowe: Kod FRK-01 FRK-02 FRK-03 FRK-04 FRK-05 FRK-06 FRK-07 FRK-08 FRK-09 FRK-10 FRK-11 FRK-12 Opis wymagania funkcjonalnego System musi umożliwiać prowadzenie rejestru kontrahentów. Rejestr kontrahentów musi stanowić jedną bazę w Systemie. Wszystkie dane osobowe rejestru kontrahentów muszą być gromadzone, przetwarzane i przechowywane zgodnie z ustawą o ochronie danych osobowych. System musi automatycznie weryfikować wprowadzone dane tak, aby nie nastąpiło ponowne wprowadzenie danych tego samego kontrahenta. System musi pozwalać na określenie i wybór rodzaju relacji kontrahenta w stosunku do CUPT, w tym w szczególności: a. beneficjent, b. kontrahent, c. pracownik (relacja pracownik jest nazwą umowną zawierającą w szczególności osoby fizyczne, z którymi CUPT zawarł umowę o pracę, umowę zlecenie, umowę o dzieło lub inną umowę cywilnoprawną). Powyższy wybór relacji kontrahenta musi następować z listy słownikowej. System musi zapewnić opisywanie danych w rejestrach z wykorzystaniem atrybutów. System musi pozwolić na elastyczne definiowanie wielu grup. Za grupę należy rozumieć zbiór atrybutów, którymi może zostać opisany kontrahent/beneficjent/pracownik w rejestrze kontrahentów: a. przykładowe grupy: Grupa RB ; Grupa ekspert b. przykładowy zbiór atrybutów Grupy RB : Grupa I, Grupa II, Grupa III, Grupa IV, przedsiębiorstwa niefinansowe, gospodarstwa domowe, Grupy ekspert : TAK, NIE. System musi automatycznie bądź przez ingerencję użytkownika poprzez wybór z listy słownikowej nadawać i zmieniać status kontrahenta/beneficjenta/pracownika. Przykładowe statusy obejmują: a. aktywny, b. nieaktywny. Rejestr kontrahentów w zakresie danych niezbędnych do sporządzenia przelewu/zlecenia płatności (skrócona nazwa i adres) musi uwzględniać format pól wymagany w Systemach bankowości elektronicznej i internetowej wykorzystywanych przez jednostkę. System domyślnie oznacza adres siedziby/adres zameldowania jako właściwy adres do dokonania przelewu/zlecenia płatności z możliwością zmiany przez użytkownika w Rejestrze kontrahentów. System musi umożliwiać przypisanie do rodzaju relacji kontrahenta w stosunku do CUPT jednego lub kilku rozrachunkowych kont syntetycznych jako wskazanie do tworzenia konta analitycznych. W rejestrze musi być odwzorowana zależność dotycząca danych: do jednego kontrahenta można przypisać wiele rachunków bankowych. Numer rachunku bankowego bez względu na format wpisania danych Systemu

19 FRK-13 FRK-14 FRK-15 FRK-16 FRK-17 musi być prezentowany w formacie wymaganym dla rachunku bankowego (z separatorami). System musi kontrolować poprawność wprowadzanego numeru bankowego oraz sygnalizować istnienie w Systemie już takiego numeru rachunku bankowego. System musi pozwalać na wprowadzenie okresu (zakresu dat) obowiązywania poszczególnych rachunków bankowych dla danego kontrahenta. System musi pozwolić na łączenie kartotek kontrahentów, w tym w szczególności kartotek pracowniczych. System musi umożliwiać z poziomu Rejestru kontrahentów wgląd/wydruk historii i stanu rozrachunków na dzień wybrany przez użytkownika, w układzie ewidencji bilansowej, pozabilansowej, w tym również w układzie klasyfikatorów. System musi automatycznie weryfikować wprowadzone dane tak, aby nie nastąpiło ponowne wprowadzenie danych tego samego kontrahenta. Rejestr Kontrahenta w zakresie kadrowo-płacowym Ewidencja struktury organizacyjnej oraz struktury zatrudnienia System musi umożliwiać prowadzenie ewidencji kadrowo-płacowej zgodnie z przepisami prawnymi i organizacją wewnętrzną CUPT. W ramach struktury organizacyjnej można wyodrębnić: Dyrektora CUPT, Departamenty, Biura, Wydziały, samodzielne stanowiska, Zespoły. Struktura organizacyjna jest zmienna i jest ustalana przez regulamin organizacyjny. Podział pracowników wg struktury organizacyjnej wykorzystywany jest do tworzenia typowych raportów, ewidencjonowania wydatków i sporządzania dokumentów kadrowo płacowych. FRKP-01 System musi umożliwiać stworzenie wykazu stanowisk przypisanych do struktury organizacyjnej. System musi umożliwiać przeprowadzenie zmian w strukturze organizacyjnej przez użytkownika: a. zmiana podporządkowania komórki organizacyjnej, b. zmiana symbolu i/lub nazwy komórki organizacyjnej, c. utworzenie/zamknięcie komórki organizacyjnej, d. łączenie/dzielenie komórek organizacyjnych. System musi gromadzić informacje dotyczące struktury organizacyjnej FRKP-02 w historii zatrudnienia. System może wersjonować strukturę organizacyjną historia zmian. System musi zapewnić ewidencję pracowników w ramach wielostopniowej FRKP-03 struktury organizacyjnej. Ewidencja podstawowych danych osobowych pracownika zawartych w kwestionariuszu osobowym System musi zapewnić gromadzenie historii zmian związanych z zatrudnieniem: FRKP-04 informacja oraz okres obowiązywania danej informacji kadrowej. Ewidencja musi zapewnić właściwy sposób gromadzenia danych pracowników, w tym także w formie telepracy osób współpracujących na podstawie umów cywilno-prawnych z uwzględnieniem specyfiki danych dla każdej grupy. FRKP-05 Ewidencja danych kadrowych musi odbywać się w oparciu o maksymalne wykorzystanie wbudowanych słowników kadrowych (np. kody ZUS, klasyfikacja zawodów GUS i inne). System musi umożliwiać prowadzenie kartoteki osobowej, która powinna zawierać szeroko pojęte dane zgodne z obowiązującymi przepisami prawa: FRKP-06 osobowe (identyfikacyjne), zawodowe, o rodzinie i uzupełniające, wykształcenie, kierunek, specjalność, tytuły naukowe, wykształcenie uzupełniające, nazwa ukończonej szkoły, data ukończenia szkoły, posiadane uprawnienia zawodowe,

20 poziom znajomości języków obcych, posiadane certyfikaty językowe, doświadczenie w pracy z funduszami Unii Europejskiej przed zatrudnieniem w CUPT, itd. w tym również informacje specyficzne dla CUPT np. ocechowanie pracownika w celu utajnienia danych osobowych (kod) wykorzystywany do zestawień np. do Wniosku o Płatność w ramach Pomocy Technicznej. Nadawany automatycznie, w sposób losowy bez zachowania kolejności wpisu, unikalny. Na etapie migracji należy uwzględnić wprowadzenie stosowanych dotychczas kodów. System musi umożliwić dodanie dowolnej ilości danych w ramach każdego zestawu danych: dane teleadresowe (adres zameldowania, zamieszkania, do korespondencji), dane dotyczące miejsca w strukturze organizacyjnej, atrybuty pracownika, dane o członkach rodziny pracownika, dane dotyczące wykształcenia pracownika, dane dotyczące wykształcenia uzupełniającego, dane dotyczące znajomości języków UE, dane dotyczące znajomości języków obcych, dane dotyczące stażu pracy pracownika, dane o przysługujących nagrodach jubileuszowych, dane dotyczące badań z zakresu medycyny pracy, dane dotyczące informacji o refundacjach za okulary, dane dotyczące informacji o szkoleniach BHP, dane dotyczące funduszu zdrowia, dane dotyczące rozliczań z US, potrącenia komornicze, potracenia inne, dane płacowe z innych miejsc pracy, atrybuty kadrowe pracownika. System musi w maksymalnie wykorzystywać listy słownikowe lub bazy (np. urzędów skarbowych), w ramach każdego zestawu danych, kontrolować limity. Baza urzędów skarbowych musi być dostarczona i aktualizowana. System musi automatycznie weryfikować zgodność wprowadzanych danych: FRKP-07 formaty i poprawność PESEL, NIP, numer konta bankowego. System musi umożliwić wybór adresu do przelewu bankowego, do PIT, FRKP-08 do innych np. zaświadczeń, umów o pracę itp. System musi umożliwić oznaczenie ułatwiające odróżnienie osób o zbliżonych FRKP-09 danych (np. dwóch pracowników o tym samym lub podobnym nazwisku) flagowanie rekordów Ewidencja historii zatrudnienia pracownika w poprzednich zakładach pracy oraz w CUPT System musi automatycznie obliczać i wykorzystywać staż pracy pracownika (na podstawie zdefiniowanych zasad zaliczania wykształcenia, okresów zatrudnienia i umów z uwzględnieniem okresów nakładających się), przysługujące wymiary FRKP-10 urlopów, dodatków zależnych od stażu pracy (dodatek stażowy). System musi dostarczać informacje o stażu pracy do urlopu wypoczynkowego, ogólnego stażu pracy, okresu pracy dla celów ustalenia okresów wypowiedzenia, dla celów ustalenia prawa do nagrody jubileuszowej, dodatków stażowych. Ewidencja szkoleń BHP System musi umożliwiać definiowanie rodzaju szkoleń BHP, w zależności od zajmowanego przez pracownika stanowiska, terminach FRKP-11 ich przeprowadzania oraz warunków BHP dla stanowiska, określanie warunków BHP dla zatrudnianego pracownika: wymagane szkolenia. System musi przypominać o kończących się terminach szkoleń BHP. Ewidencja nieobecności i zwolnień od pracy System musi zapewniać ewidencję nieobecności w dniach i godzinach pracy oraz umożliwiać definiowanie różnych rodzajów nieobecności, limitowanych (np. urlopy) lub nie limitowanych (urlop bezpłatny, okolicznościowy). Dodatkowo musi grupować rodzaje nieobecności w kategorie dla celów zestawień, obliczeń, FRKP-12 kontroli i sprawozdań oraz rejestrować dane o nieobecności. W przypadku dokumentów (ZUS ZLA), okresie, dacie dostarczenia dokumentu, jak również pobierać i nanosić dane z Rejestru Delegacji i Rejestru Szkoleń Automatyczne wyliczanie dni kalendarzowych lub roboczych