Charakterystyka i wymagania Systemów

24.6. Wymaganie utrzymywania przez Wykonawcę, w trakcie całej Umowy, zewnętrznego środowiska testowego Systemów, przeznaczonego dla potrzeb realizowania bieżących przeglądów, w tym zwłaszcza przeglądów Prototypów 342

24.7. Wymagania dotyczące Komponentów Komunikacyjnych. 342

24.8. Wymaganie dot. dostosowania systemu SZPROT PLUS w zakresie działania usługi e- Decyzje w trakcie etapowej modernizacji Systemu 343

24.9. Zwalnianie infrastruktury po produkcyjnym wdrożeniu SZPROT PLUS i SEAP PLUS. 343

24.10. Wymagania dla kodu wynikowego w celu prowadzenia testów automatycznych 343

24.11. Strategia wdrażania Systemów SZPROT PLUS i SEAP PLUS 344

24.12. Aktualizacja modelu architektury w Enterprise Architect 345

24.13. Inwentaryzacja z natury systemów SZPROT i ECIP/SEAP oraz aktualizacja dokumentacji dla tych systemów 345

24.14. Zakres funkcjonalności, jakie Wykonawca jest zobowiązany przenieść z dotychczas działających systemów SZPROT i ECIP/SEAP do nowych Systemów SZPROT PLUS i SEAP PLUS. 345

24.15. Stosowanie przez Wykonawcę przepisów dot. ochrony danych osobowych. 345

24.16. Wymaganie dot. stosowania przez Wykonawcę rozwiązań gwarantujących elastyczną konfigurację parametrów i opcji Systemów (w tym x.xx. timerów, przełączników, opcji działania systemu / modułu / funkcji, właściwości aplikacji) z poziomu GUI oraz zapewnienia elastyczności w ramach obsługi procesów 346

24.17. Ogólne wymagania dot. integracji z systemem ARIADNA2. 346

24.18. Ogólne wymagania dot. integracji z systemem AES/WALIDATOR. 347

24.19. Ogólne wymagania dla podpisów i pieczęci elektronicznych oraz usług świadczonych przez system PKI 349

24.20. Ogólne wymagania dot. Komponentów Komunikacyjnych. 349

24.21. Ogólne wymagania dot. monitorowania. 350

1. Wstęp

Niniejszy dokument stanowi informację dotyczącą szczegółowego przedmiotu zamówienia związanego z zakupem usług i produktów informatycznych dla potrzeb modernizacji i rozbudowy oraz dalszego utrzymania i rozwoju Systemów SEAP PLUS i SZPROT PLUS, zwanych dalej Systemami, w celu zapewnienia ich integracji z pozostałymi komponentami modyfikowanymi lub wytwarzanymi w ramach Programu PUESC, a także w celu wdrożenia nowych usług biznesowych (e-Dokumenty, e- Decyzje) lub modyfikacji działania usług już istniejących, w tym przede wszystkim usługi e-Klient.

1.1. Cel i zakres dokumentu

Celem dokumentu jest dostarczenie informacji dotyczących przedmiotu zamówienia.

1.2. Skróty i definicje

Tabela ze skrótami i definicjami

Skróty i definicje	Opis
AEO	Authorized economic operator – upoważniony przedsiębiorca.
AES	Automatyczny System Eksportu (ang. Automated Export System) – system informatyczny dedykowany do obsługi zgłoszeń celnych oraz innych dokumentów związanych z wywozem towarów.
AIS	Automatyczny System Importu (ang. Automated Import System) – system informatyczny dedykowany do obsługi zgłoszeń celnych i innych dokumentów związanych z przywozem towarów oraz obsługi deklaracji statystycznych INTRASTAT.
Akceptacja	Odbiór jakościowy produktu – ocena dostawy pod względem merytorycznym przeprowadzona przez specjalistów z dziedziny, dla której wykonywany jest produkt. Stwierdzenie zgodności z kryteriami akceptacji produktu. Podpisanie Protokołu Akceptacji.
Akceptacja z uwagami	Ma miejsce, gdy dostarczony produkt nie spełnia wszystkich kryteriów jakości określonych przez Zamawiającego. Akceptacja z uwagami stanowi warunkowe przyjęcie produktu oraz zobowiązuje Wykonawcę do wykonania poprawek w ustalonym terminie. Termin dostawy uważa się za dotrzymany.
API	Interfejs programistyczny aplikacji (od ang. application programming interface) – sposób, rozumiany jako ściśle określony zestaw reguł i ich opisów, w jaki programy komputerowe komunikują się między sobą. Definiuje się go na poziomie kodu źródłowego dla składników oprogramowania, na przykład aplikacji, bibliotek, systemu operacyjnego. Zadaniem interfejsu programowania aplikacji jest dostarczenie odpowiednich specyfikacji podprogramów, struktur danych, klas obiektów i wymaganych protokołów komunikacyjnych.
ARC	Administrative Reference Code - Unikalny numer referencyjny e-AD

Skróty i definicje	Opis
	nadawany przez system EMCS.
ARIT	Skrót określający Techniczną Architekturę Referencyjną, określoną w Załączniku nr 4 do Umowy.
ARIADNA2	Hurtowania Danych KAS.
ARIADNA2 PLUS	Hurtowania Danych KAS rozwijana w ramach Programu PUESC.
Awaria	Błąd uniemożliwiający działanie systemu lub o dużej uciążliwości, spowodowany błędami w Platformie Programowej, wadliwym funkcjonowaniem oprogramowania systemowego, aplikacyjnego lub infrastruktury technicznej. Błąd powoduje niefunkcjonowanie całego Systemu, jednego z jego komponentów, brak możliwości pobierania/przekazywania danych lub uniemożliwia pracę użytkowników. Przejawem wystąpienia awarii może być w szczególności zawieszanie się aplikacji, samoczynne zamykanie się aplikacji niezgodne z dokumentacją, brak możliwości obsługi procesów biznesowych, wadliwy zapis danych, brak możliwości korzystania z danych zapisanych w bazach danych, niewłaściwy odczyt danych. Jako Awaria traktowane jest również obniżenie parametru wydajnościowego Systemu o więcej niż 50% w stosunku do poziomu określonego przez Zamawiającego w wymaganiach wydajnościowych, zdefiniowanych w niniejszym dokumencie – wymagania: SEAP_WP_081, SEAP_WP_082, SEAP_WP_083, SZPROT_WFOG_070, SZPROT_WP_080.
Baza CMDB	Configuration Management DataBase – baza danych do zarządzania konfiguracją.
Baza Wiedzy HelpDesk SISC	Jeden z modułów narzędzia klasy SD, który wykorzystywany jest przez operatorów Service Desk do rozwiązywania wpływających Incydentów. Zawiera zaakceptowane rozwiązania oraz obejścia powtarzających się Incydentów.
Błąd	Skategoryzowany Incydent lub Problem o określonym priorytecie, który ze względu na ograniczenia w poprawnym działaniu Systemu określany jest jako:  Awaria  Błąd Blokujący  Błąd Poważny  Błąd Średni  Błąd Drobny Błędy wynikające z niewłaściwego działania użytkownika po stronie Zamawiającego przy obsłudze Systemu przekazywane są do Wykonawcy z priorytetem o stopień niższym niż to wynika z dokonanej klasyfikacji.

Błąd Blokujący	Błąd o dużej uciążliwości ujawniony w obszarze zastosowań Platformy Programowej, oprogramowania systemowego, aplikacyjnego lub Infrastruktury technicznej, uniemożliwiający wykonanie co najmniej jednej funkcji Systemu. Błąd Blokujący powoduje powstawanie wyników o cechach niezgodnych z opisanymi w instrukcji użytkownika i specyfikacji funkcjonalnej. Zakłada się przy tym, że Błąd Blokujący można ponownie odtworzyć i występuje on w ostatnim niezmienionym wydaniu oprogramowania. Z zastrzeżeniem przypadku opisanego w definicji Awarii, jako Błąd Blokujący będzie także traktowany każdy inny problem z wydajnością Systemu. Przez problem wydajnościowy Systemu rozumie się stwierdzone przez okres dłuższy niż 2 h, odstępstwo od parametrów minimalnych albo maksymalnych związanych z wydajnością Systemu, zdefiniowanych w niniejszym dokumencie – wymagania: SEAP_WP_081, SEAP_WP_082, SEAP_WP_083, SZPROT_WFOG_070, SZPROT_WP_080.
Błąd Poważny	Błąd przejawiający się brakiem funkcjonalności lub użyteczności Platformy Programowej Systemu, wymuszający na użytkownikach / administratorach zastosowanie Obejścia. Powoduje to naruszenie wymagań stawianych dla Platformy Programowej i utrudnia wykonywanie operacji. Zakłada się przy tym, że błąd można ponownie odtworzyć.
Błąd Średni	Błąd ujawniony w obszarze zastosowań Platformy Programowej Systemu, który nie stanowi zagrożenia wykonania funkcji Systemu, ale utrudnia wykonanie w nim pojedynczych operacji bądź powoduje konieczność wykonania dodatkowych czynności w celu wykonania funkcjonalności programu, lub problem nieprawidłowego wyświetlania danych.
Błąd Drobny	Błąd ujawniony w obszarze zastosowań Platformy Programowej Systemu, który nie stanowi zagrożenia wykonania funkcji Systemu, ale je utrudnia lub wpływa negatywnie na komfort pracy użytkownika. Może być związany x.xx. z interfejsem użytkownika, kolejnością wykonania operacji, rozmiarem, kolorem ekranu i czcionki, a także obejmuje inne Błędy niepowodujące powstawania wyników o cechach niezgodnych z opisanymi w instrukcji użytkownika.
BOM	BOM (ang. byte order mark), znacznik kolejności bajtów – znak niedrukowalny, używany w wielobajtowym kodowaniu znaków, który jest zapisywany na początku strumienia bajtów (pliku) i informuje, w jakiej kolejności należy ustawić bajty, aby odczytać kod znaku. BOM rozwiązuje problem interpretacji kolejności bajtów w znaku i umożliwia automatyczną detekcję kodowania UTF-8, UTF-16LE, UTF-16BE, UTF-32LE oraz UTF- 32BE
cCPU	(ang. Core Central Processing Unit). Określa liczbę fizycznych rdzeni procesora.
CDMS	Customs Decisions Management System – komponent unijnego systemu Decyzje Celne odpowiedzialny za centralny (w UE) proces obsługi wniosków, umożliwienie konsultacji i zarządzanie procesem wydawania oraz monitorowania decyzji celnych (w zakresie określonym w przepisach UKC). W przypadku obsługi ww. decyzji celnych przez system krajowy

Skróty i definicje	Opis
	(tzw. rozwiązanie hybrydowe) komponent CDMS udostępnia usługi konsultacji oraz rejestrowania decyzji w centralnym repozytorium.
CDS	Wdrażany przez Komisję Europejską centralny system informatyczny umożliwiający wzajemną komunikację między, państwami członkowskimi i przedsiębiorcą w toku procesu wnioskowania, zmiany, cofnięcia, unieważnienia, zawieszenia i wydania decyzji. System składa się z trzech komponentów TP, CDMS i CRS.
Centrum Kompetencyjne (CK)	Komórka organizacyjna Resortu Finansów zarządzająca komponentami SISC w zakresie funkcjonalnym (merytorycznym) i technicznym (administracja Platformą Programową).
CEIDG	Centralna Ewidencja i Informacja o Działalności Gospodarczej.
Certyfikat celny	Certyfikat, o którym mowa w art. 10 b PC
CI RF	Centrum Informatyki Resortu Finansów jest państwową jednostką budżetową podległą ministrowi właściwemu do spraw budżetu, finansów publicznych i instytucji finansowych, ustanowioną Zarządzeniem Ministra Rozwoju i Finansów z dnia 27 września 2017 r. w sprawie zmiany nazwy Centrum Przetwarzania Danych Ministerstwa Finansów na Centrum Informatyki Resortu Finansów oraz nadania statutu Centrum Informatyki Resortu Finansów (Dz. Urz. Min. Roz. i Fin. z dnia 28 września 2017 r. poz 192). Centrum Zapewnia usługi centralnej infrastruktury teleinformatycznej dla resortu finansów. Siedzibą Centrum Informatyki Resortu Finansów jest Radom.
CRKiD	Centralne Repozytorium Komunikatów i Dokumentów – komponent Systemu ECIP/SEAP PL, w którym przechowywane są komunikaty, dokumenty oraz ich metadane.
CRL	Certificate Revocation List – lista unieważnionych certyfikatów.
CRPO	Centralny Rejestr Pełnomocnictw Ogólnych.
CRS	Customer Reference System/Services – komponent unijnego systemu Decyzje Celne odpowiedzialny za udostępnianie danych (poprzez usługi web-service) z centralnych rejestrów danych o podmiotach np. REX, CD dla x.xx. systemów operacyjnych.
Dzień kalendarzowy	Każdy dzień tygodnia, w tym także dzień ustawowo wolny od pracy.
Dzień roboczy	W rozumieniu niniejszej Umowy to dzień nie będący sobotą albo niedzielą lub innym dniem ustawowo wolnym od pracy.
e-AD	Elektroniczny dokument administracyjny, generowany i obsługiwany za pomocą systemu EMCS, na którego podstawie odbywa się przemieszczanie wyrobów akcyzowych z zastosowaniem procedury zawieszenia poboru akcyzy.

Skróty i definicje	Opis
eBT	Usługa e-Booking TRUCK umożliwiająca klientom KAS wykonującym międzynarodowy transport drogowy dokonywanie rezerwacji terminu granicznej obsługi wywozowej.
ECIP	Podsystem systemu ECIP/SEAP PL umożliwiający publikację treści na portalu BIP+.
ECIP/SEAP PL	System składający się z podsystemów ECIP – portal informacyjny i SEAP – podsystem komunikacyjny.
EDIT	Elementy dokumentacji technicznej Resortu Finansów, określone w załączniku nr 4 do Umowy.
e-Decyzje	Usługa umożliwiająca elektroniczną obsługę procesu wydawania decyzji na wniosek i z urzędu oraz zarządzanie decyzjami (cofnięcie, zawieszenie, zmiana, unieważnienie, ponowna ocena).
e-Dokumenty	Usługa umożliwiająca przekazywanie, zarządzanie oraz udostępnianie dokumentów elektronicznych w ramach SISC.
e-Klient	Usługa umożliwiająca rejestrację podmiotów, reprezentantów i reprezentacji celem uzyskania przez zarejestrowanych Klientów dostępu do usług elektronicznych świadczonych poprzez PUESC, pozwalająca na określenie zakresów uprawnień dostępu Użytkowników do określonych usług SISC.
EORI	Unijny System Rejestracji i Identyfikacji Podmiotów Gospodarczych, ang. Economic Operators’ Registration and Identification. Przedsiębiorcy podlegają jednokrotnej rejestracji w systemie EORI i jest im nadawany unikalny numer identyfikacyjny EORI.
e-Rejestracja	System rejestracji podatników zlokalizowany w Resorcie Finansów.
ETL	(ang. Extract, Transform and Load) – narzędzia wspomagające proces pozyskania danych dla baz danych, szczególnie dla hurtowni danych.
GUI	Graficzny interfejs użytkownika, środowisko graficzne (ang. graphical user interface, GUI) – ogólne określenie sposobu prezentacji informacji przez komputer oraz interakcji z użytkownikiem.
HARF	Projekt „Chmura Obliczeniowa Resortu Finansów”. Projekt odpowiedzialny za dostawę platformy sprzętowo-programowej na potrzeby komponentów SISC budowanych/rozbudowywanych w ramach Programu PUESC. Celem nadrzędnym projektu pn. „Chmura obliczeniowa resortu finansów” (HARF) jest stymulowanie wzrostu wykorzystania technologii ICT w Polsce poprzez zapewnienie w sposób ciągły infrastruktury teleinformatycznej oraz bezpiecznych i wydajnych usług transmisji danych na potrzeby działania obecnych i przyszłych aplikacji elektronicznej administracji świadczących usługi dla przedsiębiorców, obywateli oraz organów administracji publicznej szczebla rządowego i samorządowego,

Skróty i definicje	Opis
	a także innych podmiotów realizujących zadania publiczne. Celem głównym i istotą projektu HARF jest zapewnienie usług infrastrukturalnych w modelu prywatnej chmury obliczeniowej w zakresie infrastruktury, jako usługi (IaaS - Infrastructure as a Service); platformy, jako usługi (PaaS - Platform as a Service) oraz oprogramowania, jako usługi (SaaS - Software as a Service) dla: usług publicznych świadczonych drogą elektroniczną tzw. e-usług resortu finansów, w szczególności w ramach nowych projektów planowanych do realizacji w perspektywie 2014-2020:  „Rozwój katalogu usług cyfrowych dla klientów Administracji Podatkowej i Kontroli Skarbowej w zakresie centralizacji obsługi podatków CIT i VAT oraz obsługi Jednolitego Pliku Kontrolnego” (CVP),  „Platforma Usług Elektronicznych Skarbowo-Celnych” (PUESC), Cele projektu są zgodne z założeniami programowymi Programu Operacyjnego Polska Cyfrowa (PO PC). Zakres przedsięwzięcia wychodzi naprzeciw wyzwaniom stawianym przez ustawodawcę w obowiązujących aktach prawnych, jak i regulacjom planowanym do wprowadzenia. Podstawowym celem projektu pn. „Chmura obliczeniowa resortu finansów” (HARF) jest zapewnienie infrastruktury informatycznej (x.xx. serwery, pamięci masowe, backup danych) oraz sieci do transmisji danych, stanowiącej podstawę dla odpowiedniego poziomu bezpieczeństwa, elastyczności działania oraz wydajności aplikacji, a także budowa wydajnego środowiska transmisji danych dla rozwiązań aplikacyjnych świadczących elektroniczne usługi dla przedsiębiorców, obywateli, organów administracji publicznej szczebla centralnego i lokalnego oraz innych podmiotów realizujących zadania publiczne. Realizacja projektu umożliwi rozbudowę wspólnej platformy informatycznej dla realizacji e-usług administracji państwowej, co z kolei przyczyni się bezpośrednio do wzrostu wykorzystania technologii informacyjnych i komunikacyjnych w administracji publicznej, pozwoli zwiększyć efektywności prowadzonych przez nią działań, ułatwi zdolność prognozowania i planowania, a także obniży koszty realizacji zadań administracji publicznej.
HelpDesk SISC	Jednolita platforma udzielania informacji i pomocy w rozwiązywaniu problemów.
HERMES2	System zarządzania zasobami ludzkimi, wytworzony w ramach Programu e-Cło.
IAM	Dla UUM&DS - krajowy system zarządzana tożsamością i uprawnieniami.
IAS	Izba Administracji Skarbowej.
IBM Rational Functional	Oprogramowanie IBM służące do automatyzacji testów funkcjonalnych.

Skróty i definicje	Opis
Tester
IBM Rational Performance Tester	Oprogramowanie IBM służące do przeprowadzania testów wydajnościowych.
ID SEAP	Unikalny identyfikator nadawany Użytkownikom posiadającym konto na Portalu PUESC.
ID SISC	Unikalny, 17-znakowy numer identyfikacyjny nadawany Klientom podczas procesu rejestracji w SISC. Dla osób posiadających NIP jest to numer NIP, do którego zostało dodanych 5 ostatnich cyfr numeru REGON (łącznie 17 znaków). Dla osób posiadających EORI jest to numer EORI. Dla osób posiadających PESEL – jest to PESEL. Numery są uzupełnione cyframi „0” do rozmiaru 17 znaków.
Incydent	Każde zdarzenie, które nie jest częścią standardowego działania Systemu.
Infrastruktura techniczna	Infrastruktura techniczna Systemu SEAP PLUS oraz Systemu SZPROT PLUS składa się z Platformy Programowej, która zostanie dostarczona przez Wykonawcę oraz z Platformy Sprzętowo-Programowej udostępnionej przez Zamawiającego w ramach projektów PUESC.P1 oraz HARF na podstawie Projektu Infrastruktury Teleinformatycznej Systemu SEAP PLUS oraz Systemu SZPROT PLUS - przygotowanego przez Wykonawcę.
Integracja	Proces łączenia Modułów/Systemów w działające Systemy lub Usługi biznesowe. Integracja dwóch Komponentów określana jest mianem integracji point- to-point (bilateralna). Integracja określonego zbioru Komponentów w celu zapewnienia realizacji procesu tworzącego Usługę biznesową określana jest mianem integracji end-to-end.
Kod wynikowy Systemu	Kod otrzymany w wyniku Kompilacji Kodu źródłowego Systemu lub otrzymywany przy uruchomieniu Systemu.
Kod źródłowy Systemu	Zapis przy pomocy określonego języka programowania operacji, jakie powinna wykonać maszyna na zgromadzonych lub otrzymanych danych.
ISZTAR4	Informacyjny System Zintegrowanej Taryfy Celnej, wytworzony w ramach Programu e-Cło.
JRWA	Jednolity Rzeczowy Wykaz Akt, będący załącznikiem do zarządzenia Ministra Rozwoju i Finansów w sprawie wprowadzenia jednolitego rzeczowego wykazu akt izb administracji skarbowej, urzędów skarbowych i urzędów celno-skarbowych.
KAS	Krajowa Administracja Skarbowa.
KE	Komisja Europejska

Skróty i definicje	Opis
Klient	Osoba fizyczna, Podmiot lub Partner posiadający dostęp do usług elektronicznych świadczonych w ramach SISC za pośrednictwem Portalu PUESC.
Kompleksowa wersja Platformy Programowej	Wersja Platformy Programowej obejmująca wszystkie funkcjonalności Systemu wytworzone w ramach realizacji każdej z transz wymagań funkcjonalnych i technicznych określonych w Załączniku nr 3 od Umowy, a także każda inna dostawa Platformy Programowej obejmująca kompleksową realizację nowych lub modyfikację istniejących usług biznesowych lub Platforma Programowa dostarczana w następstwie kompleksowej przebudowy architektury technicznej Systemu. Każda dostawa Kompleksowej wersji Platformy Programowej skutkuje koniecznością przeprowadzenia przez Wykonawcę lub na żądanie Zamawiającego przez Zespół Realizacyjny w asyście Wykonawcy, pełnozakresowego wdrożenia, obejmującego zainstalowanie dostarczonego oprogramowania, optymalizację oprogramowania systemowego i narzędziowego oraz uruchomienie usług i zasilenie struktur danych, w tym także migrację danych z istniejących systemów oraz integrację z systemami współdziałającymi, zgodnie z wymaganiami określonymi w „Specyfikacji Wymagań dla Systemu”, a następnie przetestowanie wszystkich środowisk Systemu na docelowej infrastrukturze technicznej.
Komponent	Produkt wchodzący w skład SISC, realizujący określony zbiór funkcjonalności lub wspierający realizację usługi biznesowej, procesu biznesowego.
Komponent Komunikacyjny	Interfejs wizualny użytkownika zewnętrznego, służący do komunikacji w zakresie przesyłania komunikatów biznesowych oraz we wskazanych przez Zamawiającego przypadkach również do prezentacji informacji, osadzony na Portalu SEAP zbudowany w formie portletu. W uzasadnionych przypadkach i wyłącznie na podstawie decyzji Zamawiającego Komponent Komunikacyjny może zostać również zbudowany w formie formularza w narzędziu dostarczonym przez Wykonawcę w ramach Systemu SEAP PLUS, służącym do budowy i implementacji formularzy webowych / przeglądarkowych / internetowych.
Komponent Systemowy	Element składowy (komponent) zdefiniowanej poniżej Platformy programowej.
Komponent HARF	Element składowy (komponent) zdefiniowanej poniżej Platformy sprzętowo-programowej.
Konsultacje	Wnioski o informację dotyczące zagadnień związanych w szczególności z działaniem Systemu, jego konfiguracją, parametryzacją, funkcjami, itp., bezpośrednio nie wynikające z nieprawidłowego działania Systemu SEAP PLUS oraz Systemu SZPROT PLUS.
KRAG	System w ramach którego utrzymywany jest Rejestru Automatów do Gier.
KRS	Krajowy Rejestr Sądowy.
Kryteria akceptacji dla	Zbiór minimalnych wymagań jakościowych określonych dla Produktu,

Skróty i definicje	Opis
Produktu	które muszą być spełnione przy Odbiorze Jakościowym Produktu.
Kryteria jakości	Określone cechy lub ich zespoły występujące w strukturze danego produktu, lub grupy produktów, które pozwalają na jego ocenę jakościową.
Macierz uprawnień	Zestaw uprawnień przypisanych danej Osobie upoważnionej do korzystania z określonych usług SISC lub wykonywania określonych czynności w imieniu i/lub na rzecz Podmiotu.
Model uprawnień	Zestaw uprawnień przypisanych Użytkownikowi wewnętrznemu do wykonywania określonych czynności w Systemie.
Mechanizmy HA	Oprogramowanie realizujące funkcjonalności klastrów niezawodnościowych oraz wydajnościowych.
MCA	Magistrala Celno-Akcyzowa.
Model hybrydowy CDS	Model integracji systemu SZPROT PLUS z systemem unijnym CDS polegający na procesowaniu w systemie SZPROT PLUS spraw dotyczących pozwoleń obowiązujących w więcej niż w jednym kraju unijnym. Integracja polega na konieczności odbierania wniosków z TP i zapewnienia dalszej komunikacji z Podmiotem posiadającym konto na TP, konsultowaniu warunków/pozwoleń z administracjami innych krajów unijnych z wykorzystaniem modułu komunikacji w CDMS, przesyłaniu danych z wydanych pozwoleń z wykorzystaniem modułu komunikacji w CDMS do CRS.
Moduł	Część Systemu, wyodrębniona logicznie np.: ze względu na realizację określonych funkcji biznesowych.
Naprawa/Usunięcie Błędu	Trwałe usunięcie przyczyny powstania oraz skutku wystąpienia Błędu powodujące przywrócenie pełnej sprawności Systemu po jego wystąpieniu, w tym również zakończenie innych działań naprawczych np. aktualizacja dokumentacji, korekta uszkodzonych/niepoprawnych danych.
Narzędzie klasy SD (Service Desk)	System teleinformatyczny dostarczony w ramach projektu Help Desk, działający zgodnie z ITIL v.3.0, obsługujący procesy biznesowe: Help Desk, Zarządzanie Incydentem, Zarządzanie Problemem, Zarządzanie Usługami/wnioskami, Zarządzanie Bazą Wiedzy HelpDesk SISC. System jest dostępny dla użytkowników 24/7/365.
NCTS2	Nowy Skomputeryzowany System Tranzytowy, wytworzony w ramach Programu e-Cło.
NPP	Urzędowe Potwierdzenie Nieprzedłożenia.
Obejście	Zminimalizowanie uciążliwości Błędu Systemu i umożliwienie realizacji funkcjonalności w niestandardowy sposób bez usuwania przyczyny wystąpienia Błędu. Obejście nie stanowi Naprawy, jednak pozwala tymczasowo (do momentu usunięcia przyczyny Błędu) korzystać nieprzerwanie z wszystkich funkcjonalności Systemu.
Odbiór / Odbiór	Odbiór ostateczny produktu. Potwierdzenie przez osobę upoważnioną w

Skróty i definicje	Opis
formalny	Umowie, że Wykonawca spełnił wymagania stawiane przed nim w Umowie dla tego produktu. Odbiór zostaje potwierdzony poprzez podpisanie Protokołu Odbioru bez zastrzeżeń.
Odbiór jakościowy	Ocena dostawy pod względem merytorycznym przeprowadzona przez specjalistów z dziedziny, dla której wykonywany jest produkt. Odbiór merytoryczny (akceptacja) polega na zweryfikowaniu, czy produkt spełnia wymagania jakościowe oraz stwierdzeniu zgodności z kryteriami akceptacji produktu. Dokonanie odbioru jakościowego potwierdzane jest podpisaniem Protokołu Akceptacji.
Odbiór jakościowy z uwagami	Ma miejsce, gdy dostarczony produkt nie spełnia wszystkich Kryteriów jakości określonych przez Zamawiającego. Akceptacja z uwagami stanowi warunkowe przyjęcie produktu oraz zobowiązuje Wykonawcę do wykonania poprawek w ustalonym terminie. Termin dostawy uważa się za dotrzymany. Odbiór zostaje potwierdzony poprzez podpisanie Protokołu Akceptacji ze statusem Akceptacja z uwagami.
Oprogramowanie COTS	Oprogramowania typu Commercial of the Shelf Software - powszechnie dostępne oprogramowanie standardowe wytwarzane seryjnie, dostarczane w formie gotowego zamkniętego produktu, inne niż Oprogramowanie dedykowane albo FOSS.
Oprogramowanie dedykowane	Dostarczone przez Wykonawcę w wyniku realizacji Umowy oprogramowanie inne niż Oprogramowanie gotowe, również to, które zostało wytworzone w oparciu o narzędzia COTS albo FOSS.
Oprogramowanie gotowe	Oprogramowanie typu COTS oraz Oprogramowanie FOSS, inne niż Oprogramowanie dedykowane.
Oprogramowanie FOSS	Wolne i otwarte oprogramowanie (Free and Open-Source Software) - powszechnie dostępne oprogramowanie standardowe udostępniane wraz z kodem źródłowym, którego licencja umożliwia użycie w systemach komercyjnych bez ponoszenia opłat licencyjnych.
Partner	Instytucja, organ publiczny lub inna organizacja, z którą współpracuje KAS.
PESEL	Powszechny Elektroniczny System Ewidencji Ludności (PESEL).
PI	Platforma integracji MF, świadcząca usługi: WOU – weryfikacji uprawnień do składania deklaracji, weryfikacja kwoty przychodu PIT oraz obsługi kolejek (IBM Websphere).
PIUiD	Platforma Integracji Usług i Danych. Projekt informatyczny Ministra Cyfryzacji stanowiący realizację Planu Działań Ministra Cyfryzacji w zakresie Strategii Informatyzacji Państwa. Celem projektu jest udostępnienie danych z rejestrów państwowych poprzez wspólny punkt dostępu oraz wypracowanie jednolitego Modelu Informacyjnego Państwa.
PKI	Public Key Infrastructure - zbiór usług, polityk, procedur niezbędnych do świadczenia usług uwierzytelniania, szyfrowania, integralności i

Skróty i definicje	Opis
	niezaprzeczalności za pośrednictwem kryptografii klucza publicznego i prywatnego, certyfikatów elektronicznych.
Platforma ePUAP	ePUAP (elektroniczna Platforma Usług Administracji Publicznej) - ogólnopolska platforma teleinformatyczna służąca do komunikacji obywateli z jednostkami administracji publicznej w ujednolicony, standardowy sposób.
Platforma Programowa	Platforma zastana przez Wykonawcę w momencie przystąpienia do realizacji niniejszej Umowy, a także dostarczona przez Wykonawcę w ramach realizacji tejże Umowy, stanowiąca wspólnie z udostępnioną przez Zamawiającego w ramach projektów PUESC.P1 oraz HARF Platformą Sprzętowo-Programową dedykowaną dla Systemu SEAP PLUS oraz Systemu SZPROT PLUS Infrastrukturę techniczną, niezbędną do zbudowania, uruchomienia, przetestowania, wdrożenia i gwarantowania prawidłowego funkcjonowania wszystkich środowisk Systemu SEAP PLUS oraz SZPROT PLUS, w skład której wchodzą następujące elementy dostarczone wraz z licencjami przez Wykonawcę:  Oprogramowanie gotowe serwerów aplikacyjnych oraz Oprogramowanie gotowe baz danych określone w definicjach bloków architektonicznych wyspecyfikowanych przez Wykonawcę w Projekcie Infrastruktury Teleinformatycznej Systemu SEAP PLUS oraz Systemu SZPROT PLUS,  inne oprogramowanie (niezdefiniowane w blokach architektonicznych), wyspecyfikowane przez Wykonawcę w Projekcie Infrastruktury Teleinformatycznej Systemu SEAP PLUS oraz Systemu SZPROT PLUS, niezbędne do zbudowania, uruchomienia, przetestowania, wdrożenia i gwarantowania prawidłowego funkcjonowania wszystkich środowisk Systemu SEAP PLUS oraz Systemu SZPROT PLUS.
Platforma Sprzętowo- Programowa	Platforma Sprzętowo-Programowa udostępniona Wykonawcy przez Zamawiającego w ramach projektów PUESC.P1 oraz HARF zostanie zbudowana na podstawie Projektu Infrastruktury Teleinformatycznej Systemu SEAP PLUS oraz Systemu SZPROT PLUS oraz Technicznej architektury referencyjnej. Parametry, skala oraz specyfikacja dostarczanej przez Zamawiającego w ramach projektów PUESC.P1 oraz HARF Platformy Sprzętowo- Programowej dedykowanej dla Systemu SEAP PLUS i SZPROT PLUS będą zgodne z parametrami, skalą oraz specyfikacją wybranych i zwymiarowanych bloków architektonicznych, przez Wykonawcę w Projekcie Infrastruktury Teleinformatycznej Systemu SEAP PLUS i SZPROT PLUS. Zamawiający w ramach projektów PUESC.P1 oraz HARF udostępni Wykonawcy działającą Platformę Sprzętowo-Programową składającą się z:  Platformy serwerowej z systemami operacyjnymi;  Usług dostępowych;

Skróty i definicje	Opis
	 Systemów Infrastrukturalnych.
Podmiot	 osoba fizyczna, osoba prawna lub jednostka organizacyjna nie posiadająca osobowości prawnej, krajowa lub zagraniczna, dokonująca w swoim imieniu i na swoją rzecz operacji handlowych, lub  osoba prowadząca działalność polegającą na reprezentowaniu innych Podmiotów przed organami KAS, która jednocześnie będzie występowała jako Osoba upoważniona.
Portal PUESC	Platforma Usług Elektronicznych Skarbowo – Celnych, o której mowa w art. 10 a ustawy PC.
Portlet	Niezależny komponent, najczęściej stworzony w języku Java, przeznaczony do umieszczenia na stronie www. Portlet jest programem obsługującym określoną funkcjonalność na stronie, np. wypełnianie formularzy, wyświetlanie list, wypełnianie ankiet, wyszukiwanie wg kryteriów etc. Portlet jest umieszczony w kontenerze portletów, który agreguje zawartość prezentowanej strony. Celem zastosowania portletu jest stworzenie programu, który jest niezależny od kontenera, w ramach którego jest uruchamiany, co stwarza możliwość jego wielokrotnego użycia. Specyfikacja portletu jest opracowywana przez Java Community Process i nosi numery JSR-168 i JSR-286.
PZAS	Elektroniczne potwierdzenie zapłaty akcyzy od samochodu
Projekt Infrastruktury Teleinformatycznej (ITS)	Przygotowany przez Wykonawcę Projekt obejmujący wszystkie elementy Infrastruktury Technicznej Systemu SEAP PLUS i Systemu SZPROT PLUS.
Program e-Cło	Program, który miał za zadanie wytworzenie i wdrożenie zintegrowanego środowiska elektronicznego dla administracji celnej (SISC).
Program PUESC / PUESC	Platforma Usług Elektronicznych Skarbowo-Celnych (PUESC) Program realizowany w ramach POPC, planowany do objęcia współfinansowaniem ze środków UE, którego celem jest usprawnienie procesów realizowanych przez Klientów w zakresie eksportu, importu oraz obrotu wyrobami akcyzowymi i poszerzenie zakresu spraw, które będą oni mogli załatwić w drodze elektronicznej. Program jest realizowany w obszarze podatki i cła, którego celem jest usprawnienie procesów realizowanych przez klientów SISC (eksportu, importu oraz obrotu wyrobami akcyzowymi) i poszerzenie zakresu spraw, które będą oni mogli załatwić w drodze elektronicznej. Projekt realizuje cel szczegółowy 2 POPC dzięki wdrożeniu nowych usług elektronicznych takich jak:  automatyzacja czynności na granicy UE - celem jest usprawnienie obsługi i ograniczenie czynności jakie muszą być dokonane w związku z odprawą graniczną. Usługa ta przyczyni się także do poprawy obecnych funkcjonalności systemów transakcyjnych SISC,

Skróty i definicje	Opis
	 automatyczna obsługa procedur specjalnych – celem jest automatyzacja procesu obsługi od objęcia do rozliczenia procedury,  elektroniczna obsługa dokumentów załączanych do zgłoszeń celnych,  obsługa unijnej odprawy scentralizowanej,  automatyczne rozliczanie zabezpieczeń w ramach gwarancji ważnych w ramach UE,  usługa e-płatności,  usługa Awizacji,  e-banderole - elektroniczna obsługa procesu zarządzania znakami akcyzy,  e-przemieszczanie – elektroniczna obsługa towarów z zapłaconą akcyzą, wyrobów zwolnionych z akcyzy oraz alkoholu całkowicie skażonego,  zautomatyzowana usługa wymiany informacji i dokumentów pomiędzy uczestnikami łańcucha obrotu towarowego z krajami trzecimi - Platforma Single Window – pojedyncze okno w obrocie towarowym z krajami trzecimi. Usługi te w większości będą dostarczone na piątym poziomie dojrzałości. W ramach projektu zakłada się osiągnięcie poprawy cyfrowej efektywności Krajowej Administracji Skarbowej w zakresie zwiększenia liczby dokumentów elektronicznych obsługiwanych przez SISC.
Problem	Nieznana przyczyna jednego lub wielu Incydentów.
Produkt	Wszelkie rezultaty prac opracowane i dostarczone Zamawiającemu w ramach realizacji Umowy, stanowiące utwory w rozumieniu ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (t.j. Dz. U. z 2017 r. poz. 880 z późn. zm.), w szczególności programy komputerowe (wraz z kodami źródłowymi), Dokumentacja, a także wszelkie materiały i informacje, nie podlegające ochronie prawa autorskiego, opracowane i dostarczone Zamawiającemu w ramach realizacji Umowy
Prototyp	Prototyp modułu, wersja prototypowa modułu - wstępna wersja oprogramowania Platformy Programowej działającej z ograniczoną funkcjonalnością w zaakceptowanym przez Zamawiającego zakresie, umożliwiającym mu weryfikację realizacji wymagań funkcjonalnych i pozafunkcjonalnych określonego modułu. Prototyp modułu powinien obejmować większość funkcjonalności tak, aby można było potwierdzić przebiegi zamodelowanych procesów, model danych, realizowalność poszczególnych funkcjonalności oraz spełnienie celów biznesowych o których mowa w punkcie 2.2.
PUESC.P1	Projekt realizowany w ramach Programu PUESC, odpowiedzialny za zapewnienie spójności rozwiązań technicznych i współdziałania Komponentów SISC oraz konfigurację Platformy sprzętowo-programowej na potrzeby Komponentów SISC budowanych/rozbudowywanych w ramach Programu PUESC.
PUESC.P4	Projekt Programu PUESC „Cyfrowa granica / Cyfrowa obsługa celna”. Podprojektu/Zespoły:  PUESC.P4.1 – Obsługa zgłoszeń celnych i deklaracji

Skróty i definicje	Opis
	 PUESC.P4.2 – Single Window PLUS  PUESC.P4.3 – Rozliczanie Procedur Specjalnych  PUESC.P4.4 – Komunikacja, uprawniania i dokumenty.  PUESC.P4.5 – Obsługa na granicy  PUESC.P4.6 – Obsługa procesu TAX FREE  PUESC.P4.7 – Awizacja towarów i podróżnych
PUESC.P5	Projekt Programu PUESC „Cyfrowa obsługa podatkowa” odpowiedzialny za realizację zadań z zakresu:  Przemieszczania wyrobów akcyzowych  Wsparcia rejestracji samochodów osobowych  Rozliczania znaków akcyzy
PUESC.P6	Projekt Programu PUESC odpowiedzialny za realizację zadań z zakresu płatności elektronicznych
PUESC.P7	Projekt Programu PUESC odpowiedzialny za realizację zadań z zakresu Zarządzania ryzykiem (system ZISAR PLUS) i Hurtowni danych – ARIADNA2 PLUS
Rada Programu PUESC	Organ powołany Zarządzeniem Ministra finansów do nadzorowania realizacji Programu PUESC.
Rejestr Podmiotów	Ogół danych dot. podmiotów, reprezentantów, zakresów reprezentacji i pozwoleń, uzupełniany i modyfikowany na podstawie wniosków przetwarzanych w modułach Systemu SZPROT PLUS lub danych pozyskiwanych bezpośrednio z innych rejestrów krajowych lub unijnych (np. z systemu EOS), gromadzonych w Systemie PDR PL/UE i udostępnianych przez ten system pozostałym komponentom SISC oraz innym systemom informatycznym, które uzyskają dostęp do tego Rejestru.
Resort Finansów	Ministerstwo Finansów oraz wszystkie jednostki podległe, w tym między innymi: izby krajowej administracji skarbowej, urzędy celno-skarbowe, urzędy skarbowe, centra przetwarzania danych.
REX	Registered Exporter System – system centralny KE realizujący proces nadawania i utrzymywania w centralnym rejestrze numerów Zarejestrowanego Eksportera dla przedsiębiorców w państwach członkowskich UE, z krajów partnerskich (Szwajcaria, Norwegia) oraz dla eksporterów z krajów rozwijających się korzystających z Ogólnego Systemu Preferencji (GSP).
RPI	Zapasowy mechanizm kolejkowania komunikatów w stosunku do kolejek zrealizowanych na PI. RPI nie realizuje innych funkcjonalności PI.
RPS	System budowany w ramach Podprojektu PUESC.P4.3 – Rozliczanie Procedur Specjalnych. System umożliwi Użytkownikom złożenie elektronicznego rozliczenia zamknięcia procedury specjalnej oraz zapewni organowi celno-skarbowemu zarządzaniem takim rozliczeniem, ponadto zapewni monitorowanie procedur specjalnych.
SASIC	System zarządzania uprawnieniami Użytkowników wewnętrznych –

Skróty i definicje	Opis
	komponent systemu HERMES2.
SAN	Sieć SAN (ang. storage area network) – sieć pamięci masowej, rodzaj sieci służący do dostępu do zasobów pamięci masowej przez systemy komputerowe.
SEED UE	System for Exchange of Excise Data – system wymiany informacji dotyczących podatku akcyzowego. Zawiera wykaz podmiotów uprawnionych do produkcji, magazynowania, przyjmowania oraz dokonywania wysyłki wyrobów akcyzowych w procedurze zawieszonego poboru akcyzy.
SENT	System monitorowania drogowego przewozu towarów – realizujący usługę „e-Przewóz". Pozwala na obsługę operacji przewozu towarów w rejestrze zgłoszeń SENT. System ten umożliwia Klientom Krajowej Administracji Skarbowej, tj. podmiotom wysyłającym, podmiotom odbierającym, przewoźnikom i kierującym środkami transportu, realizację obowiązków określonych w Ustawie z dnia 9 marca 2017 r. o systemie monitorowania drogowego przewozu towarów (Dz. U. poz. 708 z późn. zm.), nakładającej na podmioty przewożące tzw. towary „wrażliwe" na i przez terytorium Rzeczypospolitej Polskiej obowiązek dokonania zgłoszenia takiego przewozu do elektronicznego rejestru oraz jego uzupełniania i aktualizacji.
SISC	System Informacyjny Skarbowo-Celny.
Skrypty automatyzujące	Skrypty testowe przygotowane i uruchamiane za pomocą Narzędzi testowych przeznaczonych do automatyzacji Testów.
System	Komponent wchodzący w skład SISC. Jeśli System zbudowany jest z Modułów, przez pojęcie System rozumiemy cały System jak i jego poszczególne Moduły oraz wszystkie interfejsy integracyjne. System obejmuje również dane przez niego przetwarzane, dokumentację z nim związaną oraz wszelkie powiązane instrukcje, procedury. Jeśli nie wskazano inaczej należy rozumieć jako System SEAP PLUS oraz System SZPROT PLUS.
System dziedzinowy	System informatyczny (np. SZPROT), który za pośrednictwem systemu SEAP obustronnie komunikuje się z Klientem za pomocą wysyłanych komunikatów (np. UPD, UPO).
System EOS	Economic Operators System - Wspólnotowy System Przedsiębiorców utrzymywany przez Komisję Europejską , w którym rejestrowani są przedsiębiorcy i nadawany jest numer EORI (EOS-EORI) oraz rejestrowane są wnioski i pozwolenia AEO, prowadzone konsultacje w toku wydawania pozwolenia AEO oraz rejestrowane informację dotyczące pozwolenia AEO (cofnięcia, zawieszenie, ponowna ocena) (EOS-AEO).
System PDR PL/UE	System Danych Referencyjnych SISC.
System PKI	System świadczący usługi PKI na potrzeby SISC, między innymi takie jak podpisywanie cyfrowe, szyfrowanie danych, weryfikacja podpisów

Skróty i definicje	Opis
	elektronicznych, wystawianie certyfikatów celnych.
System SEAP	Podsystem komunikacyjny Systemu ECIP/SEAP PL. Portal komunikacyjny, wyposażony w mechanizmy komunikacyjne integrujące w jednym miejscu dwustronną wymianę komunikatów i innych dokumentów pomiędzy Klientami i Systemami dziedzinowymi.
Systemy	Komponenty wchodzące w skład SISC. Jeśli nie wskazano inaczej należy rozumieć Systemy jako System SEAP PLUS oraz System SZPROT PLUS.
Systemy centralne KE	Zarządzane przez DG TAXUD systemy informatyczne współtworzone i użytkowane przez państwa członkowskie Unii Europejskiej np. EOS, CDS, UUM&DS.
Systemy Infrastrukturalne	Lista systemów infrastrukturalnych wspierających działanie Systemu:  System komunikacji LAN/WAN,  System komunikacji SAN,  Bramka internetowa,  System zabezpieczeń sieci,  System replikacji i zabezpieczenia danych,  System backupowy,  System wirtualizacji zasobów,  System zarządzania infrastrukturą serwerową i aplikacyjną,  System automatycznego wykrywania i zbierania informacji o elementach konfiguracji infrastruktury IT w Bazie CMDB.  System dystrybucji oprogramowania.  Centralny System Monitorowania (CSM)  System – Usługa odtworzenia po katastrofie.
System SZPROT	System Zintegrowanej Rejestracji Przedsiębiorców, wytworzony w ramach Programu e-Cło.
Środowisko produkcyjne Zamawiającego	Platforma Programowa oraz Platforma Sprzętowo-Programowa stanowiąca kompletny System przeznaczony dla użytkowników końcowych i wspomagania obsługi rzeczywistych procesów biznesowych.
Środowisko rozwojowe Zamawiającego	Odzwierciedla środowisko produkcyjne i służy do testowania procedur instalacji Systemu, procedur naprawy błędów i odbioru kodów źródłowych. Może służyć także do testów spełniania przez System wymagań pozafunkcjonalnych i funkcjonalnych oraz do celów szkoleniowych.
Środowisko testowe Wykonawcy	Środowisko Wykonawcy utworzone w celu testowania Systemu przez Wykonawcę przed przystąpieniem do testów w Środowisku testowym Zamawiającego. Powinno zawierać zaślepki do innych środowisk Systemów powiązanych, o ile takie powiązania występują.
Środowisko testowe Zamawiającego	Środowisko Zamawiającego utworzone w celu testowania Systemu. Odzwierciedla Środowisko produkcyjne i służy do przeprowadzania Testów na różnych poziomach (modułowych, systemowych, integracyjnych, usług) oraz do celów szkoleniowych.

Skróty i definicje	Opis
TAXUD	DG TAXUD — Dyrekcja Generalna ds. Podatków i Unii Celnej.
Techniczna architektura referencyjna (ARIT)	Techniczna architektura referencyjna systemów informatycznych Resortu Finansów przewiduje, że są one budowane z wykorzystaniem dedykowanych dla nich zestandaryzowanych elementów, nazywanych blokami architektonicznymi. Pozostałe usługi informatyczne, niezbędne do prawidłowego działania bloków architektonicznych oraz osadzonych w nich komponentów aplikacyjnych zapewniają współdzielone Systemy Infrastrukturalne. Techniczna architektura referencyjna obejmuje:  Architekturę referencyjną środowiska IT CI RF wraz załącznikami: - Załącznik A – Bloki architektoniczne środowiska teleinformatycznego - Załącznik B – Standardy parametrów oprogramowania infrastrukturalnego - Załącznik C – Standardy parametrów technicznych urządzeń teleinformatycznych - Załącznik D – Wsparcie dla klas bezpieczeństwa i systemów informatycznych - Załącznik E – Standardy proceduralne i dokumentacyjne  Specyfikację konfiguracji bloków architektonicznych.  Standard określania klasy bezpieczeństwa systemu informatycznego Resortu Finansów.  Standard określania klasy systemu informatycznego Resortu Finansów.
Testy	Zbiór działań realizowanych zgodnie z Planem testów.
Testy akceptacyjne/TA	Jedna z Grup testów. Testy wykonywane przez Zamawiającego w środowisku testowym Zamawiającego przy wsparciu Wykonawcy. Celem testów jest weryfikacja i formalne potwierdzenie zgodności testowanego Systemu z zawartą wcześniej Umową pomiędzy Zamawiającym a Wykonawcą.
Testy bezpieczeństwa	Jeden z Typów testów. Testy weryfikujące spełnienie wymagań w obszarze bezpieczeństwa Produktu. Obejmują x.xx.:  Testy penetracyjne;  Testy podatności na luki;  Testy DOS, DDOS;  Analiza kodu źródłowego;  Zabezpieczenie przed utratą danych;  Audyt bezpieczeństwa. W ramach testów bezpieczeństwa zaplanowano prowadzenie analizy dynamicznej podatności występujących w aplikacjach wytwarzanych w ramach Projektu. Analiza dynamiczna będzie prowadzona przez Zamawiającego z udziałem Xxxxxxxxx, z wykorzystaniem

Skróty i definicje

Opis

specjalistycznych narzędzi automatyzujących ten proces w x.xx. zakresie:

 aplikacji webowych: JSP, ASP, PHP

 systemów operacyjnych, systemów zarządzania bazami danych: MS SQL, Oracle, serwerów WWW: IIS, Apache.

W ramach testów bezpieczeństwa Wykonawca (wspólnie z Zamawiającym) za pomocą własnych udostępnionych narzędzi (dedykowanych do analizy bezpieczeństwa kodu) przeprowadzi analizę statyczną kodu i wyniki tej analizy przedstawi Zamawiającemu.

Testy funkcjonalne

Jeden z Typów testów.

Testy weryfikujące spełnienie wymagań funkcjonalnych Produktu. Obejmują x.xx.:

 Testy kompletności funkcjonalnej;

 Testy poprawności funkcjonalnej;

 Testy adekwatności funkcjonalnej.

Testy modułów

integracyjne

Jeden z Poziomów testów.

Testy wykonywane w Środowisku testowym Wykonawcy w celu wykrycia Błędów występujących podczas współpracy między powiązanymi Modułami Systemu.

Testy systemów

integracyjne

Jeden z Poziomów testów.

Testy wykonywane w Środowisku testowym Zamawiającego w celu wykrycia Błędów występujących podczas współpracy między Systemami powiązanymi.

Testy integracyjne usługi end-to-end wykonuje się po pozytywnej weryfikacji integracji point-to-point.

Testy utrzymania

łatwości

Jeden z Typów testów.

Testy weryfikujące spełnienie wymagań w obszarze łatwości utrzymania Produktu. Obejmują x.xx.:

 Testy kompilacji;

 Testy instalacji;

 Testy łatwości testowania;

 Testy procedur administracyjnych.

Testy międzynarodowe

Jedna z Grup testów.

Testy prowadzone między systemami SISC a powiązanymi systemami UE. Testowaniu podlega poprawność wymiany komunikatów UE/PL między tymi systemami. Testy realizuje Wykonawca przy udziale Zamawiającego zgodnie z wymaganiami unijnymi.

Testy modułowe

Jeden z Poziomów testów.

Testy wykonywane w celu wykrycia Błędów w pojedynczych Modułach Systemu. Testy obejmują całość określonego fragmentu

Skróty i definicje

Opis

Systemu/modułu, mają na celu sprawdzenie, czy system działa zgodnie z uzgodnioną specyfikacją wymagań dla poszczególnych modułów, upewnienie się, że każda funkcja umożliwia realizację wszystkich dopuszczalnych akcji i sytuacji lub uniemożliwia realizację każdej akcji i sytuacji zabronionej.

Testy niezawodności

Jeden z Typów testów.

Testy weryfikujące spełnienie wymagań w obszarze niezawodności Produktu. Obejmują x.xx.:

 Testy backupu;

 Testy odtworzenia systemu;

 Testy odtworzenia danych;

 Testy awarii infrastruktury;

 Testy procedur awaryjnych;

 Testy odporności na błędy.

Testy otwarte

Jedna z Grup testów.

Testy wykonywane ad hoc w dowolnym czasie, bez formalnego uzgodnienia Scenariuszy testowych i wcześniejszego ich zaplanowania. W czasie wykonania takiego testu jego przebieg należy dokumentować na formularzach Scenariusza testowego i Przypadku testowego.

Testy poinstalacyjne

Jedna z Grup testów.

Testy sprawdzające poprawność i kompletność instalacji i konfiguracji Systemu w środowisku oraz zgodności przebiegu procesu instalacji z instrukcją i dokumentacją. Jest to szczególny rodzaj testu dymnego.

Testy pozafunkcjonalne

Jeden z Typów testów.

Testy weryfikujące spełnienie wymagań pozafunkcjonalnych Produktu. Obejmują x.xx. następujące Typy testów:

 Testy wydajnościowe;

 Testy zgodności;

 Testy użyteczności;

 Testy niezawodności;

 Testy bezpieczeństwa;

 Testy przenaszalności;

 Testy łatwości utrzymania.

Testy przenaszalności

Jeden z Typów testów.

Testy weryfikujące spełnienie wymagań w obszarze przenaszalności Produktu.

Testy regresywne (regresji)

Jedna z Grup testów.

Testy wykonywane po wprowadzeniu zmian do Produktu i przeprowadzeniu Retestów, mające na celu sprawdzenie, czy nowo wprowadzone poprawki nie zakłóciły wcześniej poprawnie realizowanych funkcji Produktu.

Skróty i definicje

Opis

Testy systemowe

Jeden z Poziomów testów.

Testy komponentów oprogramowania (modułów), kodów źródłowych, wykonywane w Środowisku testowym Wykonawcy w trakcie produkcji Systemu także przy możliwym udziale Zamawiającego. Mogą być przeprowadzane w Środowisku testowym Zamawiającego. Celem testów jest sprawdzenie zgodności Systemu ze Specyfikacją wymagań. Wykonanie testów systemowych jest obowiązkowe przed dostawą oprogramowania w zakresie tworzenia Platformy programowej oraz dla nowej funkcjonalności w ramach Usługi Rozwoju.

Testy usług

Jeden z Poziomów testów.

Testy wykonywane w Środowisku testowym Zamawiającego sprawdzające poprawność działania usług biznesowych współrealizowanych przez System/komponent.

Testy utrzymania i rozwoju

Jeden z Poziomów testów.

Testy wykonywane w Środowisku testowym Zamawiającego sprawdzające poprawność funkcjonowania Produktu w trakcie jego produkcyjnej eksploatacji. Obejmują również testy realizowane po wprowadzeniu zmiany w Produkcie. Muszą zawierać x.xx. Testy regresywne.

Testy użyteczności

Jeden z Typów testów.

Testy weryfikujące spełnienie wymagań w obszarze użyteczności Produktu. Obejmują x.xx.:

 Testy ochrony przed błędami użytkownika;

 Testy zrozumiałości;

 Testy łatwości użycia;

 Testy łatwości nauki;

 Testy zgodności ze standardami zachowania GUI;

 Testy poprawności treści/tłumaczenia;

 Testy estetyki interfejsu użytkownika.

Testy wycofania

Jeden z Poziomów testów.

Testy sprawdzające procedurę wycofania Systemu lub wersji Systemu z użytkowania oraz skutki wywierane na Powiązane systemy.

Testy wydajnościowe

Jeden z Typów testów.

Testy weryfikujące spełnienie wymagań wydajnościowych Produktu. Obejmują x.xx.:

 Testy czasu odpowiedzi – zweryfikowanie, czy System spełnia wymagania czasu odpowiedzi (średniego, maksymalnego) przy określonym poziomie obciążenia;

 Testy wykorzystania zasobów – zweryfikowanie czy System wykorzystuje zasoby (RAM, CPU, Przestrzeń, Sieć, itd.) równomiernie, proporcjonalnie, racjonalnie, zgodnie z założeniami i wymaganiami;

 Testy pojemności – zweryfikowanie czy System pozwala na

Skróty i definicje

Opis

obsługę określonego wolumenu użytkowników i danych załadowanych do Systemu;

 Testy obciążeniowe - zweryfikowanie zachowania się Systemu w typowych warunkach, potwierdzając tym samym prawidłową, stabilną pracę Systemu, z wydajnością nie mniejszą od oczekiwanej, zdefiniowaną w dokumentacji technicznej;

 Testy przeciążeniowe - zweryfikowanie zachowania się Systemu w warunkach przeciążenia. Test zazwyczaj ma potwierdzić, że System zachowuje się stabilnie i nie doprowadza do utraty danych (niespójności bazy itp.) po przywróceniu jego poprawnego działania;

 Testy stabilności - kontrola stabilnej pracy Systemu przez określony czas, np. 24 godzin przy określonym obciążeniu.

Testy wymagań

Jeden z Poziomów testów.

Testy weryfikujące poprawność, kompletność i spójność wymagań, w szczególności testy sprawdzające poprawność dokumentacji dotyczącej ww. zakresu.

Testy zgodności

Jeden z Typów testów.

Testy weryfikujące spełnienie wymagań w obszarze zgodności Produktu. Obejmują x.xx.:

 Testy sprawdzające współdziałanie Platformy programowej z Platformą sprzętowo-programową;Testy zgodności z

konfiguracją stacji roboczych użytkownika.

Testy zgodnościowe

Jedna z Grup testów.

Testy prowadzone w celu potwierdzenia pełnej zgodności techniczno- funkcjonalnej integracji systemów/komponentów krajowych z transeuropejskimi systemami/komponentami dostarczanymi przez KE. W przypadku zakończonych sukcesem testów zgodnościowych obie strony, zarówno KE jak i administracje krajowe zyskują pewność, że uruchomienie systemu/komponentu krajowego nie spowoduje błędów w interakcji pomiędzy systemem/komponentem krajowym i unijnym a systemami/komponentami krajowymi innych państw członkowskich już uruchomionymi produkcyjne. Testy realizuje Wykonawca przy udziale Zamawiającego zgodnie z wymaganiami unijnymi

Trader Portal - unijny centralny portal przedsiębiorców umożliwiający komunikację organu celnego z przedsiębiorcą.

Typ testów

Klasyfikacja testów ze względu na obszary wymagań. Wyróżnia się:

 Testy funkcjonalne;

 Testy wydajnościowe;

 Testy zgodności;

 Testy użyteczności;

 Testy niezawodności;

 Testy bezpieczeństwa;

 Testy przenaszalności;

 Testy łatwości utrzymania.

Wszystkie powyższe Typy testów poza Testami funkcjonalnymi określa

Skróty i definicje	Opis
	się mianem Testów pozafunkcjonalnych.
UE	Unia Europejska.
Umowa	Umowa na realizację modernizację i rozbudowę Systemu SEAP PLUS i Systemu SZPROT PLUS.
UPD	Urzędowe Potwierdzenie Doręczenia.
UPO	Urzędowe Poświadczenie Odbioru.
UPP	Urzędowe Potwierdzenie Przedłożenia.
Usługa/Usługa biznesowa	Usługa postrzegana przez klienta jako odrębna całość, służąca wsparciu procesów biznesowych klienta, będąca zbiorem logicznie powiązanych funkcji realizowanych przez szereg zintegrowanych Komponentów SISC.
Usługa Rozwoju	Określono w treści Umowy.
Usługa Utrzymania	Określono w treści Umowy.
SIWZ	Specyfikacja Istotnych Warunków Zamówienia.
UUM&DS	Uniform User Management & Digital Signatures Project – system unijny zarządzający dostępem użytkowników zewnętrznych do usług centralnych świadczonych przez Komisję Europejską.
uwierzytelnianie	Proces polegający na zweryfikowaniu zadeklarowanej tożsamości osoby, urządzenia lub usługi biorącej udział w wymianie danych.
Użytkownik	Osoba fizyczna korzystająca z Portalu PUESC.
Użytkownik wewnętrzny	Funkcjonariusz celno-skarbowy, pracownik Krajowej Administracji Skarbowej, Ministerstwa Finansów, CI RF, zatrudniony w jednostkach Resortu finansów.
vCPU	(ang. Virtual Central Processing Unit). Procesor wirtualny – wirtualna centralna jednostka przetwarzania udostępniana maszynie wirtualnej przez warstwę wirtualizującą.
Walidator	Podsystem Systemu AES, przeznaczony do definiowania algorytmów walidacji oraz walidowania dokumentów elektronicznych.
WebService	Usługa sieciowa będąca składnikiem oprogramowania, niezależnym od platformy sprzętowej oraz implementacji, dostarczającym określone funkcjonalności. Zgodnie z zaleceniami World Wide Web Consortium (W3C) dane przekazywane są zazwyczaj za pomocą protokołu HTTP i z wykorzystaniem XML.
Wersja oprogramowania	Kolejne wydanie oprogramowania, dla którego nadano nowy identyfikator odnoszący się do wersji systemu ze względu na zakres zmian w wyniku których konieczna była instalacja zmodernizowanej wersji systemu w oprogramowaniu podlegających procedurze zarządzania konfiguracją.

Skróty i definicje	Opis
Węzeł krajowy	Krajowy Węzeł Identyfikacji Elektronicznej. Projekt Ministra Cyfryzacji mający na celu dostarczenie rozwiązań organizacyjno-technicznych, które zapewnią funkcjonowanie krajowego schematu identyfikacji elektronicznej oraz będą stanowiły punkt przyłączenia akredytowanych systemów identyfikacji elektronicznej (DT). Węzeł krajowy ma umożliwić uwierzytelnienie w celu realizacji usług online z wykorzystaniem środka identyfikacji elektronicznej wydanego w ramach akredytowanego systemu identyfikacji elektronicznej.
Wsparcie zewnętrzne	Wsparcie realizowane przez ekspertów dziedzinowych z jednostek niebędących stroną Umowy w celu wykonywania zadań lub rozwiązywania problemów wymagających wiedzy eksperckiej.
Wymagania Dotyczące Komponentu Komunikacyjnego	Opracowany przez Wykonawcę zestaw wymagań obejmujących między innymi opis standardu technicznego dla Komponentu Komunikacyjnego, sposobu jego implementacji i wizualizacji, podstawowego zestaw metod dostępnych w ramach usług pośredniczących (tzw. dedykowane API), procedury audytu, procedury testowania integracyjnego, wytycznych w zakresie user experience, responsywności.
Wykonawca	Wykonawca Systemu.
Wykonawca Systemu Dziedzinowego	Wykonawca innego (poza Podprojektem PUESC.P4.4) systemu w tym również realizowanego w ramach projektu/podprojektu PUESC, osadzający Komponent Komunikacyjny na Portalu PUESC
XML	(ang. Extensible Markup Language, w wolnym tłumaczeniu Rozszerzalny Język Znaczników) – uniwersalny język znaczników przeznaczony do reprezentowania różnych danych w strukturalizowany sposób.
Zamawiający	Zamawiający System.
Zarejestrowany Eksporter	Eksporter zarejestrowany w systemie REX.
ZEFIR2	Zintegrowany system poboru należności i rozrachunków z UE i budżetem ZEFIR 2. Wytworzony w ramach Programu e-Cło.
Zespół Realizacyjny	Patrz -> Zespół Zamawiającego.
Zespół Wykonawcy	Zespół składający się z osób powołanych do realizacji Systemu po stronie Wykonawcy.
Zespół Zamawiającego	Zespół składający się z osób powołanych do realizacji Systemu po stronie Zamawiającego.
Zewnętrzny dostawca Infrastrukturalny	Zewnętrzny dostawca – Podmiot wyłoniony w odrębnym postępowaniu przetargowym przez Zamawiającego w ramach projektu HARF, odpowiedzialny za dostarczenie Platformy Sprzętowo-Programowej dedykowanej dla Systemów.
Zintegrowane logowanie	Metoda uwierzytelniania, oparta na wcześniej poświadczonej tożsamości w systemie operacyjnym stacji roboczej, bez ponownego podania loginu i

Skróty i definicje	Opis
	hasła do Systemu.
ZISAR	Zintegrowany System Analizy Ryzyka.
ZPO	Zwrotne Potwierdzenie Odbioru.

Tabela ze skrótami, pełnymi nazwami i publikacjami aktów prawnych zawierających regulacje mające wpływ na sposób realizacji funkcjonalności Systemu.

Lp	Skrót	Tytuł	publikacja
1.	XXXX	Xxxxxx z dnia 29 sierpnia 1997 r. o ochronie danych osobowych	t.j. Dz. U. z 2016 r., poz. 922 z późn. zm.
2.	RPDO	Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych	Xx. X. x 0000 x., Xx 000, poz. 1024
3.	UIDP	Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności Podmiotów realizujących zadania publiczne	t.j. Dz. U. z 2017 r., poz. 570
4.	RKRI	Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych	t.j. Dz. U. z 2017 r., poz. 2247
5.	RSDE	Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie niezbędnych elementów struktury dokumentów elektronicznych	Dz. U. z 2006 r., Nr 206, poz. 1517
6.	UKC	Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 952/2013 z dnia 9 października 2013 r. ustanawiające Unijny Kodeks Celny	Dz. Urz. UE seria L z 2013r. Nr 269.1
7.	RW	Rozporządzenie Wykonawcze Komisji (UE) nr 2015/2447 z dnia 24 listopada 2015 r. ustanawiające szczegółowe zasady wykonania niektórych przepisów rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 952/2013 ustanawiającego unijny kodeks celny	Dz. Urz. UE seria L z 2015r. Nr 343/558
8.	PC	Xxxxxx z dnia 19 marca 2004 r. Prawo celne	t.j. Dz. U. z 2016 r., poz. 1880 z późn. zm.
9.	OP	Ustawa z dnia 29 sierpnia 1997 r. Ordynacja podatkowa	t.j Dz. U. z 2017 r., poz. 201 z późn. zm.
10	UOKAS	Ustawa z dnia 16 listopada 2016 r. – Przepisy wprowadzające ustawę o Krajowej Administracji Skarbowej	Dz. U. z 2016 r., poz. 1948 z późn. zm.
11	UOPA	Ustawa z dnia 6 grudnia 2008 r. o podatku akcyzowym	t.j. Dz. U. z 2017 r., poz. 43 z późn. zm.
12	XXXX	Xxxxxx z dnia 19 listopada 2009 r. o grach hazardowych	t.j. Dz. U. z 2016 r. poz. 471 z późn. zm.
13	ZSO	Zarządzenie Ministra Rozwoju i Finansów z dnia 1 marca 2017 r. w sprawie organizacji jednostek organizacyjnych Krajowej Administracji Skarbowej oraz nadania im statutów	Dz. Urz. MRiF poz. 41

ZIK

Zarządzenie Ministra Rozwoju i Finansów z dnia 28 lutego 2017 r. w sprawie wprowadzenia instrukcji kancelaryjnej izb administracji skarbowej, urzędów skarbowych i urzędów celno-skarbowych oraz instrukcji w sprawie organizacji i zakresu działania archiwum

zakładowego izb administracji skarbowej

Dz. Urz. MRiF poz. 43

JRWA

Zarządzenie Ministra Rozwoju i Finansów z dnia 28 lutego 2017 r. w sprawie wprowadzenia jednolitego rzeczowego wykazu akt w izbach administracji skarbowej, urzędach skarbowych i urzędach celno- skarbowych.

Dz. Urz. MRiF poz. 44

RODO

Rozporządzenie Parlamentu Europejskiego i Rady 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony danych osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych. Przepisy zaczną obowiązywać od 25 maja 2018 r.

Dz. Urz. UE seria L Nr 119

2. Założenia modernizacji, przebudowy i rozbudowy Systemów SEAP i SZPROT

W ramach realizowanego zamówienia planowane jest przeprowadzenie modernizacji, przebudowy oraz rozbudowy komponentów SISC odpowiedzialnych za realizację procesów komunikacji z Klientami oraz zarządzania uprawnieniami i dokumentami elektronicznymi (System SEAP), jak również obsługę wniosków związanych z rejestracją Podmiotów, reprezentantów, reprezentacji, wydawaniem pozwoleń, prowadzeniem postępowań (na wniosek i z urzędu) i wydawaniem decyzji (System SZPROT), mające doprowadzić do:

 zapewnienia integracji z pozostałymi komponentami SISC, w tym z wdrażanymi lub rozwijanymi w ramach Programu PUESC;

 zwiększenia wydajności, optymalizacji i poprawy ergonomii procesów komunikacji;

 zapewnienia wysokiego poziomu personalizacji udostępniania informacji i usług;

 przygotowania i wdrożenia wydajnych mechanizmów wymiany, udostępniania i składowania dokumentów elektronicznych w sposób zapewniający reużywalność informacji w nich zawartych;

 przebudowy, optymalizacji i rozbudowy mechanizmów związanych z działaniem usługi e-Klient, w tym implementacji obsługi procesu nadawania numerów Zarejestrowanego Eksportera;

 rozwoju mechanizmów odpowiedzialnych za integrację krajowych systemów zarządzania uprawnieniami i tożsamością z systemem UUM&DS, umożliwiających weryfikację uprawnień i tożsamości Klientów przy dostępie do usług centralnych dostarczanych przez UE;

 przeprowadzenia integracji z CDS;

 rozwoju i optymalizacji procesów biznesowych związanych z wydawaniem decyzji przy wykorzystaniu elektronicznego obiegu dokumentów.

Przedmiotowe zamówienie jest planowane do objęcia współfinansowaniem ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Polska Cyfrowa.

2.1. Główne powiązania z innymi Projektami PUESC / komponentami SISC

W ramach realizacji Umowy Wykonawca będzie zobowiązany do współpracy w obszarach i zakresie wskazanych poniżej w Tabeli.

Projekt/Projekty	Zakres współpracy
HARF	Współpraca w zakresie zapewnienia przez HARF dostawy infrastruktury technicznej, wymaganej przez Projekt PUESC.P4.4
PUESC.P1	„Spójność techniczna” - współpraca z tym projektem obejmie zagadnienia związane z wypracowywaniem rozwiązań w zakresie architektury technicznej, wykorzystaniem metod i narzędzi prowadzenia testów dostarczanych produktów, prowadzeniem wsparcia dla użytkowników wdrożonych usług biznesowych i komponentów systemowych, a także rozwiązywaniem zagadnień projektowych dotyczących kwestii architektury technicznej oraz zagadnienia związane z uzgadnianiem optymalnych rozwiązań w zakresie architektury biznesowej oraz architektury danych, rozwiązywaniem zagadnień projektowych dotyczących kwestii architektury biznesowej.
PUESC.P7	„Integracja danych z komponentów SISC (ARIADNA2 PLUS)” – współpraca z koordynatorem tego działania obejmie kwestie dotyczące integracji danych gromadzonych w ramach komponentów dostarczonych w ramach PUESC.P4.4 z hurtownią danych lub operacyjną składnicą danych analitycznych.
PUESC.P4 PUESC.P5 PUESC.P6 PUESC.P7	Uzgadnianie i definiowanie zasad korzystania z platformy komunikacyjnej SISC oraz mechanizmów odpowiedzialnych za przepływy informacji i dostęp do dokumentów elektronicznych gromadzonych w repozytorium CRKiD, a także dostępu do danych referencyjnych i mechanizmów zarządzania nimi. Projekt PUESC.DC.4.4 będzie definiował, we współpracy z zespołami odpowiedzialnymi za architekturę techniczną i biznesową, standardy w zakresie tworzenia przez poszczególne projekty zunifikowanych mechanizmów komunikacji z Klientami za pośrednictwem Portalu PUESC w oparciu o Portlety lub, w uzasadnionych przypadkach, inne mechanizmy i interfejsy możliwe do uruchomienia lub implementacji w ramach platformy komunikacyjnej.
Systemy SISC modyfikowane w ramach Projektu PUESC - AIS, AES, PKI, EMCS XX0, XXXXX0, XXXX0, NCTS2, HERMES2, ISZTAR4, MCA	Dostarczanie / uzgadnianie specyfikacji / interfejsów, prowadzenie testów, współpraca robocza.
Systemy działające w KAS poza Projektem PUESC: np. KRAG,	Dostarczanie / uzgadnianie specyfikacji / interfejsów, prowadzenie testów, współpraca robocza. Współpraca w zakresie wymiany danych.
Współpraca z zespołami odpowiedzialnymi za systemy unijne (EOS, REX, UUM&DS, CDS, SEED UE).	Dostarczanie / uzgadnianie specyfikacji / interfejsów, prowadzenie testów, współpraca robocza. Współpraca w zakresie wymiany danych.
Współpraca z zespołami odpowiedzialnymi za system CRPO, e- Rejestracja, CEIDG, PESEL, KRS.	Dostarczanie / uzgadnianie specyfikacji / interfejsów, prowadzenie testów, współpraca robocza. Współpraca w zakresie wymiany danych.

2.2. Podstawowe cele biznesowe przedsięwzięcia.

Podstawowymi celami biznesowymi przedsięwzięcia są:

 zwiększenie wydajności, poprawa ergonomii i optymalizacja mechanizmów komunikacji z Klientami, a także personalizacja przekazywanych informacji oraz udostępnianych usług;

 poprawa wydajności i optymalizacja mechanizmów wymiany danych dla potrzeb komunikacji z Klientami w ramach procesów obsługi klienta;

 zapewnienie Klientom dostępu do usług realizowanych za pośrednictwem TP z zachowaniem wymaganego poziomu kontroli dostępu oraz bez konieczności powtórnej rejestracji danych Klientów, poprzez rozwój integracji Systemu SEAP z UUM&DS;

 optymalizacja i rozszerzenie funkcjonalności platformy komunikacyjnej SISC, w ramach której świadczone są e-usługi oraz udostępniane informacje i przetwarzane dokumenty elektroniczne;

 zmniejszenie obciążeń i ograniczeń administracyjnych poprzez wdrożenie rozwiązań optymalizujących elektroniczne przetwarzanie dokumentów dotyczących obrotu gospodarczego;

 usprawnienie procesów obsługi wniosków w ramach usługi e-Klient oraz dostosowanie do zmian w zakresie EORI (komunikacja z EOS-EORI);

 wdrożenie rozwiązań optymalizujących elektroniczne przetwarzanie dokumentów dotyczących obrotu gospodarczego, mające na celu zmniejszenie obciążeń i ograniczeń administracyjnych;

 wdrożenie procesów obsługi decyzji wydawanych w trybie UKC, integracja z CDS oraz modernizacja i optymalizacja mechanizmów związanych z elektroniczną obsługą tego procesu, w tym także procesu obsługi cofnięcia lub unieważnienia numeru REX oraz zmiany w zakresie danych powiązanych z tym numerem.

2.3. Informacje o Systemach SEAP i SZPROT

2.3.1.System SEAP

System SEAP to portal komunikacyjny, wyposażony w mechanizmy komunikacyjne integrujące w jednym miejscu dwustronną wymianę komunikatów i innych dokumentów pomiędzy Klientami i Systemami dziedzinowymi. System SEAP integruje kanały komunikacyjne, takie jak Portal PUESC, Platforma ePUAP, e-mail oraz WebService.

System SEAP umożliwia zakładanie i usuwanie kont Użytkowników oraz bierze udział w procesie łączenia (oraz usuwania połączenia) konta z danymi Użytkownika zarejestrowanymi w SISC. Ponadto System SEAP stanowi wizualny komponent Portalu PUESC.

Usługi Systemu SEAP:

 umożliwienie założenia i zarządzania kontem Użytkownika (związane z tym nadanie unikatowego numeru ID SEAP) oraz udział w procesie powiązania konta z danymi zarejestrowanymi w SISC, a w przypadku dezaktywacji danych Użytkownika w SISC – udział w procesie usunięcia powiązania;

 prezentacja informacji o zarejestrowanych w SISC danych własnych Użytkownika, Podmiotów i reprezentacji;

 umożliwienie uprawnionym Użytkownikom dostępu do danych osób przez nie reprezentowanych

 obsługa dwustronnej komunikacji pomiędzy Systemami dziedzinowymi a Użytkownikami.

Funkcjonalności w tym obszarze obejmują:

o przekazywanie komunikatów w formacie XML w paczkach i pojedynczo przy wykorzystaniu interfejsu niewizualnego (WebService, e-mail),

o wypełnianie pojedynczych formularzy i załączanie do nich wymaganych dokumentów z wykorzystaniem interfejsu wizualnego (Portal PUESC, Platforma e-PUAP). Interfejs wizualny wypełniania formularzy może być wykorzystany także przez Użytkowników wewnętrznych.

Komunikaty poddawane są walidacji technicznej oraz, przy wykorzystaniu usług świadczonych przez System PKI, weryfikowany jest podpis elektroniczny;

 wystawienie UPP;

 realizacja doręczenia komunikatu z Systemu dziedzinowego do Klienta. Proces ten posiada następujące możliwe przebiegi:

o doręczenie zwykłe – dostarczenie komunikatu Klientowi poprzez umieszczenie go na koncie Klienta oraz (w przypadku, gdy System dziedzinowy tak wskaże) przekazanie na adres e-mail lub WebService,

o doręczenie za Urzędowym Potwierdzeniem Doręczenia (UPD). W niektórych przypadkach (decyduje o tym System dziedzinowy) konieczne jest dokonanie doręczenia kwalifikowanego, zrealizowanego za UPD. Przebieg procesu jest zdeterminowany wymogami prawnymi, określającymi niezbędne elementy dla procesu prawidłowego doręczenia dokumentu i może mieć on dwa przebiegi w zależności od sposobu zachowania się adresata.

 doręczenie faktyczne - adresat po otrzymaniu informacji mailowej o nadaniu do niego dokumentu za UPD i o czynnościach niezbędnych do wykonania w celu jego doręczenia, po zalogowaniu na PUESC dokonuje podpisania dokumentu UPD oraz jego odesłania. Podpisany dokument UPD jest przekazywany do systemu żądającego potwierdzenia odbioru. Adresatowi odsłaniany jest dokumentu na PUESC.

Jeśli adresat nie dokona w terminie siedmiu dni czynności podpisania i odesłania UPD na PUESC, wysyłana jest do niego ponownie informacja w formie mailowej.

 doręczenie zastępcze - jeśli adresat po upływie czternastu dni nie odeśle podpisanego UPD dokument uważa się za doręczony i informacja o tym jest przekazywana do systemu żądającego potwierdzenia. Dokument nie jest odsyłany adresatowi na PUESC, będzie widoczny tylko w przypadku zapytania o akta sprawy;

o doręczenie „w sprawach celnych” – ten tryb doręczenia polega na automatycznym odsyłaniu potwierdzenia odczytania dokumentu z powiadomieniem o długu celnym do Systemu dziedzinowego, którego dotyczy - bez konieczności wcześniejszego podpisania i odesłania dokumentu UPD, jak to ma miejsce w standardowym trybie doręczenia za UPD. Adresat otrzymując na Portalu PUESC dokument z powiadomieniem o długu celnym, dodatkowo informowany jest mailem o udostępnieniu dokumentu na koncie. W przypadku nie odczytania dokumentu w ciągu 7 dni, ponowna informacja nie jest wysyłana.

W momencie odczytania przez adresata dokumentu z powiadomieniem o długu celnym System SEAP odsyła potwierdzenie odczytania powiadomienia do właściwego Systemu dziedzinowego, uwzględniając wszystkie potrzebne informacje uzupełniające o dacie i czasie odczytania dokumentu;

 obsługa apletu (wystawionego przez System PKI) służącego do pobierania i użytkowania zaawansowanego podpisu elektronicznego weryfikowanego za pomocą certyfikatu celnego oraz umożliwiającego podpisywanie dokumentów kwalifikowanym podpisem elektronicznym i podpisem potwierdzonym profilem zaufanym ePUAP;

 uwierzytelnianie i autoryzacja systemu Klienta (interfejs niewizualny);

 publikacja formularzy xForms wygenerowanych w narzędziu ORBEON, z których generowane są pliki XML;

 obsługa danych dotyczących komunikatów w CRKiD przekazanych przez Systemy dziedzinowe. publikacja aktualnych danych słownikowych otrzymanych z Systemu PDR PL/UE oraz list CRL otrzymanych z Systemu PKI;

 dostęp do Zintegrowanej Taryfy Celnej udostępnionej przez ISZTAR4;

 udostępnienie zalogowanemu Użytkownikowi interfejsu Systemu HelpDesk SISC bez konieczności ponownej autoryzacji;

 dostęp Użytkownika za pomocą UUM&DS - proces umożliwia Użytkownikowi dostęp do usługi centralnej KE poprzez uwierzytelnienie i autoryzację w Systemie SEAP;

 dostęp Użytkownika wewnętrznego - podczas logowania Użytkowników wewnętrznych nazwa użytkownika i hasło są sprawdzane z danymi Active Directory MF przez protokół LDAP. Następnie po poprawnym logowaniu dane Użytkownika wewnętrznego są pobierane z komponentu autoryzacyjnego. Treści na Portalu PUESC są prezentowane Użytkownikowi wewnętrznemu w zależności od pełnionych przez niego ról.

System SEAP posiada mechanizm umożliwiający zarządzanie schematami komunikatów XML oraz ich publikację, a także narzędzie do budowania formularzy dla Systemów dziedzinowych SISC wraz z mechanizmem publikacyjnym.

2.3.1.1. System ECIP/SEAP PL– zarys architektury logicznej i technicznej

cmp Warstwy (DASI)

ECIP

SEAP

CRKiD

Fasada UUM&DS

Warstwa prezentacji

ECIP Intranet

ECIP Portal

SEAP Portal

SEAP Intranet

«COTS»

Saperion ECM Workflow Suite Ritch Client

«COTS»

Saperion ECM Workflow Suite Web Client

Formatka logowania fasady

Warstwa komunikacji

Usługi WebServ ice "publikacji automatycznej"

SEAP Portal WS: Usługi SEAP Intranet WS:

WebServ ice Usługi WebServ ice "Generycznego procesu "Generycznego procesu obsługi komunikatów" obsługi komunikatów"

Usługi WebServ ice API CRKiD

Klient WS "Dane do UUMDS"

SEAP Portal WS: WebServ ice "Systemu podmiotu"

SEAP Portal WS: WebServ ice "Dane do UUMDS"

Warstwa aplikacji

SEAP Portal SEAP Intranet

WS WS

«COTS»

ELK

«COTS»

Saperion ECM Workflow Suite Serv er

«COTS»

j BPM

«COTS»

Orbeon

Warstwa danych trwałych

«COTS»

Baza danych

«COTS»

Baza danych

«COTS»

Repozytorium plików

Warstwy Systemu ECIP/SEAP PL

Model projektowy zdekomponowano na warstwy od najniższej do najwyższej, mianowicie: warstwa danych trwałych, warstwa aplikacji, warstwa komunikacji, warstwa prezentacji.

Komponenty oprogramowania zdekomponowane wg struktury logicznej i funkcji, jaką mają pełnić. Pakiety oprogramowania zdekomponowano pod względem pakietów języka Java, które grupują funkcjonalności. Pakiety mają odzwierciedlenie w komponentach.

Wydzielono następujące warstwy:

1. Warstwa danych trwałych.

Niniejsza warstwa reprezentuje funkcje bazy danych i przechowywania danych trwałych, które nie mogą być utracone. W ramach tej warstwy wykorzystane zostały następujące standardy techniczne:

 SQL,

 .NET (w zakresie C# wykorzystywanego wewnątrz narzędzia MS SQL Server).

Za realizację trwałości dokumentów i załączników podczas przesyłania ich pomiędzy SISC a Podmiotami zewnętrznymi odpowiada:

 na etapie transmisji komunikatów

Platforma Integracyjna / RPI przez wykorzystanie kolejek trwałych;

 na etapie przetwarzania w procesie obsługi komunikatów Komponent BPM realizowany przez JBPM;

 na etapie składowania dokumentów

komponent CRKiD, realizowany przy pomocy oprogramowania SAPERION ECM Workflow Suite for Windows,

2. Warstwa aplikacji.

Niniejsza warstwa korzysta z warstwy danych trwałych. Tutaj znajdują się aplikacje (programy w języku Java EE oraz .NET) realizujące funkcje biznesowe projektu, a także narzędzia dokonujące renderowania formularzy XForms do postaci WWW.

3. Warstwa komunikacji.

Warstwa komunikacji odpowiada za przesyłanie danych w komunikacji obustronnej dla systemów zewnętrznych i również na potrzeby wewnętrzne między warstwą prezentacji a warstwą aplikacji. Warstwa komunikacji realizuje wymianę komunikatów pomiędzy systemami w modelu SOA, z wykorzystaniem usług WebService oraz silnika procesów biznesowych opartego o BPMN 2.0.

4. Warstwa prezentacji.

Reprezentuje warstwę odpowiedzialną za prezentację danych i interakcje z użytkownikiem systemu. Prezentacja odbywa się w postaci interfejsu graficznego, dostępnego przez WWW, z poziomu przeglądarek internetowych.

System ECIP/SEAP PL posiada następujące komponenty oprogramowania:

1. Komponent „ECIP Intranet WS”, którego kluczową funkcjonalnością jest automatyczna publikacja informacji z SISC.

Definicja interfejsów: komponent produkuje interfejs niewizualny wymiany informacji w zakresie przekazywania komunikatów XML zawierających informację do opublikowania.

2. Komponent „SEAP Portal”, który realizuje następujące kluczowe funkcjonalności:

 obsługa WWW Klientów;

 wyświetlanie i obsługa formularzy elektronicznych (obsługa od strony prezentacji);

 prezentacja spraw i dokumentów Użytkowników ;

 funkcje CMS (poprzez Liferay Portal);

 publikacja list CRL od Systemu PKI;

 publikacja publicznych słowników PDR PL/UE. Definicja interfejsów:

 komponent produkuje interfejs wizualny WWW Internet. Do tworzenia/wypełniania formularzy wykorzystano oprogramowanie Orbeon;

 komponent produkuje interfejs wymiany informacji z „SEAP Intranet WS” w zakresie przekazywania dokumentów XML pochodzących z wypełnionych formularzy elektronicznych;

 komponent udostępnia możliwość pobierania oraz prezentacji słowników Systemu PDR PL/UE na potrzeby formularzy tworzonych z wykorzystaniem oprogramowania Orbeon.

3. Komponent „SEAP Portal WS”, którego kluczową funkcjonalnością jest zapewnienie obsługi kanałów komunikacyjnych (dla odbiorców zewnętrznych). W zakresie Platformy ePUAP, e-mail i WebService, Portal PUESC:

 przekazywanie komunikatów z/do Klientów publicznej usługi WebService;

 przekazywanie komunikatów z/do Klientów publicznych skrytek ePUAP;

 przekazywanie komunikatów z/do klientów publicznych skrzynek email;

 przekazywanie komunikatów z/do Użytkowników wewnętrznych skrzynek email.

Definicja interfejsów:

 komponent produkuje interfejsy zewnętrzne: ePUAP, e-mail, WebService w zakresie przyjmowania komunikatów (w tym dokumentów jak i paczek dokumentów) oraz przekazywania informacji o ich statusie lub związanych z nimi spraw. Interfejsy te zostały wskazane na rysunku powyżej jako należące do „warstwy komunikacyjnej”;

 komponent produkuje interfejs wymiany informacji z pakietami komponentu z „SEAP Intranet WS” w zakresie przekazywania dokumentów z kanałów niewizualnych do dalszego przetwarzania jak i odsyłanie odpowiedzi/doręczeń do odbiorców w kanałach niewizualnych.

4. Komponent „SEAP Intranet” który realizuje następujące kluczowe funkcjonalności:

 obsługę Użytkowników wewnętrznych (funkcjonariuszy i administratorów technicznych/dziedzinowych);

 administrowanie funkcjami CMS Liferay Portal;

 zarządzanie schemami XML do wymiany komunikatów (w tym publikacja na „SEAP Portal”);

 tworzenie wzorów formularzy elektronicznych;

 publikacja formularzy elektronicznych do „SEAP Portal”;

 konfiguracja kanałów komunikacyjnych (ePUAP, email, WebService, Portal PUESC);

 dostęp do kreatora procesów biznesowych BPM i określanie parametrów procesów oraz zarządzanie procesami;

 dostęp do dedykowanych Portletów służących do monitorowania Systemu oraz pochodzących z COTS Liferay;

 zarządzanie dostępnością Systemów dziedzinowych.

Definicja interfejsów:

 komponent realizuje interfejs wizualny WWW Intranet w zakresie wymagań związanych z Użytkownikami wewnętrznymi, w tym z administratorami technicznymi, merytorycznymi i dziedzinowymi. Kluczowy zakres to tworzenie, edycja oraz publikacja formularzy, zarządzania schemami XML oraz konfiguracja reguł, którym podlega przetwarzanie komunikatów,

 komponent realizuje interfejs konfiguracyjny do „SEAP Portal WS” w zakresie konfiguracji kanałów niewizualnych i interfejsów do „SEAP Intranet WS” w zakresie konfiguracji przetwarzania dokumentów XML pochodzących z kanałów komunikacyjnych (Platforma ePUAP, email, WebService, Portal PUESC).

5. Komponent „SEAP Intranet WS” który realizuje następujące kluczowe funkcjonalności:

 zapisywanie danych trwałych do bazy danych (schema SEAP);

 przeprowadzanie wstępnej walidacji technicznej dokumentów przychodzących różnymi kanałami od „SEAP Portal” (wizualnie) i „SEAP Portal WS” (niewizualnie);

 przekazywanie komunikatów do CRKiD;

 przekazywanie komunikatów z/do SISC bezpośrednio lub za pośrednictwem kolejek PI / RPI;

 wyzwalanie procesów;

 wyzwalanie pozostałych procesów zrealizowanych w oparciu o inne składniki i komponenty oprogramowania (np. usługę SCP, implementację Portletów Liferay, implementację ServiceTasków w jBPM), niezbędnych do działania poszczególnych komponentów Systemu;

 odpytywanie Systemów dziedzinowych względem ich stanu operacyjnego, tj. czy są w stanie przyjmować i odsyłać dokumenty/komunikaty/zapytania poprawnie;

 udostępnianie mechanizmu do odpytywania Systemu PDR PL/UE umożliwiającego formularzom interaktywnym dynamiczne korzystanie ze słowników PDR PL/UE (REST-WS);

 pośredniczenie w przekazywaniu komunikatów od SISC do systemów klienckich;

 komunikacja z usługami na PI, np. na potrzeby ZEFIR2 (WOU), albo podpis kwotą podatku.

Definicja interfejsów:

 komponent jest zasilany z interfejsu pochodzącego od „SEAP Portal” i „SEAP Portal WS” oraz

„SEAP Intranet”;

 komponent realizuje interfejs wymiany informacji z oprogramowaniem jBPM (w zakresie uruchamiania, sprawdzania stanu procesów BPM).

Interfejsy te zostały wskazane na rysunku powyżej (Warstwy Systemu ECIP/SEAP PL) jako należące do „warstwy komunikacyjnej”.

6. Komponenty typu COTS

System ECIP/SEAP PL wykorzystuje następujące komponenty typu COTS:

 Microsoft SQL Server Enterprise.

W ramach tego komponentu zrealizowane są następujące komponenty logiczne:

o bazy danych Systemu SEAP („SEAP”, „PORTAL”);

o bazy danych repozytorium („Saperion”);

 SAPERION ECM Workflow Suite for Windows. który stanowi zestaw komponentów będących podstawą budowy CRKiD;

 JBPM, który jest podstawą budowy silnika procesów biznesowych, sterujących przesyłaniem komunikatów;

 Orbeon, który jest podstawowym komponentem do budowy oraz prezentacji formularzy Systemu SEAP;

 Drools Guvnor, będący narzędziem pozwalającym na konfigurację procesów biznesowych;

 Liferay Portal, oprogramowanie portalowe, CMS stanowiące bazę dla komponentów

„SEAP Portal”, „SEAP Intranet”;

 IBM WebSphere MQ oraz WebSphere MessageBroker. Jest to oprogramowanie dostarczone przez Zamawiającego wykorzystywane na potrzeby realizacji PI i pozwalające na realizację mechanizmów kolejek trwałych stanowiących integralną część Systemu SEAP;

 Apache Camel oraz Apache MQ. Jest to oprogramowanie wykorzystywane na potrzeby realizacji RPI, pozwalające na realizację zapasowego mechanizmu kolejek trwałych stanowiących integralną część Systemu SEAP;

 ELK:

o ElasticSearch - silnik wyszukiwania oparty na Apache Lucene, pozwalający przeszukiwać i analizować zgromadzone dane,

o Logstash - narzędzie zajmujące się zbieraniem logów ze wskazanych źródeł a następnie ich ustrukturyzowaniem do pożądanego formatu za pomocą dostępnych filtrów oraz wysłanie gotowych danych do ElasticSearch,

o Kibana - przyjazny dla użytkownika w pełni definiowalny interfejs pozywający przeglądać, przeszukiwać i wizualizować zgromadzone dane za pomocą wykresów.

Komponenty MS SQL Server, SAPERION ECM Workflow Suite for Windows, Orbeon, JBPM, Drools Guvnor, IBM WebSphere MQ, IBM WebSphere MessageBroker, Apache Camel, ApacheMQ, ElasticSearch, Logstash oraz Kibana są oprogramowaniem typu COTS. Producenci komponentów nie udostępniają informacji dotyczących wewnętrznej budowy oprogramowania, podjętych decyzji projektowych, stosowanych wzorców projektowych czy też diagramów klas i pakietów.

7. Komponent fasady UUM&DS

Zarządza dostępem użytkownika zewnętrznego do usług centralnych Komisji Europejskiej na podstawie tożsamości i uprawnień zarejestrowanych w SISC. Fasada jest elementem pośredniczącym w procesie dostępu do usług centralnych. Wywoływana jest za każdym razem gdy użytkownik zewnętrzny, na stronie „Where are you from” UUM&DS, wskaże Polskę jako krajowy system zarządzana tożsamością i uprawnieniami (IAM), w którym chce się uwierzytelnić. Fasada przechwytuje żądanie dostępu, identyfikuje domenę, w której użytkownik chce się uwierzytelnić i przekierowuje go do właściwego IAM. W komunikacji zwrotnej otrzymuje od IAM, potwierdzenie tożsamości i profil autoryzacyjny (w zakresie atrybutów autoryzacyjnych dla systemów centralnych) i przekazuje go do komponentu, który wywołał żądanie (C-PEPS). Komunikacja między C- PEPS a fasadą odbywa się za pomocą protokołu SAML a komunikacja między fasadą a krajowym IAM za pomocą usługi WebService. W chwili obecnej z fasadą integrowany jest jeden krajowy IAM (ECIP/SEAP PL)

Podstawowe funkcjonalności:

 Komponent dostarcza interfejsy zewnętrzne: wymiana danych z C-PEPS za pomocą SAML (w zakresie tożsamości i uprawnień) oraz używa interfejsu wystawianego przez Portal PUESC.

 Komponent dostarcza funkcjonalność automatycznego mapowania ról krajowych na centralne. Odpowiedź do C-PEPS musi zawierać atrybuty ról centralnych.

Na poniższym rysunku został przedstawiony diagram Komponentów, przedstawiający ogólną architekturę logiczną komponentów Systemu ECIP/SEAP PL.

cmp Architektura Logiczna

Baza danych (MS SQL Serv er)

ESZD

SEAP

LPORTAL

BPM

RPI

Saperion

Saperion ECM Ritch Client

Fasada UUM&DS

BPM (j BPM)

Użytkownik systemu KE

BIP+ / WP (Liferay)

Logowanie z systemu centralnego KE

Obsługa Obsługa wewnętrznych bufora (LIB) procesów kancelaryjnych

CRKiD

CRKiD Saperion ECM Web

Client

ECIP Portal

Dostęp do treści

Process Consola

Portal SEAP

Obsługa formularzy

Użytkownik Zewnętrzny ECIP

SEAP Portal

SEAP Intranet

Funkcjonariusz

Synchroniczne wysyłanie

komunikatów do/z silnika BPM

ECIP Intranet WS

Saperion ECM Serv er

Publikacja informacji

ECIP Intranet

Rejestry wpływów / wysyłek

Zarządzenie / publikacja treści

Wgląd w stan spraw / dokumentów

Moduł synchronizacji

Publikacja treści

SEAP Portal WS

SEAP Intranet WS

Synchronizacja RSS

Administrator / Redaktor ECIP

Administratorzy SEAP

Asynchroniczne wysyłanie komunikatów do silnika BPM

WS CRKiD

Serwer plików

Obsługa fomularzy, dostęp do treści, kanał email

Dwustronna komunikacja,

obsługa podpisu profilem zaufanym

Podpis profilem zaufanym

ELK

Weryfikacja podpisu kwotą

Asynchroniczne przychodu w PIT przesyłanie komunikatów

do / z SI S.C.

ECIP EU

e-Puap

Użytkownik Zewnętrzny SEAP

Dwustronna komunikacja (webservice, email)

ElasticSearch

Logstash

Warstwa Integracji

Kibana

Platforma Integracyjna (WebSphere)

Systemy Podmiotów Zewnętrznych

Redundantna Platforma Integracyjna

(Apache Activ eMQ / Apache Camel)

API CRKiD (Tworzenie i modyfikacja spraw / dokumentów)

Osadzanie informacji bezpośrednio na portalu ECIP

Integracje "Specyficzne" HERMES / AD

Asynchroniczne przesyłanie komunikatów

MS Exchange

Komunikacja z podmiotami zewnętrznymi, przedstawicielami tych podmiotów oraz użytkownikami

Synchroniczne przesyłanie komunikatów z pominięciem PI/RPI

SI S.C. podlegające integracji "generycznym procesem obsługi komunikatów"

SI S.C. podlegające integracji "specyficznej"

AIS

AES

Intrastat

HelpDesk

PKI

Integracje "specyficzne"

SZPROT

OSOZ 2

NCTS 2

SZPROT

AES/Walidator

ZEFIR 2

HERMES 2

EMCS PL 2

PDR

ISZTAR 4

Automatyczna publikacja informacji na portal ECIP

HERMES

Activ e Directory

Ogólna architektura logiczna komponentów Systemu ECIP/SEAP PL

8. Integracja z Systemami SENT i eBT.

Integracja SEAP - SENT

Platforma PUESC zapewnia użytkownikom dostęp do systemu SENT poprzez:

1) Generyczne mechanizmy systemu SEAP(formularze ORBERON, silnik procesów BPM, kanały komunikacyjne SEAP).

2) Osadzone na Portalu PUESC portlety do komunikacji synchronicznej.

3) Dedykowane kanały do komunikacji niewizualnej.

Aktualnie ze środowiska wewnętrznego SEAP korzysta ok. 3000 użytkowników systemu SENT.

SENT odbiera i wysyła maksymalnie 175 tys komunikatów na dobę. Średnio 140 tys, a w weekendy do 20 tys. Na te liczby składają się komunikaty zgłoszeń, aktualizacji, zakończeń i potwierdzenia dla tych komunikatów.

Integracja SEAP - eBT

Platforma PUESC zapewnia użytkownikom dostęp do systemu eBT poprzez:

1) Generyczne mechanizmy systemu SEAP( silnik procesów BPM, kanały komunikacyjne SEAP).

2) Osadzony na Portalu PUESC portlet do komunikacji synchronicznej.

2.3.2.System SZPROT

W początkowej fazie System SZPROT realizował funkcjonalności związane z nadawaniem i zarządzaniem numerami EORI. W ramach Programu e-Cło zakres działania Systemu SZPROT został poszerzony o funkcjonalności uprzednio realizowane przez lokalne podsystemy zapewniające rejestrację Podmiotów, Osób upoważnionych oraz uprawnień do korzystania z Systemów dziedzinowych, a także o rejestrację i obsługę wniosków składanych przez Klientów działających w obszarach obsługiwanych przez KAS i związanych z wydawaniem decyzji (zarówno na wniosek, jak i z urzędu) w sprawach dotyczących cła, akcyzy, gier hazardowych, VAT-u z tytułu importu, podatków innych i INTRASTAT. W Systemie SZPROT obsługiwane są procesy wszczynane na wniosek lub z urzędu, związane z:

 wydawaniem, zmianą i cofaniem decyzji, pozwoleń, zezwoleń i zaświadczeń (Usługa e- Decyzje),

 rejestracją, aktualizacją i dezaktywacją danych osób, Podmiotów i powiązań pomiędzy nimi, w tym zakresów reprezentacji,

 procesy tzw. „ad – hoc”, wykonywane w ramach alternatywnych przebiegów procesów głównych, takie jak: zawieszenie sprawy, podjęcie sprawy, umorzenie postępowania, wydanie rozstrzygnięcia innego niż merytoryczne załatwienie sprawy (z powodu np. braków formalnych wniosku).

Procesy w Systemie SZPROT przedstawione zostały w notacji BPMN.

Lista zaimplementowanych procesów w Systemie SZPROT
1.	Rejestracja aktualizacja, dezaktywacja danych Podmiotu (proces 3,4,5)
2.	Rejestracja aktualizacja, dezaktywacja danych osoby fizycznej (proces 6,7, 92)
3.	Rejestracja, aktualizacja, dezaktywacja danych reprezentacji (proces 93)
4.	Postępowanie w sprawie wniosku o uproszczone obliczanie wartości statystycznej w zgłoszeniach INTRASTAT (proces 9)
5.	Postępowanie w sprawie wniosku o udzielenie, zmianę lub cofnięcie upoważnienia do stosowania uproszczonego sposobu dokumentowania preferencyjnego pochodzenia; postępowanie prowadzone z urzędu w tym zakresie (proces 13)
6.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie pozwolenia na stosowanie zabezpieczenia generalnego; postępowania prowadzone z urzędu w tym zakresie (proces 14)
7.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie pozwolenia na odroczenie terminu płatności należności celnych; postępowania prowadzone z urzędu w tym zakresie (proces 15)
8.	Postępowanie w sprawie wniosku o udzielenie, zmianę lub cofnięcie upoważnienia dostosowania uproszczonej procedury wystawienia niepreferencyjnych świadectw pochodzenia; postępowanie prowadzone z urzędu w tym zakresie (proces 20)
9.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie pozwolenia na stosowanie gwarancji generalnej dla przewozów towarów w ramach wspólnej/wspólnotowej procedury tranzytu; postępowania prowadzone z urzędu w tym zakresie (proces 21)
10.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie pozwolenia na zwolnienia z gwarancji generalnej dla przewozów towarów w ramach wspólnej/wspólnotowej procedury tranzytu; postępowania prowadzone z urzędu w tym zakresie (proces 22)
11.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie pozwolenia na stosowanie przez upoważnionego wystawiającego dokumentów potwierdzających wspólnotowy status towarów; postępowania prowadzone z urzędu w tym zakresie (proces 38)
12.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie pozwolenia na korzystanie z procedury TIR (proces 40)

13.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie pozwolenia na utworzenie regularnej linii żeglugowej; postępowania prowadzone z urzędu w tym zakresie (proces 42)
14.	Postępowanie w sprawie wniosku o zastosowanie uproszczonego trybu udzielania świadectwa X.XX lub jego zmianę/cofnięcie, postępowanie prowadzone z urzędu w tym zakresie (proces 46)
15.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie decyzji na prowadzenie loterii fantowej lub gry bingo fantowe; postępowanie prowadzone z urzędu w tym zakresie (proces 50)
16.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie decyzji na prowadzenie loterii promocyjnej; postępowania prowadzone z urzędu w tym zakresie (proces 51)
17.	Postępowanie w sprawie wniosku zmianę regulaminu gry (losowej) hazardowej (proces 53)
18.	Postępowanie w sprawie zwrotu nadpłaty podatku od gier (proces 56)
19.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie zezwolenia na prowadzenie składu podatkowego; postępowania prowadzone z urzędu w tym zakresie (proces 64)
20.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie zezwolenia na nabywanie wyrobów akcyzowych jako zarejestrowany odbiorca; postępowania prowadzone z urzędu w tym zakresie (proces 65)
21.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie zezwolenia na jednorazowe nabycie wyrobów akcyzowych jako zarejestrowany odbiorca; postępowania prowadzone z urzędu w tym zakresie (proces 66)
22.	Postępowanie w sprawie wniosku o wydanie zezwolenia na prowadzenie działalności jako Podmiot pośredniczący (proces 67)
23.	Postępowanie w sprawie wniosku o zwrot akcyzy (proces 70)
24.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie zezwolenia na wysyłanie wyrobów akcyzowych jako zarejestrowany wysyłający; postępowania prowadzone z urzędu w tym zakresie (proces 71)
25.	Postępowanie w sprawie wniosku o udzielenie, zmianę i cofnięcie zezwolenia wyprowadzenia; postępowania prowadzone z urzędu w tym zakresie (proces 72)
26.	Postępowania podatkowe w sprawie nadpłaty podatku akcyzowego prowadzone na wniosek strony (proces 74)
27.	Postępowanie w sprawie wniosku o wpis, zmianę, skreślenie z listy agentów celnych (proces 76)
28.	Postępowania w sprawie udzielania ulg w spłacie zobowiązań (proces 86)
29.	Wniosek o sprostowanie oczywistej omyłki pisarskiej; postępowanie prowadzone z urzędu w tym zakresie (proces 100)
30.	Proces uniwersalny (proces 101)
31.	Rejestracja Podmiotu z urzędu
32.	Rejestracja osoby fizycznej z urzędu
33.	Procesy ad – hoc

Statusy spraw
1.	W toku
2.	Zamknięta
3.	Zawieszona
4.	Przerwana

Statusy dokumentów

Aktywny

Nieaktywny

System SZPROT odpowiada za prowadzenie następujących rejestrów:

1. Rejestr bazy Podmiotów,

2. Rejestr osób fizycznych,

3. Rejestr dokumentów,

4. Rejestr spraw,

5. Rejestry pozwoleń, zezwoleń,

6. Rejestr Miejsc wyznaczonych,

7. Rejestr wpisu na listę agentów celnych,

8. Rejestr zaświadczeń i oświadczeń,

9. Rejestr zgłoszeń urządzenia małej loterii fantowej ,

10. Rejestr zgłoszeń urządzania gry bingo fantowe,

11. Rejestr koncesji na prowadzenie kasyna gry,

12. Rejestr loterii pieniężnej,

13. Rejestr gry telebingo,

14. Rejestr gry liczbowej,

15. Rejestr zgłoszeń urządzania turnieju gry w pokera,

16. Rejestr zezwoleń na urządzanie salonu gry bingo pieniężne,

17. Rejestr zezwoleń na urządzanie zakładów wzajemnych,

18. Rejestr komunikatów SEED UE,

Z poziomu GUI dostęp do dokumentów odbywa się poprzez portfel użytkownika, w którym można wyświetlić sprawy w konfiguracji:

1. Moje zadania – z tego poziomu w widoku okna użytkownik ma dostęp do dokumentów przypisanych do niego do realizacji lub widocznych dla konkretnego uprawnienia (roli) w systemie;

2. Sprawy w toku – w tym widoku wyświetlane są wszystkie sprawy w statusie w toku znajdujące się w komórce;

3. Kalendarz zadań – to spis zadań, które ma zrealizować Użytkownik wewnętrzny, posortowany według wymaganej daty realizacji zadania;

4. Koszyk – umożliwia udostępnianie dokumentów (poza procesem) zdefiniowanej grupie osób;

5. Notatki – Użytkownik ma możliwość dodania i zapisania notatki, które nie są powiązane ze sprawą, ani też z zadaniem. Dodane do portfela notatki, mogą być trwale z niego usunięte w dowolnym czasie. Podczas tworzenia notatki możliwe jest zaznaczenie czy notatka jest prywatna, co oznacza że jest widoczna tylko dla osoby, która ją utworzyła.

2.3.2.1. System SZPROT – procesy w zakresie usługi e-Decyzje.

Poniżej zostały przedstawione skrótowo opisy przebiegów procesów związanych z prowadzeniem postępowań w Systemie SZPROT. Są to przebiegi podstawowe, z założeniem, że kolejne kroki są zakończone wynikiem pozytywnym.

Wszystkie przebiegi procesów posiadają ścieżki alternatywne, które przewidują różne sytuacje w prowadzonym postępowaniu i mogą doprowadzić do wydania różnych rozstrzygnięć na różnych etapach sprawy.

I. Sprawy wszczęte na wniosek.

 Wydanie rozstrzygnięcia w standardowym procesie obsługi sprawy (inne niż cło). Jest to obszar obsługi wniosków i decyzji w obszarze podatku VAT z tytułu importu, akcyzy, gier hazardowych, podatków oraz inne rozstrzygnięcia wydawane na podstawie przepisów OP.

o Wpływ wniosku z Systemu SEAP

1. otrzymanie zwalidowanego technicznie wniosku i przekazanie potwierdzenia do Systemu SEAP;

2. przydzielenie sprawy Użytkownikowi wewnętrznemu, nadanie numeru sprawy, wysłanie UPO z nadanym numerem sprawy;

3. sprawdzenie przez Użytkownika wewnętrznego wymogów formalnych wniosku, analiza merytoryczna (na tym etapie może być konieczność wielokrotnej komunikacji z Podmiotem, Osobą upoważnioną i/lub innymi uczestnikami postępowania i instytucjami, dodawanie protokołów, odpytanie innych Systemów dziedzinowych, wykonanie innej czynności);

4. wydanie rozstrzygnięcia (wraz z wysłaniem pism poprzedzających, zgodnie z wymogami prawa);

5. doręczenie rozstrzygnięcia z wykorzystaniem usług Systemu SEAP;

6. przekazanie danych z rozstrzygnięć do właściwych słowników PDR PL/UE;

7. publikacja decyzji w Systemach centralnych KE (np. SEED UE dla akcyzy).

Na właściwych etapach sprawy System SZPROT nadaje odpowiednie statusy sprawom oraz rozstrzygnięciom. Możliwe jest dodawanie dokumentów do spraw, również zakończonych, poprzez dekretację dokumentu do sprawy, gromadzenie dokumentów w zdefiniowanych teczkach spraw, przenoszenie dokumentów pomiędzy sprawami oraz linkowanie ich do innych spraw.

o Wpływ wniosku w postaci papierowej lub elektronicznego przesłanego na nośniku danych w formacie XML

Proces rozpoczyna się wprowadzeniem wniosku przez Użytkownika wewnętrznego do Systemu SZPROT. Następnie przebieg procesu jest analogiczny, jak w przypadku wpływu z Systemu SEAP. Zakończenie procesu zawiera dodatkowo element dokonania wysyłki pocztą tradycyjną i wprowadzenia daty doręczenia z otrzymanego ZPO, w przypadku braku zgody na korespondencję elektroniczną.

 Wydanie rozstrzygnięcia w standardowym procesie obsługi sprawy – obszar cła.

o Wpływ wniosku z Systemu SEAP. Przebieg procesu jest analogiczny do procesu obsługi wniosku dotyczącego innych obszarów. Proces jest dodatkowo rozszerzony o elementy związane z komunikacją z Systemami centralnymi KE (publikacja wniosku, procedura konsultacyjna, publikacja decyzji).

o Wpływ wniosku w postaci papierowej lub elektronicznego przesłanego na nośniku danych w formacie XML. Proces rozpoczyna się wprowadzeniem wniosku przez Użytkownika wewnętrznego do Systemu SZPROT. Następnie przebieg procesu jest analogiczny, jak w przypadku wpływu z Systemu SEAP. Zakończenie procesu zawiera dodatkowo element dokonania wysyłki pocztą tradycyjną i wprowadzenia daty doręczenia z otrzymanego ZPO, w przypadku braku zgody na korespondencję elektroniczną.

II. Sprawy wszczęte z urzędu.

 Obsługa sprawy w obszarze innym niż cło.

1. Zainicjowanie w Systemie SZPROT postępowania z urzędu, nadanie numeru sprawy i wysłanie postanowienia o wszczęciu postępowania za ZPO lub UPD (w zależności czy Podmiot wyraził zgodę na korespondencję elektroniczną, czy też nie);

2. po otrzymaniu podpisanego przez Podmiot ZPO lub UPD z datą odbioru postanowienia o wszczęciu postępowania kolejnym krokiem procesu jest analiza merytoryczna (na tym etapie może być konieczność wielokrotnej komunikacji z Podmiotem, Osobą upoważnioną i/lub innymi uczestnikami postępowania, instytucjami, dodawanie protokołów, odpytanie innych Systemów dziedzinowych);

3. wydanie rozstrzygnięcia (wraz z wysłaniem pism poprzedzających, zgodnie z wymogami prawa);

4. doręczenie rozstrzygnięcia z wykorzystaniem usług Systemu SEAP (i/lub pocztą tradycyjną);

5. przekazanie danych z rozstrzygnięć do właściwych systemów słowników PDR PL/UE;

6. publikacja decyzji w Systemach centralnych KE (np. SEED UE dla akcyzy).

Na właściwych etapach sprawy System SZPROT nadaje odpowiednie statusy sprawom oraz rozstrzygnięciom. Możliwe jest dodawanie dokumentów do spraw, również tych zakończonych, poprzez dekretację dokumentu do sprawy, gromadzenie dokumentów w

zdefiniowanych teczkach spraw, przenoszenie dokumentów pomiędzy sprawami oraz linkowanie ich do innych spraw.

 Obsługa sprawy w obszarze cła.

Przebieg procesu jest analogiczny do procesu dotyczącego załatwienia sprawy w innym obszarze. Różnica polega na tym, że po zainicjowaniu postępowania nie jest wydawane postanowienie o wszczęciu, a dla dalszego procedowania sprawy po wysłaniu informacji o wszczęciu przez organ postępowania z urzędu i przejście do kolejnego kroku nie jest uzależnione od otrzymania ZPO lub UPD potwierdzającego doręczenie tej informacji. Proces jest dodatkowo rozszerzony o elementy związane z komunikacją z Systemami centralnymi KE (publikacja danych z wniosku i decyzji).

W Systemie SZPROT zostały przewidziane role procesowe, do których zostały przypisane określone zadania. Jeden użytkownik może posiadać wiele ról.

skrót

nazwa

opis

REJ

Rejestrator

Użytkownik wewnętrzny dokonujący rejestracji wpływu wniosku/dokumentu kanałem innym niż za pośrednictwem Systemu SEAP (dokumentacja papierowa lub na nośniku danych). Zadaniem Użytkownika wewnętrznego w tej roli jest rejestrowanie korespondencji

przychodzącej i wysyłanie korespondencji wychodzącej

KKO

Kierownik Komórki Organizacyjnej

rola pozwala na wykonywanie zadań przypisanych w Systemie SZPROT do przełożonego na różnych szczeblach zarządzania. Użytkownik

wewnętrzny w tej roli uprawniony jest do zarządzania sprawami prowadzonymi w systemie i ich nadzoru

Prowadzący sprawę

podstawowa rola, którą posiada każdy Użytkownik wewnętrzny, prowadzący postępowanie. Użytkownik ten ma uprawnienia do

prowadzenia postępowania zgodnie ze ścieżkami procesu

brak

Akceptujący

rola biorąca udział w procesie na kroku Akceptacja dokumentu w prowadzonym postępowaniu

brak

Podpisujący

rola biorąca udział w procesie na kroku Podpisania dokumentu w prowadzonym postępowaniu

brak

Czytelnik, Audytor

Niektórym Użytkownikom wewnętrznym mogą zostać przydzielone dodatkowe role strukturalne takie jak np.: Czytelnik czy Audytor. Role te zapewniają dostęp do danych przechowywanych w Systemie SZPROT bez możliwości ich edycji. Osoby posiadające te role mogą przeglądać określone kategorie spraw w komórce, dla której mają przypisaną tę rolę. Tym samym osoby te mają dostęp do określonych danych wygenerowanych w danej komórce. Role te można mieć w jednej lub w kilku komórkach i nie są one powiązane z rzeczywistym zatrudnieniem w

danej komórce.

Wizualizacja przebiegu i opis przykładowego procesu realizowanego obecnie w Systemie SZPROT w zakresie usługi e-Decyzje.

Przebiegi pozostałych procesów, są zaprojektowane w sposób analogiczny. Na poniższym rysunku dokonano podziału zadań na role.

- zadania wykonywane przez Rejestratora,

- zadania wykonywane przez Kierownika Komórki,

- zadania wykonywane przez Prowadzącego sprawę,

- zadania wykonywane przez Akceptującego i Podpisującego,

- pozostałe niezaznaczone zadania, są wykonywane przez System SZPROT.

Momentem inicjującym przebieg procesu jest złożenie przez wnioskodawcę wniosku bądź zainicjowanie sprawy z urzędu przez KKO. Wnioski mogą być składane w postaci papierowej lub elektronicznej - poprzez Portal PUESC albo przekazane na nośniku danych w postaci elektronicznej, w formacie pliku XML.

Wnioski papierowe lub elektroniczne przekazane na nośniku danych są wprowadzane do Systemu SZPROT przez REJ, a następne przekazywane do KKO właściwej do rozpatrzenia danego typu wniosku. Wnioski przesłane z Systemu SEAP wpływają bezpośrednio do KKO właściwego do rozpatrzenia danego typu wniosku, do rejestru „Moje zadania”. KKO otrzymuje zadanie, którego celem jest przypisanie sprawy do odpowiedniej kategorii JRWA oraz wskazanie PS i przekazanie mu sprawy do załatwienia. Nowa sprawa przydzielona PS pojawia się w jego rejestrze „Moje zadania”. Rejestr taki mają wszyscy użytkownicy biorący udział w procesowaniu spraw.

Sprawa wszczęta z urzędu jest inicjowana przez KKO. Dla sprawy wszczętej z urzędu KKO również wskazuje właściwą kategorię JRWA i PS, któremu zostanie ona przydzielona do dalszego prowadzenia postępowania , a także stronę postępowania. PS w ramach prowadzonego postępowania ma do wykonania, odpowiednio do sprawy, szereg czynności.

Każdy z procesów realizowanych w Systemie SZPROT odzwierciedla klasyczną procedurę postępowania, której przebieg wynika z przepisów prawa.

W zależności od sposobu wszczęcia postępowania, różne są początkowe kroki w procesie.

W przypadku sprawy wszczętej na wniosek, w pierwszej kolejności przeprowadzana jest weryfikacja formalna wniosku. Kroki decyzyjne składają się z zestawu pytań, które pomagają dokonać weryfikacji wniosku. W zależności od uzyskanej odpowiedzi na pytanie, System SZPROT prowadzi Użytkownika wewnętrznego na właściwą ścieżkę postępowania. Przewidziane są następujące możliwości:

 przekazania wniosku do innego organu wg właściwości;

 wystosowania wezwania do Podmiotu lub Osoby upoważnionej;

 w przypadku, gdy wniosek nie spełnia wymogów formalnych lub np. w razie nieuzupełnienia podania - wydania rozstrzygnięcia formalnego i zakończenia w ten sposób sprawy;

 w przypadku, gdy wniosek spełnia wymogi formalne proces umożliwia przejście do analizy merytorycznej wniosku i wykonanie kolejnych kroków procesu właściwych dla danego typu sprawy.

W przypadku konieczności wszczęcia postępowania z urzędu, pierwszym zadaniem PS jest przygotowanie postanowienia o wszczęciu postępowania lub w przypadku sprawy z obszaru cła pisemnej informacji. Dokument po zaakceptowaniu i podpisaniu przez osobę/y uprawnione jest wysyłany do Osoby Upoważnionej i/lub Podmiotu. Po otrzymaniu potwierdzenia doręczenia postanowienia możliwe jest przejście do następnych kroków procesu, które są wspólne dla spraw prowadzonych na wniosek i wszczętych z urzędu. Dla sprawy z obszaru cła nie jest konieczne oczekiwanie na doręczenie pisma.

W ramach procesu wyodrębnione są następujące etapy:

 analiza merytoryczna, w ramach której PS ma możliwość wykonania szeregu czynności w celu podjęcia właściwej decyzji. Na tym kroku możliwe jest wielokrotne (i jednoczesne) wysyłanie pism/postanowień do różnych uczestników postępowania. Możliwe jest sporządzanie i dodawanie protokołów oraz komunikowanie się z innymi systemami poprzez pobieranie danych koniecznych do wydania rozstrzygnięcia a także wykonanie innej czynności;

 przed wydaniem decyzji kończącej postępowanie w przypadku, kiedy rozstrzygnięcie nie będzie zgodne z wnioskiem lub jeśli sprawa została zainicjowana z urzędu, możliwe jest wysłanie zawiadomienia informującego uczestników postępowania o zamiarze wydania rozstrzygnięcia. Po doręczeniu (faktycznym lub zastępczym) pisma i upływie czasu przewidzianego na ewentualną odpowiedź odbiorcy, możliwe jest przejście do kolejnego kroku procesu;

 przygotowanie rozstrzygnięcia. Na tym kroku PS wybiera rodzaj rozstrzygnięcia i przygotowany projekt przekazuje do akceptacji/podpisania przez upoważnionego Użytkownika wewnętrznego. Następnie rozstrzygnięcie jest wysyłane do uczestników postępowania. Proces zostaje zakończony po uzyskaniu informacji o doręczeniu (faktycznym lub zastępczym).

Akceptujący i Podpisujący, wskazani przez PS, dla każdej korespondencji z osobna, mogą w trakcie realizacji zadania podjąć jedną z trzech decyzji:

 zaakceptować lub podpisać dokument;

 odmówić jego akceptacji lub podpisania i skierować do PS do ponownego przygotowania;

 podjąć decyzję o rezygnacji z wydawania danego dokumentu lub powrocie do procesu głównego.

W zależności od decyzji, System SZPROT kieruje proces na odpowiedni krok. Należy zauważyć, że każdy dokument podlega tym samym regułom akceptacji, tj. projekt jest przekazywany od PS najpierw do wybranego przez niego Akceptującego, a następnie do Podpisującego.

Wszelkie dokumenty, które wpływają do Systemu SZPROT, a są związane ze sprawą, zostają w niej zapisane i stanowią akta tej sprawy. Każda czynność użytkownika w Systemie SZPROT jest

odkładana w historii, zaś każda czynność związana z zakończeniem określonego zadania (min. pozytywne zakończenie weryfikacji formalnej wniosku, przygotowanie pisma/postanowienia/rozstrzygnięcia, sporządzanie protokołu, akceptacja i podpis, przekazanie do wysyłki) zapisywana jest w metryce sprawy.

W trakcie prowadzonego postępowania, na każdym kroku procesu KKO może sprawę przekazać do dalszego prowadzenia przez innego Użytkownika wewnętrznego, poprzez zmianę PS . Może również delegować na inną osobę poszczególne zadania, a także w razie potrzeby zmienić Akceptującego i/lub Podpisującego.

W niektórych procesach istnieje możliwość tworzenia zespołów zadaniowych i przekazywania zadań pomiędzy poszczególnymi członkami tych zespołów.

Dodatkowo KKO w ramach prowadzonego postępowania (procesu), na każdym jego kroku może uruchomić podproces „ad hoc”. „Ad hoc” są to procesy dedykowane sytuacjom wyjątkowym, których uruchomienie umożliwia wykonanie dodatkowych działań bądź zakończenie procesu, bez konieczności przechodzenia całej ścieżki procesu.

KKO ponadto może dodać do sprawy dokument, który wpłynął w trakcie postępowania. Dokument taki w przypadku wpływu papierowego, bądź na nośniku danych w formacie XML, jest najpierw rejestrowany przez REJ i przekazywany do właściwego KKO. Jeżeli wpływ takiego dokumentu następuje w postaci elektronicznej (za pośrednictwem Systemu SEAP), wówczas jest on od razu przypisywany do sprawy. W każdym przypadku PS otrzymuje powiadomienie na skrzynkę e-mail o dołączeniu dokumentu do sprawy.

Poza tym jest możliwość wykorzystania jednego dokumentu w wielu sprawach. Jeśli jest taka potrzeba, wówczas uruchamiana jest funkcjonalność linkowania dokumentów.

Jeśli decyzja dotyczy wydania pozwolenia, zezwolenia lub upoważnienia, akceptujący lub podpisujący uruchamia przycisk do generowania numeru pozwolenia zezwolenia lub upoważnienia. Zostaje on wówczas zapisany tak jak i inne niezbędne dane na formularzu decyzji. Po podpisaniu rozstrzygnięcia odpowiednie dane z formularza decyzji zostają zapisane w oddzielnym rejestrze z pozwoleniami i jednocześnie przekazane do właściwych słowników PDR PL/UE.

W każdym wydanym rozstrzygnięciu istnieje możliwość dokonania sprostowania oczywistej omyłki pisarskiej, z wykorzystaniem dedykowanego do tego procesu. Po wydaniu takiego sprostowania jest ono dołączane do akt sprawy prostowanego rozstrzygnięcia. Jeśli sprostowaniu podlegało rozstrzygnięcie będące pozwoleniem lub zezwoleniem w procesie tym istnieje możliwość sprostowania danych w rejestrze, w którym zapisane jest pozwolenie, zezwolenie i tym samym aktualizacja tych danych w słownikach PDR PL/UE.

Rejestr dodawania pozwoleń i zaświadczeń/oświadczeń do bazy podmiotów.

Oprócz procesu wniosków, które kończą się w Systemie SZPROT wydaniem pozwolenia, z którego dane przekazywane zostają do odpowiednich słowników umiejscowionych w Systemie PDR PL/UE, w Systemie SZPROT funkcjonują rejestry. Jednym z tych rejestrów jest rejestr podmiotów, do którego wpisywane są dane z pozwoleń wydanych poza Systemem SZPROT. Dane te również zasilają słowniki Systemu PDR PL/UE. Możliwość wpisu tych danych dostępna jest dla Użytkownika wewnętrznego w roli użytkownika tymczasowego. . Po wybraniu podmiotu, do którego należy dopisać dane użytkownik tymczasowy uruchamia przycisk „dodaj rozstrzygnięcie”, wówczas otwiera się okno z wyborem typu rozstrzygnięcia. W oknie wyboru są dostępne następujące typy rozstrzygnięć:

- AEO,

- decyzje na lokalizacje,

- pozwolenia na procedurę gospodarczą/ szczególnego przeznaczenia,

- pozwolenia na procedurę uproszczoną,

- zaświadczenia.

Po wybraniu określonego typu rozstrzygnięcia, użytkownik tymczasowy na formularzu rejestru uzupełnia dane. Wszystkie pola na formularzu, które są obligatoryjne do uzupełnienia są zaznaczone na czerwono. Formularze są interaktywne, bowiem w przypadku wybrania określonej wartości w polu z listą rozwijalną, zmieniają się widoczności innych pól lub ich aktywności Po uzupełnieniu danych na formularzu wybranie przycisku „zapisz” powoduje, że dane zostają zapisane w rejestrze i jednocześnie przekazane do dedykowanego słownika PDR PL/UE. Raz zapisane w rejestrze dane można modyfikować. Do rejestru CR03 zapisywane są również dane wprowadzane z poziomu procesu uniwersalnego. Dane te jednak dotyczą tylko zaświadczeń i oświadczeń przedkładanych przez podmiot w celu spełnienia wymogów przewidzianych dla uproszczonego trybu rozliczania podatku od towarów i usług. Po zarejestrowaniu sprawy w tym procesie i wybraniu w trakcie procesu przez prowadzącego sprawę opcji dodaj zaświadczenie/oświadczenie, otwiera się taki sam formularz jak w rejestrze CR03 Podobnie jak w rejestrze należy uzupełnić formularz poprzez wpisanie w niego odpowiednich danych i wybranie przycisku „zapisz”. Powoduje to, że dane trafiają zarówno do rejestru jak i słownika PDR PL/UE.

2.3.2.2. System SZPROT – procesy e-Klient.

Realizacja usługi e-Klient wymaga ścisłej integracji Systemów dziedzinowych zaangażowanych w działanie usługi z uwagi na konieczność realizacji określonych etapów procesu przez różne systemy.

 System SEAP

o założenie konta przez Użytkownika (osobę fizyczną);

o wypełnienie wniosków elektronicznych o:

 rejestrację danych osoby fizycznej,

 aktualizację danych osoby fizycznej,

 dezaktywację danych osoby fizycznej,

 rejestrację danych Podmiotu,

 aktualizację danych Podmiotu,

 dezaktywację danych Podmiotu,

 rejestrację/aktualizację/dezaktywację danych dotyczących reprezentacji;

o podpisanie i wysłanie wniosków elektronicznych (Usługa współdzielona z Systemem PKI);

o odbiór komunikatów z SISC i ich prezentacja na koncie Użytkownika;

o obsługa formularza umożliwiającego dodawanie załączników do sprawy.

 System SZPROT

o obsługa wniosków składanych w ramach usługi e-Klient;

o komunikacja z Systemem EOS związana z nadawaniem numeru EORI;

o komunikacja z Systemem EOS związana z aktualizacją danych Podmiotów, którym został nadany numer EORI w Polsce;

o komunikacja z Systemem EOS związana z pobieraniem danych Podmiotów (za pośrednictwem MCA), którym został nadany numer EORI w innym Państwie Członkowskim UE (poza Polską);

o komunikacja z Systemem EOS związana z konsultacją danych Podmiotów w ramach wzajemnego uznawania statusu AEO (za pośrednictwem MCA), polegająca na pobieraniu danych Podmiotów, którym został nadany numer AEO w Kraju Trzecim (EORI a-like);

o zasilanie zarejestrowanymi danymi Systemu PDR PL/UE;

o podpisanie dokumentu wysyłanego do Klienta certyfikatem celnym z wykorzystaniem apletu PKI.

 System PDR PL/UE

o udostępnianie zarejestrowanych danych Systemowi SEAP;

o udostępnianie danych słowników używanych przy wypełnianiu wniosków

o propagacja zapytania do Systemu SZPROT związana z pobieraniem zagranicznych numerów EORI i EORI a-like z EOS.

o Udostępnianie danych Systemom dziedzinowym.

Opis usługi realizowanej w Systemie SZPROT.

System SZPROT w zakresie e-Klient został wdrożony 29 czerwca 2015 r. Dane Podmiotów i Osób upoważnionych zostały zmigrowane do Systemu SZPROT z kilku systemów źródłowych takich jak: EORI PL, PDR_ECS, PDR_NCTS, ZEFIR, które po migracji danych zostały wygaszone w zakresie funkcjonalności realizujących rejestrację danych Osób upoważnionych i Podmiotów.

Obecnie podstawowym sposobem rejestracji danych jest obsługa wniosków wpływających z Systemu SEAP. Wnioski elektroniczne zostały udostępnione na Portalu PUESC, z możliwością ich elektronicznego przesłania po wypełnieniu na Portalu PUESC. Ponadto istnieje możliwość złożenia wniosku w postaci papierowej, przesyłanego pocztą tradycyjną do komórki organizacyjnej centralnie realizującej zadania związane z rejestracją.

Obsługa merytoryczna wniosków, która realizowana jest w Systemie SZPROT, oparta jest na silniku workflow. Podstawą do identyfikacji Podmiotu jest nadanie numeru ID SISC. Numer służy do jednoznacznej identyfikacji Podmiotu we wszystkich systemach powiązanych z Systemem SZPROT, niezależnie od tego w jakim obszarze prowadzi działalność tj. zarówno w cle, podatku akcyzowym, grach hazardowych, podatkach innych czy INTRASTAT. Dodatkowo numer ID SISC jest również używany do identyfikacji Podmiotów w ramach Systemów centralnych KE z którymi KAS regularnie wymienia dane o prowadzonych postępowaniach.

Obsługa wniosków rejestracyjnych może zakończyć się:

 nadaniem numeru EORI dla Podmiotów krajowych i zagranicznych działających w obszarze cła;

 nadaniem numeru ID SISC Podmiotom działającym w obszarach: cła, INTRASTAT, akcyzy, gier hazardowych, podatków innych;

 nadaniem numeru ID SISC osobom fizycznym krajowym i zagranicznym;

 zarejestrowaniem uprawnień do działania, czyli wzajemnych powiązań pomiędzy:

o Podmiotem a innym Podmiotem;

o Podmiotem a osobą fizyczną.

Format ID SISC jest następujący:

1) dla Podmiotów - długość 17 znaków:

 dla Podmiotów krajowych posiadających numer REGON 9-cio znakowy: litery PL, numer NIP oraz pięć zer,

 dla Podmiotów krajowych posiadających numer REGON 14-sto znakowy: litery PL, numer NIP oraz 5 ostatnich cyfr numeru REGON,

 dla Podmiotów zagranicznych z krajów trzecich (poza unijnych), które nie posiadają numeru EORI: litery PL, 14 znakowy unikalny numer sekwencyjny oraz litera Z,

 dla Podmiotów zagranicznych posiadających numer EORI (nadany w innym kraju unijnym) numer EORI tego Podmiotu uzupełniony zerami do 17 znaków;

2) dla osób fizycznych - długość 17 znaków:

 dla osób fizycznych posiadających nr PESEL: litery PL oraz numer PESEL, uzupełniony zerami do 17 znaków;

 dla osób fizycznych nie posiadających nr PESEL: dwuliterowy kod kraju, data urodzenia zapisana w formacie RRMMDD, 4-ro znakowy numer sekwencyjny oraz literą S i uzupełniony zerami do 17 znaków.

Poza numerem ID SISC Podmioty prowadzące działalność w obszarze cła będą dodatkowo posiadać identyfikator w postaci numeru EORI.

Poniżej został opisany uproszczony przebieg procesu obsługi wniosku rejestracyjnego:

 walidacja techniczna wniosku przed wpływem do Systemu SZPROT;

 odnotowanie wpływu w rejestrze wpływów– wniosek elektroniczny;

 zarejestrowanie ręczne w rejestrze wpływów

 zadekretowanie wniosku (nadanie numeru JRWA, wskazanie prowadzącego sprawę);

 weryfikacja merytoryczna, w tym:

o dla wniosków w zakresie rejestracji danych Podmiotu, w których podany jest numer EORI nadany w innym kraju UE następuje komunikacja z EOS-EORI w wyniku której pobierane są dane z EOS-EORI do warstwy aplikacyjnej Systemu SZPROT;

o dla Podmiotów krajowych możliwe jest wywołanie komunikacji z e-Rejestracja, który w formie PDF prezentuje podstawowe dane o podmiocie;

 w sytuacji, gdy rejestracja danych Podmiotu (krajowego lub zagranicznego) wiąże się z nadaniem numeru EORI, następuje komunikacja z EOS-EORI. W tym momencie następuje zatrzymanie procesu związane z oczekiwaniem na odpowiedź z Systemu EOS- EORI. Do czasu wpływu komunikatu zwrotnego z EOS-EORI, PS nie ma możliwości podjęcia dalszych działań związanych z procedowaniem tej konkretnej sprawy. Odnotowanie wpływu komunikatu pozwala na przejście do kolejnych kroków procesu);

 przygotowanie pisma informacyjnego do wnioskodawcy (treść części pism generuje się automatycznie);

 podpisanie pisma;

 komunikacja z Systemem PDR PL/UE – w zależności od zakresu rejestrowanych danych przekazanie danych do słownika:

o 4000 – osoby fizyczne,

o 4003 – Podmioty,

o 4001 – reprezentacja Podmiot-osoba fizyczna,

o 4002 – reprezentacja Podmiot – Podmiot;

 przekazanie do wysyłki – dla wniosków elektronicznych (komunikacja z Systemem SEAP);

 potwierdzenie wysłania, poprzez uzupełnienie daty faktycznej wysyłki pisma w kancelarii – dla wniosków papierowych;

 zapisanie komunikatu wychodzącego w rejestrze w korespondencji wychodzącej (krok realizowany automatycznie przez System SZPROT).

Na etapie weryfikacji merytorycznej, jeżeli wniosek posiada braki formalne, istnieje możliwość wysłania do Użytkownika informacji o konieczności uzupełnienia braków formalnych. Pismo jest generowane w podprocesie, w którym następuje jego przygotowanie, podpisanie i przekazanie do wysyłki. Sprawa w takim przypadku otrzymuje status „oczekiwanie”.

System SZPROT umożliwia rejestrację wniosków papierowych. Wprowadzanie danych z wniosków następuje poprzez wykorzystanie formularza elektronicznego. W trakcie wprowadzania, dane są walidowane z wykorzystaniem reguł walidacyjnych zaimplementowanych w określonych formularzach. Każdy wniosek wprowadzony do Systemu SZPROT można edytować do poziomu pola, na kroku weryfikacji wniosku.

Każdy wniosek ma możliwe do realizacji dwie ścieżki procesu obsługi:

 pozytywną – zakończoną nadaniem numeru i zapisaniem danych w bazie Systemu SZPROT, a następnie w słowniku danych referencyjnych w Systemie PDR PL/UE;

 negatywną – zakończoną wysłaniem pisma informującego o negatywnym rozpatrzeniu wniosku.

W Systemie SZPROT można dokonać zestawień:

 ilości zarejestrowanych spraw dziennie;

 ilości zarejestrowanych spraw w określonym przedziale czasowym;

 ilości zarejestrowanych spraw przydzielonych konkretnej osobie w danym dniu lub w określonym przedziale czasowym;

 ilości zarejestrowanych spraw zakończonych w danym dniu lub w określonym przedziale czasowym;

 ilości zarejestrowanych spraw zakończonych w danym dniu lub w określonym przedziale czasowym przez konkretną osobę prowadzącą sprawę.

 ilości spraw znajdujących się w statusie „oczekujące” w danym dniu lub we wskazanym przedziale czasowym.

System SZPROT dla usługi e-Klient prowadzi rejestry i zbiory informacji w celu wspomagania procesów realizowanych w KAS, zgodnie z wymaganiami wynikającymi z przepisów UKC, OP, RW, PC.

System SZPROT pracuje w trybie on-line 24 godziny na dobę 7 dni w tygodniu.

Każdego dnia jest rejestrowanych średnio 500 wniosków, które są obsługiwane w jednym miejscu w Polsce w Izbie Administracji Skarbowej w Poznaniu. System SZPROT w zakresie e-Klient działa tylko w warstwie centralnej.

System SZPROT dla usługi e-Klient obsługuje następujące dokumenty: WRR0001 – Wniosek rejestracji osoby fizycznej

WRR0002 – wniosek aktualizacji osoby fizycznej WRR0003 – wniosek dezaktywacji osoby fizycznej WRP0001 – wniosek rejestracji Podmiotu WRP0002 – wniosek aktualizacji Podmiotu WRP0003 – wniosek dezaktywacji Podmiotu

WPE0001 – wniosek rejestracji/aktualizacji/dezaktywacji reprezentacji

Załącznik do sprawy – wniosek wspólny dla usług realizowanych w ramach e-Klienta i e-Decyzje.

2.3.2.3. Architektura logiczna w zakresie SZPROT

2.3.2.3.1. Warstwy Systemu SZPROT

W Systemie SZPROT można wyróżnić następujące logiczne warstwy oprogramowania:

 warstwa zasobów;

 warstwa dostępu do danych;

 warstwa logiki biznesowej;

 warstwa prezentacji:

o warstwa dostępu do logiki biznesowej (WebServices),

o warstwa interfejsu użytkownika (GUI).

Każda z warstw ma dostęp wyłącznie do usług oferowanych przez warstwę bezpośrednio niższą. Oznacza to, że np. funkcje realizujące interfejs użytkownika w warstwie prezentacji nie komunikują się w sposób bezpośredni z bazą danych, lecz wykorzystują do tego funkcje udostępniane przez moduły aplikacji działające w warstwie dostępu do logiki biznesowej, które z kolei poprzez warstwę logiki biznesowej wywołują funkcje interfejsu udostępnionego przez odpowiedni moduł dostępu do danych.

2.3.2.3.2. Komponenty oprogramowania.

Poniżej przedstawiony został diagram komponentów oprogramowania z ich wzajemnymi powiązaniami z uwzględnieniem interfejsów oraz krótki opis komponentów, z których składa się System SZPROT.

Diagram komponentów oprogramowania

System SZPROT oparty został na 4 podstawowych komponentach oprogramowania:

 Baza danych MS SQL Server;

 Repozytorium dokumentów EMC Documentum;

 Silnik procesów Activiti;

 Aplikacja intranetowa SZPROT.

Opis komponentów Systemu SZPROT:

 Baza danych - MS SQL Server 2012

o Relacyjny model danych - przechowuje następujące informacje:

 xxxx Xxxxxxxxx, reprezentantów oraz powiązań między nimi - e-Klient;

 dane z pozwoleń, zezwoleń, upoważnień, zgód, rozstrzygnięć wydawanych w obszarach cła, INTRASTAT, akcyzy oraz gier hazardowych - e-Decyzje;

 dane z oświadczeń oraz zaświadczeń;

 dane dotyczące prowadzonych spraw i dokumentów;

 dane osób wpisanych na listę agentów celnych;

 dane miejsc wyznaczonych;

 dane z obszaru gier hazardowych (zgłoszeń urządzenia loterii fantowej lub zgłoszeń urządzania gry bingo fantowe, koncesji na prowadzenie kasyna gry, loterii pieniężnej, gry telebingo, gry liczbowej, zezwoleń na urządzanie turnieju gry w pokera, zezwoleń na urządzanie zakładów wzajemnych, zezwoleń na urządzanie salonu gry bingo pieniężne;

 dane z komunikatów SEED UE.

Dostęp do danych zapewniony jest poprzez JDBC, ODBC lub inny sterownik dostarczany dla SQL Server.

o Repozytorium XML - wydzielony fragment relacyjnego modelu danych odpowiedzialny za przechowywanie dokumentów składanych przez Podmioty. Wnioski przechowywane są w formacie XML. Dostęp do danych zapewniony jest poprzez JDBC, ODBC lub inny sterownik dostarczany dla SQL Server.

 Repozytorium dokumentów EMC Documentum 6.7

o Content Server - serwer treści. Przechowuje dokumenty związane z obsługą spraw, które są plikami binarnymi (PDF, jpg, doc i inne). Wykorzystywany jest również moduł do wyszukiwania pełnotekstowego FTI (Full-Text Index). Przechowuje konfigurację formularzy i rejestrów, zapewnia obsługę kont użytkowników oraz uprawnień. Dostęp do danych jest możliwy przy użyciu specjalnego API DFC (Documentum Foundation Classes).

o Java Method Server - komponent do definiowania metod serwerowych które mogą być uruchomiane podczas działania procesu.

 Activiti w wersji 5.13

o Activiti Engine - silnik procesów biznesowych definiowanych w standardzie BPMN

2.0. Dostęp do danych procesowych możliwy jest poprzez specjalne API Activiti.

o Activiti Explorer - komponent pozwalający zarządzać procesami posiadający wbudowany graficzny edytor procesów.

 Szprot App

o Serwisy aplikacyjne - zawiera główne moduły realizujące logikę biznesową aplikacji.

o Interfejs niewizualny (WebServices) - udostępniające funkcje logiki biznesowej systemom zewnętrznym przy pomocy usług sieciowych (WebService).

o Interfejs wizualny (GUI)

 Szprot Forms - komponent odpowiedzialny za konfigurację oraz wyświetlanie formularzy.

 Szprot Registries - komponent odpowiedzialny za konfigurację oraz wyświetlanie rejestrów z danymi systemu.

2.3.2.3.3. Powiązania z innymi systemami.

Obecnie System SZPROT jest systemem źródłowym dla danych rejestracyjnych Klientów w ramach usługi e-Klient oraz systemem źródłowym dla danych z rozstrzygnięć w ramach usługi e-Decyzje. Dane te replikowane są do Systemu PDR PL/UE, który pełni funkcję bazy referencyjnej dla wszystkich Systemów SISC.

Integracje systemu SZPROT.

W Systemie SZPROT realizowany jest obecnie dwojaki sposób integracji systemów:

 Systemy centralne KE - dwukierunkowa komunikacja odbywa się:

o w trybie synchronicznym za pomocą usług WebService bezpośrednio poprzez bramkę CCN-CSI – S2S np. funkcja wyszukiwania informacji o podmiocie EORI;

o w trybie asynchronicznym za pomocą usług WebService poprzez kolejki w Systemie MCA i dalej poprzez bramkę CCN-CSI np. rejestracja Podmiotu w bazie EOS/EORI. System SZPROT wysyła synchronicznie komunikat w określonej postaci do MCA i dalej MCA poprzez swój system kolejek obsługuje komunikację z Systemami

centralnymi KE i zwraca pseudo-synchronicznie (w oparciu o id korelacji) komunikat do Systemu SZPROT;

 Systemy SISC (komunikacja za pomocą usług WebService) – komunikacja synchroniczna na potrzeby danych operacyjnych w procesach biznesowych.

Dane referencyjne zgromadzone w Systemie SZPROT replikowane są do Systemu PDR PL/UE, a ten udostępnia je Systemom SISC.

Integracja obejmuje:

 PDR PL/UE – System SZPROT korzysta z części danych słownikowych oraz umieszcza własne dane w dedykowanych słownikach w Systemie PDR PL/UE (replikacja danych o Podmiotach / reprezentantach oraz zakresie reprezentacji; przesyłanie danych o pozwoleniach; pobieranie i aktualizacja danych słownikowych; odpowiedzi w ramach żądania / zapytania o numer EORI oraz replikacji danych Podmiotów unijnych w przypadku niepowodzenie znalezienia ich w Systemie SZPROT);

 EOS-EORI – System SZPROT pobiera dane Podmiotów zagranicznych, posiadających numer EORI nadany w innym kraju UE (kraj trzeci – (TC) i kraj z Unii Europejskiej – (UE)) oraz publikuje w EOS dane Podmiotów krajowych i zagranicznych ( z krajów Trzecich), którym numer EORI został nadany w Systemie SZPROT;

 EOS-AEO – System SZPROT w trakcie realizacji procesu wydawania pozwolenia AEO wymienia, pobiera i publikuje dane z wniosku oraz pozwolenia AEO;

 EOS- AEO (MRA Management) – System SZPROT konsultuje dane Podmiotów z krajów trzecich posiadających numer EORI a-like zarejestrowany w Systemie EOS na podstawie porozumienia o wzajemnym uznawaniu statusu AEO między UE a państwem trzecim (obecnie w EOS są numery JP, US, CN i CH). Numer jest rejestrowany i zarządzany na poziomie Komisji Europejskiej. XXX nie przekazuje systemom krajowym informacji o aktualizacji rekordu, dlatego też numer EORI a-like trzeba każdorazowo konsultować z EOS.

 PKI – System SZPROT wykorzystuje certyfikat celny niekwalifikowany do podpisywania komunikatów wygenerowanych w SZPROT i wysyłanych na konto Użytkownika oraz korzysta z kontrolki Systemu PKI w celu weryfikacji podpisu złożonego pod dokumentami wchodzącymi do Systemu SZPROT.

 MCA - wykorzystywana do komunikacji z Systemem EOS (EOS-EORI, EOS-AEO) oraz z e- Rejestracja.

 e-Rejestracja – System SZPROT korzysta z danych Podmiotów w celach weryfikacyjnych.

Dane udostępniane są w formacie PDF.

 ECIP/SEAP – Portal PUESC wykorzystywany do składania wniosków elektronicznych, które przesyłane są do Systemu SZPROT. Każdy wniosek rozpatrzony w Systemie SZPROT kończy się wysłaniem komunikatu (UPO, informacji, potwierdzenia), który jest publikowany na koncie Użytkownika.

 ZISAR – System SZPROT korzysta z analizy ryzyka realizowanej w Systemie ZISAR, a dane pobierane przez System SZPROT są załącznikiem w sprawie w postaci pliku PDF.

 ZEFIR2 – System SZPROT w trakcie procesu pobiera informacje o zadłużeniu, a pobierane dane są załącznikiem w sprawie, w postaci pliku PDF;

 OSOZ2 – System SZPROT pobiera informacje o rozliczeniach / zabezpieczeniach, a udostępniane dane są załącznikiem w sprawie w postaci pliku PDF.

 SEED UE - wymiana informacji o zezwoleniach akcyzowych wydanych Podmiotom.

2.3.2.3.4. Licencje wykorzystywane przez System SZPROT

Lp.	Rodzaj środowiska	Nazwa oprogramowania	Ilość instancji	Charakterystyka (np. sposób licencjonowania, wersja)	Liczba licencji
1.	Produkcyjne	00-000-000 EMC DOCUMENTUM PLATFORM BUNDLE 000-000-000 EMC DOCUMENTUM CUSTOM CLIENT	1	Na użytkownika	5289
2.	Produkcyjne	Cameleoo EMC Documentum Edition v.2		Na użytkownika	5289
3.	Produkcyjne	Java EE	2	Darmowa – GPL License	Nie dotyczy
4.	Produkcyjne	Activiti	6	Darmowa - Apache License 2.0	Nie dotyczy
5.	Produkcyjne	Apache Tomcat	6	Darmowa - Apache License, Version	Nie dotyczy
6.	Testowe	00-000-000 EMC DOCUMENTUM PLATFORM BUNDLE 000-000-000 EMC DOCUMENTUM CUSTOM CLIENT	1	Na użytkownika	529
7.	Testowe	Cameleoo EMC Documentum Edition v.2		Na użytkownika	529
8.	Testowe	Java EE	2	Darmowa – GPL License	Nie dotyczy
9.	Testowe	Activiti	6	Darmowa - Apache License 2.0	Nie dotyczy
10.	Testowe	Apache Tomcat	6	Nie dotyczy	Nie dotyczy
11.	Rozwojowe	00-000-000 EMC DOCUMENTUM PLATFORM BUNDLE 000-000-000 EMC DOCUMENTUM CUSTOM CLIENT	1	Na użytkownika	53
12.	Rozwojowe	Cameleoo EMC Documentum Edition v.2		Na użytkownika	53
13.	Rozwojowe	Java EE	1	Darmowa – GPL License	Nie dotyczy
14.	Rozwojowe	Activiti	3	Darmowa - Apache License 2.0	Nie dotyczy
15.	Rozwojowe	Apache Tomcat	3	Darmowa - Apache License, Version 2.0	Nie dotyczy
16.	Produkcyjne	MS SQL 2012 Enterprise Core	2	1 licencja na dwa vCPU	4
17.	Testowe	MS SQL 2012 Standard Core	2	1 licencja na dwa vCPU	2
18.	Rozwojowe	MS SQL 2012 Developer per User	1	Na użytkownika	53

Wykaz oprogramowania dodatkowego instalowanego na blokach OS środowisku PRODUKCYJNYM, TESTOWYM i ROZWOJOWYM

3. Założenia rozwoju i modernizacji Systemów SZPROT i SEAP w ramach Programu PUESC

3.1. Założenia i koncepcja Systemu SEAP PLUS

Celem zamówienia jest dokonanie przebudowy, modernizacji i rozbudowy funkcjonalnej Systemu SEAP oraz dostosowanie go do współpracy z wytworzonymi lub zmodyfikowanymi (także w ramach

Programu PUESC, finansowanego w ramach POPC) komponentami SISC. System odpowiedzialny będzie za zapewnienie środowisku SISC, w tym komponentom wytworzonym w ramach Programu PUESC, komunikacji z Klientami. Ponadto będzie platformą do wystawiania usług oferowanych Klientom przez komponenty SISC z obszaru PUESC, rozwinie zintegrowane mechanizmy umożliwiające uwierzytelnianie i autoryzację Użytkowników do usług centralnych Komisji Europejskiej oraz wprowadzi rozwiązania umożliwiające użycie w celu uwierzytelnienia na PUESC np. profilu podatnika i profilu zaufanego ePUAP i/lub funkcjonalności oferowanych przez Węzeł krajowy (w sytuacji, gdy realizacja tego projektu będzie na etapie pozwalającym na podjęcie działań integracyjnych).

Celem realizacji zamówienia jest modernizacja oraz rozwój Systemu SEAP PLUS i dostosowanie go do potrzeb poszczególnych grup jego użytkowników, zoptymalizowanie współpracy z komponentami SISC oraz wykonanie i przeprowadzenie integracji z nowo wytworzonymi komponentami.

Zakłada się w szczególności rozwój funkcjonalny oraz niezbędną przebudowę, rozbudowę i dostosowanie Platformy Programowej w oparciu o wytworzoną przez Wykonawcę dokumentację Systemu SEAP PLUS oraz dokumentację dostarczoną przez Zamawiającego, dotyczącą wymaganej rozbudowy interfejsu użytkownika oraz współpracy z innymi komponentami SISC, w tym z komponentami realizowanymi w ramach Programu PUESC, a także wymogami określonymi w dokumentacji dostarczonej przez Komisję Europejską.

Zmiany w Systemie SEAP PLUS będą wymagały przede wszystkim:

 przebudowy Platformy Programowej w celu zastosowania najnowszych wersji oprogramowania (obowiązujących w dniu dostawy lub innych stabilnych wersji uzgodnionych z Zamawiającym) lub zastosowania innego (nowego) oprogramowania w jego najnowszych wersjach, z zachowaniem w pełnym zakresie dotychczasowych funkcjonalności Systemu (w tym udostępnienia wszystkich formularzy z zachowaniem co najmniej dotychczasowych mechanizmów walidacyjnych i automatyzujących), chyba że funkcjonalności te będą zmieniane na podstawie wymagań określonych w Umowie lub jej załącznikach;

 dostarczenia licencji na zastosowane oprogramowanie dla wszystkich środowisk Systemu, zgodnie z warunkami Umowy;

 przeprowadzenia migracji wszystkich danych w pełnym zakresie, chyba że zakres danych ulega zmianie na podstawie zapisów Umowy lub jej załączników;

 przeprowadzenia analizy potrzeb i wymagań interesariuszy, określającej formy i sposoby komunikacji Klientów z istniejącymi i projektowanymi komponentami SISC;

 przygotowania koncepcji Systemu SEAP PLUS jako platformy świadczącej usługi w zakresie komunikacji elektronicznej Klientów z SISC, w tym z komponentami wytworzonymi w ramach Programu PUESC. Koncepcja zostanie opracowana w oparciu o zebrane wymagania interesariuszy, ocenę ergonomii i jakości dotychczasowych rozwiązań, uzgodnienia z poszczególnymi projektami Programu PUESC, wytyczne TAXUD, dostępne technologie, wytyczne i rekomendacje dot. architektury biznesowej i technicznej oraz z uwzględnieniem działań podejmowanych przez Ministra Cyfryzacji w zakresie Strategii Informatyzacji Państwa;

 wytworzenia mechanizmów Systemu SEAP PLUS na podstawie opracowanej i uzgodnionej koncepcji;

 zintegrowania mechanizmów Systemu SEAP PLUS z innymi komponentami SISC, w tym integracja z systemem kancelaryjnym;

zdefiniowania zasad korzystania przez Systemy dziedzinowe z platformy komunikacyjnej, w tym w szczególności z zastosowaniem dostarczanych przez te systemy Komponentów Komunikacyjnych, a także z mechanizmów odpowiedzialnych za przepływy i udostępnianie informacji oraz dostęp do dokumentów elektronicznych gromadzonych w repozytorium.

 rozbudowy mechanizmów zarządzania tożsamością i uprawnieniami w ramach integracji z UUM&DS;

 wdrożenia usługi e-Dokumenty, która umożliwi dostarczanie dokumentów w postaci elektronicznej, celem wykorzystania tych dokumentów przez funkcjonariuszy i pracowników KAS i Klientów w procesach realizowanych w ramach SISC oraz zapewnienia ich reużywalności;

 rozbudowy i optymalizacji interfejsu graficznego Portalu PUESC, wynikającej z integracji z komponentami SISC i realizującej postulaty zgłaszane przez Użytkowników, a także uwzględniającej rozdzielenie i personalizację profili poszczególnych grup Użytkowników Systemu SEAP PLUS;

 dostosowania Portalu PUESC do obsługi innych publicznych usług uwierzytelniających świadczonych między innymi przez Platformę e-PUAP, profil podatnika i/lub krajowy węzeł zarządzania tożsamością;

 rozbudowy niewizualnych interfejsów komunikacyjnych odpowiedzialnych za integrację z systemami Klientów KAS oraz komponentami SISC;

 rozbudowy i optymalizacji modułów konfiguracyjnych i diagnostycznych Systemu SEAP związanych z procesami przesyłania i przetwarzania komunikatów pomiędzy użytkownikami zewnętrznymi a komponentami SISC;

 modernizacji wszystkich niezbędnych komponentów oprogramowania wchodzących w skład Platformy Programowej, związanej z aktualizacją Oprogramowania gotowego do najnowszych wersji w przypadku pozostania przy obecnej architekturze Systemu SEAP.

 ujednolicenia autoryzacji Użytkowników wewnętrznych, która ma się odbywać w komponencie autoryzacyjnym dostarczonym i wskazanym przez Zamawiającego, ale jeśli taki komponent na etapie wytwarzania Systemu nie zostanie wskazany, musi być zrealizowana bezpośrednio w Systemie.

Szczegółowe wymagania funkcjonalne i pozafunkcjonalne dla Systemu SEAP PLUS zostały zdefiniowane w dalszej części niniejszego dokumentu.

3.1.1.Założenia i koncepcja oraz wymagania dotyczące Komponentów Komunikacyjnych.

W zakresie Komponentów Komunikacyjnych należy przyjąć następujące założenia:

1. Interfejs wizualny użytkownika zewnętrznego służący do przesyłania za pośrednictwem Portalu PUESC komunikatów biznesowych do systemów SISC lub do prezentacji informacji na Portalu PUESC musi zostać zrealizowany jako produkt wykonany w formie portletu. Produkty te, zwane Komponentami Komunikacyjnymi, będą osadzane na Portalu PUESC. Wymaganie to dotyczy Komponentów Komunikacyjnych realizowanych w projektach/podprojektach Programu PUESC. Dopuszcza się wytworzenie Komponentu Komunikacyjnego w formie formularza, w narzędziu dostarczonym przez Wykonawcę, służącym do budowy i implementacji formularzy webowych/ przeglądarkowych/ internetowych, wymaga to jednak każdorazowej zgody Zamawiającego oraz uzyskania odstępstwa od architektonicznej decyzji kierunkowej.

2. Wymagania dotyczące Komponentu Komunikacyjnego zostaną opracowane w pierwszym etapie realizacji Umowy. Wymagania te obejmują x.xx. standard techniczny dla Komponentu Komunikacyjnego, sposób jego implementacji i wizualizacji, podstawowy zestaw metod dostępnych w ramach usług pośredniczących (tzw. dedykowane API), procedurę audytu, procedurę testowania integracyjnego, wytyczne w zakresie user experience, responsywności, wytycznych konsorcjum W3C WCAG.

3. Dostarczany Komponent Komunikacyjny musi być zgodny z Wymaganiami dotyczącymi Komponentu Komunikacyjnego.

4. Za pomocą Komponentu Komunikacyjnego osadzonego na Portalu PUESC może zostać zrealizowany wyłącznie interfejs służący do komunikacji (w tym prezentacji informacji) pomiędzy SISC a użytkownikami zewnętrznymi (podmiotami gospodarczymi i partnerami Krajowej Administracji Skarbowej) w zakresie udostępnianych przez SISC usług oraz obsługi procesów biznesowych. Wykorzystanie Komponentu Komunikacyjnego do innych celów wymaga każdorazowej zgody Zamawiającego oraz uzyskania odstępstwa od architektonicznej decyzji kierunkowej.

5. Komponent Komunikacyjny musi być odporny na cyberataki (między innymi: SQL injection, cross-site scripting, cross-site request forgery, session fixation, session hijacking, DoS, DDoS). Szczegółowe wymagania w zakresie zabezpieczeń zostaną zdeterminowane wyborem technologii. Zostaną one określone przez Wykonawcę w Wymaganiach dotyczących Komponentu Komunikacyjnego.

6. Ze względów bezpieczeństwa Komponent Komunikacyjny nie może nawiązywać bezpośrednich połączeń do baz danych SISC. Musi korzystać z usług pośredniczących udostępnionych na Portalu PUESC. Usługami pośredniczącymi w komunikacji mogą być metody silnika formularzy SEAP, Webservice typu SOAP lub REST oraz inne mechanizmy zaakceptowane przez Zamawiającego. Zadaniem usługi pośredniczącej jest odseparowanie Komponentu Komunikacyjnego od bezpośredniego połączenia z bazą danych. Dla przykładu, w przypadku komunikacji z systemem danych referencyjnych SISC PDR PL/UE Komponent Komunikacyjny musi wykorzystać udostępnione przez PDR PL/UE metody dostępu do danych referencyjnych.

7. Komponent Komunikacyjny musi pozyskiwać dane referencyjne z Systemu PDR PL/UE (przy użyciu dostarczonego przez Wykonawcę API) w sytuacji, gdy dane te są dostępne w tym systemie. Odstąpienie od tego wymagania wymaga zgody Zamawiającego oraz odstępstwa od architektonicznej decyzji kierunkowej.

8. W przypadku, gdy Komponent Komunikacyjny wymagana uwierzytelniania, musi on zintegrować się z jednokrotnym uwierzytelnianiem SSO, zaimplementowanym w obrębie całego Portalu PUESC.

9. Obsługa uprawnień w Komponencie Komunikacyjnym musi zostać zrealizowana przy użyciu dostarczonego przez Wykonawcę API do obsługi macierzy uprawnień

10. Komponent Komunikacyjny musi zostać zwizualizowany co najmniej w języku polskim oraz angielskim. Musi on automatycznie wykrywać język interfejsu zgodny z językiem wybranym przez użytkownika zewnętrznego na Portalu PUESC (np. poprzez implementację procedury obsługi zdarzenia zmiany języka). W przypadku gdy wybrany język nie jest dostępny, powinien zostać zastosowany język angielski.

11. Komponent Komunikacyjny musi być przystosowany dla obsługi przez osoby niepełnosprawne (np. niepełnosprawni ruchowo lub niedowidzący) poprzez wyświetlanie treści przy zastosowaniu stylu przeznaczonego dla niepełnosprawnych. Styl będzie jednolity dla całego Portalu PUESC i będzie spełniał wytyczne konsorcjum W3C WCAG 2.0 na poziomie A i AA. Komponent Komunikacyjny będzie podlegał audytom przeprowadzanym przez Wykonawcę w zakresie weryfikacji zgodności z wymaganiami WCAG 2.0 na poziomie AA. Wykonawca Komponentu Komunikacyjnego zobowiązany jest wprowadzać zmiany w wytwarzanych Komponentach Komunikacyjnych uwzględniające wyniki ww. audytów.

12. Komponent Komunikacyjny musi implementować zasady User Experience określone w Wymaganiach Dotyczących Komponentu Komunikacyjnego opracowanych przez Wykonawcę. Jego wygląd i układ musi zostać tak wkomponowany w Portal PUESC, aby automatycznie dostosowywał się do ekranu urządzenia na którym jest wyświetlany, np. na smartfonach czy tabletach przez zastosowanie x.xx. responsywności (RWD).

13. Wszelkie dokumenty wygenerowane przez Komponent Komunikacyjny, niosące skutek prawny (w tym wszystkie podpisane podpisem elektronicznym), muszą zostać przesyłane za pośrednictwem właściwej metody, udostępnionej na Portalu PUESC (np. umieszczenie w rejestrze dokumentów do wysyłki) i przez to włączone do procesu komunikacji Portalu PUESC. Zamawiający zastrzega sobie możliwość odstąpienia od tego wymagania..

14. Wszelkie dokumenty wygenerowane w Komponencie Komunikacyjnym niosące skutek prawny muszą posiadać funkcjonalność wizualizacji w formacie PDF oraz drukowania w układzie odpowiadającym wzorom dokumentów papierowych.

15. Wykonawca Systemu Dziedzinowego określi wielkość zasobu infrastrukturalnego wymaganego do poprawnego działania Komponentu Komunikacyjnego (zgodnie z wymaganiami Systemu Dziedzinowego) w jednostkach vCPU (wymagane jest podanie wartości vCPU, zaokrąglonej do najbliższej liczby całkowitej) i RAM. Wielkość tą wlicza się do całkowitego limitu przyznanych zasobów infrastrukturalnych, który może wykorzystać Wykonawca Systemu Dziedzinowego w ramach realizacji umowy. Infrastruktura obejmuje również zasób infrastrukturalny wymagany zarówno na uruchomienie środowiska produkcyjnego jak i testowego..

16. Wykonawca Systemu Dziedzinowego wydziela ze swojej puli zasób infrastrukturalny określony w punkcie 15, a wydzielony zasób powiększa zasoby infrastrukturalne Systemu SEAP PLUS. W sytuacji, gdy w wyniku audytu zostanie oszacowana inna wielkość wymaganego do poprawnego działania Komponentu Komunikacyjnego zasobu infrastrukturalnego, Wykonawca Systemu Dziedzinowego musi wydzielić wielkość zasobu na podstawie rekomendacji wynikającej z audytu i decyzji Zamawiającego.

17. W przypadku interakcji pomiędzy Portalem SEAP a osadzonym na nim Komponentem Komunikacyjnym Wykonawca Systemu Dziedzinowego może opracować lub rekomendować inny, dedykowany interfejs API umożliwiający pełniejszą integrację pomiędzy portalem SEAP

a Komponentem Komunikacyjnym (o większej funkcjonalności i precyzji interakcji). Interfejs taki wymaga jednak akceptacji Zamawiającego.

18. Osadzany Komponent Komunikacyjny nie może zakłócać działania zarówno Portalu PUESC, jak i już zaimplementowanych na nim innych Komponentów Komunikacyjnych oraz formularzy. Dodatkowo musi spełniać Wymagania Dotyczące Komponentu Komunikacyjnego opracowane przez Wykonawcę. Osadzony na portalu PUESC Komponent Komunikacyjny musi spełniać wymagane normy wydajnościowe Usługę utrzymania Komponentu Komunikacyjnego świadczy jego wykonawca.

a) Wykonawca jest zobowiązany do każdorazowego przeprowadzenia audytu Komponentu Komunikacyjnego dostarczonego przez Wykonawcę Systemu Dziedzinowego pod kątem wydajności oraz zgodności z Wymaganiami Dotyczącymi Komponentu Komunikacyjnego (z zastrzeżeniem litery c). Audyt działania Komponentu Komunikacyjnego jest przeprowadzany na środowisku wskazanym przez Zamawiającego,

b) Wykonawca jest zobowiązany do opracowania procedury audytu Komponentów Komunikacyjnych i przeszkolenia przedstawicieli Zamawiającego w zakresie przeprowadzania audytu. Po przeprowadzonym szkoleniu Wykonawca potwierdza, że uczestnicy szkolenia nabyli niezbędne umiejętności do przeprowadzenia audytu.

c) Po nabyciu niezbędnych umiejętności do przeprowadzenia audytu Komponentów Komunikacyjnych Zamawiający może podjąć decyzję o jego samodzielnym przeprowadzeniu.

d) Decyzja o implementacji Komponentu Komunikacyjnego na Portalu PUESC podejmowana jest przez Zamawiającego z uwzględnieniem rezultatów audytu i po pozytywnych wynikach testów, na podstawie rekomendacji przeprowadzającego audyt.

e) Osadzenie Komponentu Komunikacyjnego na Portalu PUESC wykonywane jest przez Wykonawcę przy asyście Zamawiającego w oparciu o zaakceptowaną instrukcję dostarczoną przez Wykonawcę Systemu Dziedzinowego. Zamawiający w uzgodnieniu z Wykonawcą może podjąć decyzję o samodzielnym osadzeniu Komponentu Komunikacyjnego. W takim przypadku, samodzielne osadzenie przez Zamawiającego Komponentu Komunikacyjnego nie narusza warunków Gwarancji i Utrzymania określonych w Umowie z Wykonawcą.

19. Wykonawca Systemu Dziedzinowego przeprowadza testy integracyjne działania Komponentu Komunikacyjnego po osadzeniu tego komponentu w środowisku testowym Systemu SEAP PLUS.

20. W przypadku instalacji nowszej wersji środowiska Portalu PUESC Wykonawca lub Wykonawca Systemu Dziedzinowego wytwarzający Komponent Komunikacyjny zobowiązany jest do dostosowania Komponentu Komunikacyjnego do pracy na nowej wersji środowiska, w terminie 30 dni od daty ogłoszenia nadchodzącej zmiany. Zamawiający dopuszcza możliwość wydłużenia tego terminu w przypadku zaistnienia uzasadnionych okoliczności. Wydłużenie terminu wymaga zgody Zamawiającego.

3.2. Założenia i koncepcja Systemu SZPROT PLUS

W ramach Systemu SZPROT PLUS zostaną zmodernizowane, przebudowane i rozbudowane dotychczasowe funkcjonalności Systemu SZPROT oraz zrealizowane nowe rozwiązania funkcjonalne i pozafunkcjonalne opracowane na etapie prac projektowych.

Modernizacja Systemu SZPROT PLUS ma obejmować przebudowę Platformy Programowej polegającą na zastosowaniu najnowszych wersji oprogramowania (obowiązujących w dniu dostawy lub innych stabilnych wersji uzgodnionych z Zamawiającym) lub zastosowania innego (nowego) oprogramowania w jego najnowszych wersjach, z zachowaniem w pełnym zakresie dotychczasowych funkcjonalności Systemu, chyba że będą one zmieniane/rozbudowywane na podstawie wymagań określonych w Umowie lub jej załącznikach. Wykonawca jest zobowiązany do dostarczenia licencji na zastosowane oprogramowanie dla wszystkich środowisk Systemu, zgodnie z warunkami Umowy. Ponadto Wykonawca zobowiązany jest do przeprowadzenia migracji wszystkich danych w pełnym zakresie, chyba że zakres danych ulega zmianie na podstawie zapisów Umowy lub jej załączników.

System SZPROT PLUS musi zachować wielowarstwową architekturę, w której reprezentowane są przynajmniej następujące warstwy: przechowywania danych, logiki biznesowej, prezentacji.

Pod względem architektury modernizacja Systemu SZPROT PLUS obejmie następujące zmiany:

1) wydzielenie dwóch rozdzielnych i niezależnych komponentów:

a. Komponentu e-Klient, odpowiedzialnego za obsługę wniosków związanych z rejestracją, aktualizacją i dezaktywacją danych o Podmiotach, reprezentantach i zakresach reprezentacji, w tym nadawaniem numerów ID SISC, EORI, REX,

b. Komponentu e-Decyzje, odpowiedzialnego za obsługę procesów biznesowych związanych z wydawaniem decyzji, w tym w ramach integracji z CDS;

2) wykorzystanie zewnętrznego CRKiD, udostępnionego przez System SEAP PLUS, jako repozytorium dokumentów spraw zakończonych. Po rozpoczęciu wykorzystywania CRKiD osadzonego w Systemie SEAP PLUS przeprowadzona zostanie migracja danych dokumentów z Systemu SZPROT do CRKiD. System SZPROT PLUS będzie posiadał własną bazę dokumentów wykorzystywaną do obsługi procesów workflow.;

3) dostosowanie Komponentu e-Klient, wymieniającego dane i informacje z innymi systemami biznesowymi, do zmian realizowanych w ramach projektu PUESC;

4) modernizację mechanizmu aktualizacji słowników w Systemie PDR PL/UE, których źródłem danych jest System SZPROT PLUS. Zmodernizowany mechanizm musi uniemożliwić powstanie niespójności danych pomiędzy systemami.

5) wykorzystanie bazy danych Systemu PDR PL/UE do gromadzenia danych (podmiotów, osób fizycznych i zakresu reprezentacji) w zakresie usługi e-Klient;

6) modernizacja rejestracji wpływów wniosków papierowych lub przesyłanych poprzez TP albo na nośnikach danych, wprowadzanych przez Użytkowników wewnętrznych Systemu SZPROT PLUS. System SZPROT PLUS będzie wykorzystywał numer wpływu z rejestru wpływów osadzonego w Systemie SEAP PLUS;

7) modernizacja rejestracji wysyłki dokumentów papierowych z wykorzystaniem numeru wysyłki z rejestru korespondencji wychodzącej osadzonej w Systemie SEAP PLUS;

8) modernizacja formularzy zaimplementowanych w Systemie SZPROT;

9) zastosowanie klastrów wydajnościowo-niezawodnościowych lub niezawodnościowych obejmujących wszystkie komponenty serwerowe systemu w celu zapewnienia ciągłości świadczenia usług wizualnych i niewizualnych w przypadku wyłączenia jednego z serwerów;

10) integracja z komponentem autoryzacyjnym, dostarczonym przez Zamawiającego lub jeśli taki komponent na etapie wytwarzania produktów projektu nie zostanie wskazany, to autoryzacja Użytkowników wewnętrznych będzie odbywała się bezpośrednio w Systemie.

Zamówienie obejmuje również dostarczenie Komponentów Komunikacyjnych w postaci Portletów osadzonych na Portalu PUESC, które w sposób interaktywny pozwolą na sporządzanie i składanie wniosków elektronicznych procedowanych w Systemie SZPROT PLUS, dodawanie załączników do wniosków, przesyłanie wyjaśnień i uzupełnień akt sprawy, uzyskanie informacji o statusie sprawy lub zaświadczenia/oświadczenia, jak również umożliwią realizację zapytania o akta sprawy. Funkcjonalności związane ze sporządzeniem wniosku mogą być również realizowane z wykorzystaniem dostarczonego przez Wykonawcę narzędzia do tworzenia interaktywnych formularzy, jeśli wykorzystanie tej technologii pozwoli zrealizować wszystkie wymagania Zamawiającego dotyczące wniosku oraz Zamawiający wyrazi zgodę na zastosowanie technologii innej niż Potlety.

3.2.1.Wizja komponentu e-Klient

Moduł Systemu SZPROT PLUS zaangażowany w realizację usługi e-Klient ma być wyodrębnionym, interaktywnym komponentem obsługującym wnioski o rejestrację danych Podmiotów, Osób upoważnionych i reprezentacji w SISC. W ramach jego przebudowy i optymalizacji ma nastąpić:

 udostępnienie Klientom przyjaznych formularzy osadzonych na Portalu PUESC w postaci Komponentów Komunikacyjnych, które w sposób interaktywny i intuicyjny pozwolą na składanie wniosków w usłudze e-Klient;

 przebudowa istniejących procesów, ich uelastycznienie i zautomatyzowanie;

 zmodernizowanie i uelastycznienie prowadzonych rejestrów, w tym umożliwienie wykonywania operacji łączenia rekordów z poziomu GUI Użytkownika wewnętrznego;

 uelastycznienie osadzania i modyfikowania szablonów używanych w procesach e-Klient;

 zwiększenie możliwości raportowych dotyczących danych z usługi e-Klient, dostępnych i definiowanych z poziomu GUI Użytkownika wewnętrznego.

Zadaniem modułu e-Klient będzie rejestrowanie i zapisywanie (z wykorzystaniem usług WebService) do bazy Systemu PDR PL/UE danych Podmiotów (słownik 4003), osób fizycznych (słownik 4000) oraz reprezentacji (słownik 4001 i 4002). W celu zapewnienia spójności danych zakłada się, że podobnie jak dla innych komponentów SISC, także dla Systemu SZPROT PLUS miejscem przechowywania i pobierania danych o osobach fizycznych, Podmiotach i reprezentacjach będzie wyłącznie System PDR PL/UE – System SZPROT PLUS będzie pobierał te dane z systemu PDR PL/UE na zasadzie usług subskrypcji lub na innej zasadzie, uzgodnionej z Zamawiającym (obecnie System SZPROT korzysta z danych lokowanych we własnej bazie, będących w stosunku do danych przechowywanych w Systemie PDR PL/UE odrębnym zestawem danych). W Systemie SZPROT PLUS przechowywane będą systemowe dane operacyjne.

W ramach rejestracji Podmiotu System SZPROT PLUS ma umożliwiać:

 nadanie numeru EORI Podmiotom działającym w obszarze cła, które mają siedzibę w Polsce i podmiotom zagranicznym z krajów trzecich (spoza UE);

 nadanie numeru ID SISC wszystkim Podmiotom działającym we wszystkich obszarach;

 nadawanie numeru REX Podmiotom, które mają siedzibę w Polsce a w przypadku odmowy - kierowanie sprawy do postępowania w Systemie SZPROT PLUS.

Rejestracja Podmiotu dotyczy Podmiotów krajowych, z krajów trzecich oraz prowadzących działalność na terenie Unii Europejskiej.

W ramach rejestracji osoby fizycznej System SZPROT PLUS ma umożliwiać nadanie numeru ID SISC osobom krajowym i zagranicznym.

W ramach rejestracji reprezentacji System SZPROT PLUS ma umożliwiać utworzenie aktywnego powiązania pomiędzy Podmiotem a jego reprezentantem, którym może być inny Podmiot – profesjonalnie zajmujący się reprezentacją (np. agencja celna, biuro rachunkowe) lub osoba fizyczna (np. pracownik, pełnomocnik), a także reprezentacji w stosunku do danego Podmiotu w powiązaniu z określonym obszarem działania, np. dla składu podatkowego (przypadki zostaną określone na etapie analizy). Musi być możliwość zarejestrowania reprezentacji kilkupoziomowej:

 Podmiot A jest reprezentowany przez Xxxxxxx X, którego reprezentantem jest pracownik;

 Podmiot A jest reprezentowany przez Podmiot C (reprezentowany przez pracownika), który otrzymał cesję upoważnienia od Podmiotu B.

Zarejestrowany zakres reprezentacji ma być podstawą do publikacji referencji dla innych Systemów działających w ramach SISC.

Ponadto System SZPROT PLUS ma umożliwiać zapisywanie upoważnień w CRKiD, a także zapisywanie przez operatora danych z upoważnienia z możliwością późniejszej reużywalności tych danych, np. w toku walidacji.

Wnioski rejestrowane w ramach usługi e-Klient oraz pozostała dokumentacja wytwarzana do sprawy ma być archiwizowana w CRKiD.

Moduł e-Klient ma być zbudowany na silniku workflow, który pozwoli na następujące czynności w Systemie SZPROT PLUS:

 pobranie numeru wpływu z Systemu SEAP PLUS dla wniosków złożonych w postaci papierowej,

 wprowadzenie wniosku papierowego do Systemu SZPROT PLUS z poziomu GUI,

 nadanie numeru JRWA,

 przydzielenie (automatyczne lub ręczne) prowadzącego sprawę,

 analizę danych zawartych we wniosku (walidacja ręczna i automatyczna),

 automatyczne przejście procesu obsługi wniosku w określonych przypadkach (tzw. ścieżka bezobsługowa),

 wielokrotną elektroniczną komunikację z wnioskodawcą,

 komunikację z wybranymi systemami SISC (np. System PDR PL/UE),

 komunikację z Systemami centralnymi KE (np. EOS),

 komunikację z e-Rejestracja,

 pobranie i zapisanie danych z ww. systemów,

 wybór szablonu pisma do komunikacji z Klientem,

 podpisanie certyfikatem celnym pism wysyłanych do Klienta,

 wielokrotne wygenerowanie komunikatu z informacją o osobie prowadzącej sprawę w przypadku jej zmiany (automatyczne i ręczne),

 dodanie dokumentu (załącznika) do sprawy (na każdym etapie obsługi wniosków).

Ponadto w ramach operacji możliwych do wykonania przez Użytkownika wewnętrznego z poziomu GUI System SZPROT PLUS powinien pozwalać na:

 edycję i modyfikację danych zapisanych w rejestrze: Podmiotów, osób fizycznych, reprezentacji (np. z powodu błędu popełnionego przez prowadzącego sprawę),

 automatyczne wygenerowanie komunikatu do Systemu EOS i/lub zapisanie danych w bazie Systemu PDR PL/UE, jeżeli edycja danych w rejestrze modyfikuje pola podlegające wymianie,

 łączenie rekordów w rejestrze Podmiotów z poziomu GUI Użytkownika wewnętrznego, które będzie skutkować połączeniem danych lub nadpisaniem danych zdublowanych (które dane są nadrzędne decyduje użytkownik), w przypadku spraw, reprezentacji lub rozstrzygnięć dowiązanych do Podmiotu operacja łączy dane lub nadpisuje dane zdublowane (dane nadrzędne wskazuje użytkownik).

Moduł musi mieć zaimplementowany Model uprawnień, która pozwoli na zdefiniowanie uprawnień do określonych ról Użytkowników wewnętrznych (w tym definiowanie ról typu kierownik komórki organizacyjnej, dekretujący, prowadzący sprawę).

W ramach obsługi wniosków realizowanych w usłudze e-Klient moduł będzie wymieniał dane z innymi systemami na dwóch poziomach:

 pobierania danych:

o z Systemu EOS– dane Podmiotów, które posiadają numer EORI nadany w jednym z krajów unijnych. Celem komunikacji jest pobranie danych referencyjnych, które w Polsce mają służyć do weryfikacji Podmiotu, ale nie mogą być modyfikowane. Dane będą pobierane na trzy sposoby:

 usługą EoriConsultation - zapytanie wywołane przez jeden z Systemów dziedzinowych, w wyniku którego pobrane dane mają zostać zapisane w słowniku 4003 wraz z nadaniem numeru ID SISC;

 usługą EORI a-like – zapytanie wywołane przez jeden z Systemów dziedzinowych SISC, w wyniku pobrania dane mają zostać zapisane w

słowniku 4003 wraz z nadaniem numeru ID SISC. System EOS nie przekazuje systemom krajowym informacji o aktualizacji rekordu, dlatego też numer EORI a-like trzeba każdorazowo konsultować z Systemem EOS;

 usługą pobrania danych z poziomu wniosku (z Komponentu Komunikacyjnego Użytkownika i/lub GUI Użytkownika wewnętrznego modułu e-Klient).

o z e-Rejestracja – dane Podmiotów krajowych, które posiadają nadany numer NIP. Celem komunikacji jest pobranie danych podstawowych Podmiotu, możliwość porównania pobranych danych z danymi na wniosku, a także oznaczenia poszczególnych danych pobranych z e-Rejestracji i zasilenia nimi formularza / wniosku / rejestru. Ponadto System SZPROT PLUS ma umożliwiać zapisanie w bazie danych wyspecyfikowanych wg numeru NIP Podmiotów wcześniej niezarejestrowanych i automatyczne nadanie im ID SISC. Pobranie ma być realizowane z poziomu Komponentu Komunikacyjnego Klienta i/lub poziomu GUI Użytkownika wewnętrznego modułu e-Klient.

 udostępniania danych:

o zapis danych w bazie danych Systemu PDR PL/UE w słownikach: 4000, 4001, 4002, 4003;

o do Systemu EOS – publikacja numerów EORI i danych Podmiotów, którym nadano numer EORI w Polsce;

 w przypadku, gdyby realizacja projektu PIUiD znajdowała się na etapie pozwalającym na integrację, wymagana jest realizacja integracji w ustalonym na etapie analizy zakresie.

Formularz wniosku powinien być dostępny do edycji przez Użytkownika wewnętrznego (prowadzącego sprawę na kroku weryfikowania) w zakresie zdefiniowanych pól, oraz mieć możliwość podania tymczasowego adresu i nazwy dla Podmiotów wnioskujących o nadanie numeru EORI, których zaktualizowane dane nie zostały jeszcze wprowadzone do rejestru referencyjnego (KRS, CEDIG). W przypadku aktualizacji danych w rejestrze i odnotowanie tego faktu w bazie danych System powinien automatycznie nadpisywać dane podstawowe i generować komunikaty do EOS- EORI oraz przekazywać je do systemu PDR PL/UE celem zapisania w odpowiednich słownikach.

Ponadto w module mają być dostępne rejestry, które są obecnie prowadzone w Systemie SZPROT:

 rejestr Podmiotów;

 rejestr osób fizycznych;

 rejestr spraw;

 rejestr spraw w toku. oraz dodatkowe rejestry typu:

 rejestr upoważnień;

 rejestr reprezentacji (3 – poziomowy);

 rejestr spraw – oczekujące ;

 rejestr spraw – aktualizacja;

 rejestr spraw – alarm;

 rejestr spraw – pilne;

 rejestr numerów REX.

Rejestry spraw: oczekujące, pilne, alarmy, aktualizacja nie posiadają własnej numeracji i mają służyć do automatycznego zarządzania sprawami i być dostępne z poziomu GUI jako widok Użytkownika wewnętrznego.

Moduł ma umożliwiać generowanie raportów z poziomu GUI służących do kontrolowania stanu bieżącej pracy poprzez wyselekcjonowanie z ogółu spraw konkretnych danych.

Elementem modułu e-Klient ma być Komponent Komunikacyjny, wystawiony na Portalu PUESC i służący do wypełniania wniosków składanych w usłudze e-Klient, sporządzania upoważnień w postaci elektronicznej, dosyłania elektronicznych dokumentów do sprawy oraz odbierania komunikatów wysyłanych z SISC, a także wskazywania dokumentu złożonego w CRKiD oraz umożliwienie dołączenia tego dokumentu do sprawy.

Rozwiązanie dedykowane dla usługi e-Klient ma umożliwiać wypełnianie interaktywnych dokumentów, które w trakcie wypełniania aktywnie komunikują się z danymi referencyjnymi SISC, aby wyeliminować dublowanie wniosków, składanie zbędnych dokumentów lub nieprawidłowo wypełnionych formularzy. Komponent Komunikacyjny będzie umożliwiał zarządzanie Podmiotami i reprezentacjami, z którymi właściciel konta PUESC jest powiązany lub do których jest szczególnie uprawniony. Z poziomu Komponentu Komunikacyjnego będzie możliwe wyświetlenie Podmiotów powiązanych bezpośrednio lub za pośrednictwem Podmiotu reprezentującego oraz reprezentacji i jej zakresu dla danego Podmiotu, w zależności od posiadanych uprawnień. Możliwe będzie pobranie wygenerowanej listy do formatu Excel. Rozwiązanie będzie umożliwiało podpisanie wypełnionych formularzy kwalifikowanym podpisem elektronicznym, podpisem potwierdzonym profilem zaufanym ePUAP lub zaawansowanym podpisem elektronicznym weryfikowanym za pomocą certyfikatu celnego. Z poziomu Komponentu Komunikacyjnego będzie możliwe zapisanie w CRKiD dokumentu będącego pełnomocnictwem oraz dostęp do dokumentów wcześniej umieszczonych w repozytorium.

3.2.2.Wizja komponentu e-Decyzje

Moduł e-Decyzje będzie interaktywną aplikacją obsługującą wnioski z obszaru cła, akcyzy, gier hazardowych, INTRASTAT oraz podatku VAT z tytułu importu. Oprócz obsługi składanych wniosków będzie możliwość procedowania spraw wszczętych z urzędu w ww. obszarach. Obsługiwane będą zarówno wnioski elektroniczne jak i papierowe.

Głównym celem zmian jest:

 wdrożenie nowych procesów usługi e-Decyzje,

 modyfikacja dotychczas zaimplementowanych procesów i formularzy, w celu dostosowania ich do aktualnego stanu prawnego,

 wdrożenie nowych rejestrów,

 zmodernizowanie i uelastycznienie prowadzonych rejestrów, w tym zasad ich przeszukiwania, prezentowania historii wpisów,

 zaimplementowanie nowych funkcjonalności,

 modyfikacja niektórych funkcjonalności obecnego Systemu SZPROT, w tym. x.xx. uelastycznienie wykorzystywanych szablonów używanych w procesach e-Decyzje, tj. umożliwienie opcjonalnego, a nie obligatoryjnego wykorzystania szablonu,

 zwiększenie możliwości raportowych dotyczących danych z usługi e-Decyzje dostępnych i definiowanych z poziomu GUI Użytkownika wewnętrznego,

 integracja z systemami krajowymi w ramach SISC,

 integracja z systemami krajowymi spoza SISC,

 integracja z systemami centralnymi KE,

 umożliwienie Użytkownikom wewnętrznym Systemu SZPROT PLUS bardziej przyjaznego interfejsu Użytkownika wewnętrznego i zarządzania nim,

 umożliwienie Klientom KAS bardziej przyjaznego interfejsu Użytkownika na Portalu PUESC, który w sposób interaktywny i intuicyjny pozwoli na składanie wniosków, dokumentów, zaświadczeń /oświadczeń w usłudze e-Decyzje, jak również pozwoli na zarządzanie nimi.

W Systemie SZPROT PLUS planowane są modyfikacje istniejących oraz realizacja nowych integracji między innymi w następującym zakresie:

1) TP / CDS / CRS - obsługa wniosków przesłanych za pośrednictwem TP do SISC, usługi umożliwiające obsługę wszystkich procesów zgodnie z modelem hybrydowym CD;

2) AES/AIS - proces interakcji będzie wymagał stworzenia interfejsów/funkcji wejścia i wyjścia. Przedstawiona poniżej propozycja mechanizmów integracji jest możliwa do uszczegółowienia/modyfikacji w czasie trwania analizy biznesowej, ustaleń pomiędzy zespołami projektowymi lub analizy/implementacji przez Wykonawców.

 Wejściem (typowym) do procesu obsługi decyzji w komponencie e-Decyzje będzie wywołanie z poziomu SO prośby o wszczęcie postępowania a następnie przekazania danych do wydania decyzji. Możliwe jest też rozpoczęcie procesu wyłącznie przez moduł e-Decyzje. .

o Prośba o wszczęcie postępowania będzie mogła być wywołana z poziomu SO przez użytkownika z uprawnieniami typu „operator” który zgłasza np. nieprawidłowości ujawnione podczas kontroli zgłoszenia/towaru do prawnika. Prośba o wszczęcie postępowania będzie mogła być zarejestrowania autonomicznie przez e-Decyzje tylko dla spraw, które nie mogą być zainicjowane w SO. Prośba generowana przez SO będzie zawierała następujące wartości:

 referencję do zgłoszenia celnego (MRN) i ew. numery pozycji zgłoszenia celnego jeśli decyzja dotyczy wybranych pozycji,

 komentarz operatora. Po wywołaniu prośby o wszczęcie postępowania w e- Decyzje tworzy się sprawa z linkiem do SO, gdzie można oglądać lub edytować obiekt w celu przygotowania decyzji.

o Przekazanie danych do wydania decyzji stanowi przesłanie efektu przygotowania decyzji - zmian oryginalnego obiektu "w trybie decyzji" i będzie mogło być wykonane i wywołane z poziomu SO przez użytkownika z uprawnieniami typu „prawnik”. Na potrzeby przygotowania decyzji zostaną wykorzystane funkcjonalności SO w zakresie edycji, walidacji danych zgłoszenia oraz zapisu w formie roboczej edytowanych danych. a następnie wywołania przekazania danych do wydania decyzji do e-Decyzje. Wersja robocza stanowiąca podstawę do wygenerowania przekazania danych do wydania decyzji będzie mogła być zmieniana wielokrotnie, a wygenerowane przekazanie danych do wydania decyzji przesłane do e-Decyzji również wielokrotnie. Przekazanie danych do wydania decyzji będzie zawierało następujące wartości:

 referencję do zgłoszenia celnego (MRN) i ew. numery pozycji zgłoszenia celnego jeśli decyzja dotyczy wybranych pozycji,

 listę zmian proponowanych z poziomu SO zmian zawartych w wersji roboczej,

 ew. komentarz operatora.

 Wyjściem z procesu obsługi decyzji będzie:

o odnotowanie odmowy wszczęcia postępowania w SO lub

o odnotowanie efektu rozstrzygnięcia w SO po wydaniu decyzji, polegające na zatwierdzeniu zmiany danych zgodnie z przekazanymi danymi do wydania decyzji.

Np. proces decyzji wymierzającej należności celne będzie mógł wyglądać następująco:

 stwierdzenie nieprawidłowości przez funkcjonariusza kontrolującego;

 uruchomienie/zainicjowanie przez funkcjonariusza z poziomu SO prośby o wszczęcie postępowania;

o ustawienie w SO (automatycznie) statusu zgłoszenia do decyzji, co powoduje zatrzymanie procesowania zgłoszenia w SO;

 wejście w tryb edycji kopii zgłoszenia przez prawnika w SO (status zgłoszenia w decyzji, zmiana danych i symulacja zmian);

 zatwierdzenie zmian kopii zgłoszenia przez prawnika;

o automatyczne wygenerowanie przez SO przekazania danych do wydania decyzji (MRN, pozycja towarowa, zakres danych do weryfikacji oraz komentarza kontrolującego), przekazujące zmiany do e-Decyzje;

o otrzymana prośba o wszczęcie postępowania będzie podstawą do dekretacji i procesowania sprawy w systemie SZPROT PLUS. W przypadku otrzymania

ponownej prośby o wszczęcie postępowania dla tego samego MRN i ewentualnie numeru pozycji informacja ta dołączana będzie do istniejącej sprawy w toku, w przypadku tego samego MRN i innej pozycji wszczynana będzie nowa sprawa;

 wygenerowanie w e-Decyzje decyzji;

o przesłanie do SO informacji, że decyzja została wygenerowana i wydana;

o zatwierdzenie zmian danych dokonanych na kopii na zgłoszeniu celnym;

o zmiana przez SO statusu zgłoszenia na pozwalający na dalszy przebieg procesu biznesowego w SO,

o przesłanie decyzji przez System SZPROT PLUS (w formie zmienionego zgłoszenia celnego) do obsługi poboru należności w ZEFIR2.

Np. proces odmowy korekty zgłoszenia celnego będzie mógł wyglądać następująco:

 złożenie dokumentu korekty przez podmiot;

 wygenerowanie przez SO (prawdopodobnie automatycznie) prośby o wszczęcie postępowania;

o ustawienie w SO (automatycznie) statusu zgłoszenia do decyzji, co powoduje zatrzymanie procesowania zgłoszenia w SO;

o przesłanie z SO do e-Decyzje danych identyfikujących zgłoszenie (MRN, pozycja towarowa, zakres danych do weryfikacji);

 wygenerowanie w e-Decyzje decyzji o odmowie korekty;

o przesłanie do SO informacji, że decyzja została wygenerowana;

o zmiana przez SO statusu zgłoszenia na pozwalający na dalszy przebieg procesu biznesowego w SO.

Po zwolnieniu towaru (na wniosek strony) weryfikacja danych przebiega w komponencie e-Decyzje według następujących kroków.

 w komponencie e-Decyzje będzie wywołanie usługi w SO, która na podstawie MRN spowoduje pobranie linku do wizualizacji zgłoszenia celnego;

 użytkownik w SO w roli prawnika na podstawie przesłanego linku uruchomi tryb edycji kopii zgłoszenia (status zgłoszenia w decyzji, zmiana danych i symulacja zmian);

 zatwierdzenie zmian kopii zgłoszenia przez prawnika powoduje;

o automatyczną zmianę statusu zgłoszenia do decyzji, co powoduje zatrzymanie procesowania zgłoszenia w SO;

o automatyczne wygenerowanie przez SO przekazania danych do wydania decyzji do e-Decyzje;

 wygenerowanie w e-Decyzje decyzji;

o przesłanie do SO informacji, że decyzja została wygenerowana i wydana;

o zmiana przez SO statusu zgłoszenia na pozwalający na dalszy przebieg procesu biznesowego w SO,

o jeśli wydano decyzję w przedmiocie długu celnego przesłanie tej decyzji przez system SZPROT PLUS (w formie zmienionego zgłoszenia celnego) do obsługi poboru należności w ZEFIR2.

3) NCTS2 - dwukierunkowa wymiana danych; zostanie zaimplementowana funkcjonalność umożliwiająca przekazanie informacji do Systemu SZPROT PLUS (modułu e-Decyzje) o udostępnieniu danych zgłoszenia w celu wydania odpowiedniego rozstrzygnięcia lub funkcjonalność umożliwiająca dostęp Użytkownika wewnętrznego Systemu SZPROT PLUS do danych w Systemie NCTS2 z poziomu GUI Systemu SZPROT PLUS; przesyłanie zmodyfikowanych danych dotyczących zgłoszeń do systemu NCTS2;

4) CEIDG – dwukierunkowa wymiana danych dotyczących koncesji i zezwoleń wydanych Podmiotom. Przesyłane będą dane z koncesji i zezwoleń wydawanych w obszarach akcyzy i hazardu, natomiast pobierane będą dane o koncesjach dla Podmiotu w zakresie obrotu różnymi wyrobami akcyzowymi, głównie wyrobami alkoholowymi i paliwami. Pobierane będą następujące dane: nr zezwolenia, data ważności, kto wydał, rodzaj wyrobu i miejsce wykonywania działalności z wykorzystaniem wyrobów;

5) ZEFIR2 – dwukierunkowa wymiana danych; przesyłanie danych o rozstrzygnięciach dotyczących zwrotów, zadłużenia decyzji wymiarowych, kwitów rozliczeń, danych koncesji i zezwoleń, za które należy uiścić opłatę, otrzymywanie danych o uiszczeniu należności i dacie ich uiszczenia;

6) OSOZ2 - dwukierunkowa wymiana danych; przesyłanie danych o rozstrzygnięciach dotyczących zabezpieczeń; pobieranie danych o zabezpieczeniach;

7) KRAG - dwukierunkowa wymiana danych; pobieranie danych o przemieszczeniach, zawieszeniach, wycofaniach z eksploatacji automatów; przekazywanie danych z koncesji zezwoleń, decyzji, zatwierdzonych regulaminów gier hazardowych;

8) ARI@DNA2 - udostępnianie danych dla procesów ETL;

9) CRKiD – przekazywanie i pobieranie spraw, dokumentów do sprawy, innych dokumentów oraz ich archiwizacja;

10) nowe komponenty SISC zgodnie z potrzebami zgłoszonymi na etapie analizy;

11) e-Rejestracja – pobieranie danych Podmiotów, osób fizycznych prowadzących działalność gospodarczą i osób fizycznych w trakcie procesu rejestracji/aktualizacji danych Podmiotu i/lub osoby fizycznej oraz Usługa subskrypcji tych danych, polegająca na automatycznym pobieraniu danych zaktualizowanych;

12) EOS-AEO – integracja w procesie wydawania pozwolenia AEO i zarządzania nim;

13) ZISAR PLUS - dwukierunkowa wymiana danych; przesyłanie danych dotyczących pozwoleń, koncesji, zezwoleń, decyzji wydanych Podmiotom; pobieranie informacji o Podmiocie wpływających na ocenę jego wiarygodności;

14) PDR PL/UE – dwukierunkowa wymiana danych; pobieranie i wysyłanie danych do/ze słowników;

15) SEAP PLUS – dwukierunkowa wymiana danych w zakresie komunikacji z Podmiotami;

16) SEED UE – dwukierunkowa wymiana danych; wysyłanie danych o wydanych, zmienionych, cofniętych zezwoleniach akcyzowych w Polsce, odbieranie danych w zakresie wydanych, zmienionych, cofniętych zezwoleniach w krajach unii europejskiej z wyjątkiem Polski.

System SZPROT PLUS musi umożliwiać procedowanie specyficznych wniosków z obszaru cła składanych również poprzez TP.

Wnioski i dokumenty złożone przez użytkownika zewnętrznego na Platformie PUESC muszą być zwizualizowane w Systemie SZPROT PLUS.

Architektura systemu SZPROT PLUS ma zapewnić spójność danych pomiędzy systemami SZPROT PLUS i PDR PL/UE, Jeśli dane biznesowe dostępne są w słownikach PDR PL/UE wówczas SZPROT PLUS ma korzystać z tych danych. Wszystkie wnioski, dokumenty dołączane i generowane w ramach prowadzonych postępowań, na poszczególnych krokach procesu stanowią akta sprawy i mają być dostępne dla Użytkowników wewnętrznych. Po zakończeniu sprawy mają one być przechowywane i archiwizowane w CRKiD. Użytkownik wewnętrzny Systemu SZPROT PLUS ma mieć możliwość pobrania i zwrócenia dokumentów w przypadku spraw zakończonych. Czynności związane z zarządzaniem dokumentami oraz sprawami w toku będą rejestrowane i przechowywane w systemie SZPROT PLUS, natomiast po zakończeniu sprawy w CRKiD. System SZPROT PLUS musi zapewnić możliwość dokonania wydruku poszczególnych dokumentów oraz całych akt sprawy zarówno w toku jak i zakończonych.

Możliwość wglądu i dołączenia do akt sprawy ma być również zrealizowana w zakresie dokumentów składowanych w CRKiD w ramach usługi e-Dokumenty.

Szczegółowe wymagania funkcjonalne i pozafunkcjonalne dla Systemu SZPROT PLUS zostały zdefiniowane w dalszej części niniejszego dokumentu.

Komponent Komunikacyjny wykonany w innym narzędziu pozwala na wypełnianie interaktywnych wniosków, które w trakcie wypełniania aktywnie komunikują się z danymi referencyjnymi SISC, aby wyeliminować dublowanie wniosków, składanie zbędnych dokumentów lub nieprawidłowo

wypełnionych formularzy. Rozwiązanie będzie umożliwiało podpisanie wypełnionych formularzy certyfikatem celnym, certyfikatem kwalifikowanym oraz profilem zaufanym e-PUAP.

3.3. Analiza otoczenia Projektu PUESC

W ramach analizy otoczenia zidentyfikowano następujące integracje zewnętrzne dla Projektu PUESC:

 Zrzeszenie Międzynarodowych Przewoźników Drogowych – System Safe TIR – integracja w ramach usługi Cyfrowa Odprawa zgodnie z UKC (w zakresie komponentu SISC NCTS2) – wymiana informacji dot. zamykanych karnetów TIR.

 Straż Graniczna – Zintegrowany System Ewidencji - integracja w ramach usługi eCG – wymiana danych dot. osób i pojazdów przekraczających granicę, a w zakresie pasów zielonych dane dot. deklarowanych towarów przewożonych przez podróżnych.

 Dostawca usług płatności elektronicznej – integracja z komponentem szybkich płatności elektronicznych w ramach usługi e-Płatności w zakresie formularzy (deklaracji, zgłoszeń, wniosków itp.), umożliwiająca klientowi uregulowanie w formie elektronicznej (na standardzie przelewu) w czasie rzeczywistym należności rozliczanych w komponencie ZEFIR 2 oraz otrzymanie przez klienta stanu rozliczenia w trybie on-line.

 PWPW – System SIBA (System Informacji o Banderolach Akcyzowych) – integracja w ramach usługi e-Banderole – w zakresie nabywania i rozliczania znaków akcyzy.

 ePUAP – integracja w zakresie przesyłania i odbierania komunikatów oraz Wykorzystania profilu zaufanego do uwierzytelniania użytkowników i podpisywania komunikatów,

 CEPIK 2.0 – System Organów Rejestracji Pojazdów – integracja w ramach usługi e-Wsparcie rejestracji samochodów osobowych w zakresie weryfikacji wywiązywania się z obowiązku podatkowego wynikającego z nabycia wewnątrzwspólnotowego/importu samochodu osobowego, w zakresie podatku akcyzowego.

 Rejestry Publiczne CEIDG – integracja w ramach usługi e-Decyzje w zakresie wymiany danych dotyczących koncesji i zezwoleń wydawanych w obszarach akcyzy i hazardu.

 Partnerzy KAS – integracja w ramach usługi Pojedyncze okno w obrocie towarowym z zagranicą – w zakresie wymiany informacji, danych, dokumentów związanych z obrotem towarowym z zagranicą.

 Systemy państw członkowskich – integracja w ramach usługi Cyfrowa Odprawa zgodnie z UKC w zakresie wymiany komunikatów w domenie wspólnej w systemach tranzytowym i wywozowym (NCTS i AES).

 Komisja Europejska (KE) – Systemy Centralne (np. CDMS, UUM&DS, COPIS, EBTI) – integracja w ramach usługi weryfikacji tożsamości i uprawnień użytkowników zarejestrowanych w SISC przy dostępie do usług centralnych dostarczanych/hostowanych przez KE oraz dostosowanie systemów krajowych w zakresie wymaganym przez architekturę rozwiązania centralnego (integracja hybrydowa).

 Węzeł Krajowy – integracja w ramach usługi potwierdzania tożsamości i podstawowego zestawu atrybutów autoryzacyjnych MDS (Minimum Data Set) przez zewnętrznych dostawców tożsamości. Potwierdzania tożsamości i MDS osób zarejestrowanych u zagranicznych dostawców tożsamości.

 Platforma Integracji Usług i Danych (PIUiD) – integracja w ramach usługobiorcy usług które zostaną udostępnione na PIUiD, np. rejestrów i systemów publicznych w ramach poprawy interoperacyjności usług.

W ramach Projektu wyżej wymienione integracje zostaną zrealizowane lub zmodyfikowane w ramach rozwoju Systemu Informacyjnego Skarbowo-Celnego.

Diagram otoczenia rozwiązania

Możliwość pozyskiwania danych ze źródeł zewnętrznych będzie cyklicznie monitorowana w ramach struktur projektowych i utrzymaniowych PUESC i jeśli pojawią się dodatkowe możliwości, będą one wykorzystywane w maksymalnym możliwym stopniu.

Budowane systemy muszą zapewniać gromadzenie danych dobrej jakości, co oznacza, że dane muszą spełniać szereg kryteriów, x.xx.: poprawność, kompletność, spójność i aktualność. Wymaga to implementacji mechanizmów umożliwiających zarządzanie jakością danych, weryfikację danych, wsparcie procesów wersjonowania, akceptacji, poprawy danych na różnych poziomach, w zależności od charakteru danych (informacja skierowana do klienta, dane referencyjne i słowniki, informacja wymieniana z Partnerami).

Zbieranie i aktualizacja danych na potrzeby świadczenia usług będą bazowały na udokumentowanych i wystandaryzowanych procesach i regułach zarządzania danymi, zawierających reguły kontroli, korekty, anonimizacji, wprowadzania i synchronizacji oraz integracji danych, których celem jest zapewnienie kompletności, spójności i jednolitości danych. Systemy teleinformatyczne, za pomocą których zbierane będą dane, będą zawierały - w ramach graficznego interfejsu użytkownika i interfejsów sieciowych reguły kontroli wprowadzanych danych (x.xx. w oparciu o słowniki) wraz z odpowiednimi objaśnieniami.

SISC będzie posiadał mechanizmy służące zbieraniu, monitorowaniu powszechności i ciągłości wykorzystania komponentów SISC (składających się na poszczególne usługi) i udostępnianiu tych informacji, tj. dostępności oraz wolumenu transakcji, a także innych statystyk dotyczących

wykorzystania usług. Badanie powszechności wykorzystania danej e-usługi poza wbudowanymi mechanizmami automatycznymi, o których mowa powyżej będzie badana w oparciu o dane statystyczne prezentowane przez GUS, a także w oparciu o własne analizy i statystyki KAS wykonywane przez wyspecjalizowane komórki organizacyjne KAS. Na podstawie ww. danych, jak również uzupełniająco na podstawie wygenerowanych przez administratorów systemów zapytań będą sporządzane cyklicznie zestawienia i sprawozdania obrazujące stopień wykorzystania usługi.

3.3.1.Architektura logiczna aplikacji

Zakres modernizacji SISC w ramach Projektu PUESC przedstawiono na rysunku poniżej określającym architekturę logiczną aplikacji – docelowy model komponentowy projektowanych usług.

Docelowy model komponentowy projektowanych usług

4. Elementy zamówienia

Główne elementy zamówienia:

 zaprojektowanie, budowa, dostarczenie i wdrożenie zmienionych lub nowych usług i funkcjonalności w postaci Platform Programowych dla Systemu SZPROT PLUS oraz Systemu SEAP PLUS (z zachowaniem ciągłości i trwałości dotychczasowych funkcjonalności Systemów SZPROT i ECIP/SEAP PL),

 dostarczenie dokumentacji Systemów - projektowej, użytkowej i powykonawczej,

 świadczenie Usługi Szkoleniowej,

 świadczenie Usługi Utrzymania oraz Usługi Rozwoju.

W szczególności zamówienie obejmuje:

 opracowanie i przekazanie Zamawiającemu dokumentu „Plan Umowy”, zgodnego z wymaganiami określonymi w Załączniku do Umowy;

 Dostarczenia w terminach określonych w Załączniku nr 3 do Umowy dokumentacji. Pełny wykaz dokumentacji Systemu, którą Wykonawca jest zobowiązany zaktualizować lub opracować a następnie dostarczyć, został określony w Załączniku nr 4 do Umowy, który to załącznik określa także wymagania, jakie ta dokumentacja powinna spełniać, jak również szablony, które powinny zostać wykorzystane przy opracowywaniu poszczególnych dokumentów;

 wytworzenie i dostarczenie przez Wykonawcę Platformy Programowej składającej się z:

a. Oprogramowania dedykowanego (zarówno w formie oprogramowania nowo wytworzonego jak i nowych wersji oprogramowania wytworzonego i dostarczonego w ramach Umów wcześniej zawartych),

b. Oprogramowania gotowego (zarówno w formie oprogramowania dodatkowego jak i nowych wersji oprogramowania dostarczonego dla Systemu w ramach Umów wcześniej zawartych),

dla środowisk testowego I, testowego II oraz produkcyjnego; zgodnie z założeniami harmonogramu określonego w Załączniku nr 3 do Umowy oraz wymaganiami Systemu, stanowiącymi Załącznik nr 1 do Umowy oraz odebranymi przez Zamawiającego produktami w postaci dokumentów;

 przeniesienie autorskich praw majątkowych do każdego z produktów oraz ich zmian wytworzonych w wyniku realizacji Umowy (na zasadach i polach eksploatacji określonych w Umowie) oraz, w zakresie wynikającym ze zmian dokonywanych w ramach świadczonych przez Wykonawcę usług rozwojowych, udzielenie licencji na wszystkie komponenty Platformy Programowej (Komponenty Systemowe) w ilości niezbędnej do realizacji wymagań dla wszystkich środowisk Systemu (testowego I, testowego II oraz produkcyjnego), obejmujących prawo do instalacji poprawek i nowszych wersji oprogramowania, wraz z utrzymaniem na zasadach określonych w Umowie;

 wdrożenie kompleksowych wersji Platformy Programowej, obejmujące: zainstalowanie dostarczonego oprogramowania, optymalizację oprogramowania systemowego i narzędziowego oraz uruchomienie usług i zasilenie struktur danych, w tym także migracja danych z istniejących systemów, zgodnie z wymaganiami określonymi w „Specyfikacji Wymagań dla Systemu”, a następnie przetestowanie wszystkich środowisk Systemu na docelowej infrastrukturze technicznej.

 zrealizowanie usługi szkolenia dla użytkowników po stronie Zamawiającego wg zasad, które określa Załącznik nr 5 do projektu Umowy.

 dostarczenie skonsolidowanej wersji oprogramowania na zakończenie Etapu I i II, a w Etapie III na zakończenie każdego z Okresów Rozliczeniowych Usługi Utrzymania;

 dostarczenie zaktualizowanej dokumentacji w formie elektronicznej przy każdej dostawie oprogramowania powodującej konieczność jej aktualizacji (w zakresie, w jakim dostawa ma wpływ na dotychczasowe zapisy w odnośnej dokumentacji), przy czym na zakończenie każdego z Etapów Wykonawca zobowiązany będzie do dostarczenia w formie papierowej jednego egzemplarza wszystkich zaktualizowanych dokumentów składających się na dokumentację systemową;

 świadczenie usług zapewniających utrzymanie i rozwój wdrożonych Systemów, w zakresie:

o usług utrzymania Systemu, w tym usuwania błędów w oprogramowaniu oraz asysty technicznej i konsultacji dotyczących oprogramowania, świadczonych w ramach usługi Service Desk – „Usługa Utrzymania”;

o modyfikacji oprogramowania i tworzenia nowych funkcjonalności w oprogramowaniu; wdrażania nowych wersji oprogramowania, realizacji zmian konfiguracji - „Usługa Rozwoju”.

4.1. Projekt Systemów

Wykonawca opracuje, na podstawie niniejszego dokumentu oraz wyników działań określonych w Załączniku nr 3 do Umowy, Projekt Systemu, oddzielnie dla komponentu SEAP PLUS i SZPROT PLUS, na który składać się będą następujące dokumenty:

 „Specyfikacja Procesów Biznesowych Systemu”, opracowana wg wymagań określonych przez Zamawiającego, zawartych w Załączniku nr 4 do Umowy,

 „Specyfikacja Wymagań dla Systemu”, opracowana wg wymagań określonych przez Zamawiającego, zawartych w Załączniku nr 4 do Umowy,

 „Projekt Infrastruktury Teleinformatycznej Systemu”, opracowany na podstawie wymagań określonych przez Zamawiającego, zawartych w Załączniku nr 4 do Umowy oraz w dalszej części niniejszego załącznika,

 „Projekt realizacji systemu informatycznego”,

 „Mapę wymagań”, wskazującą sposób realizacji wymagań zawartych w Specyfikacji Wymagań dla Systemu kontraktowych za pomocą funkcjonalności Systemu,

 „Model danych”, opracowana wg wymagań określonych przez Zamawiającego, zawartych w Załączniku nr 4 do Umowy,

 inne dokumenty, wyszczególnione w Załączniku nr 4 do Umowy.

4.2. Wytworzenie i dostawa Systemów

Wykonawca zobowiązuje się do zaprojektowania, zbudowania, uruchomienia, przetestowania, wdrożenia i gwarantowania prawidłowego funkcjonowania wszystkich środowisk Systemu SEAP PLUS oraz Systemu SZPROT PLUS na Infrastrukturze technicznej składającej się z Platformy Programowej, oraz z Platformy Sprzętowo-Programowej, udostępnionej przez Zamawiającego w ramach projektów PUESC.P1 oraz HARF na podstawie ITS Systemu SEAP PLUS oraz Systemu SZPROT PLUS - przygotowanego przez Wykonawcę.

Wykonawca wytworzy i dostarczy Systemy tj. Platformy Programowe obejmujące Oprogramowanie dedykowane oraz Oprogramowanie gotowe wchodzące w skład tych Platform, wraz z licencjami niezbędnymi do realizacji przedmiotu zamówienia. Systemy zostaną wytworzone na podstawie przygotowanej dla każdego z nich „Specyfikacji Wymagań dla Systemu” (Zamawiający dopuszcza scalanie za jego zgodą „Specyfikacji…” w jeden dokument, na warunkach określonych w Załączniku nr 4 do Umowy) oraz pozostałych odebranych przez Zamawiającego dokumentów, składających się na Projekt Systemów. Wykonawca dostarczy Zamawiającemu Systemy jako kompletne Platformy Programowe wraz z licencjami na systemy bazodanowe oraz pozostałe elementy Platform Programowych niezbędne do właściwego funkcjonowania wszystkich jego środowisk, a także kody źródłowe wytworzonego oprogramowania oraz dokumentację Systemów.

Na zakończenie etapów wskazanych w Umowie, Wykonawca zobowiązany jest do dostarczenia Zamawiającemu skonsolidowanej wersji oprogramowania.

W ramach dostawy Platformy Programowej dla środowisk testowego I, testowego II oraz produkcyjnego a także w ramach każdej dostawy oprogramowania wytworzonej w wyniku realizacji Usługi Rozwoju, Wykonawca zobowiązany jest do dostarczania Zamawiającemu wyliczenia liczby punktów funkcyjnych, dokonanego z zastosowaniem metodyki punktów funkcyjnych IFPUG (International Function Point Users Group) w wersji 4.1, z wykorzystaniem poniższego szablonu.

Wycena metodą Punktów Funkcyjnych (PF)

Zamawiający:	Ministerstwo Finansów
Wykonawca:
Numer Umowy:
Wycena dotyczy:
Skrócony opis przedmiotu wyceny:

Podsumowanie wyceny dokonanej metodą punktów funkcyjnych:
1. Ilość punktów funkcyjnych w funkcjach danych				0
1. Ilość punktów funkcyjnych w procesach EI				0
2. Ilość punktów funkcyjnych w procesach EO				0
4. Ilość punktów funkcyjnych w procesach EQ				0
Liczba surowych punktów funkcyjnych:				0
Liczba punktów funkcyjnych ogółem:				0
Uwaga:
Szczegółowa wycena zamieszczona została w tabelach szczegółowej wyceny
Osoba sporządzająca Załącznik do Zlecenia Zmiany	Imię i nazwisko	Data	Podpis

Szczegółowa wycena:

I. Funkcja danych (pliki ILF, EIF)

Lp.	Pozycja wyceny	L. operacji (dodawanie/ modyfikacja/usuwanie)	ILF/EIF	RET	DET		DET Razem	Liczba PF	Komentarz
Lp.	Pozycja wyceny	L. operacji (dodawanie/ modyfikacja/usuwanie)	ILF/EIF	RET	Etyk.	Pola	DET Razem	Liczba PF	Komentarz


Razem punktów funkcyjnych:								0

II. Procesy EI (Transakcje EI)

Lp.	Pozycja wyceny	L. operacji (dodawanie/ modyfikacja/usuwanie)	RET	FTR	DET		DET Razem	Liczba PF	Komentarz
Lp.	Pozycja wyceny	L. operacji (dodawanie/ modyfikacja/usuwanie)	RET	FTR	Etyk.	Pola	DET Razem	Liczba PF	Komentarz



Razem punktów funkcyjnych:								0

III. Procesy EO (Transakcje EO)

Lp.	Pozycja wyceny	L. operacji (dodawanie/ modyfikacja/usuwanie)	RET	FTR	DET		DET Razem	Liczba PF	Komentarz
Lp.	Pozycja wyceny	L. operacji (dodawanie/ modyfikacja/usuwanie)	RET	FTR	Etyk.	Pola	DET Razem	Liczba PF	Komentarz
1
2
Razem punktów funkcyjnych:								0

IV. Procesy EQ (Transakcje EQ)

Lp.	Pozycja wyceny	L. operacji (dodawanie/ modyfikacja/usuwanie)	RET	FTR	DET		DET Razem	Liczba PF	Komentarz
Lp.	Pozycja wyceny	L. operacji (dodawanie/ modyfikacja/usuwanie)	RET	FTR	Etyk.	Pola	DET Razem	Liczba PF	Komentarz



Razem punktów funkcyjnych:								0

Razem: 0

4.3. Udostępnienie Platformy Sprzętowo-Programowej

Udostępnienie docelowej Platformy Sprzętowo-Programowej przez Zamawiającego w ramach projektów PUESC.P1 oraz HARF nastąpi w terminie umożliwiającym Wykonawcy zainstalowanie,

przetestowanie i wdrożenie Systemów zgodnie z Harmonogramem Realizacji Zadań (Załącznik nr 3 do Umowy). przewidzianym w Umowie na Platformie Sprzętowo-Programowej, jednakże nie wcześniej niż w dniu 1.10.2018 r.

4.4. Wdrożenie Systemów

Wdrożenie Systemów dotyczy wyłącznie nowych i Kompleksowych wersji Platformy Programowej. Polegać będzie na zainstalowaniu, przetestowaniu oraz uruchomieniu do eksploatacji wszystkich środowisk Systemów na wskazanej przez Zamawiającego Platformie Sprzętowo-Programowej, zgodnie z Harmonogramem Realizacji Zadań (Załącznik nr 3 do Umowy). W ramach wdrożenia Systemów Wykonawca dokona zasilenia struktur danych, w tym wykona migrację określonych przez Zamawiającego zestawów danych. Ponadto Wykonawca skonfiguruje i uruchomi interfejsy Komunikacyjne w zakresie wszystkich usług, świadczonych lub konsumowanych przez System. Dopuszcza się możliwość, zależną od decyzji Zamawiającego, realizacji ww. czynności przez wyznaczonych przedstawicieli Zamawiającego w asyście Wykonawcy oraz z jego bezpośrednim wsparciem.

4.5. Usługa szkoleniowa

Szczegółowe wymagania dot. szkoleń zostały określone w Załączniku nr 5 do Umowy.

4.6. Testy Systemu

Szczegółowe zasady oraz sposób przeprowadzania Testów Systemu określa Załącznik nr 18 do Umowy.

4.7. Wykaz dokumentacji, którą będzie zobowiązany dostarczyć Wykonawca Systemów.

4.7.1. Dokumentacja zarządcza

Wykonawca opracuje, na podstawie zapisów Umowy oraz uzgodnień dokonanych z Zamawiającym, Plan Umowy, który określa szczegółowy harmonogram realizacji poszczególnych zadań związanych z wytworzeniem produktów Umowy, a także porządkuje oraz systematyzuje procedury, zasady współpracy, relacje oraz wzajemne zależności i obowiązki między Wykonawcą a Zamawiającym wynikające z Umowy. Szczegółowe wymagania dotyczące Planu Umowy określa Załącznik nr 2 do Umowy.

4.7.2. Dokumentacja techniczna i funkcjonalna

Wykonawca opracuje dokumentację techniczną i funkcjonalną z uwzględnieniem zapisów Umowy, niniejszego załącznika oraz określonych standardów technicznych.

Szczegółowe wymagania w zakresie dokumentacji Systemu określa Załącznik nr 4 do Umowy.

4.7.3.Dokumentowanie procesu wytwórczego oprogramowania Systemów SZPROT PLUS i SEAP PLUS

W ramach realizacji Umowy Wykonawca opracuje dokumentację procesu wytwórczego oprogramowania wg. standardu wymaganego dla systemów IT wykonywanych w resorcie finansów. Na tę dokumentację składają się:

• Plan zarządzania wymaganiami

• Specyfikacja procesów i wymagań biznesowych

• Specyfikacja wymagań systemu informatycznego

• Dokumentacja architektury systemu informatycznego

• Projekt interfejsu użytkownika

• Podręcznik administratora systemu

• Podręcznik użytkownika systemu

• Plan integracji systemu

• Plan testów systemu

• Raport z testów

• Plan wdrożenia systemu

• Plan zarządzania konfiguracją oprogramowania

• Projekt realizacji systemu informatycznego

• Specyfikacja migracji danych

• Pakiet kodów źródłowych

Szablony ww. dokumentów są zmieszczone w załączniku nr 4 do Umowy.

4.7.4. Dokumentacja eksploatacyjna i powykonawcza

Dokumentacja eksploatacyjna powinna zawierać procedury administracyjne (x.xx. instalacji, archiwizacji danych, administrowania Systemem), procedury awaryjne i użytkownika, instrukcje, regulaminy wraz z dokumentacją bezpieczeństwa.

Dokumentacja eksploatacyjna i powykonawcza, powinna zawierać opis rozwiązań zrealizowanych w dostarczonym Systemie, w tym x.xx.:

 Dokumentację funkcjonalną;

 Dokumentację techniczną powykonawczą;

 Podręczniki administratora technicznego oraz merytorycznego;

 Podręczniki użytkownika;

 Dokumentację powykonawczą infrastruktury technicznej Systemu;

 Dokumentację bezpieczeństwa.

W skład tej dokumentacji powinna również wchodzić dokumentacja eksploatacyjna i powykonawcza dla Oprogramowania gotowego dostarczonego przez Wykonawcę.

Przy każdej dostawie oprogramowania powodującej konieczność aktualizacji dokumentacji (w zakresie, w jakim dostawa ma wpływ na dotychczasowe zapisy w odnośnej dokumentacji) Wykonawca zobowiązany jest do dostarczenia zaktualizowanej dokumentacji oraz wykazu zmian w formie elektronicznej. Na zakończenie każdego z Etapów Wykonawca zobowiązany będzie do dostarczenia jednego egzemplarza skonsolidowanej wersji dokumentacji w formie papierowej.

Szczegółowe wymagania w zakresie dokumentacji Systemu określa Załącznik nr 4 do Umowy.

4.8. Świadczenie Usługi Utrzymania Systemu

Usługa Utrzymania Systemu realizowana będzie zgodnie z zapisami Umowy oraz zapisami zawartymi w niniejszym załączniku.

4.9. Świadczenie Usługi Rozwoju Systemu

Usługa Rozwoju Systemu realizowana będzie zgodnie z zapisami Umowy.

5. Wymagania funkcjonalne i pozafunkcjonalne dla Systemu SEAP PLUS

5.1. Przyjęta formuła opisu wymagań

Wszystkie trzy typy opisywanych wymagań zostały przedstawione w formie wykazu w układzie tabelarycznym. Taka forma pozwala przeglądać i identyfikować wymagania.

Wymagania funkcjonalne oraz pozafunkcjonalne, poza wykazem, zostały szczegółowo opisane w formie kart wymagań utworzonych oddzielnie dla każdego z nich.

5.2. Wykaz wymagań

Zarówno wykaz wymagań biznesowych, jak i wymagań funkcjonalnych i pozafunkcjonalnych, zawiera następujące informacje:

 Identyfikator – unikalny identyfikator wymagania w ramach danego obszaru funkcjonalności (rozdział 4.4)

 Opis – opis wymagania

Dodatkowo wymagania w wykazach zostały pogrupowane w ramach zidentyfikowanych obszarów, których dotyczą funkcjonalności.

5.3. Karta wymagań

Karty wymagań funkcjonalnych i pozafunkcjonalnych zawierają następujące informacje:

 Identyfikator – unikalny identyfikator wymagania w ramach danego obszaru funkcjonalności (rozdział 4.4);

 Opis – opis wymagania;

 Odniesienie do innego wymagania – wskazanie identyfikatora wymagania powiązanego;

 Odniesienie do Wymagania Biznesowego – wskazanie identyfikatora wymagania biznesowego, które będzie realizowane przez daną funkcjonalność;

 Uwagi – dodatkowe informacje, propozycje rozwiązań itp.

5.4. Identyfikator wymagania

Przyjęto zasadę, iż każdemu wymaganiu zostanie przypisany unikalny identyfikator w ramach danego typu wymagania o następującej składni:

o Wymagania biznesowe – SZPROT_WB_99 – gdzie:

 SZPROT lub SEAP – nazwa systemu

 WB – dwuznakowy kod oznaczający wymaganie biznesowe

 99 – dwucyfrowy kolejny numer wymagania począwszy od 01, 02 ….10, 11 itd.

o Wymagania funkcjonalne – SZPROT_WFXX_999 – gdzie:

 SZPROT lub SEAP – nazwa systemu

 WFXX – czteroznakowy kod, na który składają się, WF to kod oznaczający wymaganie funkcjonalne, a XX to kod oznaczający określony obszar funkcjonalności systemu

 999 – trzycyfrowy numer wymagania przypisywany co dziesięć np. 010, 020 …110 itd., w przypadku wymagań uszczegóławiających inne, są one numerowane, jako kolejne w ramach danej dziesiątki np. 011, 012 … 111, 112 itd. (pozwala to łatwo identyfikować powiązane wymagania)

o Wymagania pozafunkcjonalne – SZPROT_WPXX_999 – gdzie:

 SZPROT lub SEAP – nazwa systemu

 WPXX – czteroznakowy kod, na który składają się, WP to kod oznaczający wymaganie pozafunkcjonalne, a XX to kod oznaczający określony obszar funkcjonalności systemu 999 – trzycyfrowy numer wymagania przypisywany co dziesięć np. 010, 020 …110 itd., w przypadku wymagań uszczegóławiających inne, są one numerowane, jako kolejne w ramach danej dziesiątki np. 011, 012 … 111, 112 itd. (pozwala to łatwo identyfikować powiązane wymagania)

5.5. Wymagania biznesowe dla Systemu SEAP PLUS

W poniższej tabeli zamieszczono wykaz wymagań biznesowych.

Identyfikator	Opis wymagania
SEAP_WB_01	System ma być zbudowany w architekturze scentralizowanej i zapewniać rozbudowane mechanizmy zarządzania i konfiguracji.
SEAP_WB_02	System SEAP PLUS ma realizować wszystkie funkcjonalności dotychczasowego Systemu ECIP/SEAP PL, o ile Zamawiający nie wskazał inaczej.
SEAP_WB_03	System musi zapewniać obsługę komunikacji między Systemami dziedzinowymi a Klientami.
SEAP_WB_04	System musi zapewnić funkcjonalność Portalu PUESC.
SEAP_WB_05	System musi zapewnić funkcjonalność Centralnego Repozytorium Komunikatów i Dokumentów (CRKiD).
SEAP_WB_06	System musi umożliwiać tworzenie, modyfikowanie i publikowanie na Portalu PUESC interaktywnych formularzy webowych.
SEAP_WB_07	System musi umożliwiać osadzanie na Portalu Komponentów Komunikacyjnych dostarczanych przez zespoły projektowe lub utrzymaniowe pozostałych komponentów SISC.
SEAP_WB_08	System musi umożliwiać zarządzanie użytkownikami i ich uprawnieniami.
SEAP_WB_09	System musi zapewniać obsługę procesu przetwarzania komunikatów.

SEAP_WB_10	System musi zapewniać obsługę komunikacji niewizualnej.
SEAP_WB_11	System musi umożliwiać personalizację treści, usług i komunikatów publikowanych na Portalu PUESC.
SEAP_WB_12	System musi zapewniać tworzenie, konfigurację oraz modyfikację profili użytkowników.
SEAP_WB_13	System musi zapewniać realizację usługi e-Dokumenty, polegającej na przyjmowaniu od użytkowników oraz dalszym przetwarzaniu dokumentów wielokrotnego użytku.

5.6. Wymagania funkcjonalne dla Systemu SEAP PLUS

Wymagania funkcjonalne zostały pogrupowane w ramach obszarów, których dotyczą funkcjonalności. Ustalono następujące kody do stosowania, jako element składowy identyfikatora wymagania:

o Wymagania Funkcjonalne – Ogólne – WFOG

o Wymagania Funkcjonalne – Portal – WFPO

o Wymagania Funkcjonalne – Zarządzanie Systemem – WFZS

o Wymagania Funkcjonalne – Komunikacja Niewizualna– WFKN

o Wymagania Funkcjonalne – Rejestr Dokumentów – WFRD

5.6.1. Wykaz wymagań funkcjonalnych

Identyfikator	Opis
Wymagania funkcjonalne – Ogólne
SEAP_WFOG_010	Wykonawca zapewni w Systemie SEAP PLUS wszystkie funkcjonalności oraz wymagania pozafunkcjonalne aktualnie eksploatowanego Systemu SEAP, o ile w innych wymaganiach nie wskazano inaczej. Funkcjonalności obecnie eksploatowanego Systemu SEAP określone są w dokumentacji dla tego systemu. Poza zmianami wskazanymi w tym dokumencie Wykonawca może wykonać zmianę w stosunku do istniejącej funkcjonalności pod warunkiem akceptacji tej zmiany przez Zamawiającego.
SEAP_WFOG_020	System SEAP PLUS musi umożliwiać definiowanie przez administratora dla wybranych typów komunikatów funkcji ich kolejkowania w oddzielnej kolejce w wyznaczonych przez administratora przedziałach czasowych (wskazane dni tygodnia, wskazane przedziały godzin w ciągu doby). Musi istnieć możliwość wyłączenia funkcji dla dni wolnych i świąt. Dodatkowo, dla zakolejkowanych komunikatów musi istnieć możliwość zdefiniowania terminu ich chronologicznego zwolnienia z kolejki oraz określanie liczby komunikatów, jakie mają trafiać na kolejkę „produkcyjną” w określonym zakresie czasu.
SEAP_WFOG_030	System SEAP PLUS musi posiadać zoptymalizowane procesy komunikacyjne wchodzące w skład Platformy Programowej, służące do przesyłania komunikatów pomiędzy Klientami a Systemami dziedzinowymi.
SEAP_WFOG_040	System SEAP PLUS musi posiadać zoptymalizowane metody wchodzące w skład Platformy Programowej umożliwiające dostęp i korzystanie z CRKiD.

SEAP_WFOG_050	Wykonawca musi dostarczać komponenty Platformy Programowej będące Oprogramowaniem gotowym w najnowszych wersjach obowiązujących w dniu dostawy lub innych uzgodnionych z Zamawiającym oraz dostosować System do dostarczonego oprogramowania.
SEAP_WFOG_060	System SEAP PLUS musi posiadać co najmniej dwie bazy danych zoptymalizowane pod kątem obsługi danych odnoszących się do komunikatów w różnych cyklach życia.
SEAP_WFOG_070	System SEAP PLUS musi posiadać co najmniej dwa repozytoria plików zoptymalizowane pod kątem obsługi komunikatów w różnych cyklach życia.
SEAP_WFOG_080	System SEAP PLUS musi posiadać dodatkową usługę umożliwiającą przyjmowanie dokumentów lub komunikatów w czasie niedostępności głównych komponentów Systemu.
SEAP_WFOG_100	System SEAP PLUS musi umożliwiać konfigurowanie niezależnych komunikatów UPP oraz NPP dla poszczególnych typów komunikatów.
SEAP_WFOG_110	System SEAP PLUS musi umożliwiać Użytkownikowi wykorzystanie wcześniej wygenerowanego lub zaimportowanego dokumentu umożliwiając jego edycję w środowisku graficznym.
SEAP_WFOG_120	Wszystkie moduły Systemu SEAP PLUS, służące do prezentacji zasobów informacji związanych z realizacją przez Zamawiającego zadań publicznych, muszą spełniać wymagania WCAG 2.0 (Web Content Accessability Guidelines) na poziomie A i AA.
SEAP_WFOG_130	System SEAP PLUS musi umożliwiać synchroniczne odpytywanie Systemów dziedzinowych o dane przez Użytkowników zalogowanych i niezalogowanych .
SEAP_WFOG_140	System SEAP PLUS musi umożliwiać dołączanie do komunikatów dowolnej liczby załączników o rozmiarze do 15MB, w formatach określonych przez administratora dla danego komunikatu
SEAP_WFOG_150	Wykonawca Systemu SEAP PLUS opracuje i przekaże Wykonawcom Systemów dziedzinowych wytyczne dotyczące budowy Komponentów Komunikacyjnych, które będą osadzane na portalu PUESC.
SEAP_WFOG_160	System musi obsługiwać komunikaty XML wysyłane przez Użytkowników.
SEAP_WFOG_180	System musi zapewniać integrację z usługą e-Płatności i umożliwiać jej wywoływanie z poziomu Portalu PUESC.

SEAP_WFOG_200	System musi udostępniać dla potrzeb Komponentów Komunikacyjnych tworzonych przez innych wykonawców dedykowane API udostępniające zestaw metod systemu SEAP PLUS, poprzez które Komponenty Komunikacyjne uzyskają dostęp do określonych atrybutów i funkcjonalności dostarczanych przez te metody.
Wymagania funkcjonalne – Portal
SEAP_WFPO_010	Wykonawca przygotuje i dostarczy do akceptacji Zamawiającego projekt graficzny Portalu PUESC. Wygląd Portalu, tematu graficznego i wszystkich Portletów na nim osadzonych powinien być dostosowany i zgodny z wizualizacją graficzną przekazaną Wykonawcy przez Zamawiającego. Jakiekolwiek odstępstwo od dostarczonej wizualizacji graficznej może być zrealizowane wyłącznie za zgodą Zamawiającego.
SEAP_WFPO_011	Na podstawie zaakceptowanego przez Xxxxxxxxxxxxx projektu graficznego Wykonawca przygotuje i dostarczy interaktywną makietę graficzną, w tym prezentującą sposób wyświetlania treści na urządzeniach mobilnych, uwzględniającą przekazane przez Zamawiającego motywy graficzne.
SEAP_WFPO_012	Portal PUESC zostanie przygotowany zgodnie z zatwierdzoną przez Zamawiającego makietą.
SEAP_WFPO_013	Wykonawca musi przygotować Portal PUESC w sposób umożliwiający wyświetlanie także na urządzeniach mobilnych, zgodnie z zatwierdzoną przez Zamawiającego makietą.
SEAP_WFPO_014	Portal PUESC musi zostać zbudowany na zasadzie responsywności (RWD) w warstwie prezentacyjnej, tzn. wielkość i układ elementów portalu musi dostosowywać się do aktualnej rozdzielczości ekranu (w tym gwarantować obsługę w urządzeniach mobilnych).
SEAP_WFPO_020	System SEAP PLUS musi umożliwiać Użytkownikowi dla obiektów typu „Dokument” wykonywanie operacji co najmniej takich jak: Otwórz, Zapisz, Edytuj, Usuń, Podpisz, Drukuj, Wyślij, Przekaż, Opłać, Udostępnij, itd.
SEAP_WFPO_021	System SEAP PLUS musi umożliwiać Użytkownikowi wywołanie dla wskazanego dokumentu lub sprawy menu z operacjami możliwymi do uruchomienia na tym obiekcie i uruchomienie wybranej operacji.
SEAP_WFPO_030	System SEAP PLUS musi umożliwiać Użytkownikowi wywoływanie operacji zbiorczych dla wielu wskazanych dokumentów lub spraw zarejestrowanych w CRKiD.
SEAP_WFPO_040	System SEAP PLUS musi umożliwiać w ramach operacji możliwych do wywołania na poszczególnych typach dokumentów i spraw złożonych w repozytorium, wywołanie sparametryzowanego Portletu, zdalnej metody (np. wywołanie WebService, wywołanie procedury składowanej) itp.

SEAP_WFPO_041	System SEAP PLUS musi przekazywać do wywoływanej operacji dowolne parametry stałe, parametry z profilu zalogowanego Użytkownika, atrybuty z metadanych opisujących obiekt oraz wartości pobierane z dokumentu XML ścieżkami xPath lub inne wartości.
SEAP_WFPO_050	System SEAP PLUS musi umożliwiać Użytkownikowi na Portalu PUESC upload wielu dokumentów w jednej operacji tzw. multiupload.
SEAP_WFPO_060	System SEAP PLUS musi informować Użytkownika o przekroczonym limicie dla zasobu przeznaczonego dla użytkownika na dokumenty do wysyłki i formularze robocze i na życzenie Użytkownika informować o aktualnym stanie wykorzystania tego zasobu
SEAP_WFPO_070	System SEAP PLUS musi umożliwiać Użytkownikowi wypełnianie dokumentu za pomocą tzw. wizarda dla dokumentu.
SEAP_WFPO_071	System SEAP PLUS musi umożliwiać Użytkownikowi wybranie formy wypełnienia dokumentu (formularz tradycyjny lub tzw. wizard dla dokumentu).
SEAP_WFPO_080	System SEAP PLUS musi umożliwiać Użytkownikowi manualne lub automatyczne (bezpośrednio po utworzeniu dokumentu) uruchomienie na dokumencie lub sprawie graficznego tzw. wizarda dla operacji.
SEAP_WFPO_090	System SEAP PLUS musi umożliwiać Użytkownikowi pojedyncze oraz grupowe usuwanie wybranych dokumentów z widoku Użytkownika.
SEAP_WFPO_091	System SEAP PLUS musi umożliwiać Użytkownikowi pojedyncze oraz grupowe przywracanie dokumentów usuniętych wcześniej przez tego Użytkownika.
SEAP_WFPO_092	System SEAP PLUS musi umożliwiać Użytkownikowi pojedyncze oraz grupowe usuwanie wybranych spraw z widoku Użytkownika.
SEAP_WFPO_093	System SEAP PLUS musi umożliwiać Użytkownikowi pojedyncze oraz grupowe przywracanie usuniętych wcześniej przez tego Użytkownika spraw.
SEAP_WFPO_100	System SEAP PLUS prezentuje Użytkownikowi wygląd i funkcjonalności Portalu PUESC zdefiniowane dla profilu, roli lub grupy, do jakiej dany Użytkownik przynależy.
SEAP_WFPO_101	System SEAP PLUS musi umożliwiać obsługę jednego Użytkownika w zakresie kilku profili, ról i grup, do których jest przypisany.
SEAP_WFPO_102	System SEAP PLUS musi zalogowanemu Użytkownikowi ustawiać i wyświetlać automatycznie domyślny profil i rolę Użytkownika oraz pozwolić Użytkownikowi na zmianę profilu i roli bez potrzeby ponownego logowania.

SEAP_WFPO_103	System SEAP PLUS umożliwi zalogowanemu Użytkownikowi posiadającemu więcej niż jeden profil lub rolę ustawienie lub zmianę profilu i roli domyślnej w oknie parametrów konfiguracyjnych konta Użytkownika.
SEAP_WFPO_104	System SEAP PLUS musi dostosowywać dostępność i widoczność formularzy na Portalu PUESC do określonych profili, grup i ról użytkowników przypisanych do schematów tych komunikatów.
SEAP_WFPO_110	System SEAP PLUS musi umożliwiać Użytkownikowi dostęp do formularzy (wytworzonych w oparciu o Portlety oraz o narzędzie do budowy formularzy) i do wykonania na nich operacji zgodnie z przypisanymi uprawnieniami.
SEAP_WFPO_120	System SEAP PLUS musi umożliwić zalogowanemu Użytkownikowi definiowanie widoczności, kolejności i szerokości kolumn w poszczególnych rejestrach dokumentów i spraw lub w innych zdefiniowanych przez Zamawiającego obiektach dostępnych dla administratora, np. zarządzaniu formularzami, schematami itp. i zapamiętywanie tych ustawień.
SEAP_WFPO_121	System SEAP PLUS musi umożliwiać Użytkownikowi resetowanie ustawień własnych poszczególnych obiektów i Komponentów Komunikacyjnych do ustawień domyślnych zdefiniowanych przez administratora.
SEAP_WFPO_122	System SEAP PLUS musi umożliwiać Użytkownikowi tworzenie i zapamiętywanie oddzielnych widoków (w formie podzakładek) w Moich Dokumentach w zakładkach Odebrane i Wysłane oraz w rejestrze Moje Sprawy z podziałem na System dziedzinowy i usługę, w ramach których dany dokument/sprawa funkcjonuje.
SEAP_WFPO_130	System SEAP PLUS musi umożliwiać nawigację pomiędzy poszczególnymi sprawami w widoku podglądu szczegółów pojedynczej sprawy bez potrzeby opuszczania tego widoku.
SEAP_WFPO_140	System SEAP PLUS musi umożliwiać Użytkownikowi wprowadzenie etykiet własnych dla dowolnych spraw, dokumentów, formularzy dostępnych dla Użytkownika.
SEAP_WFPO_141	System SEAP PLUS musi prezentować zalogowanemu Użytkownikowi etykietę własną obiektów typu dokument, sprawa, formularz, niezależnie od prezentacji nazwy systemowej tych obiektów.
SEAP_WFPO_150	System SEAP PLUS musi umożliwiać Użytkownikowi bezpośredni podgląd treści wskazanego dokumentu.

SEAP_WFPO_160	System SEAP PLUS musi umożliwiać Użytkownikowi po wybraniu numeru sprawy w widoku rejestru dokumentów przełączenie się na widok szczegółów tej sprawy (sprawy, do której przynależy dokument).
SEAP_WFPO_170	System SEAP PLUS musi umożliwiać powrót z widoku szczegółów dokumentu lub sprawy do poprzedniego widoku (z którego został on wywołany), z zachowaniem ustawionych filtrów, na ostatnio wybraną pozycję z listy.
SEAP_WFPO_180	System SEAP PLUS musi umożliwić zalogowanemu użytkownikowi HelpDesk SISC przy użyciu jednego Portletu wyszukiwanie Użytkowników po nazwisku i imieniu, adresie email, numerze identyfikacyjnym, a następnie wykonanie dla wyszukanego Użytkownika dowolnych operacji serwisowych.
SEAP_WFPO_190	System SEAP PLUS musi umożliwiać Użytkownikowi utworzenie konta na Portalu PUESC przy użyciu danych wykorzystywanych do uwierzytelniania w celu skorzystania z profilu zaufanego e-PUAP oraz konta podatnika z portalu podatkowego. System SEAP PLUS musi akceptować tożsamość użytkownika potwierdzoną przez profil zaufany lub portal podatkowy.
SEAP_WFPO_191	System SEAP PLUS musi umożliwiać Użytkownikowi podpięcie pod jego konto usług uwierzytelniania świadczonych przez profil zaufany e-PUAP oraz portal podatkowy.
SEAP_WFPO_192	System SEAP PLUS musi umożliwiać Użytkownikowi odpięcie z jego konta usług uwierzytelniania świadczonych przez profil zaufany e-PUAP oraz portal podatkowy.
SEAP_WFPO_193	System SEAP PLUS musi umożliwić Użytkownikowi zalogowanie się do Portalu PUESC za pośrednictwem usług uwierzytelniających profilu zaufanego e-PUAP oraz portalu podatkowego.
SEAP_WFPO_200	System SEAP PLUS musi umożliwiać zalogowanemu Użytkownikowi udostępnianie na określony czas innym Użytkownikom swoich formularzy roboczych lub dokumentów do wysyłki.
SEAP_WFPO_201	System SEAP PLUS musi umożliwiać Użytkownikowi cofnięcie lub przedłużenie udostępnienia formularzy roboczych lub dokumentów do wysyłki.
SEAP_WFPO_202	System SEAP PLUS musi sygnalizować wizualnie na Portalu PUESC zalogowanemu Użytkownikowi, że inny Użytkownik udostępnił, przedłużył udostępnianie lub cofnął udostępnianie formularzy roboczych lub dokumentów do wysyłki.

SEAP_WFPO_203	System SEAP PLUS musi wysyłać Użytkownikowi na jego adres email informację o tym, że inny Użytkownik mu udostępnił, przedłużył udostępnianie lub cofnął udostępnienie formularzy roboczych lub dokumentów do wysyłki.
SEAP_WFPO_210	System SEAP PLUS musi umożliwiać w ramach danego profilu i roli wyświetlanie spersonalizowanych treści w zależności od dokonanego przez Użytkownika wyboru kategorii i/lub tagów użytych do oznaczenia treści na Portalu PUESC.
SEAP_WFPO_220	System SEAP PLUS w zakładce Moje konto w kontekście Podmiotu musi prezentować podstawowe dane Podmiotu.
SEAP_WFPO_230	System SEAP PLUS musi umożliwiać włączenie/wyłączenie walidowania dokumentu XML, który jest uploadowany przez Użytkownika.
SEAP_WFPO_250	System SEAP PLUS musi otwierać i umożliwiać edycję zapisanych (w nieaktualnej wersji) formularzy roboczych w ostatniej publikowanej jego wersji.
SEAP_WFPO_251	System SEAP PLUS musi zastępować w formularzach ulubionych nieaktualną (zdjętą z publikacji) wersję formularza jego aktualną wersją.
SEAP_WFPO_260	System SEAP PLUS musi umożliwiać propagację określonych treści na dwóch środowiskach (zewnętrznym i wewnętrznym) bez konieczności ich oddzielnego publikowania.
SEAP_WFPO_270	Interfejs Użytkownika Systemu SEAP PLUS musi być oznakowany zgodnie z systemem identyfikacji wizualnej beneficjenta oraz zasadami przewidzianymi dla programów polityki spójności 2014-2020 w zakresie informacji i promocji.
SEAP_WFPO_280	Wykonawca jest zobowiązany do opracowania dokumentu określającego Wymagania dla Komponentu Komunikacyjnego. Wymagania te obejmą x.xx. standard techniczny dla Komponentu Komunikacyjnego, sposób jego implementacji i wizualizacji, podstawowy zestaw metod dostępnych w ramach usług pośredniczących (tzw. dedykowane API), procedurę audytu, procedurę testowania integracyjnego, wytyczne w zakresie user experience, responsywności, wytycznych konsorcjum W3C WCAG. Wykonawca na zlecenie Zamawiającego jest zobowiązany do każdorazowego przeprowadzenia audytu dostarczanego Komponentu Komunikacyjnego pod kątem wydajności, zgodności z przekazanymi wytycznymi i bezpieczeństwem, chyba, że Zamawiający podejmie decyzję o przeprowadzeniu audytu przez przeszkolonych przedstawicieli Zamawiającego w asyście lub bez asysty Wykonawcy. Wykonawca jest zobowiązany do opracowania procedury audytu dla Komponentów Komunikacyjnych oraz przeszkolenia Zamawiającego w zakresie przeprowadzania takiego audytu.
SEAP_WFPO_300	W systemie SEAP PLUS musi być udostępniona funkcjonalność Newslettera, z możliwością ustawiania wysyłki do grup użytkowników, wskazywania daty wysyłki, układania kolejki wiadomości przeznaczonych do wysłania.
SEAP_WFPO_310	System SEAP PLUS musi umożliwiać obsługę wielojęzycznych kanałów syndykacyjnych

SEAP_WFPO_320	System SEAP PLUS musi posiadać mechanizm umożliwiający administratorowi konfigurowanie wyświetlanych treści prezentowanych we wszystkich wytworzonych przez Wykonawcę elementach Portalu PUESC.
Wymagania funkcjonalne – Zarządzanie Systemem
SEAP_WFZS_010	System SEAP PLUS musi umożliwiać administratorowi technicznemu i dziedzinowemu skonfigurowanie operacji możliwych do wywołania na poszczególnych typach dokumentów i spraw złożonych w repozytorium.
SEAP_WFZS_011	System SEAP PLUS musi umożliwiać definiowanie przez administratorów parametrów stałych, parametrów z profilu zalogowanego użytkownika, atrybutów z metadanych opisujących obiekt oraz wartości pobieranych z dokumentu XML ścieżkami xPath lub innych wartości dla poszczególnej operacji.
SEAP_WFZS_012	System SEAP PLUS musi umożliwiać administratorowi skonfigurowanie warunków wymaganych do wywołania operacji możliwej do wykonania na dokumencie lub sprawie.
SEAP_WFZS_020	System SEAP PLUS musi posiadać mechanizm umożliwiający administratorowi konfigurację uploadu.
SEAP_WFZS_030	System SEAP PLUS musi posiadać mechanizm umożliwiający administratorowi definiowanie wielkość zasobu przeznaczonego dla użytkownika na dokumenty do wysyłki i formularze robocze.
SEAP_WFZS_040	System SEAP PLUS musi posiadać graficzne narzędzie zintegrowane z Portalem PUESC, umożliwiające administratorowi technicznemu zbudowanie następujących kreatorów: - Wizard dla dokumentu, który umożliwi wypełnienie „Krok po kroku” dokumentu zalogowanemu Użytkownikowi - Wizard dla operacji, umożliwiającego wykonanie operacji lub sekwencji operacji skonfigurowanych dla wybranego typu dokumentu lub sprawy
SEAP_WFZS_041	System SEAP PLUS musi umożliwiać administratorowi technicznemu i dziedzinowemu skonfigurowanie wizardów i przypisanie ich dla wybranego typu dokumentu, operacji lub sekwencji operacji.
SEAP_WFZS_050	System SEAP PLUS musi umożliwiać definiowanie i obsługę różnych profili, ról i grup użytkowników.
SEAP_WFZS_060	System SEAP PLUS musi umożliwiać administratorowi przypisywanie schematów komunikatów do profili, ról i grup użytkowników.
SEAP_WFZS_070	System SEAP PLUS musi posiadać możliwość zarządzania przez administratora formularzami wytworzonymi w oparciu o Portlety oraz poprzez narzędzie do budowy formularzy w jednolity sposób.

SEAP_WFZS_080	System SEAP PLUS musi umożliwić administratorowi definiowanie domyślnej widoczności kolumn w poszczególnych zakładkach Portletów rejestru dokumentów i spraw lub w innych zdefiniowanych obiektach, z podziałem na profile i role Użytkowników.
SEAP_WFZS_090	System SEAP PLUS musi umożliwiać administratorowi technicznemu wyszukiwanie informacji o historii operacji oraz stanach określonego dokumentu i ich wizualizację w formie raportu z opcją załączenia do tego raportu przedmiotowego dokumentu. System SEAP PLUS ma umożliwiać wyszukiwanie dokumentu wg zadanych kryteriów ( w szczególności: numeru własnego dokumentu, numeru MRN, ARC, numeru nadwozia, adresu email, nazwiska, ID SISC itp w okresie od..do).
SEAP_WFZS_100	System SEAP PLUS musi umożliwiać administratorowi technicznemu lub dziedzinowemu skonfigurowanie transformaty pośredniczącej w mapowaniu danych z formularza wytworzonego w narzędziu do budowy formularzy.
SEAP_WFZS_110	System SEAP PLUS w widoku konsoli procesów musi oznaczać odpowiednim znacznikiem wszystkie procesy, które zostały skutecznie obsłużone przez administratora w trybie serwisowym.
SEAP_WFZS_111	Konsola administracyjna powinna obsługiwać identyfikatory biznesowe wskazane przez administratora dziedzinowego.
SEAP_WFZS_120	Wszystkie zmiany dokonywane przez administratora w Systemie SEAP PLUS (np. w zarządzaniu schematami, formularzami, itp.) muszą być logowane w Systemie. Obok nazwy użytkownika musi zostać zalogowany rodzaj wykonanej zmiany oraz jej czas.
SEAP_WFZS_130	System SEAP PLUS musi umożliwiać administratorowi technicznemu lub dziedzinowemu zarządzanie wersjonowaniem formularzy.
SEAP_WFZS_140	System SEAP PLUS musi umożliwiać administratorowi technicznemu lub dziedzinowemu kopiowanie wybranych parametrów konfiguracyjnych pomiędzy poszczególnymi schematami oraz samych schematów.
SEAP_WFZS_150	System SEAP PLUS musi umożliwiać administratorowi technicznemu lub dziedzinowemu automatyczne mapowanie pól formularza z identycznymi nazwami w schemacie. Musi istnieć możliwość zmiany mapowania w dowolnej kolejności.
SEAP_WFZS_160	System SEAP PLUS musi umożliwiać administratorowi technicznemu konfigurację procesów biznesowych BPM w sposób nie wymagający od użytkownika posiadania specjalistycznej wiedzy programistycznej.
SEAP_WFZS_170	Wykonawca musi dokonać przeglądu i optymalizacji procesów biznesowych BPM.

SEAP_WFZS_180	Wykonawca musi dokonać przeglądu i dostosować interfejs graficzny klienta - narzędzia dostępu do CRKiD, do wymagań uzgodnionych na etapie analizy.
SEAP_WFZS_190	System SEAP PLUS musi posiadać moduł umożliwiający administratorowi technicznemu biznesową oraz techniczną weryfikację stanu usług powiązanych systemów.
SEAP_WFZS_200	System SEAP PLUS w widoku konsoli procesów musi prezentować nazwę schematu wg. którego wysłany został komunikat oraz kanał wysyłki.
SEAP_WFZS_201	System SEAP PLUS w widoku konsoli procesów w podglądzie szczegółów kroku procesu musi prezentować w czytelny sposób efekt działania tego kroku, wartości parametrów, z którymi krok został wyzwolony, wynik kroku procesu oraz wartości zmiennych zwrócone po wykonaniu tego kroku.
SEAP_WFZS_202	System SEAP PLUS w widoku konsoli procesów musi umożliwiać prezentowanie uzgodnionego z Zamawiającym maksymalnego zestawu danych w kolumnach, przy czym użytkownik musi mieć możliwość ograniczenia widoczności części zbędnych dla siebie kolumn.
SEAP_WFZS_210	W systemie musi zostać wytworzony mechanizm autoryzacji Użytkowników wewnętrznych. Autoryzacja musi się odbywać w komponencie autoryzacyjnym dostarczonym przez Wykonawcę, chyba że Zamawiający zleci integrację z innym komponentem autoryzacyjnym.
SEAP_WFZS_220	System SEAP PLUS musi umożliwiać konfigurację integracji z innymi systemami Zamawiającego.
SEAP_WFZS_230	W systemie SEAP PLUS musi być zapewnione zarządzanie subskrypcją treści Portalu PUESC.
SEAP_WFZS_231	W systemie SEAP PLUS musi być zapewnione narzędzie pozwalające na tworzenie szablonów Newsletterów umożliwiających wysyłanie wiadomości w formacie tekstowym lub HTML.
SEAP_WFZS_240	System musi umożliwiać osadzanie na Portalu PUESC Komponentów Komunikacyjnych dostarczanych przez zespoły projektowe lub utrzymaniowe pozostałych komponentów SISC.
SEAP_WFZS_250	System musi umożliwiać administratorowi systemu obejście standardowego przepływu komunikatu z wykorzystaniem GUI
SEAP_WFZS_251	System musi umożliwiać administratorom systemu centralne sterowanie parametrami i zachowaniem systemu z wykorzystaniem GUI
Wymagania funkcjonalne – Komunikacja Niewizualna

SEAP_WFKN_010	System SEAP PLUS musi obsługiwać przesyłanie i przetwarzanie dokumentów i komunikatów „opakowanych” XML transportowym jako alternatywną metodę przesyłania komunikatów pomiędzy Klientami a Systemami dziedzinowymi.
SEAP_WFKN_020	System SEAP PLUS musi posiadać usługi niewizualne do wpisywania danych do metryki dokumentu i sprawy.
SEAP_WFKN_030	System SEAP PLUS musi umożliwiać pobranie z CRKiD dokumentów istniejącymi metodami niewizualnymi, dodatkowo ograniczając wynik do dokumentów skorelowanych z konkretnym Systemem dziedzinowym.
SEAP_WFKN_040	System SEAP PLUS musi posiadać metody niewizualne umożliwiające pobieranie dokumentów z CRKiD w zadanym okresie czasu liczonym w datach, minutach i sekundach.
SEAP_WFKN_050	System SEAP PLUS musi umożliwiać uprawnionym Użytkownikom odpytanie metodami niewizualnymi o dane Podmiotu, listę zarejestrowanych reprezentacji i zakres uprawnień oraz zwrócić żądaną listę.
SEAP_WFKN_060	System SEAP PLUS musi zawierać konfigurowalny komponent umożliwiający komunikację synchroniczną i niesynchroniczną, posiadający funkcjonalność konwertowania żądań REST na usługi SOAP.
SEAP_WFKN_070	System SEAP PLUS musi posiadać metody niewizualne umożliwiające dołączanie dokumentu „wielokrotnego użytku” do sprawy w CRKID oraz zmianę statusu dokumentu.
SEAP_WFKN_080	System SEAP PLUS w przypadku odrzucenia komunikatu obok odsyłanego obecnie dokumentu informującego o odrzuceniu (NPP), musi odsyłać także komunikat, który został odrzucony.
Wymagania funkcjonalne – Rejestr Dokumentów
SEAP_WFRD_010	System SEAP PLUS musi automatycznie tworzyć metrykę dokumentu i metrykę sprawy skorelowaną odpowiednio z tymi obiektami w CRKiD.
SEAP_WFRD_020	System SEAP PLUS musi umożliwiać przypisanie wielu numerów spraw do jednego dokumentu.

SEAP_WFRD_030

System SEAP PLUS musi posiadać funkcjonalność dodawania przez użytkownika dokumentów wielokrotnego użytku z wykorzystaniem każdego dostępnego kanału komunikacyjnego, z możliwością nieobligatoryjnego wskazania kontenera, do którego użytkownik chce przypisać dany dokument (np. pełnomocnictw, pozwoleń, certyfikatów etc.

- zdefiniowanych przez administratora SEAP) oraz możliwością umieszczenia adnotacji do przekazywanego dokumentu.

System SEAP PLUS musi posiadać metody niewizualne umożliwiające zarządzanie tymi dokumentami przez Użytkowników wewnętrznych oraz przez systemy dziedzinowe.

Dokumenty powinny mieć statusy: zweryfikowany i niezweryfikowany. Statusy mają być zmieniane po pierwszej weryfikacji przez System dziedzinowy.

SEAP_WFRD_040

W Systemie SEAP z poziomu administracyjnego musi być możliwe tworzenie kontenerów grupujących dodawane przez użytkownika dokumenty wielokrotnego użytku.

5.6.2. Szczegóły wymagań funkcjonalnych

5.6.2.1. Wymagania funkcjonalne - Ogólne

Identyfikator	SEAP_WFOG_010
Opis	Wykonawca zapewni w Systemie SEAP PLUS wszystkie funkcjonalności oraz wymagania pozafunkcjonalne aktualnie eksploatowanego Systemu SEAP, o ile w innych wymaganiach nie wskazano inaczej. Funkcjonalności obecnie eksploatowanego Systemu SEAP określone są w dokumentacji dla tego systemu. Poza zmianami wskazanymi w tym dokumencie Wykonawca może wykonać zmianę w stosunku do istniejącej funkcjonalności pod warunkiem akceptacji tej zmiany przez Zamawiającego.
Odniesienie do innego wymagania	SEAP_WP_020
Odniesienie do Wymagania Biznesowego	SEAP_WB_02
Uwagi	Dla potrzeb postępowania udostępniona zostanie dokumentacja Systemu SEAP, w zakresie możliwym do opublikowania w domenie publicznej.

Identyfikator	SEAP_WFOG_020
Opis	System SEAP PLUS musi umożliwiać definiowanie przez administratora dla wybranych typów komunikatów funkcji ich kolejkowania w oddzielnej kolejce w wyznaczonych przez administratora przedziałach czasowych (wskazane dni tygodnia, wskazane przedziały godzin w ciągu doby). Musi istnieć możliwość wyłączenia funkcji dla dni wolnych i świąt. Dodatkowo, dla zakolejkowanych komunikatów musi istnieć możliwość zdefiniowania terminu ich chronologicznego zwolnienia z kolejki oraz określanie liczby komunikatów, jakie mają trafiać na kolejkę „produkcyjną” w określonym zakresie czasu.
Odniesienie do innego wymagania
Odniesienie do Wymagania Biznesowego	SEAP_WB_03
Uwagi	Sposób realizacji wymagania zostanie uzgodniony z Zamawiającym w trakcie prac analitycznych

Identyfikator	SEAP_WFOG_030
Opis	System SEAP PLUS musi posiadać zoptymalizowane procesy komunikacyjne wchodzące w skład Platformy Programowej, służące do przesyłania komunikatów pomiędzy Klientami a Systemami dziedzinowymi.
Odniesienie do innego wymagania
Odniesienie do Wymagania Biznesowego	SEAP_WB_03
Uwagi	Należy wytworzyć nowe i przebudować istniejące procesy tak, aby zapewnić optymalizację mającą na celu poprawę wydajności Systemu, uproszczenie zarządzania procesami, ograniczenie liczby kroków w procesach i wyników zapisywanych w bazie. Elementy w procesach powinny korzystać z usług wspólnych, należy unikać ich redundancji, należy stosować podprocesy, ilość zmiennych procesowych nie może być nadmiarowa. Sposób realizacji wymagania zostanie szczegółowo uzgodniony z Zamawiającym w trakcie prac analitycznych.

Identyfikator	SEAP_WFOG_040
Opis	System SEAP PLUS musi posiadać zoptymalizowane metody wchodzące w skład Platformy Programowej, umożliwiające dostęp i korzystanie z CRKiD.
Odniesienie do innego wymagania
Odniesienie do Wymagania Biznesowego	SEAP_WB_05
Uwagi	Należy wytworzyć nowe jednolite API CRKiD, które będzie wykorzystywane zarówno przez sam System SEAP PLUS i jego komponenty, jak i przez Systemy dziedzinowe. Należy przebudować wszystkie Komponenty Komunikacyjne i mechanizmy Systemu ECIP/SEAP PL w celu uniknięcia redundancji metod korzystających z CRKiD. Sposób realizacji wymagania zostanie szczegółowo uzgodniony z Zamawiającym w trakcie prac analitycznych.

Identyfikator	SEAP_WFOG_050
Opis	Wykonawca musi dostarczać komponenty Platformy Programowej będące Oprogramowaniem gotowym w najnowszych wersjach obowiązujących w dniu dostawy lub innych uzgodnionych z Zamawiającym oraz dostosować System do dostarczonego oprogramowania.
Odniesienie do innego wymagania
Odniesienie do Wymagania Biznesowego	SEAP_WB_01

Uwagi

Dostosowanie systemu dotyczy wszystkich istniejących komponentów, w tym również Portletów i formularzy. Portlety i formularze mają zachować dotychczasowe funkcjonalności, chyba że zmiana tej funkcjonalności wynika z niniejszego dokumentu lub innych załączników do Umowy.

Sposób realizacji wymagania zostanie szczegółowo uzgodniony z Zamawiającym w trakcie prac analitycznych.

Identyfikator	SEAP_WFOG_060
Opis	System SEAP PLUS musi posiadać co najmniej dwie bazy danych zoptymalizowane pod kątem obsługi danych odnoszących się do komunikatów w różnych cyklach życia.
Odniesienie do innego wymagania
Odniesienie do Wymagania Biznesowego	SEAP_WB_05
Uwagi	Celem realizacji wymagania jest umożliwienie bardziej optymalnego wykorzystania zasobów poprzez podział bazy na obszar operacyjny i analityczny, tak aby prowadzone przeszukiwania danych nie zakłócały zapisów i odwrotnie. W przypadku konsoli procesów administrator musi mieć możliwość określenia zakresu danych oraz czasu, po którym dane będą przenoszone do bazy analitycznej Sposób realizacji wymagania zostanie szczegółowo uzgodniony z Zamawiającym w trakcie prac analitycznych.

Identyfikator

SEAP_WFOG_070

Opis

System SEAP PLUS musi posiadać co najmniej dwa repozytoria plików zoptymalizowane pod kątem obsługi komunikatów w różnych cyklach życia.

Odniesienie do innego wymagania

Odniesienie do Wymagania Biznesowego

SEAP_WB_05

Uwagi

Celem realizacji wymagania jest umożliwienie bardziej optymalnego wykorzystania zasobów poprzez podział repozytorium na obszar operacyjny i analityczny, tak aby prowadzone przeszukiwania komunikatów nie zakłócały zapisów i odwrotnie.

Sposób realizacji wymagania zostanie szczegółowo uzgodniony z Zamawiającym w trakcie prac analitycznych.

Identyfikator	SEAP_WFOG_080
Opis	System SEAP PLUS musi posiadać dodatkową usługę umożliwiającą przyjmowanie dokumentów lub komunikatów w czasie niedostępności głównych komponentów Systemu.
Odniesienie do innego wymagania
Odniesienie do Wymagania Biznesowego	SEAP_WB_01 , SEAP_WB_03
Uwagi	System ma posiadać dodatkowe funkcjonalności, które umożliwią w przypadku niedostępności głównych komponentów Systemu przyjmowanie od użytkowników zewnętrznych dokumentów i komunikatów zgodnych z dedykowaną dla nich schemą. Dla przyjętych w tym trybie dokumentów lub komunikatów System SEAP PLUS musi wystawiać użytkownikom potwierdzenie przyjęcia dokumentu lub komunikatu w trybie awaryjnym. Funkcjonalność musi umożliwiać przekazywanie tak przyjętych dokumentów lub komunikatów do właściwych Systemów dziedzinowych.

Identyfikator

SEAP_WFOG_100

Opis

System SEAP PLUS musi umożliwiać konfigurowanie niezależnych komunikatów UPP oraz NPP dla poszczególnych typów komunikatów.

Odniesienie do innego wymagania

Odniesienie do Wymagania Biznesowego

SEAP_WB_01

Uwagi

System SEAP PLUS ma umożliwiać administratorowi technicznemu lub dziedzinowemu utworzenie wielu różnych typów dokumentów UPP i NPP (różniących się w treści i wyglądzie) oraz przypisanie ich do poszczególnych typów komunikatów i dokumentów biznesowych. Przesyłane do Klientów komunikaty UPP i NPP będą mogły być różne w zależności od typu dokumentu dla którego są potwierdzeniem.

Identyfikator	SEAP_WFOG_110
Opis	System SEAP PLUS musi umożliwiać Użytkownikowi wykorzystanie wcześniej wygenerowanego lub zaimportowanego dokumentu umożliwiając jego edycję w środowisku graficznym.
Odniesienie do innego wymagania
Odniesienie do Wymagania Biznesowego	SEAP_WB_04
Uwagi	Sposób realizacji wymagania zostanie szczegółowo uzgodniony z Zamawiającym w trakcie prac analitycznych.

Identyfikator	SEAP_WFOG_120
Opis	Wszystkie moduły Systemu SEAP PLUS, służące do prezentacji zasobów informacji związanych z realizacją przez Zamawiającego zadań publicznych, muszą spełniać wymagania WCAG 2.0 (Web Content Accessability Guidelines) na poziomie A i AA.
Odniesienie do innego wymagania	BRAK
Odniesienie do Wymagania Biznesowego

Uwagi

Wymagania WCAG 2.0 (Web Content Accessability Guidelines) na poziomie A i AA zostały określone w załączniku nr 4 „Wymagania Web Content Accessibility Guidelines (WCAG 2.0) dla systemów teleinformatycznych w zakresie dostępności dla osób niepełnosprawnych” do RKRI.

Identyfikator	SEAP_WFOG_130
Opis	System SEAP PLUS musi umożliwiać synchroniczne odpytywanie Systemów dziedzinowych o dane przez Użytkowników zalogowanych i niezalogowanych .
Odniesienie do innego wymagania
Odniesienie do Wymagania Biznesowego
Uwagi	Odpytywanie będzie dotyczyło Systemów: ZEFIR2 w zakresie PZAS, NCTS2 w zakresie zapytania o numer MRN, OSOZ2 w zakresie zapytania o saldo. Sposób realizacji wymagania zostanie szczegółowo uzgodniony z Zamawiającym w trakcie prac analitycznych.

Identyfikator	SEAP_WFOG_140
Opis	System SEAP PLUS musi umożliwiać dołączanie do komunikatów dowolnej liczby załączników o rozmiarze do 15MB, w formatach określonych przez administratora dla danego komunikatu.
Odniesienie do innego wymagania
Odniesienie do Wymagania Biznesowego

Document Metadata

Table of Contents

Charakterystyka i wymagania Systemów

Document Metadata