Załącznik nr 7 Wytyczne do wdrożenia rozwiązań technicznych



Podobne dokumenty
Jarosław Zembrzuski. Kierownik Projektu ZSIN. Warszawa, 27 września 2013 r.

Budowa Systemu ZSIN. Jarosław Zembrzuski Zastępca Dyrektora CODGiK. Szymon Rymsza Główny specjalista GUGiK. Warszawa, r.

System ZSIN wyzwanie dla systemów do prowadzenia EGiB

Zintegrowany system informacji o nieruchomościach (ZSIN) architektura i funkcjonalność

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

Aplikacja do walidacji plików XML i GML

1. Wymagania prawne. Europejskie uwarunkowania prawne:

Implementacja standardu GML w oprogramowaniu ESRI i GISPartner na przykładzie Geoportalu2

Stan zaawansowania prac dotyczących zamówienia na opracowanie i wdrożenie rdzenia systemu e Urząd.

Zintegrowany System Informacji o Nieruchomościach FAQ

ZINTEGROWANY SYSTEM INFORMACJI O NIERUCHOMOŚCIACH podstawy prawne

ROZPORZĄDZENIE RADY MINISTÓW z dnia r. w sprawie zintegrowanego systemu informacji o nieruchomościach

Kraków, 2 kwietnia 2004 r.

ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO W RAMACH PROJEKTU

ROZPORZĄDZENIE RADY MINISTRÓW z dnia r. w sprawie zintegrowanego systemu informacji o nieruchomościach

Komunikacja i wymiana danych

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI

Architektura TERYT GUS. EMUiA. EGiB. Pozostałe systemy ZSIN SZYNA USŁUG. EMUiA

Ministerstwo Finansów

DOKUMENTACJA TECHNICZNA MOZ-U

GML w praktyce geodezyjnej

Kielce, dnia roku. HB Technology Hubert Szczukiewicz. ul. Kujawska 26 / Kielce

System DiLO. Opis interfejsu dostępowego v. 2.0

Usługi danych przestrzennych w GEOPORTAL-u. Marek Szulc , Warszawa

GEOPORTAL 2. Broker INSPIRE Broker krajowy Broker branżowy. Eliza Asendy, Marek Szulc , Warszawa

Dodatkowo, w przypadku modułu dotyczącego integracji z systemami partnerów, Wykonawca będzie przeprowadzał testy integracyjne.

Warszawa, dnia 22 lutego 2013 r. Poz. 249 ROZPORZĄDZENIE RADY MINISTRÓW. z dnia 17 stycznia 2013 r.

Opis procesów biznesowych związanych z realizacją e-usług WZGiK

Etapy weryfikacji prac dotyczących dostosowania danych EGiB. Etapy odbioru prac

Procedura Walidacyjna Interfejs

INFRA. System Connector. Opis wdrożenia systemu

Nowe regulacje prawne dla potrzeb katastru nieruchomości

Tom 6 Opis oprogramowania

Projekt ZSIN. Budowa Zintegrowanego Systemu Informacji o Nieruchomościach - Faza I

Integracja Obieg Dokumentów - GiS Spis treści

Załącznik 1b - Szczegółowy opis II części zamówienia

Platforma epuap. Igor Bednarski kierownik projektu epuap2 CPI MSWiA. Kraków, r.

PUE ZUS Wysyłka elektronicznych zapytan. Instrukcja wysyłki zapytań do ZUZ-PUE za pomocą aplikacji Komornik SQL

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 2 SEAP SPECYFIKACJA XML INTERFEJS WEBSERVICE DLA PODMIOTÓW ZEWNĘTRZNYCH PL

WYSTĄPIENIE POKONTROLNE

Posiada (TAK / NIE. Zrzut ekranu. Opis funkcji

Architektura użytkowa Regionalnej Infrastruktury Informacji Przestrzennej Województwa Lubelskiego. Maciej Żuber COMARCH Polska S.A.

REJESTR ZBIORÓW DANYCH

INSTRUKCJA UŻYTKOWNIKA Generowanie Jednolitego Pliku Kontrolnego (JPK) ISO 9001:2008 Dokument: Wydanie: 1 Waga: 90

12 czerwca Piotr Kozłowski Dyrektor ds. Rozwoju Sektora Samorządowego

Rola systemu do prowadzenia ewidencji gruntów, budynków w i lokali w krajowej infrastrukturze danych przesztrzennych

Wykorzystanie standardów serii ISO oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

WARUNKI TECHNICZNE Weryfikacja zgodności treści mapy ewidencyjnej ze stanem faktycznym w terenie. Obręby 1, 2, 3, 4, 5, 6, i 7 miasta Wąbrzeźna

GŁÓWNE WĄTKI REALIZOWANE W PROJEKCIE GEOPORTAL

DOTACJE NA INNOWACJE

Płatności CashBill - SOAP

SYNCHRONIZACJA EWIDENCJI GRUNTÓW I BUDYNKÓW Z KSIĘGĄ WIECZYSTĄ. Wisła, 05 września 2012 r. mgr inż. Alicja Kulka

OPERATOR SYSTEMU PRZESYŁOWEGO

Aplikacja serwerowa Platformy Prezentacyjnej Opis produktu

Deduplikacja danych. Zarządzanie jakością danych podstawowych

Platforma epuap. Igor Bednarski kierownik projektu epuap2 CPI MSWiA. Kraków, r.

Małopolska wobec epuap

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV

WYSTĄPIENIE POKONTROLNE

ROZPORZĄDZENIE MINISTRA FINANSÓW 1) z dnia 27 stycznia 2011 r.

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

epuap Opis standardowych elementów epuap

CEL PODEJMOWANYCH DZIAŁAŃ Zapewnienie dostępu do danych i usług przestrzennych wszystkim zainteresowanym

Obowiązek wysyłania Jednolitego Pliku Kontrolnego (JPK) Instrukcja

Elektroniczna Platforma Usług Administracji Publicznej (epuap) to system informatyczny, dzięki któremu obywatele mogą załatwiać sprawy urzędowe za

INFORMACJA DLA WYKONAWCÓW PRAC GEODEZYJNYCH

Kurs OPC S7. Spis treści. Dzień 1. I OPC motywacja, zakres zastosowań, podstawowe pojęcia dostępne specyfikacje (wersja 1501)

ZAMAWIAJĄCY. CONCEPTO Sp. z o.o.

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7

Ministerstwo Finansów

Dotacje na innowacje - Inwestujemy w Waszą przyszłość ZAPYTANIE OFERTOWE

Współpraca z platformą Emp@tia. dokumentacja techniczna

Załącznik nr 1.3. Opis Przedmiotu Zamówienia (część 3) Moduł Komunikacyjny

ZSIN Budowa Zintegrowanego Systemu Informacji o Nieruchomościach Faza I

Geoportal 2 Podsumowanie realizacji projektu

REGULAMIN PRZESYŁANIA FAKTUR W FORMIE ELEKTRONICZNEJ

Warszawa, dnia 6 października 2016 r. Poz. 1626

Dlaczego GML? Gdańsk r. Karol Stachura

IZ /11 L.dz. 1916/10 Pani Alicja Meusz Dolnośląski Wojewódzki Inspektor Nadzoru Geodezyjnego i Kartograficznego

Opis modułu pl.id w programie Komornik SQL-VAT

Założenia i stan realizacji projektu epuap2

SYSTEM ZARZĄDZANIA BAZA DANYCH TOPOGRAFICZNYCH

Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B

JPK Jednolity Plik Kontrolny.

Poznań, dzień Zapytanie ofertowe

INFO-R. Instalacja pakietu programów obsługujących platformę

1. Wymagania dla lokalnej szyny ESB

Specyfikacja techniczna interfejsu do obsługi Profilu Kandydata na Kierowcę.

INFORMACJE DLA STACJI KONTROLI POJAZDÓW

Bazy danych 2. Wykład 1

Współdziałanie SłuŜby Geodezyjnej i Kartograficznej w zakresie weryfikacji danych na potrzeby PRG

Adam Augustynowicz OPEGIEKA Elbląg

Rozdział 3. ROZWÓJ APLIKACJI CENTRALNEJ

Płatniku rozlicz PIT-11 przez internet!

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

METADANE GEOINFORMACYJNE PODLASIA

DZIENNIK URZĘDOWY WOJEWÓDZTWA ŚLĄSKIEGO

Opis modułu pl.id w programie Komornik SQL-VAT

PUE ZUS Wysyłka elektronicznych zapytan. Instrukcja wysyłki zapytań do ZUZ-PUE za pomocą aplikacji Komornik SQL

GS2TelCOMM. Rozszerzenie do TelCOMM 2.0. Opracował: Michał Siatkowski Zatwierdził: IMIĘ I NAZWISKO

Transkrypt:

Załącznik nr 7 Wytyczne do wdrożenia rozwiązań technicznych dla realizacji projektu Zintegrowany System Informacji o Nieruchomościach. Etap I Działania doraźne Projekt Pilotażowy

Autor Tytuł Projekt Informacje o dokumencie: Wersja 3.5 Liczba stron 20 Artur Kapuściński Data utworzenia 2010-08-20 Data ost. modyfikacji 2011-08-17 Kontakt do uwag Nazwa pliku Wytyczne do opracowania i wdrożenia zakładanych rozwiązań Zintegrowany Systemu Informacji o Nieruchomościach. Etap I Działania doraźne Projekt Pilotażowy artur.kapuscinski@codgik.gov.pl wytyczne_techniczne_pilotazzsin_v3_5.doc Wersja Data Wersji Autor Opis 1.0 2010-08-20 Artur Kapuściński CODGiK/GUGiK 2.0 2010-09-03 Artur Kapuściński CODGiK/GUGiK 2.1 2010-09-03 Artur Kapuściński CODGiK/GUGiK 2.2 2010-09-09 Artur Kapuściński CODGiK/GUGiK 2.3 2010-09-10 Artur Kapuściński CODGiK/GUGiK 3.0 2011-02-19 Artur Kapuściński CODGiK/GUGiK 3.5 2011-03-01 Artur Kapuściński CODGiK/GUGiK 4.0 2011-08-17 Artur Kapuściński CODGiK Utworzenie dokumentu Uzupełnienie dokumentu Uzupełnienie dokumentu (pkt 5.2.3) Uwzględnienie uwag developera systemu firmy HP Uwzględnienie uwag p. Witolda Radzio. Rozszerzenie Wytycznych o warianty dostosowania systemów EGiB. Korekty tekstu w dokumencie. Rozszerzenie Wytycznych o organy podatkowe Doprecyzowanie wariantu z MOZ-U oraz dodanie modelu ZSiN

Spis treści 1. Cel dokumentu...4 2. Definicje, nazwy, skróty, pojęcia...4 3. Ogólne wymagania biznesowe...4 4. Ogólna koncepcja rozwiązania...6 4.1. Założenia i uwarunkowania...8 4.2. Ogólny model komunikacji...9 4.2.1. Obieg komunikatów dot. zmian w EGiB adresowanych do NKW...9 4.2.2. Obieg komunikatów dot. zmian w KW...11 4.2.3. Obieg komunikatów dot. zmian w EGIB adresowanych do organów podatkowych...12 5. Wymagania dla modyfikacji systemów EGiB, SIOP, IPE i NKW...13 5.1. Wymagania ogólne...13 5.2. Wymagania dla Modułu obsługi zawiadomień (MOZ)...14 5.2.1. Wymagania funkcjonalne...14 5.2.2. Wymagania niefunkcjonalne...15 5.2.3. Wdrożenie modelu danych wg schematu GML w bazie EGiB...15 5.3. Wymagania dla systemu Integrującej Platformy Elektronicznej...15 5.3.1. Wymagania funkcjonalne...15 5.3.2. Wymagania niefunkcjonalne...16 5.4. Wymagania dla systemu Nowej Księgi Wieczystej...16 5.4.1. Wymagania funkcjonalne...16 5.4.2. Wymagania niefunkcjonalne...16 5.5. Wymagania dla systemów informatycznych organów podatkowych...17 5.5.1. Wymagania funkcjonalne...17 5.5.2. Wymagania niefunkcjonalne...17 6. Dostosowanie systemów do prowadzenia EGiB...17 6.1. Wariant I...18 6.2. Wariant II...18 7. Dostosowanie systemów informatycznych organów podatkowych...19 8. Specyfikacja komunikacji między systemami...19 8.1. Opis użytych technologii...19 8.2. Struktura komunikatów...19 8.2.1. Usługa ZsinIpeMozSerwis...20 8.2.2. Usługa ZsinIpeNkwSerwis...22 8.2.3. Usługa ZsinNkwIpeSerwis...23 9. Załączniki...24 9.1. XSD wykorzystywane w usługach...24 9.2. WSDL usługi w systemie IPE dla modułu MOZ...24 9.3. WSDL usługi w systemie IPE dla systemu NKW...24 9.4. WSDL usługi w systemie NKW dla systemu IPE...24 9.5. XSD dla zawiadomień o zmianach w EGIB...24 9.6. XSD dla zawiadomień o zmianach w NKW...24 9.7. XSD dla komunikatów zmian z systemu EGiB...24

1. Cel dokumentu Niniejszy dokument ma za zadanie przedstawienie kluczowych wymagań oraz wytycznych technicznych (ze szczególnym uwzględnieniem zagadnień dot. interoperacyjności) dla rozwiązań technicznych, będących przedmiotem realizacji projektu Zintegrowany Systemu Informacji o Nieruchomościach. Etap I Działania doraźne Projekt Pilotażowy (zwanego dalej Pilotażem ). Wytyczne mają także stanowić podstawę do późniejszego wyspecyfikowania szczegółowych wymagań funkcjonalnych i niefunkcjonalnych na modyfikację/dostosowanie systemów informatycznych objętych Pilotażem w tym: Integrującej Platformy Elektronicznej, Nowej Księgi Wieczystej, lokalnych systemów do prowadzenia EGIB oraz systemów informatycznych wykorzystywanych przez organy podatkowe 2. Definicje, nazwy, skróty, pojęcia O ile w niniejszym dokumencie nie wskazano inaczej, następujące wyrażenia będą miały poniższe znaczenia: Wyrażenie Ustawa ZSIN Założenia do Pilotażu EGiB IPE lub System IPE CBKW NKW System NKW SIOP MOZ lub Moduł MOZ lub Znaczenie Ustawa z dnia 17 maja 1989 - Prawo geodezyjne i kartograficzne (Dz.U.2005.240.2027 tekst jednolity) Zintegrowany System Informacji o Nieruchomościach Dokument Założenia do projektu mającego na celu pilotażowe wdrożenie nowych funkcjonalności w systemie Integrującej Platformy Elektronicznej (IPE) Ewidencja gruntów i budynków System Integrującej Platformy Elektronicznej, centralny komponent tworzonego ZSIN zawierający centralne repozytorium kopii zbiorów EGiB Centralna Baza Ksiąg Wieczystych (centralny komponent systemu NKW) System Nowej Księgi Wieczystej Skrót przyjęty na potrzeby dokumentu, reprezentujący dowolny system informatyczny organów podatkowych wykorzystywany przy naliczaniu podatku od nieruchomości, podatku rolnego lub podatku leśnego. Moduł obsługi zawiadomień moduł lokalny po stronie EGiB komunikujący się z systemem IPE 3. Ogólne wymagania biznesowe Wymagania biznesowe dla rozwiązań technicznych będących przedmiotem prac implementacyjnych wynikają bezpośrednio z celu głównego Pilotażu, jakim jest wdrożenie

wybranych przepisów Ustawy tj. Art. 24b ust. 1 pkt 1, 3, 4. Dla kompletności poniżej przytoczono kluczowe zapisy w/w artykułu: Art. 24b ust. 1 pkt 1 prowadzenie centralnego repozytorium kopii zbiorów danych ewidencji gruntów i budynków; Art. 24b ust. 1 pkt 3 wymianę danych w formie dokumentów elektronicznych między ewidencją gruntów i budynków a innymi rejestrami publicznymi, takimi jak: księga wieczysta, państwowy rejestr granic i powierzchni jednostek podziałów terytorialnych kraju, krajowy rejestr urzędowy podziału terytorialnego kraju, krajowy rejestr urzędowy podmiotów gospodarki narodowej, krajowy system ewidencji producentów, ewidencji gospodarstw rolnych oraz ewidencji wniosków o przyznanie płatności, w zakresie niezbędnym do prowadzenia tych rejestrów publicznych, a także przekazywanie w formie dokumentów elektronicznych zawiadomień o zmianach danych, dokonywanych w poszczególnych rejestrach publicznych, mających znaczenie dla innych rejestrów publicznych włączonych do zintegrowanego systemu informacji o nieruchomościach; Art. 24b ust. 1 pkt 4 dokonywanie przez sądy prowadzące księgi wieczyste sprawdzeń, o których mowa w art. 6268 4 Kodeksu postępowania cywilnego; Biorąc pod uwagę powyższe do osiągnięcia celu Pilotażu niezbędne jest wykonanie następujących prac implementacyjnych: Zadanie 1: dostosowanie systemu IPE do zadań centralnego repozytorium umożliwiającego w szczególności: automatyczną jego aktualizację na podstawie zmian przesyłanych z lokalnych systemów do prowadzenia EGiB oraz transfer/udostępnienie nadesłanych zawiadomień o zmianach innym systemom - funkcja brokera zawiadomień - w szczególności systemowi NKW. Realizacja wymagań Art. 24b ust. 1. pkt 1 i 4 Ustawy. Zadanie 2: rozbudowa lokalnych systemów do prowadzenia EGiB o funkcjonalności, o których mowa w art. 24b ust. 1. pkt 1 i 3 Prawa geodezyjnego i kartograficznego, umożliwiające: 1) automatyczne generowanie zawiadomień o zmianach w EGiB leżących w zainteresowaniu i adresowanych do odpowiedniego obszarowo wydziału ksiąg wieczystych oraz uwierzytelnianie tych zawiadomień podpisem elektronicznym, 2) automatyczne generowanie zawiadomień o zmianach w EGiB leżących w zainteresowaniu i adresowanych do właściwego organu podatkowego podatku od nieruchomości, podatku rolnego lub podatku leśnego oraz uwierzytelnianie tych zawiadomień podpisem elektronicznym, 3) odbiór zawiadomień o zmianach w rejestrze ksiąg wieczystych oraz obsługę procesu aktualizacji bazy EGiB na podstawie odebranych zawiadomień elektronicznych, 4) automatyczne generowanie danych aktualizacyjnych tworzonych w momencie i na podstawie dokonanych zmian w EGiB służących do aktualizacji centralnego repozytorium.

Zadanie 3: dostosowanie systemu NKW w zakresie funkcjonalności, o której mowa w art. 24b ust. 1 pkt 3 i 4 Prawa geodezyjnego i kartograficznego, umożliwiającej w szczególności: 1) automatyczne generowanie zawiadomień o zmianach w rejestrze KW leżących w zainteresowaniu i adresowanych do odpowiedniego obszarowo rejestru EGiB oraz uwierzytelnianie tych zawiadomień podpisem elektronicznym, 2) odbiór zawiadomień o zmianach danych EGIB oraz obsługa procesu aktualizacji rejestru KW na podstawie odebranych zawiadomień elektronicznych; 3) dokonywanie sprawdzeń, o których mowa w art. 626 8 4 Kodeksu postępowania cywilnego, z wykorzystaniem aktualnych danych zawartych w centralnym repozytorium kopii zbiorów danych ewidencji gruntów i budynków. 4. Ogólna koncepcja rozwiązania Na poniższym diagramie (Rysunek 1) przedstawiony został logiczny model ZSiN na podstawie, którego oparto rozwiązanie komunikacji między systemami EGiB, IPE i NKW w zakresie zawiadomień o zmianach (Rysunek 2).

deployment Logiczna_zsin Lokalne Rejestry Ewidencji Gruntów i Budynków ZSIN - komponent centralny Zewnętrzne systemy dziedzinowe System NKW Użytkownik EGiB Użytkownik ZSiN Użytkownik NKW Infrastruktura Powiatowa EGiB Interfejs WWW Intergująca Platforma Elektroniczna (Broker Usług i Centralne Repozytorium Kopii Danych EGiB) Wydział Ksiąg Wieczystych Wydział Ksiąg Wieczystych Infrastruktura Powiatowa... Centralna Baza Danych Ksiąg Wieczystych EGiB Wydział Ksiąg Wieczystych Infrastruktura Powiatowa Szyna usług ZSIN WebServ ices Lokalne Wydziały Ksiąg Wieczystych EGiB WebServ ices Rejestr PESEL... Infrastruktura Powiatowa WebServ ices Rejestr REGON EGiB WebServ ices Rejestr TERYT WebServ ices: WMS, WFS System Geoportal WebServ ices System Państwowy Rejestr Granic WebServ ices System Ewidencji Producentów, Gospodarstw Rolnych oraz Wniosków o Przyznanie Płatności WebServ ices e-puap Infrastruktura sieciowa systemu NKW Infrastruktura sieciowa PESEL-NET IPVPN Rysunek 1 Logiczny model ZSiN

deployment komunikacja_zsin Lokalne Rejestry Ew idencji Gruntów i Budynków ZSIN - komponent centralny Intergująca Platforma Elektroniczna (Broker Usług i Centralne Repozytorium Kopii Danych EGiB) Lokalne Wydziały Ksiąg Wieczystych Infrastruktura Powiatowa EGiB... Wydział Ksiąg Wieczystych Infrastruktura Powiatowa EGiB Szyna usług ZSIN WebServices (komunikaty XML) Centralna Baza Danych Ksiąg Wieczystych Wydział Ksiąg Wieczystych Infrastruktura Powiatowa EGiB Wydział Ksiąg Wieczystych Infrastruktura sieciowa systemu NKW Infrastruktura sieciowa PESEL-NET IPVPN ślad komunikacji pomiędzy EGiB a WKW Rysunek 2 Moduł komunikacji przy przesyłaniu zawiadomień o zmianach. 4.1. Założenia i uwarunkowania Z uwagi na stan obecnie funkcjonujących rozwiązań informatycznych oraz biorąc pod uwagę termin przewidziany na realizację Pilotażu przyjęto następujące założenia: 1. Transfer zawiadomień będzie realizowany za pośrednictwem systemu IPE, który będzie pełnił funkcję brokera zawiadomień (z możliwością odstąpienia patrz pkt 6), 2. Stanowiska do prowadzenia EGIB (w tym do wprowadzania zmian w EGIB oraz wprowadzenia zmian na podstawie zawiadomień z NKW) będzie połączone z siecią IPE (WAN-GUGiK), 3. Komunikacja między lokalnymi systemami do prowadzenia EGiB (a w szczególności MOZ), systemem IPE, systemem NKW oraz systemami organów podatkowych zostanie zrealizowana z wykorzystaniem usług sieciowych (ang. Web Services), 4. Dane służące do aktualizacji centralnego repozytorium będą przekazywane do centralnego repozytorium w postaci plików zapisanych w formacie GML, zgodnych ze schematem zdefiniowanym za pomocą XSD. Przesyłane pliki będą podlegać walidacji zgodności ze zdefiniowanym schematem. 5. Zawiadomienia będą przekazywane w postaci plików zapisanych w formacie XML zgodnych ze schematem zdefiniowanym za pomocą XSD. Przesyłane pliki będą podlegać walidacji zgodności ze zdefiniowanym schematem. 6. Transfer zawiadomień o zmianach danych w EGiB adresowanych do organów podatkowych, ze względu na uwarunkowania techniczne, a w szczególności na

niedostępność sieci WAN-GUGiK w lokalizacjach organów podatkowych, będzie mógł być realizowany z pominięciem systemu IPE (brokera) z wykorzystaniem sieci Internet. 7. Podpis elektroniczny do uwierzytelniania zawiadomień będzie spełniał wymagania bezpiecznego podpisu elektronicznego, o którym mowa w art. 3 pkt 2 ustawy z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. Nr 130, poz. 1450 z późn. zm.). 4.2. Ogólny model komunikacji 4.2.1. Obieg komunikatów dot. zmian w EGiB adresowanych do NKW Na poniższym diagramie przedstawiono sekwencję wymiany komunikatów między systemami EGiB, IPE i NKW dot. zmian w EGiB. Rysunek 3 Diagram sekwencji dot. zmian w EGiB adresowanych do WKW Po zatwierdzeniu zmian przez operatora EGiB, moduł obsługi zawiadomień dla systemu EGiB (MOZ) przesyła dane aktualizujące w formacie GML do systemu IPE. Następnie system IPE przeprowadza walidację otrzymanych danych, aktualizuje centralne repozytorium danych i generuje raporty z dokonania aktualizacji. Moduł MOZ cyklicznie odpytuje się do systemu IPE o raporty z ładowania i pobiera wyniki. Po pobraniu pozytywnego raportu dla danego ładowania moduł MOZ wysyła zawiadomienie o zmianie w EGiB oraz rejestruje wewnętrznie informację o wysłaniu zawiadomienia. Następne akcje po stronie MOZ będą dotyczyć aktualizacji statusu zawiadomienia w związku z odebraniem go przez system NKW. System IPE wysyła otrzymane zawiadomienie do systemu NKW. Następnie po stronie systemu NKW, operator WKW (sędzia orzecznik) dokonuje obsługi zawiadomienia

(zatwierdzenia lub nie zmiany na podstawie otrzymanego zawiadomienia), a informacja o dokonanej zmianie w systemie NKW przekazywana jest do systemu IPE. W kolejnym kroku system IPE aktualizuje status zawiadomienia. Moduł MOZ cyklicznie odpytuje się system IPE o status zawiadomienia, po otrzymaniu stosownej informacji o zatwierdzeniu zmiany, MOZ lokalnie zmienia/aktualizuje status zawiadomienia. Na poniższym rysunku przedstawiono diagram stanów dla zawiadomienia o zmianach EGiB. stm ZawiadomienieE... Initial Wygenerowane w MOZ Zmiany zatwierdzone w NKW Przesłane do IPE Zatwierdzenie przesłane do IPE Przesłane do NKW Zatwierdzenie pobrane przez MOZ Final Rysunek 4 Diagram stanów zawiadomienia i zmian w systemie EGiB

4.2.2. Obieg komunikatów dot. zmian w KW Na poniższym diagramie przedstawiono sekwencję wymiany komunikatów między systemami EGiB, IPE i NKW dot. zmian w KW. Rysunek 5 Diagram sekwencji dot. zmian w KW Po wprowadzeniu zmiany w rejestrze KW przez operatora WKW (sędzia orzecznik), system NKW przesyła zawiadomienie o zmianie w KW do systemu IPE. Moduł MOZ cyklicznie odpytuje się systemu IPE o nowe zawiadomienia o zmianie w KW. W przypadku pojawienia się nowego zawiadomienia jest ono pobierane przez moduł MOZ a w systemie IPE aktualizowany jest odpowiednio status tego zawiadomienia. Następnie moduł MOZ powiadamia operatora EGiB o odebraniu zawiadomienia o zmianie w KW. Po zatwierdzeniu zmiany przez operatora EGiB moduł MOZ aktualizuje dane w EGiB i przesyła informację o aktualizacji statusu zawiadomienia do systemu IPE. System IPE aktualizuje status zawiadomienia i przekazuje informację o zatwierdzeniu zmiany do systemu NKW.

Na poniższym rysunku przedstawiono diagram stanów dla zawiadomienia o zmianach w KW. stm ZawiadomienieN... Initial Wygenerowane w NKW Zmiany zatwierdzone w MOZ Przesłane do IPE Zatwierdzenie przesłane do IPE Pobrane przez MOZ Zatwierdzenie przesłane do NKW Final Rysunek 6 Diagram stanów zawiadomienia i zmian w systemie KW 4.2.3. Obieg komunikatów dot. zmian w EGIB adresowanych do organów podatkowych. Na potrzeby wymiany komunikatów pomiędzy EGIB, a organami podatkowymi przyjęto dwa modele komunikacji, zróżnicowane pod kątem wykorzystanej infrastruktury sieciowej: 1) wykorzystanie sieci WAN-GUGiK - model jest spójny z ogólnym modelem komunikacji przyjętym w pilotażu, w którym jako sieć transmisyjna wykorzystywana jest sieć wydzielona. Model ten jest możliwy do realizacji w tych lokalizacjach, w których organy powiatowe mogą mieć zapewniony dostęp do sieci WAN-GUGIK (np. współdzielenie budynku z wydziałem ewidencji gruntów i budynków lub może nastąpić przyłączenie sieci wydzielonej). Model zakłada wykorzystanie systemu IPE jako brokera zawiadomień. Rysunek 7. Powyższy diagram prezentuje model I komunikacji.

2) wykorzystanie sieci Internet model zakłada bezpośrednią wymianę komunikatów pomiędzy EGiB i siop (z pominięciem systemu IPE za pomocą sieci publicznej Internet). W modelu tym, nacisk szczególny nacisk zostanie położony na bezpieczeństwo przesyłanych danych, a w szczególności poufność danych. Rysunek 8. Powyższy diagram prezentuje model II komunikacji 5. Wymagania dla modyfikacji systemów EGiB, SIOP, IPE i NKW Opisane w niniejszym punkcie wymagania zgodnie z Założeniami do Pilotażu - będą stanowić podstawę do przygotowania specyfikacji wymagań dostosowania dla lokalnych systemów do prowadzenia EGiB, systemów informatycznych organów podatkowych, a także systemu IPE i NKW. 5.1. Wymagania ogólne W niniejszym punkcie przedstawiono wymagania wspólne dla wszystkich systemów biorących udział w Pilotażu. 1) Komunikacja odbywa się z wykorzystaniem wydzielonej sieci WAN-GUGiK (z możliwością odstąpienia patrz pkt 2). 2) Wzajemna komunikacja systemów EGiB i systemu organów podatkowych może odbywać się z wykorzystaniem sieci Internet. 3) Moduły biorące udział w komunikacji będą umożliwiać wymianę danych za pomocą usług sieciowych (WebService) przy wykorzystaniu następujących standardów: SOAP wersja 1.2 (Simple Object Access Protocol) oraz załączniki zgodne z rozszerzeniem SOAP with Attachments Protokół wywoływania zdalnego dostępu do obiektów, WSDL wersja 1.1 (Web Services Description Language) - Język opisu usług sieciowych, 4) Moduły zapewnią obsługę przesyłanych danych przy uwzględnieniu następujących formatów: XML (Extensible Markup Language) - standard uniwersalnego formatu tekstowego służącego do zapisu danych w formie elektronicznej, XSD (XML Schema Definition) - standard definicji struktury dokumentów zapisanych w formacie XML, GML (Geography Markup Language) Język Znaczników Geograficznych, PDF wersja 1.4 (Portable Document Format) - dokumenty tekstowo-graficzne.

5) Usługi sieciowe będą komunikowały się za pomocą protokołu HTTPS. 6) Autentykacja usługi odbywa się za pomocą loginu i hasła na poziomie protokołu HTTPS (tryb Basic). 7) Komunikacja systemów IPE i NKW może być inicjowana zarówno przez NKW jak i IPE. 8) Komunikacja systemu IPE i modułu MOZ jest zawsze inicjowana przez moduł MOZ. 9) Przyjmowane dane ewidencyjne w formacie GML podlegają walidacji zgodności z XSD przed wprowadzeniem do centralnego repozytorium. 5.2. Wymagania dla Modułu obsługi zawiadomień (MOZ) Poniżej przedstawione zostały wybrane wymagania (w podziale na wymagania funkcjonalne i niefunkcjonalne) dla Modułu obsługi zawiadomień (MOZ). 5.2.1. Wymagania funkcjonalne 1) Moduł obsługi zawiadomień powinien zapewnić niezawodną współpracę (interoperacyjność) z systemem do prowadzenia ewidencji gruntów i budynków oraz systemem IPE i NKW, 2) Moduł obsługi zawiadomień powinien posiadać następujące funkcjonalności generowanie i przesyłanie zawiadomień o zmianach w EGiB zgodnie z przyjętym protokołem wymiany informacji (ref. pkt 4), generowanie i przesyłanie zmian w EGiB mających na celu aktualizację bazy centralnego repozytorium, zgodnie z przyjętym protokołem wymiany informacji (ref. pkt 4), odbieranie/pobieranie i przygotowywanie do zatwierdzenia zawiadomienia o zmianach w NKW, zgodnie z przyjętym protokołem wymiany informacji (ref. pkt 4) udostępnianie (np. przez panel administracyjny) wglądu do stanu (statusów) wysłanej i odbieranej komunikacji dot. zawiadomień i zmian. W szczególności: - moduł MOZ dostarcza funkcjonalność przesyłania (zmian) danych ewidencji gruntów i budynków w formacie GML do systemu IPE, - moduł MOZ dostarcza funkcjonalności odbierania informacji o aktualizacji danych w systemie IPE, - moduł MOZ dostarcza funkcjonalność przekazywania zawiadomień o zmianie w EGiB do systemu IPE, - moduł MOZ dostarcza funkcjonalność odbierania informacji o zatwierdzeniu zmiany w NKW przez operatora NKW powstałej w związku z zawiadomieniem o zmianie w EGiB, - moduł MOZ dostarcza funkcjonalność wysyłania informacji o zatwierdzeniu zmiany w EGIB przez operatora EGIB powstałej w związku z zawiadomieniem o zmianie w NKW. - moduł MOZ dostarcza funkcjonalność przekazywania zawiadomień o zmianie w EGiB do organów podatkowych (w modelu komunikacji z pominięciem systemu IPE), - moduł MOZ dostarcza funkcjonalność odbierania informacji o odbiorze zawiadomienia o zmianie w EGiB przez system organów podatkowych (w modelu komunikacji z pominięciem systemu IPE). 3) Moduł obsługi zawiadomień powinien zapewnić przechowywanie historii wysłanej i odbieranej komunikacji dot. zawiadomień i zmian.

4) Moduł obsługi zawiadomień powinien umożliwiać na wprowadzenie i zmianę konfiguracji parametrów jego pracy (np. zmiana cyklu wysyłania żądań). 5) Moduł obsługi zawiadomień powinien umożliwiać autoryzację i weryfikację autoryzacji zawiadomień pod kątem uwierzytelnienia zawiadomień bezpiecznym podpisem elektronicznym. 5.2.2. Wymagania niefunkcjonalne 1) Moduł będzie spełniał wymagania opisane w pkt. 5.1 2) Moduł będzie komunikował się zgodnie z przyjętym protokołem wymiany informacji ref. pkt 4 3) Moduł obsługi zawiadomień będzie działać jako klient usług sieciowych. 4) Moduł obsługi zawiadomień musi cechować niezawodność i dostępność działania w godzinach analogicznych do czasu pracy Urzędu (dokonywania zmian w EGiB), organów podatkowych i NKW. 5.2.3. Wdrożenie modelu danych wg schematu GML w bazie EGiB Zapewnienie funkcjonalności przesyłania danych oraz zmian danych w ewidencji gruntów i budynków w formacie GML wg schematu opracowanego przez GUGiK (Rozporządzenie w sprawie EGiB) wiąże się z koniecznością implementacji nowego modelu danych w bazie EGiB. Zmiana modelu powiązana jest także z: - dostosowaniem niezbędnych narzędzi i aplikacji systemu do prowadzenia EGiB do współpracy z nowo zamodelowaną bazą danych np. implementacja eksportera danych w formacie GML. 5.3. Wymagania dla systemu Integrującej Platformy Elektronicznej Poniżej przedstawione zostały wybrane wymagania (w podziale na wymagania funkcjonalne i niefunkcjonalne) dla systemu Integrującej Platformy Elektronicznej. 5.3.1. Wymagania funkcjonalne 1) System IPE dostarcza funkcjonalność przyjmowania danych ewidencji gruntów i budynków w formacie GML oraz aktualizacji centralnego repozytorium kopii zbiorów EGiB w oparciu o te dane. 2) System IPE dostarcza funkcjonalności przyjmowania zawiadomień o zmianie w EGiB od modułu MOZ. 3) System IPE dostarcza funkcjonalność przekazywania zawiadomień o zmianie w EGiB do systemu NKW 4) System IPE dostarcza funkcjonalność odbierania informacji o zatwierdzeniu zmiany w EGiB przez operatora WKW. 5) System IPE dostarcza funkcjonalność przekazywania informacji o zatwierdzeniu zmiany w EGiB przez operatora WKW do modułu MOZ. 6) System IPE dostarcza funkcjonalność przyjmowania zawiadomień o zmianie w KW od systemu NKW. 7) System IPE dostarcza funkcjonalność przekazywania zawiadomień o zmianie w KW do modułu MOZ.

8) System IPE dostarcza funkcjonalność odbierania informacji o zatwierdzeniu przez operatora EGiB zmiany powstałej w EGIB w związku z zawiadomieniem o zmianie w KW 9) System IPE dostarcza funkcjonalność przekazywania informacji o zatwierdzeniu zmiany w EGiB w związku z zawiadomieniem z systemu NKW. 10) System IPE dostarcza funkcjonalności przeglądu informacji o zawiadomieniach o zmianie w EGiB. 11) System IPE dostarcza funkcjonalności przeglądu informacji o zawiadomieniach o zmianie w KW. 5.3.2. Wymagania niefunkcjonalne 1) System będzie spełniał wymagania opisane w pkt 5.1 2) System będzie komunikował się zgodnie z przyjętym protokołem wymiany informacji (ref. pkt 4) 3) System będzie działać zarówno jako serwer jak i klient usług sieciowych (komunikacja systemów IPE i NKW może być inicjowana zarówno przez NKW jak i IPE). 4) System musi cechować niezawodność i dostępność działania w godzinach analogicznych do czasu pracy lokalizacji EGIB i NKW. 5.4. Wymagania dla systemu Nowej Księgi Wieczystej Poniżej przedstawione zostały wybrane wymagania (w podziale na wymagania funkcjonalne i niefunkcjonalne) dla systemu Nowej Księgi Wieczystej. 5.4.1. Wymagania funkcjonalne 1) System NKW dostarcza funkcjonalności przyjmowania zawiadomień o zmianie w EGiB od systemu IPE. 2) System NKW dostarcza funkcjonalność przekazywania zawiadomień o zmianie w KW do systemu IPE. 3) System NKW dostarcza funkcjonalność odbierania informacji o zatwierdzeniu zmiany w EGiB przez operatora EGiB w związku z zawiadomieniem o zmianie w NKW. 4) System NKW dostarcza funkcjonalność przekazywania informacji o zatwierdzeniu zmiany w KW przez operatora WKW. 5.4.2. Wymagania niefunkcjonalne 1) System będzie spełniał wymagania ref. pkt 5.1 2) System obsługi zawiadomień będzie działać zarówno jako serwer jak i klient usług sieciowych (komunikacja systemów IPE i NKW może być inicjowana zarówno przez NKW jak i IPE). 3) System obsługi zawiadomień musi cechować niezawodność i dostępność działania w godzinach analogicznych do czasu pracy lokalizacji EGIB i WKW.

5.5. Wymagania dla systemów informatycznych organów podatkowych Poniżej przedstawione zostały wymagania (w podziale na wymagania funkcjonalne i niefunkcjonalne) niezbędne do współdziałania w ramach ZSIN, w szczególności odbioru zawiadomień o zmianach w EGiB. 5.5.1. Wymagania funkcjonalne 1) System informatyczny organów podatkowych (SIOP) powinien zapewnić niezawodną współpracę (interoperacyjność) z systemem do prowadzenia ewidencji gruntów i budynków oraz systemem IPE (w przypadku przyjęcia modelu wykorzystującego system IPE). 2) SIOP powinien posiadać następujące funkcjonalności odbieranie/pobieranie zawiadomień o zmianach w EGiB zgodnie z przyjętym protokołem wymiany informacji (ref. pkt 4), umożliwienie wykorzystania zawiadomień o zmianach w EGiB przez operatora systemu w procesie aktualizacji bazy i naliczania podatku nieruchomości, podatku rolnego lub podatku leśnego. W szczególności: - dostosowany SIOP dostarcza funkcjonalności odbierania zawiadomienia o zmianach w EGiB, - dostosowany SIOP dostarcza funkcjonalności potwierdzenia otrzymania zawiadomienia o zmianach w EGIB. 3) SIOP powinien umożliwiać weryfikację autoryzacji zawiadomień pod kątem uwierzytelnienia zawiadomień bezpiecznym podpisem elektronicznym. 5.5.2. Wymagania niefunkcjonalne 5) Dostosowany SIOP będzie spełniał wymagania opisane w pkt. 5.1 6) Dostosowany SIOP będzie komunikował się zgodnie z przyjętym protokołem wymiany informacji ref. pkt 4 7) Dostosowany SIOP będzie działać jako klient usług sieciowych. 8) Dostosowany SIOP musi cechować niezawodność i dostępność działania w godzinach analogicznych do czasu pracy Urzędu (dokonywania zmian w EGiB) oraz pracy organu podatkowego. 6. Dostosowanie systemów do prowadzenia EGiB Przyjęto dwa warianty dostosowania systemów do prowadzenia EGiB do wymagań przedmiotowych Wytycznych. Ich wybór i zastosowanie zależy od czynników finansowych, organizacyjnych oraz technologicznych uwarunkowań w danej lokalizacji. Obydwa warianty różni zakres prac koniecznych do podjęcia przy dostosowaniu systemów EGIB.

6.1. Wariant I Wariant I zakłada stworzenie przy dostosowaniu systemu EGIB - modułu obsługi zawiadomień (MOZ), który w założeniu (np. ze względów technologicznych) będzie integralną część oprogramowania (systemu) do prowadzenia EGiB. Całość dostosowania jest realizowana zgodnie z Wytycznymi w szczególności wymaganiami dla MOZ pkt 5.2 Wytycznych. Odpowiedzialność za poprawność funkcjonowania modułu MOZ współdziałającego z egib spoczywa na lokalizacji. Rysunek 6. Powyższy diagram prezentuje zakres dostosowania w wariancie I. 6.2. Wariant II Wariant II zakłada dostarczenie do lokalizacji uniwersalnego modułu obsługi zawiadomień (MOZ-U), którego istotą jest możliwość współdziałania z każdym systemem do prowadzenia ewidencji gruntów i budynków, umożliwiającym eksport zmian egib (w trybie różnicowym) w formacie GML. Moduł MOZ-U zasilany jest zmianami egib w formacie GML i na ich podstawie generuje zawiadomienia o zmianach egib. Wariant zakłada mniejszy zakres dostosowania po stronie sytemu egib. Odpowiedzialność za poprawność funkcjonowania modułu MOZ-U spoczywa na GUGiK. Rysunek 7. Powyższy diagram prezentuje zakres dostosowania w wariancie II.

7. Dostosowanie systemów informatycznych organów podatkowych Dostosowanie SIOP do realizacji zakładanych pilotażem celów, w szczególności do umożliwienia wymiany komunikatów z odpowiednim wydziałem EGIB musi obejmować nast. zakresy prac: - prace programistyczne polegające na rozszerzeniu funkcjonalnym obecnego oprogramowania (systemu), - prace wdrożeniowe i konfiguracyjne dla zapewnia odpowiedniej infrastruktury sieciowej. Zakłada się, że realizowany pilotaż dostarczy informacji, które będą miały przełożenie na wybór optymalnych rozwiązań technicznych i organizacyjnych w zakresie współdziałania organów podatkowych w ramach ZSiN. 8. Specyfikacja komunikacji między systemami 8.1. Opis użytych technologii Komunikacja pomiędzy systemami odbywa się za pomocą usług sieciowych (Web Service). W ramach wywoływania usług przekazywane są komunikaty w formacie SOAP 1.2. Jeżeli dodatkowo przesyłane są załączniki, to zgodnie w rozszerzeniem SOAP with Attachments. Usługi sieciowe są zdefiniowane za pomocą języka WSDL 1.1. W ramach definicji zdefiniowane są operacje udostępniane przez usługi i format komunikatów. Wywołanie usług następuje z wykorzystaniem protokołu HTTPS. Do autentykacji klienta wykorzystywany jest tryb Basic (użytkownik i hasło w ramach atrybutów nagłówka wywołania HTTPS). Podpis elektroniczny jest składany w formacie obecnie wykorzystywanym w systemie IPE. Składa się on ze strumienia bajtów, w którym jest zapisany najpierw certyfikat wykorzystany przy podpisaniu zapisany w formacie DER, a po nim wartość wyliczonej sygnatury SHA-1. Treść zawiadomienia jest załącznikiem do komunikatu SOAP w formacie XML. Wyrys i wypis jest przekazywany jako załącznik do komunikatu SOAP w formacie PDF. 8.2. Struktura komunikatów Nazewnictwo usług przyjęto według schematu: gdzie: ZsinAAABBBSerwis AAA oznacza system który udostępnia usługę (Ipe albo Nkw) BBB oznacza system dla którego usługa jest udostępniona (Ipe, Nkw, Moz).

W przypadku niepowodzenia wykonywania operacji jest zwracany standardowy komunikat SOAP Fault. 8.2.1. Usługa ZsinIpeMozSerwis Usługa zawiera operacje udostępnione dla modułu MOZ przez system IPE. Usługa została zdefiniowana w załączniku ZsinIpeMozSerwis.wsdl. 8.2.1.1. Opis metody PrzeslijDaneEwidencyjne Przesłanie danych aktualizacyjnych do centralnego repozytorium w IPE po zatwierdzeniu zmian w EGiB. Żądanie Struktura komunikatu głównego (koperty): dane dotyczące EGIB metadane dotyczącego przesyłanych danych plik GML z danymi ewidencyjnymi podpis pliku GML Odpowiedź Struktura komunikatu głównego (koperty): identyfikator zlecenia Brak 8.2.1.2. Opis metody PobierzRaportyLadowaniaDanych Przesłanie raportów z ładowania danych ewidencyjnych. Żądanie Struktura komunikatu głównego (koperty): dane dotyczące EGiB data ostatniego pobrania brak Odpowiedź Struktura komunikatu głównego (koperty): lista o raport dotyczący ładowania do IPE-W lub IPE-C brak 8.2.1.3. Opis metody PrzeslijZawiadomienieEGiB Przesłanie zawiadomienia o zmianach w EGiB z MOZ do systemu IPE. Żądanie Struktura komunikatu głównego (koperty): dane dotyczące EGIB metadane dotyczące zawiadomienia

plik XML z zawiadomieniem podpis pliku XML zawiadomienia plik PDF z wyrysem podpis pliku wyrysu Odpowiedź Struktura komunikatu głównego (koperty): identyfikator zawiadomienia przydzielony w systemie IPE Brak 8.2.1.4. Opis metody PobierzZatwierdzonoZmianyNkw Pobieranie informacji o zatwierdzeniu zmian w systemie NKW na podstawie przesłanego zawiadomienia o zmianach EGiB. Żądanie Struktura komunikatu głównego (koperty): dane dotyczące EGiB data ostatniego pobrania brak Odpowiedź Struktura komunikatu głównego (koperty): lista o metadane dotyczące zawiadomienia brak 8.2.1.5. Opis metody PobierzListeZawiadomienNKW Pobranie listy zawiadomień przesłanych z NKW do IPE. W ramach tej metody pobierane są tylko informacje nagłówkowe. Każde zawiadomienie trzeba pobrać pojedynczo metodą pobierzzawiadomienienkw. Po wywołaniu tej metody nie ulegają zmianie statusy zawiadomień. Żądanie Struktura komunikatu głównego (koperty): dane dotyczące EGiB data ostatniego pobrania brak Odpowiedź Struktura komunikatu głównego (koperty): lista o metadane dotyczące zawiadomienia brak

8.2.1.6. Opis metody PobierzZawiadomienieNkw Pobranie zawiadomienia o zmianach w NKW. Po pobraniu ulega zmianie status zawiadomienia. Żądanie Struktura komunikatu głównego (koperty): dane dotyczące EGiB identyfikator zawiadomienia przydzielony w systemie IPE brak Odpowiedź Struktura komunikatu głównego (koperty): dane dotyczące WKW metadane dotyczące zawiadomienia plik XML z zawiadomieniem podpis pliku XML zawiadomienia 8.2.1.7. Opis metody ZatwierdzonoZmianyEGiB Przesłanie informacji o zatwierdzeniu zmian w systemie EGiB na podstawie przesłanego zawiadomienia o zmianach w NKW. Żądanie Struktura komunikatu głównego (koperty): dane dotyczące EGiB metadane dotyczące zawiadomienia Brak Odpowiedź Struktura komunikatu głównego (koperty): Pusty element Brak 8.2.2. Usługa ZsinIpeNkwSerwis Usługa zwiera operacje udostępnione dla systemu NKW przesz system IPE. Usługa została zdefiniowana w załączniku ZsinIpeNkwSerwis.wsdl. 8.2.2.1. Opis metody ZatwierdzonoZmianyNkw Przesłanie informacji o zatwierdzeniu zmian w systemie NKW na podstawie przesłanego zawiadomienia o zmianach w EGiB. Żądanie Struktura komunikatu głównego (koperty): dane dotyczące WKW metadane dotyczące zawiadomienia Brak Odpowiedź Struktura komunikatu głównego (koperty): Pusty element

Brak 8.2.2.2. Opis metody PrzeslijZawiadomienieNkw Przesłanie zawiadomienia o zmianach w KW z NKW do IPE. Żądanie Struktura komunikatu głównego (koperty): dane dotyczące WKW metadane dotyczące zawiadomienia plik XML z zawiadomieniem podpis pliku XML zawiadomienia Odpowiedź Struktura komunikatu głównego (koperty): identyfikator zawiadomienia przydzielony w systemie IPE Brak 8.2.3. Usługa ZsinNkwIpeSerwis Usługa zawiera operacje udostępnione dla systemu IPE przez system NKW. Usługa została zdefiniowana w załączniku ZsinNkwIpeSerwis.wsdl. 8.2.3.1. Opis metody PrzeslijZawiadomienieEGiB Przesłanie zawiadomienia o zmianach w EGiB z system IPE do systemu NKW Żądanie Struktura komunikatu głównego (koperty): dane dotyczące EGIB metadane dotyczące zawiadomienia plik XML z zawiadomieniem podpis pliku XML zawiadomienia plik PDF z wyrysem podpis pliku wyrysu Odpowiedź Struktura komunikatu głównego (koperty): Pusty element Brak 8.2.3.2. Opis metody ZatwierdzonoZmianyEGiB Przesłanie informacji o zatwierdzeniu zmian w systemie EGiB na podstawie przesłanego zawiadomienia o zmianach w NKW. Żądanie Struktura komunikatu głównego (koperty): dane dotyczące EGiB dodatkowe dane zawiadomienia

brak Odpowiedź Struktura komunikatu głównego (koperty): pusty element brak 9. Załączniki 9.1. XSD wykorzystywane w usługach Definicja znajduje się w pliku ZsinSerwisTypy.xsd. 9.2. WSDL usługi w systemie IPE dla modułu MOZ Definicja znajduje się w pliku ZsinIpeMozSerwis.wsdl 9.3. WSDL usługi w systemie IPE dla systemu NKW Definicja znajduje się w pliku ZsinIpeNkwSerwis.wsdl 9.4. WSDL usługi w systemie NKW dla systemu IPE Definicja znajduje się w pliku ZsinNkwIpeSerwis.wsdl 9.5. XSD dla zawiadomień o zmianach w EGIB Definicja schematu znajduje się w katalogu zawiadomieniaegib. 9.6. XSD dla zawiadomień o zmianach w NKW Definicja schematu znajduje się w katalogu zawiadomieniankw. 9.7. XSD dla komunikatów zmian z systemu EGiB Definicja schematu znajduje się w katalogu gmlegib.