Istotne Postanowienia Umowy - BIP Urząd Marszałkowski

Załącznik nr 1 do umowy
Szczegółowy opis Przedmiotu Umowy
Specyfikacja wymagań systemu Centralny Rejestr Umów dla
UrzęduMarszałkowskiego Województwa Dolnośląskiego
Strona 1/68
Załącznik nr 1 do umowy
Spis treści
Spis treści ..................................................................................................................2
Cel dokumentu ........................................................................................................................... 5
I - Kontekst przedsięwzięcia ...................................................................................5
Opis sytuacji bieżącej ................................................................................................................ 5
Zidentyfikowane / główne problemy ........................................................................................ 5
Wizja ........................................................................................................................................... 5
Misja ............................................................................................................................................ 5
Cele biznesowe............................................................................................................................ 6
Opis planowanego stanu docelowego ....................................................................................... 6
Glosariusz ................................................................................................................................... 6
II - Wymagania.........................................................................................................7
Wymagania dotyczące wdrożenia systemu .............................................................................. 7
W ramach wdrożenia wykonawca wykona następujące czynności: ...................................... 8
Dodatkowe szkolenia. ............................................................................................................ 8
Pomoc hot line. ...................................................................................................................... 8
Przypadki testowe. ................................................................................................................. 8
Wymagania funkcjonalne ....................................................................................................... 10
Wymagania niefunkcjonalne .................................................................................................. 12
Operatywność ...................................................................................................................... 12
Niezawodność ...................................................................................................................... 14
Wydajność............................................................................................................................ 14
Bezpieczeństwo.................................................................................................................... 15
Wsparcie i zgodność ............................................................................................................ 16
Wymagania infrastrukturalne............................................................................................... 17
Założenia implementacyjne ................................................................................................. 18
Wymagania dodatkowe ........................................................................................................... 19
III - Specyfikacja rozwiązania ..............................................................................20
Aktorzy ....................................................................................................................20
Role ............................................................................................................................................ 20
Administrator Systemu ........................................................................................................ 20
Osoba Akceptująca .............................................................................................................. 20
Osoba Akceptująca Rekomendację...................................................................................... 21
Osoba Dekretująca ............................................................................................................... 21
Osoba Dysponująca ............................................................................................................. 21
Osoba Kontrasygnująca ....................................................................................................... 21
Osoba Merytoryczna ............................................................................................................ 21
Osoba Obserwująca ............................................................................................................. 21
Osoba Opiniująca ................................................................................................................. 21
Osoba Opiniująca (WZP) ..................................................................................................... 21
Osoba Rejestrująca............................................................................................................... 21
Systemy ..................................................................................................................................... 22
Agent powiadomień ............................................................................................................. 22
Strona 2/68
Załącznik nr 1 do umowy
Silnik raportowy................................................................................................................... 22
System danych o kontrahentach........................................................................................... 22
System finansowo-księgowy ............................................................................................... 23
System katalogowy .............................................................................................................. 23
System obsługujący zamówienia publiczne......................................................................... 23
Procesy biznesowe ..................................................................................................24
Decyzja o Opiniowaniu w DBiF .............................................................................................. 24
Istotne Postanowienia Umowy ................................................................................................ 25
Opiniowanie dokumentu ......................................................................................................... 26
Opiniowanie dokumentu w DBiF ........................................................................................... 28
Projekt umowy/Projekt Aneksu ............................................................................................. 29
Umowa Właściwa/Aneks ......................................................................................................... 32
Zamówienie............................................................................................................................... 35
Systemowe Przypadki Użycia ...............................................................................37
Akceptacja Dokumentu ........................................................................................................... 37
UC007: Akceptacja dokumentu ........................................................................................... 37
UC007a: Masowa akceptacja dokumentów ......................................................................... 38
UC007b: Kontrasygnata dokumentu.................................................................................... 39
Obsługa Kar Umownych, Wierzytelności i Zamknięcia Umowy ........................................ 40
UC025: Zamknięcie umowy ................................................................................................ 40
UC027: Edycja wierzytelności ............................................................................................ 41
UC031: Edycja kary umownej ............................................................................................. 42
Tworzenie i edycja dokumentu ............................................................................................... 43
UC001: Edycja metryki dokumentu .................................................................................... 43
UC001a: Edycja treści dokumentu ...................................................................................... 46
UC003: Anulowanie dokumentu ......................................................................................... 46
UC008: Wyszukanie dokumentu ......................................................................................... 47
UC016: Edycja dysponentów .............................................................................................. 47
UC019: Generowanie umowy właściwej............................................................................. 48
UC020: Rejestracja umowy właściwej ................................................................................ 49
UC023: Seryjne tworzenie dokumentów na podstawie szablonu ........................................ 49
UC029: Wydruk dokumentu ................................................................................................ 50
UC032: Archiwizacja dokumentu........................................................................................ 50
UC036: Edycja wysokości składek na ubezpieczenia społeczne ........................................ 51
UC037: Edycja kontrahenta ................................................................................................. 51
UC038: Wyszukanie kontrahenta ........................................................................................ 52
Opiniowanie Dokumentu ........................................................................................................ 52
UC006: Zaopiniowanie dokumentu ..................................................................................... 53
UC010: Edycja komentarza do treści dokumentu ............................................................... 54
UC012: Dekretacja dokumentu............................................................................................ 54
UC014: Edycja zadań do wykonania ................................................................................... 55
UC035: Prezentacja listy zmian ........................................................................................... 56
UC038: Edycja zastępstwa .................................................................................................. 56
Powiadomienia i Raporty ........................................................................................................ 57
UC033: Wygenerowanie raportu ......................................................................................... 57
UC034: Wysłanie powiadomienia ....................................................................................... 58
Strona 3/68
Załącznik nr 1 do umowy
Interfejsy i Integracja .............................................................................................................. 58
IUC003: Pobranie podania z ZP .......................................................................................... 59
IUC005: Pobranie listy pracowników z SK ......................................................................... 60
IUC006: Wysłanie dokumentu do FK ................................................................................. 60
IUC008: Wyszukanie kontrahenta w SDK .......................................................................... 61
IUC009: Wysłanie dokumentu do ZP .................................................................................. 62
IUC010: Synchronizacja słowników z FK .......................................................................... 62
IUC011: Anulowanie lub odrzucenie podania w ZP ........................................................... 63
Definicje powiadomień i raportów .......................................................................64
Powiadomienia ......................................................................................................................... 64
Raporty ..................................................................................................................................... 65
Lista raportów w systemie ................................................................................................... 65
Model Domeny........................................................................................................66
Otoczenie IT - interfejsy zewnętrzne ...................................................................67
Macierz śledzenia ..................................................................................................................... 68
Strona 4/68
Załącznik nr 1 do umowy
Cel dokumentu
Celem dokumentu jest specyfikacja projektu rozwiązania informatycznego Centralny Rejestr Umów, w
skrócie CRU.
I - Kontekst przedsięwzięcia
Opis sytuacji bieżącej
Obecnie w UMWD procesy opiniowania i kontrasygnaty dokumentów są realizowane w sposób ręczny,
przy wykorzystaniu wyłącznie papierowych dokumentów.
Zidentyfikowane / główne problemy
Obsługa procesu opiniowania i kontrasygnaty dokumentów w oparciu o papierowy obieg dokumentów jest
nieoptymalna. Do głównych zidentyfikowanych problemów zaliczyć można:
 Niską wydajność procesu
 Wysoką podatność na błędy ludzkie
 Brak realnej możliwości pomiaru procesu (czasy wykonywanych zadań)
 Długi czas analizy papierowej dokumentacji
Wizja
System CRU będzie wspomagał procesy związane ze wspieraniem obsługi dokumentów w całym zakresie
ich cyklu życia, a w szczególności:
 przygotowania dokumentów,
 ich opiniowania i akceptacji,
 kontroli dostępu do utworzonych w systemie dokumentów,
 rejestracji dokumentów,
 archiwizacji dokumentów,
 zarządzania wierzytelnościami i karami umownymi.
Misja
System CRU ma zautomatyzować i usprawnić proces opiniowania i kontrasygnaty dokumentów przy
równoczesnym zwiększeniu poziomu bezpieczeństwa, dzięki wykorzystaniu zintegrowanego z istniejącą
infrastrukturą w zakresie kontroli dostępu.
Strona 5/68
Załącznik nr 1 do umowy
Cele biznesowe
Do głównych celów biznesowych stawianych przed rozwiązaniem należą:

eliminacja papierowego obiegu dokumentów,

skrócenie czasu i usprawnienie procesu opiniowania

standaryzacja procesu opiniowania i kontrasygnaty we wszystkich zaangażowanych komórkach
organizacyjnych
 wydajna i rzetelna kontrola dostępu do procesowanych dokumentów
Opis planowanego stanu docelowego
Założeniem wdrożenia systemu CRU jest automatyzacja procesu opiniowania i kontrasygnaty
dokumentów. Docelowo proces ten od strony użytkowników będzie realizowany w systemie workflow,
który w oparciu o zdefiniowane procesy będzie przekazywał odpowiednie zadania do realizacji przez
pracowników o określonych rolach. Wykorzystanie istniejącego systemu nadawania i kontroli uprawnień
pozwoli na rzetelną i spójną kontrolę dostępu do procesowanych dokumentów.
Glosariusz
Akceptacja - Czynność wykonywana przez Osobę Akceptującą, potwierdzająca zgodność Dokumentu
z wymaganiami danej Komórki Organizacyjnej. Jest warunkiem przejścia Dokumentu do kolejnego kroku
w procesie.
Akceptacja Rekomendacji - Czynność wykonywana w DBiF, ze względu na dwuetapową akceptację
Dokumentu w tym Departamencie. Polega na akceptacji rekomendacji wydanej przez Osobę Opiniującą i
przekazaniu Dokumentu do Osoby Akceptującej lub Kontrasygnującej.
Anulowanie - Czynność wykonywana przez Osobę Merytoryczną. Anulowanie przerywa i kończy
prace nad Dokumentem.
Cofnięcie - Czynność wykonywana przez Osobę Akceptującą Rekomendację, Osobę Akceptującą lub
Kontrasygnującą. Cofnięty Dokument wraca do Osób Opiniujących w odpowiedniej Komórce
Organizacyjnej (Cofnięcie Dokumentu przez Osobę Kontrasygnującą w DBiF może spowodować
Cofnięcie Dokumentu do Osoby Opiniującej w Wydziale Kadr, Szkolenia i Spraw Socjalnych).
Dokument - Podstawowy obiekt biznesowy w systemie CRU. Reprezentuje różne typy dokumentów w
obiegu UMWD: projekt umowy, projekt aneksu, umowa właściwa, aneks, zamówienie, istotne
postanowienia umowy.
Dziennik Zdarzeń - Zapis zdarzeń zachodzących wewnątrz systemu CRU. Dziennik zdarzeń musi
udostępniać funkcje audytowe (kto, kiedy i jakie zdarzenie wywołał) ze względu na kontrolowany dostęp
do dokumentów. Zdarzenia mogą być spowodowane wewnętrzną logiką systemu lub interakcją z
systemami zewnętrznymi.
Komentarz - Informacja dotycząca treści Dokumentu, dodawana przez Osobę Opiniującą, Osobę
Akceptującą Rekomendację, Osobę Akceptującą i Osobę Kontrasygnującą, przeznaczona dla innych Osób
Opiniujących lub Osoby Merytorycznej. Wyróżnione są dwa typy komentarzy: powiązany z Dokumentem
jako obiektem biznesowym i powiązany z jednostką redakcyjną treści Dokumentu.
Strona 6/68
Załącznik nr 1 do umowy
Komórka Dodatkowa - Jednostka organizacyjna wymagana do zaopiniowania Dokumentu spoza listy
komórek: Wydział Organizacyjno-Prawny, Wydział Promocji Województwa, Wydział Informatyki i
Systemów Informatycznych, Wydział Zamówień Publicznych, Wydział Kadr, Szkolenia i Spraw
Socjalnych oraz Departament Budżetu i Finansów. Określenie Komórki Dodatkowej wymusza
opiniowanie Dokumentu w danej komórce według standardowego procesu opiniowania.
Komórka Merytoryczna - Komórka organizacyjna w UMWD, uprawniona do tworzenia dokumentów
w CRU.
Komórka Organizacyjna - Jednostka organizacyjna w UMWD. Aktualną strukturę organizacyjną
przechowuje system katalogowy.
Kontrahent - Podmiot (osoba fizyczna, osoba prawna lub jednostka organizacyjna nie posiadająca
osobowości prawnej np. stowarzyszenie), użyty w modelu domenowym.
Kontrasygnata - Czynność potwierdzająca zabezpieczenie środków w planie finansowym UMWD
dokonywana na Dokumentach rodzących zobowiązania pieniężne. Czynność ta potwierdza zgodność
Dokumentu z wymaganiami danej Komórki Organizacyjnej.
Odrzucenie - Czynność wykonywana przez Osobę Akceptującą, oznaczająca brak zgodności
Dokumentu z wymaganiami danej Komórki Organizacyjnej. Odrzucony Dokument wraca do Komórki
Merytorycznej, w której został utworzony i po korekcie przechodzi ponownie cały proces akceptacji.
Zadanie - Zlecenie wykonania czynności Osobie Opiniującej, niezbędnej do zaopiniowania Dokumentu
(np. zaopiniowanie podstawy prawnej).
II - Wymagania
Wymagania dotyczące wdrożenia systemu
Specjalne wymagania, które muszą być spełnione w trakcie okresu przejściowego, w którym będzie trwało
wdrożenie rozwiązania. Po zakończeniu wdrożenia wymagania te przestają być potrzebne.
Wdrożenie Systemu realizowane będzie przez Wykonawcę co najmniej w 3 Etapach:
1. Etap I - Opracowanie projektu technicznego Systemu zgodnie z wytycznymi zawartymi w
załączniku nr 1 do umowy do 30 dni kalendarzowych od dnia podpisania umowy;
2. Etap II - Przygotowanie wersji instalacyjnej Systemu wraz z dokumentacją do w pełni
automatycznego zainstalowania przez Zamawiającego, wdrożenie oraz produkcyjne
uruchomienie Systemu do 100 dni kalendarzowych od dnia zakończenia Etapu I;
3. Etap III - Przygotowanie i przekazanie Zamawiającemu dokumentacji Systemu, przekazanie
Zamawiającemu kodów źródłowych do oprogramowania wytworzonego lub/i dostarczonego
przez Wykonawcę w trakcie realizacji Systemu wraz z dokumentacją techniczną, szkolenia
użytkowników oraz administratorów Systemu nie później niż 20 dni kalendarzowych od
zakończenia Etapu II. Dopuszcza się aby szkolenia były prowadzone równolegle z Etapem I i II.
Strona 7/68
Załącznik nr 1 do umowy
W ramach wdrożenia wykonawca wykona następujące czynności:
a) Opracowanie wizji graficznej Systemu zgodnie z wymaganiami opisu przedmiotu umowy i
przedstawienie jej w formie dokumentu do akceptacji Zamawiającego
b) Wstępna analizę systemową oraz projekt techniczny, który będzie zawierał co najmniej:
i. specyfikację komponentów zgodną z szablonem stanowiącym załącznik nr 5 umowy.
Przedstawiona specyfikacja powinna być kompletna i spójna przez co Zamawiający rozumie, że
nie pozostawia wątpliwości co do sposobu działania poszczególnych komponentów oraz
architektury rozwiązania
ii. specyfikację konfiguracji aplikacji stanowiąca załącznik nr 6 do umowy.
c) Weryfikacja środowiska systemowego Zamawiającego,
d) Implementacja systemu wraz z przekazaniem wersji instalacyjnej do instalacji w środowisku
testowym Zamawiającego wraz z instrukcją instalacyjną. Instalacja w środowisku testowym
realizowana będzie przez Zamawiającego.
e) Szkolenie użytkowników i administratorów
f) Testy akceptacyjne przeprowadzone wspólnie z Zamawiającym
g) Poprawa błędów i przygotowanie kolejnej wersji instalacyjnej
h) Ponowne testy akceptacyjne przeprowadzone wspólnie z Zamawiającym.
i) Szkolenie użytkowników Systemu w siedzibie Zamawiającego na danych wprowadzonych dla
celów szkolenia. Szkolenie powinno odbywać się w grupach zbliżonych tematycznie osobno dla
każdego modułu/obszaru i obejmować pełen zakres wymaganych przez użytkownika
funkcjonalności Systemu. Harmonogram szkolenia zostanie ustalony oddzielnie dla każdej grupy
szkoleniowej w porozumieniu z Zamawiającym, aby zapewnić niezakłóconą pracę
Zamawiającego. Minimalna liczba godzin szkoleniowych powinna wynosić 40. Zamawiający
przewiduje przeszkolenie do 120 osób w zakresie niezbędnym do prawidłowej obsługi Systemu.
Dodatkowe szkolenia.
Dodatkowe szkolenia w formie asyst technicznych we wskazanych przez Zamawiającego z
odpowiednim wyprzedzeniem dniach.
a) Asysty będą odbywać się na zasadzie obecności osoby szkolącej podczas wykonywania
kluczowych zadań Systemu i obserwacji użytkowników oraz udzieleniu na bieżąco konsultacji i
kontroli poprawności działań i wprowadzonych danych przez użytkowników.
b) Minimalna ilość dni asyst powinna wynosić 10 dni (bez dodatkowej opłaty w ramach gwarancji).
Pomoc hot line.
Pomoc telefoniczna (hot line) w procesie eksploatacji systemu obejmująca wyjaśnienia i porady
analityków i techników Wykonawcy w godzinach pracy Zamawiającego (bez dodatkowej opłaty w
ramach gwarancji).
Przypadki testowe.
W ramach wdrożenia wykonawca przygotuje szczegółowy plan testów akceptacyjnych wraz z opisem
akceptacyjnych przypadków testowych prezentujących scenariusze oraz punkty kontroli
podstawowych ścieżek przejścia dla podprocesów będących przedmiotem specyfikacji. Podstawę do
przygotowania akceptacyjnych przypadków stanowią opisane w niniejszej dokumentacji przypadki
użycia oraz reguły biznesowe. Lista przypadków akceptacyjnych wraz z planem testów
Strona 8/68
Załącznik nr 1 do umowy
akceptacyjnych powinna zawierać szereg przypadków testowych sprawdzających poprawność
działania rozwiązania dla różnych wariantów wprowadzanych danych z uwzględnieniem funkcji
realizowanych przez web services lub innych funkcji bazodanowych. Przygotowane scenariusze
testowe powinny obejmować scenariusze podstawowe i alternatywne z zastrzeżeniem, że minimalny
stopień szczegółowości scenariuszy testowych określony został w przypadkach użycia
przedstawionych w niniejszej specyfikacji.
W szczególności należy uwzględnić:
 Dane poprawne typowe dla danego scenariusza
 Dane poprawne brzegowe oraz szczególne przypadki
 Dane błędne
Podstawą akceptacji przygotowanych scenariuszy akceptacyjnych przypadków użycia są odpowiednie
przypadki użycia oraz wymagania funkcjonalne przedstawione w specyfikacji rozwiązania.
Specyfikacja przypadków użycia określa sposób oraz minimalny zakres prezentowanych informacji.
W ramach wdrożenia wykonawca przygotuje raport z wyników testów akceptacyjnych zawierający
opis przypadków testowych i informację o pozytywnym bądź negatywnym wyniku testów, według
poniższego wzoru.
RAPORT Z WYNIKÓW TESTÓW AKCEPTACYJNYCH
Lp.
przypadki testowe
wynik testu
pozytywny
negatywny
...
...
...
req Wymagania dotyczące w drożenia systemu
TR001: Wsparcie
wdrożeniowe
A
TR002: Zasilenie systemu
danymi
Rysunek: Wymagania dotyczące wdrożenia systemu
TR001: Wsparcie wdrożeniowe
Po dniu startu produktywnego, oczekiwane jest wsparcie powdrożeniowe na miejscu przez okres jednego
miesiąca.
TR002: Zasilenie systemu danymi
System będzie posiadał możliwość importu danych z obecnie wykorzystywanych przez Zamawiającego
systemów. Wykonawca określi formaty oraz struktury danych do prawidłowego zasilenia systemu
danymi.
Strona 9/68
Załącznik nr 1 do umowy
Wymagania funkcjonalne
req Wymagania funkcj onalne
FR004: Komentarze
FR001: Archiwizacja
dokumentów
FR002: Automatyczna
dekretacja
FR003: Edytor tekstów
FR005: Kontrola wersji
FR006: Kopie robocze
FR007: Kopiowanie
parametrów
FR008: Liczba osób
opiniujących
FR009: Model uprawnień
FR010: Numeracja
dokumentów
FR011: Seryjne tworzenie
umów
FR012: Szablony
dokumentów
FR013: Usuwanie komentarzy
FR014: Zadania
FR015: Zastępstwa
FR016: Załączniki binarne
FR017: Ścieżka obiegu
FR018: Kalkulacja składek na
ubezpieczenia społeczne
FR019:
Kontrahenci
Rysunek: Wymagania funkcjonalne
FR001: Archiwizacja dokumentów
System musi umożliwiać archiwizację dokumentów zgodnie z ustawą z dnia 17 lutego 2005 r. o
informatyzacji działalności podmiotów realizujących zadania publicznych oraz aktami wykonawczymi
do ustawy.
FR002: Automatyczna dekretacja
System powinien mieć możliwość określania osoby dekretowanej w danej Komórce Organizacyjnej, na
którą automatycznie dekretowany będzie wybrany typ dokumentu.
FR003: Edytor tekstów
System musi umożliwiać tworzenie i edycję treści dokumentu w edytorze struktury logicznej z
predefiniowanej listy jednostek redakcyjnych.
Edytor powinien pozwalać co najmniej na:
 personalizację i dostosowania do indywidualnych wymagań użytkowników:
 tworzenie dokumentów w standardzie XML/Open XML;
 budowanie dokumentów składających się z jednostek redakcyjnych takich jak np.: artykuł, paragraf,
ustęp, punkt, litera, tiret;
 dodawanie jednostki redakcyjnej, która oznaczona jest niestandardowo np. duża litera, cyfra rzymska,
itp.
 dodawanie obrazów w dokumentach, a także w nagłówkach i stopkach dokumentów (np. logotypy)
 automatyczne tworzenie tekstów ujednoliconych dokumentów, system musi mieć zaimplementowaną
pełną dynamiczną obsługę tzw. "znaczników nowelizujących" realizowaną w standardzie XML;
 podgląd ujednoliconego tekstu dokumentu z uwzględnieniem proponowanych zmian;
 zarządzanie wersją oraz rejestrowanie historii zmian w dokumencie na każdym etapie jego
przetwarzania;
 korzystanie z predefiniowanych szablonów oraz bazy klauzul zweryfikowanych i zalecanych do
stosowania w całej organizacji np. zapisy dotyczące siły wyższej, standardowych warunków
świadczenia usług serwisowych, z możliwością modyfikacji określonych pól;
Strona 10/68
Załącznik nr 1 do umowy








możliwość definiowania pól które zostaną uzupełnione przed wygenerowaniem umowy właściwej,
np. dane wykonawcy wyłonionego w postępowaniu przetargowym, data zawarcia, numer, kwota, itp.
możliwość tworzenia tabel, import tabel bezpośrednio z programu Excel, Word
dodawanie załączników
definiowanie własnych ustawień podglądu i wydruku dokumentu;
eksport do formatu PDF z DOCX (z obsługą linków do załączników), Word (z obsługą linków),
HTML (z obsługą linków) oraz PDF (bez obsługi linków);
możliwość zapisywania/importowanie do systemu plików w formatach: XML, PDF, RTF, doc, docx,
odt, odts, xls, xlsx;
generowanie umów na podstawie szablonu dla wielu kontrahentów – korespondencja seryjna.
wyszukiwanie pełno-tekstowe we wszystkich dokumentach, ich fragmentach oraz załącznikach.
FR004: Komentarze
System musi umożliwiać tworzenie komentarzy na dwóch poziomach: w odniesieniu do całego
dokumentu i w odniesieniu do wybranej jednostki redakcyjnej tekstu dokumentu. Komentarze do danej
jednostki redakcyjnej powinny być wyświetlane w kolejności chronologicznej.
FR005: Kontrola wersji
System musi wspierać kontrolę wersji dokumentów. Kontrola wersji musi umożliwiać generowanie
dziennika zmian pomiędzy wersjami w formacie XML. Prezentacja różnic pomiędzy dwiema dowolnymi
wersjami dokumentu powinna być wyświetlana w formie przyjaznej dla użytkownika - równoległy układ
zmienionych jednostek redakcyjnych ('było'-'jest').
FR006: Kopie robocze
System musi umożliwiać tworzenie, przechowywanie i odczyt kopii roboczych dokumentów, widocznych
wyłącznie dla ich właściciela.
FR007: Kopiowanie parametrów
System musi umożliwiać kopiowanie parametrów tego samego typu (np. dane finansowe, dane do
ubezpieczeń społecznych) z innych wcześniej wpisanych w szczegółach metryki dokumentu.
FR008: Liczba osób opiniujących
System musi umożliwiać określenie, czy do dalszego procesowania dokumentu niezbędne są opinie
wszystkich osób, na które zadekretowany został dokument. Musi istnieć możliwość domyślnego
ustawienia niniejszej zasady.
FR009: Model uprawnień
Dokumenty powinny obsługiwać rozszerzone uprawnienia:
1.
dokument widoczny dla wszystkich pracowników Komórki Organizacyjnej
2.
dokument widoczny tylko dla pracowników, którym zadekretowano ten dokument i którzy muszą
wykonać na nim operacje (opiniowanie, akceptacje, odrzucenia, cofnięcia, kontrasygnaty, akceptacja
rekomendacji).
FR010: Numeracja dokumentów
Numer dla umowy musi być generowany automatycznie przez system i musi być zgodny z szablonem
numeracji obowiązującym w UMWD
FR011: Seryjne tworzenie umów
System musi umożliwiać seryjne tworzenie dokumentów na podstawie zapisanego wcześniej szablonu
umowy. ze zdefiniowanym zestawem pól danych i możliwością podłączania różnych źródeł danych o
Strona 11/68
Załącznik nr 1 do umowy
Kontrahentach.
FR012: Szablony dokumentów
System musi umożliwiać zapisanie dokumentu jako szablonu, na bazie którego system umożliwi później
utworzenie umowy nowego dokumentu. Nowe umowy będą mogły być tworzone również na podstawie
dokumentów zarchiwizowanych
FR013: Usuwanie komentarzy
System musi automatycznie zapisywać kopię dokumentu po każdej Akceptacji i zmieniać wersję
dokumentu na wyższą według ustalonego wzorca. Po zapisaniu kopii system usuwa komentarze do
jednostek redakcyjnych treści dokumentu i zadania powiązane z dokumentem. System musi umożliwiać
przeglądanie komentarzy z poprzednich wersji z dokładnością do jednostki redakcyjnej.
FR014: Zadania
System musi umożliwiać tworzenie Zadań przez Osoby Akceptujące i Dekretujące oraz przypisywanie
ich Osobom Opiniującym z określeniem terminu wykonania zadania.
FR015: Zastępstwa
System musi umożliwiać użytkownikowi przekazanie swojej roli innemu użytkownikowi na wybrany
okres czasu oraz nadanie innej roli pracownikowi przez przełożonego lub administratora.
FR016: Załączniki binarne
System musi mieć możliwość dołączania plików binarnych, ich opisywania i wiązania z dokumentem (np.
dokumenty rejestrowe kontrahenta, protokoły odbioru).
FR017: Ścieżka obiegu
System powinien umożliwić kopiowanie danych o osobach zadekretowanych i komórkach, w których
opiniowany był projekt umowy/projekt aneksu do umowy właściwej/aneksu z możliwością korekty tych
danych.
FR018: Kalkulacja składek na ubezpieczenia społeczne
System musi dysponować algorytmem obliczania wysokości składek na ubezpieczenia społeczne na
podstawie danych z oświadczenia do celów podatkowych i ubezpieczeń złożonego przez Zleceniobiorcę
oraz musi umożliwiać ręczną korektę wysokości tych składek uprawnionej osobie z Wydziału Kadr,
Szkolenia i Spraw Socjalnych.
FR019: Kontrahenci
System musi umożliwiać zarządzanie kontrahentami, na rzecz których podpisywane są dokumenty, w
szczególności ich wyszukiwanie, dodawanie, edycję i usuwanie z możliwością użycia danych wielu
kontrahentów dla jednego dokumentu.
Wymagania niefunkcjonalne
Operatywność
Czy aplikacja jest zrozumiała dla użytkowników? Wymagania dotyczące użyteczności określają, w jakim
stopniu użytkownicy mogą określić, czy aplikacja rzeczywiście zaspokaja ich potrzeby, łatwość nauki
obsługi aplikacji, oraz użyteczność samej aplikacji. Należy położyć duży nacisk na intuicyjność i łatwość
obsługi aplikacji.
Strona 12/68
Załącznik nr 1 do umowy
NFR001: Szybkość użytkowania
Interfejs użytkownika powinien wspierać szybką obsługę systemu i ułatwiać dostęp do poszukiwanej
informacji przy jak najmniejszej ilości czynności wykonywanych przez użytkownika (mała ilość kliknięć
myszy - zasada 3, max 4 kliknięć myszy), przy zachowaniu zrozumiałego dla użytkownika stylu
komunikacji.
NFR002: Poziom zaawansowania użytkownika
System przeznaczony jest dla osób, których poziom zaznajomienia z obsługą komputera można określić
w skali jako 2/5. Obsługa aplikacji nie może wymagać od użytkownika wiedzy ponadprzeciętnej.
NFR003: Łatwość opanowania obsługi
System powinien być możliwy do opanowania w ciągu 8h treningu /samoszkolenia z dokumentem
treningowym dla użytkowników ze średnią znajomością obsługi komputera, w taki sposób, iż będzie on w
stanie pracować z systemem samodzielnie, opcjonalnie korzystając z systemu pomocy.
NFR004: Walidacja formularzy
System waliduje dane wprowadzane w formularzach przez użytkowników, w przypadku błędów
wyświetla stosowne informacje wskazujące użytkownikowi, gdzie jest błąd i jak go poprawić.
NFR005: Materiał treningowy
W ramach dokumentacji systemu zostanie dołączona dokumentacja treningowa, która zawierać będzie
opis scenariuszy realizowanych przez system w formie instrukcji typu „krok po kroku” ilustrowanej
ekranami systemu.
NFR006: Dokumentacja
System powinien zawierać następujące elementy dokumentacji:
1. Dokumentacja systemu
Opis architektury systemu pokazujący podstawowe komponenty oraz użyte technologie oraz
dokumentację kodu źródłowego (komentarze), pozwalającą na wygenerowanie dokumentacji dla
potrzeb utrzymania systemu.
2. Dokumentacja instalacyjna zawierająca szczegółową procedurę instalacji systemu na serwerze oraz
niezbędnej konfiguracji oprogramowania stacji roboczych, z uwzględnieniem ewentualnych
wymagań w zakresie komponentów koniecznych do prawidłowego działania oraz wymagań
dotyczących parametrów technicznych.
3. Dokumentacja użytkownika
Dokumentacja opisująca funkcjonalności systemu oraz opisy procesów, które są przez niego
realizowane.
4. System Pomocy
Pomoc on-line, zgodnie z opisem w stosownym punkcie.
Dokumentacja musi spełniać wewnętrzne standardy UMWD. Odpowiednie standardy zostaną przekazane
Dostawcy.
NFR007: Pomoc On-line
Każdy ekran aplikacji powinien być opatrzony kontekstową pomocą, którą można wywołać poprzez
kliknięcie w ikonę Pomocy. Pomoc powinna zawierać informację na temat:
1. funkcji ekranu (cel funkcjonalności)
2. miejsca danej funkcjonalności w procesie (warunki wstępne, efekt funkcjonalności)
3. znaczenia prezentowanych/wymaganych informacji (opis prezentowanych/wymaganych pól)
4. formatu wprowadzanych danych
Strona 13/68
Załącznik nr 1 do umowy
5. dozwolonego zakresu wartości dla prezentowanych/wymaganych pól
NFR008: Spójność
Interfejs użytkownika ma wspierać szybką obsługę systemu i umożliwić dostęp do informacji w sposób
ergonomiczny przy zachowaniu zrozumiałego dla użytkownika stylu komunikacji. Wszelkie akcje w
systemie odbywają się w sposób spójny, dzięki czemu użytkownik na zasadzie analogii jest w stanie
wykonać akcję, której nigdy wcześniej nie przeprowadził.
NFR009: Szata graficzna
Wygląd graficzny aplikacji zgody ze standardem uzgodnionym w ramach osobnego projektu dla aplikacji
SharePoint, tożsamy ze wzorami identyfikacji wizualnej stosowanej w UMWD.
Niezawodność
Czy aplikacja będzie dostępna wtedy, kiedy jest potrzebna? Wymagania dotyczące niezawodności
obejmują zdolność do przywrócenia dostępności aplikacji w przypadku wystąpienia awarii, czas pracy, lub
wystąpienia problemu w interfejsach.
NFR010: Maksymalny współczynnik częstości uszkodzeń
Nie zdefiniowano
NFR011: Maksymalny czas przestoju
Maksymalny czas przestoju to 8 godzin roboczych.
NFR012: Łatwość odzyskiwania
System powinien zostać dostarczony z instrukcją postępowania w przypadku potrzeby odzyskania
dostępności aplikacji w przypadku awarii z wykorzystaniem kopii zapasowych.
Niezbędny czas potrzebny do uruchomienia systemu z kopii zapasowej i odtworzenia danych, które
zostały wprowadzone w systemie od czasu stworzenia ostatniej kopii zapasowej do zaistnienia błędu nie
może wynosić więcej niż 8 godzin roboczych.
System powinien zapisywać przebieg swojego działania w postaci dziennika zdarzeń, w szczególności w
zakresie wyjątków oraz błędów, co ułatwi zdiagnozowanie błędu.
NFR013: Maksymalna liczba usterek/ błędów
System nie może zostać dostarczony z błędami krytycznymi ani błędami istotnymi.
Jako błąd krytyczny uznaje się sytuację, w której błąd uniemożliwia zrealizowanie podstawowej
funkcjonalności systemu lub generuje wpis o błędzie. statusie „krytyczny” w logu systemowym lub
aplikacyjnym
Jako błąd istotny uznaje się sytuację, w której błąd utrudnia w stopniu istotnym skorzystanie z
funkcjonalności podstawowej systemu, lub uniemożliwia skorzystanie z nie podstawowej
funkcjonalności systemu lub generuje wpis o błędzie w logu systemowym lub aplikacyjnym
Wydajność
Czy aplikacja dostarcza akceptowalny poziom wydajności w ramach dostępnych zasobów? Wymagania
dotyczące wydajności dotyczą czasu niezbędnego na wykonanie określonych zadań oraz poziom
wykorzystania dostępnych zasobów.
NFR014: Wolumen danych
Strona 14/68
Załącznik nr 1 do umowy
Wolumeny:
 Liczba umów zawieranych rocznie w UMWD to ok. 3500, z czego ok. 1000 to umowy unikalne a
reszta - generowane za pomocą wydruku seryjnego
Wymagania obligatoryjne nakładają obowiązek przechowywania danych przez minimum 5 lat
(wymagania szczegółowe zgodne z JRWA - Rozporządzenie Prezesa Rady Ministrów z dnia 18
stycznia 2011 i wymaganiami poszczególnych projektów). Dane te muszą być dostępne w systemie
do odczytu (patrz zdefiniowane raporty).
NFR015: Przepustowość
System będzie obsługiwał do 100 równoczesnych sesji użytkowników, jeśli chodzi o klienta biurowego
NFR016: Czas odpowiedzi
Ze względu na brak odczuwania przestoju w pracy z systemem, czas reakcji systemu powinien być nie
dłuższy niż 1 sekunda. Wskazany średni czas reakcji to 0,1 sekundy, który sprawia wrażenie
natychmiastowej reakcji systemu.
NFR017: Użycie zasobów
System powinien przewidywać zapotrzebowanie zasobów, aby zapewnić pracę spełniającą przedstawione
kryteria.
W przypadku konieczności wykonania przetwarzania w stopniu istotnie obciążającym zasoby
infrastruktury, powinny one zostać zaplanowane do wykonania poza godzinami pracy użytkowników.
NFR018: Działanie w czasie przeciążenia
System w momencie przekroczenia przewidywanej ilości równoczesnych użytkowników pozwala
realizować czynności użytkownikom. Dopuszczalny jest spadek wydajności, zwiększenie czasów
odpowiedzi na żądania użytkowników. Niedopuszczalne są błędy lub ograniczenia funkcjonalności.
Bezpieczeństwo
Czy aplikacja zapobiega umyślnym nadużyciom? Wymagania dotyczące bezpieczeństwa obejmują
zdolność do zapewnienia odpowiedniego poziomu poufności przechowywanych informacji, integralności
zapisanych w aplikacji danych, możliwość zweryfikowania, czy i przez kogo podjęte zostały aktywności, a
także mechanizmy autentykacji i autoryzacji użytkowników.
NFR019: Ochrona danych wrażliwych
System musi obsługiwać przypadki szczególnej ochrony danych i umożliwiać określanie zakresu danych
widocznych dla zdefiniowanych grup użytkowników.
NFR020: Podpis elektroniczny
Obsługa podpisu niekwalifikowanego podpisu elektronicznego zgodnie ze standardem PKCS#11
(Zamawiający posiada własne CA) oraz podpisu elektronicznego kwalifikowanego.
Wsparcie podpisu elektronicznego w systemie tworzenia dokumentów oraz podpisywanie plików:
 możliwość podpisania dokumentów wraz z załącznikami
 podpis elektroniczny umieszczany na dokumentach w dowolnej formie (pieczątka, faksymile)
 możliwe "hurtowe" podpisywanie wielu dokumentów - 100 dokumentów (do 300 KB każdy)
powinny być podpisywanie w czasie nie dłuższym niż 5 min.
NFR021: System loguje akcje użytkowników
Strona 15/68
Załącznik nr 1 do umowy
System zapisuje akcje wykonywane przez użytkowników, dzięki czemu możliwe jest sprawdzenie, kto
uczestniczył w procesie przetwarzania dokumentu. Na podstawie dzienników zdarzeń można
zidentyfikować kto i kiedy zmienił wartość pola w obiekcie domenowym. Stara i nowa wartość pola są
również logowane.
NFR022: Wewnętrzne bezpieczeństwo
System wykorzystuje SSL.
System wykorzystuje SSO – wraz z mechanizmem automatycznego uwierzytelniania użytkowników i
operatorów przy użyciu mechanizmów uwierzytelniania Windows w oparciu o Active Directory.
Zarządzanie poziomami uprawnień użytkowników do poszczególnych modułów aplikacji odbywać się
będzie z wykorzystaniem grup MS Sharepoint, bez zależności z poziomem uprawnień użytkownika
stosowanym w ActiveDirectory.
NFR023: Zewnętrzne bezpieczeństwo
W przyszłości system może zostać udostępniony zewnętrznym podmiotom, np. kancelariom prawnym
obsługującym UMWD. W tym celu należy zabezpieczyć system przed niepowołanym dostępem z
zewnątrz oraz przed podsłuchaniem komunikatów wysyłanych z zewnętrznych klientów do serwera.
Wsparcie i zgodność
Czy aplikacja będzie skutecznie współpracować z innymi aplikacjami w tym samym środowisku?
Wymagania dotyczące zgodności obejmują wymagania dotyczące potrzeby zastąpienia innej aplikacji,
zdolność do koegzystencji z innymi aplikacjami, oraz możliwość interakcji z innymi aplikacjami.
Aplikacja powinna mieć możliwość współpracy z innymi systemami z wykorzystaniem technologii Web
Services. Powinna również zapewniać współpracę z MS Reporting Services oraz Analysis Services.
Zamawiający informuje, że posiada opracowane polityki Architecture & Governance w zakresie
zarządzania platformą Sharepoint 2010.
NFR024: Łatwość instalacji
Niezbędny czas potrzebny do instalacji systemu nie może wynosić więcej niż 8 godzin roboczych (nie
wliczając w to czasu potrzebnego na przygotowanie infrastruktury, czyli np. instalacji systemów
operacyjnych, baz danych, etc.).
NFR025: Utrzymanie
Dostawca zapewnia wsparcie gwarancyjne przez 12 miesięcy od dnia podpisania protokołu odbioru.
NFR026: Łatwość konfiguracji
Konfiguracja systemu nie wymaga zmian w kodzie aplikacji, administratorzy po stronie UMWD
posiadają m.in. co najmniej następujące możliwości konfiguracji systemu:
 Szablony wiadomości, komunikatów i powiadomień
 Etykiety pól w GUI
 Treść pomocy w GUI
 Konfiguracja powiązanych komponentów aplikacyjnych i infrastruktury (np. IP/port serwera bazy
danych).
 Zmiana uprawnień użytkowników systemu
NFR027: Łatwość testowania
System dostarczony jest ze zbiorem testów funkcjonalnych (na poziomie GUI), które pozwalają na
testowanie funkcjonalności systemu na środowisku testowym UMWD. Zbiór testów będzie
wykorzystywany przez UMWD przy weryfikacji nowych wersji aplikacji (np. poprawianych błędów,
tworzenia nowych funkcjonalności).
Strona 16/68
Załącznik nr 1 do umowy
Wymagania infrastrukturalne
Czy aplikacja może zostać zainstalowana w innym środowisku? Wymagania infrastrukturalne obejmują
łatwość instalacji oraz deinstalacji aplikacji, rodzaje różnych środowisk, w których aplikacja może zostać
uruchamiana oraz łatwość migracji do innego środowiska, a także wymagania dotyczące otoczenia
aplikacji.
NFR028: Dostarczenie rozwiązania
Rozwiązanie powinno być dostarczone w formie Solucji SharePoint wraz ze skryptami pozwalającymi na
automatyczną instalację rozwiązania na środowisku z zainstalowaną platformą SharePoint oraz stworzoną
dedykowaną web aplikacją.
NFR029: Serwery
Środowisko Sharepoint UWMD składa się z następujących grup serwerów:
 Środowisko produkcyjne
 Środowisko deweloperskie
 Środowisko testowe
Środowisko produkcyjne
Środowisko produkcyjne składa się z następujących serwerów:
 Serwer aplikacyjny (MS Sharepoint 2010 wersja 14.0.6126.5000)
 Serwer bazodanowy (MS SQL Server 2008 R2)
Oba serwery pracują pod kontrolą system MS Windows Server 2008 R2 Enterprise SP1
Środowisko deweloperskie
Środowisko deweloperskie składa się z następujących serwerów:
 Serwer aplikacyjny (MS Sharepoint 2010 wersja 14.0.6029.1000)
 Serwer bazodanowy (MS SQL Server 2008 R2)
 Serwer MS Visual Studio Team Foundation Server 2012
 Serwer bazodanowy (MS SQL Server 2008 R2)
Oba serwery pracują pod kontrolą system MS Windows Server 2008 R2 Enterprise SP1
Środowisko testowe
Środowisko testowe składa się z następujących serwerów:
 Serwer aplikacyjny (MS Sharepoint 2010 wersja 14.0.6106.5002)
 Serwer bazodanowy (MS SQL Server 2008 R2)
Oba serwery pracują pod kontrolą system MS Windows Server 2008 R2 Enterprise SP1
NFR030: Sieci
Nie zdefiniowano
NFR031: Urządzenia peryferyjne
Pracownicy Urzędu Marszałkowskiego Województwa Dolnośląskiego korzystają z zewnętrznych
urządzeń oraz kart na potrzeby wykonania podpisu cyfrowego.
NFR032: Web Services/API
Wskazane użycie Web Services oraz API jako mechanizmów integracji z zewnętrznymi systemami.
NFR044: Klienci
System dostępny będzie jako aplikacja WWW. Klienci korzystają z przeglądarek internetowych różnych
Strona 17/68
Załącznik nr 1 do umowy
dostawców. Konieczne zapewnienie poprawnej pracy z wszystkimi popularnymi przeglądarkami, w
szczególności:
1.
Internet Explorer w wersji 7 oraz nowszej,
2.
Firefox w wersji 3 i nowszej,
3.
Google Chrome,
4.
Opera w wersji 9 i nowszej.
Założenia implementacyjne
Czy aplikacja może być efektywnie modyfikowana po wdrożeniu, aby spełniać wymagania stawiane przez
zmieniające się potrzeby? Wymagania dotyczą utrzymania aplikacji, możliwości zmiany komponentu bez
wpływu na pozostałe komponenty, zdolności do ponownego wykorzystania istniejących komponentów,
oraz możliwości sprawnego testowania aplikacji i diagnozowania występujących problemów oraz zdolność
do wprowadzania zmian bez powodowania nieoczekiwanych awarii.
NFR033: Kostka OLAP
Budowa kostki OLAP pozwalającej na generację elastycznych raportów z danych zgromadzonych w
CRU.
NFR034: Środowisko
Dedykowana aplikacja będzie tworzona przy użycia języków programowania .NET (dla środowiska
SharePoint). Zamawiający dostarczy dokumentację istniejącej architektury dla SharePoint w UMWD a
Wykonawca zrealizuje zgodnie z nimi aplikację. Zarówno serwery, jak i stacje klienckie będą
funkcjonować w systemie operacyjnym Windows. Dla serwerów będzie to Windows Serwer 2008, dla
baz danych MS SQL 2008 R2 (minimum) natomiast dla stacji klienckich musi to być Windows XP z SP3
lub nowszy. Językiem środowiska będzie język polski.
NFR035: Wsparcie platform
Aplikacja będzie oparta o posiadane już przez UMWD rozwiązanie Microsoft Sharepoint 2010.
NFR036: Standardy
Dopuszczalne jest wykorzystanie oprogramowania i bibliotek typu OpenSource. Zalecane jest użycie
otwartych standardów, np. XML, OpenXML czy WS-*. Zamawiający posiada oprogramowanie Datapolis
Workbox, które umożliwia graficzne modelowanie procesów biznesowych na platformie Microsoft
SharePoint.
NFR037: Interfejsy systemu
System powinien udostępniać następujące interfejsy:
GUI – aplikacja webowa dla użytkowników sytemu.
URI – umożliwia integracje z systemem po przez adresy URI (np. link do raportu lub dokumentu,
możliwy do przekazania np. pocztą e-mail) w autoryzowany sposób.
Web Services – umożliwia integracje z innymi systemami.
API - umożliwia integracje z innymi systemami oraz zmianę stanu obiektów biznesowych w systemie
CRU.
NFR038: Bazy danych
System będzie oparty o system zarządzania bazą danych MS SQL Server 2008 R2
Strona 18/68
Załącznik nr 1 do umowy
Wymagania dodatkowe
Wymagania niefunkcjonalne nie ujęte w poprzednich pakietach wymagań niefunkcjonalnych, np. aspekty
formalne i prawne związane z aplikacją.
NFR039: Spójny rozwój aplikacji
Aby zapewnić elastyczność i możliwość szybkiej realizacji oczekiwań użytkowników biznesowych
systemu, interfejs użytkownika (GUI) powinien zawierać zdefiniowane obszary, służące do wyświetlania
niezdefiniowanych funkcjonalności, które zostaną stworzone w przyszłości. Celem określenia takich
obszarów jest zachowanie spójności interfejsu użytkownika oraz ujednolicenie wyglądu i formatu
wdrożonych w przyszłości zmian w aplikacji.
NFR040: Prawa do kodu
Zamawiający nabywa prawa licencyjne do aplikacji oraz kodu źródłowego zgodnie z § 6 Umowy.
NFR041: Informacje o zmianach
Dostawca udostępnia Zamawiającemu dostęp do oprogramowania typu issue management dającego
wgląd w historię oraz stan aktualny realizacji zmian w systemie. Wraz z każdą nową wersją Wykonawca
dostarcza pełny opis zmian dokonanych w aplikacji oraz, jeśli to niezbędne, aktualizuje dokumentacje.
NFR042: Modułowa budowa
Pożądane jest, aby system posiadał budowę modułową, zapewniającą większą elastyczność oraz
łatwiejsze zarządzanie i utrzymanie w stosunku do rozwiązań monolitycznych (silosowych). Budowa
modułowa powinna być zrealizowana na poziomie komponentów aplikacyjnych. Zmiany w
poszczególnych komponentach nie powinny wymuszać zmian w pozostałych komponentach.
Sugerowane jest, aby system posiadał jeden komponent główny dostarczający wszystkie podstawowe
funkcjonalności biznesowe systemu oraz dodatkowe, wymienialne komponenty, które rozszerzają
funkcjonalności systemu.
NFR043: Skalowalność
System jest skalowalny. Umożliwia obsłużenie większych wolumenów danych lub obsługę większej
ilości użytkowników poprzez zwiększenie dostępnych dla Aplikacji zasobów.
Strona 19/68
Załącznik nr 1 do umowy
III - Specyfikacja rozwiązania
Aktorzy
Role
uc Pracow nicy
Osoba Obserw uj ąca
«abstract»
Administrator Systemu
Osoba Opiniuj ąca (WZP)
Osoba Merytoryczna
Osoba Opiniuj ąca
Osoba Rej estruj ąca
Osoba Dysponuj ąca
Osoba Dekretuj ąca
Osoba Akceptuj ąca
Osoba Kontrasygnuj ąca
Diagram: Pracownicy
Administrator Systemu
Użytkownik o najwyższych uprawnieniach w systemie. Może nadawać i odbierać uprawnienia innym
użytkownikom systemu, edytować szablony wiadomości, komunikatów i powiadomień, etykiety pól w
GUI oraz treść pomocy w GUI.
Sposób implementacji w systemie roli musi uwzględniać fakt, że Administrator Systemu nie jest
równoznaczny z administratorem Sharepoint (funkcją realizowaną przez dział IT).
Osoba Akceptująca
Osoba potwierdzająca zgodność dokumentu z wymogami danej komórki organizacyjnej (departamentu lub
wydziału). Najczęściej rolę tę pełni dyrektor danej komórki.
Strona 20/68
Załącznik nr 1 do umowy
Osoba Akceptująca Rekomendację
Osoba w Departamencie Budżetu i Finansów, odpowiedzialna za akceptację rekomendacji Osoby
Opiniującej.
Osoba Dekretująca
Osoba dokonująca dekretacji zadania na pracowników w danej komórce organizacyjnej. Najczęściej rolę tę
pełni dyrektor lub sekretariat danej komórki organizacyjnej.
Osoba Dysponująca
Dysponent środków. Najczęściej dyrektor danej komórki organizacyjnej.
Osoba Kontrasygnująca
Osoba kontrasygnująca Dokument (rolę tę pełni Skarbnik Województwa lub osoba upoważniona).
Osoba Merytoryczna
Osoba wprowadzająca Dokument do systemu CRU. Właściciel Dokumentu. Jedyna osoba z uprawnieniem
do modyfikacji treści dokumentu.
Osoba Obserwująca
Osoba Obserwująca ma prawo podglądu dokumentów procesowanych w podległych Komórkach
Organizacyjnych.
Osoba Opiniująca
Osoba opiniująca Dokument w danej komórce organizacyjnej po dekretacji.
Osoba Opiniująca (WZP)
Osoba opiniująca Dokument w Wydziale Zamówień Publicznych po dekretacji. Posiada prawo do
Odrzucania Dokumentów.
Osoba Rejestrująca
Osoba rejestrująca zawartą umowę w rejestrze umów. Obsługuje kary umowne i wierzytelności.
Najczęściej pracownik Wydziału Organizacyjno-Prawnego lub Osoba Merytoryczna.
Strona 21/68
Załącznik nr 1 do umowy
Systemy
uc Systemy
System obsługuj ący
zamów ienia publiczne
System katalogow y
wyślij dane
zgodnie z
modelem
domenowym
udostępnij dane o
pracownikach i
strukturze
organizacyjnej
udostępnij dane o
podaniu
udostępnij
kontrahenta
System CRU
System danych o
kontrahentach
synchronizuj słowniki
Agent pow iadomień
wygeneruj raport
udostępnij szablony
raportów
wyślij dane
zgodnie z
modelem
domenowym
System finansow o-księgow y
Silnik raportow y
Diagram: Systemy
Agent powiadomień
Część systemu CRU odpowiedzialna za wysyłanie powiadomień o zdarzeniach do uprawnionych
użytkowników. W dalszej części dokumentu analitycznego oznaczony skrótem AP.
Silnik raportowy
Zewnętrzny system informatyczny, umożliwiający wykorzystanie danych CRU przechowywanych w
formie kostek OLAP jako źródła danych do raportów. W dalszej części dokumentu analitycznego
oznaczony skrótem SR.
System danych o kontrahentach
System obecnie przechowujący dane o istniejących Kontrahentach w organizacji. Wyłącznie udostępnia
dane o istniejących Kontrahentach w ramach jednostronnej komunikacji na potrzeby tworzenia lokalnej
bazy Kontrahentów w systemie CRU. W dalszej części dokumentu analitycznego oznaczony skrótem SDK.
Strona 22/68
Załącznik nr 1 do umowy
System finansowo-księgowy
System wspomagający pracę Departamentu Finansów i Budżetu oraz Wydziału Kadr, Szkolenia i Spraw
Socjalnych. W dalszej części dokumentu analitycznego oznaczony skrótem FK
System katalogowy
System implementujący usługę katalogową. Przechowuje informacje o użytkownikach i grupach
roboczych, a także strukturze organizacyjnej UMWD. Autoryzuje użytkowników. W dalszej części
dokumentu analitycznego oznaczony skrótem SK.
System obsługujący zamówienia publiczne
System informatyczny wspomagający obsługę zamówień publicznych. W dalszej części dokumentu
analitycznego oznaczony skrótem ZP.
Strona 23/68
Załącznik nr 1 do umowy
Procesy biznesowe
Decyzja o Opiniowaniu w DBiF
Business Process Decyzj a o Opiniow aniu w DBiF
Czy Dokument typu
Aneks/Projekt Aneksu?
TAK
NIE
Departament Budżetu i Finansów
NIE
NIE
NIE
OBLIGATORYJNA
TAK
Czy Aneks dotyczy
zwiększenia kwoty
wynikającej z umowy?
Obligatoryjne wypełnienie
parametrów finansowych
dokumentu
TAK
TAK
Pozytywna decyzja o
opiniowaniu w DBiF
TAK
Czy Aneks dotyczy
zmiany terminów
realizacji przedmiotu
umowy i nowy termin
wykracza poza rok
budżetowy?
Negatywna decyzja o
opiniowaniu w DBiF
NIE
NIE
Czy Aneks dotyczy zmiany
sposobu rozliczenia
finansowego umowy?
Czy Aneks dotyczy zmiany
terminów płatności?
Czy mimo tego, że
aneks(/projekt aneksu) nie
wymaga
kontrasygnaty/opiniowania
przekazać do DBiF?
Czy wydanie
opinii przez
DBiF jest
obowiązkowe?
TAK
FAKULTATYWNA
Fakultatywne wypełnienie
parametrów finansowych dokumentu
TAK
NIE
Czy podlega
zaopiniowaniu przez
DBiF?
Diagram: Decyzja o Opiniowaniu w DBiF
Schemat przedstawia proces decyzyjny dotyczący opiniowania Dokumentu w Departamencie Budżetu i
Finansów
Jeżeli Dokument jest Aneksem/Projektem Aneksu, to o ile dotyczy przynajmniej jednego z poniższych
zagadnień:
 zwiększenia kwoty wynagrodzenia wynikającego z umowy
 zmiany terminów realizacji przedmiotu umowy i nowy termin wykracza poza rok budżetowy,
 zmiany sposobu rozliczenia finansowego umowy,
 zmiany terminów płatności,
musi mieć wypełnione pola dotyczące parametrów finansowych umowy. W takim wypadku podlega
opiniowaniu przez DBiF. Jeżeli Aneks/Projekt Aneksu dotyczy innych zagadnień, nie podlega opiniowaniu
w DBiF, chyba że Osoba Merytoryczna podejmie decyzję o przekazaniu do DBiF mimo, że Aneks/Projekt
Aneksu nie wymaga Kontrasygnaty/Opiniowania przez DBiF tj. wybierze opcję, że wydanie opinii przez
Strona 24/68
Załącznik nr 1 do umowy
DBiF jest fakultatywne.
Jeżeli dokument jest innego typu niż Aneks/Projekt Aneksu, Osoba Merytoryczna podejmuje decyzję czy
dokument podlega zaopiniowaniu do DBiF. Jeżeli podejmie decyzję o przekazaniu do DBiF, Osoba
Merytoryczna musi zdefiniować, czy wydanie opinii przez DBiF jest obligatoryjne dla kompletności
procesu obiegu dokumentu (zgodnie z ustawą o finansach publicznych lub/i obowiązującymi w UMWD
procedurami) czy też, że jest fakultatywne czyli że wydanie opinii przez DBiF nie jest wymagane dla
dalszego biegu dokumentu.– Osoba Merytoryczna udziela odpowiedzi na pytanie „Czy wydanie opinii
przez DBiF jest obowiązkowe?” wybierając jedną z dwóch opcji: opinia obligatoryjna lub opinia
fakultatywna. W przypadku opinii obligatoryjnej Osoba Merytoryczna musi uzupełnić dane dotyczące
parametrów finansowych Dokumentu i Dokument podlega opiniowaniu w DBiF.
W przypadku opinii fakultatywnej Osoba Merytoryczna wypełnia obligatoryjne dla danego rodzaju
budżetu pola dotyczące parametrów finansowych Dokumentu (część pól wypełniana jest fakultatywnie) i
Dokument jest opiniowany w DBiF.
W przypadku, gdy Dokument jest innego typu niż Aneks/Projekt Aneksu i nie podlega zaopiniowaniu
przez DBiF, nie jest przekazywany do tej Komórki Organizacyjnej.
Istotne Postanowienia Umowy
UMWD
Wydział Zamówień Publicznych
Wydział Informatyki i Systemów
Informatycznych
Komórka Merytoryczna
Business Process Proces: Istotne Postanow ienia Umow y
NIE
Korekta dokumentu
NIE
Opiniowanie IPU
Utworzenie IPU
Generowanie umowy
właściwej
Archiwizacja IPU
Czy zaakceptowano?
TAK
TAK
Czy wymagana
opinia WI?
Czy zaakceptowano?
TAK
NIE
Opiniowanie IPU
TAK
Czy zaakceptowano?
Opiniowanie IPU
Diagram: Proces: Istotne Postanowienia Umowy
Proces obsługi Dokumentu typu Istotne Postanowienia Umowy rozpoczyna się w momencie utworzenia
nowego Dokumentu tego typu w systemie przez uprawnionego pracownika Komórki Merytorycznej.
Utworzony IPU podlega akceptacji przez Osobę Akceptującą w danej Komórce Organizacyjnej. Jeżeli IPU
został odrzucony, wraca do Osoby Merytorycznej i po odpowiedniej korekcie przechodzi ponownie proces
Strona 25/68
Załącznik nr 1 do umowy
akceptacji. W przypadku Akceptacji IPU przez Osobę Akceptującą w danej Komórce Organizacyjnej IPU
zostaje przekazany do Wydziału Informatyki i Systemów Informatycznych, o ile wymaga opinii tego
wydziału.
Przekazanie IPU do Wydziału Informatyki i Systemów Informatycznych uruchamia podproces
Opiniowanie Dokumentu. Po zaopiniowaniu IPU podlega Akceptacji przez Osobę Akceptującą w tym
Wydziale. Jeżeli IPU został odrzucony, wraca do Osoby Merytorycznej i po odpowiedniej korekcie
przechodzi ponownie proces akceptacji. W przypadku akceptacji IPU w Wydziale Informatyki i Systemów
Informatycznych IPU zostaje przekazany do Wydziału Zamówień Publicznych.
Przekazanie IPU do Wydziału Zamówień Publicznych uruchamia podproces Opiniowanie Dokumentu. Po
zaopiniowaniu IPU podlega Akceptacji przez Osobę Akceptującą. Jeżeli IPU został odrzucony, wraca do
Osoby Merytorycznej i po odpowiedniej korekcie przechodzi ponownie proces akceptacji.
W przypadku Akceptacji IPU przez Osobę Akceptującą w Wydziale Zamówień Publicznych zostaje
przekazany do Osoby Merytorycznej. Dokument zmienia status na ZAAKCEPTOWANY i nie może już
podlegać edycji.
Po Akceptacji IPU w Wydziale Zamówień Publicznych Osoba Merytoryczna może wygenerować na jego
podstawie Umowę Właściwą, procedowaną według odpowiedniego procesu, a następnie zarchiwizować
IPU (ze statusem ZAMKNIETY).
Opiniowanie dokumentu
Osoba Dekretująca
Business Process Podproces: Opiniow anie dokumentu
Czy dokument był
wcześniej dekretowany?
NIE
Dekretacja na
pracownika
Zadanie
Osoba Opiniująca
Komórka Organizacyjna
TAK
Dodanie komentarza
TAK
TAK
Opiniowanie
dokumentu
NIE
NIE
Wydanie
rekomendacji
Czy rekomendacja
negatywna?
Czy dodać komentarz?
KomentarzDoTekstu
Czy opinia wymaga
korekty?
Zapoznanie się z
opinią
TAK
Dodanie komentarza
NIE
KomentarzDoTekstu
Dodanie komentarza
Komentarz
Osoba Akceptująca
TAK
Czy dodać komentarz?
NIE
NIE
TAK
NIE
Akceptacja
dokumentu
Czy zaakceptowano?
Czy dodać komentarz?
TAK
Dodanie komentarza
Komentarz
Diagram: Podproces: Opiniowanie dokumentu
W ramach bieżącego projektu podproces Opiniowania Dokumentów został wystandaryzowany i wygląda
identycznie w każdej z Komórek Organizacyjnych, poza Departamentem Budżetu i Finansów,
zamodelowanym osobnym procesem.
Strona 26/68
Załącznik nr 1 do umowy
Dokument trafia do Osoby Dekretującej. Zwykle tę rolę pełni dyrektor danego wydziału. Osoba
Dekretująca dokonuje dekretacji na jedną lub więcej Osób Opiniujących. Dekretacja może wiązać się z
przydzieleniem tym osobom Zadań. W przypadku, gdy dany Dokument ponownie trafia do Komórki
Organizacyjnej, nie podlega dekretacji, ale trafia bezpośrednio do Osób Opiniujących, które już z nim
pracowały.
Następnie Osoby Opiniujące umieszczają komentarze do treści dokumentu, a następnie wydają
rekomendacje pozytywne lub negatywne.
W przypadku wydania rekomendacji negatywnej Osoba Opiniująca jest zobligowana do uzupełnienia
komentarza z powodem takiej rekomendacji. W przypadku rekomendacji pozytywnej Osoba Opiniująca
może, ale nie musi uzasadniać swoją decyzję.
W kolejnym kroku procesu Dokument trafia do Osoby Akceptującej. Jeżeli opinia wymaga korekty,
Dokument zostaje cofnięty do Osób Opiniujących z obligatoryjnym komentarzem. W przeciwnym
wypadku dodanie komentarza jest fakultatywne.
Jeżeli opinia nie wymaga korekty, Osoba Akceptująca podejmuje decyzję o akceptacji bądź odrzuceniu
Dokumentu. Odrzucenie Dokumentu oznacza konieczność dodania komentarza z powodem odrzucenia.
Domyślnie treść komentarza jest taka sama, jak Osoby Opiniującej. W przypadku akceptacji, dodanie
komentarza nie jest konieczne.
W przypadku Wydziału Zamówień Publicznych Odrzucenia (ale nie Akceptacji) może dokonać Osoba
Opiniująca.
Strona 27/68
Załącznik nr 1 do umowy
Opiniowanie dokumentu w DBiF
Osoba Dekretująca
Business Process Opiniow anie dokumentu w DBiF
Czy dokument był
wcześniej
dekretowany?
NIE
Dekretacja na
pracownika
Zadanie
TAK
Osoba Opiniująca
Departament Budżetu i Finansów
Dodanie komentarza
TAK
TAK
Opiniowanie
Dokumentu
NIE
NIE
Wydanie
rekomendacji
Czy rekomendacja
negatywna?
Czy dodać komentarz?
KomentarzDoTresciDokumentu
Osoba Akceptująca Rekomendację
Czy opinia wymaga
korekty?
Zapoznanie się z
opinią
TAK
Dodanie komentarza
Komentarz
TAK
Dodanie komentarza
NIE
NIE
Akceptacja
rekomendacji
Czy dodać komentarz?
Diagram: Opiniowanie dokumentu w DBiF
Dokument trafia do Osoby Dekretującej. Rolę tę pełni Sekretariat. Osoba Dekretująca dokonuje dekretacji
na jedną lub więcej Osób Opiniujących. Dekretacja może wiązać się z przydzieleniem tym osobom Zadań.
W przypadku, gdy dany Dokument ponownie trafia do DBiF, nie podlega dekretacji, ale trafia
bezpośrednio do Osób Opiniujących, które już z nim pracowały.
Następnie Osoby Opiniujące umieszczają komentarze do treści dokumentu, a następnie wydają
rekomendacje pozytywne lub negatywne.
W przypadku wydania rekomendacji negatywnej Osoba Opiniująca jest zobligowana do uzupełnienia
komentarza z powodem takiej rekomendacji. W przypadku rekomendacji pozytywnej Osoba Opiniująca
może, ale nie musi uzasadniać swoją decyzję.
W kolejnym kroku procesu Dokument trafia do Osoby Akceptującej Rekomendację. Jeżeli opinia wymaga
korekty, Dokument zostaje cofnięty do Osób Opiniujących z obligatoryjnym komentarzem.
Jeżeli opinia nie wymaga korekty, Osoba Akceptująca Rekomendację podejmuje decyzję o akceptacji
rekomendacji i może dodać komentarz z uzasadnieniem swojej decyzji. Domyślnie treść komentarza jest
taka sama, jak Osoby Opiniującej.
Strona 28/68
Załącznik nr 1 do umowy
Projekt umowy/Projekt Aneksu
Komórka Merytoryczna
Business Process Proces: Proj ekt Umow y/Proj ekt Aneksu
Dokument
Czy zaakceptowano?
NIE
NIE
Korekta dokumentu
Opi ni owani e Dokumentu
Utworzeni e proj ektu
umowy
Wydział
Organizacyjno-Prawny
NIE
NIE
T AK
Generowani e umowy
wł aści wej
Archi wi zacj a proj ektu
umowy
T AK
NEGAT YWNA
Czy zaakceptowano?
NIE
Dekretacj a na Radcę
Opi ni owani e dokumentu
Dodani e komentarza
Zadani e
Opi ni owani e Dokumentu
T AK
Wydział Informatyki i
Systemów Informatycznych
Komórka Dodatkowa
Wydział Promocji
Województwa
Czy zaakceptowano?
T AK
Czy zaakceptowano?
T AK
Czy zakceptowano?
Opi ni owani e Dokumentu
Czy koni eczna akceptacj a
Dysponenta w CRU?
NIE
Dysponent
Opi ni owani e Dokumentu
Czy wymagana
opi ni a WI?
T AK
T AK
NIE
T AK
UMWD
Czy wymagana opi ni a
Komórki Dodatkowej ?
Czy zaakceptowano?
T AK
Akceptacj a Dysponenta
NIE
Czy dokument powi ązany z ZP?
T AK
Procesowani e w
komórkach
Czy zaakceptowano?
Opi ni owani e Dokumentu
Czy dotyczy szkol eń
l ub j est to umowa o
dzi el o l ub zl eceni e?
Wydział Zamówień
Publicznych
Wydział Kadr, Szkolenia i
Spraw Socjalnych
T AK
Czy powi ązany z
podani em w ZP?
Czy zaakceptowano?
Opi ni owani e dokumentu
T AK
Dodani e komentarza
Dodani e komentarza
Departament Budżetu i Finansów
NIE
Czy podl ega
zaopi ni owani u
przez DBi F?
NIE
T AK
Czy
zaakceptowano?
T AK
Czy opi ni a wymaga
korekty?
Decyzj a o
Opi ni owani u w DBi F
Dodani e komentarza
Opi ni owani e
dokumentu w DBi F
Zapoznani e si ę z
opi ni ą
Czy dodać komentarz?
POZYT YWNA
NIE
Akceptacj a
dokumentu
Jaka decyzj a o
opi ni owani u
przez DBi F?
Diagram: Proces: Projekt Umowy/Projekt Aneksu
Proces obsługi Dokumentu typu Projekt Umowy/Projekt Aneksu rozpoczyna się w momencie utworzenia
nowego Dokumentu tego typu w systemie przez uprawnionego pracownika Komórki Merytorycznej.
Utworzony Projekt Umowy/Projekt Aneksu podlega akceptacji przez Osobę Akceptującą w danej
Komórce Organizacyjnej. Jeżeli Projekt Umowy/Projekt Aneksu został odrzucony, wraca do Osoby
Merytorycznej i po odpowiedniej korekcie przechodzi ponownie proces akceptacji. W przypadku
Akceptacji przez Osobę Akceptującą Projekt Umowy/Projekt Aneksu zostaje przekazany do Wydziału
Organizacyjno-Prawnego.
W Wydziale Organizacyjno-Prawnym Projekt Umowy/Projekt Aneksu zostaje zadekretowany przez Osobę
Dekretującą na Osobę Opiniującą (wybranego Radcę Prawnego). Dekretacja może wiązać się z
przydzieleniem Zadań Osobie Opiniującej. Ponieważ ze względu na uwarunkowania prawne decyzje
Radcy Prawnego są autonomiczne, wydanie rekomendacji pozytywnej przez Radcę jest jednoznaczne z
Akceptacją Projektu Umowy/Projektu Aneksu przez Wydział Organizacyjno-Prawny, a wydanie
Strona 29/68
Załącznik nr 1 do umowy
rekomendacji negatywnej - z jego Odrzuceniem (decyzje Radcy Prawnego nie podlegają Akceptacji przez
dyrektora Wydziału Organizacyjno-Prawnego; Radca Prawny jest jednocześnie Osobą Opiniującą i Osobą
Akceptującą). Jeżeli Projekt Umowy/Projekt Aneksu został odrzucony, wraca do Osoby Merytorycznej z
obligatoryjnym Komentarzem i po odpowiedniej korekcie przechodzi ponownie proces akceptacji. W
przypadku Akceptacji Projektu Umowy/Projektu Aneksu zostaje przekazany do Wydziału Promocji
Województwa.
Przekazanie Projektu Umowy/Projektu Aneksu do Wydziału Promocji Województwa uruchamia
podproces Opiniowanie Dokumentu. Po zaopiniowaniu Projekt Umowy/Projekt Aneksu podlega
Akceptacji przez Osobę Akceptującą. Jeżeli został odrzucony, wraca do Osoby Merytorycznej i po
odpowiedniej korekcie przechodzi ponownie proces akceptacji. W przypadku Akceptacji Projekt
Umowy/Projekt Aneksu zostaje przekazany do dalszego procedowania.
Jeżeli wymagana jest opinia Komórki Dodatkowej, to Projekt Umowy/Projekt Aneksu zostaje do niej
przekazany i tam uruchamia się podproces Opiniowanie Dokumentu. Po zaopiniowaniu Projekt
Umowy/Projekt Aneksu podlega Akceptacji przez Osobę Akceptującą. Jeżeli został odrzucony, wraca do
Osoby Merytorycznej i po odpowiedniej korekcie przechodzi ponownie proces akceptacji. W przypadku
Akceptacji zostaje przekazany do dalszego procedowania.
Jeżeli wymagana jest opinia Wydziału Informatyki i Systemów Informatycznych, to Projekt
Umowy/Projekt Aneksu zostaje do niego przekazany i tam uruchamia się podproces Opiniowanie
Dokumentu. Po zaopiniowaniu Projekt Umowy/Projekt Aneksu podlega Akceptacji przez Osobę
Akceptującą. Jeżeli został odrzucony, wraca do Osoby Merytorycznej i po odpowiedniej korekcie
przechodzi ponownie proces akceptacji. W przypadku Akceptacji Projekt Umowy/Projekt Aneksu zostaje
przekazany do dalszego procedowania.
Następnie w przypadku, gdy Projekt Umowy/Projekt Aneksu wymaga akceptacji Dysponentów w CRU,
jest przekazywany do akceptacji Dysponentów. Tam uruchamia się podproces Akceptacji Dysponenta
według obiegu zdefiniowanego w podprocesie Opiniowanie Dokumentu. Po zaopiniowaniu Projekt
Umowy/Projekt Aneksu podlega Akceptacji przez Osoby Dysponujące. Jeżeli został odrzucony, wraca do
Osoby Merytorycznej i po odpowiedniej korekcie przechodzi ponownie proces akceptacji. W przypadku
Akceptacji Projekt Umowy/Projekt Aneksu zostaje przekazany do dalszego procedowania.
Jeżeli Projekt Umowy/Projekt Aneksu nie jest powiązany z podaniem w systemie obsługującym
zamówienia publiczne, to może podlegać opiniowaniu wyłącznie w Departamencie Budżetu i Finansów,
przy czym decyzja o opiniowaniu w tym departamencie zależy od wartości atrybutów Dokumentu w
zakresie typu dokumentu i danych finansowych, których analiza została szczegółowo zdefiniowana w
podprocesie Decyzja o Opiniowaniu w DBiF. W przypadku negatywnej decyzji o opiniowaniu w DBiF
Projekt Umowy/Projekt Aneksu wraca do Osoby Merytorycznej w celu wygenerowania Umowy
Właściwej/Aneksu. Jeżeli decyzja o opiniowaniu w DBiF jest pozytywna, Dokument podlega opiniowaniu
według procesu Opiniowanie dokumentu w DBiF. Osoba Akceptująca w DBiF zapoznaje się z opinią i w
przypadku, gdy opinia wymaga korekty cofa dokument do Osoby Opiniującej w DBiF z obligatoryjnym
komentarzem. Jeżeli opinia nie wymaga korekty, to Osoba Akceptująca dokonuje Akceptacji lub
Odrzucenia Projektu Umowy/Projektu Aneksu. W przypadku Odrzucenia dokument wraca do Osoby
Merytorycznej z obligatoryjnym komentarzem, a w przypadku Akceptacji oczekuje na akceptacje innych
Komórek Organizacyjnych, o ile są wymagane. Akceptacja umożliwia dodania Komentarza.
Jeżeli Dokument jest powiązany z podaniem w ZP, kolejnym krokiem procesu jest równoległe opiniowanie
Projektu Umowy/Projektu Aneksu w wybranych Komórkach Organizacyjnych. Komórki Organizacyjne
wymagane do zaopiniowania definiowane są na etapie tworzenia Projektu Umowy/Projektu Aneksu.
Projekt Umowy/Projekt Aneksu może być opiniowany w następujących komórkach: Wydziale Zamówień
Strona 30/68
Załącznik nr 1 do umowy
Publicznych, Wydziale Kadr, Szkolenia i Spraw Socjalnych oraz Departamencie Budżetu i Finansów, przy
czym decyzja o opiniowaniu w tym departamencie zależy od wartości atrybutów Dokumentu w zakresie
typu dokumentu i danych finansowych, których analiza została szczegółowo zdefiniowana w podprocesie
Decyzja o Opiniowaniu w DBiF. Opiniowanie w każdej z tych komórek uruchamia podproces Opiniowania
Dokumentu lub Opiniowania Dokumentu w DBiF. Aby Projekt Umowy/Projekt Aneksu przeszedł do
kolejnego kroku w procesie, wymagana jest Akceptacja od wszystkich Osób Akceptujących w
wymaganych Komórkach Organizacyjnych. Jeżeli Projekt Umowy/Projekt Aneksu zostanie odrzucony
przez którąkolwiek z Osób Akceptujących w wymaganych komórkach, wraca do Osoby Merytorycznej z
obligatoryjnym Komentarzem i po odpowiedniej korekcie przechodzi ponownie cały proces akceptacji.
W przypadku, gdy Projekt Umowy/Projekt Aneksu zostanie zaakceptowany przez wszystkie Osoby
Akceptujące, wraca do Osoby Merytorycznej ze statusem ZAAKCEPTOWANY i nie może już podlegać
edycji. Osoba Merytoryczna generuje Umowę Właściwą, a dalsze procesowanie Umowy Właściwej
odbywa się według zdefiniowanego dla niej procesu. Projekt Umowy/Projekt Aneksu jest archiwizowany i
kończy swój cykl życia.
Strona 31/68
Załącznik nr 1 do umowy
Umowa Właściwa/Aneks
Business Process Proces: Umow a Właściw a/Aneks
Komórka Merytoryczna
Dokument
Czy podpisano?
Czy zaakceptowano?
NIE
Utworzenie umowy
NIE
TAK
Podpisanie umowy
Korekta dokumentu
Opiniowanie Dokumentu
NIE
NEGATYWNA
NIE
Rejestracja Dokumentu
NIE
TAK
NIE
Archiwizacja dokumentu
Wydział
Organizacyjno-Prawny
TAK
Czy zaakceptowany?
Dekretacja na Radcę
Wydział Promocji
Województwa
Generowanie numeru
umowy
TAK
NIE
Opiniowanie
dokumentu
Dodanie komentarza
Czy zaakceptowano?
Opiniowanie Dokumentu
Komórka Dodatkowa
TAK
Czy wymagana opinia
Komórki Dodatkowej?
Czy zaakceptowano?
TAK
Opiniowanie Dokumentu
TAK
NIE
Czy zaakceptowano?
TAK
Opiniowanie Dokumentu
Wydział Informatyki i Systemów Informatycznych
UMWD
Wydział Kadr, Szkolenia i Spraw Socjalnych
Czy dotyczy szkoleń lub umowa
zlecenie/o dzieło?
TAK
NIE
Czy zaakceptowano?
Czy wymagana opinia
WI?
TAK
TAK
Czy konieczna
akceptacja
Dysponentów w CRU?
TAK
Dysponent
NIE
Opiniowanie dokumentu
Czy zaakceptowano?
Akceptacja Dysponenta
TAK
Opiniowanie Dokumentu
Czy dokument będzie
powiązany z ZP?
Wydział Kadr, Szkolenia i Spraw Socjalnych
Wydział Zamówień
Publicznych
Czy zaakceptowno?
TAK
NIE
TAK
Czy zaakceptowano?
TAK
NIE
Dodanie komentarza
Czy dodać komentarz?
TAK
Dodanie komentarza
Opiniowanie dokumentu
TAK
NIE
Czy możliwa
kontrasygnata w WK?
TAK
Czy dotyczy
szkoleń?
TAK
Czy
kontrasygnowano?
TAK
TAK
Czy wymagana
Kontrasygnata?
Kontrasygnata
Jaka decyzja o opiniowaniu
przez DBiF?
Opiniowanie
NIE
POZYTYWNA
Decyzja o
opiniowaniu w DBiF
NIE
Opiniowanie Dokumentu w
DBiF
Dodanie komentarza
Czy rekomendacja
negatywna?
NIE
Akceptacja
Departament Budżetu i Finansów
TAK
Czy opinia
wymaga korekty?
TAK
NIE
NIE
Zapoznanie się z
opinią
NIE
Akceptacja
dokumentu
Dodanie komentarza
Czy wymaga kontrasygnaty?
Czy zaakceptowano?
NIE
TAK Dodanie komentarza
Czy dodać komentarz?
TAK
TAK
Dodanie komentarza
Dodanie komentarza
Kontrasygnata
Dodanie komentarza
Czy dotyczy szkoleń?
TAK
Czy dodać komentarz?
NIE
TAK
NIE
NIE
Zapoznanie się z
opinią
Kontrasygnata
Czy opinia wymaga korekty?
Czy kontrasygnowano?
Diagram: Proces: Umowa Właściwa/Aneks
Proces obsługi Dokumentu typu Umowa Właściwa/Aneks rozpoczyna się w momencie utworzenia nowego
Strona 32/68
Załącznik nr 1 do umowy
Dokumentu tego typu w systemie przez uprawnionego pracownika Komórki Merytorycznej lub
wygenerowania go z Dokumentu typu Projekt Umowy/Projekt Aneksu lub Istotne Postanowienia Umowy.
Utworzona Umowa Właściwa/Aneks musi mieć wypełnione wymagane pola i podlega Akceptacji przez
Osobę Akceptującą w danej Komórce Organizacyjnej. Jeżeli została odrzucona, wraca do Osoby
Merytorycznej i po odpowiedniej korekcie przechodzi ponownie proces akceptacji. W przypadku
Akceptacji przez Osobę Akceptującą Umowa Właściwa/Aneks zostaje przekazana do Wydziału
Organizacyjno-Prawnego.
W Wydziale Organizacyjno-Prawnym Umowa Właściwa/Aneks zostaje zadekretowana przez Osobę
Dekretującą na Osobę Opiniującą (wybranego Radcę Prawnego). Dekretacja może wiązać się z
przydzieleniem Zadań Osobie Opiniującej. Ponieważ ze względu na uwarunkowania prawne decyzje
Radcy Prawnego są autonomiczne, wydanie rekomendacji pozytywnej przez Radcę jest jednoznaczne z
Akceptacją Umowy Właściwej/Aneksu przez Wydział Organizacyjno-Prawny, a wydanie rekomendacji
negatywnej - z jego Odrzuceniem (decyzje Radcy Prawnego nie podlegają Akceptacji przez dyrektora
Wydziału Organizacyjno-Prawnego; Radca Prawny jest jednocześnie Osobą Opiniującą i Osobą
Akceptującą). Jeżeli Umowa Właściwa/Aneks została odrzucona, wraca do Osoby Merytorycznej i po
odpowiedniej korekcie przechodzi ponownie proces akceptacji. W przypadku Akceptacji zostaje
przekazana do Wydziału Promocji Województwa.
Przekazanie Umowy Właściwej/Aneksu do Wydziału Promocji Województwa uruchamia podproces
Opiniowanie Dokumentu. Po zaopiniowaniu Umowa Właściwa/Aneks podlega Akceptacji przez Osobę
Akceptującą. Jeżeli została odrzucona, wraca do Osoby Merytorycznej i po odpowiedniej korekcie
przechodzi ponownie proces akceptacji. W przypadku Akceptacji zostaje przekazana do opiniowania w
Komórce Dodatkowej, o ile Komórka Dodatkowa została wskazana na etapie tworzenia Umowa
Właściwej.
Opiniowanie Umowy Właściwej/Aneksu w Komórce Dodatkowej uruchamia podproces Opiniowania
Dokumentu we właściwej Komórce. W przypadku Odrzucenia Dokumentu, Umowa Właściwa/Aneks
wraca do Osoby Merytorycznej i po odpowiedniej korekcie przechodzi ponownie cały proces akceptacji.
W przypadku Akceptacji Umowa Właściwa/Aneks zostaje przekazana do Akceptacji w Wydziale Kadr,
Szkolenia i Spraw Socjalnych, o ile dotyczy szkoleń lub jest umową zleceniem lub o dzieło. Opiniowanie w
Wydziale Kadr, Szkolenia i Spraw Socjalnych odbywa się według standardowego procesu. W przypadku
Odrzucenia, Umowa Właściwa/Aneks wraca do Osoby Merytorycznej i po odpowiedniej korekcie
przechodzi ponownie cały proces akceptacji.
W przypadku Akceptacji zostaje przekazana do Akceptacji w Wydziale Informatyki i Systemów
Informatycznych, o ile Wydział ten został wskazany na etapie tworzenia Umowy Właściwej/Aneksu.
Opiniowanie w Wydziale Informatyki i Systemów Informatycznych odbywa się według standardowego
procesu. W przypadku Odrzucenia, Umowa Właściwa/Aneks wraca do Osoby Merytorycznej i po
odpowiedniej korekcie przechodzi ponownie cały proces akceptacji.
W przypadku Akceptacji Umowa Właściwa/Aneks zostaje przekazana do Akceptacji Osób Dysponujących
we właściwych Komórkach Organizacyjnych, o ile wymagana jest Akceptacja Osoby Dysponującej.
Opiniowanie w Komórce Organizacyjnej Osoby Dysponującej odbywa się według podprocesu
Opiniowanie Dokumentu. W przypadku Odrzucenia Dokumentu, Umowa Właściwa/Aneks wraca do
Osoby Merytorycznej i po odpowiedniej korekcie przechodzi ponownie cały proces akceptacji.
Umowa Właściwa zaakceptowana przez wszystkie Osoby Dysponujące podlega opiniowaniu w Wydziale
Zamówień Publicznych według standardowego schematu, o ile Wydział Zamówień Publicznych został
wskazany na etapie tworzenia Dokumentu. W przypadku Odrzucenia Dokumentu, Umowa
Strona 33/68
Załącznik nr 1 do umowy
Właściwa/Aneks wraca do Osoby Merytorycznej i po odpowiedniej korekcie przechodzi ponownie cały
proces akceptacji.
Jeżeli Umowa Właściwa/Aneks została zaakceptowana w Wydziale Zamówień Publicznych, to podlega
opiniowaniu w Wydziale Kadr. Szkolenia i Spraw Socjalnych według standardowego procesu, o ile
dotyczy szkoleń. W przypadku Odrzucenia Dokumentu, Umowa Właściwa/Aneks wraca do Osoby
Merytorycznej i po odpowiedniej korekcie przechodzi ponownie cały proces akceptacji.
Umowa Właściwa/Aneks zaakceptowana przez Osobę Akceptującą zostaje przekazana do Osoby
Kontrasygnującej w Wydziale Kadr, Szkolenia i Spraw Socjalnych, o ile wymagana jest Kontrasygnata. W
przypadku Kontrasygnaty Dokumentu, Umowa Właściwa/Aneks wraca do Osoby Merytorycznej z
fakultatywnym komentarzem i jest gotowa do podpisania przez wszystkie strony. W przypadku braku
Kontrasygnaty Umowy Właściwej/Aneksu Osoba Kontrasygnująca dodaje obligatoryjny komentarz, a
Umowa Właściwa/Aneks jest archiwizowana ze statusem BRAK_KONTRASYGNATY.
Jeżeli Kontrasygnata w Wydziale Kadr, Szkolenia i Spraw Socjalnych nie jest możliwa (np. z powodu
nieobecności Osoby Kontrasygnującej), to Umowa Właściwa/Aneks jest przekazywana do Kontrasygnaty
w Departamencie Budżetu i Finansów. Jeżeli opinia wymaga korekty, to Umowa Właściwa/Aneks wraca
do Wydziału Kadr, Szkolenia i Spraw Socjalnych z obligatoryjnym komentarzem. W przeciwnym
wypadku następuje Kontrasygnata Umowy.
Jeżeli Umowa Właściwa/Aneks nie dotyczy szkoleń, to podlega opiniowaniu w Departamencie Budżetu i
Finansów, przy czym decyzja o opiniowaniu w tym departamencie zależy od wartości atrybutów
Dokumentu w zakresie typu dokumentu i danych finansowych, których analiza została szczegółowo
zdefiniowana w podprocesie Decyzja o Opiniowaniu w DBiF. Jeżeli opinia wymaga korekty, to Umowa
Właściwa/Aneks wraca do Osoby Opiniującej z obligatoryjnym komentarzem.
W przypadku rekomendacji negatywnej Odrzucenia dokumentu dokonuje Osoba Akceptująca
Rekomendację. Umowa Właściwa/Aneks wraca do Osoby Merytorycznej i po odpowiedniej korekcie
przechodzi ponownie cały proces akceptacji.
W przypadku rekomendacji pozytywnej, Umowa Właściwa/Aneks zaakceptowana przez Osobę
Akceptującą zostaje przekazana do Osoby Kontrasygnującej w Departamencie Budżetu i Finansów, o ile
wymagana jest Kontrasygnata. W przypadku Kontrasygnaty Dokumentu, Umowa Właściwa/Aneks wraca
do Osoby Merytorycznej z fakultatywnym komentarzem i jest gotowa do podpisania przez wszystkie
strony. W przypadku braku Kontrasygnaty Osoba Kontrasygnująca dodaje obligatoryjny komentarz, a
Umowa Właściwa/Aneks jest archiwizowana ze statusem BRAK_KONTRASYGNATY.
W przypadku umów dotyczących szkoleń Osobą Kontrasygnującą jest Dyrektor Wydziału Kadr, Szkolenia
i Spraw Socjalnych, w przeciwnym wypadku Osobą Kontrasygnującą jest Skarbnik Województwa.
Jeżeli Umowa Właściwa/Aneks nie wymaga Kontrasygnaty, to o ile opinia nie wymaga korekty Umowa
Właściwa/Aneks zostaje zaakceptowana z fakultatywnym komentarzem, wraca do Osoby Merytorycznej i
jest gotowa do podpisania. W przypadku, gdy opinia wymaga korekty, wraca do Osoby Opiniującej z
obligatoryjnym komentarzem.
Po podpisaniu Umowy Właściwej/Aneksu zostaje ona archiwizowana ze statusem PODPISANA. Jeżeli
Umowa Właściwa/Aneks nie została podpisana, to jest archiwizowana ze statusem NIE_PODPISANA.
Strona 34/68
Załącznik nr 1 do umowy
Zamówienie
Komórka Merytoryczna
Business Process Proces: Zamówienie
Czy zaakceptowano?
Opiniowanie Dokumentu
Czy konieczna akceptacja
Dysponenta?
Korekta dokumentu
Dodanie komentarza
Archiwizacja
dokumentu
Potwierdzenie
zamówienia
Czy zaakceptowano?
TAK
TAK
NIE
Opiniowanie
Dokumentu
Dysponent
NIE
TAK
NIE
Utworzenie
zamówienia
Dodanie komentarza
NIE
Dodanie komentarza
UMWD
NIE
TAK
TAK
Czy zaakceptowano?
TAK
Opiniowanie Dokumentu w
DBiF
Czy dodać komentarz?
Dodanie komentarza
Dodanie komentarza
NIE
Dodanie komentarza
TAK
NIE
TAK
NIE
Departament Budżetu i Finansów
Akceptacja
dokumentu
Dodanie komentarza
TAK
Kontrasygnata
Czy kontrasygnowano?
NIE
Zapoznanie się z
opinią
Czy opinia wymaga korekty?
Czy dodać komentarz?
TAK Dodanie komentarza
Czy dodać komentarz?
Diagram: Proces: Zamówienie
Zamówienie po utworzeniu podlega Opiniowaniu i Akceptacji przez Osobę Dysponującą we wskazanych
komórkach merytorycznych, o ile wymagana jest Akceptacja Osoby Dysponującej. W przypadku
Odrzucenia, Zamówienie wraca do Osoby Merytorycznej z obligatoryjnym komentarzem i po
odpowiedniej korekcie przechodzi ponownie cały proces akceptacji.
W przypadku Akceptacji Zamówienie podlega opiniowaniu w Departamencie Budżetu i Finansów według
procesu Opiniowanie w DBiF. Osoba Akceptująca Rekomendację zapoznaje się z opinią i w przypadku,
gdy opinia wymaga korekty, cofa Zamówienie do Osoby Opiniującej z obligatoryjnym komentarzem.
Jeżeli opinia nie wymaga korekty, to o ile zostaje zaakceptowana trafia do Kontrasygnaty z fakultatywnym
komentarzem. W przypadku odrzucenia Zamówienie wraca do Osoby Merytorycznej z obligatoryjnym
komentarzem i po odpowiedniej korekcie przechodzi ponownie cały proces akceptacji.
Po Akceptacji w Departamencie Budżetu i Finansów Zamówienie podlega Kontrasygnacie. W przypadku
kontrasygnowania Zamówienia wraca ono do Osoby Merytorycznej w celu potwierdzenia i rejestracji,
polegającej na dodaniu skanu dokumentu potwierdzającego realizację Zamówienia. Osoba
Kontrasygnująca może dołączyć komentarz. Zamówienie jest archiwizowane ze statusem
ZREALIZOWANY.
Strona 35/68
Załącznik nr 1 do umowy
Jeżeli Osoba Kontrasygnująca wydała decyzję negatywną, musi ją uzasadnić w obligatoryjnym
komentarzu. Zamówienie jest archiwizowane ze statusem BRAK_KONTRASYGNATY.
Dokumentem nadrzędnym dla Zamówienia jest podanie w systemie obsługującym zamówienia publiczne.
Strona 36/68
Załącznik nr 1 do umowy
Systemowe Przypadki Użycia
Akceptacja Dokumentu
uc Akceptacj a Dokumentu
Osoba Kontrasygnuj ąca
(from
Role)
Osoba Akceptuj ąca
(from
Role)
UC007a: Masow a
akceptacj a
dokumentów
UC007b: Kontrasygnata
dokumentu
extends
«extend»
UC007: Akceptacj a
dokumentu
Akceptacja Dokumentu
Przypadek
użycia:
UC007: Akceptacja dokumentu
Uwagi:
Celem przypadku użycia jest zaakceptowanie dokumentu. Opierając się na rekomendacjach
swoich pracowników, dyrektor może:
1. zaakceptować dokument, który w takim przypadku przechodzi do kolejnego etapu w
procesie. Akceptacja dokumentu musi umożliwiać dołączenie opcjonalnego komentarza.
Akceptacja dokumentu generuje wpis do dziennika zdarzeń w systemie.
2. odrzucić dokument, który w takim przypadku wraca do komórki merytorycznej z
obligatoryjnym komentarzem.
Warunki
Niepusty
komentarz
Opis
W przypadku odrzucenia dokumentu, system wymusza dodanie niepustego komentarza z
powodem odrzucenia dokumentu.
Scenariusze:
Strona 37/68
Załącznik nr 1 do umowy
Typ:
1. Przypadek użycia rozpoczyna się w momencie, gdy Osoba Akceptująca wybiera
opcję przeglądu dokumentów w statusie DO_AKCEPTACJI.
Bazowy
2. System prezentuje listę dokumentów przypisanych do Komórki Organizacyjnej
Nazwa:
Osoby Akceptującej.
Scenariusz podstawowy
3. Osoba Akceptująca wybiera rekord z listy.
4. Osoba Akceptująca akceptuje dokument. Dokument zmienia status na
DO_DEKRETACJI, DO_KONTRASYGNATY lub DO_PODPISU, w
zależności od miejsca w procesie.
5. System pyta, czy Osoba Akceptująca chce dodać komentarz do decyzji o
akceptacji. Osoba Akceptująca uzupełnia komentarz.
6. Jeżeli akceptacja następuje w Wydziale Organizacyjno-Prawnym, dokumentowi
zostaje nadany numer.
7. Przypadek użycia kończy bieg.
Typ:
4a. Osoba Akceptująca lub Opiniująca w WZP odrzuca wybrany dokument.
Alternatywny
5. System wyświetla okno dialogowe z miejscem na komentarz z powodem
odrzucenia dokumentu. Osoba Akceptująca musi uzupełnić komentarz..
Nazwa:
Odrzucenie dokumentu 6. System zmienia status dokumentu na ODRZUCONY.
7. Dokument wraca do Komórki Merytorycznej.
8. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Cofnięcie dokumentu
4a. Osoba Akceptująca cofa wybrany dokument.
5. System wyświetla okno dialogowe z miejscem na komentarz z powodem
cofnięcia dokumentu. Osoba Akceptująca musi uzupełnić komentarz.
6. System zmienia status dokumentu na OPINIOWANY.
7. Dokument wraca do Osoby Opiniującej w danej Komórce Organizacyjnej.
8. Przypadek użycia kończy bieg.
Przypadek
użycia:
UC007a: Masowa akceptacja dokumentów
Uwagi:
Celem przypadku użycia jest umożliwienie masowej akceptacji dokumentów. Masowa
akceptacja dokumentów generuje wpis do dziennika zdarzeń w systemie.
Scenariusze:
Typ:
1. Przypadek użycia rozszerza UC007 i rozpoczyna się w momencie, gdy Osoba
Akceptująca Osoba Akceptująca wybiera więcej niż jeden dokument do
Bazowy
akceptacji.
Nazwa:
2. Osoba Akceptująca akceptuje wszystkie dokumenty z możliwością dodania
Scenariusz podstawowy
komentarza identycznego dla wszystkich dokumentów.
3. Przypadek użycia kończy bieg.
Strona 38/68
Załącznik nr 1 do umowy
Przypadek
użycia:
Uwagi:
UC007b: Kontrasygnata dokumentu
Celem przypadku użycia jest kontrasygnata dokumentu przez Skarbnika Województwa lub
osobę upoważnioną. Kontrasygnata dokumentu generuje wpis do dziennika zdarzeń w
systemie.
Scenariusze:
Typ:
1. Przypadek użycia rozpoczyna się w momencie, gdy Osoba Kontrasygnująca
wybiera opcję przeglądu dokumentów w statusie DO_KONTRASYGNATY.
Bazowy
2. System prezentuje listę dokumentów przypisanych do danej Osoby
Nazwa:
Kontrasygnującej.
Scenariusz podstawowy
3. Osoba Kontrasygnująca wybiera rekord z listy.
4. Osoba Kontrasygnująca wybiera opcję kontrasygnaty dokumentu. Dokument
zmienia status na KONTRASYGNOWANY.
6. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Brak kontrasygnaty
1. Osoba Kontrasygnująca wybiera opcję braku kontrasygnaty dla dokumentu.
Dokument zmienia status na BRAK_KONTRASYGNATY.
2. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Cofnięcie dokumentu
4a. Osoba Kontrasygnująca cofa wybrany dokument.
5. System wyświetla okno dialogowe z miejscem na komentarz z powodem
cofnięcia dokumentu. Osoba Kontrasygnująca musi uzupełnić komentarz.
6. System zmienia status dokumentu na OPINIOWANY.
7. Dokument wraca do Osoby Opiniującej we właściwej Komórce Organizacyjnej.
8. Przypadek użycia kończy bieg.
Strona 39/68
Załącznik nr 1 do umowy
Obsługa Kar Umownych, Wierzytelności i Zamknięcia Umowy
uc Obsługa Kar Umow nych, Wierzytelności i Zamknięcia Umow y
UC027: Edycj a
w ierzytelności
UC031: Edycj a kary
umow nej
Osoba Rej estruj ąca
UC025: Zamknięcie umow y
(from
Role)
Obsługa Kar Umownych, Wierzytelności i Zamknięcia Umowy
Przypadek
użycia:
Uwagi:
UC025: Zamknięcie umowy
Celem przypadku użycia jest wprowadzenie do systemu informacji o rozwiązaniu,
wypowiedzeniu bądź odstąpieniu od umowy i zmiana jej statusu na ZAMKNIĘTY. System
musi umożliwiać dołączanie załączników do takiej informacji (np. orzeczenia sądów,
uchwały zarządu województwa). Rozwiązanie, wypowiedzenie lub odstąpienie od umowy
generuje wpis do dziennika zdarzeń w systemie.
Scenariusze:
Typ:
1. Przypadek użycia rozpoczyna się w momencie, gdy Osoba Merytoryczna
wyświetli metrykę umowy w trybie edycji.
Bazowy
2. Osoba Merytoryczna wybiera opcję zamknięcia umowy.
Nazwa:
Scenariusz podstawowy 3. System prezentuje formularz zawierający dane zamknięcia umowy, zgodny z
modelem domenowym.
4. Po wprowadzeniu danych Osoba Merytoryczna wybiera opcję Zapisz, a system
waliduje wprowadzone dane.
5. W przypadku poprawnej walidacji danych system zapisuje informację o
zamknięciu umowy i zmienia status umowy na ZAMKNIĘTY.
6. Przypadek użycia kończy bieg.
Typ:
Wyjątek
Nazwa:
Błędy walidacji
6a. System odnalazł niepoprawne wartości wśród wprowadzonych przez Osobę
Merytoryczną danych.
7. System prezentuje odnalezione błędy, oznaczając błędne pola i wyświetlając
przy każdym z nich opis błędu.
8. Osoba Merytoryczna zapoznaje się z błędami, dokonuje korekty i ponownie
Strona 40/68
Załącznik nr 1 do umowy
zapisuje formularz.
9. Przypadek użycia kończy bieg.
Przypadek
użycia:
Uwagi:
UC027: Edycja wierzytelności
Celem przypadku użycia jest zmiana informacji o stanie wierzytelności na podstawie
informacji z kancelarii komorniczych. W szczególności możliwe jest dodanie nowej, edycja
oraz usunięcie wierzytelności. System musi umożliwiać dodanie adnotacji oraz dołączanie
załączników w formie plików binarnych. Edycja wierzytelności generuje wpis do dziennika
zdarzeń w systemie.
Scenariusze:
Typ:
1. Przypadek użycia rozpoczyna się od wyszukania kontrahenta zgodnie z UC038.
Bazowy
2. Osoba Rejestrująca wywołuje edycję znalezionego rekordu Kontrahenta i
przechodzi do edycji listy powiązanych wierzytelności.
Nazwa:
Scenariusz podstawowy 3. Osoba Rejestrująca wywołuje akcję Dodaj nową.
4. System umożliwia edycję rekordu zgodnie z klasą Wierzytelność.
5. Użytkownik wprowadza niezbędne dane i wywołuje akcję Zapisz,
6. Dane zostają zapisane w systemie.
7. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Edycja wierzytelności
3a. Osoba Rejestrująca wybiera wierzytelność z listy.
4. Osoba Rejestrująca wywołuje akcję Edytuj.
5. Powrót do pkt. 5 Scenariusza podstawowego, kontynuacja.
Typ:
Alternatywny
Nazwa:
Usunięcie wierzytelności
3a. Osoba Rejestrująca wybiera wierzytelność z listy.
4. Osoba Rejestrująca wywołuje akcję Usuń.
5. System prosi o potwierdzenie usunięcia.
6. Osoba Rejestrująca potwierdza usunięcie.
7. Powrót do pkt. 6 Scenariusza podstawowego, kontynuacja.
Typ:
Alternatywny
Nazwa:
Brak kontrahenta
1. Przypadek użycia rozpoczyna się w momencie, gdy system nie znajdzie
kontrahenta względem podanych kryteriów (NIP, PESEL, REGON, KRS)
zgodnie z UC038.
2. Osoba Rejestrująca wywołuje akcję Nowy kontrahent.
3. System umożliwia edycję rekordu Kontrahenta zgodnie z modelem
domenowym.
4. Osoba Rejestrująca przechodzi do edycji listy powiązanych wierzytelności.
5. Osoba Rejestrująca wywołuje akcję Nowa wierzytelność.
Strona 41/68
Załącznik nr 1 do umowy
6. System umożliwia edycję rekordu wierzytelności zgodnie z modelem
domenowym.
7. Użytkownik wprowadza niezbędne dane i wywołuje akcję Zapisz.
8. Dane zostają zapisane w systemie.
9. Przypadek użycia kończy bieg.
Przypadek
użycia:
Uwagi:
UC031: Edycja kary umownej
Celem przypadku użycia jest zmiana informacji o stanie kar umownych. W szczególności
możliwe jest dodanie nowej, edycja oraz usunięcie kary umownej. Edycja kary umownej
generuje wpis do dziennika zdarzeń w systemie.
Scenariusze:
Typ:
1. Przypadek użycia rozpoczyna się od wyszukania umowy zgodnie z UC008.
Bazowy
2. Osoba Rejestrująca wywołuje edycję znalezionego rekordu umowy i przechodzi
do edycji listy powiązanych kar umownych.
Nazwa:
Scenariusz podstawowy 3. Osoba Rejestrująca wywołuje akcję Dodaj nową.
4. System umożliwia edycję rekordu kary umownej zgodnie z modelem
domenowym.
5. Użytkownik wprowadza niezbędne dane i wywołuje akcję Zapisz.
6. Dane zostają zapisane w systemie.
7. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Edycja kary umownej
3a. Osoba Rejestrująca wybiera karę umowną z listy.
4. Osoba Rejestrująca wywołuje akcję Edytuj.
5. Powrót do pkt. 5 Scenariusza podstawowego, kontynuacja.
Typ:
Alternatywny
Nazwa:
Usunięcie kary umownej
3a. Osoba Rejestrująca wybiera karę umowną z listy.
4. Osoba Rejestrująca wywołuje akcję Usuń.
5. System prosi o potwierdzenie usunięcia.
6. Osoba Rejestrująca potwierdza usunięcie.
7. Powrót do pkt. 6 Scenariusza podstawowego, kontynuacja.
Typ:
Wyjątek
Nazwa:
Błąd walidacji
4a. System odnalazł błędy we wprowadzonych przez użytkownika danych.
5. System prezentuje odnalezione błędy, oznaczając błędne pola i wyświetlając
przy każdym z nich opis błędu.
6. Użytkownik zapoznaje się z błędami i zapisuje formularz.
7. Przypadek użycia kończy bieg.
Strona 42/68
Załącznik nr 1 do umowy
Tworzenie i edycja dokumentu
uc Tw orzenie i edycj a dokumentu
UC001a: Edycj a treści
dokumentu
UC001: Edycj a
metryki dokumentu
«extend»
UC008: Wyszukanie
dokumentu
A
UC016: Edycj a
dysponentów
UC003: Anulow anie
dokumentu
UC019: Generow anie
umow y w łaściw ej
UC032: Archiw izacj a
dokumentu
Osoba Merytoryczna
(from
Role)
UC020: Rej estracj a
umow y w łaściw ej
UC029: Wydruk
dokumentu
UC023: Seryj ne tw orzenie
dokumentów na podstaw ie
szablonu
UC036: Edycj a w ysokości
składek na ubezpieczenia
społeczne
UC037: Edycj a
kontrahenta
UC038: Wyszukanie
kontrahenta
Tworzenie i edycja dokumentu
Przypadek
użycia:
UC001: Edycja metryki dokumentu
Uwagi:
Celem przypadku jest edycja danych dokumentu w systemie CRU, w szczególności
utworzenie nowego, utworzenie nowego na podstawie dokumentu zarchiwizowanego oraz
edycja listy załączników binarnych. Wymagane jest zebranie niezbędnych danych
przechowywanych w obiektach dziedziczących z klasy Dokument. Edycja treści dokumentu
jest możliwa wyłącznie na wskazanych wykonawcy statusach dokumentów zdefiniowanych
przez Zamawiającego. Utworzenie dokumentu generuje wpis do dziennika zdarzeń w
systemie. Przypadek ten rozpoczyna proces.
Warunki
Komórka
Dodatkowa
Opis
Pole Komórka Dodatkowa zawiera listę Komórek Organizacyjnych UMWD oprócz
następujących komórek: Wydział Organizacyjno-Prawny, Wydział Promocji Województwa,
Wydział Informatyki i Systemów Informatycznych, Wydział Zamówień Publicznych, Wydział
Kadr, Szkolenia i Spraw Socjalnych, Departament Budżetu i Finansów.
Typ dokumentu W zależności od wybranego typu dokumentu system prezentuje różny zestaw pól, według
modelu domenowego.
Strona 43/68
Załącznik nr 1 do umowy
Walidacja
wierzytelności
System powinien umożliwić walidację wierzytelności kontrahenta na etapie tworzenia umowy.
Scenariusze:
Typ:
1. System prezentuje listę dokumentów w statusie DO_OPINIOWANIA,
ODRZUCONY, KOPIA_ROBOCZA.
Bazowy
2.
Osoba
Merytoryczna wybiera opcję utworzenia nowego dokumentu w systemie.
Nazwa:
Scenariusz podstawowy 3. System prezentuje formularz tworzenia wybranego typu dokumentu zawierający
następujące bloki danych, zgodny z modelem domenowym:

typ dokumentu,

komórki organizacyjne, w których wymagane jest procesowanie
dokumentu (włącznie z dodatkową),

właściwości dokumentu,

rozszerzone uprawnienia dokumentu,

dane finansowe,

dane do ubezpieczeń społecznych,

kontrahent (możliwość dodania kilku kontrahentów),

załączniki w formie plików binarnych,

treść umowy.
4. Osoba Merytoryczna wypełnia dane formularza.
5. System waliduje dane formularza i tworzy odpowiednie obiekty w systemie.
Status dokumentu zostaje oznaczony jako NOWY.
6. Przypadek użycia kończy bieg.
Typ:
1. System odnalazł niepoprawne wartości wśród wprowadzonych przez
użytkownika danych,.
Wyjątek
2. System prezentuje odnalezione błędy, oznaczając błędne pola i wyświetlając
Nazwa:
przy każdym z nich opis błędu. System proponuje zapisanie danych formularza
Błędna walidacja danych
ze statusem KOPIA_ROBOCZA.
3. Osoba Merytoryczna zapoznaje się z błędami i zapisuje formularz.
4. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Edycja metryki
dokumentu
2a. Osoba merytoryczna wybiera rekord z listy i wybiera akcję Edytuj.
3. System prezentuje formularz dokumentu zawierający następujące bloki danych,
zgodny z modelem domenowym:

typ dokumentu,

komórki organizacyjne, w których wymagane jest procesowanie
dokumentu,

właściwości dokumentu,

rozszerzone uprawnienia dokumentu,

dane finansowe,

dane do ubezpieczeń społecznych,

kontrahent,
Strona 44/68
Załącznik nr 1 do umowy

załączniki w formie plików binarnych,

treść umowy.
4. Osoba Merytoryczna wypełnia dane formularza.
5. System waliduje dane formularza i zapisuje zmiany w obiektach w systemie. 6.
Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Utworzenie dokumentu
na podstawie dokumentu
archiwalnego
1. System wyszukuje dokument zgodnie z UC008 i prezentuje użytkownikowi listę
wyników.
2. Osoba Merytoryczna wybiera rekord z listy.
3. Osoba Merytoryczna wybiera opcje Utwórz nowy z dokumentu archiwalnego.
4. System prezentuje ekran z listą plików binarnych dołączonych do dokumentu
archiwalnego.
5. Osoba Merytoryczna wybiera pliki, które będą dołączone do nowego dokumentu
i wybiera opcję Dalej.
6. System prezentuje ekran z parametrami dokumentu archiwalnego (dane
finansowe, dane o ubezpieczeniach społecznych, dysponenci, wymagane
komórki organizacyjne).
7. Osoba Merytoryczna wybiera parametry do przekopiowania do nowego
dokumentu i wybiera opcję Wygeneruj nowy dokument.
8. System zapisuje nowy dokument ze statusem OPINIOWANY.
9. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Zapisanie
dokumentu
jako szablonu
2a. Osoba merytoryczna wybiera rekord z listy i wybiera akcję Edytuj.
3. System prezentuje formularz dokumentu zawierający następujące bloki danych,
zgodny z modelem domenowym:

typ dokumentu,

komórki organizacyjne, w których wymagane jest procesowanie
dokumentu,

właściwości dokumentu,

rozszerzone uprawnienia dokumentu,

dane finansowe,

dane do ubezpieczeń społecznych,

kontrahent,

załączniki w formie plików binarnych,

treść umowy.
4. Osoba Merytoryczna wypełnia dane formularza.
5. Osoba Merytoryczna wybiera opcję Zapisz jako szablon
6. System wyświetla okno dialogowe i prosi o podanie nazwy szablonu.
7. Osoba Merytoryczna podaje nową nazwę szablonu.
8. System zapisuje obiekt zgodnie z modelem domenowym w statusie SZABLON.
9. Przypadek użycia kończy bieg.
Strona 45/68
Załącznik nr 1 do umowy
Przypadek
użycia:
Uwagi:
UC001a: Edycja treści dokumentu
Celem przypadku użycia jest umożliwienie pracownikowi merytorycznemu edycji treści
dokumentu. System musi umożliwiać tworzenie dokumentów z jednostek redakcyjnych (np.
akapit, ustęp, punkt, podpunkt, tiret) oraz korzystanie z predefiniowanych szablonów i
zweryfikowanych klauzul (o sile wyższej, przetwarzaniu danych osobowych, itp.). Edycja
treści dokumentu jest możliwa wyłącznie na wskazanych wykonawcy statusach dokumentów
zdefiniowanych przez Zamawiającego. Edycja treści dokumentu generuje wpis do dziennika
zdarzeń w systemie.
Scenariusze:
Typ:
1. Przypadek użycia rozpoczyna się, gdy Osoba Merytoryczna wyświetli dokument
w trybie edycji zgodnie z UC001.
Bazowy
2. Osoba Merytoryczna wybiera opcję Edytuj treść dokumentu
Nazwa:
Scenariusz podstawowy 3. System wyświetla edytor treści dokumentu.
4. Osoba Merytoryczna dokonuje pożądanych zmian w treści dokumentu.
5. Osoba Merytoryczna wybiera opcję Zapisz.
6. System zapisuje zmiany w treści dokumentu.
7. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Anulowanie edycji
Przypadek
użycia:
5a. Osoba Merytoryczna wybiera opcję Anuluj.
6. System pyta o potwierdzenie anulowania.
7. Osoba Merytoryczna potwierdza anulowanie zmian.
8. System anuluje zmiany.
9. Przypadek użycia kończy bieg.
UC003: Anulowanie dokumentu
Uwagi:
Celem przypadku jest anulowanie prac nad dokumentem i powiadomienie zainteresowanych
osób o tym fakcie. Anulowania dokumentu może dokonać wyłącznie Osoba Merytoryczna.
Anulowanie dokumentu generuje wpis do dziennika zdarzeń w systemie.
Warunki
Niepusty
komentarz
Status w ZP
Opis
System wymusza dodanie niepustego komentarza z powodem anulowania dokumentu.
Anulowanie dokumentu jest możliwe w każdym momencie w przypadku braku podania w ZP
lub do momentu uzyskania statusu Zatwierdzony przez Kierownika Zamawiającego lub
Zatwierdzony przez Dyrektora WZP w systemie ZP.
Scenariusze:
Strona 46/68
Załącznik nr 1 do umowy
Typ:
Bazowy
Nazwa:
Scenariusz podstawowy
1. System wyświetla listę dokumentów w statusie OPINIOWANY.
2. Osoba Merytoryczna wybiera dokument z listy.
3. Osoba Merytoryczna wybiera opcję Anuluj dokument.
4. System wywołuje przypadek użycia IUC003.
5. System wyświetla formularz pozwalający na dodanie komentarza do dokumentu
z powodem anulowania. Osoba Merytoryczna uzupełnia komentarz.
6. Dokument zmienia status na ANULOWANY.
7. Przypadek użycia kończy bieg.
Typ:
Wyjątek
Nazwa:
Niedozwolony status
4a. System pobiera podanie do dokumentu z systemu ZP zgodnie z IUC003.
5. W przypadku, gdy podanie w ZP ma niedozwolony status, system uniemożliwia
anulowanie dokumentu i wyświetla odpowiednią informację użytkownikowi.
6. Przypadek użycia kończy bieg.
Przypadek
użycia:
UC008: Wyszukanie dokumentu
Uwagi:
Generyczny opis generowania list dokumentów.
Scenariusze:
Typ:
1. System prezentuje formularz uzupełniający kryteria wyszukiwania
dokumentów. W zależności od listy i uprawnień użytkownika mogą to być:
Bazowy
- przedział czasu utworzenia dokumentu,
Nazwa:
Scenariusz podstawowy - osoba - właściciel dokumentu,
- typ dokumentu,
- komórka organizacyjna
- status dokumentu
- inne
2. Użytkownik uzupełnia formularz i wywołuje akcję Szukaj.
3. System wyświetla listę rekordów reprezentujących znalezione dokumenty.
4. Przypadek użycia kończy bieg
Przypadek
użycia:
Uwagi:
UC016: Edycja dysponentów
Celem przypadku użycia jest przypisanie dysponenta środków do dokumentu przez
pracownika merytorycznego. Możliwe jest przypisanie więcej niż jednego dysponenta do
danego dokumentu. Lista dysponentów jest pobierana z systemu SK. Przypisanie dysponenta
generuje wpis do dziennika zdarzeń w systemie.
Strona 47/68
Załącznik nr 1 do umowy
Scenariusze:
Typ:
1. System prezentuje listę dokumentów w statusie OPINIOWANY.
Bazowy
2. Osoba Merytoryczna wybiera rekord z listy i wybiera opcję Edytuj dysponentów
Nazwa:
3. System prezentuje listę Osób Dysponujących przypisanych do dokumentu oraz
listę innych Osób Dysponujących nie przypisanych do dokumentu.
Scenariusz podstawowy
4. Osoba Merytoryczna wybiera osobę z listy osób nie przypisanych do dokumentu
i wybiera opcję Dodaj dysponenta.
5. System zapisuje zmiany w obiektach domenowych.
6. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Usunięcie dysponenta
Przypadek
użycia:
Uwagi:
4a. Osoba Merytoryczna wybiera osobę z listy osób przypisanych do dokumentu i
wybiera opcję Usuń dysponenta.
5. System prosi o potwierdzenie usunięcia.
6. System zapisuje zmiany w obiektach domenowych.
7. Przypadek użycia kończy bieg.
UC019: Generowanie umowy właściwej
Celem przypadku użycia jest wygenerowanie umowy właściwej z projektu umowy lub IPU.
Generowanie umowy musi umożliwić przeniesienie z dokumentu źródłowego wyłącznie
wybranych przez pracownika merytorycznego załączników do umowy właściwej.
Generowanie umowy generuje wpis do dziennika zdarzeń w systemie.
Scenariusze:
Typ:
1. System prezentuje listę dokumentów typu Projekt umowy i IPU w statusie
ZAAKCEPTOWANY.
Bazowy
2. Osoba Merytoryczna wybiera rekord z listy.
Nazwa:
Scenariusz podstawowy 3. Osoba Merytoryczna wybiera opcje Generuj umowę właściwą.
4. System prezentuje ekran z listą plików binarnych dołączonych do dokumentu
bazowego.
5. Osoba Merytoryczna wybiera pliki, które będą dołączone do nowego dokumentu
i wybiera opcję Dalej.
6. System prezentuje ekran z parametrami dokumentu bazowego (dane finansowe,
dane o ubezpieczeniach społecznych, dysponenci, wymagane komórki
organizacyjne)
7. Osoba Merytoryczna wybiera parametry do przekopiowania do nowego
dokumentu i wybiera opcję Wygeneruj nowy dokument
8. System archiwizuje dokument bazowy ze statusem ZAMKNIĘTY i zapisuje
nowy dokument ze statusem OPINIOWANY.
9. Przypadek użycia kończy bieg.
Strona 48/68
Załącznik nr 1 do umowy
Przypadek
użycia:
Uwagi:
UC020: Rejestracja umowy właściwej
Celem przypadku użycia jest zmiana statusu umowy właściwej na podpisaną. System musi
umożliwiać ręczne wpisanie daty zawarcia umowy. Podpisanie umowy generuje wpis do
dziennika zdarzeń w systemie.
Scenariusze:
Typ:
1. System prezentuje listę dokumentów w statusie DO_PODPISU.
Bazowy
2. Osoba Merytoryczna wybiera rekord z listy oraz wybiera opcję Dołącz
informację o podpisaniu umowy.
Nazwa:
Scenariusz podstawowy 3. System prezentuje formularz umożliwiający podanie daty podpisania umowy
oraz dołączenie pliku binarnego ze skanem umowy.
4. Osoba Merytoryczna wybiera opcję Zapisz.
5. System waliduje dane.
6. System zapisuje zmiany w obiektach domenowych. Dokument zmienia status na
PODPISANY.
7. System wywołuje integracyjny przypadek użycia IUC009.
8. System wywołuje integracyjny przypadek użycia IUC006.
9. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Brak podpisu
Przypadek
użycia:
Uwagi:
2a. Osoba Merytoryczna wybiera rekord z listy oraz wybiera opcję Brak podpisu
3. Osoba Merytoryczna wybiera opcję Zapisz.
4. System zapisuje zmiany w obiektach domenowych. Dokument zmienia status na
NIE_PODPISANY.
5. Przypadek użycia kończy bieg.
UC023: Seryjne tworzenie dokumentów na podstawie szablonu
Celem przypadku użycia jest umożliwienie seryjnego utworzenia wielu umów według
jednego szablonu umowy na podstawie listy pól do uzupełnienia i powiązanych z nimi źródeł
danych.
Scenariusze:
Typ:
1. System prezentuje Osobie Merytorycznej listę dokumentów ze statusem
SZABLON.
Bazowy
2. Osoba Merytoryczna wybiera rekord z listy i wybiera opcję Utwórz umowy.
Nazwa:
Scenariusz podstawowy 3. System analizuje listę pól w szablonie, wyświetla ich listę użytkownikowi.
4. Osoba Merytoryczna definiuje źródło danych dla każdego z pól.
5. Osoba wybiera zakres danych Kontrahentów, dla jakich system musi
Strona 49/68
Załącznik nr 1 do umowy
wygenerować dokumenty.
6. Osoba Merytoryczna wybiera opcję Zapisz.
7. System sprawdza, czy każde pole danych w dokumencie ma zdefiniowane
źródło.
8. System tworzy nowe obiekty biznesowe i zapisuje nowe dokumenty ze statusem
NOWY.
9. Przypadek użycia kończy bieg.
8a. System informuje Osobę Merytoryczną o braku danych dla danego rekordu nie
przerywając generowania umów.
9. System prezentuje Osobie Merytorycznej zapis błędów dla wybranego zestawu
rekordów.
10. Przypadek użycia kończy bieg.
Typ:
Wyjątek
Nazwa:
Brak danych
Przypadek
użycia:
UC029: Wydruk dokumentu
Uwagi:
Celem przypadku użycia jest wydruk dokumentu. Wydruk dokumentu jest możliwy na
każdym etapie cyklu życia dokumentu. Wydruk dokumentu generuje wpis w dzienniku
zdarzeń systemu.
Warunki
Znak wodny
Opis
Wszystkie dokumenty poza statusem DO_PODPISU muszą być oznaczone na wydruku bardzo
wyraźnym znakiem wodnym, ale nie utrudniającym odczytu wersji roboczej.
Scenariusze:
Typ:
Bazowy
Nazwa:
Scenariusz podstawowy
Przypadek
użycia:
Uwagi:
1. Użytkownik wyszukuje dokument zgodnie z UC008.
2. System prezentuje wyniki wyszukiwania.
3. Użytkownik wybiera rekord z listy.
4. System prezentuje ekran z treścią dokumentu.
5. Użytkownik wybiera opcję Drukuj.
6. System drukuje dokument.
7. Przypadek użycia kończy bieg.
UC032: Archiwizacja dokumentu
Celem przypadku użycia jest zmiana statusu umowy na ZREALIZOWANY oraz dodanie
informacji o należytym bądź nie wykonaniu umowy przez kontrahenta. Archiwizacja
dokumentu generuje wpis do dziennika zdarzeń w systemie.
Scenariusze:
Typ:
1. System wyświetla listę dokumentów ze statusem REALIZOWANY.
Strona 50/68
Załącznik nr 1 do umowy
Bazowy
2. Użytkownik wybiera rekord z listy i wybiera opcję Archiwizuj.
Nazwa:
3. System wyświetla formularz umożliwiający podanie opinii o sposobie realizacji
umowy przez kontrahenta.
Scenariusz podstawowy
4. Użytkownik wybiera opcję Zapisz.
5. System zmienia status dokumentu na ZREALIZOWANY.
6. Przypadek użycia kończy bieg.
Przypadek
użycia:
Uwagi:
UC036: Edycja wysokości składek na ubezpieczenia społeczne
Celem przypadku użycia jest umożliwienie Osobie Opiniującej w Wydziale Kadr, Szkolenia i
Spraw Socjalnych ręcznej zmiany wysokości automatycznie wyliczonych wysokości składek
na ubezpieczenia społeczne.
Scenariusze:
Typ:
1. Przypadek użycia rozpoczyna się, gdy Osoba Opiniująca w Wydziale Kadr,
Szkolenia i Spraw Socjalnych wyświetli dokument w trybie edycji zgodnie z
Bazowy
UC001.
Nazwa:
2. Osoba Opiniująca wybiera opcję Edytuj wysokość składek
Scenariusz podstawowy
3. System wyświetla metrykę dokumentu w zakresie składek na ubezpieczenia
społeczne
4. Osoba Opiniująca dokonuje pożądanych zmian w wysokości składek.
5. Osoba Opiniująca wybiera opcję Zapisz.
6. System zapisuje zmiany w metryce dokumentu.
7. Przypadek użycia kończy bieg.
Przypadek
użycia:
Uwagi:
UC037: Edycja kontrahenta
Celem przypadku użycia jest umożliwienie użytkownikowi edycję danych kontrahenta, w
szczególności utworzenie nowego. Utworzenie kontrahenta generuje wpis w dzienniku
zdarzeń w systemie.
Scenariusze:
Typ:
1. Osoba Merytoryczna wyszukuje kontrahenta zgodnie z IUC008.
Bazowy
2. System prezentuje listę wyników.
Nazwa:
3. Osoba Merytoryczna wybiera kontrahenta z listy i wybiera opcję Nowy
kontrahent w CRU
Scenariusz podstawowy
4. System wyświetla formularz zgodny z modelem domenowym i wypełnia go
danymi z systemu SDK.
5. Użytkownik uzupełnia niezbędne dane i wybiera opcję Zapisz.
6. System waliduje dane.
Strona 51/68
Załącznik nr 1 do umowy
7. System zapisuje obiekt biznesowy.
8. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Edycja kontrahenta
3a. Użytkownik wybiera rekord z listy i wybiera opcję Edytuj
4. System wyświetla formularz zgodny z modelem domenowym
5. Powrót do scenariusza podstawowego, kontynuacja.
Typ:
Wyjątek
Nazwa:
Błąd
1a. W przypadku wystąpienia błędu (błąd komunikacji, niedostępność systemu
SDK, inne) system SDK generuje informację do systemu CRU.
2. System CRU prezentuje informację o błędzie użytkownikowi.
3. Przypadek użycia kończy bieg.
Przypadek
użycia:
UC038: Wyszukanie kontrahenta
Uwagi:
Celem przypadku użycia jest wyszukanie kontrahenta w systemie CRU.
Scenariusze:
Typ:
1. System prezentuje formularz uzupełniający kryteria wyszukiwania
kontrahentów. Mogą to być:
Bazowy
- typ kontrahenta (osoba fizyczna/prawna),
Nazwa:
Scenariusz podstawowy - nazwa lub fragment nazwy,
- NIP,
- PESEL,
- REGON
- KRS
- numer dokumentu
- kary umowne
- wierzytelności
- inne
2. Użytkownik uzupełnia formularz i wywołuje akcję Szukaj.
3. System wyszukuje kontrahentów względem zadanych kryteriów
4. System wyświetla listę rekordów reprezentujących znalezionych kontrahentów.
5. Przypadek użycia kończy bieg
Opiniowanie Dokumentu
Strona 52/68
Załącznik nr 1 do umowy
uc Opiniow anie Dokumentu
UC006: Zaopiniow anie
dokumentu
UC014: Edycj a zadań do
w ykonania
UC010: Edycj a
komentarza do treści
dokumentu
Osoba Opiniuj ąca
Osoba Akceptuj ąca
Osoba Dekretuj ąca
(from
Role)
(from
Role)
(from
Role)
UC038: Edycj a
zastępstw a
UC012: Dekretacj a
dokumentu
UC035: Prezentacj a
listy zmian
Opiniowanie Dokumentu
Przypadek
użycia:
Uwagi:
UC006: Zaopiniowanie dokumentu
Przypadek użycia, którego celem jest rekomendacja pozytywna (do akceptacji) lub
negatywna (do odrzucenia) dokumentu przez pracownika wydziału, w którym dokument jest
procedowany. Rekomendację otrzymuje dyrektor danego wydziału. Zaopiniowanie
dokumentu generuje wpis do dziennika zdarzeń w systemie.
Scenariusze:
Typ:
Bazowy
Nazwa:
Rekomendacja
pozytywna
1. Osoba Opiniująca wyświetla dokumenty w statusie OPINIOWANY.
2. Osoba Opiniująca wybiera rekord z listy.
3. Osoba Opiniująca wybiera opcję Rekomendacja pozytywna.
4. System pyta, czy Osoba Opiniująca chce dodać komentarz do rekomendacji.
Osoba Opiniująca uzupełnia komentarz.
5. Dokument zmienia status na DO_AKCEPTACJI.
6. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Rekomendacja
negatywna
3a. Osoba Opiniująca wybiera opcję Rekomendacja negatywna.
4. System wyświetla formularz pozwalający na dodanie komentarza do
rekomendacji. Osoba Opiniująca uzupełnia komentarz.
5. Dokument zmienia status na DO_AKCEPTACJI.
6. Przypadek użycia kończy bieg.
Strona 53/68
Załącznik nr 1 do umowy
Typ:
3a. Osoba Opiniująca wybiera opcję Wyślij do FK.
Alternatywny
4. System wywołuje integracyjny przypadek użycia IUC006.
Nazwa:
5. Przypadek użycia kończy bieg.
Wysłanie dokumentu do
systemu FK
Przypadek
użycia:
Uwagi:
UC010: Edycja komentarza do treści dokumentu
Celem przypadku użycia jest umożliwienie edycji własnego komentarza osobie opiniującej
dokument w odniesieniu do jednostki redakcyjnej treści dokumentu (paragraf, punkt,
podpunkt, tiret), a w szczególności dodania nowego i edycji. Komentarze są podstawową
formą komunikacji między osobami pracującymi nad tym samym dokumentem. Edycja
komentarza generuje wpis do dziennika zdarzeń w systemie.
Scenariusze:
Typ:
1. Przypadek użycia rozpoczyna się, kiedy Osoba Opiniująca wyświetli treść
dokumentu w trybie edycji.
Bazowy
2. Osoba Opiniująca zaznacza jednostkę redakcyjną tekstu a system wyświetla listę
Nazwa:
komentarzy.
Scenariusz podstawowy
3. Osoba Opiniująca wybiera opcję Dodaj komentarz.
4. System wyświetla formularz zgodnie z modelem domenowym.
5. Osoba Opiniująca uzupełnia dane i wybiera opcję Zapisz.
6. System zapisuje dane.
7. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Edycja komentarza
2a. Osoba Opiniująca wskazuje komentarz i wybiera akcję Edytuj
3. Powrót do punktu 4 Scenariusza podstawowego, kontynuacja.
Przypadek
użycia:
UC012: Dekretacja dokumentu
Uwagi:
Celem przypadku użycia jest przypisanie osób odpowiedzialnych za procesowanie
Strona 54/68
Załącznik nr 1 do umowy
dokumentu w danej Komórce Organizacyjnej. Dekretacji Dokumentu można dokonać w
każdym momencie Opiniowania Dokumentu w danej Komórce Organizacyjnej, przy czym
Dekretacja do Osób Opiniujących jest obowiązkowa w momencie, w którym Dokument trafia
po raz pierwszy do danej Komórki Organizacyjnej. Przypisując osoby, Osoba Dekretująca
definiuje, czy wymagana jest rekomendacja wszystkich osób przypisanych do dokumentu.
Lista pracowników danej komórki organizacyjnej jest pobierana z systemu SK. Przypisanie
osób odpowiedzialnych generuje wpis do dziennika zdarzeń w systemie.
Scenariusze:
Typ:
1. System prezentuje listę dokumentów w statusie OPINIOWANE,
DO_DEKRETACJI i DO_OPINIOWANIA.
Bazowy
2. Osoba Dekretująca wybiera rekord z listy i wybiera opcję Edytuj osoby
Nazwa:
opiniujące
Scenariusz podstawowy
3. System prezentuje listę osób przypisanych do dokumentu oraz listę osób nie
przypisanych do dokumentu, pole wyboru określające, czy do akceptacji jest
wymagana rekomendacja od wszystkich osób, pole wyboru określające, czy w
przyszłości dekretować dokument tego samego typu tym samym osobom oraz
pole wyboru określające typ osoby dekretowanej: Osoba Opiniująca, Osoba
Akceptująca, Osoba Akceptująca Rekomendację, Osoba Kontrasygnująca.
4. Osoba Dekretująca wybiera osobę z listy osób nie przypisanych do dokumentu i
wybiera opcję Dodaj osobę opiniującą.
5. Dokument zmienia status na DO_OPINIOWANIA.
6. System zapisuje zmiany w obiektach biznesowych.
7. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Usunięcie
osoby opiniującej
Przypadek
użycia:
Uwagi:
4a. Osoba Dekretująca wybiera osobę z listy osób przypisanych do dokumentu i
wybiera opcję Usuń osobę opiniującą.
5. System prosi o potwierdzenie usunięcia.
6. System zapisuje zmiany w obiektach biznesowych.
7. Przypadek użycia kończy bieg.
UC014: Edycja zadań do wykonania
Celem przypadku użycia jest umożliwienie osobie akceptującej zlecania zadań
poszczególnym osobom odpowiedzialnym za procesowanie dokumentu w danej komórce.
Zadanie ma określony termin wykonania. Zlecenie zadania pracownikowi generuje wpis do
dziennika zdarzeń w systemie.
Scenariusze:
Typ:
Bazowy
1. Osoba Akceptująca wyszukuje dokument według UC008.
2. System prezentuje listę dokumentów.
Strona 55/68
Załącznik nr 1 do umowy
Nazwa:
3. Osoba Akceptująca wybiera rekord z listy wyników i przechodzi do listy zadań.
Scenariusz podstawowy 4. Osoba Akceptująca wybiera opcję Nowe zadanie.
5. System wyświetla formularz Zadania zgodny z obiektem domenowym.
6. Osoba Akceptująca uzupełnia wymagane dane i wybiera opcję Zapisz.
7. System waliduje wprowadzone dane.
8. System tworzy i zapisuje obiekty biznesowe.
9. Przypadek użycia kończy bieg.
Typ:
Alternatywny
Nazwa:
Usunięcie zadania
4a. Osoba Akceptująca wskazuje komentarz i wybiera akcję Usuń
5. System prosi o potwierdzenie usunięcia
6. Osoba Akceptująca potwierdza usunięcie zadania.
7. System usuwa zadanie i zapisuje zmiany w obiektach biznesowych.
8. Przypadek użycia kończy bieg.
Przypadek
użycia:
UC035: Prezentacja listy zmian
Uwagi:
Celem przypadku użycia jest umożliwienie użytkownikowi przeprowadzenie analizy
porównawczej dwóch wersji tego samego dokumentu.
Scenariusze:
Typ:
1. Przypadek użycia rozpoczyna się w momencie, gdy użytkownik wyszuka
dokumenty zgodnie z UC008.
Bazowy
2. System prezentuje listę dokumentów.
Nazwa:
Scenariusz podstawowy 3. Użytkownik wybiera dokument z listy i wybiera opcję Pokaż poprzednie wersje
4. Użytkownik wybiera dwie dowolne wersje dokumentu.
5. System prezentuje listę zmian pomiędzy wersjami.
6. Użytkownik wybiera zmianę z listy.
7. System prezentuje zmianę między wersjami w postaci dwóch równoległych
obszarów wyświetlających tę samą jednostkę redakcyjną przed i po zmianie.
8. Przypadek użycia kończy bieg.
Przypadek
użycia:
UC038: Edycja zastępstwa
Uwagi:
Celem przypadku użycia jest przekazanie uprawnień wybranego pracownika innemu
pracownikowi UMWD, np. na czas urlopu.
Strona 56/68
Załącznik nr 1 do umowy
Scenariusze:
Typ:
1. Użytkownik wybiera opcje Przekaż uprawnienia.
Bazowy
2. System pobiera listę pracowników odpowiedniej komórki merytorycznej
zgodnie z IUC005.
Nazwa:
Scenariusz podstawowy 3. Użytkownik wybiera żądaną osobę oraz określa zakres dat, na jaki przekazuje
swoje uprawnienia.
4. Użytkownik wybiera opcję Zapisz.
5. Przypadek użycia kończy bieg.
Powiadomienia i Raporty
uc Pow iadomienia i Raporty
UC034: Wysłanie
pow iadomienia
Silnik raportow y
Agent pow iadomień
(from
Systemy)
UC033:
Wygenerow anie
raportu
(from
Systemy)
Powiadomienia i Raporty
Przypadek
użycia:
UC033: Wygenerowanie raportu
Uwagi:
Generyczny opis generowania raportów.
Scenariusze:
Typ:
1. Użytkownik wybiera rodzaj raportu z listy predefiniowanych raportów
Bazowy
2. System prezentuje formularz uzupełniający kryteria raportu. W zależności od
rodzaju raportu mogą to być:
Nazwa:
Scenariusz podstawowy - przedział czasu
- osoba
- typ dokumentu
- komórka organizacyjna
- status dokumentu
- inne
3. Użytkownik uzupełnia formularz i wywołuje akcję generuj.
4. System prezentuje "pasek postępu" z informacja o pozostałym czasie
wymaganym do skończenia raportu
5. System wyświetla wygenerowany raport.
6. Przypadek użycia kończy bieg.
Strona 57/68
Załącznik nr 1 do umowy
Przypadek
użycia:
UC034: Wysłanie powiadomienia
Uwagi:
Powiadomienie jest to przesłanie informacji o zarejestrowaniu przez system pewnych zdarzeń
do określonych grup użytkowników.
Scenariusze:
Typ:
Zostało wywołane zdarzenie Z:
Bazowy
Nazwa:
1. System analizuje dane Dokumentów powiązanych ze zdarzeniem Z,
Scenariusz podstawowy 2. Gdy spełnione są warunki powiadomienia, system wysyła powiadomienie do
grupy użytkowników zdefiniowanej w warunkach powiadomienia,
3. Przypadek użycia kończy bieg
Interfejsy i Integracja
Strona 58/68
Załącznik nr 1 do umowy
uc Interfej sy i Integracj a
IUC011: Anulow anie
lub odrzucenie
podania w ZP
IUC008: Wyszukanie
kontrahenta w SDK
System danych o
kontrahentach
(from
Systemy)
System obsługuj ący
zamów ienia publiczne
(from
Systemy)
IUC003: Pobranie
podania z ZP
IUC009: Wysłanie
dokumentu do ZP
IUC006: Wysłanie
dokumentu do FK
IUC005: Pobranie listy
pracow ników z SK
System katalogow y
(from
Systemy)
System finansow o-księgow y
(from
Systemy)
IUC010:
Synchronizacj a
słow ników z FK
Interfejsy i Integracja
Przypadek
użycia:
IUC003: Pobranie podania z ZP
Uwagi:
Pobranie danych o podaniu z systemu wspomagającego obsługę zamówień publicznych.
Scenariusze:
Typ:
1. System CRU odpytuje ZP o podanie o danym numerze L.dz. wywołując
odpowiednią metodę API.
Bazowy
2. System ZP zwraca rekord podania zgodny z modelem domenowym systemu ZP.
Nazwa:
Scenariusz podstawowy 3. System CRU wybiera z rekordu podania potrzebne dane i zapisuje je w obiekcie
dokumentu zgodnie z modelem domenowym.
4. Przypadek użycia kończy bieg.
Typ:
Wyjątek
Nazwa:
Błąd
1a. W przypadku wystąpienia błędu (błąd komunikacji, niedostępność systemu ZP,
inne) system ZP generuje informację do systemu CRU.
2. System CRU prezentuje informację o błędzie użytkownikowi.
3. Przypadek użycia kończy bieg.
Strona 59/68
Załącznik nr 1 do umowy
Przypadek
użycia:
IUC005: Pobranie listy pracowników z SK
Uwagi:
Pobranie listy pracowników z systemu katalogowego. System musi umożliwiać filtrowanie
listy pracowników ze względu na jednostkę organizacyjną.
Scenariusze:
Typ:
1. System prezentuje formularz uzupełniający kryteria wyszukiwania
użytkowników. Mogą to być:
Bazowy
- nazwisko
Nazwa:
Scenariusz podstawowy - komórka organizacyjna
- inne
2. Użytkownik uzupełnia formularz i wywołuje akcję generuj.
3. System odpytuje SK o listę użytkowników względem zadanych kryteriów i
prezentuje "pasek postępu" z informacja o pozostałym czasie wymaganym do
skończenia listy
4. System SK zwraca listę rekordów spełniających kryteria wyszukiwania zgodnie
z własnym modelem domenowym.
5. System wyświetla listę rekordów reprezentujących znalezionych
użytkowników.
6. Przypadek użycia kończy bieg
Typ:
Wyjątek
Nazwa:
Błąd
3a. W przypadku wystąpienia błędu (błąd komunikacji, niedostępność systemu
SK, inne) system SK generuje informację do systemu CRU.
4. System CRU prezentuje informację o błędzie użytkownikowi.
5. Przypadek użycia kończy bieg.
Przypadek
użycia:
IUC006: Wysłanie dokumentu do FK
Uwagi:
Wysłanie danych o dokumencie do systemu finansowo-księgowego. Konieczne do
zaopiniowania dokumentu w Departamencie Budżetu i Finansów.
Scenariusze:
Typ:
1. System CRU tworzy dokument zgodny z własnym modelem domenowym
Bazowy
2. System CRU wywołuje odpowiednią metodę API systemu FK i przekazuje
dokument do systemu FK.
Nazwa:
3.
Przypadek
użycia kończy bieg.
Scenariusz podstawowy
Strona 60/68
Załącznik nr 1 do umowy
Typ:
Wyjątek
Nazwa:
Błąd
2a. W przypadku wystąpienia błędu (błąd komunikacji, niedostępność systemu
FK, dokument o podanym numerze istnieje, inne) system FK generuje
informację do systemu CRU.
3. System CRU prezentuje informację o błędzie użytkownikowi.
4. Przypadek użycia kończy bieg.
Przypadek
użycia:
IUC008: Wyszukanie kontrahenta w SDK
Uwagi:
Generyczny sposób generowania list kontrahentów.
Warunki
Minimalny
zestaw
parametrów
wyszukiwania
Opis
Do uzupełnienia w UMWD.
Scenariusze:
Typ:
1. System prezentuje formularz uzupełniający kryteria wyszukiwania
kontrahentów. Mogą to być:
Bazowy
- typ kontrahenta (osoba fizyczna/prawna),
Nazwa:
Scenariusz podstawowy - nazwa lub fragment nazwy,
- NIP,
- PESEL,
- REGON
- KRS
- numer dokumentu
- kary umowne
- wierzytelności
- inne
2. Użytkownik uzupełnia formularz i wywołuje akcję Wyszukaj.
3. System odpytuje SDK o listę kontrahentów względem zadanych kryteriów i
prezentuje "pasek postępu" z informacja o pozostałym czasie wymaganym do
skończenia listy
4. System SDK zwraca listę rekordów spełniających kryteria wyszukiwania
zgodnie z własnym modelem domenowym.
5. System wyświetla listę rekordów reprezentujących znalezionych kontrahentów.
6. Przypadek użycia kończy bieg
Typ:
3a. W przypadku wystąpienia błędu (błąd komunikacji, niedostępność systemu
SDK, inne) system SDK generuje informację do systemu CRU.
Strona 61/68
Załącznik nr 1 do umowy
Wyjątek
Nazwa:
Błąd
4. System CRU prezentuje informację o błędzie użytkownikowi.
5. Przypadek użycia kończy bieg.
Przypadek
użycia:
IUC009: Wysłanie dokumentu do ZP
Uwagi:
Celem przypadku użycia jest przekazanie informacji o zmianie statusu dokumentu w systemie
CRU.
Scenariusze:
Typ:
1. System CRU tworzy dokument zgodny z własnym modelem domenowym
Bazowy
2. System CRU wywołuje odpowiednią metodę API systemu ZP i przekazuje
dokument do systemu ZP.
Nazwa:
Scenariusz podstawowy 3. Przypadek użycia kończy bieg.
Typ:
Wyjątek
Nazwa:
Błąd
2a. W przypadku wystąpienia błędu (błąd komunikacji, niedostępność systemu ZP,
dokument o podanym numerze istnieje, inne) system ZP generuje informację
do systemu CRU.
3. System CRU prezentuje informację o błędzie użytkownikowi.
4. Przypadek użycia kończy bieg.
Przypadek
użycia:
IUC010: Synchronizacja słowników z FK
Uwagi:
Synchronizacja słowników z systemu FK.
Scenariusze:
Typ:
1. Raz na dobę system CRU wywołuje odpowiednią metodę API systemu FK.
Bazowy
2. System FK udostępnia wartości pól słownikowych wykorzystywanych w
systemie CRU.
Nazwa:
Scenariusz podstawowy 3. System CRU zapisuje nowe wartości pól.
4. Przypadek użycia kończy bieg.
Typ:
1a. W przypadku wystąpienia błędu (błąd komunikacji, niedostępność systemu
Strona 62/68
Załącznik nr 1 do umowy
Wyjątek
Nazwa:
Błąd
Przypadek
użycia:
Uwagi:
FK, inne) system FK generuje informację do systemu CRU.
2. System CRU generuje informację o błędzie do dziennika zdarzeń.
3. Przypadek użycia kończy bieg.
IUC011: Anulowanie lub odrzucenie podania w ZP
Celem przypadku użycia jest obsługa anulowania lub odrzucenia podania w ZP.
Scenariusze:
Typ:
1. System odbiera informację o anulowaniu lub odrzuceniu podania w systemie
ZP.
Bazowy
2. System wyszukuje żądany dokument oraz archiwizuje go ze statusem
Nazwa:
odpowiednio ANULOWANY_ZP lub ODRZUCONY_ZP.
Scenariusz podstawowy
3. Przypadek użycia kończy bieg.
Typ:
Exception
Nazwa:
Błąd
2a. W przypadku wystąpienia błędu (brak dokumentu w systemie, inne) system
CRU generuje informację do systemu ZP.
3. System CRU generuje informację o błędzie do dziennika zdarzeń.
4. Przypadek użycia kończy bieg.
Strona 63/68
Załącznik nr 1 do umowy
Definicje powiadomień i raportów
Powiadomienia
Minimalna lista powiadomień w systemie. W przypadku kiedy w trakcie realizacji systemu pojawi się
konieczność zdefiniowania dodatkowych lub edycji istniejących powiadomień, lista odbiorców i treść
powiadomienia zostanie dostosowane do potrzeb Zamawiającego.
1. Powiadamianie Osoby Merytorycznej o odrzuceniu dokumentu z informacją, na jakim etapie i przez
kogo został odrzucony.
2. Powiadamianie Osoby Merytorycznej o zaakceptowaniu dokumentu z informacją, na jakim etapie i
przez kogo został zaakceptowany.
3. Powiadamianie Osoby Opiniującej o cofnięciu dokumentu z informacją, przez kogo został cofnięty.
4. Powiadomienie Osób Opiniujących w WZP, Osoby Akceptującej o anulowaniu umowy dekretowanej
wcześniej w WZP.
5. Powiadamianie Osób Opiniujących w DBiF, Osoby Akceptującej w DBiF o anulowaniu umowy
dekretowanej wcześniej w DBiF.
6. Powiadamianie Osób Opiniujących w WK, Osoby Akceptującej w WK o anulowaniu umowy
dekretowanej wcześniej w WK.
7. Powiadomienie Koordynatora Radców Prawnych, Osób Opiniujących w WZP, Dyrektora WZP,
Dyrektora Komórki Merytorycznej oraz Osób Opiniujących i Dyrektorów DBiF o zamknięciu umowy.
8. Powiadomienie Osób Opiniujących w DBiF, WZP, WK o zmianie statusu na NIE_PODPISANA i
BRAK_KONTRASYGNATY, KONTRASYGNOWANY, PODPISANY.
9. Powiadamianie WK (w przypadku umów-zleceń dla danego kontrahenta), DBiF, Dyrektorów
wydziałów, z których osoby merytoryczne mają podpisane umowy z danym kontrahentem w
przypadku rejestracji i zmiany statusu wierzytelności.
10. Powiadamianie Osób Opiniujących o zbliżających się terminach wykonania zleconych zadań.
11. Powiadamianie Osób Merytorycznych o zbliżających się terminach zwrotów zabezpieczeń umowy.
12. Powiadomienie Osób Opiniujących w WK o podpisanej umowie opiniowanej w tym dziale z
informacją o konieczności zgłoszenia Kontrahenta do ZUS w terminie 7 dni.
13. Powiadomienie właściwych Osób Akceptujących i Akceptujących Rekomendację w zakresie danego
Dokumentu w DBiF i WK o Cofnięciu tego Dokumentu na etapie Kontrasygnaty/Akceptacji
dokumentu.
14. Powiadomienie Osoby Merytorycznej i Osób Opiniujących w DBiF o fakcie przekroczenia roku
ujętego w okresie realizacji umowy w stosunku do najwcześniejszego roku zdefiniowanego jako
parametr finansowy w metryce dokumentu.
15. Powiadomienie pracownika ZP przypisanego do podania z którego powstało zamówienie o zmianie
jego statusu na ZAMKNIETY, ZREALIZOWANY, PODPISANY, NIEPODPISANY,
BRAK_KONTRASYGNATY.
Strona 64/68
Załącznik nr 1 do umowy
Raporty
Lista raportów w systemie
Lp.
Nazwa
Opis
1.
Lista dokumentów
Lista przechowywanych w systemie dokumentów,
filtrowana ze względu na atrybuty obiektów
biznesowych.
2.
Liczba dekretacji
Lista pracowników danej komórki organizacyjnej z
liczbą dekretacji za wskazany okres i statusem
dekretowanego dokumentu
3.
Kary umowne
Lista kontrahentów z sumą kar umownych w
rozbiciu na poszczególne umowy
4.
Wierzytelności kontrahentów
Lista kontrahentów z kwotami wierzytelności,
uwzględniająca status wierzytelności
5.
Raport o kontrahentach Pzp
Raport o kontrahentach podlegających ustawie o Pzp
(art. 24 ust 1 pkt. 1 i 1a).
6.
Raport o wartościach umów dotacji
Raport dotyczący wartości umów
udzielonych na podst. art 4 pkt 7 Pzp.
7.
Raport z umów o dzieło
Raport z umów o dzieło, filtrowanych po atrybutach
obiektów biznesowych.
8.
Raport z umów zleceń
Raport z umów zleceń, filtrowanych po atrybutach
obiektów biznesowych.
9.
Raport ze szkoleń
Raport ze szkoleń, filtrowanych po atrybutach
obiektów biznesowych.
dotacji
Raporty będą implementowane za pomocą funkcjonalności Analyzing Services i Reporting Services
udostępnianej przez serwer MS SQL Server 2008.
Strona 65/68
Załącznik nr 1 do umowy
Model Domeny
class Model Domeny
OsobaOpiniuj aca
KomentarzDoDokumentu
tworzy
-
OsobaPraw na
ktoUtworzyl
tekstKomentarza
dataUtworzenia
-
wykonuje
Zadanie
-
KomentarzDoTekstuDokumentu
-
jednostkaLogicznaTekstu
komuZlecono
ktoZlecil
tekstZadania
terminWykonania
KRS
nazwa
REGON
OsobaFizyczna
-
imie
nazwisko
PESEL
«enumeration»
StatusWierzytelnosci
JednostkaNiePosiadaj ącaOsobow osciPraw nej
W_TOKU
ZREALIZOWANA
UMORZONA
zleca
KomorkaOrganizacyj na
OsobaDekretuj aca
JednostkaRedakcyj na
nazwa
skrot
Wierzytelnosc
nalezy do
Kontrahent
-
Osoba
obciaza
adres
NIP
IPU
-
imie
nazwisko
procesuje
-
kwota
skanPisma
status
sygnaturaPisma
wierzyciel
zajmujacy
KaraUmow na
-
kwota
procentWartosciUmowy
wplaca
dotyczy
pracuje
ZabezpieczenieNalezytegoWykonaniaUmow y
«abstract»
Umow a
«abstract»
Dokument
TekstDokumentu
Zalacznik
-
link
nrLDZ
opis
sciezkaDoPliku
-
«enumeration»
Status
KOPIA_ROBOCZA
NOWY
OPINIOWANY
ANULOWANY
ANULOWANY_ZP
ODRZUCONY_ZP
ODRZUCONY
KONTRASYGNOWANY
PODPISANY
ZAREJESTROWANY
REALIZOWANY
ZAMKNIETY
ZREALIZOWANY
DO_AKCEPTACJI
DO_ANULOWANIA
BRAK_KONTRASYGNATY
DO_OPINIOWANIA
DO_KONTRASYGNATY
DO_PODPISU
NIE_PODPISANA
DO_DEKRETACJI
SZABLON
ZAAKCEPTOWANY
-
dataZwrotu
kwota
Zamkniecie
czyWymaganaOpiniaDBiF
czyPodlegaIT
czyPowiazanyZeZP
czySzkoleniaPracownikow
czyUmowaZlecenieLubODzielo
dataUtworzenia
komorkaDodatkowa
status
tekstDokumentu
uwagi
zalaczniki
Zamow ienie
«enumeration»
TypUrlopu
MACIERZYNSKI
WYCHOWAWCZY
RODZICIELSKI
BEZPLATNY
-
czyDotacja47Pzp
czyDotyczyPrawMajatkowych
czyJestUczniemDo26RokuZycia
czyLaczyUrlopZPraca
czyNaPotrzebyWewnetrzne
czyPoboryWyzszeOdMinimalnego
czyProwadziPozarolniczaDzialalnosc
czyWnosiOUbezpChorobowe
czyWnosiOUbezpEmerytalne
czyWykonujeUmowyZlecenie
czyWymaganaKontrasygnata
czyWymaganeZabezpieczenie
czyZatrudnionyNaUmoweOPrace
dysponent
klasyfikacja
kwota
mozliwoscGospodarczegoWykorzystania
nrLDZ
nrPostepowaniaZP
nrUmowy
okresEkonomicznejUzytecznosci
osobaMerytoryczna
projekt
przedmiotUmowy
rodzajBudzetu
rodzajSrodkow
rok
typUrlopu
umowaDo
umowaOd
realizacjaUmowyNiePozniejNizData
realizacjaUmowyJednostkaCzasu
realizacjaUmowyLiczbaJednostekCzasu
czyRealizacjaWDniRobocze
wartoscPrawMajatkowych
wartoscUmowy
zadanie
zatrudnionyDoDnia
zrodloFinansowania
parametryFinansowe
«enumerati...
Rodzaj Budzetu
DOCHODY
WYDATKI
PRZYCHODY
ROZCHODY
Diagram: Model Domeny
Strona 66/68
zabezpiecza
Umow aWlasciw a
wypowiada
dotyczy
-
czyFirmaDoWykluczenia
czyKaryWyynikajaZOrzeczeniaSadu
czyNaliczacKary
czyZWinyWykonawcy
dataOrzeczenia
dataUprawomocnienia
dataZamknieciaUmowy
okreslenieSadu
podstawaPrawnaRozwiazania
przyczynaRozwiazania
skanDokumentu
skanOrzeczenia
sygnaturaAkt
tryb
wartoscNiezrealizowanegoZamowienia
Aneks/Proj ekt Aneksu
-
czyZmianaSposobuRozliczenia
czyZmianaTerminow
czyZmianaTerminowPlatnosci
czyZwiekszenieWynagrodzenia
inne
nrUmowyWlasciwej
Proj ektUmow y
-
nrIPU
«enumeration»
Rodzaj Srodkow
BIEZACE
NIEWYGASAJACE
«enumeration»
TrybZamkniecia
WYPOWIEDZENIE
ROZWIAZANIE
ODSTAPIENIE_OD_UMOWY
Załącznik nr 1 do umowy
Otoczenie IT - interfejsy zewnętrzne
Conv ersation Otoczenie IT - interfej sy zew nętrzne
CRU
SK
wywołanie WebService
ZP
udostępnij dane o
pracownikach
wyślij podanie
wyślij dane zgodnie z
modelem domenowym
wywołanie natywne
SDK
FK
pobierz kontrahenta
wyślij dane
zgodnie z
modelem
domenowym
wywołanie WebService
wywołanie WebService
Diagram: Otoczenie IT - interfejsy zewnętrzne
W toku analizy stwierdzono konieczność integracji z następującymi systemami:
 SK w celu pobierania danych o pracownikach i strukturze organizacyjnej UMWD (uwierzytelnianie,
autoryzacja, listy jednostek organizacyjnych),
 SDK w celu pobierania danych o istniejących Kontrahentach,
 FK w celu umożliwienia prognozowania na podstawie danych finansowych powiązanych z
Dokumentem,
 ZP w celu powiązania z dokumentami dotyczącymi zamówień publicznych.
Strona 67/68
Załącznik nr 1 do umowy
Macierz śledzenia
Traceability Matrix (Macierz śledzenia wymagań) wskazuje powiązania pomiędzy wymaganiami a
przypadkami użycia realizującymi wskazane wymagania. Pozwala na identyfikację oraz śledzenie
wymagań oraz wskazuje pokrycie określonych w procesie analizy wymagań przez przypadki użycia
określające zakres funkcjonalny rozwiązania.
Macierz śledzenia dla wymagań ma zastosowanie w weryfikacji, czy bieżące wymagania dotyczące
projektu zostaną spełnione, jest również pomocna przy tworzeniu zapytań ofertowych, czy innych
dokumentów potrzebnych w poszczególnych zadaniach projektowych.
Strona 68/68