Administracja | Szkoła Główna Handlowa w Warszawie€¦ · Web viewWarunek konieczny Spełniony: Tak/Nie 173. Definiowanie przekierowania środków (przepływów finansowych)

załącznik nr 1 do SIWZ

Zakup i wdrożenie Systemu do planowania i zarządzania finansami uczelni oraz wykonanie integracji z Zintegrowanym Systemem Informatycznym klasy ERP w Szkole Głównej Handlowej w Warszawie.

Opis Przedmiotu Zamówienia

Spis treściWymagania ogólne......................................................................................................................................................................................................................... 4

Wymagania odnośnie licencjonowania systemu........................................................................................................................................................................5

Wymagania techniczne.............................................................................................................................................................................................................. 6

Wymagania w zakresie wsparcia interfejsu i wersji językowej...................................................................................................................................................9

Wymagania w zakresie uwierzytelniania i uprawnień..............................................................................................................................................................11

Wymagania odnośnie monitorowania systemu.......................................................................................................................................................................12

Wymagania w zakresie filtrowania i raportowania danych......................................................................................................................................................13

Wymagania systemu komunikacji i standardów wymiany danych...........................................................................................................................................15

Kopie bezpieczeństwa, archiwizacja danych............................................................................................................................................................................16

Wymagania w zakresie środowiska programistycznego...........................................................................................................................................................17

Projekt współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Społecznego1

Wymagania w zakresie wydajności systemu............................................................................................................................................................................17

Planowanie i zarządzanie finansami............................................................................................................................................................................................. 18

Projekty.................................................................................................................................................................................................................................... 18

Budżety..................................................................................................................................................................................................................................... 19

Blokowanie środków................................................................................................................................................................................................................ 23

Struktura organizacyjna............................................................................................................................................................................................................ 25

Budżety walutowe.................................................................................................................................................................................................................... 26

Przepływy budżetowe.............................................................................................................................................................................................................. 28

Dokumenty............................................................................................................................................................................................................................... 29

Kartoteki................................................................................................................................................................................................................................... 30

Koszty pośrednie...................................................................................................................................................................................................................... 31

Komentarze i załączone dokumenty.........................................................................................................................................................................................32

Budżety zagregowane.............................................................................................................................................................................................................. 33

Planowanie............................................................................................................................................................................................................................... 36

Dokumenty centralne............................................................................................................................................................................................................... 38

Raportowanie........................................................................................................................................................................................................................... 40

Wymagania w zakresie integracji................................................................................................................................................................................................. 42

Wymagania w zakresie migracji danych.......................................................................................................................................................................................48

Wymagania w zakresie zgodności z przepisami prawa.................................................................................................................................................................49


Wymagania w zakresie zgodności z aktami wewnętrznymi SGH..................................................................................................................................................57

Zasady przeprowadzania testów Systemu....................................................................................................................................................................................64

Wymagania w zakresie Dokumentacji projektowej......................................................................................................................................................................67

Elementy Platformy Sprzętowej................................................................................................................................................................................................... 70


Oferowany System na dzień składania ofert musi spełniać minimum 80% warunków koniecznych. Potwierdzenie warunku koniecznego należy wykonać poprzez zaznaczenie „Tak” lub skreślenie „Nie”.

Warunek oceniany ma wpływ na kryterium oceny „Funkcjonalność”. Potwierdzenie warunku ocenianego należy wykonać poprzez zaznaczenie „Tak” lub skreślenie „Nie”.

Wymagania ogólne

L.p.(1)

Wymaganie(2)

Status wymagania(3)

1. Dostarczony System musi istnieć w podanej funkcjonalności i być dostosowany do wymagań funkcjonalnych i potrzeb opisanych przez Zamawiającego.

Warunek koniecznySpełniony: Tak/Nie

Należy podać nazwę producenta oraz

nazwę oferowanego systemu i wersję

2. Dostarczone Oprogramowanie Standardowe ma działać w ostatniej, aktualnej wersji opublikowanej przez Warunek konieczny


Producenta. Spełniony: Tak/Nie3. System wspiera wszystkie obszary funkcjonalne uwzględnione w niniejszej SIWZ i uszczegółowione w

Specyfikacji Funkcjonalnej.Warunek koniecznySpełniony: Tak/Nie

4. System i wszystkie jego moduły są ze sobą zintegrowane w ramach jednego systemu informatycznego co jest rozumiane jako automatyczną wymianę i współdzielenie informacji (kartoteki, rejestry, słowniki, wprowadzone dokumenty, operacje, inne) tworzonych w różnych modułach. Zasilenie systemu ma mieć jedno źródło danych i być udostępniane innym funkcjonalnościom i modułom.


5. System zgodny z aktami prawnymi obowiązującymi w państwowej szkole wyższej. Warunek koniecznySpełniony: Tak/Nie

6. System musi zapewniać przechowywanie historii danych wprowadzanych do systemu wraz z informację jak dana wyglądała w określonym przedziale czasowym.


Wymagania odnośnie licencjonowania systemu7. Wykonawca udzieli Zamawiającemu licencji lub zapewni udzielenie licencji i przeniesie autorskie prawa

majątkowe na warunkach opisanych w umowie.Warunek koniecznySpełniony: Tak/Nie

8. System licencjonowania na jednoczesnych pojedynczych użytkowników lub/i nazwanych z podziałem na role w systemie.


9. Licencja dostępowa ma zapewniać dostęp do wszystkich modułów Systemu. Warunek koniecznySpełniony: Tak/Nie

10. Licencja ma umożliwiać instalację i uruchomienie środowiska produkcyjnego i testowego. Warunek koniecznySpełniony: Tak/Nie


11. Udzielona licencja nie ogranicza tworzenia ilości danych w systemie (np. ilości kartotek pracowniczych, danych słownikowych, danych kontrahentów, dokumentów finansowych itp.).


12. Licencja nie może zawierać ograniczeń, w myśl których z Oprogramowania będzie mogło korzystać mniej użytkowników, aniżeli wskazano poniżej:

a) System – 50 użytkownikówb) Portal internetowy – 400 użytkowników


Wymagania techniczne13. Wykorzystywany przez System serwer aplikacji powinien działać na 64-bitowym systemie operacyjnym (min.

posiadany przez Zamawiającego MS Windows Server 2008 Enterprise). Warunek koniecznySpełniony: Tak/Nie

14. Licencja umożliwia uruchomienie min. 1-3 serwerów aplikacyjnych w celu zrównoważenia np. obciążenia. Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

15. System musi działać w oparciu o posiadany przez Zamawiającego Systemie Zarządzania Bazami Danych Microsoft SQL 2008 Enterprise oraz wykorzystywać standardowe mechanizmy Systemu.


16. System działa w architekturze wielowarstwowej – dwu lub trzy warstwowej. Warunek koniecznySpełniony: Tak/Nie

17. System musi pracować w oparciu o sieć komputerową z protokołem TCP/IP w wersji 4. Warunek koniecznySpełniony: Tak/Nie


18. System może pracować w oparciu o sieć komputerową z protokołem TCP/IP w wersji 6. Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

19. System pracujący w środowisku sieciowym i „wielo – użytkownikowym”, w którym wielu użytkowników równocześnie korzysta z Systemu w trybie on-line.


20. System musi dać się instalować na dyskach lokalnych serwera, a także zewnętrznych, podłączonych przez protokoły/złącza iSCSI, FC, SAS, NFS.


21. Aplikacja kliencka powinna działać na min. 5 z wymienionych systemach operacyjnych:• MS Windows XP min. Professional - wszystkie wersje 32 bitowe,• MS Windows Vista min. Professional - wszystkie wersje 32 i 64 bitowe,• MS Windows 7 min. Professional - wszystkie wersje 32 i 64 bitowe.• MS Windows 8 min. Professional - wszystkie wersje 32 i 64 bitowe.


22. System musi wspierać rozwiązania klastrowe. Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

23. System w pełni skalowalny, a więc pozwala na migrację do wydajniejszych i nowszych wersji baz danych lub nowszej wersji systemu operacyjnego oraz możliwość przeniesienia na nowocześniejszy bardziej wydajny sprzęt.



24. System pozwala na uruchomienie wielu wątków aplikacji klienckiej w tym umożliwia aktywną pracę na dużej ilości otwartych okien.


25. System musi obsługiwać drukarki przy stacjach PC, serwerach, sieciowe z własną kartą sieciową i udostępnione przez inne komputery; igłowe, laserowe i atramentowe oraz w formatach do A3 włącznie.


26. Część transakcyjna Systemu pracuje w trybie on-line i zapewnia ciągły dostęp do aktualnych danych. Warunek koniecznySpełniony: Tak/Nie

27. Aktualizacja informacji w bazach danych odbywa się w natychmiast po operacji lub po zebraniu paczki operacji, stosownie do charakteru operacji.


28. Aplikacja kliencka powinna działać na stacji roboczej z zainstalowanym oprogramowaniem antywirusowym oraz pakietem MS Office w wersji min. 2007, 2010, 2013 będącym w posiadaniu przez Zamawiającego.


29. System pozwala na równoczesne korzystanie z innych aplikacji biurowych takich jak poczta elektroniczna, przeglądarka, programy biurowe i inne aplikacje działające w systemie operacyjnym na stacji roboczej użytkownika.


30. Połączenia i wymiana danych pomiędzy poszczególnymi warstwami Systemu jest kodowana/szyfrowana. W szczególności dotyczy to komunikacji systemu z aplikacją kliencką (stacją roboczą użytkownika).


31. System powinien być wyposażony w mechanizmy i narzędzia wspierające przenoszenie zmian konfiguracyjnych pomiędzy środowiskami.

Warunek oceniany

Tak – 1 pkt


Nie – 0 pkt

32. System umożliwia automatyczne kasowanie lub automatyczną zmianę wrażliwych danych (np. PESEL, imię nazwisko lub inna dowolna cecha ewidencjonowana w Systemie) np. podczas kopiowania danych ze środowiska produkcyjnego do testowego, gdzie dostęp do danych (osobowe, finansowe) mogą posiadać osoby nie uprawnione.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

33. System posiada mechanizmy automatyzacji stałych czynności (odpowiednik CRON-a z systemu UNIX, lub Tasków z Windows) pozwalający na zautomatyzowanie zdefiniowanych czynności przez użytkownika.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

Wymagania w zakresie wsparcia interfejsu i wersji językowej34. Realizacja funkcji Systemu poprzez aplikację kliencką oraz w zakresie Portalu internetowego poprzez interfejs

www.Warunek koniecznySpełniony: Tak/Nie

35. System i wszystkie jego moduły muszą być w języku polskim i zapewniać poprawne wyświetlanie i przetwarzanie polskich znaków diakrytycznych na poziomie interfejsu użytkownika jak i baz danych. Wszystkie interfejsy systemu na potrzeby integracji powinny używać kodowania UTF8 lub UTF16 do przesyłania/odbierania danych z/do systemu.


36. System i wszystkie jego moduły wyposażony w graficzny i ergonomiczny interfejs użytkownika sterowany za pomocą myszy i klawiatury, gwarantujący wygodne wprowadzanie danych.



37. System w całości spolonizowany w zakresie obsługi polskich znaków - dotyczy: aplikacji klienckiej oraz Portalu internetowego, dokumentacji, pomocy z poziomu Systemu, instrukcji obsługi, materiałów szkoleniowych.


38. System pozwala użytkownikowi w sposób elastyczny definiować wygląd aplikacji w tym układ menu oraz wzajemnego rozmieszczenia poszczególnych informacji, wielkość ikon, wielkość czcionki.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

39. Portal internetowy jest wielojęzyczny, tj. umożliwia wgranie/uruchomienie pakietów językowych (min. język angielski) i po wybraniu języka komunikacji w trakcie logowania do systemu, etykiety pól muszą być widoczne w wybranym języku.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

40. Możliwość wywoływania funkcji Systemu poprzez predefiniowane skróty klawiszowe. Warunek koniecznySpełniony: Tak/Nie

41. Pomoc kontekstowa do poszczególnych funkcji Systemu. Warunek koniecznySpełniony: Tak/Nie

42. Możliwość personalizacji formularzy Systemu poprawiającej ergonomię pracy z aplikacją - personalizacja formularzy powinna obejmować między innymi: zmianę etykiet, ukrywanie pól, położenia pól, kolejności nawigacji pomiędzy polami, zmiana układu formularzy, nawigacji między formularzami, modyfikacja zawartości menu - ukrywanie lub dodawanie opcji menu. Zmiany te powinny być możliwe do zrealizowania przez użytkownika końcowego nie posiadającego uprawnień administratora lub developera.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt


43. System posiada wbudowane słowniki wewnętrzne z możliwością ich rozbudowy przez użytkownika posiadającego odpowiednie uprawnienia.


44. Każde okno Systemu musi być opisane w sposób czytelny i by identyfikacja wykonywanej czynności nie budziła wątpliwości. Szczegóły nazewnictwa poszczególnych okien zostaną ustalone podczas wdrożenia.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

45. Udogodnienia dla osób niepełnosprawnych, np. powiększanie czcionki lub modyfikacja koloru na ekranie dla osób z wadami wzroku.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

Wymagania w zakresie uwierzytelniania i uprawnień46. Zintegrowany sposób autoryzacji do systemu przez konta w Active Directory z funkcją jednokrotnego

logowania (Single Sign On).Warunek koniecznySpełniony: Tak/Nie

47. System jednoznacznie identyfikuje użytkowników poprzez unikalny login i hasło. Warunek koniecznySpełniony: Tak/Nie

48. Przejście z jednego modułu do innego odbywa się bez konieczności ponownego logowania. Warunek koniecznySpełniony: Tak/Nie


49. Możliwość elastycznego konfigurowania uprawnień użytkowników oraz utworzonych grup użytkowników do obszarów danych i funkcjonalności systemu.


50. Mechanizm nadawania wielopoziomowych uprawnień (pełny dostęp, zapis, odczyt) do pojedynczych funkcji i pól systemu.


51. System pozwala w sposób dowolny tworzyć role dla użytkowników. Rola jest rozumiana jako grupa uprawnień, które użytkownik posiada w Systemie. Uprawnienia jako takie określają zakres dostępnych funkcjonalności, oraz dostępu do danych w tym prawa czytania, tworzenia, zmiany i kasowania danych.


52. System powinien umożliwiać grupowe nadawanie użytkownikom, posiadającym już uprawnienia w systemie, dodatkowych uprawnień, np. grupując ich po przynależności do jednostki organizacyjnej.


Wymagania odnośnie monitorowania systemu53. System wyposażony w mechanizm logowania zdarzeń pozwalający w sposób jednoznaczny zidentyfikować

użytkownika, który w określonym czasie (dzień, miesiąc, rok, godzina, minuta, sekunda) dokonał modyfikacji danych. Możliwość zidentyfikowania autora każdej zmiany wprowadzonej w systemie, możliwość dokonania identyfikacji z poziomu konkretnej operacji. Logowanie zmian danych (z wyłączeniem logowania zmian plików, załączników i innych pól binarnych).


54. System posiada wbudowane mechanizmy kontroli spójności i poprawności wprowadzanych danych w tym również wymuszanie pól obowiązkowych. System wyświetla komunikaty o nieprawidłowościach w procesie wprowadzania i przetwarzania danych w Systemie. Wykonawca prezentując funkcjonalność podczas wdrożenia przedstawi propozycję walidacji pól, która zostanie ustalona ostatecznie z Zamawiającym.



55. Możliwość definiowania obszarów, w stosunku do których System będzie wyświetlał komunikaty informujące o osiągnięciu wartości uznanych za krytyczne np.: wykorzystanie budżetu na dane zadanie na poziomie 90 procent.


Wymagania w zakresie filtrowania i raportowania danych

56. System posiada jednolity interfejs w zakresie wyszukiwania, grupowania i filtrowania informacji w całym Systemie w tym również dotyczy to sortowania według wybranych kolumn lub innych danych.


57. Użytkownik może konstruować własne filtry do prezentacji wybranych w ten sposób danych w oknach i listach aplikacji.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

58. System pozwala na grupowanie raportów i dokumentów, np. grupowanie dokumentów finansowych, dokumentów inicjujących.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

59. System posiada wbudowane standardowe raporty i szablony dokumentów. Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt


60. System musi posiadać możliwość drukowania zdefiniowanych wydruków i możliwość definiowania własnych wydruków za pomocą przyjaznych użytkownikowi narzędzi. Taka możliwość powinna być dostępna dla uprawnionych użytkowników.


61. System umożliwia definiowanie szablonu raportu za pomocą pakietów biurowych posiadanych przez Zamawiającego, (np. MS Office) bez konieczności używania innych aplikacji.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

62. System pozwala na modyfikowanie istniejących lub tworzenie na bazie wbudowanych nowych raportów i szablonów dokumentów przez użytkownika posiadającego odpowiednie do tego uprawnienia.


63. Tworzenie, modyfikowanie raportów i szablonów dokumentów w oparciu o graficzny interfejs użytkownika. Warunek koniecznySpełniony: Tak/Nie

64. System umożliwia udostępnienie utworzonych/zmodyfikowanych raportów i szablonów dokumentów innym użytkownikom Systemu.


65. Możliwość uruchamiania raportów i procesów w tle, bez konieczności oczekiwania na ich zakończenie – użytkownik zleca Systemowi określone zadanie np. wygenerowanie raportu i może w tym czasie wykonywać inną pracę.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

66. Wyniki raportów powinny być automatycznie zapisywane na serwerze i możliwe do podejrzenia i Warunek oceniany


wydrukowania w późniejszym czasie. Tak – 1 pkt

Nie – 0 pkt

67. System powinien umożliwiać określenie czasu przechowywania wyniku raportu na serwerze i automatycznie usuwać wydruki przeterminowane.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

68. Możliwość załączania zeskanowanych dokumentów do Systemu w powiązaniu z odpowiednią ewidencją zdarzenia w Systemie.


69. Możliwość przechowywania skanowanych dokumentów w osobnej bazie danych dedykowanej tylko przechowywaniu dokumentów.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

Wymagania systemu komunikacji i standardów wymiany danych

70. System musi mieć możliwość importu i eksportu danych w konfigurowalnym formacie (np. excel, csv, xml, txt).


71. Do Systemu powinna być dostępna dokumentacja techniczna producenta Systemu – opis tabel, pakietów, interfejsów API, interfejsów wymiany danych.

Warunek oceniany

Tak – 1 pkt


Nie – 0 pkt

72. Obsługa usług sieciowych (Web Services). Warunek koniecznySpełniony: Tak/Nie

73. Aplikacja kliencka pozwala w prosty sposób przenosić wszelkich zestawienia, opracowania, sprawozdania, raporty itp. do aplikacji biurowych posiadanych przez Zamawiającego (min. z pakietu MS Office w wersji 2007 i nowszych). Eksportowanie generowanych w Systemie raportów, sprawozdań, dokumentów do popularnych formatów typu xls, pdf, rtf itp.


74. Zarządzanie procesami Systemu poprzez mechanizm typu workflow. Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

75. Informowanie użytkowników lub grup użytkowników o zdarzeniach, oczekujących w kolejce do realizacji działaniach. Informacja powinna być dostępna po zalogowaniu do Systemu z opcją przekazywania poprzez e-mail.

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

Kopie bezpieczeństwa, archiwizacja danych76. System musi posiadać funkcjonalność wykonywania pełnych i cząstkowych backupów. Warunek konieczny

Spełniony: Tak/Nie


77. System musi umożliwiać wykonywanie backupu bez przerywania jego pracy (on-line). Warunek koniecznySpełniony: Tak/Nie

78. System posiada możliwość rozdzielania danych archiwalnych od aktualnych. Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt

Wymagania w zakresie środowiska programistycznego79. Otwartość na integrację z innymi aplikacjami umożliwiająca dalszy rozwój - tabele Systemu zawierające dane

biznesowe muszą być dostępne z poziomu bazy danych dla aplikacji, które zostaną uruchomione w przyszłości, aplikacja musi posiadać interfejs programistyczny API obsługujący dodatkowe informacje zdefiniowane w czasie wdrożenia Systemu.


80. System musi umożliwiać stworzenie i konfigurację środowiska testowego (min. 1 ) bez konieczności wykupywania dodatkowych licencji.


Wymagania w zakresie wydajności systemu81. Czas odpowiedzi Systemu na podstawowe polecenia zmiany ekranu (np. wyświetlenie dokumentu

finansowego, wyświetlenie blokady, wyświetlenie realizacji) nie przekroczy 20 sekund.Warunek koniecznySpełniony: Tak/Nie

82. Czas wykonania zapisu np. wielopozycyjnych budżetów, symulacji lub jednoczesnej modyfikacji wielu transakcji nie przekroczy 40 minut.



83. Czas wykonania przekrojowego raportu nie przekroczy 4 godzin. Warunek koniecznySpełniony: Tak/Nie


Planowanie i zarządzanie finansamiProjekty

87. Możliwość tworzenia w Systemie projektów zakładających realizację dowolnej liczby budżetów. Warunek konieczny Spełniony: Tak/Nie

88. Możliwość łatwego przepinania budżetów pomiędzy projektami. Warunek konieczny Spełniony: Tak/Nie

89. Możliwość tworzenia kartotek projektów zawierających swobodnie definiowalny szablon informacji m.in.: o jednostce odpowiedzialnej za dany projekt, nazwie projektu, okresie realizacji projektu, osobie do kontaktu.

Warunek konieczny Spełniony: Tak/Nie

90. Możliwość powiązania projektu z operatorem Systemu lub grupą operatorów Systemu. Warunek konieczny Spełniony: Tak/Nie

91.Możliwość przypisywania do projektu osób będących dysponentami, mających podgląd lub pełniących inną rolę z kartoteki osób w strukturze organizacyjnej Uczelni. Taka osoba i jej rola powinna dotyczyć wszystkich budżetów w ramach projektu. Przypisywanie powinno respektować pełnomocnictwa.


92. Możliwość nadawania alfanumerycznych, minimum 20 znakowych unikalnych kodów projektów. Warunek konieczny Spełniony: Tak/Nie

93. Możliwość dodawania do projektów budżetów w różnych walutach. Warunek konieczny Spełniony: Tak/Nie

94. Możliwość tworzenia budżetów dla dowolnych okresów, również okresów zachodzących na siebie w ramach jednego projektu.



95. Możliwość umieszczenie w ramach jednego projektu (w grupie budżetów) budżetów o różnej strukturze i dla różnych okresów oraz różnych walutach.


96. System musi posiadać kartotekę (słownik) funkcji pełnionych w projektach uzupełnianą przez uprawnionego użytkownika.


97. Możliwość automatycznego nadawanie kodów budżetom w ramach jednej grupy budżetów (w projekcie) w zależności od okresu budżetu oraz początku i końca grupy budżetów. Kod budżetu musi być unikalny.


Budżety

98.

Prezentacja budżetu i poszczególnych pozycji budżetowych musi być trzystopniowa (pierwszy stopień - budżet pierwotny, wprowadzony przez użytkownika, uwzględniający pozycje sumujące, naliczanie kosztów pośrednich; drugi stopień - przepływy budżetowe - zwiększenia i zmniejszenia budżetu wynikające z otrzymania lub przekazania części środków od / do dyspozycji innym dysponentom; trzeci stopień - budżet do dyspozycji - uwzględniający zmniejszenia / zwiększenia budżetu pierwotnego poprzez przepływy budżetowe).


99.Definiowanie różnych typów szablonów budżetowych o różnych poziomach szczegółowości, opisujących koszty i przychody w różnych aspektach (np.: wg rodzaju kosztu, wg zadań). System musi obsługiwać budżety w strukturze dwuwymiarowej.


100. Możliwość przypisywania do budżetu osób będących dysponentami, mających podgląd lub pełniących inną rolę, z kartoteki osób w strukturze organizacyjnej Uczelni.


101. Drzewiasta, wielopoziomowa budowa szablonów budżetów z możliwością przechodzenia od ogółu do szczegółu i od szczegółu do ogółu.



102.Struktura budżetów musi być wielopoziomowa z podpozycjami. Dodatkowo niezbędne jest definiowanie pozycji agregujących podpozycje budżetowe (zarówno w wartości budżetów, blokad, dokumentów finansowych, dostępnych środków). Wymagana jest dowolna ilość poziomów.


103.

Możliwość eksportowania poza System szablonów budżetowych do elektronicznego wypełnienia. System musi odczytywać i zapisywać pliki wzorców w formacie Office Open XML (ISO/IEC 29500), z uwzględnieniem formatowania komórek (czcionka, wielkość czcionki, wielkość komórki, obramowanie, format, scalenie) oraz podstawowych formuł (odejmowanie, dodawanie, mnożenie, dzielenie, również z zastosowaniem nawiasów) między komórkami.


104.

Możliwość importowania do Systemu szablonów budżetowych wypełnionych elektronicznie. System musi odczytywać i zapisywać pliki wzorców w formacie Office Open XML (ISO/IEC 29500), z uwzględnieniem formatowania komórek (czcionka, wielkość czcionki, wielkość komórki, obramowanie, format, scalenie) oraz podstawowych formuł (odejmowanie, dodawanie, mnożenie, dzielenie, również z zastosowaniem nawiasów) między komórkami. Musi istnieć możliwość zmiany nazwy pozycji budżetowej w importowanym budżecie.


105. Możliwość tworzenia budżetów dla dowolnych okresów niezależnie od bieżącego roku obrotowego. Warunek konieczny Spełniony: Tak/Nie

106. Możliwość dowolnej rekonstrukcji istniejącego już budżetu oraz szablonów budżetów. Warunek konieczny Spełniony: Tak/Nie

107. Możliwość tworzenie szablonów budżetów oraz tworzenia nowych, konkretnych budżetów na podstawie szablonów.



108. Możliwość tworzenia szablonów budżetów na podstawie innych budżetów lub szablonów. Warunek konieczny Spełniony: Tak/Nie

109.Możliwość automatycznego nadawanie kodów budżetów w oparciu o kody projektów, których budżety dotyczą oraz możliwość manualnej korekty nadanych kodów. Kody powinny być unikalne w ramach całego systemu.


110. Przechowywanie historii zmian budżetu wraz z ewentualnymi komentarzami. Warunek konieczny Spełniony: Tak/Nie

111.Prezentowanie budżetów z trzystopniowym wykonaniem kosztów i przychodów (pierwszy stopień - środki zablokowane; drugi stopień - realizacja na podstawie dokumentów finansowych; trzeci stopień - dostępne środki).


112. Możliwość eksportu przeliczonych wartości budżetu oraz jego wykonania w zaprojektowanej formie w formacie Office Open XML (ISO/IEC 29500).


113.Możliwość sprawnego poruszania się po transakcjach realizujących budżet zarówno pionowo jak i poziomo. Możliwość przechodzenia z pozycji budżetowej do blokad oraz dokumentów finansowych (np. wniosków, umów, faktur) realizujących budżet.


114. Możliwość nadawania unikalnego (w ramach jednego budżetu) kodu pozycjom budżetowym. Warunek konieczny Spełniony: Tak/Nie

115. Możliwość zdefiniowania w budżecie więcej niż jednej pozycji budżetowej będącej agregacją innych pozycji budżetowych (sumującej inne pozycje budżetowe).


116. Możliwość definiowania więcej niż jednej pozycji budżetowej będącej kosztami pośrednimi. Warunek konieczny Spełniony: Tak/Nie

117. Możliwość formatowania pozycji budżetu (kolor tła, kolor czcionki, pogrubienie, kursywa). Warunek konieczny Spełniony: Tak/Nie


118.

Możliwość dodawania do pozycji budżetowych dodatkowych parametrów je identyfikujących (np.: wskaźników opisujących stopień realizacji). W pozycji budżetu musi istnieć możliwość zdefiniowania wartości na które składa się unikalny kod (w ramach budżetu), nazwa, opis oraz wartość liczbowa/finansowa. Dla wartości finansowych powinna być dostępna opcja przewalutowania. Musi być dostępna opcja agregowania wartości zdefiniowanych w wielopoziomowej strukturze budżetu.


119. Możliwość wprowadzenia ograniczenia przy realizacji budżetu kosztowego do wartości zaplanowanych lub zrealizowanych przychodów.


120. Możliwość powiązania realizacji przychodu wyrażonej w walucie z zaplanowanym przychodem w innej walucie. Możliwość przewalutowania.


121. Możliwość importowania i synchronizacji danych o realizacji przychodów z systemu bankowego. Warunek konieczny Spełniony: Tak/Nie

122. Możliwość zamykania budżetu oraz wskazanych pozycji budżetowych. Po zamknięciu system musi blokować edycję oraz możliwość dodawania lub usuwania transakcji.


123.

Możliwość przenoszenia niewykorzystanych środków w ramach danego budżetu do innego budżetu lub do pozycji budżetowej w tym samym budżecie. Niezbędne jest jawne wskazanie jakie środki nie zostały wykorzystane i następnie przeniesione (np.: po zamknięciu budżetu studiów podyplomowych przeznaczenie niewykorzystanych środków do dyspozycji Dziekana).


124.

System musi posiadać funkcjonalność częściowego zamykania budżetów (np.: za dany okres) oraz prezentowania stanu wykonania budżetów częściowo zamkniętych na określony moment w czasie. Wyznaczanie daty może odbywać się na podstawie daty transakcji, daty okresu rozliczeniowego lub daty płatności określonej realizacji.



125. System musi zapewniać możliwość prezentacji stanu realizacji budżetów w czasie (np.: za dany okres). Warunek konieczny Spełniony: Tak/Nie

126. Możliwość sprawnego przeglądania oraz modyfikacji wszystkich realizacji dla dowolnego budżetu w jednym zestawieniu.


127.Możliwość szybkiego wyszukiwania projektów, budżetów, dokumentów w Systemie poprzez wpisywanie elementów informacji je identyfikujących (np. człon kodu budżetu, nazwisko opiekuna projektu, numer dokumentu, nazwa).


128.

Możliwość przeglądania informacji zawartych w Systemie z pozycji przeznaczonej do podglądu danego typu informacji oraz poprzez wykorzystanie wzajemnych powiązań pomiędzy informacjami (np.: możliwość przejścia z pozycji budżetowej do dokonanych w jej ramach blokad środków, następnie do dokumentów finansowych realizujących blokady, płynne przejście do edycji i struktury budżetu).


129. Możliwość współpracy z systemem oraz wprowadzania danego typu danych z różnych poziomów Systemu (np. dokonywanie blokady środków z pozycji budżetu lub z pozycji dokumentu).


Blokowanie środków

130.Możliwość tworzenia blokad środków dla pozycji budżetowej, które rezerwują środki na przyszły koszt/przychody. Konieczne jest ostrzeganie o możliwości (w przypadku założenia blokady) przekroczenia dostępnych w ramach danej pozycji budżetowej środków.


131.Każda blokada musi być poprzedzona powiązaniem z dokumentem inicjującym (np. wnioskiem, zamówieniem). Dokument inicjujący musi zawierać swoją nazwę, datę, numer oraz zapewniać możliwość określenia historii zmian wnioskowanej do zablokowania kwoty.


132. Możliwość powiązania jednego dokumentu inicjującego (np.: wniosku, zamówienia) z wieloma blokadami z różnych budżetów.



133.Możliwość powiązania dokumentów inicjujących i blokad w grupy (np.: jako jedno działanie) wraz z opisem oraz datą. System musi zapewniać możliwość automatycznego generowania opisu grupy blokad na podstawie opisu dokumentów inicjujących.


134. Dostępna musi być funkcja wspierająca wprowadzanie kwoty blokady/dokumentu inicjującego w zależności od kwoty dokumentu inicjującego/blokady (automatyczne kopiowanie kwoty).


135. Możliwość tworzenia dokumentów inicjujących (np.: wniosku, zamówienia) w dowolnej walucie. Możliwość przewalutowania na podstawie kursu wybranego z kartoteki kursów.


136. Możliwość zakładania blokad dla pozycji budżetowej w walucie innej niż waluta budżetu. Zapewnienie operacji przewalutowania transakcji w oparci o kurs wybrany z kartoteki kursów.


137. System musi ostrzegać o przypadkach niezgodności walut np. gdy inna jest waluta wniosku i inna jest waluta blokady.


138.Dostępność kartoteki typów blokad. Możliwość wyboru odpowiedniego typu blokady uzależnionego od rodzaju transakcji której dotyczy. Pozycja budżetowa musi mieć możliwość określenia domyślnego typu blokady (np.: blokada na wynagrodzenia powinna podpowiadać pozycję budżetową dot. wynagrodzeń).


139.

Możliwość automatycznego tworzenia (wyliczania, zakładania, uzupełniania) blokady na podstawie innej blokady. Możliwość przypięcia automatycznie utworzonej blokady do innej pozycji budżetowej niż blokada bazowa (np.: na podstawie kwoty blokady na wynagrodzenie brutto utworzenie automatycznej blokady na ZUS pracodawcy i przypięcie jej do pozycji budżetowej dedykowanej pochodnym od wynagrodzeń).



140.W przypadku tworzenia kilku blokad na podstawie jednego dokumentu inicjującego, przy zakładaniu drugiej i kolejenej blokady system powinien automatycznie przenosić kwotę nie zablokowaną z dokumentu inicjującego do nowo tworzonej blokady.


141. Możliwość anulowania blokady wraz z jednoczesnym anulowaniem wszystkich dokumentów dotyczących jej realizacji.


142.Możliwość przenoszenia blokady do innej pozycji budżetowej. System powinien uwzględniać modyfikację realizacji przypisanych do blokady oraz przepływów budżetowych do których te realizacje są przypięte. System powinien przechowywać informację o przeniesieniu blokady.


143. Możliwość łączenie kilku blokad dla tej samej pozycji budżetowej w jedną. Łączenie powinno uwzględniać łączenie realizacji.


144. Możliwość przenoszenia dokumentów inicjujących pomiędzy działaniami. Warunek konieczny Spełniony: Tak/Nie

145. System powinien umożliwiać przenoszenie dokumentu inicjującego do innego działania. Warunek konieczny Spełniony: Tak/Nie

146. Możliwość zamykania blokady i jej realizacji. Po zamknięciu nie może być możliwa edycja transakcji ani jej usunięcie. Blokady zamknięte powinny być oznaczone (np. innym kolorem).


Struktura organizacyjna

147. Możliwość tworzenia w systemie struktury organizacyjnej Uczelni w formie drzewa. Warunek konieczny Spełniony: Tak/Nie

148. Możliwość deaktywowania i późniejszego aktywowania poszczególnych jednostek organizacyjnych Uczelni w strukturze organizacyjnej wraz z określeniem daty aktywacji/dezaktywacji.



149. Możliwość przechowywania wcześniejszej struktury organizacyjnej niezależnie od obecnej struktury organizacyjnej.


150. Możliwość określania dat (od - do) w których dana jednostka organizacyjna Uczelni istniała w Uczelni. Warunek konieczny Spełniony: Tak/Nie

151.Możliwość przechowywania informacji o zmianach w strukturze organizacyjnej Uczelni wraz z informacją o tym w jaki sposób następowało przekształcanie jednostek (np.: informacja o tym, że jednostka powstała z połączenia lub rozdzielenia innych jednostek).


152. Możliwość przechowywania informacji o modyfikacji kodu lub nazwy jednostki. Warunek konieczny Spełniony: Tak/Nie

153. Możliwość przechowywania w systemie informacja o danych teleadresowych Uczelni, również jeżeli Uczelnia posiada kilka siedzib. Możliwość oznaczania okresu ważności danych teleadresowych.


154. Możliwość tworzenia kartotek osób w strukturze organizacyjnej Uczelni. Kartoteka osób powinna zawierać podstawowe informacje o osobie (np.: imiona, nazwisko, data urodzenia, pesel, tytuł naukowy, login i inne).


155. Możliwość przypisywania poszczególnych osób do jednostek w strukturze organizacyjnej. Jedna osoba może być przypisana do wielu jednostek. Przypisanie powinno mieć określony początek i jeśli nastąpił, koniec.


156. Możliwość określania ról osób w strukturze organizacyjnej, jednocześnie określając daty pełnienia tych ról. Możliwość określania roli domyślnej.


Budżety walutowe

157. Możliwość tworzenia budżetów oraz ewidencji ich realizacji w walucie obcej (zarówno przychodów jak i kosztów).



158. Możliwość przedstawienia realizacji budżetu jednocześnie w walucie projektu, walucie z dokumentu finansowego i walucie krajowej.


159.

Możliwość określenia dodatkowych przewalutowań do innych kursów w celu przedstawiania spójnej informacji finansowej. Automatyczne przeliczanie walut w oparciu o wskazany kurs (nie zależnie od tego, w której z 3 możliwych walut wprowadzimy daną, system automatycznie powinien dokonać przeliczenia na dwie pozostałe).


160. Automatyczne pobieranie kursów walut (np.: średni NBP, kurs banku). Warunek konieczny Spełniony: Tak/Nie

161. Możliwość zdefiniowania kursu waluty przez użytkownika. Warunek konieczny Spełniony: Tak/Nie

162. Tworzenie kartoteki kursów walut zarówno dla kursów dziennych, jak i innych (np. miesięcznych). Musi istnieć możliwość zdefiniowania dowolnej ilości kartotek kursów walut.


163. Możliwość przypisania kursów do projektu (do grupy budżetów) ze wskazaniem kursu domyślnego (np.: średni kurs NBP z dnia poprzedzającego datę dokumentu).


164. Możliwość wskazanie transakcji realizowanych w systemie poprzez poszczególne kursy walut. Warunek konieczny Spełniony: Tak/Nie

165. W systemie niezbędna jest funkcjonalność pokazywania wtórnych transakcji przewalutowania wobec transakcji pierwotnych.


166.

Możliwość zmiany kursu walutowego dla wybranej grupy transakcji. Zmiana powinna odbywać się automatycznie z respektowaniem ograniczeń (np. nie przekraczania budżetu dostępnych środków). System musi umożliwiać filtrowanie transakcji w których ma zostać zmieniony kurs. W przypadku transakcji wtórnych musi istnieć możliwość automatycznej zmiany wartości transakcji, w związku ze zmianą wartości transakcji pierwotnej.



Przepływy budżetowe

167. Możliwość przekierowywania (przepływania) wolnych środków w ramach danego budżetu i pozycji budżetowej do innego budżetu i pozycji budżetowej.


168. Możliwość przekierowywania (przepływania) wolnych środków w ramach danego budżetu i pozycji budżetowej do innego budżetu bez konieczności jednoczesnego wskazania konkretnej pozycji w budżecie.


169. Możliwość rozdzielania przekierowanych środków (otrzymanych przepływów) na poszczególne pozycje budżetowe bez wskazywania, który przepływ jest przekierowany na którą pozycję budżetową.


170. Możliwość automatycznego przekierowania (przepływania) kosztów pośrednich w przypadku przekierowania (dokonania przepływu) kosztów bezpośrednich.


171. Możliwość automatycznej numeracji przekierowań (przepływów) w oparciu o kody budżetów i pozycji budżetowych, z których i do których przekierowania (przepływy) są realizowane.


172.Przechowywanie łatwo dostępnej informacji o pierwotnej postaci budżetów, dokonanych dodatnich i ujemnych przekierowaniach (przepływach) pomiędzy poszczególnymi budżetami i pozycjami budżetowymi oraz postaci budżetów po dokonaniu przekierowania (przepływów).


173.Definiowanie przekierowania środków (przepływów finansowych) obejmujących całość dostępnych środków, tzw. przepływów zamykających pozycję budżetową. System musi prezentować w budżecie oraz pozycjach budżetowych sumaryczną wartość przepływów zamykających.


174. Możliwość powiązania dokumentów finansowych z przekierowaniem środków (przepływami budżetowymi). Warunek konieczny Spełniony: Tak/Nie


Dokumenty

175. Możliwość wprowadzania do systemu dokumentów na podstawie których realizowana była blokada środków w budżecie (danych liczbowych oraz opisowych dotyczących dokumentów).


176. Możliwość wprowadzania do systemu dokumentów dotyczących realizacji blokad - dokumentów finansowych (danych liczbowych oraz opisowych dotyczących dokumentów).


177.Wyposażenie w mechanizm walidujący, pilnujący aby wprowadzane numery dokumentów się nie powtarzały, w przypadku dokumentów finansowych walidacja numerów dokumentów powinna być uwzględniona w ramach jednego kontrahenta.


178. Możliwość powiązania dokumentów, na podstawie których dokonywana jest blokada środków z dokumentami finansowymi realizującymi blokady.


179. Możliwość automatycznego tworzenia dokumentu do realizacji na podstawie dokumentu do blokady i na odwrót (w przypadku gdy oba etapy realizacji dokonywane są na podstawie tego samego dokumentu).


180. Wyposażenie w mechanizm walidujący, pilnujący aby dokumenty realizujące blokadę środków nie przekroczyły wartości blokady.


181. Możliwość zamykania blokad środków (poprzez wskazanie, że dokument finansowy jest ostatnim dokumentem do danej blokady środków).


182. Wyposażenie w mechanizm informujący o blokadach środków, których termin ważności upłynął, połączony z możliwością ręcznego lub automatycznego zamykania tych blokad.


183. Automatyczne odblokowanie w budżecie niewykorzystanej kwoty z blokady środków po jej zamknięciu . Warunek konieczny Spełniony: Tak/Nie

184. Możliwość wprowadzania dla dokumentów i realizacji okresów sprawozdawczych oraz dat płatności. Warunek konieczny Spełniony: Tak/Nie


185. Możliwość wprowadzenia listy płac wraz z pozycjami listy płac i składnikami płacowymi, jako dokumentu finansowego.


186. Możliwość wprowadzania pozycji dokumentu finansowego (np. informacje o pozycjach faktury, o podatku VAT, czy pozycje listy płac).


187. Możliwość wprowadzania informacji o dekretowaniu poszczególnych realizacji na konta księgowe. Dekretacja powinna uwzględniać możliwość zastosowania wymiarów kont księgowych.


188. Możliwość wprowadzania realizacji będących korektami innych realizacji powiązanych z realizacjami korygowanymi.


189. Możliwość klonowania realizacji w ramach jednego dokumentu finansowego. Warunek konieczny Spełniony: Tak/Nie

190. Możliwość oznaczania statusem dokumentów finansowych oraz realizacji blokad (informacja o dokonaniu walidacji).


Kartoteki

191. Możliwość zdefiniowania dowolnej liczby typów kartotek o co najmniej 20 znakowych symbolach alfanumerycznych (np.: kartoteka kontrahentów, banków, opiekunów projektów, typów dokumentów).


192. Możliwość zdefiniowania dowolnej liczby rodzajów kartotek w ramach danego typu kartoteki (np.: w ramach kartoteki kontrahentów podział na kontrahentów krajowych i zagranicznych).


193. Swoboda definiowania rodzaju informacji zawartych w kartotece oraz ich wymagalności np.: nazwa, nazwa skrócona, NIP, NIP UE, REGON, kilka rodzajów adresów, kilka numerów rachunków bankowych.



194. Wyposażenie w mechanizm walidujący, pilnujący aby nie wprowadzać ponownie tego samego kontrahenta. Warunek konieczny Spełniony: Tak/Nie

195. Oznaczanie obiektów w kartotece jako nieaktywne z możliwością przywrócenia statusu aktywnego, przy zachowaniu historii danych.


196. Możliwość wyszukiwania obiektów w kartotekach po różnych zmiennych je identyfikujących. Warunek konieczny Spełniony: Tak/Nie

197.

Automatyczne podpowiadanie elementów z kartoteki spełniających wymagane kryterium w trakcie jego wpisywania podczas wyszukiwania elementu (np. podpowiadanie kontrahentów, których NIP jest zgodny z wpisywanym nr NIP w trakcie jego wpisywania i stopniowa eliminacja kontrahentów, których NIP jest niezgodny z wpisywanym).


198.System musi zawierać kartotekę loginów zapewniających uwierzytelnianie w Systemie i umożliwiać synchronizację z Active Directory. Przy czym system musi umożliwiać wyłączanie ważności loginów w przypadku wyłączenia ich w Active Directory lub umieszczenia we wskazanej grupie Active Directory.


Koszty pośrednie

199. Automatyczne naliczanie i ewidencjonowanie kosztów pośrednich na poziomie budżetu, blokady środków, realizacji w oparciu o dokumenty finansowe, dostępnych środków.


200. Automatyczne naliczanie i ewidencjonowanie kosztów pośrednich wg kluczy podziałowych opartych na zdefiniowanych algorytmach.


201. Definiowanie dowolnych algorytmów do naliczania kosztów pośrednich (np. w stosunku do części kosztów bezpośrednich, przychodów).


202. Przypisywanie konkretnych algorytmów do naliczania kosztów pośrednich do konkretnych wzorców budżetu. Warunek konieczny Spełniony: Tak/Nie


203. Możliwość wskazania pozycji budżetowych od których naliczane są koszty pośrednie (zarówno kosztowych jak i przychodowych).


204. Możliwość wskazania dowolnej ilości oraz typu pozycji budżetowych na potrzeby definiowania algorytmu do naliczania kosztów pośrednich.


205. Możliwość definiowania więcej niż jednej pozycji budżetowej w ramach jednego budżetu, będącej kosztami pośrednimi.


206.Możliwość wskazywania różnych algorytmów naliczania kosztów pośrednich dla różnych naliczeń kosztów pośrednich w ramach jednego budżetu (np.: naliczenie kosztów pośrednich kolegialnych wg innego algorytmu i kosztów pośrednich ogólnouczelnianych wg innego algorytmu).


207. Możliwość zmiany sposobu naliczania kosztów pośrednich w funkcjonującym budżecie (np.: budżecie, na którym dokonano już blokady środków).


208. Możliwość automatycznego naliczenia realizacji kosztów pośrednich wg innego algorytmu, niż dla naliczenia. Warunek konieczny Spełniony: Tak/Nie

209. Możliwość definiowania dla budżetu i projektu grup kosztów pośrednich i uwzględnianie ich w algorytmach obliczania kosztów pośrednich.


210. Możliwość określenia do której grupy kosztów pośrednich należy blokada. Warunek konieczny Spełniony: Tak/Nie

211. Możliwość obliczenia współczynnika kosztów pośrednich na podstawie wprowadzonej wartości budżetu. Warunek konieczny Spełniony: Tak/Nie

Komentarze i załączone dokumenty

212. Możliwość załączania notatek zawierających komentarze i pliki do dowolnych (wszystkich) obiektów i typów danych w systemie.



213. Załączone dokumenty muszą być przechowywane w bazie danych i dostępne z poziomu każdego stanowiska. Warunek konieczny Spełniony: Tak/Nie

214. Możliwość tworzenia i otwierania załączonych plików w formacie Rich Text Format wewnątrz systemu. Możliwość edycji plików, w tym dodawanie obrazków.


215. Możliwość tworzenia i otwierania w systemie plików arkuszy kalkulacyjnych programu MS Excel z podstawowymi formułami oraz wykresami.


216. Możliwość podglądu załączonych plików typu pdf wewnątrz aplikacji. Warunek konieczny Spełniony: Tak/Nie

217.Łatwe przeglądanie załączonych dokumentów i komentarzy (np: system musi wskazywać wszystkie załączone pliki związane z fakturą oraz transakcjami, które tą fakturę realizują; pokazać wszystkie załączone plik do budżetu lub grupy budżetów (projektu)). Możliwość łatwego, zbiorczego eksportu załączonych plików.


218. W przypadku załączania plików tekstowych lub plików Txt, Word, Rtf, Excel powinna istnieć możliwość wyszukiwania dokumentów wg zadanego tekstu.


Budżety zagregowane

219.Możliwość automatycznego agregowania (sumowania) budżetów i tworzenia na ich podstawie budżetów agregujących (sumujących, łącznych) przedstawiających łączną wartość kilku wskazanych budżetów (np.: budżety w ramach projektu sumują się w jeden zagregowany budżet całego projektu).


220. Możliwość wskazywania do agregacji jednego lub wielu budżetów zarówno kosztowych jak i przychodowych. Warunek konieczny Spełniony: Tak/Nie

221. Możliwość wprowadzenia budżetów agregujących na kilku poziomach (np.: budżet agregujący wszystkie projekty danego typu, budżet agregujący budżety agregujące dla poszczególnych typów projektów).



222. System musi zapewniać wielopoziomową strukturę budżetów agregujących z uwzględnieniem sum częściowych.


223. W systemie musi istnieć możliwość formatowania pozycji budżetu agregującego (kolor tła, kolor czcionki, pogrubienie, kursywa).


224.System musi umożliwiać tworzenie budżetów agregujących w innej walucie niż budżety, które agreguje. Musi być dostępna opcja szybkiego, masowego przewalutowania wartości finansowych przypisanych do pozycji budżetu agregującego.


225. Wielopoziomowa struktura budżetów oznacza, że wszystkie podpozycje budżetu mają być agregowane do pozycji nadrzędnej wraz ze swoimi wartościami finansowymi.


226. Kod pozycji budżetowej w budżecie agregującym powinien być unikalny w ramach jednego budżetu. Warunek konieczny Spełniony: Tak/Nie

227. Pozycją agregowaną przez budżet agregujący może być zarówno zwykła pozycja budżetowa, jak i pozycja budżetu agregującego oraz każdego innego budżetu.


228. System musi pozwalać na dodawanie do pozycji budżetu agregującego własnych pól z wartościami wyliczanymi na podstawie innych informacji o pozycji budżetu agregującego oraz pozycji przez nią agregowanych.


229. System musi zapewniać możliwość klonowania budżetów zagregowanych. Warunek konieczny Spełniony: Tak/Nie

230.System powinien umożliwiać prezentację budżetu agregującego w formie z jedną kolumną, wskazującą wybraną wartość, np. wartość budżetu, wartość wykonania, wartość wolnych środków lub inną wartością wyliczoną.



231.

W systemie musi być dostępna możliwość projektowania wzorca prezentacji budżetu agregującego w postaci tabelarycznej (podobnie, jak w arkuszu kalkulacyjnym) z możliwością definiowania formatów komórek (czcionka, wielkość czcionki, wielkość komórki, obramowanie, format, scalenie) z zastosowaniem podstawowych formuł (odejmowanie, dodawanie, mnożeniem, dzielenie, również z zastosowaniem nawiasów) między komórkami. System musi umożliwić eksport przeliczonych wartości budżetu w zaprojektowanej formie w formacie Office Open XML (ISO/IEC 29500).


232.

System powinien odczytywać i zapisywać pliki wzorców budżetów zagregowanych w formacie Office Open XML (ISO/IEC 29500), z uwzględnieniem formatowania komórek (czcionka, wielkość czcionki, wielkość komórki, obramowanie, format, scalenie) oraz podstawowych formuł (odejmowanie, dodawanie, mnożenie, dzielenie, również z zastosowaniem nawiasów) między komórkami.


233.

W systemie musi istnieć możliwość filtrowania po dowolnych właściwościach pozycji budżetowych, które mają być dodane do budżetu agregującego. Konieczna jest możliwość założenia repozytorium filtrów dla budżetu agregującego wraz z możliwością ich późniejszego wykorzystania. Filtrowanie musi przewidywać podstawowe porównania (m.in. mniejsze, większe, równe, nierówne, zawiera) i obsługiwać zagnieżdżanie warunków.


234. System musi umożliwiać wyłączenie (ale nie poprzez usunięcie) z agregacji dodanej pozycji budżetowej (wskazujemy czy ma się liczyć czy nie).


235.System musi pokazywać wszystkie pozycje budżetowe, które są przypisane do budżetu agregującego wraz z informacją do której pozycji agregującej są przypisane oraz umożliwiać masowe wyłączanie lub usuwanie przypisań.



236.System musi umożliwiać przypisanie współczynnika przez który mnożone są wartości finansowe poszczególnych pozycji budżetowych przypisanych do pozycji budżetu agregującego. Musi istnieć możliwość określania sposobu zaokrąglania tych wartości.


237. System musi umożliwiać opcję wersjonowania na żądanie budżetów agregujących wraz z przypisanymi pozycjami budżetowymi.


Planowanie

238. Możliwość budowania planu finansowego uczelni przy wykorzystaniu systemu. Warunek konieczny Spełniony: Tak/Nie

239. Możliwość tworzenia łącznego budżetu Uczelni poprzez zsumowanie planów cząstkowych - planowanie oddolne.


240.Możliwość planowania (wypełniania budżetów dla ustalonego wzorca) poprzez wskazane osoby za pośrednictwem portalu internetowego i automatycznego zaczytywania wypełnionych budżetów do systemu. System musi obsługiwać planowanie w podziale na zadania (struktura dwuwymiarowa).


241. Możliwość zmiany nazwy pozycji planowanej przez użytkownika wypełniającego budżet za pośrednictwem portalu internetowego.


242. Możliwość określenia statusu planowanej pozycji budżetowej (otwarta, zamknięta, do decyzji, ukryta, podgląd).


243.Struktura planowanego budżetu musi być wielopoziomowa z uwzględnieniem agregowania wartości finansowych podpozycji przez pozycję nadrzędną, umożliwiać obsługę sum częściowych oraz kosztów pośrednich.


244. System musi umożliwiać przypisanie do budżetu planowanego innych budżetów wraz z dodatkową informacją. Użytkownik powinien móc swobodnie zapoznać się z informacjami finansowymi w przypiętych budżetach.



245.Proces budżetowania powinien odbywać się poprzez zdefiniowanie wartość pierwotnej planowanego budżetu, a następnie wprowadzanie korekt. Musi istnieć możliwość określania typu oraz opisu korekty. Korekty muszą być ewidencjonowane.


246. Korekty powinny być agregowane w strukturze planowanego budżetu. Warunek konieczny Spełniony: Tak/Nie

247. Musi istnieć możliwość określania domyślnego typu korekt budżetu dla użytkownika planującego za pośrednictwem portalu internetowego.


248. System musi pokazywać za pośrednictwem portalu internetowego wartość pierwotną budżetu, zsumowaną wartość korekt oraz ostateczną wartość budżetu.


249. Musi istnieć możliwość dopisania do korekt dodatkowych komentarzy oraz załączenia dokumentów. Warunek konieczny Spełniony: Tak/Nie

250. System musi zapewniać informację o wartościach korekt budżetów w zestawieniu dla całej uczelni lub wskazanego zakresu.


251.

System musi udostępniać narzędzia do planowania z góry, które zaproponują proporcjonalny podział środków na podstawie wcześniej zdefiniowanych wartości planowanych pozycji (np. wartości budżetu pierwotnego, wartości korekt określonego typu itd.). Proponowany podział musi zostać automatycznie wprowadzony do planów, których dotyczy, jako korekta.


252. System musi umożliwiać podgląd planowanych budżetów wyznaczonym osobom poprzez portal internetowy. Osoby obsługujące portal internetowy muszą mieć możliwość dopisywania komentarzy do budżetu.


253. System musi umożliwiać zatwierdzenie budżetu, co uniemożliwia wprowadzenie korekt przez portal internetowy.



254. System musi udostępniać opcję automatycznego zbudowania budżetu ewidencji kosztów/przychodów (budżetu, na którym się pracuje, potwierdza środki itd.) na podstawie zaplanowanego budżetu.


255.Jeżeli planowane budżety łączą się w plan finansowy (np. budżet zadaniowy uczelni) system powinien zbudować całą strukturę budżetów ewidencji kosztów/przychodów oraz budżetów agregujących, tak by odwzorować plan finansowy.


256. System powinien zachowywać powiązanie pomiędzy budżetem planowanym, a późniejszym budżetem opisującym wykonanie co najmniej na poziomie pozycji budżetowej.


Dokumenty centralne

257. Możliwość wprowadzania do systemu dokumentów centralnych bezpośrednio nie realizujących budżetów (np.: umowa, w ramach której zostanie wystawiona faktura, wniosek o zaliczkę).


258.Dokument centralny powinien posiada unikalne pole kod.


259.Powinien istnieć słownik typów dokumentów centralnych.


260. Dokument centralny powinien posiadać pola opisowe (np. nazwa, data powstania, daty obowiązywania) oraz dodatkowe szablony zawierające szczegółowy opis dokumentu, związany z typem dokumentu centralnego.


261. Powinna istnieć możliwość powiązania dokumentu centralnego z osobami w strukturze organizacyjnej uczelni oraz ich rolami (z uwzględnieniem roli domyślnej).


262.Możliwość powiązania dokumentu centralnego z kontrahentem.



263. Powinna istnieć możliwość tekstowego wyszukiwania wśród plików powiązanych z dokumentami centralnymi, jeśli istnieje ich reprezentacja tekstowa.


264.Możliwość powiązania dokumentu centralnego z operatorem systemu lub grupą operatorów Systemu.


265.Możliwość określenia kwoty całkowitej dokumentu centralnego.


266.Możliwość wprowadzania pozycji dokumentu centralnego.


267. Możliwość wprowadzenia minimum dwóch rodzajów wartości dokumentu centralnego, które będą kontrolowane przez System.


268.Możliwość określania formatowania czcionki i kolorów dokumentu centralnego.


269. Możliwość powiązania dokumentów centralnych z dokumentami realizującymi budżety (powiązanie powinno być wyabstrahowane od projektu czy budżetu).


270.Możliwość kontrolowania stopnia wypełnienia dokumentu centralnego poprzez blokadę środków w budżecie.


271. Możliwość pilnowania stopnia realizacji dokumentu centralnego przez dokument realizujący (np.: czy faktury wystawione do umowy nie przekraczają wartości umowy).


272. Możliwość automatycznego ustawienia stopnia realizacji dokumentu centralnego przez dokumenty realizujące poprzez przeniesienie informacji z blokady środków powiązanej z dokumentem centralnym.


273. System powinien umożliwiać prezentację dokumentu centralnego wraz z informacjami o realizujących go dokumentach finansowych i blokadach.



274. Możliwość definiowania statusu dokumentu centralnego, który np. uniemożliwia wiązanie dokumentu centralnego z blokadami lub z dokumentami finansowymi.


Raportowanie

275.Definiowanie dowolnych zapytań o pozycje budżetowe, blokady środków, dokumenty finansowe, dokumenty powiązane, przepływy budżetowe oraz dostępne środki zaewidencjonowane w systemie w oparciu o przedział czasowy, kwotowy, rodzajowy transakcji.


276.Samodzielne tworzenie przez uprawnionych użytkowników szablonów raportów, zakładających indywidualną wizualizację oraz określenie zawartości merytorycznej, z możliwością zachowania szablonu i udostępnienia innym użytkownikom.


277. Nieograniczona pojemność raportów co do liczby wierszy i kolumn. Warunek konieczny Spełniony: Tak/Nie

278. Dostęp do raportów za pośrednictwem portalu internetowego. Warunek konieczny Spełniony: Tak/Nie

279.Opracowanie i wykonanie maximum 10 raportów ustalonych w Analizie Funkcjonalnej.


280.Opracowanie i wykonanie maximum 30 raportów ustalonych w Analizie Funkcjonalnej

Warunek oceniany Tak – 1 pkt Nie – 0 pkt

281. Możliwość eksportowania i zapisywania generowanych w systemie raportów, zestawień, do programów pakietu MS Office (Word, Excel), pdf.



282.Szablon raportu automatycznie generowane przez system (nie zakładające możliwości ingerencji przez użytkownika) powinny zawierać m.in.: nagłówek - nazwę raportu, logo uczelni, okres lub na jaki dzień obowiązuje raport; stopkę - Imię i nazwisko osoby generującej raport, data wygenerowania raportu.


283. Na etapie Analizy Funkcjonalnej zostaną określone nazwy poszczególnych raportów oraz ich szczegółowy zakres.



Wymagania w zakresie integracjiL.p.

(1)

Wymaganie

(2)

Status wymagania

(3)

1. System zostanie zintegrowany przez Wykonawcę z Systemami Bankowości Internetowej (SBI) wykorzystywanymi przez Zamawiającego.

Uczelnia współpracuje z bankiem PEKAO S.A. i korzysta z Systemu Bankowości Internetowej PekaoBIZNES. Integracja oferowanego Systemu z Systemem Bankowości Internetowej (SBI) powinna umożliwić automatyczne importowanie, rozliczanie (kojarzenie) wyciągów bankowych z SBI.

Warunek konieczny

Spełniony: Tak/Nie

2. System zapewni możliwość integracji z systemem wniosków elektronicznych SGH.

Zakres przekazywanych danych przez System do systemu wniosków elektronicznych SGH to m.in.:

a) kod budżetu, b) kod pozycji budżetowej, c) nazwa pozycji budżetowej, d) informacja o dostępnych środkach.

Zakres danych pobieranych przez System z systemu wniosków elektronicznych SGH to m.in.:

a) numer wniosku,

Warunek oceniany

Tak – 1 pkt

Nie – 0 pkt


b) wnioskodawca (login osoby, kod jednostki organizacyjnej SGH),c) rodzaj zamówienia, d) szacowana kwota zamówienia,e) opis wniosku, f) przedmiot wniosku, g) pozycje budżetowe, h) cel realizacji, i) proponowana jednostka realizująca zamówienie, j) numer umowy sukcesywnej, k) szacunkowa wartość zamówienia (z uwzględnieniem wartości netto, vat, wartość brutto).

Szczegółowy zakres danych oraz ich format zostanie ustalony na Etapie Analizy Funkcjonalnej. Na podstawie pobranych informacji z systemu wniosków elektronicznych SGH, System powinien dokonywać automatycznych blokad środków w budżecie.

3. System zapewni możliwość integracji z systemem klasy ERP z zastosowaniem następujących technologii:

a) WebServices,b) przenoszenie danych za pośrednictwem tabel, widoków, funkcji zdefiniowanych przez

użytkownika lub procedur wbudowanych we wskazanych bazach danych z zastosowaniem posiadanego przez Zamawiającego Systemu Zarządzania Bazami Danych Microsoft SQL 2008 Enterprise,

c) plików XML, CSV, XLS i XLSX.

Warunek konieczny

Spełniony: Tak/Nie

4. System musi umożliwiać pobranie z systemu klasy ERP informacji dotyczących zaewidencjonowanych Warunek konieczny


dokumentów finansowych, m.in. w zakresie następujących danych:

a) kod dokumentu finansowego,b) alfanumeryczny, unikalny, systemowy kod dokumentu,c) numer wniosku zakupowego, d) numer zamówienia,e) numer własny dokumentu finansowego,f) numer ewidencyjny dokumentu finansowego,g) kod kontrahenta,h) data dokumentu finansowego,i) data operacji gospodarczej,j) data wpływu,k) opis merytoryczny,l) kwota netto, kwota VAT, kwota brutto,m) rozpisanie dokumentu wg stawek VAT (kwota netto, kwota VAT, kwota brutto),n) pozycje dokumentu finansowego, o) data księgowania,p) status (kod i nazwa statusu, wartość),q) data okresu sprawozdawczego,r) termin płatności,s) rachunek bankowy płatności wraz z tytułem przelewu i datą płatności,t) informacje o dekretach księgowych (numer konta, kwota, wymiary), u) skan dokumentu,

Spełniony: Tak/Nie


v) data wprowadzenia,w) data modyfikacji.

5. System musi umożliwiać pobranie z systemu klasy ERP informacji dotyczących kontrahentów, m.in. w zakresie następujących danych:

a) alfanumeryczny, unikalny, systemowy kod, b) nazwa/imię i nazwisko, c) NIP/PESEL, d) kod rodzaju kontrahenta, e) adresy, f) numery rachunków bankowych (wraz z kodem banku), g) data modyfikacji.

Warunek konieczny

Spełniony: Tak/Nie

6. System musi umożliwiać pobranie z systemu klasy ERP informacji dotyczących pracowników lub osób fizycznych, m.in. w zakresie następujących danych:

a) alfanumeryczny, unikalny, systemowy kod pracownika,b) kod, c) imiona, d) nazwisko, e) PESEL, f) typ dokumentu tożsamości, g) numer dokumentu tożsamości,

Warunek konieczny

Spełniony: Tak/Nie


h) nazwisko rodowe, i) płeć, j) data urodzenia, k) adres, l) numery rachunków bankowych (wraz z kodem banku), m) email, n) login,

wraz z informacjami o zatrudnieniu:

a) alfanumeryczny, unikalny, systemowy kod zatrudnienia,b) kod stanowiska,c) data rozpoczęcia zatrudnienia,d) data zakończenia zatrudnienia,e) wymiar etatu,f) kod jednostki organizacyjnej.

7. System musi umożliwiać pobranie z systemu klasy ERP informacji dotyczących list płac, m.in. w zakresie następujących danych:

a) alfanumeryczny, unikalny, systemowy kod,b) numer listy płac,c) data listy płac,d) kod jednostki organizacyjnej,

Warunek konieczny

Spełniony: Tak/Nie


e) kod projektu, f) informacje o dekretach księgowych (numer konta, kwota, wymiary),g) składniki płacowe listy płac wraz z wartościami,h) wartość listy płac,i) pozycje listy płac wraz z numerem rachunku oraz imieniem, nazwiskiem, kodem pracownika,

wartością pozycji, listą składników płacowych dla pozycji wraz z wartościami.

8. System umożliwia okresową wymianę danych uruchamianą na życzenie użytkownika lub okresowo wg zdefiniowanego przez użytkownika harmonogramu lub poprzez wystąpienie określonego zdarzenia, które inicjuje proces wymiany danych.

Warunek konieczny

Spełniony: Tak/Nie

9. System umożliwia wymianę danych poprzez następujące mechanizmy wymiany danych:

a) Usługi sieciowe – WebServices,b) Pliki XML,c) Pliki CSV,d) Pliki XLS i XSLX.

Warunek konieczny

Spełniony: Tak/Nie


Wymagania w zakresie migracji danych

L.p.

(1)

Wymaganie

(2)

Komentarz

(3)

1. Wykonawca w ramach Analizy Funkcjonalnej:

a) doprecyzuje i wyspecyfikuje w uzgodnieniu z SGH zakres danych do migracji do systemu warunkujący działanie systemu zgodne z wymaganiami Zamawiającego oraz poprawność procedury migracji,

b) zaproponuje optymalną dla SGH (z punktu widzenia bezpieczeństwa, nakładu czasu i pracy) metodę migracji tych danych.

2. Za pozyskanie danych do migracji z systemów źródłowych i przygotowanie ich do formatu wskazanego na etapie Analizy Funkcjonalnej (np. xls, csv, txt) odpowiada Zamawiający.


Wymagania w zakresie zgodności z przepisami prawaZamawiający na Etapie Analizy Funkcjonalnej wskaże, które elementy podanych przepisów prawa będą wymagały implementacji w Systemie.

L.p.

(1)

Akt prawny

(2)

Komentarz

(3)

Status wymagania

(4)

1. Ustawa – Prawo o szkolnictwie wyższym:

Ustawa z dnia 27 lipca 2005 r. Prawo o szkolnictwie wyższym ( Dz. U. z 2012 poz. 572 z późn. zm. )

Łącznie z przepisami wykonawczymi.

Warunek konieczny

Spełniony: Tak/Nie

2. Ustawa o finansach publicznych:

Ustawa z dnia 27 sierpnia 2009r. o finansach publicznych ( Dz. U. z 2013 poz. 885 z późn. zm.)


Warunek konieczny

Spełniony: Tak/Nie

3. Ustawa – Prawo zamówień publicznych:

Ustawa z dnia 29 stycznia 2004r. Prawo zamówień publicznych ( Dz. U. z 2013 poz. 907 z późn. zm. )


Warunek konieczny

Spełniony: Tak/Nie

4. Ustawa o rachunkowości:

Ustawa z dnia 29 września 1994r. o rachunkowości ( Dz. U. z 2013r. poz. 330 z późn. zm )


Warunek konieczny

Spełniony: Tak/Nie

5. Ustawa o podatku dochodowym od osób fizycznych: Łącznie z przepisami Warunek konieczny


Ustawa z dnia 26 lipca 1991r. o podatku dochodowym od osób fizycznych ( Dz. U. z 2012r. poz. 361 z późn. zm. )

wykonawczymi. Spełniony: Tak/Nie

6. Ustawa o podatku dochodowym od osób prawnych:

Ustawa z dnia 15 lutego 1992r. o podatku dochodowym od osób prawnych ( Dz. U. 2011r. nr 74, poz. 397 z późn. zm. )


Warunek konieczny

Spełniony: Tak/Nie

7. Ustawa o podatku od towarów i usług VAT:

Ustawa z dnia 11 marca 2004r. o podatku od towarów i usług ( Dz. U. 2011r. nr 177, poz. 1054 z późn. zm. )


Warunek konieczny

Spełniony: Tak/Nie

8. Ustawa o systemie ubezpieczeń społecznych:

Ustawa z dnia 13 października 1998r. o systemie ubezpieczeń społecznych ( Dz. U. z 2013r. poz. 1442 z późn. zm. )


Warunek konieczny

Spełniony: Tak/Nie

9. Ustawa – Kodeks pracy:

Ustawa z dnia 26 czerwca 1974 r. Kodeks pracy ( Dz. U. z 1998 nr 21, poz. 94 z późn. zm. )


Warunek konieczny

Spełniony: Tak/Nie

10. Rozporządzenie Ministra Nauki i Szkolnictwa Wyższego w sprawie warunków wynagradzania za pracę i przyznawania innych świadczeń związanych z pracą dla pracowników zatrudnionych w uczelni publicznej z dnia 5.10.2011 r. (Dz. U. Nr 243, poz. 1447 z późn. zm. ) ( nieaktualne – obecnie obowiązujące z dnia 11 grudnia 2013r. ( Dz. U. z 2013 poz. 1571 )

Warunek konieczny

Spełniony: Tak/Nie


11. Rozporządzenie Ministra Pracy i Polityki Socjalnej z dnia 15 maja 1996 r. w sprawie sposobu usprawiedliwiania nieobecności w pracy oraz udzielania pracownikom zwolnień od pracy ( Dz. U. nr 60 poz. 281 z późn. zm. )

Warunek konieczny

Spełniony: Tak/Nie

12. Rozporządzenie Ministra Pracy i Polityki Socjalnej z dnia 8 stycznia 1997 r. w sprawie szczegółowych zasad udzielania urlopu wypoczynkowego, ustalania i wypłacania wynagrodzenia za czas urlopu oraz ekwiwalentu pieniężnego za urlop (Dz. U. nr 2 poz.14 z późn.zm. )

Warunek konieczny

Spełniony: Tak/Nie

13. Rozporządzenie Ministra Pracy i Polityki Społecznej z dnia 19 września 2013 r. w sprawie szczegółowych warunków udzielania urlopu wychowawczego (Dz. U. z 2013 r. poz. 1139)

Warunek konieczny

Spełniony: Tak/Nie

14. Ustawa z dnia 25 czerwca 1999r. o świadczeniach pieniężnych z ubezpieczenia społecznego w razie choroby i macierzyństwa ( Dz. U. z 2014 poz. 159 z późn. zm. )

Warunek konieczny

Spełniony: Tak/Nie

15. Ustawa z dnia 17 grudnia 1998 r. o emeryturach i rentach z Funduszu Ubezpieczeń Społecznych z dnia ( Dz. U. z 2013r. poz. 1440 z późn. zm. )


Warunek konieczny

Spełniony: Tak/Nie


16. Ustawa z dnia 30 października 2002r. o ubezpieczeniu społecznym z tytułu wypadków przy pracy i chorób zawodowych ( Dz. U. z 2009 Nr 167 poz. 1322, z późn. zm. )


Warunek konieczny

Spełniony: Tak/Nie

17. Ustawa z dnia 20 kwietnia 2004 r. o promocji zatrudnienia i instytucjach rynku pracy ( Dz. U. z 2013r. poz. 674 z późn. zm. )


Warunek konieczny

Spełniony: Tak/Nie

18. Rozporządzenie Ministra Pracy i Polityki Społecznej z dnia 23 października 2009 r. w sprawie określenia wzorów zgłoszeń do ubezpieczeń społecznych i ubezpieczenia zdrowotnego, imiennych raportów miesięcznych i imiennych raportów miesięcznych korygujących, zgłoszeń płatnika, deklaracji rozliczeniowych i deklaracji rozliczeniowych korygujących, zgłoszeń danych o pracy w szczególnych warunkach lub o szczególnym charakterze oraz innych dokumentów ( Dz. U. nr 186, poz. 1444, z późn.zm. )

Warunek konieczny

Spełniony: Tak/Nie

19. Ustawa z dnia 10 października 2002 r. o minimalnym wynagrodzeniu za pracę ( Dz. U. Nr 200 poz. 1679, z późn. zm. )


Warunek konieczny

Spełniony: Tak/Nie


20. Ustawa z dnia 14 marca 2003 r. o stopniach naukowych i tytule naukowym oraz o stopniach i tytule w zakresie sztuki (Dz. U. Nr 65, poz. 595 z późn. zm. )


Warunek konieczny

Spełniony: Tak/Nie

21. Rozporządzenie Ministra Nauki i Szkolnictwa Wyższego z dnia 2 listopada 2006 r. w sprawie sposobu ustalania wynagrodzenia za urlop wypoczynkowy oraz ekwiwalentu pieniężnego za okres niewykorzystanego urlopu wypoczynkowego nauczycieli akademickich ( Dz. U. Nr 203, poz. 1499, z późn.zm. )

Warunek konieczny

Spełniony: Tak/Nie

22. Ustawa z dnia 23 kwietnia 1964 r. - Kodeks Cywilny ( Dz. U. z 2014 poz. 121, ) Warunek konieczny

Spełniony: Tak/Nie

23. Ustawa z dnia 16 października 1992 r. o orderach i odznaczeniach ( Dz. U. Nr 90, poz. 450, z późn.zm. )

Warunek konieczny

Spełniony: Tak/Nie


24. Rozporządzenie Ministra Edukacji Narodowej z dnia 20 września 2000 r. w sprawie szczegółowych zasad nadawania "Medalu Komisji Edukacji Narodowej", trybu przedstawiania wniosków, wzoru medalu, trybu jego wręczania i sposobu noszenia ( Dz. U. Nr 99 poz. 1073 z późn.zm. )

Warunek konieczny

Spełniony: Tak/Nie

25. Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych ( Dz. U. z 2002 r. Nr 101 poz. 926, z późn.zm. )


Warunek konieczny

Spełniony: Tak/Nie

26. Ustawa z dnia 12 grudnia 1997r. o dodatkowym wynagrodzeniu rocznym dla pracowników jednostek sfery budżetowej, ( Dz. U. z 2013 poz. 1144 )

Warunek konieczny

Spełniony: Tak/Nie

27. Rozporządzenie Ministra Pracy i Polityki Socjalnej z dnia 18 grudnia 1998 r. w sprawie szczegółowych zasad ustalania podstawy wymiaru składek na ubezpieczenia emerytalne i rentowe ( Dz. U. Nr 161 poz. 1106 z późn. zm. )

Warunek konieczny

Spełniony: Tak/Nie

28. Ustawa z dnia 27 sierpnia 2004 r. o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych ( Dz. U. z 2008 Nr 164 poz. 1027 z późn. zm. )

Warunek konieczny

Spełniony: Tak/Nie


29. Rozporządzenie Ministra Pracy i Polityki Socjalnej z dnia 29 maja 1996 r. w sprawie sposobu ustalania wynagrodzenia w okresie niewykonywania pracy oraz wynagrodzenia stanowiącego podstawę obliczania odszkodowań, odpraw, dodatków wyrównawczych do wynagrodzenia oraz innych należności przewidzianych w Kodeksie pracy, ( Dz. U. Nr 62 poz. 289 z późn. zm. )

Warunek konieczny

Spełniony: Tak/Nie

30. Rozporządzenie Ministra Nauki i Szkolnictwa Wyższego z dnia 14 września 2006 r. w sprawie sposobu ustalania okresów pracy i innych okresów uprawniających pracowników uczelni publicznej do nagrody jubileuszowej oraz sposobu jej obliczania i wypłacania ( Dz. U. Nr 169, poz. 1211 )

Warunek konieczny

Spełniony: Tak/Nie

31. Ustawa z dnia 13 marca 2003 r. o szczególnych zasadach rozwiązywania z pracownikami stosunków pracy z przyczyn niedotyczących pracowników ( Dz. U. Nr 90 poz. 844 z późn. zm )

Warunek konieczny

Spełniony: Tak/Nie

32. Ustawa z dnia 4 marca 1994 r. o zakładowym funduszu świadczeń socjalnych (Dz. U. z 2012 r., poz. 592 z późn. zm.)

Warunek konieczny

Spełniony: Tak/Nie


33. Rozporządzenie Ministra Pracy i Polityki Społecznej z dnia 9 marca 2009 r. w sprawie sposobu ustalania przeciętnej liczby zatrudnionych w celu naliczania odpisu na zakładowy fundusz świadczeń socjalnych (Dz. U. Nr 43, poz. 349)

Warunek konieczny

Spełniony: Tak/Nie

34. Rozporządzenie Rady Ministrów z dnia 18 grudnia 2012 r. w sprawie szczegółowych zasad gospodarki finansowej uczelni publicznych (Dz. U. z 2012r. poz. 1533 )

Warunek konieczny

Spełniony: Tak/Nie

35. Rozporządzenie Ministra Pracy i Polityki Społecznej z dnia 29 stycznia 2013 r. w sprawie należności przysługujących pracownikowi zatrudnionemu w państwowej lub samorządowej jednostce sfery budżetowej z tytułu podróży służbowej ( Dz. U. z 2013 poz. 167 )

Warunek konieczny

Spełniony: Tak/Nie


Wymagania w zakresie zgodności z aktami wewnętrznymi SGHZamawiający na Etapie Analizy Funkcjonalnej wskaże, które elementy podanych wewnętrznych aktów wewnętrznych SGH będą wymagały implementacji w Systemie.

L.p.(1)

Regulacja wewnętrzna SGH(2)

Komentarz(3)

1. Uchwała Senatu SGH nr 258 z dnia 30 maja 2007 r. w sprawie warunków i trybu kierowania za granicę pracowników, doktorantów i studentów SGH w celach naukowych, dydaktycznych i szkoleniowychZmieniający:Uchwała Senatu SGH nr 371/2010 zmieniająca uchwałę nr 258 Senatu SGH z dnia 30 maja 2007 r. w sprawie warunków i trybu kierowania za granicę pracowników, doktorantów i studentów SGH w celach naukowych, dydaktycznych i szkoleniowych.

2. Uchwała Senatu SGH nr 196/2009 w sprawie przyznawania pracownikom SGH dodatkowych wynagrodzeń pochodzących ze środków pozadotacyjnych.Zmieniający:Uchwała Senatu SGH nr 451 z dnia 25 maja 2011 r. zmieniająca uchwałę nr 196 Senatu SGH z dnia 21 października 2009 r. w sprawie przyznawania pracownikom SGH dodatkowych wynagrodzeń pochodzących ze środków pozadotacyjnych.

3. Uchwała nr 300 Senatu SGH z dnia 24 października 2007 r. w sprawie ustalenia podziału czasu pracy nauczycieli akademickichZmieniający:Uchwała nr 302 Senatu SGH z dnia 26 maja 2010 r. zmieniająca uchwałę nr 300 Senatu SGH z dnia 24


października 2007 r. w sprawie ustalenia podziału czasu pracy nauczycieli akademickich.4. Uchwała Senatu SGH nr 349/2010 w sprawie wprowadzenia Regulaminu wynagradzania za prace na rzecz

projektów finansowanych ze źródeł zewnętrznych Zmieniający:Uchwała Senatu SGH nr 419/2011 zmieniająca uchwałę nr 349 Senatu SGH z dnia 13 października 2010 r. w sprawie wprowadzenia Regulaminu wynagradzania za prace na rzecz projektów finansowanych ze źródeł zewnętrznych

5. Uchwała nr 143 Senatu SGH z dnia 9 października 2013 r. w sprawie stosowania 50% stawki kosztów uzyskania przychodów ze stosunku pracy w Szkole Głównej Handlowej w Warszawie.

6. Obwieszczenie nr 1 Rektora z dnia 11 października 2013 r. w sprawie ogłoszenia tekstu jednolitego statutu Szkoły Głównej Handlowej w Warszawie.

7. Regulaminu premiowania pracowników niebędących nauczycielami akademickimi – Zarządzenie Rektora SGPIS nr 12/1989.

8. Regulamin Pracy w SGH – Zarządzenie Rektora 30/2007.Zmieniający:– Zarządzenie Rektora nr 25 z dnia 27 marca 2009 r. w sprawie zmiany w Regulaminie pracy w SGHZmieniający:– Zarządzenie Rektora nr 55 z dnia 14 października 2013 r. w sprawie zmiany i ujednolicenia Regulaminu pracy w SGH (wchodzi w życie 1 listopada 2013 r.). Tekst jednolity Regulaminu pracy w SGH stanowi załącznik do zarządzenia.Zmieniający:- Zarządzenie Rektora nr 27 z dni 20 czerwca 2014 w sprawie zmiany Regulaminu pracy

9. Zarządzenie nr 43 z dnia 11 czerwca 2007 r. w sprawie wprowadzenia w życie „Polityki rachunkowości”.Zmieniający:Zarządzenie nr 19 z dnia 25 kwietnia 2013 r. zmieniające zarządzenie Rektora nr 43 z dnia 11 czerwca 2007 r. w sprawie wprowadzenia w życie "Polityki rachunkowości"


ZmieniającyZarządzenie nr 21 z dnia 15 maja 2014 r. zmieniające zarządzenie Rektora nr 43 z dnia 11 czerwca 2007 r. w sprawie wprowadzenia w życie "Polityki rachunkowości"ZmieniającyZarządzenie nr 24 z dnia 30 maja 2014 r. zmieniające zarządzenie Rektora nr 43 z dnia 11 czerwca 2007 r. w sprawie wprowadzenia w życie "Polityki rachunkowości"

10. Zarządzenie Rektora nr 65 z dnia 27 października 2009 r. w sprawie zasad przyznawania pomocy z Zakładowego Funduszu Świadczeń Socjalnych.Zmieniający:Zarządzenie Rektora nr 55 Rektora z dnia 22 października 2012 r. zmieniające zarządzenie Rektora nr 65 z dnia 27 października 2009 r. w sprawie zasad przyznawania pomocy z Zakładowego Funduszu Świadczeń Socjalnych.

11. Zarządzenie Rektora nr 25 z dnia 30 maja 2014 r. w sprawie zasad funkcjonowania i finansowania działalności studenckiej.

12. Zarządzenie Rektora nr 11/2010 w sprawie trybu zgłaszania, składania podpisów i obiegu dokumentów w projektach badawczych i edukacyjnych realizowanych w SGH w ramach programów międzynarodowych, w tym programów Unii Europejskiej.

13. Zarządzenie nr 19 Rektora z dnia 24 kwietnia 2012 r. w sprawie tworzenia i prowadzenia studiów doktoranckich.Zmieniające:Zarządzenie nr 5 z dnia 5 lutego 2014 r. zmieniające zarządzenie Rektora nr 19 z dnia 24 kwietnia 2012 r. w sprawie tworzenia i prowadzenia studiów doktoranckich

14. Zarządzenie Rektora nr 55/2010 w sprawie rejestracji i archiwizacji umów zawieranych w projektach realizowanych w SGH w ramach programów operacyjnych UE.

Utraciło moc tylko w zakresie dotyczącym rejestrowania umów


15. Zarządzenie Rektora nr 38/2010 w sprawie zawierania umów cywilnoprawnych na prace o charakterze pozaakademickimZmieniający:Zarządzenie nr 48 Rektora zmieniające zarządzenie nr 38 Rektora z dnia 9 sierpnia 2010 r. w sprawie zawierania umów cywilnoprawnych na prace o charakterze pozaakademickim.

Utraciły moc tylko w zakresie dotyczącym rejestrowania umów

16. Zarządzenie Rektora nr 39/2010 w sprawie zawierania umów w zakresie działalności twórczej.Zmieniający:Zarządzenie nr 49 Rektora z dnia 29 października 2010 zmieniające zarządzenie Rektora nr 39 z dnia 9 sierpnia 2010 r. w sprawie zawierania umów w zakresie działalności twórczejZmieniający:Zarządzenie nr 2 Rektora z dnia 18 stycznia 2012 r.zmieniające zarządzenie Rektora nr 39 z dnia 9 sierpnia 2010 r. w sprawie zawierania umów w zakresie działalności twórczej.

Utraciły moc tylko w zakresie dotyczącym rejestrowania umów

17. Zarządzenie Rektora nr 43/2010 w sprawie pomocy Uczelni dla pracowników podnoszących kwalifikacje zawodowe.Zmieniający:Zarządzenie Rektora nr 57 z dnia 9 grudnia 2011 r.zmieniające zarządzenie Rektora nr 43 z dnia 20 października 2010 r. w sprawie pomocy Uczelni dla pracowników podnoszących kwalifikacje zawodowe.

18. Pismo Okólne Rektora nr 3/2010 w sprawie przechowywania i zabezpieczenia dokumentów.

19. Zarządzenie Rektora nr 20/2011 w sprawie zawierania umów związanych z prowadzeniem naukowych prac badawczych.

Utraciło moc tylko w zakresie dotyczącym rejestrowania umów

20. Decyzja Rektora nr 16 z dnia 6 kwietnia 2011 r. w sprawie powołania Komisji ds. Majątku


Zmieniający:Decyzja Rektora nr 5 z dnia 28 stycznia 2013 r. zmieniająca decyzję Rektora nr 16 z dnia 6 kwietnia 2011 r. w sprawie powołania Komisji ds. Majątku.

21. Zarządzenie Rektora 8/2012 w sprawie tworzenia oraz szczegółowych zasad prowadzenia studiów podyplomowych.

22. Zarządzenie Rektora nr 9/2012 w sprawie zawierania umów o prowadzenie zajęć dydaktycznych. Utraciło moc tylko w zakresie dotyczącym rejestrowania umów

23. Zarządzenie Rektora nr 32 z dnia 8 lipca 2014 r. w sprawie wprowadzenia Regulaminu składania i obiegu wniosków dotyczących zamówień oraz udzielania zamówień publicznych w Szkole Głównej Handlowej w Warszawie i Regulaminu pracy komisji przetargowej.

24. Zarządzenie Rektora nr 29z dnia 27 czerwca 2014 r. w sprawie Regulaminu przyznawania stypendium doktoranckiego oraz zwiększenia stypendium doktoranckiego w Szkole Głównej Handlowej w Warszawie (z zastrzeżeniem § 3).

25. Zarządzenie Rektora nr 35/2013 w sprawie opłat za wynajem pokoi w domach studenta SGH w okresie od 1 lipca do 22 września 2013 r.

26. Zarządzenie Rektora nr 61 z dnia 23 października 2013 r. w sprawie wprowadzenia Regulaminu organizacyjnego SGH.ZmieniającyZarządzenie nr 10 z dnia 27 marca 2014 r. zmieniające zarządzenie Rektora nr 61 z dnia 23 października 2013 r. w sprawie wprowadzenia Regulaminu organizacyjnego SGH

27. Zarządzenie Rektora nr 22 z dnia 16 maja 2014 r. w sprawie wprowadzenia Centralnego Rejestru Umów.


28. Zarządzenie nr 8 z dnia 3 marca 2014 r. w sprawie zawierania umów o używanie pojazdów niebędących własnością SGH do celów służbowych w ramach delegacji krajowej lub zagranicznej.

29. Zarządzenia Kanclerza nr 3/2010 w sprawie zasad korzystania z oprogramowania komputerowego.

30. Zarządzenia Kanclerza nr 9/2010 w sprawie wprowadzania zadaniowego czasu pracy dla pracowników Biura ds. Funduszy Europejskich.

31. Zarządzenia Kanclerza nr 6/2011 w sprawie obiegu dokumentów w SGH.orazZarządzenie Kanclerza nr 1/2013 w sprawie uszczegółowienia niektórych procedur obiegu dokumentów w formie papierowej w SGH.

32. Zarządzenie Kanclerza nr 6 z dnia 9 czerwca 2014 r. w sprawie wysokości w sprawie opłat za wynajem pokoi w domach studenta SGH w okresie od 1 lipca do 23 września 2014 r.

33. Zarządzenie Kanclerza nr 2 z dnia 12 marca 2014 r. w sprawie kodów identyfikacyjnych w SGH.

34. Zarządzenie Rektora nr 13 z 11 kwietnia 2008 w sprawie określenia wzoru dokumentów i zasad kierowania za granicę pracowników, doktorantów i studentów SGH, w celach naukowych, dydaktycznych, szkoleniowych.


35. Zarządzenie Rektora nr 47z 17 listopada 2003 w sprawie wprowadzenia w życie "Instrukcji obiegu dokumentów finansowo-księgowych".


Zasady przeprowadzania testów Systemu

L.p.

(1)

Wymaganie

(2)

Komentarz

(3)

1. W ramach testowania Systemu zostaną przeprowadzone Testy Wewnętrzne Wykonawcy. Celem Testów Wewnętrznych Wykonawcy będzie kompleksowa weryfikacja systemu przez Wykonawcę pod kątem zgodności z SIWZ, Ofertą oraz Specyfikacją Funkcjonalną. Testy zostaną przeprowadzone przed przekazaniem Systemu do testów u Zamawiającego i potwierdzony pisemnie.

2. W ramach testowania Systemu zostaną przeprowadzone Testy Jednostkowe. Celem Testów Jednostkowych będzie poddanie sprawdzeniu konfiguracji i poprawności funkcjonowania pojedynczych operacji i funkcji systemu. Stwierdzone w ramach testów nieprawidłowości zostaną usunięte. Poprawione elementy zostaną poddane kolejnemu Testowi Jednostkowemu weryfikującemu.

3. W ramach testowania Systemu zostaną przeprowadzone Testy Integracyjne. Celem Testów Integracyjnych będzie sprawdzenie poprawności działania wszystkich interfejsów pomiędzy systemami oraz przenoszenia i konwersji dokumentów pomiędzy nimi.

4. W ramach testowania Systemu zostaną przeprowadzone Testy Regresji. Celem Testów Regresji jest sprawdzenie, czy zmiany wprowadzone w systemach informatycznych objętych zakresem wdrożenia (np. w związku z poprawą zidentyfikowanych błędów) nie mają negatywnego wpływu na procesy określone w Specyfikacji Funkcjonalnej i działanie Systemu zgodne z SIWZ, Ofertą i Specyfikacją Funkcjonalną.


5. W ramach testowania Systemu, jako element procedury odbioru zostaną przeprowadzone Testy Akceptacyjne. Celem Testów Akceptacyjnych będzie kompleksowa weryfikacja Systemu przez Zamawiającego pod kątem zgodności z SIWZ, Ofertą oraz Specyfikacją Funkcjonalną, tj. sprawdzenie procesów i funkcjonalności określonych w Specyfikacji Funkcjonalnej, włącznie z testami poprawności działania interfejsów pomiędzy systemami oraz przenoszenia i konwersji dokumentów pomiędzy nimi. W ramach Testów Akceptacyjnych, zostaną również zweryfikowane następujące aspekty działania Systemu:

a) Role i uprawnienia użytkowników Systemu,

b) Migracja danych,

c) Wydajność - Celem jest weryfikacja czasu odpowiedzi Systemu pod kątem zgodności z wymaganiami dotyczącymi wydajności Systemu wskazanymi w SIWZ ,

d) Bezpieczeństwo - celem jest weryfikacja Systemu pod kątem zgodności z wymaganiami dotyczącymi bezpieczeństwa wskazanymi w SIWZ. Przedmiotem testów jest zbadanie odporności Systemu na znane zagrożenia. Testy bezpieczeństwa będą wykonywane na Systemie oraz na elementach towarzyszących takich jak system operacyjny, serwer baz danych, serwer aplikacyjny, sieć.

e) Infrastrukturalne, techniczne i administracyjne, - celem jest weryfikacja w szczególności:

i. procedury wykonania kopii bezpieczeństwa Systemu

ii. procedury odtworzenia Systemu z kopii bezpieczeństwa

iii. testów współpracy z peryferiami użytkownika, np. wydruk na drukarki sieciowe lub lokalne.


iv. testów połączenia klienta z serwerem, czy zostały spełnione standardy wymiany danych (np. szyfrowanie).

v. działania Systemu na stacji roboczej Zamawiającego – instalacja, uruchomienie.

6. Szczegółowy plan testów, scenariusze i przypadki testowe zostaną przygotowane przez Wykonawcę i zatwierdzone przez Zamawiającego na etapie Analizy Funkcjonalnej.

7. Za przeprowadzenie Testów Wewnętrznych Wykonawcy odpowiada Wykonawca. Pozostałe testy zostaną przeprowadzone przez Zamawiającego przy wsparciu Wykonawcy, które w szczególności będzie dotyczyć następujących aspektów:

a) zdefiniowanie w Systemie ról i uprawnień,b) przygotowanie w Systemie danych testowych,c) udzielanie, bez zbędnej zwłoki, osobom testującym porad w zakresie obsługi Systemu.

8. Wyniki testów systemu zostaną udokumentowane przez Wykonawcę oraz Zamawiającego w formie raportów z testów.

9. Warunkiem zakończenia testów części lub całości Systemu i rozpoczęcia procedury odbioru określonej części lub całości Systemu jest zaakceptowanie przez Zamawiającego wyników testów części lub całości Systemu, udokumentowane w formie stosownego protokołu.


Wymagania w zakresie Dokumentacji projektowej

L.p.

(1)

Wymaganie

(2)

Komentarz

(3)

1. Wykonawca opracuje i dostarczy dokumentację merytoryczną oraz zarządczą dotyczącą wdrożenia Systemu.

2. W skład dokumentacji merytorycznej wchodzą:

a) Specyfikacja Funkcjonalna systemu,b) Dokumentacja konfiguracji systemu,c) Dokumentacja techniczna projektu wdrożenia (dokumentacja modyfikacji standardowej

funkcjonalności, prac instalacyjnych, konfiguracyjnych, programistycznych itd.),d) Instrukcje kluczowych użytkowników systemu w podziale na zakresy funkcjonalne,e) Instrukcja dla Administratora Systemu,f) Instrukcja API,g) Materiały szkoleniowe zgodnie z wymaganiami w SIWZ,h) Dokumentacja testów zgodnie z wymaganiami w SIWZ,

3. Instrukcja użytkownika kluczowego powinna zawierać następujące informacje:

a) Obsługa systemu – wprowadzenie i podstawowe zasady,b) Opis wszystkich funkcjonalności systemu i ich obsługi przez użytkownika,


c) Podstawowe czynności konfiguracyjne możliwe do wykonania z poziomu użytkownika biznesowego,

4. Instrukcje stanowiskowe dla użytkowników końcowych powinny zawierać opis sposobu realizacji ich codziennych zadań w systemie zgodnie z ich zakresem zadań i obowiązków.

5. Instrukcja Administratora Systemu powinna zawierać następujące informacje:

a) Obsługa systemu – wprowadzenie i podstawowe zasady,b) Opis funkcjonalności służących do zarządzania systemem w tym m.in. bieżącego monitorowanie pracy

systemu, przydzielania uprawnień, zakładania kont, ról, wprowadzania zmian w konfiguracji systemu, oceny poprawności działania systemu,

c) Opis działania i obsługa mechanizmów wymiany danych wymaganych w SIWZ,d) Opis czynności okresowych związanych z administracją systemem,e) Procedury postępowania w przypadku nieprawidłowości działania systemu,f) Najczęściej występujące zagadnienia i sposoby ich rozwiązywania, tzw. FAQ dla Administratora Aplikacji.g) Architektura techniczna systemu wdrożonego u Zamawiającego,h) Opis systemu,i) Procedura instalacji systemu,j) Procedury utrzymania systemu (np. w przypadku konieczności wykonywania cyklicznie powtarzających

się czynności, rutynowe zadania Administratora technicznego, zakładanie kont, modyfikacja praw itp.)k) Procedury rozruchu i zatrzymania systemu,l) Procedury monitorowania pracy systemu,m) Procedury backupu i archiwizacji systemu (w tym archiwizacja logów), wykaz danych które powinny być

archiwizowane, zalecane cykle archiwizacji itp. (nie dotyczy obsługi systemu do backupu, tylko czynności specyficznych dla systemu będącego przedmiotem zamówienia).

n) Procedury odtwarzania z backupu,o) Procedura postępowania w przypadku awarii i odtwarzania systemu (tzw. „Disaster Recovery Plan”).


7. Instrukcja API powinna zawierać opis parametrów wejściowych i wyjściowych oraz logiki działania API wraz z przykładami użycia.

8. Docelowy skład i zakres dokumentacji zarządczej będzie wynikał z metodyki prowadzenia projektu wdrożenia systemu zaproponowanej przez Wykonawcę. W ramach dokumentacji zarządczej Wykonawca przygotuje, dostarczy i będzie aktualizował w trakcie wdrożenia systemu przynajmniej następujące dokumenty:

a) Plan projektu wdrożenia,b) Harmonogram projektu wdrożenia,c) Rejestr ryzyk,d) Rejestr zagadnień projektowych,e) Cykliczne raporty z postępu prac,

9. Ogólne wymagania Zamawiającego dotyczące tworzenia i dostarczania dokumentacji przez Wykonawcę:

a) Wszelka dokumentacja będzie opracowana w języku polskim,b) Dokumentacja w wersji elektronicznej oraz papierowej,c) Dokumentacja ma uwzględniać specyfikę wdrożenia i konfiguracji systemu u Zamawiającego, a nie tylko

standardową funkcjonalność, d) Szczegółowy zakres dokumentacji zostanie uzgodniony przez Wykonawcę z Zamawiającym w trakcie

opracowywania Specyfikacji Funkcjonalnej.


Elementy Platformy Sprzętowej

minimalne wymagania sprzętowe, w oparciu o które ma działać Oprogramowanie:

1. Serwer aplikacji ( w przypadku wykorzystania architektury 3-warstwowej)

Komponent Wymagania minimalneProcesor QUAD CORE XEON X5460 3.16GHzPamięć operacyjna 32 GBKarta sieciowa 1 Gbit/sSystem operacyjny Microsoft Windows 2008 Server Enterprise

2. Serwer bazodanowy

Procesor QUAD CORE XEON X5460 3.16GHzPamięć operacyjna 32 GBKarta sieciowa 1 Gbit/sSystem operacyjny Microsoft Windows 2008 Server EnterpriseSystem bazodanowy Microsoft SQL Server 2008 Standard

3. Stacje robocze


Komponent Wymagania minimalneProcesor Procesor Intel/AMD - zegar 2GHzPamięć operacyjna 3 GBZasoby dyskowe 200 GBKarta graficzna Karta grafiki - rozdzielczość 1280x1024,Karta dźwiękowa TakKarta sieciowa 100/1000 Mbit/sSystem operacyjny Microsoft Windows 7 Professional PL 32 bit


Documents

Administracja | Szkoła Główna Handlowa w Warszawie€¦ · Web viewWarunek konieczny Spełniony: Tak/Nie 173. Definiowanie przekierowania środków (przepływów finansowych)