Model Wymiany Danych. dla Migracji Usług Hurtowych. w ramach dostępu telekomunikacyjnego. do sieci TP. Wersja

Aplikacje IT IT Obszaru Usług Hurtowych Wydział Systemów Kolekcji, Mediacji i Bilingu Hurtowego ul. Rakowicka 51, 31-510 Kraków tel.: 12 410 04 41 fax.: 12 422 06 40 http://www.hurt-tp.p Model Wymiany Danych dla Migracji Usług Hurtowych w ramach dostępu telekomunikacyjnego do sieci TP Wersja 5.10.2 Data wdrożenia: 2013-10-01 MWD_dla_migracji_V5 10 3- JWZ.doc

Historia zmian Wersja Data modyfikacji Opis 1.0 7.07.2008 Utworzenie dokumentu 2.0 16.07.2008 Merytoryczne 2.1 8.08.2008 Merytoryczne 2.2 14.08.2008 Merytoryczne 2.3 26.08.2008 Merytoryczne 2.4 8.09.2008 Merytoryczne 2.5 16.09.2008 Merytoryczne 2.6 22.09.2008 Merytoryczne 2.7 23.09.2008 Merytoryczne 2.8 23.09.2008 Merytoryczne 2.9 24.09.2008 Merytoryczne 2.10 26.09.2008 Uzupełnienie w zakresie realizacji technicznej. Wyjaśnienia do pytań w formie komentarzy. 2.10a 29.09.2008. Korekta komunikatów i przykładów 3 29.09.2008 Merytoryczne 3.1 07.10.2008 Merytoryczne 3.2 08.10.2008 Przeniesienie zmian z wersji 2.10a, nieuwzględnionych w wersji 3.1. Poprawa i uzupełnienie komunikatów zgodnie z ustaleniami z telekonferencji. 4.0 08.10.2008 Merytoryczne 5.0 10.10.2008 Merytoryczne 5.1 14.10.2008 Merytoryczne 5.2 17.10.2008 Merytoryczne 5.3 29.10.2008 Merytoryczne dopisanie numeracji dla czterech nieopisanych kodów odrzuceń 5.4 3.12.2008 Doprecyzowanie zapisów w rozdziale 9 odnośnie dni na rozpatrzenie reklamacji. 5.5 4.12.2008 Uwzględnienie nowych wymagań biznesowych w specyfikacji komunikatów 5.6 5.12.2008 Uwzględnienie wymagań biznesowych po spotkaniu dotyczącym Modelu realizacji procesów 5.6 11.12.2008 6.01.2009. Zmiany w komunikacie ORDER-STATUS, korekta przykładów, korekta kodów, korekty edytorskie, komentarze, zmiana wymagalności pól struktury rekordu typu ADDRESS, dodanie nowej wartości słownikowej 2 w komunikacie SERVICE-QUERY-RESULT w polu QUERY- STATUS 5.6.1 9.01.2009 Zmiany merytoryczne we wprowadzeniu oraz doprecyzowanie zapisów przy opisach kroków procesów. Zmodyfikowano także rodzaje migracji w rozdziale 3. 5.6.2 11.01.2009 Uwzględnienie zmian wprowadzonych przez HLD-0 (2) w komunikacie ORDER-MIGRATION- STATUS 5.6.3 12.01.2009 Uwzględnienie zmian biznesowych i informatycznych. 5.6.4 14.01.2009 Uwzględnienie uwag biznesowych informatycznych MWD_dla_migracji_V5 10 3- JWZ.doc 2

Wersja Data modyfikacji Opis 5.6.5 23.01.2009 Uzupełnienie komunikatu ORDER-MIGRATION-CANCEL o pole GENERATE-DATE 5.6.6 27.03.2009 Uzupełnienie procesu składania reklamacji oraz informacji niezbędnych dla realizacji procesu BSA na LLU 5.6.7 7.04.2009 Zmiana formatu dat w polach IMPLEMENTATION-DATE i STATUS-DATE. Dodanie typu usługi 8 NBSA usługa BSA w trybie Naked (usługa szerokopasmowa ATM). Doprecyzowanie znaczenia typu BSA w komunikatach. Usunięcie pól VERSION-ADSL, SPECIAL-VERSION-ID, OPTION-ADSL z komunikatu zamówienia jako niewykorzystywanych w procesie, zastąpionych polem wymaganym CODE. Dodanie parametrów technicznych BSA i NBSA tj. VP, VC, VP2PDU, ID interfejsu ATM. Usunięcie obligatoryjnych usług VAS ze specyfikacji usług zamawianych. 5.6.8 23.04.2009 Dodanie zgody abonenta na przetwarzanie danych osobowych w komunikacie SERVICE- QUERY zmiana zakresu godzinowego dla T0 z 8-16 na 23:59 5.6.9 27.04.2009 Uzupełniono p.9,2.1 Uzupełniono kody odrzuceń. 5.6.10 4.05.2009 Usunięto punkt 3.1.5 celem uspójnienia zapisów z rozdziałem 3. Modyfikacja zapisów biznesowych w rozdziale drugim odnośnie T0 dla realizacji zamówień. Dodanie kodu nr 404 Niepoprawne PG/PPD, usunięcie kodu 295 5.7 5.05.2009 Podniesienie wersji po akceptacji dokumentu 5.7.1 22.05.2009 Modyfikacja procesu reklamacji 5.7.2 27.05.2009 Modyfikacja kodów odrzutu 5.7.3 11.09.2009 Dodanie rozdziału 6 Odpytanie o warunki dla NP. Modyfikacja zapisów merytorycznych dla rozdziału 7 i 9 w zakresie określenia KPI dla realizacji poszczególnych kroków procesu. Dodanie 6 BSA-BROADBAND TP powrót BSA w polu ORDER-TYPE 5.7.4 14.09.2009 Modyfikacja KPI dla realizacji procesów dla usługi NP. Dodanie kodów odrzutu dla weryfikacji formalnej. 5.7.6 2009-09-18 Uwzględnienie uwag do dokumentu, poprawa KPI w opisie procesu realizacji dla Zamówień Migracji. 5.8 2009-09-18 Akceptacja zmian, podniesie wersji po akceptacji. 5.8 2009-10-22 Aktualizacja dokument pod kątem poprawnej zawartości komunikatów dotyczących zmiany wartości pola dla atrybutów z zawiera wyłączenie cyfr na zawiera znaki liczbowe. zawiera wyłączenie cyfr na zawiera znaki liczbowe. Zmiana wymagalności pola ROUTING-NUMBER na Jeżeli NP-TYPE = 1,2 MWD_dla_migracji_V5 10 3- JWZ.doc 3

Wersja Data modyfikacji Opis 5.8.1 2009-10-23 Uproszczenie zapisu dotyczącego skrzynek e-mail do komunikacji produkcyjnej i testów. Aktualizacja linków dla RFC dostępnych w Internecie (stare linki nie działają) Dodanie taga <query-agreement> w przykładzie zapytania o usługi. Aktualizacja wymagań dla pola <number-type>, <number-count>, <number-lo> dla zamówienia migracji. Usunięcie z przykładu zamówienia WLR WLR, <cease-type>6. Uzupełnienie wymagalności pola <produkt-id> dla <order-type> 2 i 8 w komunikacie statusu migracji. Zmiana opisu wymagań dla <attr-value> dla LLU średnica w mm do dwóch miejsc po przecinku Usunięcie <size>1</size> z przykładów (gdy <size>1 pole nie występuje). Uspójnienie nazw BRADBAND-TP oraz BSA-BRAODBAND na nazwę BRAODBAND dla <order-type>, <cease-type>, <product-id>, <service-name> Uzupełnienie przykładów komunikatów XML 5.8.2 2009-10-30 Zmiana pola TYPE na MODE w komunikacie akceptacji migracji od operatora ORDER- MIGRATION-TO-OPER-ACC 5.8.3 2009-11-04 Uściślenie nazewnictwa LLU w rodzajach migracji (LLUP i LLUW) 5.8.4 2009-11-05 Przeniesienie komunikatów do jednego rozdziału, aktualizacja odwołań do komunikatów w całym dokumencie. 5.8.4c 5.8.4d 2009-11-20 Usystematyzowanie kodów odrzuceń - kody weryfikacji formalnej Dostawcy - podział kodów Macierzysty, Dawca - kody odpowiedzi po weryfikacji technicznej 2009-11-30 W komunikatach <order-migration>, <order-migration-to-oper> wymagalność <servicespecyfication> ustawiona na NIE Tylko, jeżeli <service-type> <> 9 W komunikatach <order-migration> wymagane, <vas-type> ; <vas-value> gdy VAS-TYPE=2, 3, 22 W komunikatach <order-migration-status> wymagalność <line-attr> ustawia się na, jeżeli określono <produkt-id>. Może występować wielokrotnie W komunikatach <order-migration-status> pole <sernice-id> jest wymagane zawsze, gdy powstaje nowa usługa szerokopasmowa BSA, LLUP, LLUW, BROADBAND, NBSA. Nowy czytelny zapis tego wymagania [, Jeżeli (CEASE-TYPE = 2, 6, 8) lub (SERVICE- TYPE = 9) lub (ORDER-TYPE = 2,3,4,6,8 i SERVICE-STATUS = 4) ] 5.8.4e 5.8.4f 5.8.4g 5.8.4g 2009-12-10 Dodanie dla zamówienia migracji dodatkowej wartości dla sekcji <order-type> 5 - VOICE usługa głosowa 2009-12-15 Dla <order-migration-status> i <rejected-service> usuwamy słowa rezerwa z 3 - rezerwa - "LLUP" - usługa LLU Pełny (usługa głosowa iszerokopasmowa) 4 - rezerwa - "LLUW" - usługa LLU 2010-02-23 W komunikacie ORDER-MIGRATION dodano pole BARCODE dla zgodności z MWD-LLU 2010-03-01 Uzupełniono odwołanie do RFC4880 (http://www.ietf.org/rfc/rfc4880.txt).dodane w przykładzie dla reklamacji wymaganego pola <client-name> MWD_dla_migracji_V5 10 3- JWZ.doc 4

Wersja 5.8.4h Data modyfikacji 2010-04-20 Uszczegółowienie opisu dla pola <test-ver> Opis 5.8.4i 5.8.4j 5.8.4k 2010-05-04 Wprowadzenie wymagalności <test-ver> dla ORDER-MIGRATION-STATUS Ujednolicenie ograniczeń dla pól ITEM i SIZE do INT(10) 2010-05-07 W przykładach poprawiono zamknięcia tagów <query-id> z </query> na </query-id> 2010-10-05 Podział kodów odrzuceń dla ABORT i ACK 5.9.0 2010-10-07 Aktualizacja dokumentu o procesy zwrotu numeru do operatora macierzystego, zmiana numeru RN, reklamacje NP.. 5.9.1 2010-10-13 Usunięcie opisu w akapitach 8,9 do niezbędnego minimum 5.9.2 2010-11-18 Zmiany kodów odrzuceń w p. 12. 5.9.4 2011-03-31 Uzupełnienie tematów e-maili przed tabelami specyfikacji danego komunikatu 5.9.5 2011-10-03 Anulowanie przeniesienia numeru możliwe jest minimalnie na 5 DK poprawiono na 5DR 5.10.0 2012-12-03 Dodanie MODE=3 dla trybu realizacji NP w ciągu 1-6DR - dostosowanie MPM/NP do zmiany Prawa Telekomunikacyjnego, dodanie wyjaśnień dotyczących realizacji procesu NP w trybie MODE=3 5.10.1 2012-12-10 Dodanie kodów odrzuceń 440, 441, dodanie informacji o walidacji CEASE-MODE w przypadku ustawienia MODE=3 5.10.2 2013-06-11 Korekta opisu kodu 441 w zakresie "CEASE-MODE=1" Spis Treści 1. Wprowadzenie... 10 2. Podstawowe dane konfiguracyjne - kanał e-mail... 12 2.1. Ustawienia techniczne systemów TP i Przedsiębiorcy telekomunikacyjnego... 12 2.2. Zasady bezpieczeństwa przesyłu danych... 13 2.3. Specyfikacja postaci wiadomości e-mail... 14 3. Typy danych... 16 3.1. Typy pól... 16 3.1.1. ADDRESS... 16 3.1.2. LOC-ADDRESS... 17 3.1.3. INT-ID... 17 3.1.4. ORDER-NUMBER... 18 3.2. Rodzaje migracji... 18 4. Słownik pojęć... 20 5. Zapytanie TP przez Przedsiębiorcę telekomunikacyjnego o aktywne usługi hurtowe na danym Łączu Abonenckim Aktywnym... 21 5.1. Zapytanie o aktywne usługi hurtowe... 21 5.1.1. Komunikat zapytania o aktywne usługi na danym Łączu Abonenckim... 21 5.1.2. Komunikat potwierdzenia przyjęcia SERVICE-QUERY... 22 MWD_dla_migracji_V5 10 3- JWZ.doc 5

5.2. Informacja o zainstalowanych usługach na aktywnym łączu abonenckim... 23 5.2.1. Komunikat odpowiedzi na zapytanie o aktywne usługi na danym Łączu Abonenckim... 23 5.2.2. Komunikat potwierdzenia przyjęcia SERVICE-QUERY-RESULT... 24 6. Proces przeniesienia numeru przy zmianie dostawcy usług Number Portability (TP realizuje komunikację pomiędzy Operatorami)... 25 6.1. Zapytanie o techniczne warunki realizacji NP... 25 6.1.1. Komunikat zapytania o warunki NP... 26 6.1.2. Komunikat potwierdzenia zapytania o warunki NP.... 26 6.2. Potwierdzenie daty lub negatywna weryfikacja formalna... 26 6.2.1. Komunikat potwierdzenie daty lub negatywna weryfikacja formalna... 26 6.2.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzenia daty lub negatywnej weryfikacji formalnej... 27 6.3. Odpowiedź od Dawcy i Macierzystego... 27 6.3.1. Komunikat odpowiedzi od Dawcy i Macierzystego... 27 6.3.2. Komunikat potwierdzenia dostarczenia odpowiedzi od Dawcy i Macierzystego... 27 6.4. Potwierdzenie daty realizacji lub odrzucenie... 27 6.4.1. Komunikat - potwierdzenie daty realizacji lub odrzucenie... 27 6.4.2. Komunikat potwierdzenia dostarczenia ORDER-MIGRATION-STATUS... 27 6.5. Zamówienie przeniesienia numeru... 27 6.6. Zwrot Numeru do Operatora Macierzystego,... 29 6.7. Zmiana Numeru Rutingowego w Sieci Operatora Biorcy,... 30 6.8. Anulowanie Operatora Biorcy/Dawcy/Macierzystego zamówienia przeniesienia numeru,... 30 7. Dostosowanie MWD-MPM do zmiany Prawa Telekomunikacyjnego - realizacja Number Portability w terminie od 1 do 6 DR (TP realizuje komunikację pomiędzy Operatorami)... 31 7.1. Zamówienie realizacji NP w trybie 1-6 DR... 31 7.1.1. Komunikat zamówienia.... 32 7.1.2. Komunikat potwierdzenia przyjęcia zamówienia przez system.... 32 7.2. Weryfikacja formalno-techniczna... 32 7.2.1. Komunikat - negatywna weryfikacja formalna... 32 7.2.2. Komunikat potwierdzenia dostarczenia negatywnej weryfikacji formalnej lub technicznej.... 33 7.3. Brak odpowiedzi od Dawcy i Macierzystego... 33 7.4. Neagtywne weryfikacja techniczna - przypadek szczególny... 33 7.4.1. Komunikat - odwołanie realizacji zamówienia do Dawcy i/lub Macierzystego... 33 7.4.2. Komunikat potwierdzenia dla komunikatu informacji o odmowie realizacji zamówienia Migracji... 33 7.5. Potwierdzenie od Dawcy i Macierzystego wykonania NP... 33 7.5.1. Komunikat potwierdzenia realizacji Macierzystego... 34 7.5.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzającego realizację przez Dawcę i Macierzystego... 34 7.6. Potwierdzenie realizacji Zamówienia Migracji... 34 7.6.1. Komunikat statusu wykonania zamówienia migracji... 34 7.6.2. Komunikat potwierdzenia statusu wykonania zamówienia migracji... 34 7.7. Zmiana Numeru Rutingowego w Sieci Operatora Biorcy,... 36 7.8. Anulowanie Operatora Biorcy/Dawcy/Macierzystego zamówienia przeniesienia numeru,... 37 MWD_dla_migracji_V5 10 3- JWZ.doc 6

8. Migracja Usługi Abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego Przedsiębiorcy telekomunikacyjnego (Biorca) ze zmianą Usługi Hurtowej... 38 8.1. Schemat migracji... 38 8.2. Opis kroków schematu... 39 8.3. Złożenie Zamówienia Migracji... 39 8.3.1. Proces po stronie Operatora Biorcy... 41 8.3.2. Opis kroków przesłania Zamówień Migracji... 42 8.3.3. Opis kroków przesłania grupy odpowiedzi na Zamówienia Migracji... 42 8.3.4. Komunikat Zamówień Migracji... 43 8.3.5. Komunikat potwierdzenia zamówień usług migracji... 44 8.4. Negatywna weryfikacja formalna TP... 45 8.4.1. Komunikat statusu... 46 8.4.2. Komunikat potwierdzenia statusu... 52 8.5. Przekazanie daty rezygnacji lub daty wykonania NP do Dawców... 52 8.5.1. Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP... 53 8.5.2. Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP.. 55 8.6. Potwierdzenia realizacji zlecenia Zamówienia lub jego odrzucenie... 55 8.6.1. Komunikat akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców... 56 8.6.2. Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców... 58 8.7. Potwierdzenie do Biorcy oraz Dawcy/Dawców bądź odmowa realizacji Zamówienia Migracji wraz z datą realizacji... 59 8.7.1. Komunikat - informacja o dacie realizacji Zamówienia Migracji/odmowie realizacji zamówienia Migracji 59 8.7.2. Komunikat potwierdzenia dla komunikatu informacji o dacie realizacji Zamówienia Migracji/odmowie realizacji zamówienia Migracji... 59 8.8. Rezygnacja z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji... 60 8.8.1. Komunikat Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji 60 8.8.2. Komunikat potwierdzenia Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji... 61 8.9. Potwierdzenie do Biorcy, Dawcy/ów anulowania zamówienia migracji... 61 8.9.1. Komunikat statusu anulowania zamówienia migracji... 62 8.9.2. Komunikat potwierdzenia statusu anulowania zamówienia migracji... 62 8.10. Potwierdzenie od Dawcy i Macierzystego wykonania NP... 62 8.10.1. Komunikat potwierdzenia realizacji przez Dawcę i Macierzystego... 63 8.10.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzającego realizację przez Dawcę i Macierzystego... 63 8.11. Potwierdzenie realizacji Zamówienia Migracji... 63 8.11.1. Komunikat statusu wykonania zamówienia migracji... 63 8.11.2. Komunikat potwierdzenia statusu wykonania zamówienia migracji... 63 8.11.3. Potwierdzenie deinstalacji usługi dla Operatora Dawcy... 64 9. Migracja usługi abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego Przedsiębiorcy telekomunikacyjnego (Biorca) bez zmiany usługi hurtowej;... 65 10. Migracja usługi abonenckiej z usługi hurtowej obecnie świadczonej na inną usługę hurtową bez zmiany Przedsiębiorcy telekomunikacyjnego... 66 10.1. Złożenie Zamówienia Migracji... 66 10.1.1. Komunikat Zamówień Migracji... 66 MWD_dla_migracji_V5 10 3- JWZ.doc 7

11. Proces zgłaszania reklamacji... 67 11.1. Zgłoszenie reklamacji formalnej... 69 11.1.1. Komunikat zgłaszania reklamacji... 69 11.1.2. Komunikat potwierdzenia zgłoszenia reklamacji formalnej... 70 11.1.3. Komunikat zapytania o informacje dodatkowe w procesie reklamacji... 70 11.1.4. Potwierdzenie ACK dla zapytania o informacje dodatkowe... 71 11.1.5. Komunikat odpowiedzi na zapytanie o informacje dodatkowe w procesie reklamacji... 72 11.1.6. Potwierdzenie ACK dla odpowiedzi na zapytanie o informacje dodatkowe... 72 11.1.7. Komunikat odpowiedzi na zgłoszenie reklamacji formalnej... 73 11.1.8. Komunikat potwierdzenia odpowiedzi na zgłoszenie reklamacji formalnej... 75 11.2. Zgłoszenie reklamacji technicznej... 75 11.2.1. Komunikat zgłoszenia reklamacji technicznej... 76 11.2.2. Komunikat potwierdzenia zgłoszenia reklamacji technicznej... 76 11.2.3. Komunikat odpowiedzi na zgłoszenie reklamacji technicznej... 76 11.2.4. Komunikat zapytania do biorcy dawcy i macierzystego celem wyjaśnienia przyczyny niezrealizowania lub błędnej realizacji zamówienia NP... 77 11.2.5. Zwrotna odpowiedź Dawcy, Biorcy, Macierzystego na dodatkowe zapytanie.... 77 11.2.6. Komunikat potwierdzenia odpowiedzi na zgłoszenie reklamacji technicznej... 77 12. Specyfikacja komunikatów... 78 12.1. Specyfikacja komunikatów dla zapytań... 78 12.1.1. SERVICE-QUERY Komunikat zapytania o aktywne usługi na danym Łączu Abonenckim... 78 12.1.2. SERVICE-QUERY-ACK Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY... 79 12.1.3. SERVICE-QUERY-RESULT Komunikat odpowiedzi na zapytanie o aktywne usługi na danym Łączu Abonenckim... 81 12.1.4. SERVICE-QUERY-RESULT-ACK Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY- RESULT... 83 12.2. Specyfikacja komunikatów dla zamówień migracji... 84 12.2.1. ORDER-MIGRATION Komunikat Zamówień Migracji... 84 12.2.2. ORDER-MIGRATION-ACK Komunikat potwierdzenia zamówień usług migracji... 91 12.2.3. ORDER-MIGRATION-STATUS Komunikat statusu... 93 12.2.4. Lista atrybutów... 99 12.2.5. ORDER-MIGRATION-STATUS-ACK Komunikat potwierdzenia statusu... 102 12.2.6. ORDER-MIGRATION-TO-OPER Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP... 103 12.2.7. ORDER-MIGRATION-TO-OPER-ACK Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP... 107 12.2.8. ORDER-MIGRATION-TO-OPER-ACC Komunikat akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców... 108 12.2.9. ORDER-MIGRATION-TO-OPER-ACC-ACK Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców... 111 12.2.10. ORDER-MIGRATION-CANCEL Komunikat Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji... 112 12.2.11. ORDER-MIGRATION-CANCEL-ACK Komunikat potwierdzenia Rezygnacji z Zamówienia Migracji 114 12.3. Specyfikacja komunikatów dla reklamacji MPM... 115 12.3.1. COMPLAIN-MIGRATION-TO-SERVICE-PACKAGE Komunikat zgłaszania reklamacji... 115 12.3.2. COMPLAIN-MIGRATION-TO-SERVICE-PACKAGE-ACK Komunikat potwierdzenia zgłoszenia reklamacji... 117 12.3.3. COMPLAIN-MIGRATION-TO-OPER Zapytanie dodatkowe w procesie reklamacji... 118 12.3.4. COMPLAIN-MIGRATION-TO-OPER-ACK Komunikat potwierdzenia zapytania dodatkowego reklamacji... 120 MWD_dla_migracji_V5 10 3- JWZ.doc 8

12.3.5. COMPLAIN-MIGRATION-TO-OPER-ACC Komunikat odpowiedzi na zapytanie dodatkowe w reklamacji... 121 12.3.6. COMPLAIN-MIGRATION-TO-OPER-ACC-ACK Komunikat potwierdzenia odpowiedzi na zapytanie dodatkowe... 123 12.3.7. COMPLAIN-MIGRATION-TO-SERVICE-REPLY-PACKAGE Komunikat odpowiedzi na zgłoszenie reklamacji... 124 12.3.8. COMPLAIN-MIGRATION-TO-SERVICE-REPLY-PACKAGE-ACK Komunikat potwierdzenia odpowiedzi na zgłoszenie reklamacji formalnej... 127 12.4. Specyfikacja komunikatów awaryjnych... 129 12.4.1. Komunikat ABORT... 129 13. Kody odrzuceń dla korelacji i przejść pomiędzy Operatorami... 131 13.1. Kody odrzuceń weryfikacja informatyczna... 131 13.2. Kody odpowiedzi weryfikacji formalnej Dostawcy... 131 13.3. Kody odrzucenia rezygnacji przez Dawcę... 132 13.4. Kody odpowiedzi Dostawcy do Biorcy/Dawcy/Macierzystego dotyczące weryfikacji formalnej Dawcy 132 13.5. Kody odrzucenia rezygnacji przez Macierzystego... 132 13.6. Kody odpowiedzi Dostawcy do Biorcy/Dawcy/Macierzystego dotyczące weryfikacji technicznej Macierzystego... 132 13.7. Kody odpowiedzi Dostawcy do Biorcy/Dawcy/Macierzystego dotyczące weryfikacji technicznej Dostawcy... 132 13.8. Kody związane z rezygnacją Abonenta otrzymaną od Dawcy/ Biorcy... 133 14. Kody odrzuceń dla informacji o usługach hurtowych... 134 15. Kody odrzuceń dla reklamacji... 135 15.1. Negatywna weryfikacja informatyczna w BNP - Kody odrzucenia reklamacji przez BNP... 135 15.2. Negatywny wynik rozpatrzenia Reklamacji - Kody odrzucenia reklamacji... 135 15.3. Wynik rozpatrzenia reklamacji... 135 15.4. Przedmiot Reklamacji... 135 MWD_dla_migracji_V5 10 3- JWZ.doc 9

1. Wprowadzenie Niniejszy dokument jest opisem Modelu Wymiany Danych (MWD) dla Migracji Usług Hurtowych w ramach dostępu telekomunikacyjnego do sieci TP zawartym pomiędzy: Telekomunikacją Polską S.A. (dalej zwaną TP) a Przedsiębiorcą telekomunikacyjnym. Dokument ten jest realizacją zakresu i wymagań zgodnie z Decyzją UKE o elektronicznej komunikacji między operatorami. Celem niniejszego dokumentu jest określanie zasad wykonywania przez Strony postanowień Decyzji Prezesa UKE oraz uregulowanie kwestii pozostawionych do uzgodnienia Stronom w ramach procesu wdrażania Decyzji Prezesa UKE. W przypadku zmiany zasad współpracy Stron poprzez nową Decyzję Prezesa UKE lub umowę zawartą między Stronami, Strony niezwłocznie dokonają zmian w niniejszym dokumencie celem dostosowania go do wprowadzonych zmian. Modelowy przebieg komunikacji MWD z użyciem kanału e-mail przedstawia poniższy rysunek, na którym jest widoczny ogólny schemat dla poszczególnych rodzajów zleceń. Serwer poczty e-mail Operatora Serwer poczty e-mail TP Operator System TP Migracja Usług Hurtowych w ramach dostępu telekomunikacyjnego w sieci TP jest dedykowana dla Przedsiębiorców Telekomunikacyjnych, którzy mają obecnie podpisaną umowę o dostępie telekomunikacyjnym w zakresie Usług Hurtowych oraz podpisane porozumienie oparte na dokumencie Model Przejść Międzyoperatorskich. W ramach Oferty określającej warunki Migracji, TP świadczy na rzecz Przedsiębiorcy telekomunikacyjnego następujące usługi: Migrację Usługi Abonenckiej z Usługi Hurtowej obecnie świadczonej na inną Usługę Hurtową bez zmiany Przedsiębiorcy telekomunikacyjnego Migracja Usługi Abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego Przedsiębiorcy telekomunikacyjnego (Biorca) bez zmiany Usługi Hurtowej; Migracja Usługi Abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego Przedsiębiorcy telekomunikacyjnego (Biorca) ze zmianą Usługi Hurtowej; MWD_dla_migracji_V5 10 3- JWZ.doc 10

Migrację można ustanowić na wszystkich Łączach Abonenckich Aktywnych, na których świadczone są obecnie Usługi Hurtowe BSA, LLU, WLR, realizowane jest Przeniesienie Numeru (NP) oraz w przypadku migracji na LLU także dla łączy, na których jest świadczona Abonentowi głosowa usługa detaliczna TP. W przypadku usług detalicznych TP, TP jest traktowana na identycznych zasadach jak pozostali OA. W celu zapewnienia prawidłowej obsługi Przedsiębiorcy telekomunikacyjnego (Biorcy) w zakresie procesów posprzedażowych po dokonaniu migracji, Przedsiębiorca telekomunikacyjny (Biorca) powinien mieć podpisane odpowiednie umowy / modele wymiany danych, właściwe dla usług hurtowych, które podlegają migracji w ramach niniejszego Modelu. Migracja z dwóch Usług Abonenckich podlega realizacji, jeżeli Stroną Umów Abonenckich świadczonych w oparciu o Usługę Hurtową jest ten sam Abonent. Komunikacja w zakresie realizacji poniżej wskazanych procesów odbywa się drogą elektroniczną za pośrednictwem Komunikatów XML właściwych dla prawidłowego przebiegu procesów, a w szczególności: obsługi Zamówień na podstawie Modelu Przejść Międzyoperatorskich określającego warunki Migracji na Łączu Abonenckim Aktywnym, obsługi Zamówień rezygnacji Abonenta z Migracji składanych przez Dawcę/Biorcę do TP, obsługi zgłoszeń Przedsiębiorcy telekomunikacyjnego z tytułu reklamacji, i nieprawidłowości technicznych w realizacji usług objętych procesem Migracji. Komunikacja opisana w niniejszym dokumencie pomiędzy TP, a Operatorem Macierzystym będzie prowadzona analogicznie jak między TP, a Operatorem Dawcą, różnicy podlega jedynie zawartość komunikatów przesyłanych między TP a Operatorem Dawcą i TP a Operatorem Macierzystym. Zmiana kanału komunikacyjnego (np. na WebService) nie będzie wymagała zmiany Modelu Wymiany Danych - sekwencje komunikatów i same komunikaty XML wymieniane w dowolnym kanale komunikacyjnym nie ulegają zmianie w związku ze zmianą tego kanału, a szczegóły techniczne dotyczące kanału będą uzgodnione i opisane w odrębnym dokumencie (załącznik techniczny). Każda ze Stron uczestniczących w wymianie komunikatów jest zobowiązana do przeprowadzenia testów wzajemnej komunikacji w ramach niniejszego Modelu, zgodnie ze scenariuszami testowymi. Pozytywne zakończenie testów warunkuje produkcyjne uruchomienie komunikacji elektronicznej między Stronami. MWD_dla_migracji_V5 10 3- JWZ.doc 11

2. Podstawowe dane konfiguracyjne - kanał e-mail Wymiana danych pomiędzy TP i Przedsiębiorcą telekomunikacyjnym odbywać się będzie przy użyciu poczty e- mail. E-mail będzie przesyłany do dedykowanych skrzynek pocztowych. Każda ze Stron uczestniczących w wymianie komunikatów jest zobowiązana do zapewnienia własnej części infrastruktury niezbędnej do wymiany informacji. Pliki będą zapisane w stronie kodowej UTF-8. W celu umożliwienia kontroli postaci plików XML, TP przekaże Przedsiębiorcom telekomunikacyjnym schematy XSD pozwalające na parsowanie zawartości komunikatów przed ich wysłaniem. Za dzień roboczy uznaje się dzień powszedni, w godzinach roboczych 8:00 16:00. (Dotyczy wszystkich zgłoszeń i zamówień). W dni robocze w godzinach 00:00 23:59 dzień wpływu zgłoszeń i zamówień jest dniem zerowym. Zamówienia przesłane w dni wolne od pracy oraz w dni świąteczne są zaliczane na poczet następnego dnia roboczego - T0. Data realizacji migracji wskazana przez Biorcę lub Dawcę musi się mieścić w przedziale między 21 Dni Roboczych a 120 Dni Kalendarzowych i nie może przypadać na dzień świąteczny, ani wolny od pracy. W specyficznych przypadkach np. gdy zamawiana jest sama usługa NP, wskazany zakres dat może być inny. Szczegółowy opis zamieszczono w dalszej części Dokumentu. Komunikaty, (czyli treść plików XML) będą wklejane do treści wiadomości e-mail, następnie email będzie kodowany PGP i przesyłany do dedykowanych skrzynek pocztowych, gdzie nastąpi dalsze procesowanie zawartych w komunikatach informacji. 2.1. Ustawienia techniczne systemów TP i Przedsiębiorcy telekomunikacyjnego Dla wiadomości przesyłanych pomiędzy Operatorem a TP, skrzynka pocztowa TP będzie miała adres: MPM_XX@telekomunikacja.pl W miejsce XX należy wstawić numer z rejestru przedsiębiorców telekomunikacyjnych nadany przez UKE. skrzynka pocztowa Operatora będzie miała adres: XXXXX@xxx.xx. Dla celów testów międzyoperatorskich prowadzonych przed wdrożeniem komunikacji na produkcję skrzynka pocztowa TP będzie miała adres: WLR.test@telekomunikacja.pl skrzynka pocztowa Operatora będzie miała adres: YYYYY@xxx.xx System TP wysyłający maile będzie prezentował się adresem IP: XX.XX.XX.XX. System Operatora wysyłający maile będzie prezentował się adresem IP: XX.XX.XX.XX. System TP wysyłający maile testowe będzie prezentował się adresem IP: XX.XX.XX.XX. MWD_dla_migracji_V5 10 3- JWZ.doc 12

System Operatora wysyłający maile testowe będzie prezentował się adresem IP: XX.XX.XX.XX. W przypadku konieczności zmiany adresów e-mail, do których jest przesyłana poczta lub, z których jest wysyłana poczta oraz zmiany adresów IP systemów wysyłających pocztę, Strony powiadomią siebie telefonicznie (na numer telefonu administratora systemu) oraz e-mailem (na adres administratora systemu) najdalej na 2 dni robocze przed planowaną zmianą. Niniejszy dokument w ramach prac zespołów roboczych, TP i Przedsiębiorcy telekomunikacyjnego będzie ulegał modyfikacji. Modyfikacje będą wykonywane w formie pisemnej i będą podlegały akceptacji przez Strony. 2.2. Zasady bezpieczeństwa przesyłu danych Każda wiadomość przesłana do operatora będzie szyfrowana jego kluczem publicznym PGP. Dopuszczalne jest szyfrowanie dwoma kluczami publicznymi - Przedsiębiorcy telekomunikacyjnego, do którego kierowany jest e-mail i własnym. Strony wymienią się kluczami publicznymi PGP służącymi do kodowania danych przesyłanych pomiędzy sobą już na etapie testów. O zmianach dotyczących kluczy publicznych strony będą się wzajemnie informować najdalej na dwa dni robocze przed planowaną zmianą. Strony będą przekazywać sobie klucze publiczne za pomocą e-maili, na adresy administratorów systemów obu stron. Przed zaszyfrowaniem wiadomość e-mail powinna zostać zapisana w formacie MIME. Wiadomość w formacie MIME składa się z nagłówków oraz właściwej zawartości (body, content). Szyfrowanie PGP wiadomości email, polega na stworzeniu nowej wiadomości, która zawiera niezmienione nagłówki z oryginału oraz zawartości, która jest zaszyfrowaną zawartością oryginału opatrzoną odpowiednim typem zawartości (content type). Wiadomość po zaszyfrowaniu musi być dalej poprawną wiadomością w formacie MIME. Dokładny opis szyfrowania email zawarty jest w dokumencie RFC2015 (www.ietf.org/rfc/rfc2015.txt). Informacje dotyczące szyfrowania PGP zawarte są w dokumencie RFC2440 (www.ietf.org/rfc/rfc2440.txt) oraz w dokumencie RFC4880 (http://www.ietf.org/rfc/rfc4880.txt). Każda wiadomość wysłana od Przedsiębiorcy telekomunikacyjnego do TP będzie potwierdzana przez TP mailem, w którego treści będzie wklejony odpowiednio sformatowany komunikat XML zawierający potwierdzenie otrzymania Zamówienia Migracji od Przedsiębiorcy telekomunikacyjnego. Potwierdzenie to oznacza, że Zamówienie Migracji od Przedsiębiorcy telekomunikacyjnego dotarło w całości, dane zawarte w Zamówieniu Migracji są poprawne pod względem informatycznym oraz dostarczone w wymaganym czasie od daty generacji (potwierdzenie nie obejmuje innej weryfikacji formalnej danych). Podobnie każdy komunikat z TP do Przedsiębiorcy telekomunikacyjnego zostanie potwierdzony przez Przedsiębiorcę telekomunikacyjnego e-mail em, w którego treści będzie wklejony odpowiednio sformatowany komunikat XML zawierający potwierdzenie otrzymania komunikatu z TP. W przypadku, gdy otrzymany komunikat Zamówienia Migracji nie może być przyjęty z uwagi na błędy w zawartości (błędy informatyczne), strona, do której był skierowany komunikat wygeneruje potwierdzenie otrzymania komunikatu z błędami (kody błędów są ustalone rozdziale 13). Jeśli otrzymany komunikat nie może być obsłużony przez system informatyczny Przedsiębiorcy telekomunikacyjnego z powodu błędów krytycznych w strukturze wiadomości, awarii systemu, wyłączenia systemu na czas prac konserwacyjnych, wyłączenia kanału komunikacyjnego z powodu awarii po stronie Przedsiębiorcy telekomunikacyjnego itp., strona, do której był skierowany komunikat wygeneruje komunikat awaryjny ABORT na adres e-mail, z którego została przysłany nieobsłużony komunikat. W zależności od przyczyny odrzucenia przesyłki, strona, która wygenerowała przesyłkę jest zobowiązana do poprawienia błędów i powtórnego wysłania przesyłki lub uruchomienia komunikacji kanałem awaryjnym. Poprawiony komunikat powinien zawierać zaktualizowane informacje o dacie jego generacji i nowe, unikalne INTERACTION-ID. MWD_dla_migracji_V5 10 3- JWZ.doc 13

Formaty przesyłek oraz formaty potwierdzeń (zarówno pozytywnych jak i negatywnych) są opisane w tym dokumencie. Strony ustalają, że na podstawie rejestru przedsiębiorców telekomunikacyjnych UKE, TP będzie posiadała identyfikator liczbowy = 1. 2.3. Specyfikacja postaci wiadomości e-mail Każda wiadomość e-mail przesyłana na dedykowaną skrzynkę pocztową będzie miała następującą postać: Tytuł wiadomości: id:[<ident Przedsiębiorcy telekomunikacyjnego wg UKE>][INTERACTION-ID]<nazwa typu komunikatu>[<xml>] Przykładowa postać komunikatu zamówień Migracji przesłanej od Przedsiębiorcy telekomunikacyjnego będzie następująca: Tytuł wiadomości: id:[99][123456]zamowienie-migracja[xml] Ogólny opis struktury komunikatu ORDER-MIGRATION Jak każdy komunikat XML opisywany w tym dokumencie składa się z sekcji nagłówkowej opisującej nadawcę, odbiorcę komunikatu oraz unikalny numer interakcji. W dalszej jego części znajduje się sekcja ORDER-MIGRATION opisująca ilość elementarnych zamówień w komunikacie i datę jego generacji. Kolejne rekordy ORDER- MIGRATION ELEMENT stanowią specyfikację poszczególnych zamówień składanych przez OA. Istotą tej części komunikatu jest podział na sekcję ogólną dotyczącą Abonenta, dla którego ma być świadczona usługa. Znajdują się tam dane tele-adresowe, numer telefonu bądź ID usługi szerokopasmowej. W dalszej kolejności znajdują się sekcje CEASE i ORDER. Pozwalają one odpowiednio wskazać, z jakiej usługi Abonent rezygnuje i jaką nową usługę zamawia. Zaznaczyć należy w tym miejscu, iż Number Portability jako prawo Abonenta wydzielone zostało w osobnej sekcji, aby rozdzielić NP. od usług hurtowych. Tak sekcja CEASE jak i ORDER może wystąpić maksymalnie dwa razy, raz dla przypadku usługi głosowej raz dla usługi szerokopasmowej. Podział taki pozwala na dowolne zamawianie migrowanych usług. W sekcji CEASE dla usługi głosowej znaleźć się może rezygnacja z głosu w TP lub rezygnacja z WLR. Podobnie CEASE dla usług szerokopasmowych może zawierać rezygnację z BSA jak i rezygnację z usługi szerokopasmowej świadczonej w TP. Dzięki takiej konstrukcji komunikatu niewymagane są dedykowane komunikaty dla rezygnacji z usług świadczonych przez TP i tym samym niebędące de-facto w zakresie migracji. Sekcja ORDER wskazuje na typ zamawianej usługi, na obecnym etapie dotyczy ona usługi LLU w wersji pełnej i współdzielonej, WLR oraz BSA/NBSA. MWD_dla_migracji_V5 10 3- JWZ.doc 14

W związku z tym, iż proces NP jest objęty innymi regulacjami UKE i Prawa Telekomunikacyjnego zostanie opisany oddzielnie w dedykowanych akapitach tego dokumentu. Przykładowa postać potwierdzenia odbioru wiadomości zamówienia Migracji przesłanej od TP do Przedsiębiorcy telekomunikacyjnego będzie następująca: Tytuł wiadomości: id:[1][123456]zamowienie-migracja-ack[xml] Identyfikator sesji (INTERACTION-ID) w przypadku komunikatów od Przedsiębiorcy telekomunikacyjnego do TP musi być unikalnym identyfikatorem wymiany danych w obrębie danego źródła komunikatu (Przedsiębiorcy telekomunikacyjnego Migracji). Identyfikator ten będzie liczbą całkowitą o długości maksymalnej 10 znaków [INT(10)]. Identyfikator nie musi zachowywać sekwencyjności numeracji. W przypadku komunikatów wysyłanych od TP do Przedsiębiorcy telekomunikacyjnego identyfikator sesji będzie unikalnym identyfikatorem wymiany danych w obrębie całej wymiany ze wszystkimi Przedsiębiorcami telekomunikacyjnymi. Identyfikator ten będzie liczbą całkowitą o długości maksymalnej 10 znaków [INT(10)]. Komunikaty ACK są technicznym potwierdzeniem odczytania komunikatu przez adresata wysyłanej informacji. MWD_dla_migracji_V5 10 3- JWZ.doc 15

3. Typy danych Jeśli szczegółowy opis w specyfikacji komunikatów nie stanowi inaczej, przyjmuje się następującą interpretację typów danych: INT, INTEGER - liczba całkowita z zakresu od 0 do 32767, reprezentowana przez ciąg znaków INT(n) - liczba całkowita, nieujemna, reprezentowana przez ciąg n znaków DATE - data reprezentowana przez ciąg znaków w postaci RRRR-MM-DD GG:mm:SS, gdzie RRRR - rok (4 cyfry), MM - miesiąc (2 cyfry od 01 do 12), DD dzień (2 cyfry od 01 do 31), GG - godzina (2 cyfry od 00 do 23), mm - minuty (2 cyfry od 00 do 59), SS - sekundy (2 cyfry od 00 do 59) np. 2007-11-15 13:52:45 oznacza datę 15 listopada 2007 godz. 13:52:45. Dopuszcza się zapis daty w postaci RRRR-MM-DD - wówczas godzina nie jest znacząca, a systemy przyjmują godzinę 00:00:00. CHAR - jeden znak CHAR(512) - pole znakowe o długości 512 znaków W przypadku typów INT, zera wiodące są ignorowane przez systemy, dlatego jeśli np. w jednym komunikacie pole <INTERACTION-ID> będzie zawierało ciąg znaków "1234", a w kolejnym takim komunikacie pole <INTERACTION- ID> będzie zawierało ciąg znaków "00001234", to drugi komunikat zostanie odrzucony z powodu powtórzonego <INTERACTION-ID>. Struktura większości komunikatów została wstępnie przygotowana do obsługi wieloelementowych grup komunikatów, które mogą być w przyszłości wykorzystane do przekazywania grup komunikatów. W chwili obecnej przewiduje się przesyłanie wyłącznie komunikatów w postaci pojedynczych zleceń (zamówień, odpowiedzi, statusów, zgłoszeń itp.). Oznacza to, że pole SIZE nie będzie występowało w komunikatach, a pole ITEM zawsze będzie zawierało wartość "1". Obsługa wieloelementowych grup komunikatów określonych typów może zostać włączona po uprzednim uzgodnieniu między operatorami. 3.1. Typy pól 3.1.1. ADDRESS Format tagowy Pole zawierające podrzędne tagi zawierające składowe adresu o następującym układzie: ADDRESS Nazwa pola Typ Opis Czy wymagany? /CH AR(512) CITY-NAME CHAR(50) Miejscowość STREET-NAME CHAR(50) Ulica NIE BUILDING-NUMBER CHAR(8) Numer domu FLAT-NUMBER CHAR(8) Numer lokalu NIE POSTAL-CODE CHAR(6) Kod pocztowy POSTAL-NAME CHAR(100) Poczta Uwaga! nadrzędn y MWD_dla_migracji_V5 10 3- JWZ.doc 16

Wartości pól adresowych nie mogą zawierać przecinków Przykładowy fragment XML: <address> <city-name>warszawa</city-name> <street-name>woronicza</street-name> <building-number>17</building-number> <flat-number>34</flat-number> <postal-code>44-100</postal-code> <postal-name>warszawa</postal-name> </address> 3.1.2. LOC-ADDRESS Typ adresu lokalizacyjnego Wszystkie pola odnoszące się do danych adresowych PG/PPD będą posiadały następujący format tagowy: Format tagowy Pole zawierające podrzędne tagi zawierające składowe adresu lokalizacyjnego o następującym układzie: ADDRESS Nazwa pola Typ Opis Czy wymagany? /CH AR(512) CITY-NAME CHAR(50) Miejscowość STREET-NAME CHAR(50) Ulica PROPERTY-NUMBER CHAR(50) Numer nieruchomości (Uwaga! Wartości pól adresowych nie mogą zawierać przecinków) nadrzędn y Przykładowy fragment XML: <address> <city-name>warszawa</city-name> <street-name>woronicza</street-name> <property-number>17</property-number> </address> 3.1.3. INT-ID Typ identyfikatora interakcji może występować w 2 formatach. Stosowany format w komunikatach od operatorów zależy od ustaleń konfiguracyjnych. W przypadku komunikatów tworzonych przez system do komunikacji z Operatorem, które nie są komunikatami typu ACK zawsze stosowany jest format liczbowy. Format stringowy: MWD_dla_migracji_V5 10 3- JWZ.doc 17

Pole o typie CHAR(40) Format liczbowy: Pole o typie INT(10) 3.1.4. ORDER-NUMBER Identyfikator zamówienia nadany przez operatora zgłaszającego zamówienie. Format stringowy: Pole o typie CHAR(15) w formacie XXXXXYYYYYYYYYY, gdzie pięć pierwszych cyfry XXXXX będzie identyfikować (kod) operatora/przedsiębiorcy nadany przez UKE, a kolejne dziesięć cyfr będzie oznaczać kolejny numer zamówienia danego operatora np. 000010000002323 3.2. Rodzaje migracji MIGRACJA_1 przejście z usługi na usługę bez zmiany operatora o o MIGRACJA_1 z WLR na NP MIGRACJA_1 z WLR na LLUP z NP o MIGRACJA_1 z WLR na LLUP (bez NP) o MIGRACJA_1 z WLR i BSA na LLUP z NP o MIGRACJA_1 z WLR i BSA na LLUP (bez NP) o MIGRACJA_1 z BSA na LLUW (POTS bez zmian) o MIGRACJA_1 z NBSA na LLUP (bez NP) o o MIGRACJA_1 z NBSA na LLUW MIGRACJA_1 zmiana RN M-NP-RN MIGRACJA_2 przejście od operatora do operatora bez zmiany usługi o o o o MIGRACJA_2 Zmiana operatora BSA (migracja z BSA na BSA) MIGRACJA_2 Zmiana operatora WLR (migracja z WLR na WLR) MIGRACJA_2 Zmiana operatora NBSA (migracja z NBSA na NBSA) MIGRACJA_2 Zmiana operatora NP (migracja z NP na NP) MIGRACJA_3 przejście zmienia się zarówno operator, jak i usługa o o o o o MIGRACJA_3 z WLR na NP MIGRACJA_3 z WLR na LLUP z NP MIGRACJA_3 z WLR na LLUP bez NP MIGRACJA_3 z WLR + BSA na LLUP z NP MIGRACJA_3 z WLR + BSA na LLUP bez NP o MIGRACJA_3 z POTS + BSA na LLUP z NP (Voice + BSA na LLUP z NP) MWD_dla_migracji_V5 10 3- JWZ.doc 18

o MIGRACJA_3 z POTS + BSA na LLUP (bez NP) (Voice + BSA na LLUP) o MIGRACJA_3 z BSA na LLUW (POTS bez zmian) o o o o o o MIGRACJA_3 z NBSA na LLUP bez NP MIGRACJA_3 z NBSA na LLUW MIGRACJA_3 powrót z BSA do TP (BSA na BROADBAND) MIGRACJA_3 powrót z NBSA do TP (NBSA na BROADBAND) MIGRACJA_3 przejście z usługi głosowej na NP (Voice na NP) MIGRACJA_3 zwrot numeru NP C-NP Dotychczasowa realizacja procesów MPM, dla których usługa NP jest jedną ze składowych zamówienia LLUP, będzie realizowana zgodnie z procesem dla usługi LLUP. MWD_dla_migracji_V5 10 3- JWZ.doc 19

4. Słownik pojęć Biorca CHAR(n) Dawca Date() DR Migracja MWD NBSA NWF NWT Przedsiębiorca telekomunikacyjny RTPrzylacze TP ZT Przedsiębiorca telekomunikacyjny świadczący usługi stacjonarnej usługi telefonicznej z którym abonent zamierza podpisać umowę o świadczenie usług telekomunikacyjnych w zakresie usługi (BSA, LLU, WLR, NP) Ciąg znaków o długości maksymalnej n (np. CHAR(512) pole znakowe gdzie można wstawić ciąg znaków o długości maksymalnej 512 znaków). Przedsiębiorca telekomunikacyjny aktualnie świadczący usługi na rzecz abonenta w ramach dostępu telekomunikacyjnego do sieci TP realizowanego na podstawie umów lub decyzji: BSA, LLU, WLR NP.? Data reprezentowana przez ciąg znaków w postaci RRRR-MM-DD GG:mm:SS, gdzie RRRR - rok (4 cyfry), MM - miesiąc (2 cyfry od 01 do 12), DD dzień (2 cyfry od 01 do 31), GG - godzina (2 cyfry od 00 do 23), mm - minuty (2 cyfry od 00 do 59), SS - sekundy (2 cyfry od 00 do 59). W niektórych przypadkach dopuszcza się zapis daty w postaci RRRR-MM-DD - wówczas godzina nie jest znacząca, a systemy przyjmują godzinę 00:00:00. Wszystkie dni tygodnia za wyjątkiem sobót, niedziel oraz innych dni ustawowo wolnych od pracy na terenie RP. Godziny DR 23:59 00:00 Przejście usług hurtowych w ramach dostępu telekomunikacyjnego w ramach sieci TP dedykowana dla PT, którzy mają obecnie podpisaną umowę o dostępie telekomunikacyjnym w zakresie usług hurtowych oraz podpisane porozumienie w zakresie Modelu Przejść Międzyoperatorskich. Migrację można ustanowić na wszystkich Łączach Abonenckich Aktywnych, na których świadczone są obecnie usługi hurtowe BSA, LLU, WLR z możliwością zachowania numeru przez abonenta. Migrację TP realizuje w ramach regulowanych usług hurtowych BSA, LLU, WLR, Model Wymiany Danych Aktywna usługa szerokopasmowa BSA na łączu, na którym nie jest świadczona usługa telefoniczna POTS lub WLR Negatywna Weryfikacja Formalna Negatywne Warunki Techniczne Przedsiębiorca lub inny podmiot uprawniony do wykonywania działalności gospodarczej na podstawie odrębnych przepisów, który wykonuje działalność gospodarczą polegającą na dostarczaniu sieci telekomunikacyjnych, udogodnień towarzyszących lub świadczeniu usług telekomunikacyjnych, przy czym przedsiębiorca telekomunikacyjny, uprawniony do: świadczenia usług telekomunikacyjnych, zwany jest dostawcą usług, dostarczania publicznych sieci telekomunikacyjnych lub udogodnień towarzyszących Realizacja Techniczna Przyłącza Telekomunikacja Polska S.A. Dokument Załącznik Teleadresowy MWD_dla_migracji_V5 10 3- JWZ.doc 20

5. Zapytanie TP przez Przedsiębiorcę telekomunikacyjnego o aktywne usługi hurtowe na danym Łączu Abonenckim Aktywnym 5.1. Zapytanie o aktywne usługi hurtowe Każdy Przedsiębiorca Telekomunikacyjny, który ma podpisaną z TP umowę o połączeniu sieci, może wystąpić do TP z zapytaniem o usługi hurtowe świadczone na danym łączu oraz o obecnego dostawcę/dawców usług. W tym celu wysyła zapytanie do TP poprzez interfejs informatyczny (System do komunikacji z Operatorem) podając numer telefonu lub ID usługi oraz adres instalacji, którego dotyczy zapytanie. 5.1.1. Komunikat zapytania o aktywne usługi na danym Łączu Abonenckim Temat wiadomości: id:[subject-id][interaction-id]zapytanie-o-uslugi[xml] SERVICE-QUERY (Operator Biorca->BNP)<T_3_0> MWD_dla_migracji_V5 10 3- JWZ.doc 21

Komunikat został opisany w punkcie 12.1.1 SERVICE-QUERY Komunikat zapytania o aktywne usługi na danym Łączu Abonenckim. Operator -> BNP Komunikat przesyłany kanałem elektronicznym. Przykładowy XML: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>6</subject-id> <dest-subject-id>1</dest-subject-id> <test-ver>0</test-ver> </msg-header> <service-query> <service-oper>1</service-oper> <generate-date>2006-08-22 08:00:00</generate-date> <service-query-element> <item>1</item> <query-id>sdfa123123</query-id> <number>322251527</number> <service-id></service-id> <client-address> <city-name>kozia Wólka</city-name> <street-name>mickiewicza</street-name> <building-number>12</building-number> <flat-number>35</flat-number> <postal-code>00-345</postal-code> <postal-name>kozia Wólka</postal-name> </client-address> <query-agreement>1</query-agreement> <msg>dodatkowe informacje </msg> </service-query-element> </service-query> </cbnp-message> 5.1.2. Komunikat potwierdzenia przyjęcia SERVICE-QUERY Temat wiadomości: id:[subject-id][interaction-id]zapytanie-o-uslugi-ack[xml] SERVICE-QUERY-ACK (BNP->Operator Biorca)<T_3_0> Komunikat został opisany w punkcie 12.2.2 SERVICE-QUERY-ACK Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY. BNP -> Operator Komunikat przesyłany kanałem elektronicznym. Przykładowy XML: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>1</subject-id> MWD_dla_migracji_V5 10 3- JWZ.doc 22

<dest-subject-id>6</dest-subject-id> <test-ver>0</test-ver> </msg-header> <service-query-ack> <acceptance> <item>1</item> <acc-status>0</acc-status> <acc-date>2008-12-22 14:00:00</acc-date> </acceptance> </service-query-ack> </cbnp-message> 5.2. Informacja o zainstalowanych usługach na aktywnym łączu abonenckim TP w ciągu 2 DR udziela operatorowi informacji o tym, jakie usługi hurtowe są zainstalowane na danym numerze telefonu/id usługi oraz podaje PT, dla którego świadczona jest dana usługa. 5.2.1. Komunikat odpowiedzi na zapytanie o aktywne usługi na danym Łączu Abonenckim Temat wiadomości: id:[subject-id][interaction-id]odpowiedz-zapytanie-o-uslugi[xml] SERVICE-QUERY-RESULT (BNP->Operator Biorca)<T_3_0> Komunikat został opisany w punkcie 12.1.3 SERVICE-QUERY-RESULT Komunikat odpowiedzi na zapytanie o aktywne usługi na danym Łączu Abonenckim. BNP->Operator Komunikat przesyłany kanałem elektronicznym. Przykładowy XML: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>1</subject-id> <dest-subject-id>6</dest-subject-id> <test-ver>0</test-ver> </msg-header> <service-query-result> <generate-date>2008-12-22 08:00:00</generate-date> <service-query-result-element> <item>1</item> <query-id>sdfa123123</query-id> <number>322251527</number> <service-number></service-number> <client-address> <city-name>kozia Wólka</city-name> <street-name>koziołka Matołka</street-name> <building-number>12</building-number> <flat-number>35</flat-number> <postal-code>00-345</postal-code> <postal-name>koziegłowy</postal-name> </client-address> <query-status>0</query-status> <msg>informacje dodatkowe</msg> <service> <service-name>1</service-name> <oper>10</oper> </service> MWD_dla_migracji_V5 10 3- JWZ.doc 23

<service> <service-name>2</service-name> <oper>18</oper> </service> </service-query-result-element> </service-query-result> </cbnp-message> 5.2.2. Komunikat potwierdzenia przyjęcia SERVICE-QUERY-RESULT Temat wiadomości: id:[subject-id][interaction-id]odpowiedz-zapytanie-o-uslugi-ack[xml] SERVICE-QUERY-RESULT-ACK (Operator Biorca-BNP)<T_3_0> Komunikat został opisany w punkcie 12.1.4 SERVICE-QUERY-RESULT-ACK Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY-RESULT. Operator -> BNP Komunikat przesyłany kanałem elektronicznym. Przykładowy XML: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>6</subject-id> <dest-subject-id>1</dest-subject-id> <test-ver>0</test-ver> </msg-header> <service-query-result-ack> <acceptance> <item>1</item> <acc-status>0</acc-status> <acc-date>2008-12-22 14:00:00</acc-date> </acceptance> </service-query-result-ack> </cbnp-message> MWD_dla_migracji_V5 10 3- JWZ.doc 24

6. Proces przeniesienia numeru przy zmianie dostawcy usług Number Portability (TP realizuje komunikację pomiędzy Operatorami) Rozdział ten opisuje procesy NP realizowane w Bazie Numerów Przeniesionych przy pomocy komunikatów migracyjnych w zakresie: Odpytanie o warunki technicznej realizacji NP Realizacja NP Zwrot Numeru do Operatora Macierzystego, Zmiana Numeru Rutingowego w Sieci Operatora Biorcy, Anulowanie Operatora Biorcy/Dawcy/Macierzystego zamówienia przeniesienia numeru, Komunikaty migracji posiadają wydzieloną sekcję NP i w dalszej części tego rozdziału analizowana będzie jedynie ta sekcja z pominięciem części ORDER i CEASE chyba, że dany podrozdział będzie wymagał inaczej. Procesy NP w modelu migracji zawarte są w następujących typach migracji: Zapytanie o techniczne warunki realizacji NP WLR -> NP - WLR na NP (zamówienie) WLRiBSA -> LLUPzNP - WLR z BSA na LLU Pełny z NP WLR -> LLUPzNP - WLR na LLU Pełny z NP WLR -> LLUWzNP - WLR na LLU Współdzielony z NP POTSiBSA -> LLUPzNP - Usługa głos. TP z BSA na LLU Pełny z NP VOICE -> NP - Usługa głos. na NP (zamówienie) M-NP-RN - Zmiana RN C-NP - Zwrot numeru NP. Listonosz - pośredniczenie w komunikacji pomięzy OA (Zapytanie o techniczne warunki realizacji NP. i VOICE -> NP ) Dla wszystkich wskazanych powyżej typów migracji zastosowanie ma proces anulowania zamówienia z uwzględnieniem opisanych dalej ograniczeń. Należy zaznaczyć, iż przewidziana jest możliwość realizacji zamówienia NP nawet w przypadku, kiedy TP nie jest stroną w zamówieniu. Funkcjonalność ta dostępna jest jedynie dla przedsiębiorców telekomunikacyjnych współpracujących z TP w ramach niniejszego modelu. Procesy realizacji NP w zależności od typu migracji mogą różnić się czasem realizacji kolejnych kroków w procesie zamówienia. Ograniczenia te wynikają z powiązania zamówienia NP z innymi produktami hurtowymi, które mają bezpośredni wpływ na czas reakcji systemu BNP. 6.1. Zapytanie o techniczne warunki realizacji NP Operator Biorca składa drogą elektroniczną za pośrednictwem systemu BNP dedykowane zamówienie zapytania o warunki techniczne oraz datę dla realizacji przeniesienia numeru do jego sieci. Zapytanie to z punktu widzenia komunikatów XML różni się od właściwego zamówienia przeniesienia numeru jedynie w sekcji MODE, gdzie dla zapytania pole to przyjmuje wartość 2. W zapytaniu znajdują się: MWD_dla_migracji_V5 10 3- JWZ.doc 25

Identyfikator zapytania (15-cyfrowy gdzie pięć pierwszych cyfr XXXXX będzie identyfikować (kod) operatora/przedsiębiorcy kolejne dziesięć cyfr będzie oznaczać kolejne zamówienie danego operatora tzw. ORDER-NUMBER) Numer abonencki (NUMBER) Rodzaj usługi (NP) poprzez wypełnienie sekcji NUMBER-PORTABILITY Dane klienta (imię i nazwisko / nazwa firmy) Adres instalacji Operator Biorca (Numer nadany przez UKE) Operator Dawca (Numer nadany przez UKE) Planowana data rozpoczęcia świadczenia usługi przez Biorcę na rzecz Abonenta (BEGIN-DATE). sposób rozwiązania umowy u Operatorów Dawców (DAY- natychmiastowy - oczekiwana przez klienta data przeniesienia, END zgodnie z regulaminem Dawcy, EOP na koniec umowy lojalnościowej) (CEASE-MODE) konieczne jest wypełnienie sekcji CEASE i wskazanie w CEASE-TYPE = 5 VOICE usługa głosowa numer RN * Proces zapytania nie jest wymagany dla realizacji zamówień NP 6.1.1. Komunikat zapytania o warunki NP. ORDER-MIGRATION z sekcją wskazująca, że komunikat jest tylko zapytaniem (MODE = 2). 6.1.2. Komunikat potwierdzenia zapytania o warunki NP. Potwierdzenie zapytania realizowane jest przez standardowy komunikat ORDER-MIGRATION-ACK 6.2. Potwierdzenie daty lub negatywna weryfikacja formalna TP w ciągu 1 DR dokonuje sprawdzenia komunikatu pod względem formalnym i jeżeli weryfikacja jest pozytywna wysyła komunikat do Operatora Dawcy i Operatora Macierzystego (jeżeli jest inny niż Dawca) o potwierdzenie daty przejścia za pomocą ORDER-MIGRATION-TO-OPER w przypadku negatywnej weryfikacji formalnej TP prześle komunikat odmowy realizacji zamówienia odpytania wraz z podaniem przyczyny (dopisany na komunikacie zamówienia Operatora Biorcy). 6.2.1. Komunikat potwierdzenie daty lub negatywna weryfikacja formalna ORDER-MIGRATION-STATUS Potwierdzenie daty przesyłane jest do Biorcy komunikatem ORDER-MIGRATION-STATUS po wcześniejszym odebraniu komunikatów od Dawcy i Macierzystego. Odbywa się to za pomocą ORDER-MIGRATION-TO- OPER-ACC. Komunikat ten w trybie zapytania będzie posiadał dodatkową sekcję wskazującą na ten tryb (MODE = 2). Realizacja negatywnej weryfikacji odbywa się poprzez przesłanie komunikatu ORDER-MIGRATION-STATUS (SERVICE-STAUS = 1 REJECTED) MWD_dla_migracji_V5 10 3- JWZ.doc 26

6.2.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzenia daty lub negatywnej weryfikacji formalnej. Potwierdzenie realizowane jest przez standardowy komunikat ORDER-MIGRATION-STATUS-ACK 6.3. Odpowiedź od Dawcy i Macierzystego Operator Dawca oraz Macierzysty mają 1 DR na potwierdzenie daty wykonania NP. Brak odpowiedzi przez Dawcę i Macierzystego (jeżeli jest inny niż Dawca) w wyznaczonym terminie TP traktuje jako odpowiedź pozytywną. 6.3.1. Komunikat odpowiedzi od Dawcy i Macierzystego Komunikat zawiera dane przesłane przez Biorcę i dodatkowo: - Potwierdzenie realizacji przejścia przez Dawcę wraz z Datą możliwej realizacji. - przyczynę zmiany daty wymaganej - Potwierdzenie możliwości wykonania RN przez macierzystego (jeżeli jest inny niż Dawca) - datę i godzinę przekazania komunikatu przez do TP ORDER-MIGRATION-TO-OPER-ACC 6.3.2. Komunikat potwierdzenia dostarczenia odpowiedzi od Dawcy i Macierzystego Potwierdzenie realizowane jest przez standardowy komunikat ORDER-MIGRATION-TO-OPER-ACC-ACK 6.4. Potwierdzenie daty realizacji lub odrzucenie W przypadku, gdy Dawca lub Macierzysty (jeżeli jest inny niż Dawca) odrzuci możliwość realizacji przejścia z podaniem powodu, TP przesyła komunikat do Operatora Biorcy z informacją o braku akceptacji i następuje zakończenie zamówienia z wynikiem negatywnym W przypadku, gdy Dawca i/lub Macierzysty nie prześle komunikatu, lub prześle odpowiedź pozytywną, TP przesyła komunikat do Operatora Biorcy z informacji o potwierdzeniu daty realizacji. 6.4.1. Komunikat - potwierdzenie daty realizacji lub odrzucenie Odpowiedź ORDER-MIGRATION-STATUS zawiera dane przesłane przez Biorcę i dodatkowo: - przyczyna weryfikacji negatywnej Dawcy lub Macierzystego - datę i godzinę przekazania komunikatu przez TP 6.4.2. Komunikat potwierdzenia dostarczenia ORDER-MIGRATION- STATUS Potwierdzenie realizowane jest przez standardowy komunikat ORDER-MIGRATION-STATUS-ACK 6.5. Zamówienie przeniesienia numeru MWD_dla_migracji_V5 10 3- JWZ.doc 27

Wyżej opisany proces zapytania o możliwość realizacji NP w wymaganym terminie jest identyczny z procesem właściwego zamówienia NP i w dalszej części tego dokumentu nie zostanie on ponownie opisany. Poniżej przedstawiona zostanie jedynie graficzna prezentacja procesu zamówienia NP. MWD_dla_migracji_V5 10 3- JWZ.doc 28

Istotne z punktu widzenia procesu jest położenie poszczególnych komunikatów na osi czasu i tak kolejno: - komunikat ORDER-MIGRATION rejestrowany jest umownie w czasie T-0. TP na weryfikację posiada czas 1 DR. Weryfikacja pozytywna wiąże się z wysłaniem do Dawcy i Macierzystego komunikatów ORDER-MIGRATION-TO-OPER. Dawca i Macierzysty również mają 1 DR na udzielenie odpowiedzi ORDER-MIGRATION-TO-OPER-ACC. Jej brak traktowany jest jak pozytywne potwierdzenie możliwości realizacji. Najdalej w trzecim dniu od T-0 pojawia się komunikat statusu do Biorcy z potwierdzeniem możliwości wykonania i wskazaniem daty realizacji. W dacie wymaganej Dawca i Macierzysty potwierdzają wykonanie. Tym samym system BNP generuje komunikat do Biorcy ORDER-MIGRATION- STATUS ze statusem COMPLETED. Na tym proces przeniesienia numeru się kończy. Maksymalny czas na realizację, jaki możliwy jest do zgłoszenia zawiera się między 7 DR a 120 DK. Fragment komunikatu ORDER-MIGRATION uwzględniający sekcję NP. Przy jego pomocy realizowane są wskazane warianty procesu NP, czyli przeniesienie, zmiana RN w sieci operatora, zwrot numeru i anulowanie zamówienia NP. Procesy złożone z inną usługą hurtową znajdą odzwierciedlenie w dalszej części dokumentu....... NUMBER- PORTABILITY Opcja zachowania numeru NIE Tylko jeżeli SERVICE- TYPE <> 9 ORDER- MIGRATIO N- ELEMENT NP-TYPE INT(4) 1 - PROVIDE zgłoszenie przeniesienia numeru od innego operatora 2 - MOBILITY zgłoszenie przeniesienia numeru wewnątrz operatora 3 - CEASE zgłoszenia zwrotu numeru do operatora macierzystego 4 - CANCEL zgłoszenie anulacji przeniesienia (należy przywrócić poprzedni RN) DONOR-OPER CHAR(10) Identyfikator UKE, który oddaje numer (operator, który aktualnie posiada przenoszony numer) Jeżeli NP- TYPE = 1 lub 2 lub 3 ROUTING-NUMBER CHAR(6) Numer routingowy dla wymaganego przekierowania do centrali operatora biorcy Jeżeli NP- TYPE = 1 lub 2 6.6. Zwrot Numeru do Operatora Macierzystego, Zwrot numeru do operatora macierzystego realizowany jest przy pomocy komunikatu ORDER- MIGRATION z wartością pola MODE = 1 i z wypełnioną podsekcją NP, gdzie parametr NP-TYPE MWD_dla_migracji_V5 10 3- JWZ.doc 29

przyjmuje wartość 3 (CEASE). W procesie tym może wystąpić negatywna weryfikacja formalna, nie przewiduje się negatywnej realizacji po stronie operatora macierzystego. W procesie tym nie przewiduje się anulowania. Data wymagana musi zawierać się w przedziale 2 DR do 30 DK. System BNP oczekuje 1 DR na potwierdzenie wykonania. Po tym czasie zlecenie zwrotu przyjmuje status COMPLETED. 6.7. Zmiana Numeru Rutingowego w Sieci Operatora Biorcy, Podobnie jak dla procesu zwrotu numeru do operatora macierzystego, zmiana numeru RN realizowana jest przy użyciu ORDER-MIGRATION ze wskazaniem w sekcji NP parametru NP-TYPE = 2 ( MOBILITY ). Proces przewiduje negatywną weryfikację formalną i, co jest bardzo istotne, negatywną realizację*. Możliwość taka zaimplementowana została w celu umożliwienia operatorowi macierzystemu zgłoszenia braku możliwości wykreowania wymaganego przez operatora aktualnego, numeru rutingowego. W procesie tym nie przewiduje się anulowania. Data wymagana musi zawierać się w przedziale 5 DR do 30 DK. System BNP oczekuje 1 DR na potwierdzenie wykonania. Po tym czasie zlecenie zmiany RN przyjmuje status COMPLETED. * w trybie awaryjnym - nie ma możliwości zgłoszenia negatywnej realizacji w komunikacji automatycznej 6.8. Anulowanie Operatora Biorcy/Dawcy/Macierzystego zamówienia przeniesienia numeru, Anulowanie przeniesienia numeru możliwe jest minimalnie na 5 DR przed datą wymaganą. Głównie proces przewiduje zgłoszenie anulowania od Biorcy lub Dawcy, pozostawiono jednak opcjonalną możliwość anulowania po stronie operatora macierzystego. Obecnie nie wykorzystywana. MWD_dla_migracji_V5 10 3- JWZ.doc 30

7. Dostosowanie MWD-MPM do zmiany Prawa Telekomunikacyjnego - realizacja Number Portability w terminie od 1 do 6 DR (TP realizuje komunikację pomiędzy Operatorami) Rozdział ten opisuje procesy NP skrócone na potrzeby dostosowania do zmian w Prawie Telekomunikacyjnym, realizowane w Bazie Numerów Przeniesionych przy pomocy komunikatów migracyjnych w zakresie: Realizacja NP Zmiana Numeru Rutingowego w Sieci Operatora Biorcy W celu jednoznacznej identyfikacji i wydzielenia procesu MPM realizowanego w trybie skróconym ze względu na terminy wymagane postanowieniami Prawa Telekomunikacyunego zostaje wprowadzona nowa wartość pola MODE=3 - "realizacja w trybie 1-6 DR". Komunikaty migracji posiadają wydzieloną sekcję NP i w dalszej części tego rozdziału analizowana będzie jedynie ta sekcja z pominięciem części ORDER i CEASE chyba, że dany podrozdział będzie wymagał inaczej. Procesy NP objęte skróconym procesem (MODE=3) zawarte są w następujących typach migracji: WLR -> NP - WLR na NP (zamówienie) VOICE -> NP - Usługa głos. na NP (zamówienie) M-NP-RN - Zmiana RN Listonosz - pośredniczenie w komunikacji pomięzy OA ( VOICE -> NP ) Dla wszystkich wskazanych powyżej typów migracji niedostępne będzie anulowanie zamówienia. Należy zaznaczyć, iż przewidziana jest możliwość realizacji zamówienia NP nawet w przypadku, kiedy TP nie jest stroną w zamówieniu. Funkcjonalność ta dostępna jest jedynie dla przedsiębiorców telekomunikacyjnych współpracujących z TP w ramach niniejszego modelu. W takich przypadkach czas realizacji poszczególnych kroków procesu jest uzależniony wyłącznie od czasu reakcji innych przedsiębiorców telekomunikacyjnych - uczestników procesu, a system BNP nie ma wpływu na działania wykonywane po stronie uczestników procesu i ich terminowość. 7.1. Zamówienie realizacji NP w trybie 1-6 DR Operator Biorca składa drogą elektroniczną za pośrednictwem systemu BNP dedykowane zamówienie wskazując tryb MODE=3 oraz datę dla realizacji przeniesienia numeru do jego sieci, która musi się mieścić w przedziale od 1 do 6 DR względem daty przesłania komunikatu do systemu BNP liczonego jako T0. Zamówienie to z punktu widzenia komunikatów XML różni się od innych zamówień przeniesienia numeru jedynie w sekcji MODE, gdzie pole to przyjmuje wartość 3. W zamówieniu znajdują się: Identyfikator zamówienia (15-cyfrowy gdzie pięć pierwszych cyfr XXXXX będzie identyfikować (kod) operatora/przedsiębiorcy kolejne dziesięć cyfr będzie oznaczać kolejne zamówienie danego operatora tzw. ORDER-NUMBER) Numer abonencki (NUMBER) Rodzaj usługi (NP) poprzez wypełnienie sekcji NUMBER-PORTABILITY Dane klienta (imię i nazwisko / nazwa firmy) Adres instalacji MWD_dla_migracji_V5 10 3- JWZ.doc 31

Operator Biorca (Numer nadany przez UKE) Operator Dawca (Numer nadany przez UKE) Planowana data rozpoczęcia świadczenia usługi przez Biorcę na rzecz Abonenta (BEGIN-DATE). sposób rozwiązania umowy u Operatorów Dawców (DAY- natychmiastowy - oczekiwana przez klienta data przeniesienia) (CEASE-MODE) konieczne jest wypełnienie sekcji CEASE i wskazanie w CEASE-TYPE = 5 VOICE usługa głosowa lub CEASE-TYPE = 1 "WLR" numer RN 7.1.1. Komunikat zamówienia. ORDER-MIGRATION z sekcją wskazująca, że komunikat jest zamówieniem w trybie 1-6 DR (MODE = 3). 7.1.2. Komunikat potwierdzenia przyjęcia zamówienia przez system. Potwierdzenie zamówienia realizowane jest przez standardowy komunikat ORDER-MIGRATION-ACK 7.2. Weryfikacja formalno-techniczna TP w ciągu 1 DR dokonuje sprawdzenia danych pod względem formalnym oraz możliwości technicznej realizacji zamówienia i jeżeli weryfikacja jest pozytywna wysyła komunikat do Operatora Dawcy i Operatora Macierzystego (jeżeli jest inny niż Dawca) za pomocą ORDER-MIGRATION-TO-OPER. Komunikat ten w trybie zamówienia 1-6 DR będzie posiadał sekcję wskazującą na ten tryb (MODE = 3). Dzięki temu możliwa będzie jednoznaczna idfentyfikacja odrębnego - skróconego przebiegu procesu. w przypadku negatywnej weryfikacji formalnej lub technicznej TP prześle do Biorcy komunikat odmowy realizacji zamówienia wraz z podaniem przyczyny. w szczególnym przypadku gdy negatywny wynik weryfikacji technicznej zostanie zarejestrowany później niż weryfikacja formalna (czyli po wysłaniu komunikatów ORDER-MIGRATION-TO-OPER do Operatora Dawcy i Operatora Macierzystego), system BNP wygeneruje do tych Operatorów komunikat odwołania zamówienia analogicznie jak w przebiegu anulowania w trybie MODE=2. 7.2.1. Komunikat - negatywna weryfikacja formalna ORDER-MIGRATION-STATUS Odmowa realizacji zamówienia przesyłana jest do Biorcy komunikatem ORDER-MIGRATION-STATUS. W odróżnieniu od procesów realizowanych w terminie dłuższym niż 6 DR (wartość pola MODE<3), system nie oczekuje na potwierdzenie daty przez Operatorów Dawcę i Macierzystego (ewentualny komunikat ORDER- MIGRATION-TO-OPER-ACC zostanie odrzucony z podaniem odpowiedniego kodu przyczyny odrzucenia). Realizacja negatywnej weryfikacji odbywa się poprzez przesłanie komunikatu ORDER-MIGRATION-STATUS (SERVICE-STAUS = 1 "REJECTED") MWD_dla_migracji_V5 10 3- JWZ.doc 32

7.2.2. Komunikat potwierdzenia dostarczenia negatywnej weryfikacji formalnej lub technicznej. Potwierdzenie realizowane jest przez standardowy komunikat ORDER-MIGRATION-STATUS-ACK 7.3. Brak odpowiedzi od Dawcy i Macierzystego W odróżnieniu od procesów realizowanych w terminie dłuższym niż 6 DR (wartość pola MODE<3), system BNP nie oczekuje na potwierdzenie daty przez Operatorów Dawcę i Macierzystego. Ewentualny komunikat ORDER-MIGRATION-TO-OPER-ACC zostanie odrzucony z podaniem odpowiedniego kodu przyczyny odrzucenia. 7.4. Neagtywne weryfikacja techniczna - przypadek szczególny W szczególnym przypadku, gdy negatywny wynik weryfikacji technicznej zostanie zarejestrowany później niż weryfikacja formalna (czyli po wysłaniu komunikatów ORDER-MIGRATION-TO-OPER do Operatora Dawcy i/lub Operatora Macierzystego), system BNP wygeneruje do tych Operatorów komunikat odwołania zamówienia analogicznie jak przy odmowie realizacji zamówienia Migracji w trybie MODE=2. Odmowa realizacji zamówienia przesyłana jest do Biorcy komunikatem ORDER-MIGRATION-STATUS. 7.4.1. Komunikat - odwołanie realizacji zamówienia do Dawcy i/lub Macierzystego Do operatora Biorcy i Dawców przesyłany jest komunikat jak w punkcie 12.2.3 ORDER-MIGRATION-STATUS Komunikat statusu, ze statusem REJECTED. Do operatora macierzystego (jeśli bierze udział w procesie migracji) wysyłany jest taki sam komunikat jak w punkcie 12.2.6 ORDER-MIGRATION-TO-OPER Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP z wypełnioną sekcją NUMBER-PORTABILITY i typem przeniesienia ustawionym na CANCEL. 7.4.2. Komunikat potwierdzenia dla komunikatu informacji o odmowie realizacji zamówienia Migracji W tym kroku procesu stosowany jest taki sam komunikat jak w punkcie 12.2.5 ORDER-MIGRATION-STATUS- ACK Komunikat potwierdzenia statusu. Komunikat ten przysyłany jest przez operatora Biorcę oraz Dawcę/Dawców. Operator Macierzysty (jeśli bierze udział w procesie migracji) przysyła taki sam komunikat jak w punkcie 12.2.7 ORDER-MIGRATION-TO-OPER-ACK Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP. 7.5. Potwierdzenie od Dawcy i Macierzystego wykonania NP. W przypadku, gdy TP jest pośrednikiem w przekazywaniu komunikatów dla poprawnej realizacji zamówień NP, Operator Dawca i Macierzysty niezwłocznie (w dacie realizacji) po wykonaniu przeniesienia informuje TP o pozytywnej realizacji technicznej. W przypadku braku komunikatu TP realizuje zamówienie w wymaganej dacie. MWD_dla_migracji_V5 10 3- JWZ.doc 33

7.5.1. Komunikat potwierdzenia realizacji Macierzystego Przy pomocy komunikatu ORDER-MIGRATION-TO-OPER-ACC operator Macierzysty zgłasza do TP pozytywną realizację techniczną. Realizacja ta odbywa się poprzez wskazanie w komunikacie pola ACC-STATUS z wartością 4 COMPLETED. Komunikat został opisany w punkcie 12.2.8 ORDER-MIGRATION-TO-OPER-ACC Komunikat akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców. 7.5.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzającego realizację przez Dawcę i Macierzystego Potwierdzenie dostarczenia komunikatu pozytywnej realizacji technicznej odbywa się za pomocą standardowego ORDER-MIGRATION-TO-OPER-ACC-ACK. Komunikat został opisany w punkcie 12.2.9 ORDER-MIGRATION-TO-OPER-ACC-ACK Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców. 7.6. Potwierdzenie realizacji Zamówienia Migracji TP, po zrealizowaniu Zamówienia Migracji, potwierdza elektronicznie Biorcy, zrealizowanie zamówienia. 7.6.1. Komunikat statusu wykonania zamówienia migracji W tym kroku procesu stosowany jest taki sam komunikat jak w punkcie 12.2.3 ORDER-MIGRATION-STATUS Komunikat statusu. Komunikat ten wysyłany jest do operatora Biorcy. W komunikacie przesyłany jest status COMPLETED. 7.6.2. Komunikat potwierdzenia statusu wykonania zamówienia migracji W tym kroku procesu stosowany jest taki sam komunikat jak w punkcie 12.2.5 ORDER-MIGRATION-STATUS- ACK Komunikat potwierdzenia statusu. Komunikat ten przysyłany jest przez operatora Biorcę. MWD_dla_migracji_V5 10 3- JWZ.doc 34

sd Zamówinie NP-MPM (MODE... Biorca :OA Dawca :OA Macierzysty :OA Dostawca (TP) Ogólny schemat przebiegu komunikacji :BNP dla zamówień MPM-NP z MOED=3 1.0 ORDER-MIGRATION(MODE=3) 1.1 ORDER-MIGRATION-ACK() break Neagtywna Weryfikacja Formalna 1.2 ORDER-MIGRATION-STATUS(STATUS=REJECTED) 1.3 ORDER-MIGRATION-STATUS-ACK() 1.4 ORDER-MIGRATION-TO-OPER(MODE=3, STATUS=CEASE) 1.5 ORDER-MIGRATION-TO-OPER-ACK() 1.6 ORDER-MIGRATION-TO-OPER(MODE=3, STATUS=REDIRECT, NP-TYPE=PROVIDE) 1.7 ORDER-MIGRATION-TO-OPER-ACK() break Negatywna Weryfikacja Techniczna [przypadek szczególny gdy WT zarejestrowano po wysłaniu komunikatów do OA] 1.8 ORDER-MIGRATION-STATUS(STATUS=REJECTED) 1.9 ORDER-MIGRATION-STATUS-ACK() 1.10 ORDER-MIGRATION-STATUS(STATUS=REJECTED) 1.11 ORDER-MIGRATION-STATUS-ACK() 1.12 ORDER-MIGRATION-TO-OPER(STATUS=REDIRECT, NP-TYPE=CANCEL) 1.13 ORDER-MIGRATION-TO-OPER-ACK() 1.14 zmiana RN() 1.15 ORDER-MIGRATION-TO-OPER-ACC(ACC-STATUS=COMPLETED) 1.16 ORDER-MIGRATION-TO-OPER-ACC-ACK() 1.17 ORDER-MIGRATION-STATUS(STATUS=COMPLETED) 1.18 ORDER-MIGRATION-STATUS-ACK() Istotne z punktu widzenia procesu jest położenie poszczególnych komunikatów na osi czasu i tak kolejno: - komunikat ORDER-MIGRATION rejestrowany jest umownie w czasie T-0. TP przeprowadza weryfikację niezwłocznie. Weryfikacja pozytywna wiąże się z wysłaniem do Operatorów Dawcy i MWD_dla_migracji_V5 10 3- JWZ.doc 35

Macierzystego komunikatów ORDER-MIGRATION-TO-OPER. Operatorzy Dawca i Macierzysty nie udzielają odpowiedzi. W przypadku neagtywnej weryfikacji może pojawić się komunikat statusu do Operatora Biorcy, w szczególnym przypadku Negatywnej Weryfikacji Technicznej może pojawić się komunikat statusu do Operatorów Dawcy i Macierzystego. W dacie wymaganej Operator Macierzysty potwierdza wykonanie. Tym samym system BNP generuje komunikat do Operatora Biorcy ORDER- MIGRATION-STATUS ze statusem COMPLETED. Na tym proces przeniesienia numeru się kończy. Maksymalny czas na realizację, jaki możliwy jest do zgłoszenia zawiera się między 1 DR a 6 DR od T0. Fragment komunikatu ORDER-MIGRATION uwzględniający sekcję NP. Przy jego pomocy realizowane są wskazane warianty procesu NP, czyli przeniesienie i zmiana RN w sieci operatora w trybie od 1 do 6 DR.... MODE 1 - realizacja 2 - zapytanie 3 - realizacja w trybie 1-6 DR Tylko w procesie migracji z NP... NUMBER- PORTABILITY Opcja zachowania numeru NIE Tylko jeżeli SERVICE- TYPE <> 9 ORDER- MIGRATIO N- ELEMENT NP-TYPE INT(4) 1 - PROVIDE zgłoszenie przeniesienia numeru od innego operatora 2 - MOBILITY zgłoszenie przeniesienia numeru wewnątrz operatora 3 - CEASE zgłoszenia zwrotu numeru do operatora macierzystego 4 - CANCEL zgłoszenie anulacji przeniesienia (należy przywrócić poprzedni RN) DONOR-OPER CHAR(10) Identyfikator UKE, który oddaje numer (operator, który aktualnie posiada przenoszony numer) Jeżeli NP- TYPE = 1 lub 2 lub 3 ROUTING-NUMBER CHAR(6) Numer routingowy dla wymaganego przekierowania do centrali operatora biorcy Jeżeli NP- TYPE = 1 lub 2 7.7. Zmiana Numeru Rutingowego w Sieci Operatora Biorcy, Zmiana numeru RN w trybie 1-6 DR (MODE=3) realizowana jest przy użyciu ORDER-MIGRATION ze wskazaniem w sekcji NP parametru NP-TYPE = 2 (MOBILITY) oraz parametru MODE=3. Proces przewiduje negatywną weryfikację formalno-techniczną. W procesie tym nie przewiduje się anulowania. MWD_dla_migracji_V5 10 3- JWZ.doc 36

Data wymagana musi zawierać się w przedziale 1 DR do 6 DR względem T0. System BNP oczekuje do daty wymaganej na potwierdzenie wykonania. Po tym czasie zlecenie zmiany RN przyjmuje status COMPLETED. 7.8. Anulowanie Operatora Biorcy/Dawcy/Macierzystego zamówienia przeniesienia numeru, W przypadku zamówień zgłoszonych w trybie 1-6 DR (MODE=3) Anulowanie przeniesienia numeru nie jest możliwe przez żadną ze stron. Ewentualne komunikaty dotyczące anulowania takich procesów będą odrzucane. MWD_dla_migracji_V5 10 3- JWZ.doc 37

8. Migracja Usługi Abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego Przedsiębiorcy telekomunikacyjnego (Biorca) ze zmianą Usługi Hurtowej 8.1. Schemat migracji MWD_dla_migracji_V5 10 3- JWZ.doc 38

Aplikacje IT IT Obszaru Usług Hurtowych Wydział Systemów Kolekcji, Mediacji i Bilingu Hurtowego ul. Rakowicka 51, 31-510 Kraków tel.: 12 410 04 41 fax.: 12 422 06 40 http://www.hurt-tp.p 8.2. Opis kroków schematu 1) Abonent składa u Operatora Biorcy wniosek o nową usługę oraz rezygnację z aktualnych usług, która wymagana jest dla realizacji zamówienia. 2) a i b) W imieniu i z upoważnienia Abonenta Biorca przekazuje Operatorom Dawcom dokument Rezygnacji abonenta z aktualnych usług. Dla zgłoszeń dotyczących NP nie ma obowiązku przekazania dokumentów, udostępnienie oryginału może wystąpić na żądanie. c) Po otrzymaniu potwierdzenia dostarczenia oświadczenia o rezygnacji do Operatora Dawcy/Dawców Biorca przesyła do TP zamówienie w formie elektronicznej na nowe usługi np. LLUP z NP, ze wskazaniem usług, z których abonent rezygnuje u innych operatorów. d) TP w sytuacji, gdy komunikat xml nie zawiera niezbędnych informacji o rezygnacji z wszystkich usług hurtowych na danym łączu, TP powiadamia o tym operatora Biorcę, tym samym zamówienie jest zamykane z odpowiednim statusem (odrzucenie z przyczyn formalnych). TP ma 1 DR dla zamówień dotyczących NP lub 2 DR dla pozostałych zamówień Migracji na weryfikację, liczone od daty wpływu, gdzie dzień wpływu jest dniem zerowym. Przyczyny odrzuceń formalnych wypisane są w rozdziale 13. Odrzucenie z przyczyn formalnych jest możliwe również z innych powodów niż brak rezygnacji z usługi u Dawcy, zgodnie z załączonymi kodami odrzuceń dla NWF (rozdział 13). 3) TP wysyła komunikat do Operatorów Dawców wraz z przekazaniem daty rezygnacji lub trybu rozwiązania w przypadku NP. Komunikat jest wysyłany najpóźniej w ostatnim dniu weryfikacji (2DR). 4) a i b) Operatorzy Dawcy i Macierzysty w czasie 1 DR dla zamówień dotyczących NP lub 3 DR dla zamówień dotyczących Migracji od daty przesłania komunikatu (pkt.3) zobowiązani są do potwierdzenia realizacji zamówienia lub wskazują jeden z powodów odmowy realizacji zamówienia do TP. Operatorzy Dawcy mogą również zgłosić przesunięcie daty przełączenia w określonych granicach czasowych. Brak odpowiedzi w w/w terminie oznacza akceptację dla realizacji zgodnie z zamówieniem Biorcy. 5) a) TP potwierdza Operatorowi Biorcy realizację zlecenia wraz z datą realizacji bądź odmawia realizacji wskazując przyczynę i Operatora, który odmówił realizacji. b i c) Jednocześnie TP przesyła do Operatorów Dawców potwierdzenie daty zaprzestania świadczenia usług. 6) a, b i c) Biorca lub Dawcy, najpóźniej na 5 DR dla zamówień dotyczących NP lub 10 DR dla pozostałych zamówień Migracji przed datą wymaganą, mogą przesłać rezygnację Abonenta wysyłając właściwy komunikat xml do TP. 7) a i b) TP informuje Operatorów Dawców o rezygnacji i anuluje zamówienie Migracji Operatora Biorcy. Rezygnacja skutkuje wstrzymaniem wypowiedzenia umów z klientem - utrzymaniem obecnych usług. 8) TP potwierdza Biorcy wykonanie anulowania zamówienia. 9) Operator Macierzysty po zrealizowaniu zamówienia NP potwierdza do TP realizację zamówienia (dotyczy przypadku, gdy TP nie jest stroną). 10) TP po zrealizowaniu zamówienia Migracji potwierdza Biorcy realizację zamówienia. 8.3. Złożenie Zamówienia Migracji MWD_dla_migracji_V5 10 3- JWZ.doc

Ogólny przebieg procesu migracji przedstawia poniższy rysunek. MWD_dla_migracji_V5 10 3- JWZ.doc 40

8.3.1. Proces po stronie Operatora Biorcy Abonent składa zamówienie na przejście z usług głosowej i/lub szerokopasmowej na inną usługę wraz z upoważnieniem dla Przedsiębiorcy telekomunikacyjnego do występowania w jego imieniu w zakresie realizacji danego Zamówienia Migracji. Abonent wskazuje datę oraz tryb rozwiązania umowy z Abonentem, od której chciałby korzystać z nowej usługi (jest to data minimalna: 7 DR dla zamówień dotyczących NP lub dla pozostałych zamówień 21 dni roboczych od daty wpływu zamówienia, która nie uwzględnia czasu niezbędnego dla Operatora Biorcy na dopełnienie formalności wobec Dawców). Data ta jest uzależniona od terminów rozwiązania umów u Operatorów Dawców. W przypadku wystąpienia usługi NP w powiązaniu z inną usługą hurtową czas na weryfikację obliczany jest dla usługi o dłuższym wskaźniku na weryfikację. Biorca w terminie 10 dni roboczych dla zamówień Migracji od złożenia zamówienia powinien dopełnić formalności z dawcą/dawcami w postaci przekazania im papierowej rezygnacji tak, aby w momencie wysłania przez TP do Dawcy/Dawców komunikatu z prośbą o potwierdzenie daty realizacji, Dawcy nie odpowiedzieli TP, iż nie otrzymali rezygnacji z usługi. TP realizuje zamówienie w terminie nie krótszym niż 7 DR dla zamówień dotyczących usługi NP lub dla pozostałych zamówień Migracji w terminie 21 DR od daty wpływu i nie dłuższym niż 120 dni kalendarzowych od daty otrzymania poprawnego komunikatu xml i nie przypadającym na dzień świąteczny, ani wolny od pracy. Zamówienie Migracji w formie Komunikatu XML zawiera następujące dane: Identyfikator Zamówienia Migracji (15-cyfrowy) Kody Usług Hurtowych, z których następuje rezygnacja oraz Kody Dawcy/ów Kod usługi detalicznej (POTS) Kody zamawianych Usług Hurtowych Adres lokalu, Numer abonencki/identyfikator łącza abonenckiego/identyfikator usługi szerokopasmowej, Data wygenerowania zlecenia rozumiana, jako data wysłania Komunikatu XML Planowana data rozpoczęcia świadczenia przez Biorcę usług na rzecz Abonenta Tryb rozwiązania umowy (dla zamówień dotyczących NP) Opcjonalnie w zależności od usługi: Lokalizacja PG/PPD Numer kabla korespondencyjnego Numer pary w kablu korespondencyjnym Dane kontaktowe służb technicznych PT Routing Number dla Zamówień z zachowaniem numeru Rodzaj uwolnienia pętla lub, podpętla Rodzaj dostępu- pełny lub współdzielony Wersja usługi Opcja usługi Nazwa abonenta Kod usługi ADSL MWD_dla_migracji_V5 10 3- JWZ.doc 41

Biorca ma maksymalnie. 10 DR dla zamówień dotyczących Migracji na przesłanie rezygnacji Abonenta do Dawcy/Dawców. Dopiero po potwierdzeniu przez Dawcy/Dawców faktu otrzymania rezygnacji Abonenta z usługi hurtowej Biorca wysyła elektroniczne zamówienie do TP. 8.3.2. Opis kroków przesłania Zamówień Migracji 1. System Operatora Biorcy tworzy wiadomość e-mail, której treść zawiera zamówienie danego rodzaju Migracji w formacie XML ustalonym w tym dokumencie. Tak przygotowany e-mail jest kodowany kluczem publicznym TP i przesyłany do poczty wychodzącej Biorcy. 2. Serwer poczty wychodzącej Biorcy przesyła wiadomość do serwera poczty TP. 3. System BNP odczytuje wiadomość ze skrzynki poczty przychodzącej, sprawdza poprawność informatyczną przesłanego pliku Zamówień Migracji i zapisuje w systemie. 4. System BNP tworzy wiadomość e-mail, której treść zawiera potwierdzenie odbioru Zamówień Migracji w formacie XML ustalonym w tym dokumencie, koduje wiadomość kluczem publicznym Przedsiębiorcy telekomunikacyjnego i przesyła do serwera poczty wychodzącej TP. 5. Serwer poczty wychodzącej TP przesyła wiadomość potwierdzenia odbioru do serwera poczty Przedsiębiorcy telekomunikacyjnego. 6. System Przedsiębiorcy telekomunikacyjnego odczytuje wiadomość ze skrzynki poczty i odnotowuje na podstawie pliku potwierdzenia status Zamówień Migracji. 8.3.3. Opis kroków przesłania grupy odpowiedzi na Zamówienia Migracji 1. System BNP tworzy wiadomość e-mail, której treść zawiera odpowiedzi na Zamówienia Migracji w formacie XML ustalonym w tym dokumencie, koduje wiadomość kluczem publicznym Przedsiębiorcy telekomunikacyjnego i przesyła do serwera poczty wychodzącej TP. 2. Serwer poczty wychodzącej przesyła wiadomość do serwera poczty Przedsiębiorcy telekomunikacyjnego. 3. System Przedsiębiorcy telekomunikacyjnego odczytuje wiadomość ze skrzynki poczty przychodzącej sprawdza poprawność informatyczną przesłanego pliku z odpowiedziami na Zamówienia i zapisuje w systemie. 4. System Przedsiębiorcy telekomunikacyjnego tworzy wiadomość e-mail, której treść zawiera potwierdzenie odbioru odpowiedzi z Zamówieniem, w formacie XML ustalonym w tym dokumencie i jest zakodowana PGP, a następnie przesyła do serwera poczty wychodzącej Przedsiębiorcy telekomunikacyjnego. 5. Serwer poczty wychodzącej Przedsiębiorcy telekomunikacyjnego przesyła wiadomość potwierdzenia odbioru do serwera poczty TP. 6. System BNP odczytuje wiadomość ze skrzynki poczty przychodzącej odnotowuje na podstawie pliku potwierdzenia status odbioru paczki odpowiedzi na Zamówienia Migracji. MWD_dla_migracji_V5 10 3- JWZ.doc 42

8.3.4. Komunikat Zamówień Migracji Temat wiadomości: id:[subject-id][interaction-id]zamowienie-migracji[xml] ORDER-MIGRATION (Operator Biorca->BNP)<T_3_0> Komunikat został opisany w punkcie 12.2.1 ORDER-MIGRATION Komunikat Zamówień Migracji. Operator Biorca -> BNP Komunikat przesyłany kanałem elektronicznym, Format xml: Przykładowy XML: Przejście WLR->WLR <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>6</subject-id> <dest-subject-id>1</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration> <service-oper>1</service-oper> <generate-date>2008-12-22 08:00:00</generate-date> <order-migration-element> <item>1</item> <order-number>000060005412312</order-number> <number>322251527</number> <service-id></service-id> <client-name>kornel Makuszyński</client-name> <client-address> <city-name>kozia Wólka</city-name> <street-name>koziołka Matołka</street-name> <building-number>12</building-number> <flat-number>35</flat-number> <postal-code>00-345</postal-code> <postal-name>koziegłowy</postal-name> </client-address> <begin-date>2009-01-31</begin-date> <msg></msg> <service-type>2</service-type> <service-specification> <number-type>1</number-type> <number-count>1</number-count> <number-lo>322251527</number-lo> </service-specification> <cease> <cease-type>1</cease-type> <donor-oper>10</donor-oper> <cease-mode>1</cease-mode> </cease> <order> <order-type>1</order-type> </order> </order-migration-element> </order-migration> </cbnp-message> MWD_dla_migracji_V5 10 3- JWZ.doc 43

Przejście WLR->NP <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>6</subject-id> <dest-subject-id>1</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration> <service-oper>1</service-oper> <generate-date>2008-12-22 08:00:00</generate-date> <order-migration-element> <item>1</item> <order-number>000060005412312</order-number> <number>321234567</number> <service-id></service-id> <client-name>kornel Makuszyński</client-name> <client-address> <city-name>kozia Wólka</city-name> <street-name>koziołka Matołka</street-name> <building-number>12</building-number> <flat-number>35</flat-number> <postal-code>00-345</postal-code> <postal-name>koziegłowy</postal-name> </client-address> <begin-date>2009-01-31</begin-date> <msg>komunikat</msg> <service-type>2</service-type> <service-specification> <number-type>1</number-type> <number-count>1</number-count> <number-lo>321234567</number-lo> </service-specification> <cease> <cease-type>1</cease-type> <donor-oper>10</donor-oper> <cease-mode>1</cease-mode> </cease> <number-portability> <np-type>1</np-type> <donor-oper>1</donor-oper> <routing-number>c3210</routing-number> </number-portability> </order-migration-element> </order-migration> </cbnp-message> 8.3.5. Komunikat potwierdzenia zamówień usług migracji Temat wiadomości: id:[subject-id][interaction-id]zamowienie-migracja-ack[xml] ORDER-MIGRATION-ACK (BNP->Operator Biorca)<T_3_0> Komunikat został opisany w punkcie 12.2.2 ORDER-MIGRATION-ACK Komunikat potwierdzenia zamówień usług migracji. BNP -> Operator Biorca Komunikat przesyłany kanałem elektronicznym, Format xml: MWD_dla_migracji_V5 10 3- JWZ.doc 44

Przykładowy XML: Odrzucenie komunikatu zamówienia <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>1</subject-id> <dest-subject-id>6</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-ack> <acceptance> <item>1</item> <order-number>000060005412312</order-number> <acc-status>1</acc-status> <rejection-reason>168</rejection-reason> <msg>brak planowanej daty uruchomienia usługi</msg> <acc-date>2008-12-22 14:00:00</acc-date> <rejection-reason-element> <rejection-reason>167</rejection-reason> <msg>brak wypełnionego pola adres</msg> </rejection-reason-element> </acceptance> </order-migration-ack> </cbnp-message> Przyjęcie komunikatu zamówienia <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>1</subject-id> <dest-subject-id>6</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-ack> <acceptance> <item>1</item> <order-number>000060005412313</order-number> <acc-status>0</acc-status> <receive-date>2008-12-22 09:00:00</receive-date> <acc-date>2008-12-22 15:00:00</acc-date> </acceptance> </order-migration-ack> </cbnp-message> 8.4. Negatywna weryfikacja formalna TP TP na weryfikację formalną dla zamówień dotyczących NP ma 1 DR od wpływu zamówienia do TP, dla pozostałych zamówień Migracji 2 DR od wpływu zamówienia do TP. Jeśli zamówienie jest odrzucane (Wynik weryfikacji negatywny), to następuje jego anulowanie ze wskazaniem przyczyny (kodu odrzucenia rozdział 13). Nie ma możliwości poprawiania zamówienia, w tym przypadku Przedsiębiorca telekomunikacyjny (biorca) składa nowe Zamówienie Migracji/NP. MWD_dla_migracji_V5 10 3- JWZ.doc 45

8.4.1. Komunikat statusu Komunikat ORDER-MIGRATION-STATUS z ustalonym statusem na 1 REJECTED. Komunikat ORDER-MIGRATION-STATUS wykorzystywany jest wielokrotnie w komunikacji zwrotnej do Przedsiębiorcy telekomunikacyjnego, na różnych etapach procesu. Niektóre pola i sekcje występują w komunikacie tylko w niektórych krokach procesu. Temat wiadomości: id:[subject-id][interaction-id]status-migracja[xml] ORDER-MIGRATION-STATUS (BNP->Operator)<T_3_0> Komunikat został opisany w punkcie 12.2.3 ORDER-MIGRATION-STATUS Komunikat statusu. BNP -> Operator Komunikat jest dostępny dla Operatora poprzez kanał elektroniczny. Format xml: Lista atrybutów: PRODUCT-ID - identyfikator produktu ATTR-ID - dopuszczalny atrybut dla danego PRODUCT-ID ATTR-NAME - opis atrybutu - w komunikacie może być inny lub pusty ATTR-VALUE - możliwe lub przykładowe wartości dla atrybutów; jeśli w komunikacie pojawią się inne wartości niż wymienione powinny być zignorowane. Lista atrybutów została opisana w punkcie 12.2.4. Przykładowy XML: Status odrzucenia migracji: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>2612032</interaction-id> <subject-id>1</subject-id> <dest-subject-id>4633</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-status> <oper>4633</oper> <generate-date>2009-05-27 16:31:47</generate-date> <order-migration-status-element> <item>1</item> <service-number>2612026</service-number> <order-number>046330000000001</order-number> MWD_dla_migracji_V5 10 3- JWZ.doc 46

<number>123771108</number> <service-id></service-id> <client-name>jan Kowalski</client-name> <client-address> <city-name>włocławek</city-name> <street-name>tajna</street-name> <building-number>1</building-number> <flat-number>10</flat-number> <postal-code>87-800</postal-code> <postal-name>włocławek</postal-name> </client-address> <service-status>1</service-status> <implementation-date></implementation-date> <rejection-reason>271</rejection-reason> <msg>numer 123771108 nie należy do operatora dawcy WLR.</msg> <status-date>2009-05-27 16:31:47</status-date> <service-type>1</service-type> <cease> <cease-type>1</cease-type> </cease> <number-portability> <np-type>1</np-type> </number-portability> <rejection-reason-element> <rejection-reason>271</rejection-reason> <msg>numer 123771108 nie należy do operatora dawcy WLR.</msg> <rejected-service>1</rejected-service> <rejecting-party>1</rejecting-party> </rejection-reason-element> <rejection-reason-element> <rejection-reason>271</rejection-reason> <msg>numer 123771108 nie należy do operatora dawcy dla przeniesienia numeru.</msg> <rejected-service>1</rejected-service> <rejecting-party>1</rejecting-party> </rejection-reason-element> <rejection-reason-element> <rejection-reason>232</rejection-reason> <msg>zostało już zgłoszone zamówienie o podanym numerze</msg> <rejected-service>1</rejected-service> <rejecting-party>1</rejecting-party> </rejection-reason-element> </order-migration-status-element> </order-migration-status> </cbnp-message> Status uzgodnień dat migracji: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>2837801</interaction-id> <subject-id>1</subject-id> <dest-subject-id>87</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-status> <oper>87</oper> <generate-date>2009-09-07 13:19:03</generate-date> <order-migration-status-element> <item>1</item> <service-number>2837687</service-number> <order-number>000569031629001</order-number> <number>123771500</number> <service-id></service-id> MWD_dla_migracji_V5 10 3- JWZ.doc 47

<client-name>jan Kowalski</client-name> <client-address> <city-name>warszawa</city-name> <street-name>nieznana</street-name> <building-number>1</building-number> <flat-number>2</flat-number> <postal-code>03-098</postal-code> <postal-name>waszaw</postal-name> </client-address> <service-status>11</service-status> <implementation-date>2009-10-29</implementation-date> <rejection-reason>0</rejection-reason> <msg>akceptacja przez Macierzystego bez zmiany daty. Akceptacja Dawcy tu bez zmiany daty.</msg> <status-date>2009-09-07 13:18:44</status-date> <service-type>1</service-type> <cease> <cease-type>1</cease-type> </cease> <number-portability> <np-type>1</np-type> </number-portability> </order-migration-status-element> </order-migration-status> </cbnp-message> Status wykonania migracji: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>2849447</interaction-id> <subject-id>1</subject-id> <dest-subject-id>56</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-status> <oper>56</oper> <generate-date>2009-09-11 12:49:44</generate-date> <order-migration-status-element> <item>1</item> <service-number>2849276</service-number> <order-number>000560031654001</order-number> <number>123771501</number> <service-id></service-id> <client-name>jan Kowalski</client-name> <client-address> <city-name>kraków</city-name> <street-name>krakowska</street-name> <building-number>1</building-number> <flat-number>1</flat-number> <postal-code>34-001</postal-code> <postal-name>kraków</postal-name> </client-address> <service-status>4</service-status> <implementation-date>2009-12-01</implementation-date> <rejection-reason>0</rejection-reason> <msg>(msg np.) service-status COMPLETED (4)</msg> <status-date>2009-09-11 12:49:12</status-date> <service-type>2</service-type> <cease> <cease-type>1</cease-type> </cease> <service-specification> <number-type>1</number-type> <number-count>1</number-count> MWD_dla_migracji_V5 10 3- JWZ.doc 48

<number-lo>123771502</number-lo> <number-hi>123771502</number-hi> <product-id>wlr</product-id> <line-attr> <attr-id>vas01</attr-id> <attr-name>plan WLR</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas02</attr-id> <attr-name>preselekcja MS Miękka (CPS-ILD)</attr-name> <attr-value>1011</attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas03</attr-id> <attr-name>preselekcja MN Miękka (CPS-DLD)</attr-name> <attr-value>1011</attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas04</attr-id> <attr-name>bolkada 1033</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas06</attr-id> <attr-name>połączenia oczekujące (CW)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas07</attr-id> <attr-name>budzenie (ALM)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas14</attr-id> <attr-name>blokada przekierowanych połączeń (PSN)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas15</attr-id> <attr-name>prezentacja numeru (CLIP)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas16</attr-id> <attr-name>blokada prezentacji numeru (CLIR)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas17</attr-id> <attr-name>blokada prezentacji numeru dla jednego połączenia (CLIR PCA)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas18</attr-id> <attr-name>blokada połączeń anonimowych (ACR)</attr-name> <attr-value></attr-value> MWD_dla_migracji_V5 10 3- JWZ.doc 49

<old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas20</attr-id> <attr-name>połączenia trójstronne (3PTY)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas22</attr-id> <attr-name>blokada połączeń (według poziomów w TP)</attr-name> <attr-value>w02</attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas24</attr-id> <attr-name>przekierowanie połączeń bezwarunkowe (CFU)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas25</attr-id> <attr-name>przekierowanie połączeń w przypadku zajętości (CFB)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas26</attr-id> <attr-name>przekierowanie połączeń w przypadku nieobecności (CFNR)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> </service-specification> <service-specification> <number-type>1</number-type> <number-count>1</number-count> <number-lo>123771501</number-lo> <number-hi>123771501</number-hi> <product-id>wlr</product-id> <line-attr> <attr-id>vas01</attr-id> <attr-name>plan WLR</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas02</attr-id> <attr-name>preselekcja MS Miękka (CPS-ILD)</attr-name> <attr-value>1011</attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas03</attr-id> <attr-name>preselekcja MN Miękka (CPS-DLD)</attr-name> <attr-value>1011</attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas04</attr-id> <attr-name>bolkada 1033</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas06</attr-id> <attr-name>połączenia oczekujące (CW)</attr-name> <attr-value></attr-value> MWD_dla_migracji_V5 10 3- JWZ.doc 50

<old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas07</attr-id> <attr-name>budzenie (ALM)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas14</attr-id> <attr-name>blokada przekierowanych połączeń (PSN)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas15</attr-id> <attr-name>prezentacja numeru (CLIP)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas16</attr-id> <attr-name>blokada prezentacji numeru (CLIR)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas17</attr-id> <attr-name>blokada prezentacji numeru dla jednego połączenia (CLIR PCA)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas18</attr-id> <attr-name>blokada połączeń anonimowych (ACR)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas20</attr-id> <attr-name>połączenia trójstronne (3PTY)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas22</attr-id> <attr-name>blokada połączeń (według poziomów w TP)</attr-name> <attr-value>w11</attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas24</attr-id> <attr-name>przekierowanie połączeń bezwarunkowe (CFU)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas25</attr-id> <attr-name>przekierowanie połączeń w przypadku zajętości (CFB)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> </line-attr> <line-attr> <attr-id>vas26</attr-id> <attr-name>przekierowanie połączeń w przypadku nieobecności (CFNR)</attr-name> <attr-value></attr-value> <old-attr-value></old-attr-value> MWD_dla_migracji_V5 10 3- JWZ.doc 51

</line-attr> </service-specification> </order-migration-status-element> </order-migration-status> </cbnp-message> 8.4.2. Komunikat potwierdzenia statusu Temat wiadomości: id:[subject-id][interaction-id]status-migracja-ack[xml] ORDER-MIGRATION-STATUS-ACK (Operator->BNP)<Brak> Komunikat został opisany w punkcie 12.2.5 ORDER-MIGRATION-STATUS-ACK Komunikat potwierdzenia statusu. Operator -> BNP Komunikat wprowadzany przez kanał elektroniczny Format xml: Przykładowy XML: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>6</subject-id> <dest-subject-id>1</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-status-ack> <acceptance> <item>1</item> <acc-status>1</acc-status> <rejection-reason>987</rejection-reason> <msg>komunikat 987</msg> <acc-date>2008-12-22 14:00:00</acc-date> </acceptance> </order-migration-status-ack> </cbnp-message> 8.5. Przekazanie daty rezygnacji lub daty wykonania NP do Dawców Po pozytywnej weryfikacji formalnej TP wysyła komunikat do Dawcy/Dawców oraz Operatora Macierzystego (jeśli nie jest nim Dawca) z informacją o dacie planowanej realizacji usługi wskazanej przez Biorcę w Zamówieniu oraz trybem rozwiązania umowy dla zamówień dotyczących NP. Dawca/Dawcy oraz Macierzysty dokonuje/ą weryfikacji formalnej otrzymanego zapytania. Dawca/Dawcy oraz Macierzysty może/mogą odmówić realizacji Zamówienia tylko w przypadkach opisanych w kodach odrzuceń, stanowiących załącznik do Oferty. Komunikat z zapytaniem o daty rezygnacji może zostać wysłany w wyniku pozytywnego rozpatrzenia reklamacji dotyczącej negatywnego wyniku weryfikacji formalnej dla zamówień Migracji. Nie dotyczy zamówień NP. Komunikat ten może być poprzedzony wcześniejszym komunikatem NWF MWD_dla_migracji_V5 10 3- JWZ.doc 52

8.5.1. Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP Temat wiadomości: id:[subject-id][interaction-id]rezygnacja-z-uslug[xml] ORDER-MIGRATION-TO-OPER (BNP -> Operator Dawca)<T_3_0> Komunikat został opisany w punkcie 12.2.6 ORDER-MIGRATION-TO-OPER Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP. BNP -> Operator Dawca Komunikat przesyłany kanałem elektronicznym, Format xml: Przykładowy XML: Zgłoszenie rezygnacji z umowy WLR <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>1</subject-id> <dest-subject-id>10</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-to-oper> <donor-oper>10</donor-oper> <generate-date>2008-12-22 08:00:00</generate-date> <order-migration-to-oper-element> <item>1</item> <service-number>0002788362</service-number> <order-number>000060005412312</order-number> <number>322251527</number> <service-id></service-id> <client-name>kornel Makuszyński</client-name> <client-address> <city-name>kozia Wólka</city-name> <street-name>koziołka Matołka</street-name> <building-number>12</building-number> <flat-number>35</flat-number> <postal-code>00-345</postal-code> <postal-name>koziegłowy</postal-name> </client-address> <service-status>10</service-status> <implementation-date>2009-01-31</implementation-date> <msg>informacje dodatkowe</msg> <service-type>2</service-type> MWD_dla_migracji_V5 10 3- JWZ.doc 53

<service-specification> <number-type>1</number-type> <number-count>1</number-count> <number-lo>322251527</number-lo> </service-specification> <cease> <cease-type>1</cease-type> <recipient-oper>6</recipient-oper> <cease-mode>1</cease-mode> </cease> </order-migration-to-oper-element> </order-migration-to-oper> </cbnp-message> Zgłoszenie przekierowania numeru do operatora macierzystego <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>1</subject-id> <dest-subject-id>55</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-to-oper> <donor-oper>55</donor-oper> <generate-date>2008-12-22 08:00:00</generate-date> <order-migration-to-oper-element> <item>1</item> <service-number>0002788362</service-number> <order-number>000060005412312</order-number> <number>322251527</number> service-id></service-id> <client-name>kornel Makuszyński</client-name> <client-address> <city-name>kozia Wólka</city-name> <street-name>koziołka Matołka</street-name> <building-number>12</building-number> <flat-number>35</flat-number> <postal-code>00-345</postal-code> <postal-name>koziegłowy</postal-name> </client-address> <service-status>12</service-status> <implementation-date>2009-02-01</implementation-date> <msg>informacje dodatkowe</msg> <service-type>2</service-type> <service-specification> <number-type>1</number-type> <number-count>1</number-count> <number-lo>322251527</number-lo> </service-specification> <number-portability> <np-type>1</np-type> <donor-oper>1</donor-oper> <recipent-oper>6</recipent-oper> <routing-number>c3228</number-portability> </number-portability> </order-migration-to-oper-element> </order-migration-to-oper> </cbnp-message> MWD_dla_migracji_V5 10 3- JWZ.doc 54

8.5.2. Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP Temat wiadomości: id:[subject-id][interaction-id]rezygnacja-z-uslug-ack[xml] ORDER-MIGRATION-TO-OPER-ACK (Operator Dawca->BNP) <T_3_0> Komunikat został opisany w punkcie 12.2.7 ORDER-MIGRATION-TO-OPER-ACK Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP. Operator Dawca -> BNP Komunikat wprowadzany przez kanał elektroniczny Format xml:. Przykładowy XML: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>10</subject-id> <dest-subject-id>1</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-to-oper-ack> <acceptance> <item>1</item> <acc-status>0</acc-status> <acc-date>2008-12-22 14:00:00</acc-date> </acceptance> </order-migration-to-oper-ack> </cbnp-message> 8.6. Potwierdzenia realizacji zlecenia Zamówienia lub jego odrzucenie TP czeka na odpowiedź od Dawcy/Dawców oraz Macierzystego w zakresie weryfikacji zamówienia wysłanego przez TP. a. Gdy TP nie otrzyma w ciągu 1 DR dla zamówień dotyczących NP lub 3 DR dla pozostałych zamówień Migracji odpowiedzi od Dawcy/Dawców lub Macierzystego, to realizuje zlecenie z terminem wskazanym przez Operatora Biorcę w imieniu Abonenta, o ile weryfikacja techniczna jest pozytywna. b. Gdy TP otrzyma w ciągu 1 DR dla zamówień dotyczących NP lub 3 DR dla pozostałych zamówień Migracji odpowiedź od Dawcy/Dawców lub Macierzystego, to weryfikuje wskazane przez nich daty: i. Realizuje Zamówienie z datą najdłuższą (wskazaną przez Operatora Biorcę dla zamówień NP dotyczących rozwiązania umowy w trybie natychmiastowym lub przez Operatora Biorcę lub, Dawcę dla pozostałych zamówień), o ile data ta nie przekracza okresu 120 dni kalendarzowych od daty wpływu do TP MWD_dla_migracji_V5 10 3- JWZ.doc 55

ii. Jeśli komunikaty nadeszły po upływie czasu oczekiwania na odpowiedź Dawcy lub podana zmodyfikowana data nie spełnia określonych kryteriów system komunikacji z PT odrzuca je z odpowiednim kodem odrzutu: 1. data jest dłuższa niż 120 dni kalendarzowych lub krótsza niż 7 DR dla zamówień dotyczących usługi NP. lub dla pozostałych zamówień Migracji 21 dni roboczych. 2. realizacja przypada na dzień świąteczny lub wolny od pracy, 3. odpowiedź od Dawcy/Macierzystego wpłynęła po terminie Dawca/Dawcy odpowiadają negatywnie między innymi w sytuacji gdy: 1. Dawca/Dawcy zweryfikowali Zamówienia negatywnie pod względem formalnym (brak Abonenta/ usługi) Zamówienia 2. Dawca/Dawcy odpowiedział/odpowiedzieli, że adres instalacji nie jest właściwy 3. Dawca/Dawcy świadczą usługę dla innego Abonenta (opcjonalnie dla Migracji 1 i 3). TP, przed przesłaniem komunikatu do Biorcy i Dawcy/Dawców oraz Macierzystego, weryfikuje możliwości techniczne realizacji Zamówienia Biorcy. TP ma 1 DR dla zamówień dotyczących NP lub 6 DR dla pozostałych zamówień Migracji, na weryfikację możliwości technicznych realizacji Zamówienia migracji (termin ten jest liczony maksymalnego czasu przeznaczonego na weryfikację formalno-prawną)". 8.6.1. Komunikat akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców Temat wiadomości: id:[subject-id][interaction-id]akceptacja-migracji[xml] ORDER-MIGRATION-TO-OPER-ACC(Operator Dawca->BNP)<T_3_0> Komunikat został opisany w punkcie 12.2.8 ORDER-MIGRATION-TO-OPER-ACC Komunikat akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców. Operator Dawca -> BNP Komunikat przesyłany kanałem elektronicznym Format xml: Przykładowy XML: Status akceptacji zgłoszenia rezygnacji z umowy <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> MWD_dla_migracji_V5 10 3- JWZ.doc 56

<subject-id>10</subject-id> <dest-subject-id>1</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-to-oper-acc> <service-oper>1</service-oper> <generate-date>2008-12-22 08:00:00</generate-date> <order-migration-to-oper-acc-element> <item>1</item> <service-number>0002788362</service-number> <order-number>000060005412312</order-number> <number>322251527</number> <service-id></service-id> <service-status>10</service-status> <acc-status>0</acc-status> <implementation-date>2009-01-31</implementation-date> <rejection-reason></rejection-reason> <msg></msg> <acc-status-date>2008-12-22</status-date> <service-type>2</service-type> </order-migration-to-oper-acc-element> </order-migration-to-oper-acc> </cbnp-message> Status odrzucenia zgłoszenia przekierowania numeru od operatora macierzystego <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>55</subject-id> <dest-subject-id>1</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-to-oper-acc> <service-oper>1</service-oper> <generate-date>2008-12-22 08:00:00</generate-date> <order-migration-to-oper-acc-element> <item>1</item> <service-number>0002788362</service-number> <order-number>000060005412312</order-number> <number>322251527</number> <service-id></service-id> <service-status>12</service-status> <acc-status>1</acc-status> <implementation-date></implementation-date> <rejection-reason>987</rejection-reason> <msg>brak mozliwosci realizacji routingu, brak punktu styku z operatorem</msg> <acc-status-date>2008-12-22</status-date> <service-type>2</service-type> </order-migration-to-oper-acc-element> </order-migration-to-oper-acc> </cbnp-message> Status akceptacji zgłoszenia rezygnacji z umowy ze zmianą daty <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>10</subject-id> <dest-subject-id>1</dest-subject-id> <test-ver>0</test-ver> MWD_dla_migracji_V5 10 3- JWZ.doc 57

</msg-header> <order-migration-to-oper-acc> <service-oper>1</service-oper> <generate-date>2008-12-22 08:00:00</generate-date> <order-migration-to-oper-acc-element> <item>1</item> <service-number>0002788362</service-number> <order-number>000060005412312</order-number> <number>322251527</number> <service-id></service-id> <service-status>10</service-status> <acc-status>2</acc-status> <implementation-date>2009-02-15</implementation-date> <rejection-reason>999</rejection-reason> <msg>komunikat 999</msg> <acc-status-date>2008-12-22</status-date> <service-type>2</service-type> </order-migration-to-oper-acc-element> </order-migration-to-oper-acc> </cbnp-message> 8.6.2. Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców Temat wiadomości: id:[subject-id][interaction-id]akceptacja-migracji-ack[xml] ORDER-MIGRATION-TO-OPER-ACC-ACK (BNP -> Operator Dawca)<T_3_0> Komunikat został opisany w punkcie 12.2.9 ORDER-MIGRATION-TO-OPER-ACC-ACK Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców. BNP -> Operator Dawca Komunikat przesyłany kanałem elektronicznym, Format xml: Przykładowy XML: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>1</subject-id> <dest-subject-id>10</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-to-oper-acc-ack> <acceptance> <item>1</item> <acc-status>0</acc-status> <acc-date>2008-12-22 14:00:00</acc-date> </acceptance> </order-migration-to-oper-acc-ack> </cbnp-message> MWD_dla_migracji_V5 10 3- JWZ.doc 58

8.7. Potwierdzenie do Biorcy oraz Dawcy/Dawców bądź odmowa realizacji Zamówienia Migracji wraz z datą realizacji Po otrzymaniu komunikatu od Dawcy/Dawców o dokonanej weryfikacji formalnej Zamówienia Migracji oraz po dokonaniu w TP weryfikacji technicznej Zamówienia (Dla przypadków, kiedy TP jest pośrednikiem TP nie wykonuje weryfikacji, obowiązek ten spoczywa na Operatorze Macierzystym)., TP wysyła komunikat do Biorcy oraz Dawcy/Dawców: o odrzuceniu Zamówienia wraz ze wskazaniem przyczyny technicznej (patrz rozdział 13) bądź weryfikacji formalnej Dawcy/Dawców o przyjęciu do realizacji ze wskazaniem daty realizacji Zamówienia. W przypadku pozytywnej weryfikacji technicznej data podana przez TP jest ostateczna i nie podlega modyfikacji. Dawca, którego okres wypowiedzenia umowy jest krótszy niż wskazana przez TP data ma obowiązek przedłużenia czasu świadczenia usługi Abonentowi do daty wskazanej przez TP w powyższym komunikacie. 8.7.1. Komunikat - informacja o dacie realizacji Zamówienia Migracji/odmowie realizacji zamówienia Migracji W tym kroku procesu w przypadku przesyłania daty realizacji Zamówienia Migracji stosowany jest taki sam komunikat jak w punkcie 12.2.3 ORDER-MIGRATION-STATUS Komunikat statusu. Komunikat ten wysyłany jest do operatora Biorcy, Dawcy/Dawców oraz operatora Macierzystego (jeśli bierze udział w procesie migracji). Do operatora Biorcy przesyłany jest status OK, do operatorów Dawców status CONFIRMED-CEASE, do operatora Macierzystego status CONFIRMED-REDIRECT. W przypadku odmowy realizacji Zamówienia Migracji do operatora Biorcy i Dawców przesyłany jest status REJECTED. Do operatora macierzystego (jeśli bierze udział w procesie migracji) wysyłany jest taki sam komunikat jak w punkcie 12.2.6 ORDER-MIGRATION-TO-OPER Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP z wypełnioną sekcją NUMBER-PORTABILITY i typem przeniesienia ustawionym na CANCEL. 8.7.2. Komunikat potwierdzenia dla komunikatu informacji o dacie realizacji Zamówienia Migracji/odmowie realizacji zamówienia Migracji W tym kroku procesu stosowany jest taki sam komunikat jak w punkcie 12.2.5 ORDER-MIGRATION-STATUS- ACK Komunikat potwierdzenia statusu. Komunikat ten przysyłany jest przez operatora Biorcę oraz Dawcę/Dawców. Operator Macierzysty (jeśli bierze udział w procesie migracji) przysyła taki sam komunikat jak w punkcie 12.2.7 ORDER-MIGRATION-TO-OPER-ACK Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP. MWD_dla_migracji_V5 10 3- JWZ.doc 59

8.8. Rezygnacja z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji Biorca oraz Dawcy/Dawca tylko w przypadku otrzymania pisemnej rezygnacji z wypowiedzenia umowy Abonenta zawartej z Dawcą lub wypowiedzenia umowy abonenckiej zawartej z Biorcą. Rezygnacja taka jest skuteczna, jeśli wpłynie od Dawcy/Dawców lub Biorcy lub Macierzystego do TP najpóźniej 5 DR dla zamówień dotyczących NP lub 10 DR przed datą wymaganą realizacji pozostałych Zamówień Migracji. UWAGA: Należy zaznaczyć, iż operator zgłaszający rezygnację przesyła do TP komunikat ORDER-MIGRATION- CANCEL. TP rozsyła do Biorcy i Dawcy/Dawców komunikat ORDER-MIGRATION-STATUS a do operatora Macierzystego ORDER-MIGRATION-TO-OPER. Jest to bardzo istotne odstępstwo, które należy mieć na uwadze projektując system komunikacji z TP. 8.8.1. Komunikat Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji Temat wiadomości: id:[subject-id][interaction-id]anulowanie-migracji[xml] ORDER-MIGRATION-CANCEL (Operator ->BNP)<T_3_0> Komunikat został opisany w punkcie 12.2.10 ORDER-MIGRATION-CANCEL Komunikat Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji. Operator -> BNP Komunikat przesyłany kanałem elektronicznym, Format xml: Przykładowy XML: Zgłoszenie anulowania migracji <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>6</subject-id> <dest-subject-id>1</dest-subject-id> MWD_dla_migracji_V5 10 3- JWZ.doc 60

<test-ver>0</test-ver> </msg-header> <order-migration-cancel> <service-oper>1</service-oper> <generate-date>2008-12-22 08:00:00</generate-date> <service-number>0002788362</service-number> <order-number>000060005412312</order-number> <number>322251527</number> <service-id></service-id> <rejection-reason>987</rejection-reason> <msg>anulowanie z powodu rezygnacji klienta</msg> <service-type>2</service-type> </order-migration-cancel> </cbnp-message> 8.8.2. Komunikat potwierdzenia Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji Temat wiadomości: id:[subject-id][interaction-id]anulowanie-migracji-ack[xml] ORDER-MIGRATION-CANCEL-ACK (BNP->Operator)<T_3_0> Komunikat został opisany w punkcie 12.2.11 ORDER-MIGRATION-CANCEL-ACK Komunikat potwierdzenia Rezygnacji z Zamówienia Migracji. BNP -> Operator Komunikat przesyłany kanałem elektronicznym Format xml: Przykładowy XML: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>1</subject-id> <dest-subject-id>6</dest-subject-id> <test-ver>0</test-ver> </msg-header> <order-migration-cancel-ack> <acceptance> <acc-status>0</acc-status> <acc-date>2008-12-22 14:00:00</acc-date> </acceptance> </order-migration-cancel-ack> </cbnp-message> 8.9. Potwierdzenie do Biorcy, Dawcy/ów anulowania zamówienia migracji TP wysyła zarówno do Biorcy, jak i Dawcy/Dawców komunikat potwierdzający anulowanie Zamówienia Migracji. Jeśli taka rezygnacja wpłynie w okresie krótszymi niż 5 DR dla zamówień dotyczących NP lub 10 DR przed datą wskazaną dla pozostałych zamówień Migracji, TP odrzuci ją z komunikatem Rezygnacja na tym etapie jest nie jest możliwa i TP zrealizuje Zamówienie Migracji w uzgodnionym wcześniej terminie. MWD_dla_migracji_V5 10 3- JWZ.doc 61

TP przesyła do Biorcy, Dawcy/ów komunikat o anulowaniu zamówienia Migracji. 8.9.1. Komunikat statusu anulowania zamówienia migracji W tym kroku procesu stosowany jest taki sam komunikat jak w punkcie 12.2.3 ORDER-MIGRATION-STATUS Komunikat statusu. Komunikat ten wysyłany jest do operatora Biorcy, Dawcy/Dawców. Do operatora Biorcy jak i Dawcy/Dawców przesyłany jest status CANCEL. Do operatora macierzystego (jeśli bierze udział w procesie migracji) wysyłany jest taki sam komunikat jak w punkcie 12.2.6 ORDER-MIGRATION-TO-OPER Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP z wypełnioną sekcją NUMBER- PORTABILITY i typem przeniesienia ustawionym na CANCEL. 8.9.2. Komunikat potwierdzenia statusu anulowania zamówienia migracji W tym kroku procesu stosowany jest taki sam komunikat jak w punkcie 12.2.5 ORDER-MIGRATION-STATUS- ACK Komunikat potwierdzenia statusu. Komunikat ten przysyłany jest przez operatora Biorcę oraz Dawcę/Dawców. Operator Macierzysty (jeśli bierze udział w procesie migracji) przysyła taki sam komunikat jak w punkcie 12.2.7 ORDER-MIGRATION-TO-OPER-ACK Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP. 8.10. Potwierdzenie od Dawcy i Macierzystego wykonania NP. W przypadku, gdy TP jest pośrednikiem w przekazywaniu komunikatów dla poprawnej realizacji zamówień NP, Operator Dawca i Macierzysty niezwłocznie (w dacie realizacji) po wykonaniu przeniesienia informuje TP o pozytywnej realizacji technicznej. W przypadku braku komunikatu TP realizuje zamówienie w wymaganej dacie. MWD_dla_migracji_V5 10 3- JWZ.doc 62

8.10.1. Komunikat potwierdzenia realizacji przez Dawcę i Macierzystego Przy pomocy komunikatu ORDER-MIGRATION-TO-OPER-ACC operator Dawca i Macierzysty zgłaszają do TP pozytywną realizację techniczną. Realizacja ta odbywa się poprzez wskazanie w komunikacie pola ACC-STATUS z wartością 4 COMPLETED. Komunikat został opisany w punkcie 12.2.8 ORDER-MIGRATION-TO-OPER-ACC Komunikat akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców. 8.10.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzającego realizację przez Dawcę i Macierzystego Potwierdzenie dostarczenia komunikatu pozytywnej realizacji technicznej odbywa się za pomocą standardowego ORDER-MIGRATION-TO-OPER-ACC-ACK. Komunikat został opisany w punkcie 12.2.9 ORDER-MIGRATION-TO-OPER-ACC-ACK Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców. 8.11. Potwierdzenie realizacji Zamówienia Migracji TP, po zrealizowaniu Zamówienia Migracji, potwierdza elektronicznie Biorcy, zrealizowanie zamówienia. Komunikat potwierdzenie realizacji zamówienia Migracji dla procesu powrotów z BSA/NBSA do TP należy traktować jako informacje o zrealizowanej dezaktywacji usługi BSA/NBSA. 8.11.1. Komunikat statusu wykonania zamówienia migracji W tym kroku procesu stosowany jest taki sam komunikat jak w punkcie 12.2.3 ORDER-MIGRATION-STATUS Komunikat statusu. Komunikat ten wysyłany jest do operatora Biorcy. W komunikacie przesyłany jest status COMPLETED. 8.11.2. Komunikat potwierdzenia statusu wykonania zamówienia migracji W tym kroku procesu stosowany jest taki sam komunikat jak w punkcie 12.2.5 ORDER-MIGRATION-STATUS- ACK Komunikat potwierdzenia statusu. Komunikat ten przysyłany jest przez operatora Biorcę. MWD_dla_migracji_V5 10 3- JWZ.doc 63

8.11.3. Potwierdzenie deinstalacji usługi dla Operatora Dawcy Dotyczy przypadku zakończenia procesu odłączenia usługi na wniosek Operatora Biorcy (TP). TP będzie informowała Operatora Dawcę o dezaktywacji usługi zgodnie z aktualnie obowiązującym MWD dla usługi BSA. Kanał komunikacji: e-mail Nadawca: skrzynka.funkcyjna@telekomunikacja.pl, określony w ZT Adresat: Operator.Korzystający@operator.pl, określony w ZT Tytuł maila: ADSL_[Nazwa_Operatora]_RRZUO_[ID_Lacza] Zawartość: informacja o zakończeniu procesu dezaktywacji usługi, jedno zdarzenie jeden e-mail Generowany: po każdej dezaktywacji Format e-maila: Format załącznika: brak Kanał komunikacji: FTP Nazwa pliku: ADSL_[Nazwa_Operatora]_RRZUO_[RRRRMMDDHH24MM].TXT Plik umieszcza: TP Umiejscowienie na serwerze FTP: RRRRMM_RRZUO Zawartość: zbiorczy plik z listą zrealizowanych Zamówień. Zawiera Zamówienia, które zostały zrealizowane od momentu umieszczenia poprzedniego pliku Generowany: w DR w godzinach 7:00 20:00, co godzinę, o pełnych godzinach Struktura pliku: Nazwa pola Typ Wymagane Opis ID Łącza; Char(15) Tak Data dezaktywacji usługi; Date() Tak * Powyższy schemat komunikatu będzie obowiązywał w okresie przejściowym MWD_dla_migracji_V5 10 3- JWZ.doc 64