Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc



Podobne dokumenty
Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

kdpw_stream Struktura komunikatu: Potwierdzenie obsługi komunikatu blokady (acmt.bls ) Data utworzenia: r.

Repozytorium Transakcji w KDPW Raportowanie komunikacja z repozytorium. Warszawa,10 luty 2014

Podstawowe zasady dotyczące potwierdzania warunków transakcji na Platformie konfirmacji.

kdpw_stream Struktura komunikatu: Potwierdzenie obsługi komunikatu blokady (acmt.bls ) Data utworzenia: r.

Repozytorium Transakcji w KDPW Raportowanie komunikacja z repozytorium. Warszawa, styczeń 2014

Wykaz kodów błędów Stan na 11 sierpnia 2014 r.

kdpw_stream Struktura komunikatu: Instrukcja techniczna (sese.tec ) Data utworzenia: r.

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_stream

Zasady wymiany komunikatów ISO20022 w systemie kdpw_stream

Poczta Polska S.A. Opis struktury pliku z danymi przekazów pocztowych lub Ekspresów Pieniężnych. Wersja 2.1

Specyfikacja HTTP API. Wersja 1.6

Struktura pliku wejściowego ippk Plik Korekt Składek

kdpw_stream Struktura komunikatu: Status limitu transakcyjnego (colr.mrs ) Data utworzenia: r.

Dokumentacja SMS przez FTP

kdpw_stream Struktura komunikatu: Instrukcja dotycząca konta (acmt.rqa ) Data utworzenia: r.

Struktura pliku wejściowego ippk Plik Składkowy

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

Struktura pliku wejściowego ippk Plik Rejestracyjny

Konta w KDPW i KDPW_CCP

Dlaczego GML? Gdańsk r. Karol Stachura

Ministerstwo Finansów

1. Otwieranie kont w KDPW_CCP wykorzystywanych w celu rejestracji transakcji zestawianych na platformie konfirmacji OTC MarkitWire

Obsługa zabezpieczeń nominowanych w EUR w KDPW_CCP. Poradnik. Warszawa, 9 września 2015 r.

Instrukcja integratora - obsługa dużych plików w epuap2

System DiLO. Opis interfejsu dostępowego v. 2.0

OBNIŻENIE WARTOŚĆI NOMINALNEJ (DECR)

JPK.guru Excel (podgląd JPK) Instrukcja Użytkownika

Zasady Nazewnictwa. Dokumentów XML Strona 1 z 9

dot. Raportowania derywatów do repozytorium transakcji przez KDPW_CCP

MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI

Dokumentacja 2SMS

Dokumentacja smsapi wersja 1.4

Komunikat ze słownikiem produktów handlowych wykorzystanych w chemioterapii i programach terapeutycznych

kdpw_stream Struktura komunikatu: Instrukcja dotycząca NKK (acmt.rqc ) Data utworzenia: r.

Szkolenie systemu POL-on

PODZIAŁ PAPIERÓW WARTOŚCIOWYCH SPLIT (SPLF)

Warsztaty dot. centralnego rozliczania transakcji OTC. Szkolenie dla uczestników systemu kdpw_otc

Jednolity Plik Kontrolny w IFK

Przesyłania danych przez protokół TCP/IP

API przekazy masowe - Dokumentacja. v 1.1, czerwiec 2014 KIP S.A. ul. Św. Marcin 73/ Poznań.

Szczegółowe informacje dotyczące przekazywania do Bankowego Funduszu Gwarancyjnego informacji kanałem teletransmisji

Materiał opisujący proces raportowania MIFIR za pośrednictwem ARM z wykorzystaniem systemu RT

OPIS FORMATÓW PLIKÓW EKSPORTU HISTORII OPERACJI WYKORZYSTYWANYCH W BANKOWOŚCI ELEKTRONICZNEJ IDEA BANK S.A.

Mechanizm generowania edeklaracji

Szkolenie systemu POL-on

Załącznik nr 2 do Umowy Nr. o korzystanie z usługi Identyfikacji Przychodzących Płatności Masowych z dnia.

Struktura pliku wejściowego ippk Plik Dyspozycje

XML Schema. Bartłomiej Świercz. Łódź, 19 listopada 2005 roku. Katedra Mikroelektroniki i Technik Informatycznych. Bartłomiej Świercz XML Schema

Zakład Usług Informatycznych OTAGO

kdpw_stream Struktura komunikatu: Wniesienie lub zwolnienie zabezpieczenia (colr.ins ) Data utworzenia: r.

Instrukcja obsługi Multiconverter 2.0

INSTRUKCJA INSTALACJI PROGRAMU DO WYSYŁKI E-DEKLARACJI TC CRYPT

Struktura pliku wejściowego ippk Plik Dyspozycje

Dokumentacja REST API v 3.0. Kraków, 7 marca FreshMail, ul. Fabryczna 20a, Kraków tel , freshmail.

2. Dokumenty, o których mowa w ust. 1, mają formę dokumentu elektronicznego.

DOKUMENTACJA TECHNICZNA SMS API MT

Procedura Walidacyjna Interfejs

Import zleceń / Integracja klienta K-Ex

Struktura pliku wejściowego ippk Plik Dyspozycje

Załącznik nr 1. Automatyczny rozrachunek zleceń w częściach. Specyfikacja założeń. str

kdpw_stream Struktura komunikatu: Informacja o raportowaniu transakcji (secl.str ) Data utworzenia: r.

Komunikat ze słownikiem produktów handlowych wykorzystanych w chemioterapii, programach terapeutycznych i programach lekowych

Struktura pliku wejściowego ipko biznes przelewy zagraniczne (MT103 / CSV)

Spis treści OPIS PLIKU W FORMACIE CSV Z DANYMI PPE LUB EP 1

Struktura pliku wejściowego ipko biznes PLA/MT103

BRAMKA HTTP SMS XML Dokumentacja techniczna. wersja 3.32

Instrukcja dla użytkowników portalu. Wniosek FWRC dodanie wniosku na portalu

Dokumentacja interfejsu MySQL. Platforma BSMS.PL Instrukcja podłączenia po przez mysql

Ministerstwo Finansów

[Wartość domyślna] xmlns : mz 1 Przestrzeń nazw Definiuje przestrzeń nazw (namespace)

DOKUMENTACJA TECHNICZNA KurJerzyAPI wersja 1.0

Obsługa zabezpieczeń nominowanych w EUR w KDPW_CCP Poradnik

Kanał teletransmisji Bankowego Funduszu Gwarancyjnego (Portal BFG STP) Warszawa, 3 sierpnia 2017 r.

WOJEWÓDZTWO PODKARPACKIE

INFORMACJE NA TEMAT STRUKTURY PLIKU XML

Rozdział 1 Cel dokumentu Rozdział 2 Deklaracja Rozdział 3 Nagłówek Rozdział 4 Podmiot Rozdział 5 FATCA...

Przetwarzanie Rachunków Rozliczeniowych w SI OW NFZ przez Loader tematyczny REF

Podręcznik użytkownika

Instrukcja podłączenia do ZSMOPL na środowisku produkcyjnym

SKRÓCONA INSTRUKCJA OBSŁUGI SYSTEMU ZARZĄDZANIA OBIEGIEM INFORMACJI (SZOI)

Instrukcja obsługi DHL KONWERTER 1.6

Instrukcja importu przesyłek. z Menedżera Sprzedaży do aplikacji Webklient

REKRUTACJA DO PRZEDSZKOLI

INSTRUKCJA UZUPEŁNIANIA PLIKÓW:

BGK Zlecenia (Ferryt Enterprise)

Opis przykładowego programu realizującego komunikację z systemem epuap wykorzystując interfejs komunikacyjny "doręczyciel"

JPK.guru Creator (generowanie JPK) Instrukcja Obsługi

Komunikaty statystyczne medyczne

Instrukcja korzystania z usługi 2SMS. Wersja 2.0 [12 stycznia 2014] bramka@gsmservice.pl

GML w praktyce geodezyjnej

Format danych adnotacji do tytułów wykonawczych przekazywanych do organów egzekucyjnych przez epuap w związku ze zbiegiem egzekucji

Gatesms.eu Mobilne Rozwiązania dla biznesu

Zestawianie pola klient odbywa się według następujących zasad:

(podstawa prawna: 5 ust. 2 rozporządzenia Ministra Finansów z dnia 26 września 2016 r. I. Definicje

MECHANIZM WYMIANY DANYCH ORAZ ROZLICZEŃ APTEKA NFZ

Dokumentacja techniczna RockPay

Procedura zarządzania profilami zaufanymi epuap

Transkrypt:

Warszawa, 07 lutego 2013 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.2 1

Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)... 4 Nagłówki... 5 Zestaw znaków... 5 Schematy przepływów komunikatów... 6 Oznaczenia przyjęte przy prezentacji schematów przepływów... 6 Identyfikacja KDPW_CCP jako odbiorcy i nadawcy komunikatów... 6 Powiązania komunikatów przesyłanych pomiędzy uczestnikami a KDPW_CCP... 7 Ogólny przepływ komunikatów pomiędzy Uczestnikami a KDPW_CCP w zakresie rynku OTC... 8 Opis zawartości komunikatów... 10 otcd.rqi.001.01 instrukcja obsługi rynku OTC... 10 otcd.rsi.001.01 status realizacji instrukcji obsługi rynku OTC... 11 otcd.ntf.001.01 powiadomienie dotyczące obsługi rynku OTC... 13 Sposoby budowania części biznesowej komunikatów... 15 otcd.rqi.001.01 instrukcja obsługi rynku OTC... 15 otcd.rsi.001.01 status realizacji instrukcji obsługi rynku OTC wersja 1... 15 otcd.rsi.001.01 status realizacji instrukcji obsługi rynku OTC wersja 2... 15 otcd.ntf.001.01 powiadomienie dotyczące obsługi rynku OTC... 16 2

Tabela zmian Wersja Wprowadzone zmiany dokumentu 1.0 Materiał podstawowy 1.1 1. Wprowadzenie do dokumentu tabeli opisującej zmiany pomiędzy poszczególnymi wersjami materiału. 2. Usunięcie niezgodności nazewnictwa komunikatów pomiędzy poszczególnymi rozdziałami materiału. 3. Poszerzenie nagłówka komunikatu otcd.ntf.001.01 o pole NtfTp typ powiadomienia. 4. Uzupełnienie opisu przepływu komunikatów z uwzględnieniem natywnego komunikatu admi.err.001.01. 1.2 Dodanie opisu zasad budowy części biznesowej komunikatów 1.3 Uszczegółowienie sposobu wyboru schematu xsd do drugiego etapu walidacji komunikatów otcd.rqi.001.01 oraz otcd.rsi.001.01 1.4 Zaproponowanie alternatywnych sposobów wyboru schematu xsd do drugiego etapu walidacji komunikatów otcd.rsi.001.01 1.4.1 Poprawa błędu w odnośniku do tekstu. 1.4.2 Poprawa nazw procesów w przypadku komunikatów otcd.rqi.001.01 3

Wstęp Niniejszy dokument opisuje zasady budowy komunikatów XML w systemie kdpw_otc, opis ogólnej budowy oraz sekwencje przepływów komunikatów. Szczegółowa zawartość poszczególnych komunikatów w relacji do poszczególnych procesów biznesowych została przedstawiona w dokumencie : Elementy składowe komunikatów OTC w odniesieniu do procesów biznesowych Budowa komunikatów XML Nazewnictwo komunikatów KDPW_CCP opiera się na zaleceniach normy ISO20022: Nazwa komunikatu posiada następującą postać: otcd.aaa.bbb.cc gdzie: aaa rodzaj komunikatu związany z jego funkcją (rqi, rsi, ntf) ; bbb kod określający wariant funkcji komunikatu (numeryczny); cc wersja (w postaci numerycznej). Wersje testowe schematów komunikatów są w KDPW_CCP oznaczane dodatkowym członem w postaci:.draftn, gdzie n oznacza kolejny numer wersji testowej. To dodatkowe oznaczenie nie jest częścią normy ISO20022. Przykład: Druga wersja testowa komunikatu wersji 3 opisującego powiadomienie Uczestnika w ramach obsługi rynku OTC może mieć postać: otcd.ntf.001.03.draft2. Przestrzenie nazw (namespaces) W komunikatach KDPW wykorzystywane są cztery przestrzenie nazw: Domyślna przestrzeń nazw (default namespace) Jej nazwa składa się z części stałej w postaci: urn:std:kdpw: oraz części zmiennej zbudowanej według schematu: xsd:identyfikatorkomunikatu (np.: urn:std:kdpw:xsd: otcd.ntf.001.03.draft2) 4

xs: standardowa przestrzeń nazw dla W3C XML schema xsi: standardowa przestrzeń nazw dla W3C XML schema instance docelowa przestrzeń nazw (target namespace) taka sama jak przestrzeń domyślna Nagłówki Pierwszy element każdego komunikatu posiada zawsze nazwę: <KDPWDocument>. Element ten zawiera następujące obowiązkowe atrybuty: Sndr (sender) nadawca komunikatu w postaci kodu uczestnika KDPW_CCP; Rcvr (receiver) odbiorca komunikatu w postaci kodu uczestnika KDPW_CCP. Drugi element (bezpośredni potomek elementu głównego) posiada zawsze nazwę tożsamą z nazwą komunikatu. Przykład: <KDPWDocument Sndr= 09AA Rcvr= 0010 xmlns="urn:std:kdpw:xsd: otcd.rqi.001.01" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" <otcd.rqi.001.01> <GnlInf> </GnlInf> </otcd.rqi.001.01> </KDPWDocument> Zestaw znaków Komunikaty KDPW_CCP wykorzystują zestaw kodowania znaków UTF-8. 5

Schematy przepływów komunikatów Oznaczenia przyjęte przy prezentacji schematów przepływów W zaprezentowanych poniżej sekwencjach przepływów wykorzystano konwencję budowania schematów sekwencji (sequence diagram) pochodzącą z języka UML 2.0. W szczególności zastosowano następujące oznaczenia: Nazwa komunikatu - Komunikat - Instytucja współpracująca z KDPW_CCP (np. uczestnik, rynek) Uczestnik - KDPW_CCP Schematy zawierają jedynie te komunikaty, które zawierają bezpośrednie odniesienie do opisywanego zagadnienia. Identyfikacja KDPW_CCP jako odbiorcy i nadawcy komunikatów System KDPW_CCP posiada własny, dedykowany kod instytucji 0010. Komunikaty przesyłane do systemu KDPW_CCP muszą zawierać w polu Rcvr odpowiedni kod odbiorcy komunikatu. Analogicznie komunikaty wychodzące z KDPW_CCP będą miały pole Sndr wypełnione kodem 0010. 6

Powiązania komunikatów przesyłanych pomiędzy uczestnikami a KDPW_CCP W procesie komunikacji pomiędzy instytucjami a KDPW_CCP niezbędny jest mechanizm odwoływania się do poprzednio przesyłanych komunikatów. Każda instrukcja przesyłana przez instytucję do KDPW_CCP posiada identyfikator nadany przez nadawcę umieszczany w polu SndrMsgRef. KDPW_CCP nie kontroluje unikalności tak wprowadzonego identyfikatora. Poniżej opisano najczęściej stosowane oznaczenia służące do identyfikacji komunikatów i instrukcji: SndrMsgRef (sender message reference) identyfikator komunikatu wyznaczony przez nadawcę; jest to obowiązkowe pole każdego komunikatu. RltdRef (related reference) oznacza odniesienie do poprzednio otrzymanej instrukcji/komunikatu. Pole stosowane w przypadku odwoływania się do instrukcji przesłanej w kierunku przeciwnym niż aktualna instrukcja. Przykład: komunikat statusu instrukcji rozliczeniowej przesyłany przez KDPW_CCP do uczestnika zawiera w polu RltdRef identyfikator instrukcji nadany przez uczestnika. 7

Ogólny przepływ komunikatów pomiędzy Uczestnikami a KDPW_CCP w zakresie rynku OTC W ramach obsługi rynku OTC przez KDPW_CCP przewidziane jest wykorzystanie trzech podstawowych typów komunikatów: otcd.rqi.001.01 - instrukcja obsługi rynku OTC, komunikat kierowany od Uczestników Rozliczających do systemu KDPW_CCP. otcd.rsi.001.01 - odpowiedź na instrukcję obsługi rynku OTC na przekazany przez Uczestnika komunikat otcd.rqi.001.01. Komunikaty te będą kierowane z systemu KDPW_CCP bezpośrednio do Uczestników Rozliczających. W nagłówku komunikatu będzie zawarta stosowna referencja do pierwotnego komunikatu budowana na podstawie identyfikatora nadanego przez Uczestnika. otcd.ntf.001.01 - Powiadomienie z rynku OTC kierowane do Uczestników Rozliczających. Dodatkowo, w zakresie podstawowej obsługi komunikatów, w przypadku wystąpienia błędu formalnego w nadesłanym komunikacie generowany będzie komunikat admi.err.001.01 (komunikat ten jest natywnym komunikatem systemu rozliczeniowego wykorzystywanego przez KDPW_CCP w procesie rozliczeń). W ramach obsługi rynku OTC do KDPW_CCP mogą być przekazywane instrukcje w postaci komunikatu otcd.rqi.001.01, a na każdy przesłany komunikat do nadawcy zostanie wygenerowana odpowiedź. W przypadku błędu formalnego będzie to komunikat admi.err.001.01, ze wskazaniem kodu i opisu błędu. W przypadku braku zgodności komunikatu z właściwym schematem zostanie także wskazane miejsce wykrycia błędu. W przypadku gdy nie zostanie wykryty żaden błąd formalny instrukcja zostanie przekazana do przetwarzania w ramach obsługi rynku derywatów OTC. W następstwie przetworzenia instrukcji do nadawcy zostanie wygenerowany komunikat otcd.rsi.001.01 z informacją o wyniku realizacji. W przypadku pojawienia się błędu na etapie przetwarzania informacja o nim także będzie zawarta w komunikacie otcd.rsi.001.01. Komunikaty generowane z KDPW_CCP w ramach rynku OTC nie związane z przekazanymi instrukcjami będą generowane w momencie zaistnienia określonych zdarzeń i stanowić będą powiadomienia. Powiadomienia te będą przekazywane do odpowiednich odbiorców w postaci komunikatów typu otcd.ntf.001.01. 8

Poniższy diagram opisuje właściwe przepływy dla wymienionych typów komunikatów. Uczestnik rozliczający 1 Instrukcja OTC otcd.rqi.001.01 admi.err.001.01 2 Instrukcja OTC otcd.rqi.001.01 otcd.rsi.001.01 3 Powiadomienie OTC otc.ntf.001.01 9

Opis zawartości komunikatów otcd.rqi.001.01 instrukcja obsługi rynku OTC Komunikat przesyłany przez Uczestnika do KDPW_CCP wraz z instrukcją obsługi rynku OTC. Komunikat przetwarzany jest na bieżąco po otrzymaniu go przez KDPW_CCP. Rodzaj instrukcji określony jest poprzez odpowiednie wypełnienie dwóch pól komunikatu: ProcessId - wskazany identyfikator procesu przypisany konkretnemu rodzajowi instrukcji przekazywanych do systemu KDPW_CCP; MsgData - zawartość merytoryczna instrukcji obsługi rynku OTC. Pole MsgData wypełniane jest w zależności od procesu biznesowego, którego dotyczy. Budowa zawartości pola MsgData opisana jest poniżej (otcd.rqi.001.01 instrukcja obsługi rynku OTC). W zależności od rodzaju instrukcji wykorzystywane są odpowiednie struktury danych. Zawartość komunikatu <?xml version="1.0" encoding="utf-8"?> <KDPWDocument Sndr="0010" Rcvr="XXXX" xmlns="urn:kdpw:xsd:otcd.rqi.001.01" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" > <otcd.rqi.001.01> <GnlInf> <SndrMsgRef>Instruction1</SndrMsgRef > <FuncOfMsg>NEWM</FuncOfMsg > <ProcessId>WriteEntities</ProcessId> <CreDtTm> <DtTm>2011-04-01T10:00:00</DtTm> </CreDtTm> </GnlInf> <MsgData> </MsgData> </otcd.ntf.001.01> Opis Standardowy nagłówek komunikatu Identyfikator komunikatu Funkcja komunikatu stała wartość NEWM Identyfikator procesu skojarzony z konkretnym przepływem biznesowym. Data i czas utworzenia komunikatu Zawartość instrukcji obsługi rynku OTC zgodna z określonym procesem biznesowym. Patrz dokument: Elementy składowe komunikatów OTC w odniesieniu do procesów biznesowych 10

otcd.rsi.001.01 status realizacji instrukcji obsługi rynku OTC Komunikat generowany z systemu KDPW_CCP do Uczestnika Rozliczającego będącego wystawcą instrukcji obsługi rynku OTC. Komunikat generowany jest bezpośrednio po realizacji danego procesu biznesowego i może zawierać opis stanu przetworzenia instrukcji wraz z danymi, które zostały przekazane w wyniku jej przetworzenia. W celu powiązania komunikatu otcd.rsi.001.01 z odpowiednim komunikatem źródłowym otcd.rqi.001.01 przekazanym przez Uczestnika, wykorzystywana jest sekcja powiązań (Lnk), gdzie w polu RltdRef przekazywany jest identyfikator instrukcji nadany przez jej nadawcę. Zasadę budowania referencji opisuje poniższy diagram. Uczestnik rozliczający Sndr XXXX Rcvr 0010 otcd.rqi.001.01 SndrMsgRef MsgId1...... 0010 Sndr XXXX Rcvr CCPId1 SndrMsgRef MsgId1 RltdRef otcd.rsi.001.01...... Treść komunikatu przekazywana jest w polu MsgData, które zawiera zestaw następujących informacji: Status - oznaczenie statusu poprawności realizacji przekazanego komunikatu, na który została wygenerowana odpowiedź. Dla pola Status możliwe jest określenie dwóch wartości: o COMP - instrukcja została przetworzona poprawnie w całości; o PERR - w trakcie przetwarzania instrukcji obsługi rynku OTC wystąpiły błędy. Errors - wykaz błędów powstałych w wyniku przetwarzania. Pole to jest polem opcjonalnym i nie jest przekazywane w przypadku poprawnego przetworzenia instrukcji, co jest wskazywane w polu Status. Struktura tego elementu opisana jest odrębnym schematem komunikatu i zostanie opisana w innym materiale. 11

Content - dane komunikatu zawierające zestaw informacji zwrotnych wygenerowanych przez system KDPW_CCP w wyniku przetworzenia instrukcji. Jeśli przetworzona instrukcja była zapytaniem o określone informacje komunikat zwrotny będzie zawiera pole Content z odpowiednimi danymi. Format tego pola jest uzależniony od typu przekazywanych danych w ramach konkretnego procesu biznesowego, a struktury danych są opisane w odrębnych schematach XML zgodnie z punktami (otcd.rsi.001.01 status realizacji instrukcji obsługi rynku OTC wersja 1 oraz otcd.rsi.001.01 status realizacji instrukcji obsługi rynku OTC wersja 2). Pole Content jest polem opcjonalnym. Zawartość komunikatu <?xml version="1.0" encoding="utf-8"?> <KDPWDocument Sndr="0010" Rcvr="XXXX" xmlns="urn:kdpw:xsd:otcd.rsi.001.01" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" > <otcd.rsi.001.01> <GnlInf> <SndrMsgRef>Status1</SndrMsgRef > <FuncOfMsg>NEWM</FuncOfMsg > <CreDtTm> <DtTm>2011-04-01T10:00:00</DtTm> </CreDtTm> <Lnk> <RltdRef>Instruction1</RltdRef> </Lnk> </GnlInf> <MsgData> <Status>PERR</Status> <Errors> </Errors> <Content> </Content> Opis Standardowy nagłówek komunikatu Identyfikator komunikatu nadany przez KDPW_CCP Funkcja komunikatu stała wartość NEWM Data i czas utworzenia komunikatu Identyfikator procesu skojarzony z konkretnym przepływem biznesowym. Status przetworzonej instrukcji obsługi rynku OTC: COMP - przetworzona poprawnie PERR - przetworzona z błędami Lista błędów, które wystąpiły w trakcie przetwarzania instrukcji Wynik przetworzenia instrukcji obsługi rynku OTC zgodny z danym procesem biznesowym. Patrz dokument: Elementy składowe komunikatów OTC w odniesieniu do procesów biznesowych 12

</MsgData> </otcd.rsi.001.01> otcd.ntf.001.01 powiadomienie dotyczące obsługi rynku OTC Komunikat generowany z systemu KDPW_CCP do Uczestnika Rozliczającego w wyniku wykonania określonego procesu biznesowego i nie jest związany bezpośrednio z przekazaniem instrukcji od Uczestnika. Stanowi on powiadomienie o osiągnięciu pewnego stanu przetwarzania lub wystąpieniu zdarzenia, o którym Uczestnik powinien zostać powiadomiony. Rodzaj instrukcji określony jest w polu MsgData, które wypełniane jest w zależności od procesu biznesowego, którego dotyczy. Budowę zawartości pola MsgData opisuje poniższy punkt (otcd.ntf.001.01 powiadomienie dotyczące obsługi rynku OTC). W zależności od rodzaju instrukcji wykorzystywane są odpowiednie struktury danych. Zawartość komunikatu <?xml version="1.0" encoding="utf-8"?> <KDPWDocument Sndr="0010" Rcvr="XXXX" xmlns="urn:kdpw:xsd:otcd.ntf.001.01" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" > <otcd.ntf.001.01> <GnlInf> <SndrMsgRef>Notification1</SndrMsgRef > <FuncOfMsg>NEWM</FuncOfMsg > <CreDtTm> <DtTm>2011-04-01T10:00:00</DtTm> </CreDtTm> <SeqNb>123</SeqNb> <NtfTp>NOTIFICATION_TYPE</NtfTp > </GnlInf> Opis Standardowy nagłówek komunikatu Identyfikator komunikatu nadany przez KDPW_CCP Funkcja komunikatu stała wartość NEWM Data i czas utworzenia komunikatu Numer kolejny powiadomienia generowany jako wielkość globalna utrzymywana dla całego systemu KDPW_CCP niezależnie od adresatów powiadomienia. Wielkość jest unikalna, co może być wykorzystywane do weryfikacji komunikatów w przypadku ich retransmisji. Typ komunikatu powiadamiającego skojarzony z konkretnym przepływem biznesowym. 13

<MsgData> </MsgData> </otcd.ntf.001.01> Zawartość powiadomienia dotyczącego rynku OTC zgodna z określonym procesem biznesowym. Patrz dokument: Elementy składowe komunikatów OTC w odniesieniu do procesów biznesowych 14

Sposoby budowania części biznesowej komunikatów otcd.rqi.001.01 instrukcja obsługi rynku OTC Do komunikatu należy zastosować podwójna walidację. Najpierw należy walidować komunikat zgodnie ze schematem otcd.rqi.001.01.xsd. Po poprawnej walidacji, z komunikatu należy pobrać wartość elementu KDPWDocument/otcd.rqi.001.01/GnlInf/ProcessId i w zależności od wartości tego elementu należy dobrac odpowiedni schemat do drugiego etapu walidacji zgodnie z poniższą tabelą. Nazwa procesu biznesowego (ProcessID) OnDemandTermination OnDemandTerminationAcceptance AccountMaintenance HypoteticalPortfolio AuctionQuote Schemat XML otcd.rqi.001.01.ondemantterminationrequest.xsd otcd.rqi.001.01.ondemandterminationacceptance.xsd otcd.rqi.001.01.accountmaintenancerequest.xsd otcd.rqi.001.01.hypoteticalportfolirequest.xsd otcd.rqi.001.01.auctionquoterequest otcd.rsi.001.01 status realizacji instrukcji obsługi rynku OTC wersja 1 Po otrzymaniu komunikatu otcd.rsi.001.01 z KDPW, należy zastosować podwójną walidację komunikatu. Najpierw powinna nastąpić walidacja komunikatu zgodnie ze schematem otcd.rsi.001.01.xsd. Po poprawnej walidacji, należy odszukać komunikat otcd.rqi.001.01, w którym wartość pola KDPWDocument/otcd.rqi.001.01/GnlInf/SndrMsgRef jest identyczna jak wartość pola KDPWDocument/otcd.rsi.001.01/GnlInf/Lnk/RltdRef otrzymanej odpowiedzi z systemu kdpw_otc. Następnie należy odczytać wartość pola KDPWDocument/otcd.rqi.001.01/GnlInf/ProcessId z wcześniej wysłanego komunikatu i na podstawie wartości pola ProcessId oraz poniższej tabeli należy określić jaki schemat ma być użyty do drugiego etapu walidacji. ProcessID (komunikat otcd.rqi.001.01) AccountMaintenance AuctionQuote HypotheticalPortfolio OnDemandTermination OnDemandTerminationAcceptance Schemat XML (komunikat otcd.rsi.001.01) otcd.rsi.001.01.accountmaintenanceresponse.xsd otcd.rsi.001.01.auctionerror.xsd otcd.rsi.001.01.participantnotification otcd.rsi.001.01.ondemandterminationresponse.xsd otcd.rsi.001.01.ondemandterminationresponse.xsd otcd.rsi.001.01 status realizacji instrukcji obsługi rynku OTC wersja 2 Po otrzymaniu komunikatu otcd.rsi.001.01 z KDPW, należy zastosować podwójną walidację komunikatu. Najpierw powinna nastąpić walidacja komunikatu zgodnie ze schematem 15

otcd.rsi.001.01.xsd. Po poprawnej walidacji, z komunikatu należy pobrać element KDPWDocument/otcd.rsi.001.01/MsgData/Content/contents/content i na podstawie typu tego pola dobrać odpowiedni schemat XML do drugiego etapu walidacji zgodnie z poniższą tabelą. Nazwa typu accountmaintenanceresponse auctionerror ondemandterminationresponse participantnotification Schemat XML otcd.rsi.001.01.accountmaintenanceresponse.xsd otcd.rsi.001.01.auctionerror.xsd otcd.rsi.001.01.ondemandterminationresponse.xsd otcd.rsi.001.01.participantnotification otcd.ntf.001.01 powiadomienie dotyczące obsługi rynku OTC Po otrzymaniu komunikatu ocd.ntf.001.01 z KPDW, należy zastosować podwójną walidację komunikatu. Najpierw komunikat powinien być walidowany zgodnie ze schematem otcd.ntf.001.01.xsd. Po poprawnej walidacji, z komunikatu należy pobrać wartość elementu KDPWDocument/otcd.ntf.001.01/GnlInf/NtfTp i w zależności od wartości tego elementu należy dobrać odpowiedni schemat XML do drugiego etapu walidacji zgodnie z poniższą tabelą. Wartość pola AUCTION AUCTION_NOTICE AUCTION_RESULT AUCTION_TIMEOUT AUTOMATIC_TERMINATION_SUMMARY PARTICIPANT_STATE ONDEMAND_RESPONSE ONDEMAND_RESULT TRADE_STATE SETTLEMENTS REPORT Schemat XML otcd.ntf.001.01.auctiondetail.xsd otcd.ntf.001.01.auctionnotification.xsd otcd.ntf.001.01.auctionresult.xsd otcd.ntf.001.01.auctiontimeout.xsd otcd.ntf.001.01.automaticterminationsummary.xsd otcd.ntf.001.01.clearingmemberstatus.xsd otcd.ntf.001.01.ondemandterminationresponse.xsd otcd.ntf.001.01.ondemandterminationresult.xsd otcd.ntf.001.01.participantnotification.xsd otcd.ntf.001.01.positionbalancesettlements.xsd otcd.ntf.001.01.externalreport.xsd 16