EWD Elektroniczna Wymiana Dokumentów

Transkrypt

1 Zakład Ubezpieczeń Społecznych Warszawa, ul. Szamocka 3, 5 EWD Elektroniczna Wymiana Dokumentów Specyfikacja wejścia wyjścia wersja 2.1

2 Elektroniczna Wymiana Dokumentów Specyfikacja wejścia wyjścia wersja 2.1 data wydania Strona 2 z 49

3 SPIS TREŚCI 1. Wstęp Cel dokumentu Odbiorcy dokumentu Podstawy prawne opracowania Struktura dokumentu Notacja opisu struktury danych Historia zmian w kolejnych wersjach dokumentu Wersja utworzenie dokumentu, Wersja Wersja U U 2. Założenia konstrukcji KEDU Struktura KEDU zaprezentowana w notacji graficznej Nagłówek KEDU Identyfikator KEDU Cechy KEDU Zestaw dokumentów płatnika Dokument płatnika Opis cechy Korekta OCR Opis błędu Białe znaki Znaki dopuszczalne w KEDU Zakres informacyjny KEDU Zakres informacyjny elementów organizacyjnych KEDU Komunikacja w systemie Elektronicznej Wymiany Dokumentów (EWD) Zestawienie sesji z serwerem komunikacyjnym Wysyłanie przesyłek do Pobieranie przesyłek z Specyfikacja usług webowych w systemie EWD Operacja WyslijPrzesylke Komunikaty wykorzystywane podczas operacji WyslijPrzesylke Operacja PobierzPotwierdzenie Komunikaty wykorzystywane podczas operacji PobierzPotwierdzenie Operacja PobierzIndexPrzesylek Komunikaty wykorzystywane podczas operacji PobierzIndexPrzesylek Operacja CheckTransmision Komunikaty wykorzystywane podczas operacji CheckTransmision Tworzenie przesyłek w ramach Systemu Elektronicznej Wymiany Dokumentów Nazwy typów przesyłek Przesyłka do Tworzenie przesyłek z wykorzystaniem kryptografii CMS Tworzenie przesyłek z wykorzystaniem kryptografii XMLEnc/XMLSign Przesyłka z Tworzenie przesyłek z wykorzystaniem kryptologii CMS Tworzenie przesyłek z wykorzystaniem kryptologii XMLEnc/XMLSign Wydruki formularzy ubezpieczeniowych Słownik użytych skrótów i pojęć...46 Spis rysunków...48 Spis tabel...49 Strona 3 z 49

4 1. Wstęp 1.1. Cel dokumentu Celem opracowania jest przedstawienie zasad wymiany informacji pomiędzy systemem informatycznym a programami interfejsowymi przeznaczonymi do przekazywania elektronicznych dokumentów ubezpieczeniowych do Odbiorcy dokumentu Niniejsze opracowanie przeznaczone jest przede wszystkim dla osób opracowujących oprogramowanie interfejsowe do przekazywania elektronicznych dokumentów ubezpieczeniowych do Podstawy prawne opracowania Ustawa z dnia 17 lutego 2005r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. Nr 64, poz. 565, z 2006 r. z późn. zm.), Ustawa z dnia 13 października 1998r. o systemie ubezpieczeń społecznych (Dz. U. z 2007 r. Nr 11, poz. 74, Nr 17, poz. 95, Nr 21, poz. 125), Ustawa z dnia 18 września 2001r. o podpisie elektronicznym (Dz. U. Nr 130, poz z 2002r. z późn. zm.), Rozporządzenie Rady Ministrów z dnia 11 października 2005 r. w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz. U. Nr 212 poz. 1766), Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005r. w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania (Dz. U. Nr 217, poz. 1836), Rozporządzenie Ministra Pracy i Polityki Społecznej z dnia 3 lipca 2001r. w sprawie warunków, jakie muszą spełnić płatnicy składek przekazujący dokumenty ubezpieczeniowe w formie dokumentu elektronicznego poprzez teletransmisję danych (Dz. U. Nr 73, poz. 774, z 2003 r. Nr 217, poz. 2137), 1.4. Struktura dokumentu Wstęp Rozdział 2 Rozdział 3 Rozdział 4 Zawiera informacje dotyczące celu dokumentu, jego struktury oraz stosowanej notacji Prezentuje założenia konstrukcji KEDU Prezentuje podstawowe informacje o komunikacji z systemem elektronicznym Prezentuje opis usług webowych stosowanych w systemie elektronicznym Strona 4 z 49

5 Rozdział 5 Rozdział 6 Załącznik 1 Załącznik 2 Załącznik 3 Załącznik 4 Prezentuje zasady tworzenia przesyłek w ramach systemu elektronicznego Prezentuje opis wydruków formularzy ubezpieczeniowych Zawiera zakres informacyjny dokumentów ubezpieczeniowych przekazywanych do drogą elektroniczną Zawiera specyfikację WSDL usług webowych oferowanych przez Zawiera schemat XML dokumentu potwierdzenia generowanego przez w systemie Elektronicznej Wymiany Dokumentów Zawiera wzory wydruków formularzy ubezpieczeniowych 1.5. Notacja opisu struktury danych Do szczegółowego opisu struktury dokumentów ubezpieczeniowych zwanych Kolekcją Elektronicznych Dokumentów Ubezpieczeniowych użyto standardu o nazwie XML Schema Definition. Jest to standard opublikowany przez organizację W3C (World Wide Web Consortium) służący do definiowania struktur dokumentów XML za pomocą sformalizowanego języka definicji schematów. Schemat XML ma postać dokumentu tekstowego (zazwyczaj zapisanego w pliku z rozszerzeniem xsd) zawierającego definicję typów i struktur danych dla dokumentów XML, które opisuje. Schemat XML wykorzystywany jest przez parser XML do weryfikacji poprawności struktury tych dokumentów. Sam schemat wewnętrznie także jest dokumentem XML. Do przygotowania przesyłki w Systemie Elektronicznej Wymiany Dokumentów (EWD) użyto następujących standardów: SOAP SOAP (ang. Simple Object Application Protocol) jest protokołem bazującym na standardzie XML. Protokół SOAP pozwala aplikacjom na komunikację przez Internet. Standard SOAP jest opracowywany przez W3C ( Obecna wersja SOAP to 1.2. Protokół SOAP definiuje formaty komunikatów, sposoby wysyłania komunikatów i odbierania odpowiedzi, kodowania danych w języku XML oraz gramatykę XML służącą do: określania nazw metod, definiowania typów parametrów i zwracanych wartości oraz opisu typów. Specyfikacja protokołu dopuszcza stosowanie różnych protokołów internetowych jako protokołów transportowych. Obecnie najczęściej wykorzystywanym protokołem jest HTTP. Strona 5 z 49

6 WSDL - WSDL (ang. Web Services Description Language). Plik WSDL to dokument XML, opisujący zbiór komunikatów SOAP MTOM - oraz sposób wymiany tych komunikatów. MTOM (ang. Message Transmission Optimization Mechanism) jest rozszerzeniem SOAP 1.2 pozwalającym na efektywne przesyłanie treści binarnych. Standard jest opracowywany przez W3C ( CMS - CMS (ang. Cryptographic Message Syntax) jest standardem pozwalającym na ochronę wiadomości. Standard określa kopertę dla zaszyfrowanych i podpisanych danych. Standard jest opracowywany przez Internet Engineering Task Force. Ostatnia specyfikacja standardu zawarta jest w RFC 3852 ( XML Signature - XML Signature (zwane także XMLSign) jest standardem definiującym kodowanie xml dla sygnatur dokumentów elektronicznych. Standard jest opracowywany przez W3C ( XML Encryption - XML Encryption (zwane także XMLEnc) jest standardem definiującym kodowanie xml dla zaszyfrowanych dokumentów. Standard jest opracowywany przez W3C ( SSL - SSL (ang. Secure Socket Layer) protokół aplikacyjny stosowany w celu zabezpieczenia poufności i integralności danych. Standard opisany został na stronie TLS - TLS protokół aplikacyjny stosowany w celu zabezpieczenia poufności i integralności danych. TLS jest następcą SSL 3.0. Standard TLS został opisany w RFC 2246 ( ZIP - Zip jest to algorytm kompresji bezstratnej. Więcej informacji na temat algorytmu można znaleźć w serwisie BZIP2 - BZIP2 jest to algorytm kompresji bezstratnej. Więcej informacji na temat algorytmu można znaleźć w serwisie LZMA - LZMA (ang. Lempel-Ziv-Markov chain-algorithm) jest to algorytm kompresji bezstratnej. Więcej informacji na temat algorytmu można znaleźć w serwisie Historia zmian w kolejnych wersjach dokumentu Wersja utworzenie dokumentu, Wersja 1.1 Zmiana struktury kedu usunięcie dokumentu ZCZA w związku ze zmianą rozporządzenia określającego wzory zgłoszeń do ubezpieczeń, Dodanie rozdziału opisującego wydruki formularzy ubezpieczeniowych. Strona 6 z 49

7 Wersja 2.1 Zmiana struktury kedu nowego dokumentu ZSWA oraz zmiany w istniejących dokumentach w związku ze zmianą rozporządzenia określającego wzory zgłoszeń do ubezpieczeń, Zdefiniowanie nowego prologu XML kolekcji dokumentów, który zawiera: o odwołanie do nazwy pliku nowego schematu XML "kedu_3.xsd", o nową przestrzeń nazw " o wartość atrybutu wersja_schematu="1". 2. Założenia konstrukcji KEDU W systemie EWD istnieje konieczność tworzenia i wysyłania do dokumentów tekstowych będących elektronicznym odzwierciedleniem formularzy ubezpieczeniowych XXX. Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych KEDU przedstawia logiczną strukturę informacji zebranych z formularzy oraz dodaje do niej te elementy organizacyjne, które są niezbędne z punktu widzenia procesów przetwarzania tych informacji Struktura KEDU zaprezentowana w notacji graficznej Struktura KEDU zaprezentowano na diagramie znajdującym się poniżej. Rysunek 1 Struktura KEDU Kolekcja Dokumentów Ubezpieczeniowych składa się z czterech zasadniczych części: 1. Prologu XML, którego rolą jest wskazanie definicji typu dokumentu (dla parsera XML), określenie wersji standardu XML oraz strony kodowej, w jakiej kolekcja jest zapisana. Prolog XML kolekcji może wyglądać następująco: Strona 7 z 49

8 <?xml version="1.0" encoding="utf-8"?> <KEDU wersja_schematu="1" xmlns=" xmlns:xsi=" xsi:schemalocation=" kedu_3.xsd">... </KEDU> 2. Nagłówka KEDU zawierającego informacje organizacyjne; 3. Sekwencji cech KEDU zawierających dowolne cechy kolekcji (element nie jest wymagany); 4. Ciała kolekcji, na które składa się co najmniej jeden dokument. Nagłówek KEDU, sekwencja cech KEDU oraz ciało kolekcji zawarte są w głównym elemencie dokumentu XML (ang. root element), czyli są zagnieżdżone między znacznikami <KEDU>...</KEDU>. Ponadto zestaw zawiera grupę atrybutów zestawu. Atrybuty KEDU Grupę atrybutów KEDU przedstawiono na poniższym diagramie. Rysunek 2 Atrybuty KEDU Obecnie grupa atrybutów KEDU zawiera tylko jeden atrybut: wersja_schematu. Jest to wersja schematu XML, na podstawie którego zbudowany został dokument KEDU. Tabela 1. Atrybuty KEDU Nazwa atrybutu Opis Sposób wypełnienia wersja_schematu Wersja schematu XML. Dla bieżącej wersji KEDU przyjmuje stałą wartość 1. Wprowadzić aktualną wersję schematu XML dla KEDU Nagłówek KEDU Budowę nagłówka KEDU zaprezentowano na diagramie poniżej. Strona 8 z 49

9 Rysunek 3 Nagłówek KEDU W nagłówku KEDU znajdują się informacje organizacyjne dotyczące całej kolekcji. Opis wartości pól nagłówka został zaprezentowany w poniższej tabeli. Tabela 2. Nagłówek KEDU Nazwa elementu Opis Sposób wypełnienia program Element złożony, patrz Tabela 3. patrz Tabela 3. ID_KEDU Identyfikator złożony data_utworzenia_kedu id_nadawcy_id_kedu id_miejsca_utworzenia Data nadania ID_KEDU przez, pobierana z identyfikatora KEDU. Data ta jest zapisywana w ID_KEDU wg czasu GMT Adres KSI numeryczny aplikacji (parametr aplikacji), w której utworzono ID_KEDU Adres KSI numeryczny miejsca (TJO lub OPD ), w którym utworzono ID_KEDU Budowę elementu program zaprezentowano na kolejnym diagramie. Rysunek 4 Program W elemencie program przewidziano miejsce na umieszczenie informacji identyfikujących program, który wygenerował KEDU. Wypełnianie tych informacji przez oprogramowanie generujące KEDU jest wymagane, w celu umożliwienia identyfikacji źródła ewentualnych błędów KEDU po jego przesłaniu do. Strona 9 z 49

10 Tabela 3. Program Nazwa elementu Opis Sposób wypełnienia producent Ciąg znaków identyfikujący producenta program (dla Wprowadzić nazwę producenta programu programu Płatnik przyjmuje wartość Asseco Poland SA ). symbol Ciąg znaków identyfikujący Wprowadzić nazwę programu program (dla programu Płatnik przyjmuje wartość Płatnik ). wersja Ciąg znaków identyfikujący wersję programu (dla programu Płatnik numer bieżącej wersji programu w formacie: XYYZZZ, np ). Wprowadzić wersję programu Identyfikator KEDU Budowę identyfikatorów KEDU zaprezentowano na diagramie poniżej. Rysunek 5 Identyfikatory KEDU W KEDU stosuje się dwa rodzaje identyfikatorów: - identyfikator prosty, będący liczbą naturalną, - identyfikator złożony. Identyfikator złożony składa się z kilku części, które przedstawiono w poniższej tabeli: Tabela 4. Części identyfikatora złożonego Nazwa Opis Max długość typ_obiektu Identyfikowanymi obiektami mogą być: plik, wsad, KEDU, dokument elektroniczny. Lista ta może ulec w przyszłości rozszerzeniu. Dopuszczalne wartości: 2 PW Plik WWW, PN Plik Nośnik, WS WSad, KD KEDU, DP Dokument Płatnika, ZA Zadanie Archiwizacji. id_stanowiska Adres KSI numeryczny komputera, na którym pracuje generator identyfikatorów. 24 Strona 10 z 49

11 Nazwa Opis Max długość data_utworzenia_id Czas nadania identyfikatora (z dokładnością do 14 sekundy, format RRRRMMDDGGMMSS). nr_kolejny Liczba - Numer kolejny w ramach trzech 7 poprzednich wartości. znak_kontrolny Znak wykorzystywany przy ręcznym wprowadzaniu identyfikatorów. Zapewnia wykrycie błędu; nie zapewnia korekty błędu Cechy KEDU Budowę sekwencji cech KEDU zaprezentowano na diagramie poniżej. Rysunek 6 Cechy KEDU Wewnątrz sekwencji umożliwiono umieszczenie dowolnej liczby cech, czyli dowolnych informacji powiązanych logicznie z kolekcją dokumentów. Opis elementu cecha przedstawiono w rozdziale Opis cechy Zestaw dokumentów płatnika UWAGA! System Informatyczny aktualnie nie uwzględnia obsługi zestawów dokumentów w KEDU, zatem kolekcja powinna zawierać jedynie pojedyncze dokumenty. Definicję zestawu dokumentów płatnika zamieszczono na diagramie poniżej. Rysunek 7 Zestaw dokumentów płatnika Strona 11 z 49

12 Zestaw dokumentów płatnika ma budowę trójdzielną, na którą składa się: - blok identyfikatorów płatnika zawierający identyfikatory płatnika pochodzące z bazy danych; - sekwencja cech zestawu zawierająca dowolne informacje związane z zestawem; Zawartość zestawu, czyli właściwa jego treść składająca się z dokumentów ubezpieczeniowych płatnika. Ponadto zestaw zawiera grupę atrybutów zestawu. Atrybuty Zestawu Budowę grupy atrybutów zestawu dokumentów przedstawiono na diagramie poniżej. Rysunek 8 Atrybuty zestawu Grupa atrybutów zestawu zawiera identyfikator zestawu i identyfikator płatnika oraz dane identyfikacyjne płatnika, do którego należy zastaw dokumentów. Strona 12 z 49

13 Tabela 5. Atrybuty zestawu Nazwa atrybutu Opis Sposób wypełnienia id_zestawu Identyfikator zestawu w kolekcji Nie wypełniać id_platnika Identyfikator płatnika Nie wypełniać P_Nip Numer NIP płatnika Nie wypełniać P_Regon Numer Regon płatnika Nie wypełniać P_NazwaSkr Nazwa Skrócona płatnika Nie wypełniać P_Pesel Numer PESEL płatnika Nie wypełniać P_RodzDok Rodzaj dokumentu płatnika, Nie wypełniać przyjmuje wartości: 1 Dowód osobisty, 2 Paszport. P_SeriaNrDok Seria i Numer Dokumentu Nie wypełniać P_Nazwisko Nazwisko płatnika Nie wypełniać P_Imie Imię pierwsze płatnika Nie wypełniać Identyfikacja płatnika Budowę bloku technicznych identyfikatorów płatnika pokazuje poniższy diagram. Rysunek 9 Identyfikacja płatnika Blok identyfikacji płatnika może zawierać techniczne identyfikatory płatnika pochodzące z baz danych płatnika i. Tabela 6. Identyfikacja płatnika Nazwa elementu Opis Sposób wypełnienia id_pl_systemowy Liczba, techniczny identyfikator Nie wypełniać płatnika w bazie danych płatnika. id_pl_ Liczba, techniczny identyfikator płatnika w Nie wypełniać, pole wypełniane przez System Informatyczny Cechy zestawu Budowę sekwencji cech zestawu przedstawiono na diagramie poniżej. Rysunek 10 Cechy zestawu Strona 13 z 49

14 Wewnątrz sekwencji umożliwiono umieszczenie dowolnej liczby cech, czyli dowolnych informacji powiązanych logicznie z zestawem dokumentów. Opis elementu cecha przedstawiono w rozdziale Opis cechy Dokument płatnika Lista dopuszczalnych dokumentów płatnika została zaprezentowana na diagramie poniżej. Rysunek 11 Dokumenty płatnika Dokumentem płatnika może być dokument powstały jako obraz wprowadzonych formularzy XXX. Budowa dokumentów Schemat budowy dokumentu został zamieszczony na poniższych diagramach. Pierwszy z diagramów pokazuje budowę dokumentów rozliczeniowych i zgłoszeniowych płatnika, natomiast drugi budowę dokumentów zgłoszeniowych ubezpieczonego. Strona 14 z 49

15 Rysunek 12 Budowa dokumentów płatnika Wszystkie dokumenty płatnika mają jednakową budowę, czyli składają się z: - atrybutów dokumentu, - nagłówka dokumentu, - bloku identyfikatorów płatnika, zawierającego identyfikatory płatnika pochodzące z baz danych, - sekwencji cech dokumentu, zawierającej dowolne informacje związane z dokumentem, - treści odpowiedniego formularza, - stopki dokumentu. Strona 15 z 49

16 Rysunek 13 Budowa dokumentów ubezpieczeniowych Wszystkie dokumenty ubezpieczonego mają jednakową budowę, czyli składają się z: - atrybutów dokumentu, - nagłówka dokumentu, - bloku identyfikatorów płatnika, zawierającego identyfikatory płatnika pochodzące z baz danych, - bloku identyfikatorów ubezpieczonego, zawierającego identyfikatory ubezpieczonego pochodzące z baz danych, - sekwencji cech dokumentu, zawierającej dowolne informacje związane z dokumentem, - treści odpowiedniego formularza, - stopki dokumentu. Atrybuty dokumentu Budowę grupy atrybutów dokumentu przedstawiono na diagramie poniżej. Rysunek 14 Atrybuty dokumentu Grupy atrybutów dokumentu zawiera obecnie tylko jeden atrybut: identyfikator dokumentu. Strona 16 z 49

17 Tabela 7. Atrybuty dokumentu Nazwa atrybutu id_dokumentu Opis Identyfikator dokumentu w kolekcji lub w zestawie Sposób wypełnienia Nie wypełniać Nagłówek Dokumentu Budowa nagłówka dokumentu została zaprezentowana na diagramie poniżej. Rysunek 15 Nagłówek dokumentu Nagłówek dokumentu płatnika ma budowę podobną do nagłówka kompletu dokumentów płatnika. Szczegółowy sposób nadawania wartości polom nagłówka został zaprezentowany w poniższej tabeli. Tabela 8. Nagłówek dokumentu Nazwa elementu Opis Sposób wypełnienia id_dp_źródło Identyfikator złożony. Jest to identyfikator pliku, nadawany na Serwerze Komunikacyjnym lub na stacji roboczej (dla plików dostarczanych na nośniku); dla dokumentów wewnętrznych identyfikator generowany jest na SDE Strona 17 z 49

18 Nazwa elementu Opis Sposób wypełnienia id_dp_pozycja Identyfikator prosty. Numer kolejny dokumentu w pliku źródłowym data_nadania_dp data_przyjęcia_źródła _w_ksi miejsce_przyjęcia_źró dła_w_ksi data_nadania_id_dp_ źródło miejsce_nadania_id_ DP_źródło id_nadawcy_id_dp_źr ódło data_nadania_id_dp_ pozycja miejsce_nadania_id_ DP_pozycja id_nadawcy_id_dp_p ozycja kanał_wprowadzenia status_dp wersja_biblioteki_wery fikacji W przypadku dokumentów przesłanych do KSI drogą teletransmisji jest to data rozpoczęcia transmisji (zgodnie z czasem GMT), zapisana w nazwie przesłanego pliku. W przypadku dokumentów dostarczonych na nośniku - jest to data skopiowania pliku z nośnika. Data przyjęcia pliku źródłowego (zakończenia transmisji) pobierana z nazwy pliku źródłowego. Adres KSI numeryczny miejsca (TJO ), w którym przyjęto dokumenty źródłowe (pliki, dokumenty papierowe). Data nadania id_dp_źródło przez. Data przyjęcia pliku przez. Adres KSI numeryczny miejsca (TJO ), w którym nadano id_dp_źródło Adres KSI numeryczny stanowiska/skanera/aplikacji/uży tkownika (itd.), na którym utworzono id_dp_źródło Data nadania id_dp_pozycja przez. Data przetwarzania (DataNow). Adres KSI numeryczny miejsca (TJO ), w którym nadano id_dp_pozycja. Adres KSI numeryczny stanowiska/skanera/aplikacji/uży tkownika (itd.), na którym utworzono id_dp_pozycja , Ftp, Www, Nośnik, Manualny, Skanowanie. Wartość O została zarezerwowana na potrzeby Modułu okresowego przetwarzania danych na kontach (2.2.3) i nie będzie mogła być w przyszłości wykorzystywana w KEDU do oznaczenia kanału wprowadzania. Status dokumentu stała wartość 1. Numer biblioteki weryfikacji programu Płatnika użytej do weryfikacji formalnej dokumentu. Strona 18 z 49

19 Nazwa elementu Opis Sposób wypełnienia wersja_dokumentu Kolejna wersja dokumentów w ramach serii A. Dla aktualnej wersji dokumentów wartość 4. rodzaj_formularza Rodzaj formularza dokumentu źródłowego. Dopuszczalne wartości: F formularz papierowy wypełniony ręcznie, W wydruk papierowy z programu Płatnika, E dokument elektroniczny. Identyfikacja ubezpieczonego Budowę bloku technicznych identyfikatorów ubezpieczonego pokazuje poniższy diagram. Rysunek 16 Identyfikacja ubezpieczonego Blok identyfikacji ubezpieczonego może zawierać techniczne identyfikatory ubezpieczonego pochodzące z baz danych płatnika i. Tabela 9. Identyfikacja ubezpieczonego Nazwa elementu Opis Sposób wypełnienia id_ub_systemowy Liczba, techniczny identyfikator Nie wypełniać ubezpieczonego w bazie danych płatnika. id_ub_ Liczba, techniczny identyfikator ubezpieczonego w Cechy Dokumentu Budowę sekwencji cech dokumentu przedstawiono na diagramie poniżej. Rysunek 17 Cechy dokumentu Strona 19 z 49

20 Wewnątrz sekwencji umożliwiono umieszczenie dowolnej liczby cech, czyli dowolnych informacji powiązanych logicznie z dokumentem. Opis elementu cecha przedstawiono w rozdziale Opis cechy. Cechy Bloku Budowę sekwencji cech bloku wielokrotnego dokumentu przedstawiono na diagramie poniżej. Rysunek 18 Cechy bloku Wewnątrz sekwencji umożliwiono umieszczenie dowolnej liczbie cech, czyli dowolnych informacji powiązanych logicznie z blokiem wielokrotnym dokumentu. Opis elementu cecha przedstawiono w rozdziale Opis cechy. Stopka Dokumentu Budowa stopki DP została zaprezentowana na diagramie poniżej. Rysunek 19 Stopka dokumentu W stopce dokumentu wyróżniamy dwie istotne sekwencje danych: - opis czynności edycyjnych podczas korygowania interpretacji dokumentów wykonanej przez oprogramowania OCR, - opis błędów stwierdzonych podczas kontroli formalnej Opis cechy Struktura opisu cechy została zaprezentowana na rysunku poniżej. Rysunek 20 Opis cechy Strona 20 z 49

21 Tabela 10. Opis cechy Nazwa atrybutu/elementu nazwa wartość Opis Dowolny ciąg znaków opisujący cechę. Jest to atrybut elementu cecha. Dowolny ciąg znaków stanowiący treść cechy. Sposób wypełnienia Nie wypełniać Nie wypełniać Korekta OCR Element korekta_ocr przeznaczony jest do przechowywania informacji dotyczących kolejnych etapów korekty dokumentów ubezpieczeniowych po skanowaniu i odczycie OCR. Elementy wchodzące w skład korekty OCR zostały zaprezentowane na diagramie poniżej. korekta_ocr <korekta_ocr białe_znaki typ_korekty > nerrorid1 nerrorid2 nerrorid3 wartość_przed_korektą id_korektora data_korekty </korekta_ocr> Rysunek 21 Korekta OCR Korekta OCR przechowuje zapis wszystkich czynności, jakie zostały podjęte podczas korygowania przez człowieka błędów popełnionych przez komputer w trakcie maszynowej interpretacji treści dokumentów. Tabela 11. Korekta OCR Nazwa atrybutu/ elementu typ_korekty nerrorid1 Opis Typ wykonanej korekty. Jest to atrybut elementu korekta_ocr. Dopuszczalne wartości: ocr_a korekta automatyczna, ocr_z korekta znakowa, ocr_l korekta logiczna, ocr_l2 korekta logiczna druga. Numer kolejny bloku w korygowanym dokumencie Sposób wypełnienia Strona 21 z 49

22 Nazwa atrybutu/ elementu nerrorid2 nerrorid3 wartość_przed_korekt ą id_korektora Opis Numer kolejny pola w korygowanym bloku Numer kolejny bloku wielokrotnego w korygowanym dokumencie, jeśli korygowany blok nie jest blokiem wielokrotnym, wtedy pole przyjmuje wartość -1 Wartość, która była w polu korygowanym przed dokonaniem korekty Adres KSI numeryczny korektora. Sposób wypełnienia data_korekty Data i czas wykonania korekty Opis błędu Struktura opisu błędów została zaprezentowana na rysunku poniżej. Rysunek 22 Opis błędu Struktura służy do przechowywania informacji o błędach, które zostały stwierdzone w wyniku przeprowadzenia weryfikacji formalnej dokumentu. Tabela 12. Opis błędu Nazwa atrybutu Opis Sposób wypełnienia kod Numeryczny kod błędu blok pole Numer kolejny bloku w dokumencie, którego dotyczy błąd Numer kolejny pola w bloku, którego dotyczy błąd Strona 22 z 49

23 Nazwa atrybutu Opis Sposób wypełnienia id_bloku Numer kolejny bloku wielokrotnego w dokumencie, którego dotyczy błąd opis Opis błędu Białe znaki Białym znakiem może być: spacja, odstęp: znak ASCII o kodzie szesnastkowym #x20; tabulator, znak ASCII o kodzie szesnastkowym #x9; nowy wiersz, w systemach DOS/Windows: dwuznak zgodny ze znakami ASCII o kodzie szesnastkowym #xd#xa; w systemie UNIX pojedynczy znak ASCII o kodzie szesnastkowym #xa. Oprócz miejsc wskazanych bezpośrednio, stosowanie białych znaków jest dozwolone we wszystkich miejscach kolekcji, w których dopuszcza je specyfikacja standardu XML 1.0. Należy pamiętać, że standardem kodowania znaków kolekcji jest Unikod UTF-8. Powyżej podano szesnastkowe kody ASCII, gdyż są zgodne z kodami UTF-8 dla tych samych znaków (pierwsze 127 kodów standardu UTF-8 pokrywa się z kodami ASCII). Dopuszczalne białe znaki zostały zaprezentowane na diagramie poniżej. Rysunek 23 Białe znaki 2.2. Znaki dopuszczalne w KEDU W kolekcji dozwolone jest używanie wyłącznie znaków dopuszczonych przez specyfikację standardu XML 1.0. Są to znaki o kodach szesnastkowych: #x9, #xa, #xd oraz znaki zawarte w przedziałach oznaczonych kodami szesnastkowymi: #x20-#xd7ff, #xe000-#xfffd, Strona 23 z 49

24 #x10000-#x10ffff. Standardem kodowania znaków zastosowanym w KEDU jest Unikod UTF-8. Istnieje grupa znaków zarezerwowanych, których literalne użycie w treści elementów lub w wartościach atrybutów jest niedopuszczalne. Znaki zarezerwowane używane są do formatowania dokumentu XML i z tego powodu nie mogą być wprost użyte w miejscach nieprzewidzianych przez specyfikację standardu. W przypadku konieczności umieszczenia w treści elementów lub w wartościach atrybutów znaków zarezerwowanych, należy je zastąpić odpowiednimi jednostkami predefiniowanymi ogólnymi (ang. predefined entities) lub kodami szesnastkowymi. W treści pliku XML kody szesnastkowe muszą zaczynać się znakami #x, po których następuje liczba w zapisie szesnastkowym. Ponadto kody szesnastkowe i jednostki predefiniowane poprzedza się znakiem &, a bezpośrednio po nich umieszcza się znak średnika ;. Lista znaków zarezerwowanych i odpowiadających im jednostek predefiniowanych oraz kodów szesnastkowych została przedstawiona poniższej tabeli. Tabela 13. Znaki zarezerwowane w XML Znak Opis znaku Jednostka Kod szesnastkowy predefiniowana ogólna < znak mniejsze niż < < > znak większe niż > > & znak Et (ang. & & ampersand) ' znak apostrofu &apos; &#x27; " znak cudzysłowu " " 2.3. Zakres informacyjny KEDU W tym rozdziale został opisany szczegółowo zakres informacyjny wszystkich elementów wchodzących w skład KEDU wraz z instrukcjami dotyczącymi sposobu wypełniania pól dokumentów i innych elementów kolekcji. W kolekcji nie należy umieszczać elementów, które nie zawierają treści (nie zostały wypełnione), a jednocześnie ich obligatoryjne występowanie nie zostało narzucone przez schemat XML. Oznacza to, że w przypadku elementów niewymagalnych, które nie zostały wypełnione, nie należy umieszczać w kolekcji pustych znaczników w postaci <nazwa_elementu></nazwa_elementu> lub <nazwa_elementu/>. Elementy takie należy pomijać. Dotyczy to zarówno elementów prostych (np. nie wypełnionych treścią pól formularza) jak i elementów złożonych (np. bloków, w których nie wypełniono żadnego podelementu). Umieszczanie pustych elementów nie jest niezgodne ogólnymi regułami tworzenia dokumentów XML, jednak zalecane jest nie umieszczanie w kolekcji elementów zbędnych, nie przenoszących żadnych informacji Zakres informacyjny elementów organizacyjnych KEDU Zgodnie z definicją schematu XML dla KEDU kolekcja musi zawierać co najmniej jeden dokument lub zestaw dokumentów, przy czym Strona 24 z 49

25 dopuszcza umieszczanie w kolekcji jednocześnie pojedynczych dokumentów oraz zestawów dokumentów. UWAGA! System Informatyczny aktualnie nie uwzględnia obsługi zestawów dokumentów w KEDU, zatem kolekcja powinna zawierać jedynie pojedyncze dokumenty. Tabela 14 prezentuje sposób wypełniania informacją elementów organizacyjnych KEDU. Tabela 14. Zakres informacyjny elementów organizacyjnych KEDU ELEMENT SPOSÓB WYPEŁNIANIA KROTNOŚĆ początek KEDU <?xml version="1.0" encoding="utf-8"?> 1 <KEDU wersja_schematu="1" xmlns=" xmlns:xsi=" xsi:schemalocation=" kedu_3.xsd"> nagłówek_kedu <naglowek.kedu> Patrz rozdział Nagłówek KEDU oraz Tabela 2. nagłówek KEDU </naglowek.kedu> cechy_kedu <cechy.kedu> 0 lub 1 Patrz rozdział Cechy KEDU oraz Tabela 10. Opis cechy </cechy.kedu> dokument lub zestaw <XXX 1 > <zestaw> 1 lub Patrz rozdział Dokument Patrz rozdział Zestaw płatnika dokumentów płatnika więcej </XXX 2 > </zestaw> koniec KEDU </KEDU> 1 3. Komunikacja w systemie Elektronicznej Wymiany Dokumentów (EWD) Komunikacja w EWD pomiędzy klientem a serwerem pozwala na: wysyłanie przesyłek zawierających dokumenty ubezpieczeniowe do serwera, pobieranie przesyłek z serwera. W obu przypadkach stroną inicjującą jest klient. Do mogą wpływać przesyłki przygotowane w oparciu o kryptografię CMS jak i XMLEnc/XMLSign. 1 Zastąpić napis XXX nazwą odpowiedniego formularza ubezpieczeniowego. Nazwy formularzy ubezpieczeniowych podane są w rozdziale Dokument płatnika. 2 Zastąpić napis XXX nazwą odpowiedniego formularza ubezpieczeniowego. Nazwy formularzy ubezpieczeniowych podane są w rozdziale Dokument płatnika. Strona 25 z 49

26 3.1. Zestawienie sesji z serwerem komunikacyjnym Klient w celu komunikowania się z musi ustanowić sesję przy wykorzystaniu protokołu https. Protokół http jest pakietowany przy wykorzystaniu SSL. Wykorzystanie SSL ma na celu: uwierzytelnienie serwera komunikacyjnego z którym prowadzona jest komunikacja. Oprogramowanie interfejsowe otrzymuje w procesie negocjacji warunków połączenia certyfikat serwera który może zweryfikować w oparciu o certyfikat wystawcy, zapewnienie poufności przesyłanych danych, zapewnienie integralności danych. Podczas komunikacji z należy wykorzystywać SSL z szyfrowaniem o długością klucza 128 bitów. Podczas zestawiania połączenia z oprogramowanie interfejsowe otrzymuję certyfikat serwera komunikacyjnego. Nazwa serwera powinna być zgodna z zawartością pola Common Name z certyfikatu. Certyfikat serwera weryfikuję się przy wykorzystaniu certyfikatów wystawców oraz list unieważnionych certyfikatów publikowanych przez nich. Certyfikaty i CRL konieczne do weryfikacji certyfikatu serwera można pobrać: Wysyłanie przesyłek do Wysyłanie przesyłek z może przebiegać przy wykorzystaniu usług webowych lub serwisu internetowego. W przypadku korzystania z serwisu internetowego struktura przesyłek odpowiada strukturze wiadomości wykorzystywanych podczas wymiany z serwisem webowym. Rysunek 24 Wysyłanie przesyłki do Poszczególne komunikaty wymieniane pomiędzy klientem a serwerem (patrz Rysunek 24) to: 1. przesyłka wysłana do (komunikat WyslijPrzesylkeSoapIn w formacie SOAP1.2/MTOM), Strona 26 z 49

27 2. informacja o przyjęciu przesyłki (komunikat WyslijPrzesylkeSoapOut w formacie SOAP1.2/MTOM). W wyniku przekazania dokumentu do osoba wysyłająca otrzymuję zwrotnie identyfikator przesyłki Pobieranie przesyłek z Odbieranie przesyłek z może przebiegać przy wykorzystaniu usług webowych lub serwisu internetowego. W przypadku korzystania z serwisu internetowego struktura przesyłek odpowiada strukturze wiadomości wykorzystywanych podczas wymiany z serwisem webowym. Rysunek 25 Pobieranie przesyłek z Poszczególne komunikaty wymieniane pomiędzy klientem a serwerem (patrz Rysunek 25) to: 1. żądanie indeksu przesyłek (komunikat PobierzIndexPrzesylekSoapIn w formacie SOAP) dla przesyłki o zadanym identyfikatorze, 2. indeks przesyłek będących odpowiedziami na zadany identyfikator (komunikat PobierzIndexPrzesylekSoapOut w formacie SOAP), 3. żądanie wydania przesyłki zwrotnej o wskazanym identyfikatorze (komunikat PobierzPotwierdzenieSoapIn w formacie MTOM), 4. przesyłka wydana w wyniku realizacji żądania (komunikat PobierzPotwierdzenieSoapOut w formacie MTOM). Indeks przesyłek jest strukturą informacyjną zawierającą wykaz przesyłek będących odpowiedziami na przesyłkę zawierającą dokumenty ubezpieczeniowe o zadanym identyfikatorze przekazaną do. 4. Specyfikacja usług webowych w systemie EWD System EWD oferuje usługi webowe umożliwiające przekazywanie dokumentów ubezpieczeniowych do. Dokładna specyfikacja WSDL zawarta jest w Załączniku 2 Specyfikacja usług webowych oferowanych przez. Strona 27 z 49

28 4.1. Operacja WyslijPrzesylke Operacja WyslijPrzesylke służy do wysłania przesyłek do. Przesyłka jest przekazywana na serwer komunikacyjny. <wsdl:operation name="wyslijprzesylke"> <wsdl:documentation xmlns:wsdl=" przesyłek do </wsdl:documentation> <wsdl:input message="tns:wyslijprzesylkesoapin" /> <wsdl:output message="tns:wyslijprzesylkesoapout" /> </wsdl:operation> 4.2. Komunikaty wykorzystywane podczas operacji WyslijPrzesylke Komunikaty wejściowe WyslijPrzesylkeSoapIn <wsdl:message name="wyslijprzesylkesoapin"> <wsdl:part name="parameters" element="tns:wyslijprzesylke" /> </wsdl:message> <s:element name="wyslijprzesylke"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="pbyprzesylka" type="s:base64binary" /> <s:element minoccurs="1" maxoccurs="1" name="uiprzesylkadlugosc" type="s:unsignedint" /> <s:element minoccurs="0" maxoccurs="1" name="strnazwaproducenta" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="strnazwaoprogramowania" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="strwersjaoprogramowania" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="strb64skrotprzesylkiin" type="s:string" /> Strona 28 z 49

29 type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="strtypprzesylki" <s:element minoccurs="0" maxoccurs="1" name="strb64skrotprzesylkiout" type="s:string" /> type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="stridentyfikator" </s:sequence> </s:complextype> </s:element> Tabela 15. Parametry komunikatu wejściowego WyslijPrzesylkeSoapIn Parametry wejściowe Opis: pbyprzesylka Przesyłka w postaci binarnej po przekształceniu base64 uiprzesylkadlugosc Wielkość przesyłki w bajtach strnazwaproducenta Nazwa producenta oprogramowania interfejsowego (64 znaki) strnazwaoprogramowania Nazwa oprogramowania interfejsowego (64 znaki) strwersjaoprogramowania Wersja oprogramowania interfejsowego (32 znaki) strb64skrotprzesylkiin Skrót SHA1 z przesyłki po przekształceniu BASE64 strtypprzesylki Typ przesyłki. Obsługiwane przez typy przesyłek to: SDWI2.CMS.ZIP.CMS.KEDUXML SDWI2.CMS.LZMA.CMS.KEDUXML SDWI2.CMS.BZIP2.CMS.KEDUXML SDWI2.XMLENC.ZIP.XMLSIGN.KEDUXML SDWI2.XMLENC.LZMA.XMLSIGN.KEDUXML SDWI2.XMLENC.BZIP2.XMLSIGN.KEDUXML strb64skrotprzesylkiout Pole puste. Pole wymagane przez SOAP. stridentyfikator Pole puste. Pole wymagane przez SOAP. Komunikat wyjściowy WyslijPrzesylkeSoapOut <wsdl:message name="wyslijprzesylkesoapout"> <wsdl:part name="parameters" element="tns:wyslijprzesylkeresponse" /> </wsdl:message> <s:element name="wyslijprzesylkeresponse"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="strb64skrotprzesylkiout" type="s:string" /> Strona 29 z 49

30 type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="stridentyfikator" </s:sequence> </s:complextype> </s:element> Tabela 16. Parametry komunikatu wyjściowego WyslijPrzesylkeSoapOut Parametry wyjściowe strb64skrotprzesylkiout stridentyfikator Opis: Skrót SHA1 z przesyłki po przekształceniu BASE64 Identyfikator nadany przez przesyłce zawierającej dokumenty ubezpieczeniowe. Jest to także identyfikator zadania (stridzadania) przy pobieraniu indeksu przesyłek z potwierdzeniami Operacja PobierzPotwierdzenie Operacja PobierzPotwierdzenie służy do odbioru przesyłek zawierających potwierdzenia z. Przesyłka jest pobierana z serwera komunikacyjnego. <wsdl:operation name="pobierzpotwierdzenie"> <wsdl:documentation xmlns:wsdl=" potwierdzeń z </wsdl:documentation> <wsdl:input message="tns:pobierzpotwierdzeniesoapin" /> <wsdl:output message="tns:pobierzpotwierdzeniesoapout" /> </wsdl:operation> 4.4. Komunikaty wykorzystywane podczas operacji PobierzPotwierdzenie Komunikat wejściowy PobierzPotwierdzenieSoapIn <wsdl:message name="pobierzpotwierdzeniesoapin"> <wsdl:part name="parameters" element="tns:pobierzpotwierdzenie" /> </wsdl:message> <s:element name="pobierzpotwierdzenie"> Strona 30 z 49

31 <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="stridentyfikator" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="strnazwaproducenta" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="strnazwaoprogramowania" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="strwersjaoprogramowania" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="stridzadania" type="s:string" /> /> <s:element minoccurs="1" maxoccurs="1" name="datawpisu" type="s:datetime" <s:element minoccurs="0" maxoccurs="1" name="strtyp" type="s:string" /> <s:element minoccurs="1" maxoccurs="1" name="uiwielkoscprzesylki" type="s:unsignedint" /> <s:element minoccurs="0" maxoccurs="1" name="byprzesylka" type="s:base64binary" /> /> <s:element minoccurs="0" maxoccurs="1" name="strb64skrot" type="s:string" </s:sequence> </s:complextype> </s:element> Tabela 17. Parametry komunikatu wejściowego PobierzPotwierdzenieSoapIn Parametry wejściowe stridentyfikator strnazwaproducenta strnazwaoprogramowania strwersjaoprogramowania stridzadania DataWpisu strtyp uiwielkoscprzesylki byprzesylka strb64skrot Opis: Identyfikator przesyłki z potwierdzeniem Nazwa producenta oprogramowania interfejsowego Nazwa oprogramowania interfejsowego Wersja oprogramowania interfejsowego Pole puste. Pole wymagane przez SOAP. Pole puste. Pole wymagane przez SOAP. Pole puste. Pole wymagane przez SOAP. Pole puste. Pole wymagane przez SOAP. Pole puste. Pole wymagane przez SOAP. Pole puste. Pole wymagane przez SOAP. Strona 31 z 49

32 /> Komunikat wyjściowy PobierzPotwierdzenieSoapOut <wsdl:message name="pobierzpotwierdzeniesoapout"> <wsdl:part name="parameters" element="tns:pobierzpotwierdzenieresponse" </wsdl:message> <s:element name="pobierzpotwierdzenieresponse"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="stridzadania" type="s:string" /> /> <s:element minoccurs="1" maxoccurs="1" name="datawpisu" type="s:datetime" <s:element minoccurs="0" maxoccurs="1" name="strtyp" type="s:string" /> <s:element minoccurs="1" maxoccurs="1" name="uiwielkoscprzesylki" type="s:unsignedint" /> <s:element minoccurs="0" maxoccurs="1" name="byprzesylka" type="s:base64binary" /> /> <s:element minoccurs="0" maxoccurs="1" name="strb64skrot" type="s:string" </s:sequence> </s:complextype> </s:element> Tabela 18. Parametry komunikatu wyjściowego PobierzPotwierdzenieSoapOut Parametry wyjściowe stridzadania DataWpisu strtyp uiwielkoscprzesylki byprzesylka strb64skrot Opis: Identyfikator przesyłki zawierającej dokumenty ubezpieczeniowe, której dotyczy przesyłka z potwierdzeniem Data udostępnienia przez potwierdzenia Typ przesyłki. Możliwe typy to: SDWI2.ZIP.CMS.POTWIERDZENIE SDWI2.LZMA.CMS.POTWIERDZENIE SDWI2.BZIP2.CMS.POTWIERDZENIE SDWI2.ZIP.XMLSIGN.POTWIERDZENIE SDWI2.LZMA.XMLSIGN.POTWIERDZENIE SDWI2.BZIP2.XMLSIGN.POTWIERDZENIE Wielkość przesyłki w bajtach Treść przesyłki Skrót SHA1 z treści przesyłki po przekształceniu BASE64 Strona 32 z 49

33 4.5. Operacja PobierzIndexPrzesylek Operacja PobierzIndexPrzesylek służy do odbioru indeksu przesyłek. Odbiór indeksu następuje z serwera komunikacyjnego. <wsdl:operation name="pobierzindexprzesylek"> <wsdl:documentation xmlns:wsdl=" indeksu przesyłek z </wsdl:documentation> <wsdl:input message="tns:pobierzindexprzesyleksoapin" /> <wsdl:output message="tns:pobierzindexprzesyleksoapout" /> </wsdl:operation> 4.6. Komunikaty wykorzystywane podczas operacji PobierzIndexPrzesylek Komunikat wejściowy PobierzIndexPrzesylekSoapIn <wsdl:message name="pobierzindexprzesyleksoapin"> <wsdl:part name="parameters" element="tns:pobierzindexprzesylek" /> </wsdl:message> - <s:element name="pobierzindexprzesylek"> - <s:complextype> - <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="stridzadania" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="strnazwaproducenta" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="strnazwaoprogramowania" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="strwersjaoprogramowania" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="msgindex" type="tns:messageindex" /> </s:sequence> </s:complextype> </s:element> Strona 33 z 49

34 <s:complextype name="messageindex"> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="m_collection" type="tns:arrayofmessageindexelement" /> </s:sequence> </s:complextype> - <s:complextype name="arrayofmessageindexelement"> - <s:sequence> <s:element minoccurs="0" maxoccurs="unbounded" name="messageindexelement" nillable="true" type="tns:messageindexelement" /> </s:sequence> </s:complextype> - <s:complextype name="messageindexelement"> - <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="stridentyfikator" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="stridzadania" type="s:string" /> <s:element minoccurs="1" maxoccurs="1" name="datawpisu" type="s:datetime" /> <s:element minoccurs="0" maxoccurs="1" name="strtyp" type="s:string" /> <s:element minoccurs="1" maxoccurs="1" name="uiwielkoscprzesylki" type="s:int" /> <s:element minoccurs="0" maxoccurs="1" name="strb64hash" type="s:string" /> </s:sequence> </s:complextype> Tabela 19. Parametry komunikatu wejściowego PobierzIndexPrzesulekSoapIn Parametry wejściowe stridzadania strnazwaproducenta strnazwaoprogramowania strwersjaoprogramowania msgindex Opis: Identyfikator przesyłki, która zawierała dokumenty ubezpieczeniowe, dla której ma zostać pobrany indeks przesyłek. Nazwa producenta oprogramowania interfejsowego Nazwa oprogramowania interfejsowego Wersja oprogramowania interfejsowego Pole puste. Pole wymagane przez SOAP. Strona 34 z 49

35 Komunikaty wyjściowe PobierzIndexPrzesylekSoapOut <wsdl:message name="pobierzindexprzesyleksoapout"> <wsdl:part name="parameters" element="tns:pobierzindexprzesylekresponse" /> </wsdl:message> <s:element name="pobierzindexprzesylekresponse"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="msgindex" type="tns:messageindex" /> </s:sequence> </s:complextype> </s:element> <s:complextype name="messageindex"> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="m_collection" type="tns:arrayofmessageindexelement" /> </s:sequence> </s:complextype> - <s:complextype name="arrayofmessageindexelement"> - <s:sequence> <s:element minoccurs="0" maxoccurs="unbounded" name="messageindexelement" nillable="true" type="tns:messageindexelement" /> </s:sequence> </s:complextype> - <s:complextype name="messageindexelement"> - <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="stridentyfikator" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="stridzadania" type="s:string" /> <s:element minoccurs="1" maxoccurs="1" name="datawpisu" type="s:datetime" /> <s:element minoccurs="0" maxoccurs="1" name="strtyp" type="s:string" /> Strona 35 z 49

36 <s:element minoccurs="1" maxoccurs="1" name="uiwielkoscprzesylki" type="s:int" /> /> <s:element minoccurs="0" maxoccurs="1" name="strb64hash" type="s:string" </s:sequence> </s:complextype> Tabela 20. Parametry komunikatu wyjściowego PobierzIndexPrzesulekSoapOut Parametry wyjściowe stridentyfikator stridzadania DataWpisu strtyp uiwielkoscprzesylki strb64hash Opis: Identyfikator przesyłki z potwierdzeniem Identyfikator przesyłki która zawierała dokumenty ubezpieczeniowe której dotyczy potwierdzenie Data udostępnienia przez przesyłki Typ przesyłki Możliwe typy to: SDWI2.ZIP.CMS.POTWIERDZENIE SDWI2.LZMA.CMS.POTWIERDZENIE SDWI2.BZIP2.CMS.POTWIERDZENIE SDWI2.ZIP.XMLSIGN.POTWIERDZENIE SDWI2.LZMA.XMLSIGN.POTWIERDZENIE SDWI2.BZIP2.XMLSIGN.POTWIERDZENIE Wielkość przesyłki w bajtach Skrót SHA1 z treści przesyłki po przekształceniu BASE Operacja CheckTransmision Operacja CheckTransmision służy do testowania połączenia z serwerem komunikacyjnym. <wsdl:message name="checktransmisionsoapin"> <wsdl:part name="parameters" element="tns:checktransmision" /> </wsdl:message> <wsdl:message name="checktransmisionsoapout"> <wsdl:part name="parameters" element="tns:checktransmisionresponse" /> </wsdl:message> Strona 36 z 49

37 4.8. Komunikaty wykorzystywane podczas operacji CheckTransmision Komunikat wejściowy CheckTransmision <wsdl:message name="checktransmisionsoapin"> <wsdl:part name="parameters" element="tns:checktransmision" /> </wsdl:message> <s:element name="checktransmision"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="bydatain" type="s:base64binary" /> <s:element minoccurs="1" maxoccurs="1" name="uidatainlength" type="s:unsignedint" /> <s:element minoccurs="0" maxoccurs="1" name="bydataout" type="s:base64binary" /> <s:element minoccurs="1" maxoccurs="1" name="uidataoutlength" type="s:unsignedint" /> </s:sequence> </s:complextype> </s:element> Tabela 21. Parametry komunikatu wejściowego CheckTransmisionSoapIn Parametry wejściowe bydatain uidatainlength bydataout uidataoutlength Opis: Wejściowe dane testowe Długość wejściowych danych testowych w bajtach Pole puste. Pole wymagane przez SOAP Pole puste. Pole wymagane przez SOAP Komunikaty wyjściowe CheckTransmisionSoapOut <wsdl:message name="checktransmisionsoapout"> <wsdl:part name="parameters" element="tns:checktransmisionresponse" /> </wsdl:message> <s:element name="checktransmisionresponse"> Strona 37 z 49

38 <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="bydataout" type="s:base64binary" /> type="s:unsignedint" /> <s:element minoccurs="1" maxoccurs="1" name="uidataoutlength" </s:sequence> </s:complextype> </s:element> Tabela 22. Parametry komunikatu wejściowego CheckTransmisionSoapOut Parametry wejściowe bydataout uidataoutlength Opis: Wyjściowe dane testowe. Powinny być takie same jak wejściowe dane testowe. Długość wyjściowych danych testowych Powinna być taka sama jak długość wejściowych danych testowych. 5. Tworzenie przesyłek w ramach Systemu Elektronicznej Wymiany Dokumentów 5.1. Nazwy typów przesyłek Nazwa typu przesyłki budowana jest w następujący sposób: SDWI2.[Standard koperty dla zaszyfrowanych danych.][standard kompresji.][standard koperty dla podpisanych danych.][rodzaj dokumentu przekazywanego] Typy przesyłek wejściowych obsługiwanych przez : SDWI2.CMS.ZIP.CMS.KEDUXML SDWI2.CMS.LZMA.CMS.KEDUXML SDWI2.CMS.BZIP2.CMS.KEDUXML SDWI2.XMLENC.ZIP.XMLSIGN.KEDUXML SDWI2.XMLENC.LZMA.XMLSIGN.KEDUXML SDWI2.XMLENC.BZIP2.XMLSIGN.KEDUXML Typy przesyłek wyjściowych z : SDWI2.ZIP.CMS.POTWIERDZENIE SDWI2.LZMA.CMS.POTWIERDZENIE SDWI2.BZIP2.CMS.POTWIERDZENIE SDWI2.ZIP.XMLSIGN.POTWIERDZENIE SDWI2.LZMA.XMLSIGN.POTWIERDZENIE SDWI2.BZIP2.XMLSIGN.POTWIERDZENIE Strona 38 z 49

39 5.2. Przesyłka do Przesyłka do zawiera dokumenty ubezpieczeniowe w strukturze KEDU Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych. Struktura KEDU została opisana w Rozdziale Tworzenie przesyłek z wykorzystaniem kryptografii CMS Rysunek 26 Schemat tworzenia przesyłki do (komunikat WyslijPrzesylkeIn) Utworzenie przesyłki następuje w następujący sposób: Podpisanie dokumentu ubezpieczeniowego (A) i następnie zapisanie go w formacie CMS typu signed-data (B). Poszczególne pola zawierają: version wersja 3 digestalgorithms identyfikatory używanych algorytmów, encapcontentinf komunikat A, o certificates certyfikat użyty do podpisu, signerinfo Informacje dotyczące podpisu Skompresowanie dokumentu i zapisanie go w formacie ZIP/LZMA/BZIP2 (C). Umieszczenie skompresowanego dokumentu w kopercie kryptograficznej, format CMS typu enveloped-data (D). Poszczególne pola zawierają: version wersja 0 recipientinfos klucz sesji użyty do zaszyfrowania danych, encryptedconten tinfo dane niezbędne do deszyfracji np. klucz sesyjny, nazwa wystawcy oraz numer identyfikacyjny certyfikatu Strona 39 z 49

40 Utworzenie koperty komunikacyjnej SOAP1.2/MTOM (E). Wiadomość WyslijPrzesylkeSoapIn zawiera informacje opisujące przesyłaną przesyłkę oraz samą przesyłkę. W zależności od wykorzystanych algorytmów typy przesyłek przyjmują następujące wartości: SDWI2.CMS.ZIP.CMS.KEDUXML SDWI2.CMS.LZMA.CMS.KEDUXML SDWI2.CMS.BZIP2.CMS.KEDUXML Tworzenie przesyłek z wykorzystaniem kryptografii XMLEnc/XMLSign Rysunek 27 Schemat tworzenia przesyłek do (komunikat WyslijPrzesylkeIn) Utworzenie przesyłki następuje w następujący sposób: Podpisanie danych (A) i następnie zapisanie ich w formacie XMLSign typu Enveloped. Poszczególne algorytmy wykorzystywane podczas podpisu: Canonicalization Method SignatureMethod DigestMethod Transform Podpisany dokument musi posiadać element KeyInfo zawierający certyfikat (X509Certificate) który służył do złożenia podpisu oraz wskazanie na ten certyfikat (RSAKeyValue). Zawartość elementu KeyInfo <RSAKeyValue> <Modulus> <Exponent> <X509Data> <X509Certificate> Strona 40 z 49

41 Skompresowanie dokumentu przy pomocy algorytmów ZIP/LZMA/BZIP2 (C) i przekształcenie BASE64. Umieszczenie dokumentu wynikowego w kopercie XML. <?xml version="1.0" encoding="utf-8"?> <xs:schema targetnamespace=" xmlns=" xmlns:xs=" <xs:element name="compressed"> <xs:complextype> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="algorithm" use="required"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="zip"/> <xs:enumeration value="bzip2"/> <xs:enumeration value="lzma"/> </xs:restriction> </xs:simpletype> </xs:attribute> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:element> </xs:schema> Zależnie od stosowanego algorytmu wartość atrybutu algorithm : Algorithm zip lzma bzip2 Umieszczenie skompresowanego dokumentu w kopercie kryptograficznej XMLEnc Poszczególne algorytmy wykorzystywane podczas szyfrowania: EncryptedData EncryptionMetho d EncryptionMetho d Podpisany dokument musi posiadać element KeyInfo zawierający certyfikat X509Certificate. Strona 41 z 49