Model Wymiany Danych - MPM

Transkrypt

Model Wymiany Danych
dla Migracji Usług Hurtowych
w ramach dostępu telekomunikacyjnego
do sieci TP
Wersja v 5.8
Status: zamrożony
Data wdrożenia: 30-10-2009
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, nie
uwzglę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 reklamcji.
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 SERVICEQUERY-RESULT w polu QUERY-STATUS
2
Wersja
Data
modyfikacji
Opis
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 HLD0 (2) w komunikacie ORDER-MIGRATIONSTATUS
5.6.3
12.01.2009
Uwzględnienie zmian biznesowych i
informatycznych.
5.6.4
14.01.2009
Uwzględnie uwag biznesowych informatycznych
5.6.5
23.01.2009
Uzupełnienie komunikatu ORDER-MIGRATIONCANCEL o pole GENERATE-DATE
5.6.6
27.03.2009
Uzupełnienie procesu skłądania 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, SPECIALVERSION-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 SERVICEQUERY zmiana zakresu godzinowego dla T0 z 816 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.8
18.09.2009
1. Dodanie rozdziału 6 Odpytanie o warunki dla
NP. Mnodyfikacja 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.
2. Modyfikacja KPI dla realizacji procesów dla
usługi NP. Dodanie kodów odrzutu dla weryfikacji
formalnej.
3. Uwzględnienie uwag do dokumentu, poprawa
KPI w opisie procesu realizacji dla Zamówień
Migracji.
3
Spis Treści
1.
Wprowadzenie ............................................................................................................................................................. 8
2.
Podstawowe dane konfiguracyjne - kanał e-mail.................................................................................................... 10
3.
2.1.
Ustawienia techniczne systemów TP i Przedsiębiorcy telekomunikacyjnego.................................................. 10
2.2.
Zasady bezpieczeństwa przesyłu danych........................................................................................................... 11
2.3.
Specyfikacja postaci wiadomości e-mail........................................................................................................... 12
Typy danych............................................................................................................................................................... 14
3.1.
Typy pól ............................................................................................................................................................. 14
3.1.1. ADDRESS....................................................................................................................................................... 14
3.1.2. LOC-ADDRESS.............................................................................................................................................. 15
3.1.3. INT-ID ............................................................................................................................................................ 15
3.1.4. ORDER-NUMBER ......................................................................................................................................... 16
3.2.
Rodzaje migracji................................................................................................................................................ 16
4.
Słownik pojęć ............................................................................................................................................................. 18
5.
Odpytanie TP przez Przedsiębiorcę telekomunikacyjnego o aktywne usługi hurtowe na danym Łączu
Abonenckim Aktywnym ........................................................................................................................................... 19
5.1.
Zapytanie o aktywne usługi hurtowe ................................................................................................................ 19
5.1.1. Komunikat zapytania o aktywne usługi na danym Łączu Abonenckim........................................................... 19
5.1.2. Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY ............................................................. 21
5.2.
Informacja o zainstalowanych usługach na aktywnym łączu abonenckim .................................................... 22
5.2.1. Komunikat odpowiedzi na zapytanie o aktywne usługi na danym Łączu Abonenckim................................... 22
5.2.2. Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY-RESULT.............................................. 25
6.
Weryfikacja wniosku abonenta dotyczącego przeniesienia przydzielonego numeru przy zmianie dostawcy
usług. ( TP realizuje komunikację pomiędzy Operatorami).................................................................................. 27
6.1.
Odpytanie o warunki NP................................................................................................................................... 27
6.1.1. Komunikat odpytania o warunki NP. ............................................................................................................. 27
6.1.2. Komunikat potwierdzenia odpytania o warunki NP. ...................................................................................... 27
6.2.
Potwierdzenie daty lub negatywna weryfikacja formalna ............................................................................... 27
6.2.1. Komunikat potwierdzenie daty lub negatywna weryfikacja formalna ............................................................ 28
6.2.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzenia daty lub negatywnej weryfikacji
formalnej........................................................................................................................................................ 28
6.3.
Odpowiedź od Dawcy i Macierzystego .............................................................................................................. 28
6.3.1. Komunikat odpowiedzi od Dawcy i Macierzystego ........................................................................................ 28
6.3.2. Komunikat potwierdzenia dostarczenia odpowiedzi od Dawcy i Macierzystego ........................................... 28
6.4.
Potwierdzenie daty realizacji lub odrzucenie ................................................................................................... 28
6.4.1. Komunikat potwierdzenie daty realizacji lub odrzucenie............................................................................... 29
6.4.2. Komunikat potwierdzenia dostarczenia potwierdzenia daty realizacji lub odrzucenie.................................. 29
7.
Migracja Usługi Abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego
Przedsiębiorcy telekomunikacyjnego (Biorca) ze zmianą Usługi Hurtowej......................................................... 30
7.1.
Schemat migracji .............................................................................................................................................. 30
7.2.
Opis kroków schematu ...................................................................................................................................... 31
7.3.
Złożenie Zamówienia Migracji ......................................................................................................................... 32
7.3.1. Proces po stronie Operatora Biorcy .............................................................................................................. 32
7.3.2. Opis kroków przesłania Zamówień Migracji.................................................................................................. 33
4
7.3.3. Opis kroków przesłania grupy odpowiedzi na Zamówienia Migracji ............................................................ 33
7.3.4. Komunikat Zamówień Migracji ...................................................................................................................... 34
7.3.5. Komunikat potwierdzenia zamówień usług migracji ...................................................................................... 41
7.4.
Negatywna weryfikacja formalna TP ............................................................................................................... 42
7.4.1. Komunikat statusu .......................................................................................................................................... 43
7.4.2. Komunikat potwierdzenia statusu................................................................................................................... 52
7.5.
Przekazanie daty rezygnacji lub daty wykonania NP do Dawców................................................................... 54
7.5.1. Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP ................................ 54
7.5.2. Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP.......... 59
7.6.
Potwierdzenia realizacji zlecenia Zamówienia lub jego odrzucenie................................................................ 60
7.6.1. Komunikat akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców ...................................... 61
7.6.2. Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców............... 65
7.7.
Potwierdzenie do Biorcy oraz Dawcy/Dawców bądź odmowa realizacji Zamówienia Migracji wraz z datą
realizacji ............................................................................................................................................................ 66
7.7.1. Komunikat - informacja o dacie realizacji Zamówienia Migracji/odmowie realizacji zamówienia Migracji 66
7.7.2. Komunikat potwierdzenia dla komunikatu informacji o dacie realizacji Zamówienia Migracji/odmowie
realizacji zamówienia Migracji ..................................................................................................................... 67
7.8.
Rezygnacja z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji .................... 67
7.8.1. Komunikat Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji .. 67
7.8.2. Komunikat potwierdzenia Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od
zamówienia Migracji ..................................................................................................................................... 69
7.9.
Potwierdzenie do Biorcy, Dawcy/ów anulowania zamówienia migracji ......................................................... 70
7.9.1. Komunikat statusu anulowania zamówienia migracji .................................................................................... 71
7.9.2. Komunikat potwierdzenia statusu anulowania zamówienia migracji............................................................. 71
7.10.
Potwierdzenie od Dawcy i Macierzystego wykonania NP................................................................................ 71
7.10.1. Komunikat potwierdzenia realizacji przez Dawcę i Macierzystego............................................................. 71
7.10.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzającego realizację przez Dawcę i
Macierzystego ................................................................................................................................................ 71
7.11.
Potwierdzenie realizacji Zamówienia Migracji ................................................................................................ 71
7.11.1. Komunikat statusu wykonania zamówienia migracji ................................................................................... 72
7.11.2. Komunikat potwierdzenia statusu wykonania zamówienia migracji............................................................ 72
7.11.3. Potwierdzenie deinstalacji usługi dla Operaotra Dawcy............................................................................. 72
8.
Migracja usługi abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego
Przedsiębiorcy telekomunikacyjnego (Biorca) bez zmiany usługi hurtowej;....................................................... 74
8.1.
8.1.1. Opis kroków przesyłania Zamówień Migracji................................................................................................ 75
8.1.2. Opis kroków przesłania odpowiedzi na Zamówienia Migracji....................................................................... 75
8.1.4. Komunikat potwierdzenia zamówień usług MIGRACJA ................................................................................ 76
8.2.
Negatywna weryfikacja formalna TP ............................................................................................................... 76
8.2.1. Komunikat Negatywnej Weryfikacji Formalnej (NWF).................................................................................. 76
8.2.2. Komunikat potwierdzenia Negatywnej Weryfikacji Formalnej ...................................................................... 76
8.3.
Przekazanie daty rezygnacji do Dawców .......................................................................................................... 76
8.3.1. Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy ...................................................................... 77
8.3.2. Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy................................................ 77
8.4.
Potwierdzenia realizacji zlecenia lub odrzucenie............................................................................................. 77
8.4.1. Komunikat akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców ...................................... 78
8.4.2. Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców............... 78
8.5.
Potwierdzenie bądź odmowa realizacji Zamówienia Migracji wraz z datą realizacji...................................... 78
5
8.5.2. Komunikat potwierdzenia dla komunikatu informacji o dacie realizacji Zamówienia Migracji/odmowie
realizacji zamówienia Migracji ..................................................................................................................... 79
8.6.
8.6.1. Komunikat Rezygnacja z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji . 80
8.7.
Potwierdzenie do Biorcy, Dawcy/ów anulowania zamówienia migracji ......................................................... 80
8.8.
8.8.1. Komunikat statusu wykonania zamówienia migracji...................................................................................... 82
8.8.2. Komunikat potwierdzenia statusu wykonania zamówienia migracji .............................................................. 82
9.
Migracja usługi abonenckiej z usługi hurtowej obecnie świadczonej na inną usługę hurtową bez zmiany
Przedsiębiorcy telekomunikacyjnego ...................................................................................................................... 83
9.1.
9.1.2. Komunikat potwierdzenia zamówień usług MIGRACJA ................................................................................ 84
9.2.
Negatywna weryfikacja formalna..................................................................................................................... 84
9.2.1. Komunikat Negatywnej Weryfikacji Formalnej (NWF).................................................................................. 85
9.2.2. Komunikat potwierdzenia Negatywnej Weryfikacji Formalnej ...................................................................... 85
9.3.
Przekazanie daty rezygnacji lub daty wykonania NP do Dawców................................................................... 85
9.3.1. Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP ................................ 85
9.3.2. Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP.......... 85
9.4.
Potwierdzenie bądź odmowa realizacji Zamówienia Migracji wraz z datą realizacji...................................... 85
9.4.2. Komunikat potwierdzenia Akceptacja/brak akceptacji daty realizacji Zamówienia Migracji ....................... 86
9.5.
9.5.1. Komunikat Rezygnacja z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji . 87
9.6.
Potwierdzenie do Biorcy anulowania zamówienia Migracji............................................................................ 87
9.7.
Potwierdzenie od Dawcy wykonania NP. ......................................................................................................... 88
9.7.1. Komunikat potwierdzenia realizacji przez Dawcę.......................................................................................... 88
9.7.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzającego realizację przez Dawcę................... 88
9.8.
9.8.1. Komunikat statusu wykonania zamówienia migracji...................................................................................... 89
9.8.2. Komunikat potwierdzenia statusu wykonania zamówienia migracji .............................................................. 89
10.
Proces zgłaszania reklamacji.................................................................................................................................... 90
10.1.
Zgłaszenie reklamacji formalnej ...................................................................................................................... 90
10.1.1. Komunikat zgłaszania reklamacji ................................................................................................................ 91
10.1.2. Komunikat potwierdzenia zgłoszenia reklamacji formalnej ........................................................................ 93
10.1.3. Komunikat odpowiedzi na zgłoszenie reklamacji formalnej ........................................................................ 94
10.1.4. Komunikat potwierdzenia odpowiedzi na zgłoszenie reklamacji formalnej................................................. 98
10.2.
Zgłoszenie reklamacji technicznej. ................................................................................................................... 99
10.2.1. Komunikat zgłoszenia reklamacji technicznej............................................................................................ 100
10.2.2. Komunikat potwierdzenia zgłoszenia reklamacji technicznej .................................................................... 100
10.2.3. Komunikat odpowiedzi na zgłoszenie reklamacji technicznej.................................................................... 100
10.2.4. Komunikat potwierdzenia odpowiedzi na zgłoszenie reklamacji technicznej ............................................ 101
6
11.
Specyfikacja komunikatów awaryjnych................................................................................................................ 102
11.1.
12.
Komunikat ABORT......................................................................................................................................... 102
Kody odrzuceń dla korelacji i przejść pomiędzy Operatorami........................................................................... 104
12.1.
Kody odrzuceń – weryfikacja informatyczna ................................................................................................. 104
12.2.
Kody weryfikacji formalnej............................................................................................................................. 104
12.3.
Kody weryfikacji formalnej Dawca- TP ......................................................................................................... 105
12.4.
Kody odpowiedzi TP do Biorcy/Dawcy dotyczące weryfikacji formalnej i technicznej................................. 105
12.5.
Kody związane z rezygnacją Abonenta otrzymaną od Dawcy/ Biorcy .......................................................... 105
13.
Kody odrzuceń dla informacji o usługach hurtowych ......................................................................................... 106
14.
Kody odrzuceń dla reklamacji ............................................................................................................................... 107
14.1.
Negatywna weryfikacja informatyczna w BNP - Kody odrzucenia reklamacji przez BNP ......................... 107
14.2.
Negatywny wynik rozpatrzenia Reklamacji - Kody odrzucenia reklamacji.................................................. 107
14.3.
Wynik rozpatrzenia reklamacji ....................................................................................................................... 107
14.4.
Przedmiot Reklamacji ..................................................................................................................................... 107
7
1. Wprowadzenie
Niniejszy dokument jest opisem Modelu Wymiany Danych (MWD) pomiędzy Telekomunikacją
Polską S.A. (dalej zwaną TP) a Przedsiębiorcą telekomunikacyjnym dla Migracji Usług Hurtowych
w ramach dostępu telekomunikacyjnego w ramach sieci TP, zgodnie z zakresem oraz
wymaganiami Decyzji UKE w formie komunikacji elektronicznej.
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ń.
Kolejność realizacji będzie określana poprzez numeracje strzałek.
Serwer
poczty e-mail
Operatora
Serwer
poczty e-mail
TP
Operator
System
TP
Migracja Usług Hurtowych w ramach dostępu telekomunikacyjnego w ramach 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 w
zakresie Modelu Przejść Międzyoperatorskich.
W ramach Oferty określającej warunki
telekomunikacyjnego następujące usługi:
Migracji,
TP
świadczy
na
rzecz
Przedsiębiorcy

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;
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

8
(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 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ą kanału komunikacyjnego, 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.
9
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.
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 od Przedsiębiorcy telekomunikacyjnego do TP, skrzynka pocztowa
TP będzie miała adres:
[email protected]
W miejsce YY należy wstawić numer z rejestru Przedsiębiorców telekomunikacyjnych nadany
przez UKE.
Wiadomości przesyłane z XXXXX do TP będą wysyłane ze skrzynki pocztowej o adresie:
[email protected]
Dla wiadomości przesyłanych z TP do Przedsiębiorcy telekomunikacyjnego, skrzynka pocztowa
xxxxx będzie miała adres:
[email protected]
Wiadomości przesyłane z TP do Przedsiębiorcy telekomunikacyjnego będą wysyłane ze skrzynki
pocztowej o adresie:
[email protected]
10
Dla wiadomości testowych przesyłanych z XXXXX do TP, skrzynka pocztowa TP będzie miała
adres:
[email protected]
Wiadomości testowe przesyłane z XXXXX do TP będą wysyłane ze skrzynki pocztowej o adresie:
[email protected]
Dla wiadomości testowych przesyłanych z TP do Przedsiębiorcy telekomunikacyjnego, skrzynka
pocztowa Operatora będzie miała adres:
[email protected]
Wiadomości testowe przesyłane z TP do XXXXX będą wysyłane ze skrzynki pocztowej o adresie:
[email protected]
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.
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 TP będzie szyfrowana kluczem publicznym PGP TP. Każda
wiadomość przesłana do Przedsiębiorcy telekomunikacyjnego będzie szyfrowana kluczem
publicznym Przedsiębiorcy telekomunikacyjnego.
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.
11
Dokładny
opis
szyfrowania
e-mail
zawarty
jest
w
dokumencie
RFC2015
(http://rfc.net/rfc2015.html). Informacje dotyczące szyfrowania PGP zawarte są w dokumencie
RFC2440 (http://rfc.net/rfc2440.html).
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
12).
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.
Formaty przesyłek oraz formaty potwierdzeń (zarówno pozytywnych jak i negatywnych) są
opisane w tym dokumencie.
Strony ustalają, że na podstawie rejestru przedsiębioró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 skrzynkę pocztową wymiany komunikatów 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ń
telekomunikacyjnego będzie następująca:
Migracji
przesłanej
od
Przedsiębiorcy
Tytuł wiadomości:
id:[99][123456]ZAMOWIENIE-MIGRACJA[xml]
Przykładowa postać potwierdzenia odbioru wiadomości zamówienia Migracji przesłanej od TP do
Przedsiębiorcy telekomunikacyjnego będzie następująca:
12
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.
13
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:
Nazwa pola
Typ
Opis
Czy
wymagany?
ADDRESS
Rekord/CH
AR(512)
CITY-NAME
CHAR(50)
Miejscowość
TAK
STREET-NAME
CHAR(50)
Ulica
NIE
BUILDING-NUMBER
CHAR(8)
Numer domu
TAK
FLAT-NUMBER
CHAR(8)
Numer lokalu
NIE
POSTAL-CODE
CHAR(6)
Kod pocztowy
TAK
POSTAL-NAME
CHAR(100) Poczta
TAK
(Uwaga! Wartości pól adresowych nie mogą zawierać przecinków)
14
Rekord
nadrzędny
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>
Pole Nr telefonu Abonenta jest wypełniane jeśli zamówienie dotyczy migracji usługi głosowej na
tym numerze.
W przypadku BSA dla zamówień dotyczących Migracji będzie podawane pole ID_usługi
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:
Nazwa pola
Typ
Opis
Czy
Rekord
wymagany nadrzę
dny
?
ADDRESS
Rekord/
CHAR(51
2)
CITY-NAME
CHAR(50) Miejscowość
TAK
STREET-NAME
CHAR(50) Ulica
TAK
PROPERTY-NUMBER CHAR(50) Numer nieruchomości
TAK
(Uwaga! Wartości pól adresowych nie mogą zawierać przecinków)
Przykład: przy kaskadzie WLR takie dane nie są wymagane, natomiast przy LLU są konieczne
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.
15
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:
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
MIGRACJA_1 z WLR na NP.
o
MIGRACJA_1 dla z WLR / WLR i BSA na LLU z NP.
o
MIGRACJA_1 dla z WLR / WLR i BSA na LLU bez NP.
o
MIGRACJA_1 z POTS/BSA na LLU współdzielone
o
MIGRACJA_1 z NBSA na LLU pełne bez NP
o
MIGRACJA_1 z NBSA na LLU współdzielone
o
MIGRACJA_1 przejście z usługi głosowej na NP
MIGRACJA_2
przejście od operatora do operatora bez zmiany usługi (kaskada BSA na
BSA, WLR na WLR, NP. na NP)

MIGRACJA_3
przejście – zmienia się zarówno operator, jak i usługa
o
MIGRACJA_3 z WLR / WLR i BSA na LLU z NP.
o
MIGRACJA_3 z WLR / WLR i BSA na LLU bez NP.
o
MIGRACJA_3 z WLR na NP
o
MIGRACJA_3 z POTS/BSA na LLU pełne z NP.
o
MIGRACJA_3 z POTS/BSA na LLU pełne bez NP.
o
MIGRACJA_3 z POTS/BSA na LLU współdzielone
o
MIGRACJA_3 z NBSA na LLU pełne bez NP
o
MIGRACJA_3 z NBSA na LLU współdzielone
o
MIGRACJA_3 z powroty z BSA do TP
16
o
MIGRACJA_3 przejście z usługi głosowej na NP
Dotychczasowa realizacji procesów MPM dla których usługa NP. jest jedną ze
składowych zamówienia LLU, będzie realizowana zgodnie z procesem dla usługi LLU.
17
4. Słownik pojęć
Biorca
CHAR(n)
Dawca
Date()
DR
Migracja
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 RRRRMM-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
MWD
NBSA
NWF
NWT
Przedsiębiorca
telekomunikacyjny
RTPrzylacze
TP
ZT
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”
18
5. Odpytanie 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>
Komunikat zapytania o aktywne usługi na danym Łączu Abonenckim.
Operator -> BNP
Komunikat przesyłany kanałem elektronicznym.
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
Identyfikacja komunikatu
TAK
INTERACTION-ID
INT-ID
Identyfikator interakcji
TAK
SUBJECT-ID
CHAR(40)
Identyfikacja nadawcy komunikatu
TAK
DEST-SUBJECT-ID
CHAR(40)
Identyfikacja odbiorcy komunikatu
TAK
TEST-VER
INT(1)
Identyfikator komunikatu testowego
0 – komunikat produkcyjny
1 – komunikat testowy
TAK
SERVICE-QUERY
Rekord
SIZE
INT(10)
Ilość zapytań w komunikacie
elektronicznym
SERVICE-OPER
CHAR(10)
Identyfikator UKE operatora, do którego
kierowane są zapytania
GENERATE-DATE
DATE
Data generacji zapytań
(RRRRMM-DD
GG:MM:SS
)
TAK
19
NIE
Brak pola
oznacza tryb
pojedynczego
zapytania
TAK
TAK
Rekord
nadrzędny
Nazwa pola
Typ
Opis
Czy
wymagany?
SERVICE-QUERYELEMENT
Rekord
ITEM
INT(12)
Numer kolejny zapytania w komunikacie
TAK
QUERY-ID
CHAR(20)
Identyfikator zapytania
TAK
NUMBER
CHAR(10)
Numer telefonu
SERVICE-ID
CHAR(12)
Identyfikator usługi
CLIENT-ADDRESS
ADDRESS
Adres lokalizacji łącza
QUERYAGREEMENT
INT(1)
PT oświadcza, że posiada zgodę Abonenta
na przetwarzania danych osobowych przez
TP na potrzeby Odpytania o aktywne usługi
świadczone na danym łączu oraz na
ujawnienie przez TP informacji objętych
tajemnicą telekomunikacyjną.
MSG
CHAR(1024 Informacje dodatkowe
)
Rekord
nadrzędny
TAK
SERVICEMoże
QUERY
występować
wielokrotnie
(ilość
rekordów
zgodna z
polem SIZE
– brak pola
SIZE
oznacza
pojedyncze
zapytanie)
TAK
Jeżeli pole
SERVICE-ID
jest puste
TAK
Jeżeli pole
NUMBER
jest puste
TAK
TAK
(wartości
dozwolone
0 - brak
zgody
1 - zgoda )
NIE
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>
<size>1</size>
<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>
<number>322251527</number>
<service-id></service-id>
<client-address>
<city-name>Kozia Wólka</city-name>
<street-name>Mickiewicza</street-name>
20
<postal-name>Kozia Wólka</postal-name>
</client-address>
<msg>Dodatkowe informacje </msg>
</service-query-element>
</service-query>
</cbnp-message>
5.1.2. Komunikat potwierdzenia przyjęcia komunikatu SERVICEQUERY
Temat wiadomości: id:[SUBJECT-ID][INTERACTION-ID]ZAPYTANIE-O-USLUGI-ACK[xml]
SERVICE-QUERY-ACK (BNP->Operator Biorca)<T_3_0>
Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY przesyłany synchronicznie.
BNP -> Operator
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
SERVICE-QUERYACK
Rekord
ACCEPTANCE
Rekord
Informacja o akceptacji
ITEM
INT(12)
Numer kolejny potwierdzenia w
komunikacie
TAK
ACC-STATUS
INT(1)
Status przyjętego komunikatu w postaci
cyfrowej:
0 – „OK”,
1 - „REJECTED”
TAK
REJECTIONREASON
INT(4)
Powód odrzucenia
MSG
CHAR(1024 Komunikat błędu
)
Rekord
nadrzędny
TAK
TAK
SERVICEMoże
QUERYwystępować
ACK
wielokrotnie
(ilość
rekordów
zgodna z
ilością
elementów
zapytania)
TAK
Jeżeli ACCSTATUS = 1
NIE
21
Nazwa pola
Typ
ACC-DATE
Opis
DATE
Data wygenerowania potwierdzenia odbioru
(RRRRMM-DD
GG:MM:SS
)
Czy
wymagany?
Rekord
nadrzędny
TAK
Przykładowy XML:
<msg-header>
</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 informacji o aktywnych usługach na danym Łączu Abonenckim.
BNP->Operator
Nazwa pola
Typ
Opis
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
22
Czy
wymagany?
Rekord
nadrzędny
Nazwa pola
Typ
Opis
SERVICE-QUERYRESULT
Rekord
SIZE
INT(10)
GENERATE-DATE
DATE
Data generacji odpowiedzi
(RRRRMM-DD
GG:MM:SS
)
Czy
wymagany?
Rekord
nadrzędny
TAK
Ilość odpowiedzi w komunikacie
elektronicznym
SERVICE-QUERY- Rekord
RESULT-ELEMENT
NIE
Brak pola
oznacza tryb
pojedynczej
odpowiedzi
TAK
TAK
SERVICEMoże
QUERYwystępować RESULT
wielokrotnie
(ilość
rekordów
zgodna z
polem SIZE
– brak pola
SIZE
oznacza
pojedynczą
odpowiedź)
ITEM
INT(12)
Numer kolejny odpowiedzi w komunikacie
TAK
QUERY-ID
CHAR(20)
Identyfikator zapytania
TAK
NUMBER
CHAR(10)
Numer telefonu
SERVICE-ID
CHAR(12)
CLIENT-ADDRESS
ADDRESS
TAK
QUERY-STATUS
INT(4)
0 – „OK.” – Zapytanie przyjęte
1 – „REJECTED” - Zapytanie odrzucone
2 – „NO-RESULT” - brak wyników
TAK
MSG
CHAR(1024 Informacje dodatkowe.
)
TAK
Jeżeli pole
SERVICE-ID
jest puste
TAK
Jeżeli pole
NUMBER
jest puste
23
NIE
Nazwa pola
Typ
Opis
Czy
wymagany?
SERVICE
Rekord
Informacja o usługach świdczonych dla
numeru
SERVICE-NAME
INT(4)
1 – „WLR” – usługa WLR (usługa głosowa)
2 – „BSA” – usługa BSA (usługa
szerokopasmowa ATM)
3 – „LLUP” – usługa LLU Pełny (usługa
głosowa i szerokopasmowa)
4 – „LLUW” - usługa LLU Współdzielony
(usługa szerokopasmowa)
5 - rezerwa - „VOICE” – usługa głosowa w
TP (usługa głosowa)
6 -„BSA – BROADBAND TP” – usługa
szerokopasmowa w TP (usługa
szerokopasmowa)
7 – „NP” – usługa zachowania numeru
8 – „NBSA” – usługa BSA w trybie Naked
(usługa szerokopasmowa ATM)
TAK
OPER
CHAR(10)
Identyfikator UKE operatora dla którego
aktualnie świadczona jest usługa wskazana
w polu SERVICE-NAME
TAK
Rekord
nadrzędny
NIE
SERVICEMoże
QUERYwystepować RESULTwielokrotnie ELEMENT
i tylko raz
dla usług
głosowych i
raz dla usług
szerokopasm
owych.
Przykładowy XML:
<msg-header>
</msg-header>
<service-query-result>
<service-query-result-element>
<item>1</item>
<query-id>SDFA123123</query>
<service-number></service-number>
<client-address>
<street-name>Koziołka Matołka</street-name>
<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>
24
</service>
<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 komunikatu SERVICEQUERY-RESULT
Temat wiadomości: id:[SUBJECT-ID][INTERACTION-ID]ODPOWIEDZ-ZAPYTANIE-O-USLUGIACK[xml]
SERVICE-QUERY-RESULT-ACK (Operator Biorca-BNP)<T_3_0>
Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY-RESULT przesyłany
synchronicznie.
Operator -> BNP
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
SERVICE-QUERYRESULT-ACK
Rekord
ACCEPTANCE
Rekord
TAK
ITEM
INT(12)
komunikacie
TAK
ACC-STATUS
INT(1)
cyfrowej:
0 – „OK”,
1 - „REJECTED”
TAK
REJECTIONREASON
INT(4)
Powód odrzucenia
MSG
CHAR(1024 Komunikat błędu
)
NIE
ACC-DATE
DATE
(RRRRMM-DD
GG:MM:SS
)
TAK
Rekord
nadrzędny
TAK
TAK
25
SERVICEQUERYRESULTACK
Przykładowy XML:
<msg-header>
</msg-header>
<service-query-result-ack>
<acceptance>
<item>1</item>
<acc-date>2008-12-22 14:00:00</acc-date>
</acceptance>
</service-query-result-ack>
</cbnp-message>
26
6. Weryfikacja wniosku abonenta dotyczącego
przeniesienia przydzielonego numeru przy zmianie
dostawcy usług. ( TP realizuje komunikację pomiędzy
Operatorami)
6.1.
Odpytanie o warunki NP.
Operator Biorca składa drogą elektroniczną za pośrednictwem systemu BNP dedykowane
zamówienie odpytania o warunki techniczne oraz datę dla realizacji przeniesienia numeru do
innego Operatora.
W zamówieniu znajduje się:
•
•
•
•
•
•
•
•
•
•
Identyfikator Zamówienia odpytania (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 – (BEGINDATE).
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 nie jest wymagany dla realizacji zamówień NP
6.1.1. Komunikat odpytania o warunki NP.
ORDER-MIGRATION z opcjonalną sekcją wskazująca że komunikat jest tylko zapytaniem
( MODE = 2). Brak tej sekcji oznacza standardowe procesowanie zamówienia MPM.
6.1.2. Komunikat potwierdzenia odpytania 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).
27
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).
Realizacja negatywnej weryfikacji odbywa się poprzez przesłanie komunikatu ORDERMIGRATION-STATUS (SERVICE-STAUS = 1 REJECTED )
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-OPERACC-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.
28
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 potwierdzenia daty realizacji lub
odrzucenie
Potwierdzenie realizowane jest przez standardowy komunikat ORDER-MIGRATIONSTATUS-ACK
29
7. Migracja Usługi Abonenckiej od Przedsiębiorcy
telekomunikacyjnego korzystającego (Dawca) do
innego Przedsiębiorcy telekomunikacyjnego
(Biorca) ze zmianą Usługi Hurtowej
7.1.
Schemat migracji
30
7.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 obowiązku
przekazania dokumentów, udostępnienie oryginału może wystąpić na rzą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. LLU 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 12. 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ł 12).
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 ciągu 6 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) TP po zrealizowaniu zamówienia NP potwierdza Biorcy realizację zamówienia (dotyczy
przypadku gdy TP nie jest stroną).
10) TP po zrealizowaniu zamówienia Migracji potwierdza Biorcy realizację zamówienia.
7.3.
Złożenie Zamówienia Migracji
7.3.1. Proces po stronie Operatora Biorcy
Abonent składa zamówienie na przejście z usług x i y na usługę Z 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.
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 zawierającego 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
32

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
Biorca ma max. 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.
7.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.
7.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.
33
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ówieniam, 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.
7.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 zamówień migracji usług hurtowych.
Operator Biorca -> BNP
Komunikat przesyłany kanałem elektronicznym,
Format xml:
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
ORDERMIGRATION
Rekord
SIZE
INT(10)
Ilość zamówień w komunikacie
elektronicznym
SERVICE-OPER
CHAR(10)
kierowane są zamówienia
GENERATE-DATE
DATE
Data generacji paczki zamówień (data
(RRRRprzesłania zamówień w formie
MM-DD
elektronicznej)
GG:MM:SS
)
TAK
34
NIE
Brak pola
oznacza tryb
pojedynczego
zamówienia
TAK
TAK
Rekord
nadrzędny
Nazwa pola
Typ
Opis
Czy
wymagany?
Rekord
nadrzędny
TAK
Może
występować
wielokrotnie
(ilość
rekordów
zgodna z
polem SIZE
– brak pola
SIZE
oznacza
pojedyncze
zamówienie)
ORDERMIGRATI
ON
ORDERMIGRATIONELEMENT
Rekord
ITEM
INT(12)
Numer kolejny zamówienia w komunikacie
TAK
ORDER-NUMBER
ORDERNUMBER
Numer zamówienia nadany przez operatora
biorcę
TAK
(sprawdzane
w ACK)
NUMBER
CHAR(10)
Numer telefonu aktualnej usługi głosowej
TAK
Jeżeli
SERVICETYPE <> 9
SERVICE-ID
CHAR(12)
TAK
Jeżeli
CEASETYPE =
2, 6, 8 lub
SERVICETYPE = 9
CLIENT-NAME
CHAR(256) Nazwa klienta, do którego należy
numer/łącze
TAK
(sprawdzane
w ACK)
CLIENT-ADDRESS
ADDRESS
TAK
(sprawdzane
w ACK)
BEGIN-DATE
DATE
(RRRRMM-DD)
Planowana data rozpoczęcia świadczenia
przez Biorcę usług na rzecz Abonenta
(jednocześnie data zakończenia świadczenia
przez operatora dawcę usług – END-DATE
= BEGIN-DATE - 1)
TAK
(sprawdzane
w ACK)
MSG
)
SERVICE-TYPE
INT(1)
MODE
NIE
Typ dostępu aktualnej usługi głosowej:
1 – POTS
2 – ISDN BRA/MSN
3 – ISDN BRA/DDI
4 – ISDN PRA
9 – Brak usługi głosowej
TAK
(sprawdzane
w ACK)
1-realizacja
2-zapytanie
TAK
Tylko w
procesie
migracji z NP
35
Nazwa pola
Typ
Opis
Czy
wymagany?
Rekord
nadrzędny
SERVICESPECIFICATION
Rekord
NIE
ORDERTylko, jeżeli MIGRATI
SERVICEONTYPE = 2, 3 ELEMENT
lub 4.
Może
występować
wielokrotnie.
NUMBER-TYPE
INT(1)
Typ zakresu dla numeru:
1 – MSN
2 – Zakres DDI
TAK
NUMBER-COUNT
INT(4)
Ilość numerów w zakresie
TAK
NUMBER-LO
CHAR(10)
Numer telefonu będący początkowym
numerem zakresu
TAK
NUMBER-HI
CHAR(10)
Numer telefonu będący końcowym
numerem zakresu (w przypadku
pojedynczych numerów pole nie jest
wymagane)
TAK
Jeżeli
NUMBERCOUNT > 1
VASSPECIFICATIONLIST
Rekord
Lista zamówionych usług VAS do
zamówienia
NIE
SERVICETylko jeżeli SPECIFIC
istnieje
ATION
sekcja
ORDER z
ORDRTYPE = 1.
Może
występować
wielokrotnie.
VAS-ACTION
INT(1)
1 – Dodaj
VAS-TYPE
INT(5)
Typ usługi VAS:
2 - Preselekcja MS Miękka
3 - Preselekcja MN Miękka
15 - Prezentacja numeru (CLIP)
16 - Blokada prezentacji numeru (CLIR)
18 - Blokada połączeń anonimowych
(ACR)
20 - Połączenie trójstronne
21 - Automatyczna blokada
22 - Blokada połączeń (według poziomów
w TP)
VAS-NAME
CHAR(128) Nazwa typu usługi VAS
VAS-VALUE
CHAR(512) Wartość parametru dla danego typu usługi
VAS
NIE
36
NIE
(VAS-TYPE
= 15 możliwe
tylko dla
SERVICETYPE = 1)
NIE
TAK gdy
VASTYPE=22
Nazwa pola
Typ
Opis
Czy
wymagany?
CEASE
Rekord
Rezygnacja z aktualnych usług
CEASE-TYPE
INT(4)
szerokopasmowa ATM)
3 – rezerwa - „LLUP” – usługa LLU Pełny
(usługa głosowa i szerokopasmowa)
4 – rezerwa - „LLUW” - usługa LLU
Współdzielony
5 - „VOICE” – usługa głosowa
6 - „BSA – BROADBAND TP” – usługa
szerokopasmowa)
TAK
DONOR-OPER
CHAR(10)
kierowana jest rezygnacja z aktualnych
umów (operator, który aktualnie posiada
umowę świadczenia usługi wskazanej w
CEASE-TYPE)
TAK
CEASE-MODE
INT(1)
Tryb rozwiązania umowy
TAK
1 – DAY- natychmiastowy (wskazany przez
Tylko w
Abonenta)
procesie
2 – EOP – na koniec umowy lojalnościowej migracji z NP
3 – END – zgodnie z regulaminem Dawcy
37
Rekord
nadrzędny
NIE
ORDERMoże
MIGRATI
występować
ONtylko 2
ELEMENT
krotnie i
tylko raz dla
usług
głosowych i
raz dla usług
szerokopasm
owych.
Nazwa pola
Typ
Opis
Czy
wymagany?
ORDER
Rekord
Zamówienie usług hurtowych
ORDER-TYPE
INT(4)
szerokopasmowa ATM)
6 – „BSA-BROADBAND TP” – powrót
BSA
ORDER-LLUSERVICE
Rekord
Zamówienie usługi LLU
PG-PPD-ADDRESS
LOCADDRESS
Lokalizacja PG / PPD
TAK
LINK-TYPE
INT(1)
Rodzaj łącza
1 - Pętla
2 – Podpętla
TAK
CORR-CABLENUMBER
INT(4)
TAK
TAK
CONTACT-TECH
CHAR(512) Dane kontaktowe służb technicznych PT
TAK
ORDER-BSASERVICE
Rekord
Zamówienie usługi BSA
CODE
CHAR(4)
Kod usługi ADSL (kodoopcja)
CORR-CABLE-PAIR INT(4)
38
Rekord
nadrzędny
NIE
ORDERMoże
MIGRATI
występować
ONtylko 2
ELEMENT
krotnie i
tylko raz dla
usług
głosowych i
raz dla usług
szerokopasm
owych.
TAK
TAK
Tylko jeżeli
ORDERTYPE = 3
lub 4
TAK
Tylko jeżeli
ORDERTYPE = 2
TAK
ORDER
ORDER
Nazwa pola
Typ
NUMBERPORTABILITY
Rekord
Opcja zachowania numeru
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 - rezerwa, „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)
TAK
Jeżeli NPTYPE = 1 lub
2 lub 3
Numer routingowy dla wymaganego
przekierowania do centrali operatora biorcy
TAK
2
ROUTING-NUMBER CHAR(6)
Opis
Czy
wymagany?
Rekord
nadrzędny
NIE
Tylko jeżeli
SERVICETYPE <> 9
ORDERMIGRATI
ONELEMENT
TAK
Przykładowy XML:
Przejście WLR->WLR
<msg-header>
</msg-header>
<order-migration>
<order-migration-element>
<item>1</item>
<order-number>000060005412312</order-number>
<client-name>Kornel Makuszyński</client-name>
<client-address>
</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>
39
</service-specification>
<cease>
<cease-type>1</cease-type>
<donor-oper>10</donor-oper>
<cease-mode>1</cease-mode>
</cease>
<cease>
</cease>
<order>
<order-type>1</order-type>
</order>
</order-migration-element>
</order-migration>
</cbnp-message>
Przejście WLR->NP
<msg-header>
</msg-header>
<order-migration>
<order-migration-element>
<item>1</item>
<client-address>
</client-address>
<begin-date>2009-01-31</begin-date>
<msg>Komunikat</msg>
<cease>
</cease>
<number-portability>
<np-type>1</np-type>
<routing-number>C3210</routing-number>
</number-portability>
</order-migration-element>
</order-migration>
</cbnp-message>
40
7.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 potwierdzenia odebrania komunikatu ORDER-MIGRATION przesyłany synchronicznie.
BNP -> Operator Birca
Format xml:
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
ORDERMIGRATION-ACK
Rekord
ACCEPTANCE
Rekord
ITEM
INT(10)
Numer kolejny potwierdzenia zamówienia
w komunikacie
TAK
ORDER-NUMBER
ORDERNUMBER
biorcę
TAK
ACC-STATUS
INT(1)
cyfrowej:
0 – „OK”,
1 - „REJECTED”
TAK
RECEIVE-DATE
DATE
Data przyjęcie zamówienia
(RRRR-MMDD
GG:MM:SS)
TAK
REJECTIONREASON
INT(4)
TAK
Jeżeli
ACCSTATUS = 1
MSG
CHAR(1024) Komunikat błędu
NIE
ACC-DATE
DATE
(RRRR-MMDD
GG:MM:SS)
TAK
Rekord
nadrzędny
TAK
Powód odrzucenia
41
TAK
Może
występować
wielokrotnie
(ilość
rekordów
zgodna z
ilością
elementów
zamówień)
ORDERMIGRATI
ON-ACK
Nazwa pola
Typ
Opis
Czy
wymagany?
Rekord
nadrzędny
ACCEPTA
NCE
REJECTIONREASONELEMENT
Rekord
Dodatkowe powody odrzucenia - Może
występować wielokrotnie
NIE
REJECTIONREASON
INT(4)
Powód odrzucenia
TAK
MSG
CHAR(1024) Komunikat powodu odrzucenia
NIE
Przykładowy XML:
Odrzucenie komunikatu zamówienia
<msg-header>
</msg-header>
<order-migration-ack>
<acceptance>
<item>1</item>
<rejection-reason>987</rejection-reason>
<msg>Komunikat 987</msg>
<acc-date>2008-12-22 14:00:00</acc-date>
<rejection-reason-element>
</rejection-reason-element>
</acceptance>
</order-migration-ack>
</cbnp-message>
Przyjęcie komunikatu zamówienia
<msg-header>
</msg-header>
<order-migration-ack>
<acceptance>
<item>1</item>
<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>
7.4.
Negatywna weryfikacja formalna TP
42
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ł 12).
Nie ma możliwości poprawiania zamówienia, w tym przypadku Przedsiębiorca telekomunikacyjny
(biorca) składa nowe Zamówienie Migracji/NP.
7.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 zgłoszenia statusu zamówienia migracji usług hurtowych.
BNP -> Operator
Komunikat jest dostępny dla Operatora poprzez kanał elektroniczny.
Format xml:
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
NIE
ORDERMIGRATIONSTATUS
Rekord
SIZE
INT(10)
Ilość statusów w paczce
OPER
CHAR(10)
Identyfikator UKE, do którego kierowane są
statusy w paczce
TAK
43
NIE
Brak pola
oznacza tryb
pojedynczej
odpowiedzi
TAK
Rekord
nadrzędny
Nazwa pola
GENERATE-DATE
Typ
Opis
DATE
Data generacji paczki statusów
(RRRR-MMDD
GG:MM:SS)
ORDERRekord
MIGRATIONSTATUS-ELEMENT
Czy
wymagany?
Rekord
nadrzędny
TAK
TAK
ORDERMoże
MIGRATI
występować
ONwielokrotnie. STATUS
ITEM
INT(10)
Numer kolejny statusu w komunikacie
TAK
SERVICE-NUMBER
CHAR(40)
dostawcę (TP)
TAK
ORDER-NUMBER
ORDERNUMBER
biorcę
TAK
NUMBER
CHAR(10)
Numer telefonu dla zamówienia
SERVICE-ID
CHAR(12)
Identyfikator usługi;
W przypadku potwierdzenia realizacji
zamówienia Migracji na LLU jest to
Identyfikator usługi LLU
CLIENT-NAME
CHAR(256)
Nazwa klienta, do którego należy
numer/łącze
TAK
CLIENT-ADDRESS
ADDRESS
TAK
SERVICE-STATUS
INT(4)
Kod statusu realizacji zamówienia
0 – „OK” – Przyjęte (Potwierdzona data
migracji)
1 – „REJECTED” – Odrzucone (Negatywna
weryfikacja formalna lub negatywne
warunki techniczne lub odrzucona
rezygnacja)
4 – „COMPLETED” - Zakończono
(Pozytywna realizacja techniczna)
8 – „CANCEL” – Anulowane (Anulowanie
przez klienta)
9 – „UNFEASIBLE” – Anulowanie
(Negatywna realizacja techniczna)
11 – „CONFIRMED-CEASE” –
Potwierdzenie rezygnacji (Potwierdzona
data rezygnacji)
13 – „CONFIRMED-REDIRECT” –
Potwierdzenie przekierowania
(Potwierdzona data przekierowania numeru
na nowy RN)
TAK
44
TAK
Jeżeli
SERVICETYPE <> 9
TAK
Jeżeli
CEASETYPE =
2, 6, 8 lub
SERVICETYPE = 9 lub
(ORDERTYPE = 2,3,4
i SERVICESTATUS = 4)
Nazwa pola
Typ
Opis
Czy
wymagany?
IMPLEMENTATION- DATE
Data realizacji
DATE
(RRRR-MM- (dla SERVICE-STATUS = „OK” –
DD)
Potwierdzona data rozpoczęcia świadczenia
usług – BEGIN-DATE)
(dla SERVICE-STATUS = „CONFIRMCEASE” – Potwierdzona data zakończenia
świadczenia usług – END-DATE)
(dla SERVICE-STATUS = „CONFIRMEDREDIRECT” – Potwierdzona data
przekierowania – BEGIN-DATE)
TAK
Jeżeli
SERVICESTATUS =
0,11,13
REJECTIONREASON
INT(4)
TAK
Jeżeli
SERVICESTATUS =
1,8.9
MSG
CHAR(1024) Komunikat
NIE
STATUS-DATE
DATE
Data zmiany statusu
(RRRR-MMDD
GG:MM:SS)
TAK
SERVICE-TYPE
INT(1)
Typ dostępu usługi głosowej:
1 – POTS
2 – ISDN BRA/MSN
3 – ISDN BRA/DDI
4 – ISDN PRA
TAK
MODE
INT(1)
1-realizacja
2-zapytanie
Powód odrzucenia
TAK
Tylko w
procesie
migracji z NP
45
Rekord
nadrzędny
Nazwa pola
Typ
Opis
CEASE
Rekord
Rezygnacja z aktualnych usług
CEASE-TYPE
INT(4)
szerokopasmowa ATM)
Współdzielony
5 – „VOICE” – usługa głosowa
6 – „BROADBAND TP” – usługa
szerokopasmowa)
ORDER
Rekord
Specyfikacja zamówionych usług
hurtowych
ORDER-TYPE
INT(4)
szerokopasmowa ATM)
6 – „BSA-BROADBAND TP” – powrót
BSA
NUMBERPORTABILITY
Rekord
Opcja zachowania numeru
46
Czy
wymagany?
Rekord
nadrzędny
NIE
Może
występować
tylko 2
krotnie i
tylko raz dla
usług
głosowych i
raz dla usług
szerokopasm
owych.
ORDERMIGRATI
ONSTATUSELEMENT
TAK
NIE
Może
występować
tylko 2
krotnie i
tylko raz dla
usług
głosowych i
raz dla usług
szerokopasm
owych.
ORDERMIGRATI
ONSTATUSELEMENT
TAK
NIE
Tylko jeżeli
SERVICETYPE <> 9
ORDERMIGRATI
ONSTATUSELEMENT
Nazwa pola
Typ
Opis
Czy
wymagany?
2 - „MOBILITY” – zgłoszenie
przeniesienia numeru wewnątrz operatora
4 - rezerwa „CANCEL” – zgłoszenie
anulacji przeniesienia (należy przywrócić
poprzedni RN)
TAK
NP-TYPE
INT(4)
Rekord
NUMBER-TYPE
INT(1)
1 – MSN
2 – Zakres DDI
TAK
Jeżeli
SERVICETYPE = 2,3,4
i SERVICESTATUS=0,
4, 11, 13
NUMBER-COUNT
INT(4)
TAK
Jeżeli
SERVICETYPE = 2,3,4
i SERVICESTATUS=0,
4, 11, 13
NUMBER-LO
CHAR(10)
numerem zakresu
TAK
Jeżeli
SERVICETYPE = 2,3,4
i SERVICESTATUS=0,
4, 11, 13
NUMBER-HI
CHAR(10)
wymagane)
TAK
Jeżeli
NUMBERCOUNT > 1
PRODUCT-ID
CHAR(40)
„WLR” – usługa WLR (usługa głosowa)
„BSA” – usługa BSA (usługa
szerokopasmowa ATM)
„LLUP” – usługa LLU Pełny (usługa
„LLUW” - usługa LLU Współdzielony
„VOICE” – usługa głosowa w TP (usługa
głosowa)
„BROADBAND TP” – usługa
szerokopasmowa)
"NP" - przenośność numerów
„NBSA” – usługa BSA w trybie Naked
TAK
Jeżeli
SERVICESTATUS =
4 , Może
występować
dla ORDERTYPE = 1, 3,
4
Rekord
nadrzędny
NIE
ORDERMoże
MIGRATI
występować
ONwielokrotnie. STATUSELEMENT
47
Nazwa pola
Typ
Opis
Czy
wymagany?
LINE-ATTR
Rekord
ATTR-ID
CHAR(40)
Identyfikator atrybutu
TAK
ATTR-NAME
CHAR(254)
Nazwa atrybutu
NIE
ATTR-VALUE
CHAR(512)
Wartość atrybutu
NIE
OLD-ATTR-VALUE
CHAR(512)
rezerwa
NIE
REJECTIONREASONELEMENT
Rekord
Powody odrzucenia - Może występować
wielokrotnie
REJECTIONREASON
INT(4)
Powód odrzucenia
MSG
REJECTEDSERVICE
INT(4)
REJECTING-PARTY CHAR(10)
Rekord
nadrzędny
TAK, jeżeli SERVICEokreślono SPECIFIC
PRODUCT- ATION
ID
Może
występować
wielokrotnie
NIE
Tylko jeżeli
SERVICESTATUS =
1,8,9
ORDERMIGRATI
ONSTATUSELEMENT
TAK
NIE
szerokopasmowa ATM)
Współdzielony
5 – „VOICE” – usługa
6 „BROADBAND TP” – usługa
szerokopasmowa w TP
7 – "NP" - przenośność numerów
TAK, jeżeli
SERVICESTATUS =
1
rezerwa
NIE
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 to powinny być zignorowane.
PRODUCTID
ATTR-ID
ATTR-NAME
ATTR-VALUE
Czy wymagany
ATTR-ID dla
podanego
PRODUCT-ID?
WLR
VAS01
Plan taryfowy WLR
NIE
WLR
VAS02
Preselekcja MS Miękka
[cyfry preselekcji]
NIE
WLR
VAS03
Preselekcja MN Miękka
[cyfry preselekcji]
NIE
WLR
VAS04
Blokada 1033
NIE
48
PRODUCTID
ATTR-ID
ATTR-NAME
ATTR-VALUE
Czy wymagany
ATTR-ID dla
podanego
PRODUCT-ID?
WLR
VAS05
------rezerwa------
NIE
WLR
VAS06
Połączenia oczekujące
NIE
WLR
VAS07
Budzenie
NIE
WLR
VAS08
Podadresowanie (SUB)
NIE
WLR
VAS09
Zawieszenie połączenia
(HOLD)
NIE
WLR
VAS10
Przenośność terminala
NIE
WLR
VAS11
Wiadomości tekstowe
(UUS1)
NIE
WLR
VAS12
Blokady prezentacji
numeru abonenta
dołączonego (COLR )
NIE
WLR
VAS13
Identyfikacja połączeń
złośliwych (MCID)
NIE
WLR
VAS14
Blokady przekierowanych
połączeń
NIE
WLR
VAS15
Prezentacja numeru
(CLIP)
NIE
WLR
VAS16
Blokada prezentacji
numeru (CLIR)
NIE
WLR
VAS17
Blokada prezentacji
numeru dla jednego
połączenia
NIE
WLR
VAS18
Blokada połączeń
anonimowych (ACR)
NIE
WLR
VAS19
Automatyczne połączenie
NIE
WLR
VAS20
Połączenie trójstronne
NIE
WLR
VAS21
Automatyczna blokada
NIE
WLR
VAS22
Blokada połączeń (według
poziomów w TP)
WLR
VAS23
Prezentacja numeru
abonenta dołączonego
(COLP)
NIE
WLR
VAS24
Przekierowanie połączeń
bezwarunkowe
NIE
WLR
VAS25
w przypadku zajętości
NIE
WLR
VAS26
w przypadku nieobecności
NIE
WLR
RADIO-LINK
Usługa głosowa
realizowana na łączu
radiowym
NIE
WLR
HOMOLOGATION
Informacja o homologacji
na urządzenia radiowe
[treść komunikatu]
NIE
LLUP
CABLE-LENGTH
Łączna długość trasy
miedzianej (km);
[długość w km do trzech
miejsc po przecinku]
NIE
LLUP
MAIN-CBL-LENGTH
Część magistralna długość (km);
TAK
49
W01..W11
NIE
PRODUCTID
ATTR-ID
ATTR-NAME
ATTR-VALUE
Czy wymagany
ATTR-ID dla
podanego
PRODUCT-ID?
LLUP
MAIN-CBL-DIAM
Część magistralna średnica (mm);
[średnica w mm - zawiera
wyłącznie cyfry]
TAK
LLUP
DISTR-CBLLENGTH
Część rozdzielcza długość (km);
TAK
LLUP
DISTR-CBL-DIAM
Część rozdzielcza średnica (mm);
wyłącznie cyfry]
TAK
LLUP
SUBSC-LEAD-INLENGTH
Część abonencka długość (km);
NIE
LLUP
SUBSC-LEAD-INDIAM
Część abonencka średnica (mm);
wyłącznie cyfry]
NIE
LLUW
CABLE-LENGTH
Łączna długość trasy
miedzianej (km);
TAK
LLUW
MAIN-CBL-LENGTH
Część magistralna długość (km);
TAK
LLUW
MAIN-CBL-DIAM
Część magistralna średnica (mm);
wyłącznie cyfry]
TAK
LLUW
DISTR-CBLLENGTH
Część rozdzielcza długość (km);
TAK
LLUW
DISTR-CBL-DIAM
Część rozdzielcza średnica (mm);
wyłącznie cyfry]
TAK
LLUW
SUBSC-LEAD-INLENGTH
Część abonencka długość (km);
NIE
LLUW
SUBSC-LEAD-INDIAM
Część abonencka średnica (mm);
wyłącznie cyfry]
NIE
BSA
VP
Wiązka kanałów
ścieżka VP
TAK
BSA
VC
Kanał identyfikujący
abonenta
korzystającego z usługi
Szerokopasmowej
ADSL
kanał VC
TAK
BSA
VP2PDU
Wirtualna ścieżka na
PDU Operatora
TAK
BSA
ID_ATM
ID interfejsu ATM
TAK
NBSA
VP
Wiązka kanałów
ścieżka VP
TAK
NBSA
VC
Kanał identyfikujący
abonenta
korzystającego z usługi
Szerokopasmowej
ADSL
kanał VC
TAK
NBSA
VP2PDU
Wirtualna ścieżka na
PDU Operatora
TAK
NBSA
ID_ATM
ID interfejsu ATM
TAK
Przykładowy XML:
Status potwierdzenia daty migracji
50
<msg-header>
</msg-header>
<order-migration-status>
<oper>6</oper>
<order-migration-status-element>
<item>1</item>
<service-number>0002788362</service-number>
<client-address>
</client-address>
<service-status>1</service-status>
<implementation-date></implementation-date>
<status-date>2008-12-23</status-date>
<product-id>WLR</product-id>
<line-attr>
<attr-id>VAS01</attr-id>
<attr-name>Plan taryfowy WLR</attr-name>
<attr-value></attr-value>
</line-attr>
<line-attr>
<attr-name>Preselekcja MS Miękka</attr-name>
<attr-value>1055</attr-value>
</line-attr>
<line-attr>
<attr-name>Preselekcja MN Miękka</attr-name>
<attr-value>1055</attr-value>
</line-attr>
<line-attr>
<attr-name>Blokada 1033</attr-name>
<attr-value></attr-value>
</line-attr>
<line-attr>
<attr-name>Połączenia oczekujące</attr-name>
</line-attr>
<line-attr>
<attr-name>Budzenie</attr-name>
</line-attr>
<line-attr>
<attr-name>Podadresowanie (SUB)</attr-name>
</line-attr>
51
<line-attr>
<attr-name>Zawieszenie połączenia (HOLD)</attr-name>
</line-attr>
<line-attr>
<attr-name>Przenośność terminala </attr-name>
</line-attr>
<line-attr>
<attr-name>Wiadomości tekstowe (UUS1)</attr-name>
</line-attr>
<line-attr>
<attr-name>Prezentacja numeru (CLIP)</attr-name>
</line-attr>
<line-attr>
<attr-name>Blokada połączeń (według poziomów w TP)</attr-name>
<attr-value>W02</attr-value>
</line-attr>
<line-attr>
<attr-name>Przekierowanie połączeń bezwarunkowe</attr-name>
</line-attr>
<line-attr>
<attr-name>Przekierowanie połączeń w przypadku zajętości</attr-name>
</line-attr>
<line-attr>
<attr-name>Przekierowanie połączeń w przypadku nieobecności</attr-name>
</line-attr>
<line-attr>
<attr-id>RADIO-LINK</attr-id>
<attr-name>Usługa głosowa realizowana na łączu radiowym</attr-name>
</line-attr>
<line-attr>
<attr-id>HOMOLOGATION</attr-id>
<attr-name>Informacja o homologacji na urządzenia radiowe</attr-name>
<attr-value>Przewidywane jest zakończenie świadczenia usługi realizowanej
na łączu radiowym, spowodowane Decyzją Prezesa UKE o wygaśnięciu
homologacji na eksploatację systemu. Informacja o zakończeniu świadczenia
usługi zostanie przesłana odrębnym komunikatem z miesięcznym
wyprzedzeniem.</attr-value>
</line-attr>
<rejection-reason-element>
<rejected-service>1</rejected-service>
</rejection-reason-element>
</order-migration-status-element>
</order-migration-status>
</cbnp-message>
Powyższy przykład zawiera szereg tagów nadmiarowych, które w rzeczywistym komunikacie
nigdy razem nie wystąpią (np. status negatywny i sekcja service-line), a zostały użyte w
przykładzie wyłącznie w celu zobrazowania sposobu ich użycia.
7.4.2. Komunikat potwierdzenia statusu
Temat wiadomości: id:[SUBJECT-ID][INTERACTION-ID]STATUS-MIGRACJA-ACK[xml]
ORDER-MIGRATION-STATUS-ACK (Operator->BNP)<Brak>
52
Komunikat potwierdzenia przyjęcia komunikatu ORDER-MIGRATION-STATUS przesyłany
synchronicznie.
Operator -> BNP
Komunikat wprowadzany przez kanał elektroniczny
Format xml:
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
ORDERMIGRATIONSTATUS-ACK
Rekord
ACCEPTANCE
Rekord
TAK
ITEM
INT(12)
komunikacie
TAK
ACC-STATUS
INT(1)
cyfrowej:
0 – „OK”,
1 - „REJECTED”
TAK
REJECTIONREASON
INT(4)
Powód odrzucenia
MSG
NIE
ACC-DATE
DATE
(RRRR-MMDD
GG:MM:SS)
TAK
Rekord
nadrzędny
TAK
ORDERMIGRATI
ONSTATUSACK
TAK gdy
ACCSTATUS=
„REJECTED”
Przykładowy XML:
<msg-header>
</msg-header>
<order-migration-status-ack>
<acceptance>
<item>1</item>
53
<acc-date>2008-12-22 14:00:00</acc-date>
</acceptance>
</order-migration-status-ack>
</cbnp-message>
7.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
7.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 zgłoszeń rezygnacji do operatora dawcy lub przekierowania do operatora
macierzystego.
BNP -> Operator Dawca
Format xml:
Nazwa pola
Typ
Opis
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
54
Czy
wymagany?
Rekord
nadrzędny
Nazwa pola
Typ
Opis
Czy
wymagany?
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
NIE
ORDERMIGRATION-TOOPER
Rekord
SIZE
INT(10)
Ilość zleceń w paczce
DONOR-OPER
CHAR(10)
kierowane są zamówienia rezygnacji w
paczce
GENERATE-DATE
DATE
(RRRRMM-DD
GG:MM:SS
)
ORDERMIGRATION-TOOPER-ELEMENT
Rekord
ITEM
INT(10)
Numer kolejny zlecenia w komunikacie
TAK
SERVICE-NUMBER
CHAR(40)
dostawcy (TP)
TAK
ORDER-NUMBER
ORDERNUMBER
biorcę
TAK
NUMBER
CHAR(10)
TAK
Jeżeli
SERVICETYPE <> 9
SERVICE-ID
CHAR(12)
TAK
Jeżeli
CEASETYPE =
2, 6, 8 lub
SERVICETYPE = 9
CLIENT-NAME
CHAR(256) Nazwa klienta, do którego należy
numer/łącze
TAK
CLIENT-ADDRESS
ADDRESS
TAK
SERVICE-STATUS
INT(4)
Kod zgłoszenia
10 – „CEASE” – Rezygnacja z usługi
(Zgłoszenie rezygnacji z usługi)
12 – „REDIRECT” – Przekierowanie
(Zgłoszenie potrzeby przekierowania
numeru na nowy RN)
TAK
Rekord
nadrzędny
TAK
NIE
Brak pola
oznacza tryb
pojedynczej
odpowiedzi
TAK
TAK
TAK
ORDERMoże
MIGRATI
występować
ON-TOwielokrotnie.
OPER
55
Nazwa pola
Typ
DATE
(RRRRMM-DD)
Opis
Data realizacji
(dla SERVICE-STATUS = „CEASE” –
Planowana data zakończenia świadczenia
usług – END-DATE)
(dla SERVICE-STATUS = „REDIRECT”
– Wymagana data gotowości
przekierowania – BEGIN-DATE)
Czy
wymagany?
Rekord
nadrzędny
TAK
MSG
)
NIE
SERVICE-TYPE
INT(1)
1 – POTS
2 – ISDN BRA/MSN
3 – ISDN BRA/DDI
4 – ISDN PRA
TAK
MODE
INT(1)
1-realizacja
2-zapytanie
Rekord
NUMBER-TYPE
INT(1)
1 – MSN
2 – Zakres DDI
TAK
NUMBER-COUNT
INT(4)
TAK
NUMBER-LO
CHAR(10)
numerem zakresu
TAK
NUMBER-HI
CHAR(10)
wymagane)
TAK
Jeżeli
NUMBERCOUNT > 1
TAK
Tylko w
procesie
migracji z NP
NIE
ORDERTylko, jeżeli MIGRATI
SERVICEON-TOTYPE = 2, 3
OPERlub 4.
ELEMENT
Może
występować
wielokrotnie.
56
Nazwa pola
Typ
Opis
Czy
wymagany?
CEASE
Rekord
Rezygnacja z aktualnych umów
CEASE-TYPE
INT(4)
szerokopasmowa ATM)
TAK
RECIPIENT-OPER
CHAR(10)
Identyfikator UKE operatora, od którego
kierowane są rezygnacje z aktualnych
umów (operator, który zgłasza zamówienie
migracji)
TAK
CEASE-MODE
INT(1)
Tryb rozwiązania umowy
TAK
1 – DAY- natychmiastowy (wskazany
Tylko w
przez Abonenta)
procesie
2 – EOP – na koniec umowy lojalnościowej migracji z NP
3 – END – zgodnie z regulaminem Dawcy
NUMBERPORTABILITY
Rekord
Zgłoszenie przekierowania numeru
NP-TYPE
INT(4)
2 „MOBILITY” – zgłoszenie przeniesienia
numeru wewnątrz operatora
4 – rezerwa „CANCEL” – zgłoszenie
anulacja przeniesienia (należy przywrócić
poprzedni RN)
TAK
DONOR-OPER
CHAR(10)
Identyfikator UKE operatora, który oddaje
numer (operator, który aktualnie posiada
przenoszony numer)
TAK
2 lub 3
RECIPIENT-OPER
CHAR(10)
Identyfikator UKE operatora, który
przejmuje numer (operator, do którego
należy wykonywać przekierowanie)
TAK
2
57
Rekord
nadrzędny
TAK
ORDERTylko jeżeli MIGRATI
SERVICEON-TOSTATUS =
OPER10.
ELEMENT
Może
wystepować
tylko 2
krotnie i
tylko raz dla
usług
głosowych i
raz dla usług
szerokopasm
owych.
TAK
Tylko jeżeli
SERVICESTATUS =
12
ORDERMIGRATI
ON-TOOPERELEMENT
Nazwa pola
Typ
ROUTING-NUMBER CHAR(6)
Opis
Czy
wymagany?
Numer routingowy dla wymaganego
przekierowania do centrali operatora biorcy
TAK
Jeżeli NPTYPE = 1, 2
lub 4
Rekord
nadrzędny
Przykładowy XML:
Zgłoszenie rezygnacji z umowy WLR
<msg-header>
</msg-header>
<order-migration-to-oper>
<order-migration-to-oper-element>
<item>1</item>
<client-address>
</client-address>
<implementation-date>2009-01-31</implementation-date>
<cease>
<recipient-oper>6</recipient-oper>
</cease>
</order-migration-to-oper-element>
</order-migration-to-oper>
</cbnp-message>
Zgłoszenie przekierowania numeru do operatora macierzystego
<msg-header>
58
</msg-header>
<order-migration-to-oper>
<order-migration-to-oper-element>
<item>1</item>
service-id></service-id>
<client-address>
</client-address>
<number-portability>
<np-type>1</np-type>
<recipent-oper>6</recipent-oper>
<routing-number>C3228</number-portability>
</number-portability>
</order-migration-to-oper-element>
</order-migration-to-oper>
</cbnp-message>
7.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 potwierdzenia przyjęcia komunikatu ORDER-MIGRATION-TO-OPER przesyłany
synchronicznie.
Operator Dawca -> BNP
Komunikat wprowadzany przez kanał elektroniczny
Format xml:.
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
59
Rekord
nadrzędny
Nazwa pola
Typ
Opis
Czy
wymagany?
ORDERMIGRATION-TOOPER-ACK
Rekord
ACCEPTANCE
Rekord
TAK
ITEM
INT(12)
komunikacie
TAK
ACC-STATUS
INT(1)
cyfrowej:
0 – „OK”,
1 - „REJECTED”
TAK
REJECTIONREASON
INT(4)
Powód odrzucenia
MSG
NIE
ACC-DATE
DATE
(RRRR-MMDD
GG:MM:SS)
TAK
Rekord
nadrzędny
TAK
ORDERMIGRATI
ON-TOOPERACK
TAK
Przykładowy XML:
<msg-header>
</msg-header>
<order-migration-to-oper-ack>
<acceptance>
<item>1</item>
<acc-date>2008-12-22 14:00:00</acc-date>
</acceptance>
</order-migration-to-oper-ack>
</cbnp-message>
7.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,
60
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
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łyneł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ą)".
7.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 akceptacji rezygnacji lub odrzucenia zlecenia migracji przez operatora dawcę
Operator Dawca -> BNP
Komunikat przesyłany kanałem elektronicznym
Format xml:
61
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
ORDERMIGRATION-TOOPER-ACC
Rekord
SIZE
INT(10)
Ilość odpowiedzi w komunikacie
elektronicznym
SERVICE-OPER
CHAR(10)
kierowana jest akceptacja
GENERATE-DATE
DATE
(RRRR-MMDD
GG:MM:SS)
TAK
ORDERMIGRATION-TOOPER-ACCELEMENT
Rekord
TAK
ITEM
INT(10)
TAK
SERVICE-NUMBER
CHAR(40)
dostawcę (TP)
TAK
ORDER-NUMBER
ORDERNUMBER
biorcę
TAK
NUMBER
CHAR(10)
TAK
Jeżeli
SERVICETYPE <> 9
SERVICE-ID
CHAR(12)
TAK
Jeżeli
CEASETYPE =
2, 6, 8 lub
SERVICETYPE = 9
SERVICE-STATUS
INT(4)
Kod zgłoszenia
10 – „CEASE” – Rezygnacja z usługi
(Zgłoszenie rezygnacji z usługi)
12 – „REDIRECT” – Przekierowanie
(Zgłoszenie potrzeby przekierowania
numeru na nowy RN)
TAK
62
NIE
Brak pola
oznacza tryb
pojedynczej
odpowiedzi
TAK
TAK
Rekord
nadrzędny
Nazwa pola
ACC-STATUS
Typ
INT(1)
Opis
Akceptacja przesłanego zgłoszenia:
0 – „OK” - Akceptacja
1 - „REJECTED”- Odrzucenie
2 - „CHANGE” – Akceptacja ze zmianą
daty
4 – „COMPLETED” pozytywna realizacja
Czy
wymagany?
TAK,
Zmiana daty
dla NP.
niemożliwa
dla
natychmiasto
wego trybu
rozwiązania
umowy.
Data realizacji
DATE
(RRRR-MM- (dla SERVICE-STATUS = „CEASE” i
DD)
ACC-STATUS=”OK” – Potwierdzona data
zakończenia świadczenia usług – ENDDATE,
dla SERVICE-STATUS = „CEASE” i
ACC-STATUS=”CHANGE” – nowa data
zakończenia świadczenia usług – ENDDATE)
TAK
Jeżeli
SERVICESTATUS =
10
i
ACCSTATUS = 0,
2
REJECTIONREASON
INT(4)
TAK
Jeżeli
ACCSTATUS = 1
MSG
Powód odrzucenia
Rekord
nadrzędny
NIE
ACC-STATUS-DATE DATE
Data akceptacji
(RRRR-MMDD)
TAK
SERVICE-TYPE
INT(1)
1 – POTS
2 – ISDN BRA/MSN
3 – ISDN BRA/DDI
4 – ISDN PRA
TAK
TYPE
INT(1)
1 - realizacja
2 - zapytanie
TAK
Tylko w
procesie
migracji z NP
Przykładowy XML:
Status akceptacji zgłoszenia rezygnacji z umowy
<msg-header>
</msg-header>
<order-migration-to-oper-acc>
<order-migration-to-oper-acc-element>
63
<item>1</item>
<rejection-reason></rejection-reason>
<msg></msg>
<acc-status-date>2008-12-22</status-date>
</order-migration-to-oper-acc-element>
</order-migration-to-oper-acc>
</cbnp-message>
Status odrzucenia zgłoszenia przekierowania numeru od operatora macierzystego
<msg-header>
</msg-header>
<item>1</item>
<implementation-date></implementation-date>
<msg>Brak mozliwosci realizacji routingu, brak punktu styku z operatorem</msg>
</cbnp-message>
Status akceptacji zgłoszenia rezygnacji z umowy ze zmianą daty
<msg-header>
</msg-header>
<item>1</item>
64
</cbnp-message>
7.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 potwierdzenia przyjęcia komunikatu ORDER-MIGRATION-TO-OPER-ACC
BNP -> Operator Dawca
Format xml:
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
ORDERMIGRATION-TOOPER-ACC-ACK
Rekord
ACCEPTANCE
Rekord
TAK
ITEM
INT(12)
komunikacie
TAK
ACC-STATUS
INT(1)
cyfrowej:
0 – „OK”,
1 - „REJECTED”
TAK
REJECTIONREASON
INT(4)
Powód odrzucenia
MSG
NIE
ACC-DATE
DATE
(RRRR-MMDD
GG:MM:SS)
TAK
Rekord
nadrzędny
TAK
TAK
Przykładowy XML:
65
ORDERMIGRATI
ON-TOOPERACC-ACK
<msg-header>
</msg-header>
<order-migration-to-oper-acc-ack>
<acceptance>
<item>1</item>
<acc-date>2008-12-22 14:00:00</acc-date>
</acceptance>
</order-migration-to-oper-acc-ack>
</cbnp-message>
7.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ślednikmiem 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ł 12)
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.
Komunikat z ostateczną datą realizacji może zostać wysłany w wyniku pozytywnego rozpatrzenia
reklamacji dotyczącej negatywnego wyniku WT dla zamówień Migracji. Nie dotyczy zamówień NP.
Komunikat ten może być poprzedzony wcześniejszym komunikatem NWT
7.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 „7.4.1 Komunikat statusu ” czyli ORDER-MIGRATION-
66
STATUS. 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 „7.5.1 Komunikat zgłoszenia Rezygnacji z usług
u operatora Dawcy” czyli ORDER-MIGRATION-TO-OPER z wypełnioną sekcją NUMBERPORTABILITY i typem przeniesienia ustawionym na CANCEL.
7.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 „7.4.2 Komunikat
potwierdzenia statusu” czyli ORDER-MIGRATION-STATUS-ACK. 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 „7.5.2 Komunikat potwierdzenia zgłoszenia
rezygnacji z usług u operatora Dawcy” czyli ORDER-MIGRATION-TO-OPER-ACK.
7.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.
7.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 anulowania migracji do operatora dostawcy (TP).
Operator -> BNP
67
Format xml:
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
ORDERMIGRATIONCANCEL
Rekord
SERVICE-OPER
CHAR(10)
GENERATE-DATE
DATE
Data generacji komunikatu rezygnacji z
(RRRR-MM- zamówienia migracji
DD
GG:MM:SS)
TAK
SERVICE-NUMBER
CHAR(40)
dostawcę (TP)
TAK
ORDER-NUMBER
CHAR(40)
biorcę
TAK
NUMBER
CHAR(10)
TAK
Jeżeli
SERVICETYPE <> 9
SERVICE-ID
CHAR(12)
TAK
Jeżeli
CEASETYPE =
2, 6, 8 lub
SERVICETYPE = 9
REJECTIONREASON
INT(4)
Powód anulacji
TAK
MSG
NIE
SERVICE-TYPE
INT(1)
TAK
Rekord
nadrzędny
TAK
kierowana jest anulacja
1 – POTS
2 – ISDN BRA/MSN
3 – ISDN BRA/DDI
4 – ISDN PRA
TAK
Przykładowy XML:
Zgłoszenie anulowania migracji
<msg-header>
68
</msg-header>
<order-migration-cancel>
<msg>Anulowanie z powodu rezygnacji klienta</msg>
</order-migration-cancel>
</cbnp-message>
7.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 potwierdzenia odebrania komunikatu ORDER-MIGRATION-CANCEL przesyłany
synchronicznie.
BNP -> Operator
Komunikat przesyłany kanałem elektronicznym
Format xml:
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
ORDERMIGRATIONCANCEL-ACK
Rekord
ACCEPTANCE
Rekord
TAK
ACC-STATUS
INT(1)
cyfrowej:
0 – „OK”,
1 - „REJECTED”
TAK
Rekord
nadrzędny
TAK
69
ORDERMIGRATI
ONCANCELACK
Nazwa pola
Typ
Opis
Powód odrzucenia
Czy
wymagany?
REJECTIONREASON
INT(4)
MSG
NIE
ACC-DATE
DATE
(RRRR-MMDD
GG:MM:SS)
TAK
Rekord
nadrzędny
TAK
Przykładowy XML:
<msg-header>
</msg-header>
<order-migration-cancel-ack>
<acceptance>
<acc-date>2008-12-22 14:00:00</acc-date>
</acceptance>
</order-migration-cancel-ack>
</cbnp-message>
7.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ąch 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.
TP przesyła do Biorcy, Dawcy/ów komunikat o anulowaniu zamówienia Migracji.
70
7.9.1. Komunikat statusu anulowania zamówienia migracji
statusu ” czyli ORDER-MIGRATION-STATUS. 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 „7.5.1 Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy”
czyli ORDER-MIGRATION-TO-OPER z wypełnioną sekcją NUMBER-PORTABILITY i typem
przeniesienia ustawionym na CANCEL.
7.9.2. Komunikat potwierdzenia statusu anulowania zamówienia
migracji
7.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.
7.10.1. Komunikat potwierdzenia realizacji przez Dawcę i Macierzystego
Przy pomocy komunikatu ORDER-MIGRATION-TO-OPER-ACC operator Dawca i Macierzysty
zgłaszają do BNP pozytywną realizację techniczną. Realizacja ta odbywa się poprzez wskazanie w
komunikacie pola ACC-STATUS z wartością 4 COMPLETED.
7.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
7.11. Potwierdzenie realizacji Zamówienia Migracji
71
TP, po zrealizowaniu Zamówienia Migracji, potwierdza elektronicznie Biorcy, zrealizowanie
zamówienia. W okresie przejściowym komunikat potwierdzenie realizacji zamówienia Migracji dla
procesu powrotów z BSA do TP należy traktować jako informacje o zrealizowanej dezaktywacji
usługi BSA.
7.11.1. Komunikat statusu wykonania zamówienia migracji
statusu ” czyli ORDER-MIGRATION-STATUS. Komunikat ten wysyłany jest do operatora
Biorcy. W komunikacie przesyłany jest status COMPLETED.
7.11.2. Komunikat potwierdzenia statusu wykonania zamówienia
migracji
przez operatora Biorcę.
7.11.3. Potwierdzenie deinstalacji usługi dla Operaotra 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:
[email protected], określony w ZT
Adresat:
Operator.Korzystają[email protected], 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:
72
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,
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
ID Łącza;
Char(15)
Tak
Data dezaktywacji usługi;
Date()
Tak
* Powyższy schemat komunikatu będzie obowiązywał w okresie przjściowym
73
Opis
które
zostały
8. Migracja usługi abonenckiej od Przedsiębiorcy
telekomunikacyjnego korzystającego (Dawca) do
innego Przedsiębiorcy telekomunikacyjnego
(Biorca) bez zmiany usługi hurtowej;
8.1.
Abonent składa zamówienie Migracji z upoważnieniem dla Biorcy do występowania w jego imieniu
w zakresie realizacji danego Zamówienia Migracji.
Abonent wskazuje datę, 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ń Migracji 21 dni roboczych od
daty wpływu, która nie uwzględnia czasu niezbędnego dla Operatora Biorcy na dopełnienie
formalności wobec Dawcy). Data ta jest uzależniona od terminów rozwiązania umowy u
Operatora Dawcy.
Biorca w terminie 10 dni roboczych od złożenia zamówienia powinien dopełnić formalności z
dawcą w postaci przekazania im papierowej rezygnacji tak, aby w momencie wysłania przez TP
do Dawcy komunikatu z prośbą o potwierdzenie daty realizacji, Dawca nie odpowiedział TP, iż nie
otrzymali rezygnacji z usługi.
TP realizuje zamówienie Migracji w terminie nie krótszym niż 7 DR dla zamówień dotyczących
usługi NP. lub dla pozostałych zamówień Migracji 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 zawierającego co najmniej następujące dane:

Adres lokalu,

Data wygenerowania zlecenia rozumiana jako data wysłania Komunikat XML

Planowaną datę rozpoczęcia świadczenia przez Biorcę usług na rzecz Abonenta

Lokalizacja PG/PPD

Wersja usługi
74

Opcja usługi

Nazwa abonenta

Kod usługi ADSL
Biorca ma max. 10 DR 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.1.1. Opis kroków przesyłania Zamówień Migracji
1. System Operatora Biorcy tworzy wiadomość e-mail, której treść zawiera Zamówienie
Migracji 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.1.2. Opis kroków przesłania 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ówieniam, w formacie XML ustalonym w
75
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.
W tym wariancie procesu stosowany jest taki sam komunikat jak w punkcie „7.3.4 Komunikat
Zamówień Migracji” czyli ORDER-MIGRATION. Komunikat ten przysyłany jest przez operatora
Biorcę. Ze względu na to, że w tym wariancie procesu nie jest możliwa zmiana usługi hurtowej w
komunikacie typ zamówienia musi być zgodny z typem rezygnacji.
8.1.4. Komunikat potwierdzenia zamówień usług MIGRACJA
potwierdzenia zamówień usług migracji” czyli ORDER-MIGRATION-ACK. Komunikat ten wysyłany
jest do operatora Biorcy.
8.2.
Negatywna weryfikacja formalna TP
TP na weryfikację formalną ma 2 DR dla zgłoszeń dotyczących Migracji, dla zgłoszeń dotyczących
NP. nie jest przeprowadzana weryfikacja formalna zamówienia. Jeśli zamówienie jest odrzucane
(Wynik weryfikacji negatywny) zamówienie jest anulowane ze wskazaniem przyczyny (kodu
odrzucenia).
(Biorca) składa ponownie nowe Zamówienie Migracji.
8.2.1. Komunikat Negatywnej Weryfikacji Formalnej (NWF)
statusu ” czyli ORDER-MIGRATION-STATUS. Komunikat ten wysyłany jest do operatora Biorcy.
8.2.2. Komunikat potwierdzenia Negatywnej Weryfikacji Formalnej
potwierdzenia statusu” czyli ORDER-MIGRATION-ACK. Komunikat ten przysyłany jest prze
operatora Biorcę.
8.3.
Przekazanie daty rezygnacji do Dawców
Po pozytywnej weryfikacji formalnej TP wysyła komunikat do Dawcy/Dawców o dacie planowanej
dacie realizacji usługi, wskazanej przez Biorcę w Zamówieniu przez Biorcę.
Dawca/Dawcy dokonuje weryfikacji formalnej otrzymanego zapytania. Dawca może odmówić
realizacji Zamówienia tylko w przypadkach opisanych w kodach odrzuceń, stanowiących załącznik
do Oferty.
rozpatrzenia reklamacji dotyczącej negatywnego wyniku weryfikacji formalnej. Komunikat ten
może być poprzedzony wcześniejszym komunikatem NWF
76
8.3.1. Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy
zgłoszenia Rezygnacji z usług u operatora Dawcy” czyli ORDER-MIGRATION-TO-OPER.
Komunikat ten wysyłany jest do operatora Dawcy/Dawców.
operatora Dawcy
potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy” czyli ORDER-MIGRATION-ACK.
Komunikat ten przysyłany jest prze operatora Dawcę/Dawców.
8.4.
Potwierdzenia realizacji zlecenia lub odrzucenie
TP czeka na odpowiedź od Dawcy/Dawców w zakresie weryfikacji zamówienia wysłanego przez
TP:
a. Gdy nie otrzyma w ciągu 1 DR dla zamówień dotyczących NP lub 3 DR dla pozostałych
zamówień Migracji odpowiedzi od Dawców lub Macierzystego realizuje zlecenie z
terminem wskazanym przez Operatora Biorcę w imieniu Abonenta, o ile weryfikacja
techniczna jest pozytywna.
b. Odrzuca zamówienie i odpowiada Dawcy/Dawcom i Biorcy, że:
iii. 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 Operatora Biorce lub, Dawcę dla pozostałych
zamówień Migracji), o ile data ta nie przekracza okresu 120 dni
kalendarzowych od daty wpływu do TP
iv. 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 i
odpowiada Dawcy/Dawcom i Biorcy, że:
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łyneła po terminie
77
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 wraz z przesłaniem komunikatu do Dawcy/Dawców oraz Macierzystego weryfikuje możliwości
techniczne realizacji Zamówienia Biorcy. W tym zakresie również TP sprawdza zgodność
podanego adresu instalacji ze stanem faktycznym.
TP ma 1 DR dla zamówień dotyczących NP. lub 6 DR dla pozostałych zamówień na weryfikację
możliwości technicznych realizacji Zamówienia migracji (termin ten jest liczony maksymalnego
czasu przeznaczonego na weryfikację formalno- prawną)".
8.4.1. Komunikat akceptacji rezygnacji lub odrzucenia zlecenia
migracji przez Dawców
akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców” czyli ORDER-MIGRATIONTO-OPER-ACC. Komunikat ten przysyłany jest przez operatora Dawcę/Dawców.
8.4.2. Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia
zlecenia migracji przez Dawców
potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców” czyli
ORDER-MIGRATION-TO-OPER-ACC-ACK. Komunikat ten wysyłany jest do operatora
Dawcy/Dawców.
8.5.
Potwierdzenie bądź odmowa realizacji Zamówienia Migracji
wraz z datą realizacji
reklamacji dotyczącej negatywnego wyniku WT. Komunikat ten może być poprzedzony
wcześniejszym komunikatem NWT
Po otrzymaniu komunikatu od Dawcy/Dawców o dokonanej weryfikacji formalnej Zamówienia
Migracji oraz po dokonaniu w TP weryfikacji zamówienia TP wysyła komunikat do Biorcy oraz
Dawcy/Dawców:
78
•
o odrzuceniu Zamówienia wraz ze wskazaniem przyczyny technicznej (patrz rozdział 12)
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.
W przypadku nieotrzymania komunikatu od Dawcy/Dawców TP realizuje zamówienie z datą
wskazaną przez Biorcę o ile data ta nie jest dłuższa niż 120 dni kalendarzowych, nie krótsza niż
21 dni roboczych i nie przypada na dzień świąteczny, ani wolny od pracy.
8.5.1. Komunikat - informacja o dacie realizacji Zamówienia Migracji/odmowie
realizacji zamówienia Migracji
W tym wariancie procesu w przypadku przesyłania daty realizacji Zamówienia Migracji stosowany
jest taki sam komunikat jak w punkcie „7.4.1 Komunikat statusu ” czyli ORDER-MIGRATIONSTATUS. 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 „7.5.1 Komunikat zgłoszenia Rezygnacji z usług
u operatora Dawcy” czyli ORDER-MIGRATION-TO-OPER z wypełnioną sekcją NUMBERPORTABILITY i typem przeniesienia ustawionym na CANCEL
8.5.2. Komunikat potwierdzenia dla komunikatu informacji o dacie
realizacji Zamówienia Migracji/odmowie realizacji zamówienia
Migracji
W tym wariance procesu stosowany jest taki sam komunikat jak w punkcie „7.4.2 Komunikat
potwierdzenia status” czyli ORDER-MIGRATION-STATUS-ACK. Komunikat ten przysyłany jest
rezygnacji z usług u operatora Dawcy” czyli ORDER-MIGRATION-TO-OPER-ACK
79
8.6.
Biorca oraz Dawcy/Dawca mogą przesłać do TP rezygnację z Zamówienia 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.
8.6.1. Komunikat Rezygnacja z Zamówienia Migracji z powodu
Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji” czyli
ORDER-MIGRATION-CANCEL. Komunikat ten przysyłany jest przez operatora Biorcę lub
Dawcę/Dawców.
potwierdzenia Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia
Migracji” czyli ORDER-MIGRATION-CANCEL-ACK. Komunikat ten wysyłany jest do operatora
Biorcy lub Dawcy/Dawców.
8.7.
Potwierdzenie do Biorcy, Dawcy/ów anulowania zamówienia
migracji
TP przesyła komunikat o wpływie rezygnacji i anulowaniu realizacji zamówienia zarówno do
Biorcy, jak i Dawcy/Dawców.
Jeśli taka rezygnacja wpłynie w okresie krótszymi niż 5 DR dla zamówień dotyczących NP. lub 10
dni roboczych dla pozostałych zamówień Migracji, przed datą wymaganą realizacji Zamówienia,
TP odrzuci ją z komunikatem- rezygnacja na tym etapie jest nie możliwa i TP zrealizuje
zamówienie w uzgodnionym wcześniej terminie.
TP przesyła do Biorcy, Dawcy/ów komunikat o anulowaniu zamówienia Migracji.
80
statusu ” czyli ORDER-MIGRATION-STATUS. 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 „7.5.1 Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy”
czyli ORDER-MIGRATION-TO-OPER z wypełnioną sekcją NUMBER-PORTABILITY i typem
przeniesienia ustawionym na CANCEL.
migracji
8.8.
Potwierdzenie realizacji Zamówienia Migracji
TP po zrealizowaniu zamówienia na przejście potwierdza elektronicznie Biorcy, zrealizowanie
zamówienia.
81
statusu ” czyli ORDER-MIGRATION-STATUS. Komunikat ten wysyłany jest do operatora
Biorcy. W komunikacie przesyłany jest status COMPLETED.
W procesie zmiany operatora WLR w przypadku świadczenia usługi na radiodostępie, do
operatora biorcy wysyłana jest informacja, że usługa świadczona jest na radiodostępie (z
konsekwencjami jak w procesie dostarczania usługi WLR na radiodostępie).
migracji
82
9. Migracja usługi abonenckiej z usługi hurtowej
obecnie świadczonej na inną usługę hurtową bez
zmiany Przedsiębiorcy telekomunikacyjnego
Jeśli Biorca jest równocześnie Dawcą komunikacja dotycząca potwierdzenia możliwości realizacji
zamówienia pomiędzy Dawcą a TP oraz TP – Dawcą nie będzie obowiązkowa dla potwierdzenia
terminów realizacji zleceń. TP brak odpowiedzi potraktuje jako akceptacje zgłoszonej daty.
9.1.
Abonent składa zamówienie na przejście z usługi hurtowej obecnie świadczonej na inną usługę
hurtową. Abonent upoważnia swojego Operatora do występowania w jego imieniu w zakresie
realizacji danego zlecenia
Abonent wskazuje datę 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.
Biorca wysyła zamówienie na realizację danej usługi z nadanym identyfikatorem
zamówienia/rezygnacji (wyłącznie elektronicznie do TP). Jeśli data realizacji będzie krótsza niż 7
DR dla zamówień dotyczących usługi NP. lub dla pozostałych zamówień Migracji 21 DR, Biorca
przed wysłaniem zamówienia do TP uzgadnia zmianę daty z Abonentem (wydłuża datę) i
wskazuje ją w zamówieniu.
Data najdłuższa
realizacji zamówienia na przejście nie może przekraczać 120 dni
kalendarzowych od dnia wysłania zamówienia do TP i nie może przypadać na dzień świąteczny,
ani wolny od pracy.
Zamówienie Migracji w formie Komunikatu XML zawierającego następujące dane:

Adres lokalu,

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.)

Lokalizacja PG/PPD

83

Wersja usługi

Opcja usługi

Nazwa abonenta

Kod usługi ADSL
Zamówień Migracji” czyli ORDER-MIGRATION. Komunikat ten przysyłany jest przez operatora
Biorcę. Ze względu na to, że w tym wariancie procesu nie zmienia się operator, w komunikacie
operator Dawca musi być zgodny z operatorem Biorcą.
9.1.2. Komunikat potwierdzenia zamówień usług MIGRACJA
potwierdzenia zamówień usług migracji” czyli ORDER-MIGRATION-ACK. Komunikat ten wysyłany
9.2.
Negatywna weryfikacja formalna
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ń.ma 2 DR. Jeśli zamówienie jest odrzucane (Wynik weryfikacji
negatywny) zamówienie jest anulowane ze wskazaniem przyczyny (kodu odrzucenia).
(biorca) składa ponownie Zamówienie Migracji.
84
9.2.1. Komunikat Negatywnej Weryfikacji Formalnej (NWF)
statusu ” czyli ORDER-MIGRATION-STATUS ze statusem REJECTED. Komunikat ten wysyłany
9.2.2. Komunikat potwierdzenia Negatywnej Weryfikacji Formalnej
potwierdzenia statusu” czyli ORDER-MIGRATION-ACK. Komunikat ten przysyłany jest prze
operatora Biorcę
9.3.
Przekazanie daty rezygnacji lub daty wykonania NP do
Dawców
rozpatrzenia reklamacji dotyczącej negatywnego wyniku weryfikacji formalnej. Komunikat ten
może być poprzedzony wcześniejszym komunikatem NWF
9.3.1. Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy
lub daty wykonania NP
zgłoszenia Rezygnacji z usług u operatora Dawcy” czyli ORDER-MIGRATION-TO-OPER.
Komunikat ten wysyłany jest do operatora Dawcy/Dawców.
operatora Dawcy lub daty wykonania NP
potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy” czyli ORDER-MIGRATION-ACK.
Komunikat ten przysyłany jest prze operatora Dawcę/Dawców.
9.4.
Potwierdzenie bądź odmowa realizacji Zamówienia Migracji
wraz z datą realizacji
TP weryfikuje możliwości techniczne realizacji zamówienia Biorcy. W tym zakresie również TP
sprawdza zgodność podanego adresu instalacji ze stanem faktycznym.
TP ma 1 DR dla zamówień dotyczących NP. lub 6 DR dla pozostałych zamówień, na weryfikację
możliwości technicznych realizacji Zamówienia migracji (termin ten jest liczony maksymalnego
czasu przeznaczonego na weryfikację formalno- prawną)".
Po dokonaniu weryfikacji technicznej możliwości realizacji zamówienia TP wysyła komunikat do
Biorcy o odrzuceniu zamówienia wraz ze wskazaniem przyczyny technicznej bądź formalnej albo
o przyjęciu do realizacji ze wskazaniem daty realizacji zamówienia.
reklamacji dotyczącej negatywnego wyniku WT. Komunikat ten może być poprzedzony
wcześniejszym komunikatem NWT
85
9.4.1. Komunikat - informacja o dacie realizacji Zamówienia Migracji/odmowie
realizacji zamówienia Migracji
W tym wariancie procesu w przypadku przesyłania daty realizacji Zamówienia Migracji stosowany
jest taki sam komunikat jak w punkcie „7.4.1 Komunikat statusu ” czyli ORDER-MIGRATIONSTATUS. Komunikat ten wysyłany jest do operatora Biorcy oraz operatora Macierzystego (jeśli
bierze udział w procesie migracji). Do operatora Biorcy przesyłany jest status OK, do operatora
Macierzystego status CONFIRMED-REDIRECT.
W przypadku odmowy realizacji Zamówienia Migracji do operatora Biorcy przesyłany jest status
REJECTED. Do operatora macierzystego (jeśli bierze udział w procesie migracji) wysyłany jest
taki sam komunikat jak w punkcie „7.5.1 Komunikat zgłoszenia Rezygnacji z usług u operatora
Dawcy” czyli ORDER-MIGRATION-TO-OPER z wypełnioną sekcją NUMBER-PORTABILITY i typem
przeniesienia ustawionym na CANCEL
9.4.2. Komunikat potwierdzenia Akceptacja/brak akceptacji daty
realizacji Zamówienia Migracji
przez operatora Biorcę. Operator Macierzysty (jeśli bierze udział w procesie migracji) przysyła
taki sam komunikat jak w punkcie „7.5.2 Komunikat potwierdzenia zgłoszenia rezygnacji z usług
u operatora Dawcy” czyli ORDER-MIGRATION-TO-OPER-ACK.
9.5.
Operator może przesłać do TP rezygnację z Zamówienia tylko w przypadku otrzymania pisemnej
rezygnacji Abonenta. Rezygnacja taka jest skuteczna, jeśli wpłynie od Operatora do TP
najpóźniej na 5 DR dla zamówień dotyczących NP. lub 10 dni roboczych dla pozostałych
zamówień Migracji przed datą wymaganą realizacji Zamówienia.
86
9.5.1. Komunikat Rezygnacja z Zamówienia Migracji z powodu
Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji” czyli
ORDER-MIGRATION-CANCEL. Komunikat ten przysyłany jest przez operatora Biorcę.
potwierdzenia Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia
Migracji” czyli ORDER-MIGRATION-CANCEL-ACK. Komunikat ten wysyłany jest do operatora
Biorcy
9.6.
Potwierdzenie do Biorcy anulowania zamówienia Migracji.
TP przesyła komunikat o wpływie rezygnacji i anulowaniu realizacji zamówienia do Biorcy.
Jeśli taka rezygnacja wpłynie w okresie krótszymi niż 5 DR dla zamówień dotyczących NP. lub 10
dni roboczych dla pozostałych zamówień przed datą wymaganą realizacji, TP odrzuci ją z
komunikatem- rezygnacja na tym etapie jest nie możliwa i TP zrealizuje zamówienie w
uzgodnionym wcześniej terminie.
TP przesyła do Biorcy, komunikat o anulowaniu zamówienia Migracji.
87
Do operatora Biorcy przesyłany jest status CANCEL. Do operatora macierzystego (jeśli bierze
udział w procesie migracji) wysyłany jest taki sam komunikat jak w punkcie „7.5.1 Komunikat
zgłoszenia Rezygnacji z usług u operatora Dawcy” czyli ORDER-MIGRATION-TO-OPER z
wypełnioną sekcją NUMBER-PORTABILITY i typem przeniesienia ustawionym na CANCEL.
migracji
przez operatora Biorcę. Operator Macierzysty (jeśli bierze udział w procesie migracji) przysyła
taki sam komunikat jak w punkcie „7.5.2 Komunikat potwierdzenia zgłoszenia rezygnacji z usług
u operatora Dawcy” czyli ORDER-MIGRATION-TO-OPER-ACK.
9.7.
Potwierdzenie od Dawcy wykonania NP.
W przypadku gdy TP jest pośrednikiem w przekazywaniu komunikatów dla poprawnej realizacji
zamówień NP., Operator Dawca 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.
9.7.1. Komunikat potwierdzenia realizacji przez Dawcę
Przy pomocy komunikatu ORDER-MIGRATION-TO-OPER-ACC operator Dawca i Macierzysty
zgłaszają do BNP pozytywną realizację techniczną. Realizacja ta odbywa się poprzez wskazanie w
komunikacie pola ACC-STATUS z wartością 4 COMPLETED.
9.7.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzającego
realizację przez Dawcę
Potwierdzenie dostarczenia komunikatu pozytywnej realizacji technicznej odbywa się za pomocą
standardowego ORDER-MIGRATION-TO-OPER-ACC-ACK
9.8.
Potwierdzenie realizacji Zamówienia Migracji
TP po zrealizowaniu zamówienia na przejście potwierdza elektronicznie Operatorowi,
zrealizowanie zamówienia.
88
W komunikacie przesyłany jest status COMPLETED.
migracji
89
10. Proces zgłaszania reklamacji
Przedsiębiorca telekomunikacyjny Biorca może złożyć do TP reklamację dotyczącą zamówienia
migracji typu :
a. Reklamacja formalna
i. Negatywna Weryfikacja Formalna – odrzucenie prze TP zamówienia Migracji
z powodu błędów/braków formalnych przez TP
b. Reklamacja Techniczna
i. Negatywny wynik weryfikacji technicznej, ( czyli odrzucenie przez TP
zamówienia z powodu negatywnej weryfikacji technicznej)
ii. Brak/ niewłaściwa realizacja zamówienia migracji,
iii. Odmowa realizacji zamówienia migracji przez TP,
iv. Brak anulowania zamówienia migracji przez TP
Zgłoszenie reklamacji powinno zawierać:
a) datę zgłoszenia reklamacji do TP
b) ID Operatora
c) dane Abonenta (numer telefonu/id usługi szerokopasmowej/ID LLU, adres instalacyjny
usługi),
d) numer zgłoszenia Operatora,
e) Id zamówienia migracji
f) typ reklamacji
g) przedmiot reklamacji,
h) uzasadnienie reklamacji.
W ciągu 7 dni kalendarzowych od dnia przyjęcia zgłoszenia reklamacji, TP prześle do operatora
Biorcy komunikat odpowiedzi na zgłoszenie reklamacji. Komunikat będzie zawierał informację o
rozpatrzeniu reklamacji lub informację o konieczności przesunięcia terminu rozpatrzenia
reklamacji. TP może przesunąć termin rozpatrzenia reklamacji maksymalnie do 12 dni
kalendarzowych od dnia przyjęcia zgłoszenia reklamacji.
Po zrealizowaniu zamówienia migracji dostarczeniu zamówionej przez Operatora Biorcę usługi
przez TP, reklamacje od Operatora Biorcy i Operatora Dawcy powinny być zgłaszane zgodnie z
procesem obowiązującym dla danego typu usług w myśl odpowiednich umów o dostępie ( BSA,
LLU, WLR, NP).
W przypadku Number Portability reklamacja może być zgłoszona tylko i wyłącznie przez
Operatora Biorcę.
* Realizacja procesu reklamacji będzie możliwa w późniejszym etapie projektu Migracji. W chwili
obecnej informacje zawarte w komunikatach dotyczące tych usług nie będą realizowane.
10.1. Zgłaszenie reklamacji formalnej
90
Przedsiębiorca telekomunikacyjny Biorca może złożyć reklamację NWF w ciągu 2 DR od dnia
otrzymania informacji od TP o odrzuceniu Zamówienia z powodów formalnych. KPI ten umożliwia
w razie uwzględnienia reklamacji zrealizowanie Zamówienia Operatora Biorcy z datą wymaganą
wskazaną w Zamówieniu bez konieczności ponownego przysyłania zamówienia. Zgłoszenia
wysłane po terminie 2 DR będą odrzucane ze wskazanie odpwiedniego kodu odrzutu.
W przypadku uwzględnienia reklamacji dotyczącej NWF zamówienia Number Portability, Operator
Biorca składa nowe zamówienie.
10.1.1. Komunikat zgłaszania reklamacji
Treść wiadomości: id:[SUBJECT-ID][INTERACTION-ID]REKLAMACJA-MIGRACJA[xml]
Format xml:
Nazwa pola
Typ
Opis
Czy wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
COMPLAINMIGRATION-TOSERVICEPACKAGE
Rekord
SIZE
INT(10)
Ilość zgłoszeń reklamacji w komunikacie
NIE
elektronicznym
Brak pola oznacza
tryb pojedynczego
zgłoszenia
OPER
CHAR(10)
Identyfikator UKE Operatora, do którego
kierowane są zgłoszenia reklamacji
TAK
GENERATE-DATE
DATE (RRRRMM-DD
GG:MM:SS)
Data generacji komunikatu zgłoszenia
reklamacji (data przesłania reklamacji w
formie elektronicznej)
TAK
COMPLAINMIGRATION-TOSERVICEELEMENT
Rekord
COMPLAIN-TYPE
INT(4)
1 - "TECHNICAL-COMPLAIN"
reklamacja techniczna
2 - "FORMAL-COMPLAIN" reklamacja
formalna
TAK
ITEM
INT(10)
Numer kolejny zgłoszenia reklamacji w
komunikacie
TAK
Rekord
nadrzędny
TAK
TAK może
COMPLAINwystępować
MIGRATIONwielokrotnie w TO-SERVICEkomunikacie
PACKAGE
(ilość rekordów
zgodna z polem
SIZE– brak pola
SIZE oznacza
pojedyncze
zgłoszenie)
91
Nazwa pola
Typ
Opis
Czy wymagany?
COMPLAINNUMBER
ORDERNUMBER
Numer reklamacji Migracji nadany przez
Biorcę
TAK
COMPLAIN-DATE
DATE (RRRRMM-DD
GG:MM:SS)
Data zgłoszenia reklamacji do Biorcy
TAK
ORDER-NUMBER
ORDERNUMBER
Numer zamówienia nadany przez
operatora biorcę, do którego zgłaszana
jest reklamacja
TAK
NUMBER
CHAR(10)
Numer telefonu dla reklamacji
SERVICE-ID
CHAR(12)
CLIENT-NAME
CHAR(256)
Nazwa klienta, do którego należy
numer/łącze
TAK
CLIENT-ADDRESS
ADDRESS
Adres instalacyjny
TAK
COMPLAINREQUEST-UNIT
CHAR(512)
Jednostka organizacyjna operatora
(kontakt) zgłaszająca reklamację
NIE
SUBJECT
INT(4)
Kod przedmiotu reklamacji
TAK
JUSTIFICATION
CHAR(1024)
Uzasadnienie reklamacji.
TAK
Rekord
nadrzędny
TAK
Jeżeli w
reklamowanym
zamówieniu
występował.
TAK
Jeżeli w
reklamowanym
zamówieniu
występował
Przykład:
<msg-header>
</msg-header>
<complain-migration-to-service-package>
<oper>1</oper>
<complain-migration-to-service-element>
<complain-type>2</complain-type>
<item>1</item>
<complain-number>000060005412399</complain-number>
<complain-date>2008-01-10 11:12:12</complain-date>
<order-number>000060005412312</complain-number>
<client-address>
92
</client-address>
<complain-request-unit>Jednostka Organizacyjna</complain-request-unit>
<subject>98</subject>
<justification>Pole opisowe</justification>
</complain-migration-to-service-element>
</complain-migration-to-service-package>
</cbnp-message>
10.1.2. Komunikat potwierdzenia zgłoszenia reklamacji formalnej
system BNP będzie tworzył komunikat potwierdzenia odebrania
(COMPLAIN-MIGRATION-TO-SERVICE-ACK) o następującej strukturze:
zgłoszenia
reklamacji
Treść wiadomości: id:[SUBJECT-ID][INTERACTION-ID]REKLAMACJA-MIGRACJA-ACK[xml]
Format xml:
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT(10)
Identyfikator sesji wymiany
TAK
SUBJECT-ID
CHAR(40)
Identyfikacja źródła nadawcy tego
komunikatu
TAK
DEST-SUBJECT-ID
CHAR(40)
Identyfikator odbiorcy komunikatu
TAK
TEST-VER
INT(1)
TAK
COMPLAINMIGRATION-TOSERVICEPACKAGE-ACK
Rekord
ACCEPTANCE
Rekord
TAK
ITEM
INT(10)
Numer kolejny potwierdzenia zgłoszenia
reklamacji w komunikacie
TAK
ACC-STATUS
INT(1)
cyfrowej:
0 - OK”,
1 - „REJECTED”
TAK
REJECTIONREASON
INT(4)
Powód odrzucenia (informatyczny),
załącznik do tego dokumentu
MSG
CHAR(1024)
Komunikat błędu
ACC-DATE
DATE
(RRRR-MMDD GG:mm:ss)
Rekord
nadrzędny
TAK
93
TAK gdy
ACCSTATUS=
„REJECTED”
NIE
TAK
COMPLAINMIGRATIONTOSERVICEPACKAGEACK
Przykład:
<msg-header>
</msg-header>
<complain-migration-to-service-package-ack>
<acceptance>
<item>1</item>
<msg>Opis powodu odrzucenia</msg>
<acc-date>2008-01-10 16:50:30</acc-date>
</acceptance>
</complain-migration-to-service-package-ack>
</cbnp-message>
10.1.3. Komunikat odpowiedzi na zgłoszenie reklamacji formalnej
W ciągu 7 dni kalendarzowych od dnia przyjęcia zgłoszenia reklamacji, TP prześle do Operatora
Biorcy komunikat odpowiedzi na zgłoszenie reklamacji. Komunikat będzie zawierał informację o
rozpatrzeniu reklamacji lub informację o konieczności przesunięcia terminu rozpatrzenia
reklamacji. TP może przesunąć termin rozpatrzenia reklamacji maksymalnie do 12 dni
kalendarzowych od dnia przyjęcia zgłoszenia reklamacji. W razie uznania reklamacji TP realizuje
zamówienie migracji zgodnie z datą wymaganą wskazaną na Zamówieniu Operatora Biorcy.
W przypadku uwzględnienia reklamacji dotyczącej NWF zamówienia Number Portability, Operator
Biorca składa nowe zamówienie.
Treść wiadomości: id:[SUBJECT-ID][INTERACTION-ID]ODPOWIEDZ-REKLAMACJAMIGRACJA[xml]
Format xml:
Nazwa pola
Typ
Opis
Czy wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT(10)
TAK
SUBJECT-ID
CHAR(40)
Identyfikator źródła nadawcy tego
komunikatu
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
COMPLAINMIGRATION-TOSERVICE-REPLYPACKAGE
Rekord
SIZE
INTEGER
TAK
Ilość informacji o rozpatrzeniu zgłoszeń
reklamacji w paczce
94
NIE
Brak pola oznacza
tryb pojedynczego
zgłoszenia
Rekord
nadrzędny
Nazwa pola
Typ
Opis
Identyfikator UKE Operatora, do którego
kierowane są informacje w paczce
Czy wymagany?
OPER
CHAR(10)
GENERATE-DATE
DATE (RRRR- Data generacji paczki
MM-DD
GG:MM:SS)
COMPLAINMIGRATION-TOSERVICE-REPLYELEMENT
Rekord
COMPLAIN-TYPE
INT(4)
1 - "TECHNICAL-COMPLAIN"
reklamacja techniczna
2 - "FORMAL-COMPLAIN" reklamacja
formalna
TAK
ITEM
INT(10)
TAK
COMPLAINNUMBER
ORDERNUMBER
Numer reklamacji Migracji nadany przez
operatora Biorcę
TAK
COMPLAIN-DATE
DATE (RRRR- Data zgłoszenia reklamacji do Biorcy
MM-DD)
NIE
ORDER-NUMBER
ORDERNUMBER
biorcę, do którego zgłaszana jest
reklamacja
NIE
NUMBER
CHAR(10)
Numer telefonu dla zgłoszonej reklamacji
TAK
TAK
TAK może
COMPLAINwystępować
MIGRATIONwielokrotnie w
TOkomunikacie
SERVICE(ilość rekordów
REPLYzgodna z polem
PACKAGE
SIZE– brak pola
SIZE oznacza
pojedynczą
odpowiedź)
TAK
Jeżeli w
reklamowanym
zamówieniu
występował.
SERVICE-ID
CHAR(12)
Rekord
nadrzędny
TAK
Jeżeli w
reklamowanym
zamówieniu
występował
CONSIDER-DATE
DATE (RRRR- Data zakończenia rozpatrywania reklamacji
MM-DD
(lub w przypadku informacji o przesunięciu
GG:MM:SS)
terminu rozpatrzenia nowa data
rozpatrzenia)
TAK
CONSIDER-UNIT
CHAR(512)
NIE
Jednostka organizacyjna odpowiedzialna za
rozpatrzenie reklamacji
95
Nazwa pola
Typ
Opis
Czy wymagany?
COMPLAINSTATUS
INT(1)
Status rozpatrzenia zgłoszenia reklamacji:
0 - „OK” – zgłoszenie rozpatrzone
1 - "REJECTED" - zgłoszenie odrzucone,
powód odrzucenia w polu REJECTIONREASON
3 - „MOVED” – zgłoszenie konieczności
przesunięcia daty rozpatrzenia reklamacji
TAK
REJECTIONREASON
INT(4)
Powód odrzucenia zgłoszenia reklamacji
lub powód przesunięcia terminu
rozpatrzenia.
TAK gdy
FAULT-STATUS
=1
MSG
CHAR(1024)
Komunikat powodu przesunięcia
RESULT
INT(4)
Wynik rozpatrzenia reklamacji:
1 - Decyzja pozytywna
2 - Decyzja negatywna
3 - Reklamacja częściowo uznana
4- TP nie jest stroną do rozpatrzenia
reklamacji.
TAK, gdy
COMPLAINSTATUS = „OK.”
RESULT-DESC
CHAR(1024)
Opis wyniku rozpatrzenia reklamacji
TAK, gdy
VERDICT
CHAR(1024)
Proponowane rozstrzygniecie reklamacji.
TAK, gdy
W polu może znajdować się kwota uznanej
COMPLAINreklamacji.
STATUS = „OK.”
JUSTIFICATION
CHAR(1024)
Uzasadnienie rozstrzygnięcia reklamacji
Rekord
nadrzędny
TAK, gdy
COMPLAINSTATUS=
“MOVED”
TAK, gdy
Przykład:
Odrzucenie zgłoszenia reklamacji z przyczyn technicznych
<msg-header>
</msg-header>
<complain-migration-to-service-reply-package>
<oper>6</oper>
<complain-migration-to-service-reply-element>
<item>1</item>
<consider-date>2008-01-10 15:45:01</consider-date>
96
<consider-unit>Jednostka Organizacyjna</consider-unit>
<complain-status>1</complain-status>
<msg>brak lub błędny numer ID łącza</msg>
<result></result>
<result-desc></result-desc>
<verdict></verdict>
<justification></justification>
</complain-migration-to-service-reply-element>
</complain-migration-to-service-reply-package>
</cbnp-message>
Reklamacja uznana
<msg-header>
</msg-header>
<oper>6</oper>
<item>1</item>
<rejection-reason/>
<msg>Procedura poprawna</msg>
<result>1</result>
<result-desc>Uznano rekalmację</result-desc>
<verdict>Zwrot kosztów 1,23zł</verdict>
<justification>Klient ma zawsze rację</justification>
</cbnp-message>
Przesunięcie terminu rozpatrzenia reklamacji
<msg-header>
</msg-header>
<oper>6</oper>
<item>1</item>
97
<msg>Trwa proces wyjasniania po stronie operatora dawcy</msg>
<result></result>
<result-desc></result-desc>
<verdict></verdict>
<justification></justification>
</cbnp-message>
10.1.4. Komunikat potwierdzenia odpowiedzi na zgłoszenie reklamacji
formalnej
Po odczytaniu przez system Operatora odpowiedzi na zgłoszenie reklamacji Migracji i
sprawdzeniu formalnym struktury pliku system Operatora utworzy komunikat potwierdzenia
odebrania odpowiedzi na zgłoszenie reklamacji (COMPLAIN-MIGRATION-TO-SERVICE-REPLYPACKAGE-ACK) o następującej strukturze:
Treść wiadomości: id:[SUBJECT-ID][INTERACTION-ID]ODPOWIEDZ-REKLAMACJA-MIGRACJAACK[xml]
Format xml:
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT(10)
TAK
SUBJECT-ID
CHAR(40)
Identyfikacja źródła nadawcy tego
komunikatu
TAK
DEST-SUBJECT-ID
CHAR(40)
TAK
TEST-VER
INT(1)
TAK
COMPLAINMIGRATION-TOSERVICE-REPLYPACKAGE-ACK
Rekord
ACCEPTANCE
Rekord
TAK
ITEM
INT(10)
Numer kolejny potwierdzenia rozpatrzenia
reklamacji w komunikacie
TAK
ACC-STATUS
INT(1)
cyfrowej:
0 - OK”,
1 - „REJECTED”
TAK
Rekord
nadrzędny
TAK
98
COMPLAINMIGRATIONTOSERVICEREPLYPACKAGEACK
Nazwa pola
Typ
Opis
REJECTIONREASON
INT(4)
Powód odrzucenia (informatyczny),
załącznik do tego dokumentu
MSG
CHAR(1024)
Komunikat błędu
ACC-DATE
DATE
Data wygenerowania potwierdzenia
(RRRR-MModbioru, data ta będzie zapisywana
DD GG:mm:ss) w systemach OPERATORA jako data
odbioru odpowiedzi na zgłoszenie
reklamacji, jeśli nie będzie się znacznie
różniła od daty wysłania (GENERATEDATE) do TP (dopuszczalna różnica do 12
godzin)
Czy
wymagany?
Rekord
nadrzędny
TAK gdy
ACCSTATUS=
„REJECTED”
NIE
TAK
Przykład:
<msg-header>
</msg-header>
<complain-migration-to-service-reply-package-ack>
<acceptance>
<item>1</item>
<msg>Opis powodu odrzucenia</msg>
<acc-date>2008-01-10 16:50:30</acc-date>
</acceptance>
</complain-migration-to-service-reply-package-ack>
</cbnp-message>
10.2. Zgłoszenie reklamacji technicznej.
i. Negatywny wynik weryfikacji technicznej, ( czyli odrzucenie przez TP
zamówienia z powodu negatywnej weryfikacji technicznej)
Przedsiębiorca telekomunikacyjny Biorca składa reklamację dot. Negatywnej Weryfikacji
Technicznej w ciągu 2 DR od dnia otrzymania informacji od TP o odrzuceniu Zamówienia z
powodu negatywnego wyniku weryfikacji technicznej, KPI ten umożliwia w razie uwzględnienia i
pozytywnego rozpatrzenia reklamacji zrealizowanie przez TP Zamówienia Operatora Biorcy z datą
wymaganą wskazaną w Zamówieniu bez konieczności ponownego przysyłania zamówienia.
W przypadku pozytywnego rozpatrzenia Zgłoszenia Reklamacji i braku możliwości realizacji
Zamówienia Migracji w planowanej dacie potwierdzonej przez Dawcę/Dawców, faktyczna data
realizacji Zamówienia Migracji może być przesunięta na pierwszy wolny termin realizacji i nie
krótszy niż 5 DR.
W przypadku uwzględnienia reklamacji dotyczącej NWT zamówienia Number Portability, Operator
Biorca składa nowe zamówienie
Zgłoszenia wysłane po terminie 2 DR będą odrzucane ze wskazanie odpwiedniego kodu odrzutu.
ii. Brak/ niewłaściwa realizacja zamówienia migracji,
99
iii. Odmowa realizacji zamówienia migracji przez TP,
iv. Brak anulowania zamówienia migracji przez TP
Przedsiębiorca telekomunikacyjny Biorca i/lub Dawca składa reklamację dotyczącą
braku/niewłaściwej realizacji zamówienia migracji, odmowy realizacji zamówienia migracji przez
TP lub braku anulowania zamówienia migracji przez TP po dacie wymaganej realizacji
zamówienia migracji.
Przedsiębiorca telekomunikacyjny Biorca i/lub Dawca może złożyć reklamację dotyczącą braku /
niewłaściwej realizacji zamówienia migracji, odmowy realizacji zamówienia migracji przez TP lub
braku anulowania zamówienia migracji przez TP w ciągu 12 miesięcy od daty wymaganej
realizacji zamówienia migracji.
Dawca może również złożyć reklamację dot. braku lub niewłaściwej realizacji zamówienia
migracji, odmowy realizacji zamówienia migracji przez TP lub braku anulowania zamówienia
migracji przez TP w okresie od otrzymania z TP komunikatu o dacie planowanej realizacji usługi
wskazanej przez Biorcę w zamówieniu do planowanej daty realizacji zamówienia.
10.2.1. Komunikat zgłoszenia reklamacji technicznej
zgłaszania reklamacji” czyli COMPLAIN-MIGRATION-TO-SERVICE-PACKAGE z podaniem
COMPLAIN-TYPE = "TECHNICAL-COMPLAIN". Komunikat ten przysyłany jest przez operatora
Biorcę.
Po odczytaniu przez BNP zgłoszenia reklamacji Migracji i sprawdzeniu formalnym struktury pliku
system BNP utworzy komunikat potwierdzenia odebrania zgłoszenia reklamacji taki sam jak w
punkcie „10.1.2 Komunikat potwierdzenia zgłoszenia reklamacji” czyli COMPLAIN-MIGRATIONTO-SERVICE-PACKAGE-ACK.
Dla przypadków gdzie zaistniała konieczność zgłoszenia reklamacji przez Dawcę stosuje się
standardowy proces reklamacyjny zgodny z dotychczasową umową na świadczenie usług WLR,
BSA czy NP
10.2.2. Komunikat potwierdzenia zgłoszenia reklamacji technicznej
system BNP będzie tworzył komunikat potwierdzenia odebrania
(COMPLAIN-MIGRATION-TO-SERVICE-ACK) o następującej strukturze:
zgłoszenia
reklamacji
Treść wiadomości: id:[SUBJECT-ID][INTERACTION-ID]REKLAMACJA-MIGRACJA-ACK[xml]
Format xml:
10.2.3. Komunikat odpowiedzi na zgłoszenie reklamacji technicznej
W ciągu 7 dni kalendarzowych od dnia przyjęcia zgłoszenia reklamacji, TP prześle do operatora
Biorcy i/lub Dawcy komunikat odpowiedzi na zgłoszenie reklamacji. Komunikat będzie zawierał
informację o rozpatrzeniu reklamacji lub informację o konieczności przesunięcia terminu
rozpatrzenia reklamacji. TP może przesunąć termin rozpatrzenia reklamacji maksymalnie do 12
dni kalendarzowych od dnia przyjęcia zgłoszenia reklamacji. W razie uznania reklamacji TP
realizuje zamówienie migracji zgodnie z datą wymaganą wskazaną na Zamówieniu Operatora
100
Biorcy lub TP winna wskazać najbliższą możliwą datę realizacji Zamówienia i potwierdzić ją
Operatorowi.
W przypadku uwzględnienia reklamacji dotyczącej NWT zamówienia Number Portability, Operator
Biorca składa nowe zamówienie
Komunikat odpowiedzi na zgłoszenie reklamacji będzie taki sam jak w punkcie „10.1.3
Komunikat odpowiedzi na zgłoszenie reklamacji” czyli COMPLAIN-MIGRATION-TO-SERVICEREPLY-PACKAGE.
Komunikat będzie zawierał informację o rozpatrzeniu reklamacji lub informację o konieczności
przesunięcia terminu rozpatrzenia reklamacji. TP może przesunąć termin rozpatrzenia reklamacji
maksymalnie do 12 dni kalendarzowych od dnia przyjęcia zgłoszenia reklamacji.
10.2.4. Komunikat potwierdzenia odpowiedzi na zgłoszenie reklamacji
technicznej
Po odczytaniu przez system Operatora odpowiedzi na zgłoszenie reklamacji Migracji i
sprawdzeniu formalnym struktury pliku system Operatora utworzy komunikat potwierdzenia
odebrania odpowiedzi na zgłoszenie reklamacji taki sam jak w punkcie „10.1.4 czyli COMPLAINMIGRATION-TO-SERVICE-REPLY-PACKAGE-ACK.
101
11. Specyfikacja komunikatów awaryjnych
Awarie na poziomie aplikacji, komunikaty nie dające się odczytać lub wyłączenia systemu
spowodowane pracami konserwacyjnymi zostaną obsłużone komunikatem ABORT. Również w
przypadku zgłoszenia awarii systemu przez Operatora, kanał komunikacyjny dla Operatora w
systemie komunikacji zostanie ustawiony w stan blokady polegający na odpowiadaniu
komunikatem ABORT na wszystkie komunikaty od Operatora.
Po otrzymaniu komunikatu ABORT w odpowiedzi na komunikat od Operatora, Operator będzie
musiał ponowić swój komunikat po usunięciu awarii, blokady lub poprawie błędów w
komunikacie.
Na analogicznych zasadach komunikat ABORT może być wysłany przez system komunikacji
Operatora.
11.1. Komunikat ABORT
Komunikat informacji o przerwaniu przyjęcia komunikatu zgłoszonego do systemu komunikacji.
System komunikacji -> Operator
Komunikat jest tworzony w odpowiedzi na komunikat zgłoszony do systemu komunikacji, dla
którego nastąpiło przerwanie przetwarzania. Powodami przerwania przetwarzania są:
• 1 - Niepoprawny format komunikatu
•
2 - Awaria systemu lub inny błąd przyjęcia powodujący przerwanie przyjęcia
•
13 - Podmiot żądający nie jest zarejestrowany lub nie ma uprawnień
•
17 - Nie można rozkodować wiadomości (dla komunikatów przesyłanych zakodowanym email)
•
18 - Nieprawidłowy numer sesji
Odpowiedź ABORT oznacza, że system komunikacji nie zarejestrował zgłoszenia w swojej bazie.
Komunikat może wystąpić jako odpowiedź do każdego zgłaszanego komunikatu do systemu
komunikacji.
Nazwa pola
Typ
Opis
Czy
wymagany?
MSG-HEADER
Rekord
TAK
INTERACTION-ID
INT-ID
TAK
SUBJECT-ID
CHAR(40)
TAK
DEST-SUBJECT-ID
CHAR(40)
NIE
TEST-VER
INT(1)
TAK
ABORT
Rekord
ABORT-REASON
INT(4)
MSG
TAK
Powód przerwania przyjęcia komunikatu
1 – Niepoprawny format komunikatu
2 – Awaria systemu lub inny błąd przyjęcia
13 – Podmiot żądający nie jest
zarejestrowany lub nie ma uprawnień
17 – Nie można rozkodować wiadomości
18 – Nieprawidłowy numer sesji
TAK
NIE
102
Rekord
nadrzędny
Przykładowy XML:
<msg-header>
</msg-header>
<abort>
<abort-reason>1</abort-reason>
<msg>Niepoprawny format komunikatu</msg>
</abort>
</cbnp-message>
103
12. Kody odrzuceń dla korelacji i przejść pomiędzy
Operatorami
12.1. Kody odrzuceń – weryfikacja informatyczna
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
1 - Niepoprawny format komunikatu
10 - Nieprawidłowy Operator zgłaszający
13 - Operator Biorca/ Dawca nie jest uprawniony do realizacji zamówienia
17 - Nie można rozkodować wiadomości
20 - Brak specyfikacji dla WLR ISDN lub występuje dla WLR POTS
169 - Brak identyfikatora operatora lub niewłaściwy identyfikator
108 - Błąd w formacie numeru telefonu (brak lub za mało cyfr)
166 - Błąd w formacie ID_łącza (brak lub za mało cyfr)
167 - Brak wypełnionego pola adres
111 - Błędna data wygenerowania odpowiedzi
148 - Anulowanie na tym etapie nie jest możliwe
168 - Brak planowanej daty uruchomienia usługi
402 - Podana data nie przypada na dzień roboczy
152 – Brak zgody PT do przetwarzania danych osobowych Abonenta
12.2. Kody weryfikacji formalnej
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
270 - Rezygnacja nie została złożona na wszystkie usługi
271 - Wskazany operator nie świadczy takiej usługi
272 - Na tym ID łącza/ numerze telefonu nie ma takiej usługi
212 - Błąd w formacie numeru telefonu (za mało cyfr, niepełny numer) lub nieczytelny
232 - Zamówienie od Operatora już wpłynęło do TP i jest w trakcie procesowania
273 - Realizowane jest zamówienie na powiązaną usługę hurtową
220 - Realizowane jest zamówienie na cesję złożone przez Abonenta
221 - Realizowane jest zamówienie na przeniesienie numeru do innego Operatora
275 - Realizowane jest zamówienie na usługę szerokopasmową /wąskopasmową. dla innego
operatora
227 - Realizowane jest zamówienie zmiany numeru
228 - Realizowane jest zamówienie zmiany lokalizacji
223 - Realizowane jest zamówienie na LLU
261 - Realizowane jest inne zamówienie modyfikacji dla tego numeru
269 - Realizowana jest rezygnacja z powiązanej usługi
148 - Anulowanie na tym etapie nie jest możliwe
276 - Brak takiego zamówienia powiązanego z rezygnacją
277 - Brak pełnych danych odnośnie kabla korespondencyjnego (nr kabla, nr pary w kablu
korespondencyjnym)
278 - Na Zamówieniu jest więcej niż jeden numer telefonu
279 - Łącze ISDN PRA (dla zamówienia na dostęp współdzielony)
280 - Brak technicznego dostępu do PG
281 - Brak lub błędny format numeru RN na zamówieniu z opcją przeniesienia numeru
290 - Zamówienie migracji dot. łącza na którym jest usługa detaliczna TP
402 - Podana data nie przypada na dzień roboczy
407 – Błędny RN przypisany do Operatora
274 - Podana data nie mieści się w ustalonym przedziale czasowym 21 DR- 120 dni kalendarzowych
104
•
•
406 – Brak lub błędne dane w komunikacie
237 - Usługa WLR w podanej strefie numeracyjnej jest niedostępna
12.3. Kody weryfikacji formalnej Dawca- TP
•
•
•
•
•
282 - Nie ma usługi pod wskazanym adresem
283 - Nie ma usługi dla danego Abonenta / nie świadczy usługi dla danego Abonenta
284 - Nie ma usługi na tym numerze telefonu/ Numerze ID
285 - Nie wpłynęła do Dawcy pisemna rezygnacja Abonenta / Dawca nie potwierdza otrzymania
rezygnacji od Abonenta
241 – Negatywne Warunki techniczne Operatora Macierzystego (np. błędny RN)
12.4. Kody odpowiedzi TP do Biorcy/Dawcy dotyczące weryfikacji
formalnej i technicznej
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
286 - Dawca nie potwierdza umowy na usługę / Dawca nie świadczy usługi dla danego Abonenta
287 - Dawca wskazuje datę dłuższą niż wymagana data
288 - Dawca nie potwierdza instalacji usługi pod wskazanym adresem
289 - Dawca odmawia realizacji z powodu rezygnacji klienta
285 - Nie wpłynęła do Dawcy pisemna rezygnacja Abonenta / Dawca nie potwierdza otrzymania
rezygnacji od Abonenta
256 - Brak możliwości technicznych
291 - Łącze nie podlega uwolnieniu (łącze dzierżawione, łącze do PAS, na łączu zainstalowane są
numery alarmowe).
235 - Łącze nie należy do TP (współdzielnie)
298 - Przeciążone PDU
292 - Parametry linii nie spełniają wymagań dla zamawianej opcji/ wersji (usługa nie może być
uruchomiona w zamawianej prędkości).
293 - Technologia budowy łącza nieprzewidziana do uwolnienia
294 - Łącze przyłączone do PABX (dla zamówienia na dostęp współdzielony)
260 - Brak dostępu do lokalu
296 - Numer główny jest w PABX/ Centrex
297 - Dawca nie ma usługi na tym numerze telefonu/ Numerze ID
403 – Brak splittera / Brak wolnych portów na spliterze
241 – Negatywne Warunki techniczne Operatora Macierzystego (np. błędny RN)
404 – Nieprawidłowe PG/PPD – zasób z PG/PPD…
12.5. Kody związane z rezygnacją Abonenta otrzymaną od
Dawcy/ Biorcy
•
•
230 - Biorca rezygnuje z realizacji zlecenia z powodu rezygnacji przez Abonenta
219 - Wpłynęła rezygnacja do Dawcy spełniająca wymagania formalne
105
13. Kody odrzuceń dla informacji o usługach
hurtowych
•
•
•
•
•
•
•
•
•
1 - Niepoprawny format komunikatu
13 - Podmiot żądający nie jest zarejestrowany lub nie ma uprawnień
17 - Nie można rozkodować wiadomości
169 - Brak identyfikatora operatora lub niewłaściwy identyfikator
108 - Błąd w formacie numeru telefonu (brak lub za mało cyfr)
166 - Błąd w formacie ID_łącza / ID Usługi (brak lub za mało cyfr)
167 - Brak wypełnionego pola adres
106
14. Kody odrzuceń dla reklamacji
14.1. Negatywna weryfikacja informatyczna w BNP - Kody
odrzucenia reklamacji przez BNP
•
•
•
•
•
•
•
•
•
•
•
128 - Brak lub błędna data przesłania reklamacji
106 - Brak lub niewłaściwy identyfikator Operatora,
210 - Brak lub błędny numer telefonu na Zamówieniu
401 - Brak lub błędny ID usługi na Zamówieniu
129 - Brak lub błędny numer reklamacji,
109 - Brak lub błędny ID zamówienia ,
170 - Brak lub błędny typ reklamacji (formalna/techniczna),
131 - Niepoprawny kod przedmiotu reklamacji ,
171 - Brak uzasadnienia reklamacji
354 - Reklamacja zgłoszona po wymaganym terminie
130 - Brak lub błędna nazwa lub adres klienta.
•
14.2. Negatywny wynik rozpatrzenia Reklamacji - Kody
odrzucenia reklamacji
•
•
•
•
•
•
210 - Brak lub błędny numer telefonu na Zamówieniu
401 - Brak lub błędny ID usługi / ID Łącza na Zamówieniu
109 - Brak lub błędny ID zamówienia
170 - Brak lub błędny typ reklamacji,
131 - Niepoprawny kod przedmiotu reklamacji ,
354 - Reklamacja zgłoszona po wymaganym terminie
14.3. Wynik rozpatrzenia reklamacji
•
•
•
•
1 - Decyzja pozytywna
2 - Decyzja negatywna
3 - Reklamacja częściowo uznana
4 - TP nie jest stroną do rozpatrzenia reklamacji
14.4. Przedmiot Reklamacji
•
•
•
•
•
1 - Negatywna Weryfikacja Formalna
2 - Negatywny wynik weryfikacji technicznej
3 - Brak/ niewłaściwa realizacja zamówienia migracji,
4 - Odmowa realizacji zamówienia migracji przez TP,
5 - Brak anulowania zamówienia migracji przez TP
107