OPIS INTERFACE WYMIANY DANYCH SYSTEMU EPO (MS) Z SYSTEMEM OPERATORA

							

Wersja 1.0
Białystok 4 luty.2015

Spis treści
1	Wstęp
2	Słownik pojęć i skrótów
3	Opis komunikacji B2B
3.1	Zasady budowania komunikatów
3.1.1	Protokół logiczny
3.1.2	Format komunikatów
3.1.3	Format identyfikatora komunikatu
3.2	Opis komunikatów
3.2.1	AddMailListRequest
3.2.2	AddMailListResponse
3.2.3	MailStatusChangeNotify
3.2.4	GetMailStatisticRequest
3.2.5	GetMailStatisticResponse
3.2.6	AddDeliveryConfirmationRequest
3.2.7	AddDeliveryConfirmationResponse
3.2.8	GetAPIVersion
4	Lista załączników

1	
 Wstęp
Dokument jest przeznaczony dla zespołów projektowych operatorów pocztowych realizujących integracje własnych systemów z systemem EPO Ministerstwa Sprawiedliwości .
Niniejszy dokument opisuje interfejsy komunikacyjne wykorzystywane do komunikacji pomiędzy EPO a Systemami Operatorów Pocztowych. Szczegółowy opis techniczny interfejsów załączony jest do niniejszego dokumentu w postaci:
•	Opisów struktury dokumentów XML (tzw. schematów XML – pliki zakończone rozszerzeniem .xsd). Treść dokumentów XML zbudowanych zgodnie z załączonymi schematami stanowi zawartość komunikatów i pozwala na wymianę danych pomiędzy wspomnianymi systemami.
•	Plików WSDL, zawierających specyfikację interfejsów usług Web Services, pośredniczących w wymianie komunikatów pomiędzy EPO a SOP.

Dokument zawiera również:
•	słownik najważniejszych pojęć i terminów, wykorzystywanych w opisie interfejsów;
•	opis poszczególnych komunikatów, wyjaśniający ogólne ich zastosowanie oraz rolę w komunikacji pomiędzy EPO a SOP;
•	opis dodatkowych reguł biznesowych oraz ograniczeń dla danych.
2	Słownik pojęć i skrótów
Lp.	Pojęcie	Skrót	Znaczenie	
1.	Elektroniczne Potwierdzenie Odbioru	EPO	Będący własnością Ministerstwa Sprawiedliwości, system teleinformatyczny służący do obsługi elektronicznego formularza potwierdzenia odbioru sądu wysyłającego w rozumieniu nowelizacji z dnia 19.04.2013 r rozporządzenia Ministra Sprawiedliwości z dnia 12 października 2010r. w sprawie szczegółowego trybu i sposobu doręczania pism sądowych w postępowaniu cywilnym (Dz. U. Nr 190, poz. 1277 oraz z 2012 r. poz. 758)	
2.	Operator Pocztowy		Podmiot świadczący na rzecz sądów powszechnych usługi w zakresie obrotu korespondencji w rozumieniu ustawy z dnia 23 listopada 2012 r. – Prawo pocztowe (Dz. U. poz. 1529).	
3.	System Operatora Pocztowego	SOP	System, z którym za pośrednictwem B2B ma się komunikować EPO.	
4.	Interfejs B2B	B2B	Dwukierunkowy interfejs systemu EPO do systemu operatora pocztowego stanowiący główny produkt zamówienia	
5.	Elektroniczna Książka Nadawcza	EKN	Elektroniczna struktura danych zawierająca spis przesyłek rejestrowanych przekazywanych przez sąd operatorowi pocztowemu do doręczenia	
6.	Hypertext Transfer Protocol	HTTP	Protokół przesyłania dokumentów hypertekstowych) to protokół sieci WWW (ang. World Wide Web). Obecną definicję HTTP stanowi RFC 2616.	
7.	Simple Object Access Protocol	SOAP	Jeden ze standardów wykorzystywanych w technologii Web Services. Protokół wywoływania zdalnego dostępu do obiektów, wykorzystujący XML do kodowania wywołań i najczęściej HTTP do ich  przenoszenia, możliwe jest jednak wykorzystanie innych protokołów do transportu danych.	
8.	Web Services Description  Language	WSDL	Jeden ze standardów wykorzystywanych w technologii Web Services. Język opisuje protokoły i formaty używane przez Web Services.	
9.	XML Schema Definition	XSD	Opracowany przez W3C (www.w3c.org) standard służący do definiowania struktury dokumentu XML.	
10.	Extensible Markup Language	XML	Uniwersalny język formalny przeznaczony do  reprezentowania różnych danych w ustrukturalizowany sposób. XML jest niezależny od platformy.	
11.	Moduł Komunikacji z Systemem Operatora Pocztowego	MKzSOP	Część EPO odpowiedzialna za komunikację z SOP. Moduł ten wykorzystuje technologię WebService po http.	
3	Opis komunikacji B2B
Interfejs pomiędzy EPO a SOP zrealizowany jest w oparciu o protokół Web Services w określonym przez Web Services Interoperability Organization (WS–I, www.ws–i.org) profilu – Basic Profile 1.1.
Zastosowanie technologii Web Services do budowy interfejsów z systemami zewnętrznymi jest zgodne z najnowszymi kierunkami rozwoju tej gałęzi inżynierii SOA (ang. Service Oriented Architecture), gdzie technologia Web Services jest jednym z podstawowych motorów rozwiązania. Dodatkowo, technologia Web Services jest szeroko wspierana przez dostawców technologii i rozwiązań IT oraz zapewnia szeroką interoperacyjność. Technologia Web Services zbudowana jest na bazie XML, dzięki czemu zapewniona jest niezależność pomiędzy platformami klienta i serwera.
3.1	Zasady budowania komunikatów
3.1.1	Protokół logiczny
W B2B w warstwie protokołów logicznych założono wykorzystanie następujących typów komunikacji:
•	synchroniczny – komunikat/odpowiedź
•	asynchroniczny – komunikat/odpowiedź
•	asynchroniczny – powiadomienie

Tryb synchroniczny zostanie użyty zawsze tam, gdzie odpowiedź zwracana jest natychmiast po wykonaniu operacji. Zachodzi to również dla przypadku, w którym ostateczna odpowiedź z EPO/SOP nie jest natychmiastowa, ale zwracany jest pośredni status operacji (przyjęcie zgłoszenia). W B2B, tryb synchroniczny jest używany do przekazania przez operatora zmiany statusu przesyłki MailStatusChangeNotify oraz do testów komunikacji, czyli metody GetAPIVersion. Pozostałe operacje wykorzystują logiczny tryb asynchroniczny (komunikat/odpowiedź lub powiadomienie).
3.1.2	Format komunikatów
Zgodnie z założeniami, komunikaty mają format plików XML o strukturze zdefiniowanej poprzez schematy XML. Komunikaty wejściowe w nagłówkach SOAP będą zawierały podstawowe dane o  komunikacie:
•	EPOHeader/IDKomunikat – unikalny identyfikator komunikatu nadawany przez system, z którego pochodzi komunikat;
•	EPOHeader/IDKomunikatZrodlowy – wypełniany przy odpowiedzi asynchronicznej, wypełnienie w odpowiedzi synchronicznej nie jest wymagane; identyfikator pozwalający przy komunikacji asynchronicznej połączyć komunikat wejściowy z odpowiedzią;
•	EPOHeader/DataKomunikatu – data i czas wypełniany przez system wysyłającym komunikat;
•	EPOHeader/APIVersion – wersja API, która będzie używana w części właściwej (BODY) komunikatu.

Przykładowy komunikat GetAPIVersion (pełna wiadomość SOAP), który jako jedyny nie posiada nagłówka EPOHeader:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
  </s:Header>
  <s:Body>
    <GetAPIVersionRequest xmlns="http://msepo.gov.pl/epo/webservice/V1/" />
  </s:Body>
</s:Envelope>

Odpowiedź synchroniczna na ten komunikat:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
  </s:Header>
  <s:Body>
    <GetAPIVersionResponse xmlns="http://msepo.gov.pl/epo/webservice/V1/">
      <WersjaAPI>1.0.0</WersjaAPI>
    </GetAPIVersionResponse>
  </s:Body>
</s:Envelope>

Na każdy komunikat (oprócz GetAPIVersion) uczestniczący w komunikacji asynchronicznej wymagane jest odesłanie synchronicznej odpowiedzi potwierdzającej przyjęcie zgłoszenia po wstępnej weryfikacji komunikatu. Element EPOSyncResponse powinien zawierać pola:
•	EPOSyncResponse/Rezultat – kod po wstępnej weryfikacji (1 - OK, inne kody – kody błędu zgodnie z opisem w 3.2)
•	EPOSyncResponse/RezultatOpis – opis błędu.

 Przykładowa odpowiedź synchroniczna na logicznie asynchroniczny komunikat:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <h:EPOHeader xmlns:h="http://msepo.gov.pl/epo/webservice/V1/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
      <h:APIVersion>1.0.0</h:APIVersion>
      <h:DataKomunikatu>2014-01-01T00:00:00</h:DataKomunikatu>
      <h:IDKomunikat>02000000000000000015</h:IDKomunikat>
      <h:IDKomunikatZrodlowy>010000000000000000012</h:IDKomunikatZrodlowy>
    </h:EPOHeader>
  </s:Header>
  <s:Body>
    <EPOSyncResponse xmlns="http://msepo.gov.pl/epo/webservice/V1/">
      <Rezultat>1</Rezultat>
      <RezultatOpis />
    </EPOSyncResponse>
  </s:Body>
</s:Envelope>

3.1.3	Format identyfikatora komunikatu
Format pola IDKomunikat oraz IDKomunikatZrodlowy został dobrany tak, aby był unikalny w ramach całego MKzSOP. 
Pole IDKomunikat jest polem zawsze wymaganym, jego wartość musi być nadawana i zapisywana przez każdą ze stron komunikacji zgodnie z formatem:
a)	Długość całkowita pola to 20 znaków.
b)	Dwa pierwsze znaki (licząc od lewej) oznaczają identyfikator strony wysyłającej komunikat, przy czym wartość „01” jest zarezerwowana dla MKzSOP; wartości dla operatorów pocztowych zostaną przydzielone przez administratorów MKzSOP.
c)	Pozostałe znaki oznaczają unikatowy identyfikator w ramach strony wysyłającej komunikat.
Nieprawidłowy format pola lub wysłanie komunikatu z wykorzystanym już wcześniej identyfikatorem skutkuje odrzuceniem komunikatu.
3.2	Opis komunikatów
W celu realizacji odpowiednich funkcji w systemach EPO i SOP, pomiędzy nimi wymieniane są komunikaty elektroniczne o określonej strukturze. W niniejszym rozdziale przedstawiono krótką charakterystykę poszczególnych komunikatów. Dokładne informacje o ich strukturze można zaczerpnąć z plików opisujących format dokumentów XML, służących do przesyłania komunikatów (pliki *.xsd). 
Kolejność opisu poszczególnych komunikatów wynika z grupowania logicznego typów operacji.
3.2.1	AddMailListRequest
Metoda systemu: SOP
Strona wywołująca: EPO
Komunikacja: asynchroniczna

Komunikat służy do przekazania książki nadawczej (EKN) z EPO do operatora. W przypadku wystąpienia błędu na etapie odpowiedzi synchronicznej, książka nadawcza jest odrzucana w całości.
Parametry wywołania:
•	KodOperacji (0 – nadanie; 1 – wycofanie EKN)
•	NadawcaNazwa (zgodnie ze strukturą zbioru EKN)
•	NadawcaNazwaSkrocona (zgodnie ze strukturą zbioru EKN)
•	Plik (zgodnie ze strukturą zbioru EKN –  ) skompresowany (Zip – (format gzip)) w formacie Base64
•	PlikGuid (identyfikator pliku)
•	PlikSumaKontrolna (suma kontrolna md5 pliku ze zbiorem EKN)

Przy operacji nadania EKN wymagane jest wypełnienie wszystkich parametrów komunikatu.
Przy operacji wycofania pliku wymagane jest wypełnienie parametrów KodOperacji = 1 i PlikGuid. 

Odpowiedź synchroniczna:
EPOSyncResponse/Rezultat 
1 - plik został pomyślnie zarejestrowany do przetwarzania/wycofania 
-1 - inny błąd (opis w polu EPOSyncResponse /RezultatOpis)
-2   EKN (zbiór)  został już zarejestrowany
-3 – inny błąd

Przykładowy komunikat:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
	<…>
  </s:Header>
  <s:Body>
    <AddMailListRequest xmlns="http://msepo.gov.pl/epo/webservice/V1/">
      <KodOperacji>0</KodOperacji>
      <NadawcaNazwa>Sąd Apelacyjny w Białymstoku</NadawcaNazwa>
      <NadawcaNazwaSkrocona>SAB</NadawcaNazwaSkrocona>
      <Plik>YXNkLWY3cWFzZDk4NmYwYXNkNzg2ZnZxMGFjZDg2N2ZxZDhlZjY3cWQwcyBmNmFzZDBmOWE3c2Q2</Plik>
      <PlikGuid>74e48218-fc81-473e-903a-8c9b50762393</PlikGuid>
      <PlikSumaKontrolna>91162629d258a876ee994e9233b2ad87</PlikSumaKontrolna>
    </AddMailListRequest>
  </s:Body>
</s:Envelope>

3.2.2	AddMailListResponse
Metoda systemu: EPO
Strona wywołująca: SOP
Komunikacja: asynchroniczna odpowiedź na komunikat AddMailListRequest

Komunikat służy do potwierdzenia przez SOP statusu walidacji poszczególnych przesyłek w przesłanej EKN. W momencie kiedy przetwarzanie książki nadawczej zostało zakończone po stronie operatora (Rezultat = 1) zostanie zwrócony w polu Plik dokument XML (zakodowany w Base64) zawierający rezultat rejestracji w systemie centralnym operatora pocztowego każdej przesyłki z Książki Nadawczej. 
Walidacja przesyłek obejmuje weryfikację unikalności Numeru Nadania w systemie operatora pocztowego. Dane adresowe przesyłek nie są weryfikowane i przesyłki z poprawnymi Numerami Nadania są przyjmowane do obiegu pocztowego.

Przykładowa struktura pliku XML:
<Zbior IloscPrzesylek=”2” Guid=”{B290A370-9A8B-48A4-8D2A-21AED9051B82}”>
<PrzesylkaEPO Guid="{F555DCD0-17C5-4A86-BCF4-5D2206403514}">
<Atrybut Nazwa="NrNadania">188140434000</Atrybut>
<Rezultat>1<Rezultat>
</PrzesylkaEPO>
<PrzesylkaEPO Guid="{F555DCD0-17C5-4A86-BCF4-5D2206403515}">
<Atrybut Nazwa="NrNadania">188140434000</Atrybut>
<Rezultat>2<Rezultat>
</PrzesylkaEPO>
</Zbior>

Rezultat w pliku XML oznacza: 
1 – przesyłka zarejestrowana w systemie operatora, 
2 – numer nadania został już wykorzystany, 
3- przesyłka o podanym Guid została już zarejestrowana, 
4 – inny błąd

Parametry wywołania :
Rezultat (1 – OK, -1 –-1 - błąd sumy kontrolnej, -2 - błąd formalny struktury XML pliku, -3 - brak możliwości wycofania książki nadawczej (EKN), -4 inny błąd 
•	)
•	RezultatOpis (opis błędu)
•	Plik (skompresowany plik XML w formacie Base64)

Odpowiedź synchroniczna:
EPOSyncResponse/Rezultat 
1 – OK
-1 - inny błąd (opis w polu EPOSyncResponse /RezultatOpis)

Przykładowy komunikat:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
<…>
  </s:Header>
  <s:Body>
    <AddMailListResponseRequest xmlns="http://msepo.gov.pl/epo/webservice/V1/">
      <Rezultat>1</Rezultat>
      <RezultatOpis i:nil="true" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" />
      <Plik>YXNkLWY3cWFzZDk4NmYwYXNkNzg2ZnZxMGFjZDg2N2ZxZDhlZjY3cWQwcyBmNmFzZDBmOWE3c2Q2</Plik>
    </AddMailListResponseRequest>
  </s:Body>
</s:Envelope>
3.2.3	MailStatusChangeNotify
Metoda systemu: EPO
Strona wywołująca: SOP
Komunikacja: powiadomienie

Metoda będzie wywoływana w przypadkach:
a)	Pierwszego pojawiania się przesyłki w placówce operatora (np.  nadawczej/sortowni )
Zdarzenie to odpowiada pierwszemu odnotowaniu fizycznego posiadania przesyłki przez operatora
b)	Zmian statusu przesyłek w trakcie ich procesowania przez operatora pocztowego.

Parametry wywołania:
•	PrzesylkaId (identyfikator Guid przesyłki w systemie EPO, zgodnie ze strukturą zbioru EKN)
•	NumerNadania (identyfikator przesyłki)
•	StatusPrzesylki (id statusu przesyłki zgodnie z słownikiem) – wymaga się by raportowane były co najmniej statusy: 
a) w urzędzie oddawczym (5) – przy pierwszym fizycznym zarejestrowaniu przesyłki w SI opraratora
b) dowiązana do karty EPO (36 ) – przy umieszczeniu na liście doręczeń ( tablecie )
c) Awizo1  ( wraz z określeniem miejsca pozostawienia zawiadomienia)
d) Awizo2 
e) zakończona ścieżką tradycyjną (57) 
  
•	StatusUwagi (pole opisowe dla statusu wykorzystywane do przekazania dodatkowych informacji np. oznaczenia i adresu placówki awizacyjnej, ozanczenia placówki oddawczej (dowiązanie do karty EPO ) )
•	DataStatusu (data zmiany statusu z dokładnością do sekund) 

Odpowiedź synchroniczna:
EPOSyncResponse/Rezultat 
1 – zmiana statusu przyjęta
-1 – błąd (opis w polu EPOSyncResponse /RezultatOpis)

Przykładowy komunikat:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
	<…>
  </s:Header>
  <s:Body>
    <MailStatusChangeNotifyRequest xmlns="http://msepo.gov.pl/epo/webservice/V1/">
      <DataStatusu>2014-10-20T10:30:00</DataStatusu>
      <NumerNadania>123</NumerNadania>
      <PrzesylkaId>bf06ee36-94f5-41d2-a667-35fa3aa55992</PrzesylkaId>
      <StatusPrzesylki>1</StatusPrzesylki>
      <StatusUwagi>BRAK</StatusUwagi>
    </MailStatusChangeNotifyRequest>
  </s:Body>
</s:Envelope>

3.2.4	GetMailStatisticRequest
Metoda systemu: SOP
Strona wywołująca: EPO
Komunikacja: asynchroniczna

Metoda ma na celu pobranie statystyk z systemu operatora w celu ich porównania z danymi w EPO.

Parametry wywołania:
•	DataOd (data rozpoczęcia okresu, włącznie)
•	DataDo (data końca okresu, włącznie)
•	ListaWartosci (lista wartości typu <key><value> obliczona przez MS zawierająca stan przesyłek w EPO. Zakodowana w Base64)

Odpowiedź synchroniczna:
EPOSyncResponse/Rezultat 
1 – zapytania zarejestrowane pomyślnie
-1 – inny błąd (opis w polu EPOSyncResponse /RezultatOpis)
-2 – niepoprawne daty

Przykładowy komunikat:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
	<…>
  </s:Header>
  <s:Body>
    <GetMailStatisticRequest xmlns="http://msepo.gov.pl/epo/webservice/V1/">
      <DataDo>2014-10-19T10:38:00</DataDo>
      <DataOd>2014-10-20T10:38:00</DataOd>
      <ListaWartosci>
	 <Wskaznik>
	    <Nazwa>PrzekazaneDoOperatora</Nazwa>
	    <Wartosc>1000</Wartosc>
	 </Wskaznik>
	 <Wskaznik>
	    <Nazwa>Doreczone</Nazwa>
	    <Wartosc>100</Wartosc>
	 </Wskaznik>
	 <Wskaznik>
	    <Nazwa>Wydane</Nazwa>
	    <Wartosc>800</Wartosc>
	 </Wskaznik>
	 <Wskaznik>
	    <Nazwa>Zwrocone</Nazwa>
	    <Wartosc>500</Wartosc>
	 </Wskaznik>
      </ListaWartosci>
    </GetMailStatisticRequest>
  </s:Body> 
</s:Envelope>
3.2.5	GetMailStatisticResponse
Metoda systemu: EPO
Strona wywołująca: SOP
Komunikacja: asynchroniczna odpowiedź na GetMailStatisticRequest

Parametry wywołania:
•	ListaWartosci (lista wartości typu <key><value> obliczona przez MS zawierająca stan przesyłek w EPO. Zakodowana w Base64)

Odpowiedź synchroniczna:
EPOSyncResponse/Rezultat 
1 – odpowiedź zarejestrowana pomyślnie
-1 – inny błąd (opis w polu EPOSyncResponse /RezultatOpis)
-2 – brak komunikatu źródłowego

Przykładowy komunikat:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
	<…>
  </s:Header>
  <s:Body>
    <GetMailStatisticRequest xmlns="http://msepo.gov.pl/epo/webservice/V1/">
      <ListaWartosci>
	 <Wskaznik>
	    <Nazwa>PrzekazaneDoOperatora</Nazwa>
	    <Wartosc>1000</Wartosc>
	 </Wskaznik>
	 <Wskaznik>
	    <Nazwa>Doreczone</Nazwa>
	    <Wartosc>100</Wartosc>
	 </Wskaznik>
	 <Wskaznik>
	    <Nazwa>Wydane</Nazwa>
	    <Wartosc>800</Wartosc>
	 </Wskaznik>
	 <Wskaznik>
	    <Nazwa>Zwrocone</Nazwa>
	    <Wartosc>500</Wartosc>
	 </Wskaznik>
      </ListaWartosci>
    </GetMailStatisticRequest>
  </s:Body> 
</s:Envelope>
3.2.6	AddDeliveryConfirmationRequest
Metoda systemu: EPO
Strona wywołująca: SOP
Komunikacja: asynchroniczna

Informacja o osiągnieciu przez przesyłkę statusu końcowego:
•	doręczenie;
•	wydanie po awizacji;
•	zwrot;
•	zwrot przesyłki niepodjętej.

Elektroniczne potwierdzenie odbioru będzie przekazywane w polu KartaEPO w zakodowanym w Base64 pliku w formacie XML zgodnie z przekazanym plikiem XSD.

Parametry wywołania:
•	PrzesylkaId (identyfikator Guid przesyłki w systemie EPO, zgodnie ze strukturą zbioru EKN)
•	NumerNadania (identyfikator przesyłki)
•	StatusPrzesylki (id statusu przesyłki zgodnie z słownikiem)
•	StatusUwagi (pole opisowe dla statusu wykorzystywane do przekazania dodatkowych informacji np. adresu awizacji dla statusów Awizowano)
•	DataStatusu (data zmiany statusu z dokładnością do sekund)
•	KartaEPO (jedna pozycja karty EPO, dotycząca pojedynczej przesyłki; zgodnie z )
Skompresowana gzip oraz zamieniona na base64
Odpowiedź synchroniczna:
EPOSyncResponse/Rezultat 
1 – zgłoszenie EPO zostało zarejestrowane
-1 – inny błąd (opis w polu EPOSyncResponse /RezultatOpis)

Przykładowy komunikat:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
	<…>
  </s:Header>
  <s:Body>
    <AddDeliveryConfirmationRequest xmlns="http://msepo.gov.pl/epo/webservice/V1/">
      <DataStatusu>2014-10-20T10:49:00</DataStatusu>
      <KartaEPO>
	 <…>
      </KartaEPO>
      <NumerNadania>123</NumerNadania>
      <PrzesylkaID>f884440b-5702-4398-8aa5-8c54f70e8e3c</PrzesylkaID>
      <StatusPrzesylki>11</StatusPrzesylki>
      <StatusUwagi>BRAK</StatusUwagi>
    </AddDeliveryConfirmationRequest>
  </s:Body> 
</s:Envelope>

Znaczenie  zawartości istotnych znaczników:
StausPrzesylki:
		2 – Doręczona
			0 – Adresatowi
			1 – Dorosłemu domownikowi
			2  - Dozorcy
			3 – Sołtysowi
			4  - Administracji domu
			5- Upoważnionemu pracownikowi
		4-  Brak doręczenia ( przez kuriera/listonosza)  - uwaga – nie należy przekazywać informacji  np.: doręczyciel nie zdążył  )
BrakDoreczenia
					0: adresat odmówił przyjęcia
					 1: Niepełny adres
					2: Nie doręczona z innych przyczyn
BrakDoreczeniaInnaPrzyczyna – znacznik opisowy;  
		5 Wydana  (po awizo)
			OdbiorcaPrzesylki:
				0: Adresat
				1: Upoważniony Pracownik
				2: Osobie uprawnionej do reprezentacji
				3: Pełnomocnik pocztowy

		6 Zwrot (przesyłki po awizo )

	BrakDoreczenia
					0: adresat odmówił przyjęcia
					2: Nie doręczona z innych przyczyn
BrakDoreczeniaInnaPrzyczyna – znacznik opisowy;
3 – Nie podjęto przesyłki z placówki pocztowej/Urzędu gminy

Dla StatusPrzesylki =  2 lub 4  wypełniamy znacznik Doreczyciel
Dla StatusPrzesylki =  5 lub 6  wypełniamy znacznik Wydajacy

Wymagania dla podpisu elektronicznego
	Format: Pkcs#7 (Cms - .Net) podpis zewnętrzny , nie zawiera certyfikatów
	Dane podpisywane – Zawartość znacznika TabletPrzesylka wraz z samym znacznikiem
	Podpis jest  zapisany w znaczniku Podpis (na zewnątrz TabletPrzesylka) w base64 
	 
3.2.7	AddDeliveryConfirmationResponse
Metoda systemu: SOP
Strona wywołująca: EPO
Komunikacja: asynchroniczna odpowiedź na AddDeliveryConfirmationResponse

Potwierdzenie przyjęcia potwierdzenia EPO.

Parametry wywołania:
•	PrzesylkaId (identyfikator Guid przesyłki w systemie EPO, zgodnie ze strukturą zbioru EKN)
•	Rezultat (1- EPO zarejestrowano; -1 – brak takiej przesyłki (odrzucono); -2 – błąd walidacji podpisu (odrzucona); -3 Bład walidacji XML; -4 Brak takiej przesyłki w systemie MS;  -5 przesyłka została uprzednio zamknięta ( zakończono doręczenie);     -6 – inny błąd);
-10 –błąd zwrotu przesyłki niepodjętej; -11 błąd merytoryczny w procesie (np. wydanie przesyłki, która nie była awizowana);   
•	RezultatOpis (opcjonalny opis tekstowy)

Odpowiedź synchroniczna:
EPOSyncResponse/Rezultat 
1 – odpowiedź przyjęto
-1 – inny błąd (opis w polu EPOSyncResponse /RezultatOpis)
-2 – brak komunikatu źródłowego

Przykładowy komunikat:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
	<…>
  </s:Header>
  <s:Body>
   <AddDeliveryConfirmationResponse xmlns="http://msepo.gov.pl/epo/webservice/V1/">
      <PrzesylkaID>f884440b-5702-4398-8aa5-8c54f70e8e3c</PrzesylkaID>
      <Rezultat>1</Rezultat>
      <RezultatOpis i:nil="true" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" />
    </AddDeliveryConfirmationResponse>
  </s:Body>  </s:Body> 
</s:Envelope>

3.2.8	GetAPIVersion
Metoda systemu: SOP/EPO
Strona wywołująca: EPO/SOP
Komunikacja: synchroniczna

Para metod w systemie operatora i EPO. Służy jako  test komunikacji pomiędzy systemami EPO i SOP.
Parametry wywołania:
•	brak

Odpowiedź synchroniczna:
GetAPIVersionResponse/WersjaAPI 

Przykładowy komunikat:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <h:EPOHeader xmlns:i=http://www.w3.org/2001/XMLSchema-instance xmlns:h="http://msepo.gov.pl/epo/webservice/V1/">
      <h:APIVersion>1.0.0</h:APIVersion>
      <h:DataKomunikatu>2014-10-17T13:29:00</h:DataKomunikatu>
      <h:IDKomunikat>010000000012</h:IDKomunikat>
      <h:IDKomunikatZrodlowy i:nil="true" />
    </h:EPOHeader>
  </s:Header>
  <s:Body>
    <GetAPIVersionRequest xmlns="http://msepo.gov.pl/epo/webservice/V1/" />
  </s:Body>
</s:Envelope>

Odpowiedź synchroniczna na ten komunikat:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <h:EPOHeader xmlns:h="http://msepo.gov.pl/epo/webservice/V1/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
      <h:APIVersion>1.0.0</h:APIVersion>
      <h:DataKomunikatu>2014-01-01T00:00:00</h:DataKomunikatu>
      <h:IDKomunikat>000000000015</h:IDKomunikat>
      <h:IDKomunikatZrodlowy>12</h:IDKomunikatZrodlowy>
    </h:EPOHeader>
  </s:Header>
  <s:Body>
    <GetAPIVersionResponse xmlns="http://msepo.gov.pl/epo/webservice/V1/">
      <WersjaAPI>1.0.0</WersjaAPI>
    </GetAPIVersionResponse>
  </s:Body>
</s:Envelope>
4	Lista załączników
Integralną częścią tego dokumentu są pliki definiujące usługi sieciowej (Web Services) w formacie WSDL. Definicje te składają się z dwóch części:
1.	Interfejs od strony EPO (folder EPO_WSDL):
o	
2.	Interfejs od strony Systemu Operatora Pocztowego (folder EPO_SOP_WSDL):
o	l
3. Przykładowe dokumenty

Przed kompresją ( gzip ) oraz Base64 z podpisem
EKN

Adres środowiska testowego MS zostanie przekazany zainteresowanym stronom po nawiązaniu wzajemnej współpracy.