ISI. funkcjonalność. szkolenie dla Operatorów Alternatywnych/ Detal TP. Warszawa, r.

Transkrypt

1 ISI funkcjonalność szkolenie dla Operatorów Alternatywnych/ Detal TP Warszawa, r.

2 kontrakt czas trwania: przerwy: pytania: telefony: 6 godzin 15 do 30 min proszę zadawać w trakcie prezentacji proszę wyłączyć dzwonki, jeśli to konieczne - odbierać poza salą 2

3 agenda I funkcjonalności ISI faza 1 i 2 10:00 11:00 II funkcjonalności ISI faza 3 11:15 12:15 III procesy: część I 12:45 14:00 procesy: część II 14:15 16:00 pytania 16:00 16:30 3

4 I funkcjonalności ISI faza 1 i 2 4

5 I.1 informacje o ISI 5

6 informacje o ISI co to jest ISI? ISI Interfejs Systemów Informatycznych jest narzędziem informatycznym słuŝącym wymianie informacji i danych w zakresie usług regulowanych pomiędzy TP Hurt a Operatorami Alternatywnymi (OA) i Detalem TP dla kogo przeznaczony jest ISI? ISI przeznaczony jest dla uŝytkowników ze strony Operatorów Alternatywnych (OA) i Detalu TP, odpowiedzialnych za wymianę informacji z TP Hurt 6

7 informacje o ISI podstawy prawne Podstawy funkcjonowania ISI wynikają z Porozumienia z dn r. zawartego pomiędzy TP SA a UKE, dotyczącego regulacji współpracy pomiędzy TP SA a Operatorami Alternatywnymi/Detal TP zasady funkcjonowania ISI Wymagania co do funkcjonalności ISI jako narzędzia współpracy zawarte są w Załączniku 7 do Porozumienia Porozumienie i Załącznik nr 7: Porozumienie Załącznik 7 7

8 informacje o ISI jak moŝna korzystać z ISI? ISI jest aplikacją internetową, dostępną dla OA/Detal TP przez przeglądarkę pod adresem 8

9 informacje o ISI ISI obecnie udostępnia: Informacje Ogólne (IO), oraz raporty KPI, publikowane przez TP Hurt - dokumenty dostępne są do pobrania w repozytorium dokumentów ISI. interfejs do obsługi abonenckich usług hurtowych BSA, LLU, WLR zgodnie z Modelem Współpracy Międzyoperatorskiej - za pośrednictwem formularzy w Portalu ISI wymianę danych we wszystkich typach procesów pomiędzy systemami Operatorów a TP Hurt za pośrednictwem EKWD ( ) oraz WebSerwisów 9

10 informacje o ISI wymagania wobec uŝytkowników portalu ISI zalecana przeglądarka internetowa FireFox (v.3.6 +) zalecany program do kompresji / dekompresji 7Zip wymagania do integracji systemów z ISI EKWD: obsługa wiadomości z szyfrowaniem PGP WS: serwer Webservice z WSDL zgodnym z WSDL ISI 10

11 informacje o ISI dostęp do danych OA system uprawnień i certyfikatów SSL zapewnia ochronę danych przeznaczonych dla konkretnego OA nie istnieje moŝliwość wglądu w dane innego Operatora bezpieczeństwo danych dane i pliki dostępne są jedynie tylko poprzez zabezpieczone imiennymi certyfikatami SSL sesje https, brak innego dostępu spoza sieci TP Hurt infrastruktura dane przechowywane w bezpiecznej sieci korporacyjnej, na zduplikowanej infrastrukturze technicznej 11

12 informacje o ISI rozbudowany system ról i uprawnień wysokie wymagania na autoryzację dostępu do funkcjonalności i danych, z kontrolą przekazaną w ręce administratorów ze strony operatorów certyfikaty SSL serwerów i uŝytkowników generowane przez system certyfikaty SSL z wysokimi wymogami bezpieczeństwa podczas instalacji i uŝycia, z moŝliwością anulowania / wygaszenia certyfikaty PGP wiadomości do i od operatorów muszą być podpisane i zaszyfrowane przy uŝyciu kluczy PGP 12

13 I.2 funkcjonalności ISI 1 13

14 funkcjonalności ISI 1 istniejące procesy biznesowe w ramach komunikacji pomiędzy OA, Detalem TP a TP Hurt, następuje udostępnienie Informacji Ogólnych i wskaźników KPI dotyczących usług i abonentów OA/Detal TP ISI w komunikacji wychodzącej z TP Hurt W procesach TP Hurt, ISI jest miejscem publikacji Informacji Ogólnych dla wszystkich operatorów i Detalu TP oraz informacji na temat wskaźników KPI zleceń dla poszczególnych OA ISI w procesach biznesowych OA dla wszystkich OA/Detal TP, ISI jest miejscem odbioru Informacji Ogólnych i wskaźników KPI z TP Hurt, oraz narzędziem do załączania dokumentów w procesie zapytań do KPI 14

15 funkcjonalności ISI 1 Informacje Ogólne katalog z plikami dla wszystkich operatorów Informacje indywidualne katalog do wymiany informacji nt wskaźników KPI operatora z TP Hurt trwałość pełna dostępność plików z okresu 1 roku bezpieczeństwo uprawnienia OA tylko do dedykowanych dla niego folderów 15

16 funkcjonalności ISI 1 ekran powitalny 16

17 funkcjonalności ISI 1 logowanie uŝytkowników OA 17

18 funkcjonalności ISI 1 pobieranie plików przeznaczonych dla OA 18

19 funkcjonalności ISI 1 pobieranie plików przeznaczonych dla OA 19

20 funkcjonalności ISI 1 umieszczanie plików OA / Detal TP dla TP 20

21 funkcjonalności ISI 1 potwierdzenie umieszczonego pliku 21

22 funkcjonalności ISI 1 notyfikacje owe notyfikacje mailowe o nowych plikach, wysyłane na dedykowany adres podany przez Operatora dla kaŝdego operatora tworzona jest jedna lista plików, które pojawiły się w dostępnych dla Operatora folderach, od czasu ostatniego wysłania notyfikacji mailowej 22

23 I.3 funkcjonalności ISI 2 23

24 funkcjonalności ISI 2 MWM Model Współpracy Międzyoperatorskiej regulacja dotycząca podstaw funkcjonowania ISI oraz zakresu obsługiwanych procesów załącznik nr 2 do Porozumienia MRP Model Realizacji Procesów szczegółowe modele realizacji procesów objętych MWM dostępny w wersji 1.6 MWD Model Wymiany Danych definicja sposobu, formatu i wymagań wobec wymienianych w procesach MRP danych dostępny obecnie w wersji

25 funkcjonalności ISI 2 modele definiują sposób przeprowadzania procesów biznesowych i zakres wymienianych danych słuŝących do realizacji Porozumienia międzyoperatorskiego w zakresie źródła informacji o modelu: dokumentacja MWD dla MWM w aktualnej wersji schemat XSD dla dokumentów MWD (na potrzeby integracji systemów OA z ISI) 25

26 funkcjonalności ISI 2 zawartość dokumentacji MWD dla MWM: ustalenia ogólne komunikacji format komunikatów i typy danych metody wymiany komunikatów ogólny model współdziałania w ramach MWD dla MWM opis zawartości komunikatów dla poszczególnych procesów specyfikacje komunikatów słowniki statusów i kodów błędów 26

27 funkcjonalności ISI 2 typy realizowanych operacji w ramach procesów: zapytania o usługi zamówienia usług zmiany usług obsługa reklamacji i uszkodzeń 27

28 28 Proces Proces Interakcja Interakcja funkcjonalności ISI 2 Dokument Dokument Komunikat Komunikat nagłówek nagłówek Dokument Dokument Komunikat Komunikat nagłówek nagłówek Interakcja Interakcja Dokument Dokument Komunikat Komunikat nagłówek nagłówek Dokument Dokument Komunikat Komunikat nagłówek nagłówek Interakcja Interakcja Dokument Dokument Komunikat Komunikat nagłówek nagłówek Dokument Dokument Komunikat Komunikat nagłówek nagłówek

29 funkcjonalności ISI 2 przykład prostego modelu procesu zapytanie o usługi 2 interakcje (1. i 2.), 4 dokumenty i 4 komunikaty. 29

30 funkcjonalności ISI 2 walidacja komunikatów fizyczna poprawność formatu XML komunikatu, wykonywana online przez aplikację ISI informatyczna zgodność ze schematem XSD dla MWD, wykonywana online przez aplikację ISI biznesowa zgodność z biznesowymi regułami budowania i wypełniania komunikatów, weryfikowana offline przez silnik regułowy aplikacji ISI na podstawie schematronu MWD 30

31 funkcjonalności ISI 2 nazwy komunikatów nazwy biznesowe uŝyte w MWD: Informacja o zainstalowanych usługach na aktywnym łączu abonenckim nazwy techniczne uŝyte w XSD dla MWD SERVICE-QUERY-RESULT-I niektóre typy komunikatów są reuŝywane w róŝnych procesach 31

32 funkcjonalności ISI 2 scenariusze interakcji : poprawny OA rozpoczyna interakcję poprawnie zbudowanym komunikatem biznesowym TP wysyła potwierdzenie przyjęcia komunikatu (komunikat ACK, z polem acc-status = 0) Interakcja 1: zapytanie a: Zapytanie o aktywne usługi na ŁAA SERVICE-QUERY-I b: Potwierdzenie przyjęcia komunikatu zapytania o usługi na łączu SERVICE-QUERY-I-ACK 32

33 funkcjonalności ISI 2 identyfikator interakcji interaction-id nadawane przez stronę rozpoczynającą interakcję w odpowiedzi uŝywany numer interakcji z oryginalnego zapytania budowa numeru: piętnaście cyfr z wiodącymi zerami: pięć cyfr identyfikatora operatora plus dziesięć cyfr system ISI przy wypełnianiu dokumentów wspiera generację kolejnych numerów interakcji dla kaŝdego z operatorów (konfigurowalna przez administratorów ECM pula numerów) 33

34 funkcjonalności ISI 2 scenariusze interakcji : błąd biznesowy OA rozpoczyna interakcję komunikatem biznesowym poprawnym informatycznie, ale niekompletnym biznesowo TP wysyła odmowę przyjęcia komunikatu (komunikat ACK, z polem acc-status = 1 oraz przyczyną odrzucenia) Interakcja 1: zapytanie a: Zapytanie o aktywne usługi na ŁAA SERVICE-QUERY-I b: Odrzucenie przyjęcia komunikatu zapytania o usługi na łączu SERVICE-QUERY-I-ACK 34

35 funkcjonalności ISI 2 scenariusze interakcji : błąd techniczny OA rozpoczyna interakcję komunikatem biznesowym niepoprawnym pod względem technicznym (niepoprawny XML) TP wysyła techniczne odrzucenie przyjęcia komunikatu (komunikat ABORT) Interakcja 1: zapytanie a: Zapytanie o aktywne usługi na ŁAA SERVICE-QUERY-I b: Odrzucenie techniczne komunikatu ABORT 35

36 funkcjonalności ISI 2 proces reprezentacja procesu MRP: proces obsługowy, zmiany statusów przetwarzania procesu, powiązane z nim interakcje i dokumenty elementy składowe procesu statusy procesu, reprezentujące kolejne etapy komunikacji TP z OA w trakcie procesu (interakcje przychodzące i wychodzące z procesu) uczestnicy procesu i ich role operator inicjujący / biorca inicjujący proces, posiadający wgląd w cały przebieg procesu operator dawca (jeden bądź więcej) dołączający do procesu w trakcie w związku z przekazaniem usługi / usług do innego operatora TP Hurt operator hurtowy, wykonujący w ramach procesu operacje w systemach hurtowych i sterujący komunikacją 36

37 funkcjonalności ISI 2 powiązanie komunikat interakcja proces identyfikatory: interaction-id order-number Dokument nagłówek Interakcja Komunikat Dokument nagłówek Proces Dokument Interakcja nagłówek Komunikat Dokument nagłówek Interakcja Komunikat Komunikat Dokument Dokument nagłówek Komunikat nagłówek Komunikat 37

38 funkcjonalności ISI 2 przeglądanie komunikatów - lista 38

39 funkcjonalności ISI 2 przeglądanie komunikatów widok dokumentu (wersja testowa) 39

40 funkcjonalności ISI 2 tworzenie komunikatów wybór typu komunikatu 40

41 funkcjonalności ISI 2 tworzenie komunikatów wypełnianie formularza (wersja testowa) 41

42 funkcjonalności ISI 2 przeglądanie interakcji - lista 42

43 funkcjonalności ISI 2 przeglądanie interakcji - zawartość 43

44 funkcjonalności ISI 2 przeglądanie procesów - lista 44

45 funkcjonalności ISI 2 przeglądanie procesów proces, statusy 45

46 II funkcjonalności ISI 3 46

47 II.1 zmiany w modelu komunikacji 47

48 zmiany w modelu komunikacji Pliki załączane do komunikatów: ISI 3 daje moŝliwość dodawania do komunikatów biznesowych załączników w postaci plików binarnych (dokumenty, skany, PDFy) Pliki są przesyłane w ramach i przechowywane razem z interakcjami (zarówno przez OA jak i TP Hurt) Pliki są widoczne równieŝ w procesach których dotyczą (zgodnie z uprawnieniami operatorów do procesów) Nowe obszary funkcjonalne ISI: ROI RIO RLLO BSA 48

49 zmiany w modelu komunikacji Interakcja Dokument REQ nagłówek Komunikat biznesowy Dokument ACK nagłówek Komunikat ACK Dokument ATTACHMENT Dokument ATTACHMENT Dokument ATTACHMENT nagłówek Komunikat Załącznik binarny 49

50 zmiany w modelu komunikacji plik dokument binarny (doc, pdf, xls) załącznik zestaw spakowanych plików do przesłania moŝliwości funkcjonalne ISI dla plików i załączników dodawanie plików do formularzy dokumentów przesyłanie załączników przez WebService i kanałem EKWD ( ) pobieranie plików załączonych do interakcji i procesów 50

51 zmiany w modelu komunikacji pliki binarne w ISI 3 albo są przesyłane do systemu w załącznikach w ramach interakcji wraz z wiadomościami typu ATTACHMENT (kanały EKWD i WS), rozpakowywane i dołączane do interakcji mogą być dodawane bezpośrednio do nowo tworzonych formularzy w interakcjach na portalu ISI Nie wszystkie formularze pozwalają na dołączenie plików! W treści dokumentów typu REQ w interakcjach z załącznikami muszą być wymienione z nazwy załączane pliki podlega to walidacji biznesowej (lista zadeklarowana w dokumencie REQ musi odpowiadać liście plików po rozpakowaniu / załączeniu 51

52 zmiany w modelu komunikacji wiadomość typu ATTACHMENT typ wiadomości słuŝącej do przesyłania załączników dodatkowe pola w nagłówku: ilość paczek z załącznikami w interakcji, kolejny numer paczki z załącznikiem do jednej wiadomości REQ moŝe pojawić się dowolna liczba wiadomości ATTACHEMENT wiadomości w interakcji z załącznikami określają w nagłówku liczbę paczek z załącznikami wiadomości REQ i powiązane ATTACHEMENT mogą być przesyłane w dowolnej kolejności załącznik a plik załącznik ma znaczenie komunikacyjne przesyłany jest (w formie spakowanej (ZIP, ZIP w częściach) lub bez pakowania) wraz z komunikatem ATTACHEMENT, zawiera pliki, jest przypisany do interakcji plik jest bytem biznesowym zawartością rozpakowanego załącznika 52

53 zmiany w modelu komunikacji przykład komunikatu z załącznikami przychodzącego do (WS lub EKWD) wiadomość REQ z zawartością biznesową <soapenv:envelope xmlns:soapenv=" xmlns:typ=" <soapenv:header/> <soapenv:body> <typ:documentrequest> <cbnp-message:cbnp-message xmlns:cbnp-message=" <msg-header xmlns=" <interaction-id>[id interakcji]</interaction-id> <subject-id>[uke id nadawcy]</subject-id> <dest-subject-id>[uke id odbiorcy]</dest-subject-id> <msg-ver>rio;1</msg-ver> <test-ver>0</test-ver> <state>req</state> <package-quantity>2</package-quantity> </msg-header> <pss-installation-inspection-order xmlns=" [zawartość biznesowa komunikatu] </pss-installation-inspection-order> </cbnp-message:cbnp-message> </typ:documentrequest> </soapenv:body> </soapenv:envelope> 53

54 zmiany w modelu komunikacji przykład komunikatu z załącznikami przychodzącego do (WS lub EKWD) wiadomość ATTACHEMENT z załącznikiem nr 1 <soapenv:envelope xmlns:soapenv=" xmlns:typ=" <soapenv:header/> <soapenv:body> <typ:documentrequest> <cbnp-message:cbnp-message xmlns:cbnp-message=" <msg-header xmlns=" <subject-id>[uke id nadawcy]</subject-id> <test-ver>0</test-ver> <interaction-id>[id interakcji]</interaction-id> <dest-subject-id>[uke id odbiorcy]</dest-subject-id> <msg-ver>rio;1</msg-ver> <state>attachment</state> <package-quantity>2</package-quantity> <package-number>1</package-number> </msg-header> <cbnp-message:attachments> <cbnp-message:attachment> <cbnp-message:file-name>test.zip.001</cbnp-message:file-name> <cbnp-message:file-size>24072</cbnp-message:file-size> <cbnp-message:checksum>[suma kontrolna MD5]</cbnp-message:checksum> <cbnp-message:href>cid:[id załącznika w WS]</cbnp-message:href> </cbnp-message:attachment> </cbnp-message:attachments> </cbnp-message:cbnp-message> </typ:documentrequest> </soapenv:body> </soapenv:envelope> 54

55 zmiany w modelu komunikacji przykład komunikatu z załącznikami przychodzącego do (WS lub EKWD) wiadomość ATTACHEMENT z załącznikiem nr 2 <soapenv:envelope xmlns:soapenv=" xmlns:typ=" <soapenv:header/> <soapenv:body> <typ:documentrequest> <cbnp-message:cbnp-message xmlns:cbnp-message=" <msg-header xmlns=" <subject-id>[uke id nadawcy]</subject-id> <test-ver>0</test-ver> <interaction-id>[id interakcji]</interaction-id> <dest-subject-id>[uke id odbiorcy]</dest-subject-id> <msg-ver>rio;1</msg-ver> <state>attachment</state> <package-quantity>2</package-quantity> <package-number>2</package-number> </msg-header> <cbnp-message:attachments> <cbnp-message:attachment> <cbnp-message:file-name>test.zip.002</cbnp-message:file-name> <cbnp-message:file-size>12034</cbnp-message:file-size> <cbnp-message:checksum>[suma kontrolna MD5]</cbnp-message:checksum> <cbnp-message:href>cid:[id załącznika w WS]</cbnp-message:href> </cbnp-message:attachment> </cbnp-message:attachments> </cbnp-message:cbnp-message> </typ:documentrequest> </soapenv:body> </soapenv:envelope> 55

56 zmiany w modelu komunikacji ogólny schemat przebiegu procesu inicjowanego przez OA rozpoczęcie procesu OA: nowa interakcja OA: komunikat inicjujący proces OA: komunikat(y) z załącznikami TP: ack do komunikatu TP: start procesu ORDER ATTACHMENT ATTACHMENT ACK 56

57 zmiany w modelu komunikacji komunikat wychodzący z procesu do OA TP: przetwarzanie i przejście stanu w procesie TP: nowa interakcja i komunikat do OA TP: komunikat(y) z załącznikami OA: ack do komunikatu MESSAGE ATTACHMENT ACK 57

58 zmiany w modelu komunikacji zakończenie procesu TP: przejście stanu w procesie TP: komunikat do OA TP: komunikat(y) z załącznikami TP: zakończenie procesu ATTACHMENT OA: ack MESSAGE ATTACHMENT ACK 58

59 II.2 obsługa ISI 3 59

60 obsługa ISI 3 dodawanie plików binarnych w portalu 60

63 obsługa ISI 3 widok listy dokumentów 63

64 obsługa ISI 3 widok listy dokumentów nowe pola: obszar i wersja MWD np. ROI 1.0 liczba załączników zadeklarowanych i dostarczonych przy rozmiarach załączników (zip) przekraczających 10 MB naleŝy dokonać podziału załączników i przesyłać je oddzielnymi wiadomościami w tej samej interakcji kaŝdy dokument interakcji w nagłówku powinien deklarować ilość załączników oraz w wypadku wiadomości zawierających załączniki określać którą kolejną część załączników zawiera 64

65 obsługa ISI 3 widok dokumentu zawartość biznesowa (wersja testowa) 65

66 obsługa ISI 3 wczytywanie dokumentu do ISI 66

69 obsługa ISI 3 dodanie plików do dokumentu 69

70 obsługa ISI 3 lista interakcji 70

71 obsługa ISI 3 widok interakcji 71

72 obsługa ISI 3 interakcja zawartość w ISI 3 dokument biznesowy dokument potwierdzenia lista dokumentów załączników pokaŝ informacje o załącznikach pobierz załącznik (zip) lista plików interakcji nazwa i rozmiar pliku pobierz plik 72

73 II.3 przykład 73

74 74 przykład

75 75 przykład

76 76 przykład

77 77 przykład

78 78 przykład

79 przykład 79

80 80 przykład

81 (wersja testowa) 81 przykład

82 30 minut przerwy 82

83 III procesy 83

84 III.1 RLLO 84

85 proces: RLLO Ustalenia ogólne Dzień wpływu zgłoszeń i zamówień w dni robocze jest dniem zerowym T-0. Zamówienia przesłane w dni wolne od pracy oraz w dni świąteczne są zaliczane na poczet następnego dnia roboczego - T0. Wszystkie komunikaty przesyłane kanałami elektronicznemu będą podlegały wstępnej weryfikacjom: Informatycznej przedwstępnej Weryfikacja czy OA ma uprawnienia do komunikacji kanałem przychodzącym Weryfikacja czy komunikat jest moŝliwy do odszyfrowania i odczytania Weryfikacja czy komunikat posiada prawidłowe InteractionID Informatycznej Weryfikacja wersji MWD oraz jej zgodności przesłanego komunikatu Weryfikacja czy komunikat posiada wymagane pola Weryfikacja czy pola komunikatu mają prawidłowy format techniczny Formalnej Weryfikacja danych biznesowych zawartych w komunikacie Błędy w powyŝszych weryfikacjach będą oznaczane kodami odrzuceń 85

86 proces: RLLO ZłoŜenie zamówienia na Usługę / Modyfikację Usługi Przebieg procesu - ZłoŜenie zamówienia na Usługę / Modyfikację Usługi Operator składa do TP zamówienia w formie elektronicznej na: - łącze dzierŝawione, - zmianę miejsca zakończenia łącza dzierŝawionego, - modyfikację parametrów łącza dzierŝawionego. TP, dokonuje weryfikacji formalnej Zamówienia. W przypadku gdy Zamówienie posiada braki formalne, do OA wysyłany jest komunikat o jego odrzuceniu ze wskazaniem powodu odrzucenia TP, dokonuje weryfikacji formalnej Zamówienia. W przypadku gdy Zamówienie jest wolne od braków formalnych, do OA wysyłany jest komunikat systemowy. 86

87 proces: RLLO ZłoŜenie zamówienia na Usługę / Modyfikację Usługi Zamówienie RLLO OA Potwierdzenie przyjęcia zamówienia Negatywna weryfikacja formalna TP HURT Potwierdzenie przyjęcia komunikatu 87 koniec procesu

88 proces: RLLO Odpowiedź na zamówienie Usługi Przebieg procesu - Odpowiedź na zamówienie Usługi TP udziela odpowiedzi na Zamówienie na Usługę (WT) w terminie do 5 DR od dnia jego otrzymania, informując Operatora o : MoŜliwości realizacji Usługi określonej w Zamówieniu na Usługę, Braku moŝliwości realizacji Usługi określonej w Zamówieniu na Usługę wraz z uzasadnieniem oraz podaniem powodów braku moŝliwości realizacji tej Usługi. MoŜliwości realizacji Usługi określonej w Zamówieniu na Usługę w sposób alternatywny (RA - rozwiązanie alternatywne), Informację o opracowywaniu rozwiązania alternatywnego 88

89 proces: RLLO Odpowiedź na zamówienie Usługi Wydane Pozytywne WT Przejście do procesu przygotowania Umowy Szczegółowej (US) OA Lub Wydane Rozwiązanie Alternatywne (RA) Przejście do procesu potwierdzenia WT Lub Przekazanie informacji - RA w opracowaniu TP HURT Przejście do procesu opracowanie RA Potwierdzenie przyjęcia komunikatu 89

90 proces: RLLO Przekazanie propozycji RA do Operatora Przebieg procesu - Przekazanie propozycji RA do Operatora TP, w terminie do 14 dni od dnia udzielenia odpowiedzi na Zamówienie Usługi, przekaŝe Operatorowi szczegółowy opis realizacji rozwiązania alternatywnego, zawierający warunki dodatkowe związane z uzyskaniem moŝliwości świadczenia Usługi (w tym termin realizacji Usługi) oraz zestawienie kosztów takiego rozwiązania. W przypadku braku moŝliwości realizacji Usługi określonej w Zamówieniu na Usługę, w odpowiedzi na Zamówienie na Usługę, TP informuje Operatora o: MoŜliwości realizacji Usługi określonej w Zamówieniu na Usługę w sposób alternatywny (rozwiązanie alternatywne), Braku moŝliwości realizacji Usługi określonej w Zamówieniu na Usługę równieŝ w sposób alternatywny wraz z uzasadnieniem oraz podaniem powodów braku moŝliwości realizacji Usługi w sposób alternatywny. 90

91 proces: RLLO Przekazanie propozycji RA do Operatora Wydane Rozwiązanie Alternatywne OA Przejście do procesu potwierdzenia WT Lub Przekazanie informacji o braku moŝliwości realizacji zamówienia Koniec procesu TP HURT Potwierdzenie przyjęcia komunikatu 91

92 proces: RLLO Akceptacja rozwiązania alternatywnego Przebieg procesu - Akceptacja rozwiązania alternatywnego Operator, od otrzymania stanowiska TP określającego szczegółowy sposób realizacji rozwiązania alternatywnego udziela TP odpowiedzi, w której akceptuje lub odrzuca zaproponowane przez TP warunki realizacji Usługi w sposób alternatywny. Nieudzielenie przez Operatora odpowiedzi na stanowisko TP w przewidzianym terminie jest traktowane jako brak zgody na realizację Zamówienia na Usługę w sposób alternatywny (odpowiedź negatywna). Jeśli OA nie akceptuje w terminie WT z RA, TP przesyła do OA poprzez ISI informację o anulowaniu zamówienia z określonego powyŝej powodu. 92

93 proces: RLLO Akceptacja rozwiązania alternatywnego Wydane Rozwiązanie Alternatywne =<3 DR OA Akceptacja RA Przejście do procesu zawarcia US Lub Brak akceptacji RA Koniec procesu Lub >3 DR Potwierdzenie anulowania zamówienia TP HURT Koniec procesu 93

94 proces: RLLO Przesłanie projektu Umowy Szczegółowej Przebieg procesu - Przesłanie projektu Umowy Szczegółowej W przypadku pozytywnej odpowiedzi na Zamówienie Usługi lub w przypadku pozytywnej odpowiedzi Operatora na przedstawione przez TP stanowisko określające szczegółowy sposób realizacji Zamówienia na Usługę w sposób alternatywny, TP przesyła do Operatora projekt Umowy Szczegółowej, dotyczący Usługi będącej przedmiotem Zamówienia. TP przesyła projekt umowy nie później niŝ w terminie 3 DR od udzielenia pozytywnej odpowiedzi na Zamówienie na Usługę przez TP lub w terminie 3 DR od otrzymania przez TP zgody Operatora na realizację Zamówienia na Usługę w sposób alternatywny 94

95 proces: RLLO Przesłanie projektu Umowy Szczegółowej Wydane Pozytywne WT / Akceptacja RA przez OA OA = < 3 DR Przekazanie informacji o wysłaniu Umowy Szczegółowej Przejście do procesu zawarcia US Potwierdzenie przyjęcia komunikatu TP HURT Wysłanie Umowy Szczegółowej (wersja papierowa) 95

96 proces: RLLO Podpisanie Umowy Szczegółowej Przebieg procesu - Podpisanie Umowy Szczegółowej OA jest zobowiązany do niezwłocznego podpisania Umowy Szczegółowej i dostarczenia jej do TP, jednak nie później niŝ w terminie 3 DR Jeśli OA nie przekazuje do TP poprzez ISI w terminie 3 DR podpisanej przez siebie umowy (skanu) TP na podstawie wewnętrznej decyzji moŝe poinformować OA o przedłuŝeniu terminu oczekiwania na podpisaną umowę. Nieudzielenie przez Operatora odpowiedzi na stanowisko TP w przewidzianym terminie jest traktowane jako brak zgody na realizację Zamówienia na Usługę (odpowiedź negatywna). 96

97 proces: Podpisanie Umowy Szczegółowej Przekazanie informacji o wysłaniu Umowy Szczegółowej OA Wysłanie Umowy Szczegółowej (wersja papierowa) =<3 DR Potwierdzenie akceptacji Umowy Szczegółowej Odesłanie podpisanej Umowy Szczegółowej TP HURT >3 DR Potwierdzenie anulowania zamówienia Koniec procesu 97

98 proces: Podpisanie Umowy Szczegółowej OA Odesłanie podpisanej Umowy Szczegółowej Potwierdzenie wpłynięcia Umowy Szczegółowej TP HURT Realizacja łącza 98

99 proces: RLLO Realizacja Łącza Przebieg procesu - Informacja o braku dostępu do zasobów OA Jeśli w trakcie inwestycji po stronie TP zaistnieje sytuacja braku dostępu do zasobów OA/lokalu TP informuje o tym do OA wysyłając komunikat. OA przesyła do TP informację o nowym terminie dostępności do zasobów po jego stronie/lokalu. Po aktywowaniu usługi TP, wysyła do OA informację o terminie testów. 99

100 proces: Realizacja Łącza Potwierdzenie wpłynięcia Umowy Szczegółowej OA Opcjonalnie Przesłanie informacji o braku dostępu do zasobów OA Przesłanie informacji o terminie dostępu do zasobów OA TP HURT Przekazanie terminu rozpoczęcia testów 100

101 proces: RLLO Przesłanie informacji o podpisaniu PZO Przebieg procesu - Przesłanie informacji o podpisaniu Protokołu Zdawczo Odbiorczego (PZO) TP wysyła do OA jednostronnie podpisany protokół zdawczo-odbiorczy (skan) do akceptacji. OA, ma prawo zgłosić uwagi do PZO podpisanego jednostronnie przez TP. Brak zgłoszenia uwag do PZO w terminie 3 DR oznacza przyjęcie przez OA łącza do eksploatacji 101

102 proces: Przesłanie informacji o podpisaniu PZO Przesłanie informacji o uruchomieniu łącza Załącznik Protokół Zdawczo Odbiorczy (PZO) OA Opcjonalnie w terminie do 3 DR Informacja o uwagach do PZO Przesłanie poprawionego PZO Załącznik Protokół Zdawczo - Odbiorczy Lub Przesłanie informacji o odrzuceniu uwag do PZO Koniec procesu TP HURT 102

103 III.3 przykłady 103

104 (wersja testowa) 104 przykład zamówienie RLLO

108 (wersja testowa) 108 przykład interakcja

109 przykład Odpowiedź na zamówienie na Usługę (wydane pozytywne WT) (wersja testowa) 109

110 III.2 ROI 110

111 proces: ROI ZłoŜenie zapytania Przebieg procesu - ZłoŜenie zapytania W celu ustalenia moŝliwości zawarcia Umowy, Operator moŝe wystąpić do TP z Zapytaniem o moŝliwość dostępu do kanalizacji kablowej. Jedno Zapytanie moŝe dotyczyć wyłącznie moŝliwości dostępu do kanalizacji kablowej w ramach jednej Sieci Miejscowej. TP, w ciągu 5 DR dokonuje weryfikacji Zapytania. Za przeprowadzenie weryfikacji formalnej Zapytania TP nie pobiera opłat. JeŜeli Zapytanie nie dotyczy jednej Sieci Miejscowej TP zwraca zapytanie Operatorowi bez dalszej weryfikacji. W przypadku stwierdzenia niekompletności Zapytania TP odrzuca je ze wskazaniem powodu (kod odrzutu). 111

112 proces: ZłoŜenie zapytania Zapytanie ROI OA Potwierdzenie przyjęcia zamówienia Negatywna weryfikacja formalna TP HURT Potwierdzenie przyjęcia komunikatu koniec procesu 112

113 proces: ROI Odpowiedź na zapytanie o moŝliwość dostępu do kanalizacji kablowej Przebieg procesu - Odpowiedź na zapytanie o moŝliwość dostępu do kanalizacji kablowej TP, w terminie 10 DR (lub 5 dni w przypadku reasumpcji) począwszy od daty złoŝenia przez Operatora Zapytania udziela odpowiedzi, co do moŝliwości dostępu do kanalizacji kablowej, w której: podaje przyczynę odmowy wydania Warunków Technicznych w przypadku całkowitego braku moŝliwości dostępu do kanalizacji kablowej; wskazuje moŝliwości rozwiązania alternatywnego i/lub częściowego w oparciu o swoje Wolne Zasoby - wskazuje Operatorowi, w jakim zakresie dostęp do kanalizacji kablowej jest moŝliwy; udziela odpowiedzi pozytywnej. 113

114 proces: Odpowiedź na zapytanie o moŝliwość dostępu do kanalizacji kablowej Wydane Pozytywne WT OA Lub Wydane Rozwiązanie Alternatywne i/lub częściowe Lub Przekazanie informacji o braku moŝliwości realizacji zamówienia TP HURT Potwierdzenie przyjęcia komunikatu 114

115 proces: Akceptacja rozwiązania alternatywnego/częściowego reasumpcja zapytania Przebieg procesu - reasumpcja zapytania Jeśli Operator akceptuje przedstawione przez TP rozwiązanie alternatywne i/lub częściowe, składa reasumpcję Zapytania w nieprzekraczalnym terminie 5 dni od dnia otrzymania opisu rozwiązania alternatywnego od TP. Jeśli OA w terminie 5 dni nie prześle reasumpcji Zapytania, to TP zwalnia zarezerwowane zasoby i informuje OA o anulowaniu zapytania o moŝliwość dostępu do kanalizacji kablowej. 115

116 proces: Akceptacja rozwiązania alternatywnego/częściowego reasumpcja zapytania Wydane Rozwiązanie Alternatywne i/lub częściowe OA =<5 DK Akceptacja RA Przejście do procesu wydania WT Lub Brak akceptacji RA Koniec procesu Lub >5 DK TP HURT 116 Potwierdzenie anulowania zamówienia Koniec procesu

117 proces: Wniosek o przedłuŝenie okresu rezerwacji zasobów Przebieg procesu - Wniosek o przedłuŝenie okresu rezerwacji zasobów Na wniosek OA złoŝony przed upływem Okresu Rezerwacji, TP dokonuje jednokrotnej, dodatkowej rezerwacji wolnych zasobów na kolejny okres 21 DR. TP weryfikuje wniosek o przedłuŝenie rezerwacji zasobów. Jeśli wynik tej weryfikacji jest negatywny (nie jest moŝliwe przedłuŝenie rezerwacji) wysyła do OA informację o braku moŝliwości przedłuŝenia rezerwacji. 117

118 proces: Wniosek o przedłuŝenie okresu rezerwacji zasobów Opcjonalnie Wniosek o przedłuŝenie okresu rezerwacji OA Potwierdzenie przyjęcia zamówienia Informacja o braku moŝliwości przedłuŝenia okresu rezerwacji zasobów TP HURT Potwierdzenie przyjęcia komunikatu koniec procesu 118

Pokazać jeszcze